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.