Ultimately though the real explanation, I think, is Google doesn't care since for their own purposes (in LiteRT-LM), they do bundle them. As far as I know, anyway.

While I have no idea who was, I do know that John Ousterhout's text editor and terminal emulators Mx and Tx used "natural scrolling", made pre-1989. Their scroll mechanism is shift + left/right click then drag, using "natural scrolling", e.g. push mouse up to scroll down. Left click scrolls normally, right click scrolls quickly.

There's no reason you couldn't build a solid, headless PC-compatible architecture based around EFI. It would just... cost money. Even in the retrocomputing stuff you see the same thing happen. Older VAXes had very rich boot PROMs, but by the time you get to models like the 4000 "Very Low Cost", most functionality was stripped out of the PROM to save space and cost.

This isn't to disparage them, either. GP admits they are romanticizing, I'm just offering my own perspective on it. When I call old stuff "hacked together piles of garbage", it was meant with the loving connotation of someone who's home office has a MicroVAX 3400, Sun 4/75, DEC PWS 433a, and a POWER9 workstation piled in the corner, all on a KVM switch. I love tinkering on these old machines, but I think it's healthy to remember they're not beacons of 80s/90s perfection, but products that were made and sold under time/cost constraints, as you said.

... Though, I will say, the MicroVAX was running from the late 80s until about 2018 in a university environment, and its HDDs still report no errors. That is pretty remarkable ;)

Yeah, I get that you can jailbreak and get that info anyway. Also that this is specific to front ends like web chat and less about API usage. But as a sibling points out it's also a good way to make post training other models harder. Mostly a "win/win" for the provider.

I'm now in my late 20s, and my impression is these machines were largely always hacked together piles of garbage, they had just cost a lot more ;)

There were highs of elegance, yeah. The OpenBoot PROMs introduced with the SPARCstation were marvelously functional and beautifully elegant, especially compared to the previous pre-boot environment. But when you look under the cover, you find a million patches of duck tape, like Sun having to force their compilers to avoid using the o7 register due to speculative instruction prefetching sometimes triggering DMA activity on a peripheral card and causing an unintended side effect. This was due to one buggy CPU (the 80 MHz Weitek upgrade CPU for the SS2), but the bug required changes for all sun4c kernels (at an minimum).

Or how the ILOM on newer SPARC servers are just embedded PowerPC chips running RedHat Linux. At least in the late 2000s :)

At the end of the day, NetBSD on my SPARCstation 2 is cool, super cool even -- there's even EXA acceleration support for the CG6 framebuffers in X!

But ultimate NetBSD/sparc is basically identical to NetBSD on my raspberry pi. I can even run the big endian port if I want a BE system!

On the other hand, running a contemporary OS like SunOS 4, or something exotic like Sprite, gives a very different experience. And honestly, these 80s OSes themselves feel more "elegant" in a hacker sort of way.

(I'd agree that most mid/late 90s+ Unix systems mostly just feel like worse versions of modern Linux/Unix, though)

Further case in point -- the AXP64 port (64-bit Alpha) of NT didn't have the ability to run 32-bit Alpha software. If you want that, you have to develop WoW64. So in this hypothetical "port Win2k to 64-bit processors", you would need to create WoW64 from scratch. Alternatively, rebuild a lot of software which is old enough to run on Win2k but also aware of 64-bits.

Or take the AXP approach and literally treat AMD64 as a strange 32-bit CPU, not unlike the x32 port for Linux. At that point you have no binary ABI compatibility with any Windows port, and will need a custom compiler port, and compile all executables from scratch.

That said, two things: I use LLMs for coding a lot, and I'm not turning my nose at the use of LLMs here, though I do think the user-facing pages/documentation could use more direct, human-written language.

The other is I do think this is probably something I'd be interested in. I "maintain" a few modified compiler stacks for worth, using Nim to:

- generate libc-less, pure syscall binaries with minimal ELF/PE headers

- generate Cosmopolitan-libc binaries for all platforms

- cross-compile via Zig/LLVM for those platforms

It seems like there is some cool work here, I just think it could be expressed a bit more cleanly and directly on the front-page/docs.

What's strange, is that SunOS, Solaris, and even NextStep all supported higher baud serial mice. If you look at the mouse driver on SunOS for example, you'll see the logic which loops over baud rates until it detects valid mouse data.

And Sun did ship a mouse with a higher polling rate/baud. One. The wired ball mouse for the SPARCstation Voyager.

NetBSD doesn't have the baud detection loop, so there, for this single mouse, you have to change the kernel to make it work: https://www.netbsd.org/ports/sparc/faq.html#voyager-mouse

What came to mind while reading through it is that all of the information and details appear to be technically correct, but they don't really communicate much about the project to someone who knows nothing about it.

It's weird. I feel like this could maybe be interesting, but also... huh?

I feel like the idea is to produce a small, self-contained compiler with simple semantics that generates simple executables with a simple runtime model, and a basic supervisor model for scheduling tasks. Okay, that's cool.

But "vibe coded mass of JavaScript running in node.js" doesn't really mesh well with that vision, at the least to me.

Also, as whatever LLM that generated that table says, the code it generates isn't "seriously optimized". I don't buy the idea that compiler optimization is something you can bolt on to a project like this later, after you've written the IR and all the platform porting code and whatever.

It's so hard to tell what the real goal is from the page, that I'm suspecting maybe the author doesn't really know either.

I'm going to say up front that I'm not as familiar with this period of history as I should be, but -- would it be totally unfair to say the same of the "Industrial Revolution"?

I'm not gonna say they're equivalent by any means, but my understanding is the "Industrial Revolution" was hellish for many people. Maybe the mistake is the framing that "the revolution" or "the next big thing" is always a good thing?

On the one hand I get it, TLS is pretty heavy, and it makes sense to take advantage of a VPS or Cloudflare or however you want to do it.

But once you are spinning up a VPS, the question is ... why the Pi? The VPS in the article has less RAM, but more storage. If you're already doing TLS termination on the VPS (the most RAM intensive part), you might as well just do the whole shebang there.

I know this is all for fun, I'm just wondering -- is the Pi Zero really too slow to handle TLS, especially with an optimized TLS library? In this setup, the Pi is already being directly exposed to the Internet anyway, there's no VPN being used. That ARM11 isn't "fast", but surely a 1 GHz ARM11 can handle an optimized TLS library serving some subset of TLS1.2.

But what stands out to me is that it's barely able to draw a "recognizable" pelican at all. The Devstral 2 model even looks slightly better, though maybe I'm splitting hairs: https://simonwillison.net/2025/Dec/9/

I've gotten a lot of use out of Mistral models, and I imagine this model is pretty good at other things, but it really feels like a 128B parameter dense model should be at least a little better than this.

But I do wonder about the practicality. This would, I presume (never done DOS development, never touched a memory extender) only run on 386+ CPUs, and maybe more importantly, probably require a newer CPU than that to run anything non-trivial at acceptable performance. So I wonder how many "real DOS machines" this can practically target.

Still, it is massively cool.