In 2005, I saw a talk but Alan Kay. His big reveal in the middle was that the talk was using Squeak (bytecode-interpreted Smalltalk) and not PowerPoint for his slides. He showed this off by dropping into an inspector and doing some live coding in the middle. But the slide a couple before that reveal had contained full-motion video (which was still pretty rare in slides back then). The video had been an MPEG-1 video (so not the latest CODEC: MPEG-2 was feasible to decode on the CPU then, MPEG-4 non-AVC was with an optimised implementation). The CODEC was, itself, written in Smtalltalk. Computers are ludicrously fast now. Even the 'slow' Java implementations from the late '90s were an order of magnitude faster than CPython and not that slow on modern hardware. A modern optimising JIT gains you another order of magnitude or so. CHERI's capability model is not quite the shape of hardware capability systems from the '60s (different things got faster at different rates, now compute is almost free but non-local memory accesses are very expensive, whereas the converse was true back then), but the entire field was discarded for 20-30 years because RISC showed that you could make simpler computers fast and do things in software on a fast-and-simple core that outperformed doing them in a more complex implementation. Right up until you start to build complex out-of-order pipelines, at which point you realise that you have a lot of fixed overhead per instruction and doing more work per instruction is where the big performance wins come from.

Most of UNIX was a simplification of MULTICS. Most ideas from mainframes were silently ignored, even though a modern microcontroller is more powerful than a GE-645 or most Lisp machines (and vastly more powerful than the Alto, which happily ran a full OS in Smalltalk). Filesystems with rich metadata and portable notions of sub-file structure, for example, were lost. Everything-is-a-something was a pattern from Lisp and Smalltalk machines, but the 'something' being something self-describing, introspectable, and with accompanying code was too slow on a PDP-11, so we ended up with just streams of bytes instead.

And the average Office worker has no idea where Sharepoint is hosted. I mean, they know it's 'the cloud', but that covers M365 and on-premises, from their perspective. Anything that isn't the computer on their desk. And the coverage of the Sharepoint thing made it really hard to tell that M365 is not affected (I haven't actually seen this explicitly stated, but I think it's true?).

The most annoying thing about our industry is that we go through cycles where we start with a really good idea, but it isn't quite feasible on current computers. Then someone comes along with a less-good version that's actually possible to ship in the mass market. Then an entire generation of programmers grows up with the simplified version, running on computers a thousand times more powerful, and at least a hundred times more powerful than the richer system required. But they have never seen the more complex version and believe that limitations inherited from the simplified version are intrinsic to the problem being solved. And then they come up with something layered on top that repeats the cycle.

Aside from primitives, every object is allocated from the GC heap, but the degree to which this implies suffering is often overstated. Most objects that would have been stack allocations never escape the young generation and so GC adds very small overhead for them. Stack and GC allocations cost the same amount, only the deallocation costs more in the GC heap. In some implementations, the compiler can do escape analysis and either move non-escaping allocations to the stack or mark them in GC as trivially dead and not needing scanning.

I suspect the optimisations are less important these days, but the bigger issue is that FreeBSD cares about binary compatibility. This means that any code linked against the version with the exposed type needs to be supported and so you don't get any benefit from making it opaque. If you want to then you need to bump the version symbols of everything that takes a FILE*. And even that is not necessarily enough because some program may have created its own FILE instance and then passed it to a shared library that then passes it to libc and this would be an ABI break for that shared library. So doing that properly requires a lot of staging, probably using one of the bits in _flag for an ABI version and adding accessors internally. Just making it opaque doesn't really help because it's backwards-incompatible layout change, not the header change, which is the ABI break. And hiding it from the header doesn't prevent anyone else from looking inside it and depending on those details, because C visibility rules are not a security boundary.

I really liked the NeXT stuff. In particular, Interface Builder was a terrible name because, unlike a lot of things that copied it, it wasn't a tool for building interfaces. It was a tool for building serialised object graphs, which typically included a set of view objects. The fact that you could wire controllers up to views with a proxy for a model made it a joy to use for document-driven things. But even NeXT lost some of the nice things in Smalltalk. The interface builder was a separate tool, whereas in Smalltalk you could just introspect over UI objects with the built-in inspectors and modify them. With EtoileUI, we built something closer to Smalltalk on top of the OPENSTEP APIs, with the view hierarchy exposed as a consistent object model that let you recursively inspect it and map it to different UI models. My impression of SwiftUI was that it went further away from the Smalltalk model. Everything is done in code, rather than having a live structure of objects that you can interact with.

The sincere people are the worst sometimes. There are three kinds of replies that encourage engagement: People just trolling (easy block, though I did that a bit late in one thread today). People who are too lazy to look things up (fairly easy to ignore). People who genuinely want to learn something and are asking questions that suggest that they've thought about the topic. The last set are the ones I really want to talk to. But sometimes I have to remind myself not to. Or, at least, not to today.

The UNIX Haters' Handbook has some good commentary. It's worth remembering that shared libraries were one of those 'over-complicated' Multics ideas and, when the folks behind UNIX went on to do Plan 9, they still regarded it as over-complicated even though most UNIX variants at the time had implemented them. Though Multics shared libraries were much richer (they could have their own security contexts and protect data from callers, for example). CHERIoT's compartments are closer to Multics shared libraries than to anything in UNIX.

, any progress on OCI container images for the full base system? I'm trying to write an article for the FreeBSD Journal and I want to test some commands people should run on a pristine system. For Ubuntu, I'd just create an ephemeral container image, but for FreeBSD there isn't an image that's sufficiently like the full base system for this to work.