jonathaneunice
Feels useful for watermarks that are pleasant to look at.
This is a full infosec emergency unfolding here. No matter how grinding it is to motivate a team to invest in protection or resilience (and it is grinding): We gotta get ready. Stat! The AI-accelerated attacker apocalypse has begun. It's boom, boom, boom, thanks for everything, on to the next. They have us sighted and are firing for effect.
So credential rotation, tripwire secrets, DFIR on standby, solid vulnerability and intrusion detection, real listening to that signal, minimized blast radius, spending caps and time limits and tight scoping on credentials, fast incident alerting... We need to get on a real war footing here.
I end up reading more sources and exploring more things. If you want to dismiss that as "trivia," or dismiss the topics I want to know about, okay. But it's important to me. You could equally deride search engines as wanton seas of advertising, and tell me I need to head to a library and its paper-based card catalog, the only true and proper way to do research. :shrug:
It's true there are a lot of weak models out there. I tend to use the frontier models, and they are great research assistants IME.
I end up thinking _more_ about many subjects, analyzing them more deeply, using AI. Before search engines, if I wondered about subject X, it was unlikely I'd have a resource at hand that could really tell me about X. Maybe ask around, see if anyone in my circle had some knowledge or an opinion. But for most topics, there were no options. No one would know what that company makes, or why tungsten in light bulbs, or whatever. And for most questions, I was not going to go to the library or start a full research project. Just too effort-intensive. Post search engines, I could do a little research, if I was really interested. Maybe 50% or 60% of the time get a reasonable answer.
Now using AI I ask a lot more questions: Why tungsten? What is this "yarn works" thing on the map? What is my local high school's per-student budget, and how does that compare to the other school districts in the state? What is this thing? What's its history? Why this not that?
I'm curious and interested in a lot of the world around me. AI doesn't seem to be making me dumber; it seems to be enabling a much higher degree of curiosity and, better yet, a much higher degree of "finding out."
From the command line: unsloth studio
Browse to the URL it gives you (eg http://127.0.0.1:8888/)
Download a good fast local model e.g. Gemma-4-12B (small machine) or Qwen3.6-35B-A3B (larger memory). Or a Nemotron model, if you prefer that.
Then you'll have both your backup/emergency assistant that runs on your own computer and be gaining skills in a common, frequently-updated, well-supported program.
But overall there weren’t many Smalltalk apps for individual users. Most were organizational: JPMorgan (derivatives risk), Orient Overseas Container Line (global shipping logistics), Texas Instruments (fab automation), Deutsche Bahn (scheduling the German railway system). These were complex internal systems built on a graphical, fast-development, integrated platform, when such things were rare and nowhere available off the shelf. Customers often considered them "secret sauce" or strategic differentiators and weren't going to say much about them externally. Vendors were often prohibited from naming customers. As of mid-2025 at least, JPMorgan’s Kapital was still in production, and JPMorgan was still hiring Smalltalk developers for it.
GemStone, the Smalltalk-based object database, had a similar customer list, including JPMorgan Chase, UBS, Siemens, TI, and Florida Power & Light. That's a backend rather than an app, though in the Smalltalk world the line between database and application tiers is much blurrier. Still in use, though ownership has passed through several hands since the 80s.
Many apps not written in Smalltalk per se were direct idea-descendants. NeXTSTEP and WebObjects were built in Objective-C at NeXT, then bought by Apple. (Objective-C was explicitly "let's bring the Smalltalk lessons to a broader world.") In its early days WebObjects could build database-backed GUI and web apps amazingly easily compared to any competitor, and Apple used it for its online store and the iTunes Store. Another cousin was Metaphor Computer Systems. Founded by Xerox veterans, it sold Analyst-like workstations that let brand managers at consumer-goods giants like P&G, General Mills, Pillsbury, and Sara Lee analyze and report on sales and mix data, often pulled from point-of-sale scanners. That level of "what's happening in the field?" integration, in near-real-time (hours not months), with everything pulled together on one screen, was essentially unique at the time. And that users could build their own charts, reports, and workflows without programming? No one else had that either.
So there were notable Smalltalk apps, and many of them operated at substantial scale. They just weren’t consumer apps. And a lot of the direct descendants were much the same.
Efforts to standardize Unix go way back (e.g. /usr/group in 1984). Most people hadn't yet even remotely heard of Unix and we were already needing to smooth over fragmentation. POSIX first ratified in 1988. Unevenly-conforming implementations arrived a year or few later. But that ".1" was only the first, thinnest, most obvious slice of "we should all do this the same way." Overall we've been working to bring Unix and its descendants into alignment for 40+ years. Doesn't feel fully wrangled even now. There's a reason we still might need $POSIXLY_CORRECT.
I too have plumbed the call stack for hidden-maybe-forbidden knowledge from the caller, and it is always fraught. No matter how good one's intentions. Forget dynamic type testing. Forget Perl's `wantarray` dynamic introspection of "what does the caller want?" Those are small potatoes. This is full on "who's calling me and what do I want to send back as a result?" The people who will never forgive you for type testing are going to straight-up excommunicate whoever wrote this! And yet...it makes complete sense. Based on the promises made, you have to do something... and you're already in "what is the least of the evils?" territory, because you're going to have to do something that someone—maybe a lot of someones—will call evil.
My admiration for Pendulum just increased. This is sin-eating.
But selling to Sun Microsystems as a vendor was a joy. It paid bills like clockwork (net 35 IIRC). Completely showed up all the multi-$B IT competitors. They preached hyper-efficiency, but Sun delivered it in its own dealings. Unfortunately after the dot-com downfall Sun extended days payments outstanding (DPO) just like everyone else.
Cognito itself is a very AWS tradeoff. It's delightfully inexpensive. It quite effectively protects one of the most relentlessly attacked parts of any web service. It supports workflows essential as you scale, like SAML federation ("single sign on/SSO"). It basically works, day in and day out.
But OMG, the sharp edges! It has sharp edges to spare, even compared to other AWS services, for which sharp edges and exposed corners are just par for the course.
Then you try to go the next step, e.g. add multi-region disaster recovery and failover. That seemingly straightforward requirement to scale up is "left as an exercise for the reader."
Cognito has all the virtues of a utility service, including the developer experience.
2003 called and wants help finding its tech stack which has apparently wandered away from its care home.
I've built large, deep product evaluation frameworks, and it is 100% of the time a running argument with stakeholders, inside and out, "well you should have measured it this way" or "I think we should be targeting X not Y" or "why didn't you consider Z in the metric??"
The Pareto Front in practice is squishy, fuzzy, and often quite moist and moldy.
I have successfully used AI to generate generates "concept art" and logos for projects, presentations, and publications. It seems to make the outcomes more approachable, more understandable, and certainly more aesthetically pleasing.
It is not a matter of replacing human effort or skill, and certainly not a matter of adding cheap ornamentation. If AI weren't available, I usually wouldn't have the time, money, energy, or will to pursue those illustrations. I say this as someone who has historically spent what seems like a vast amount of time, energy, and money sourcing art. In a former life as as publisher I even hired full-time artists and insisted on custom artwork. But my current work no longer has that luxury. I still want the best possible looks, and the best possible outcomes.
Kermit was an extraordinary monument to portability in an era when "portable" often meant "we have individually accommodated every incompatible system anyone has ever built or might possibly still be using, however improbably."
The office-document format wars played out _at least_ twenty years ago.
The path dependence and "everyone uses it" (installed base) inertia of Microsoft's formats continue to benefit Microsoft (and its OOXML formats), despite ODF being more open and, in many ways, superior--not least because it's easier to implement, manipulate programmatically, and reason about.
But refighting that battle seems pointless. Users and the market have moved on, not least toward cloud-based tools; file formats no longer seem the primary barrier to competition.
I personally love a lot of the Claude (or LLM) lingo. Load-bearing, gate, canonical, blast radius, and friends do a lot of tight, effective heavy-lifting in my world. I even love the em-dashes (—) and the *bold the main points* memo style, both of which I have used successfully for decades.
It's seeing them in every analysis and post—the constant repetition becoming over-repetition—that makes them the Claude voice shouting "AI wrote this!" that seems to be causing LLM allergic reactions.
Tried on a "this test suite is weaker than I'd like, too often depending on internal state rather than outcomes" problem via Cursor, asking it to "review and suggest solutions." It gave me a quality overview of the test approaches, strengths, weaknesses, and gaps then recommended a disciplined multi-prong approach based on a common, trusted testing library (https://hypothesis.readthedocs.io/en/latest/). It broke down the things we could do this improvement pass or leave to later (staged scoping), identified some very hard/possibly-out-of-scope cases and gave me the option of focusing on them or not, and organized new tests in a logical way. After one round of feedback and plan tuning, I put it in agent mode and let it work. A few minutes later I had a much better test suite.
Have not tried Grok before and didn't have much confidence, but it did great. Exactly the sort of complex, detailed, nuanced analysis and multi-step task I would previously only trusted to GPT or Opus.
_Update_: It's now also found a substantive long-standing bug. After testing improved asked it to do overall code and packaging review. It caught a few glitches and oversights, mostly cosmetic IMO, but certainly worth cleaning up. But also some error-handling weaknesses, and one embarrassing functional bug. Which it has now also fixed and added to the tests. Color me impressed.
You'll need MDM, installed anti-virus/anti-malware, and reasonable update policies, as with any endpoint. But have passed multiple years' audits with mostly-macOS fleet.
Maybe not strictly impossible, but ANE was designed with an earlier, pre-LLM style of ML. Running LLMs on ANE (e.g. via Core ML) possible in theory, but the substantial model conversion and custom hardware tuning required makes for a high hurdle IRL. The LLM ecosystem standardized around CPU/GPU execution, and to date at least seems unwilling to devote resources to ANE. Even Apple's MLX framework has no ANE support. There are models ANE runs well, but LLMs do not seem to be among them.