Author here.

This is one of those things, where 99.999% of all IT people have never even heard or imagined that things can be different than "how we have always done it." (Obligatory Douglas Adams quote goes here.)

This makes a certain kind of people, self-secure in their own knowledge, burst out words like "clueless", "fail miserably" etc. based on insufficient depth of actual knowledge. To them I can only say: Study harder, this is so much more technologically interesting, than you can imagine.

And yes, neither the iAPX432, nor for that matter Z8000, fared well with their segmented memory models, but it is important to remember that they primarily failed for entirely different reasons, mostly out of touch top-management, so we cannot, and should not, conclude from that, that all such memory models cannot possibly work.

There are several interesting memory models, which never really got a fair chance, because they came too early to benefit from VLSI technology, and it would be stupid to ignore a good idea, just because it was untimely. (Obligatory "Mother of all demos" reference goes here.)

CHERI is one such memory model, and probably the one we will end up with, at least in critical applications: Stick with the linear physical memory, but cabin the pointers.

In many applications, that can allow you to disable all the Virtual Memory hardware entirely. (I think the "CHERIot" project does this ?)

The R1000 model is different, but as far as I can tell equally valid, but it suffers from a much harder "getting from A to B" problem than CHERI does, yet I can see several kinds of applications where it would totally scream around any other memory model.

But if people have never even heard about it, or think that just because computers look a certain way today, every other idea we tried must be definition have been worse, nobody will ever do the back-of-the-napkin math, to see if would make sense to try it out (again).

I'm sure there are also other memory concepts, even I have not heard about. (Yes, I've worked with IBM S/38)

But what we have right now, huge flat memory spaces, physical and virtual, with a horribly expensive translation mechanism between them, and no pointer safety, is literally the worst of all imaginable memory models, for the kind of computing we do, and the kind of security challenges we face.

There are other similar "we have always done it that way" mental blocks we need to reexamine, and I will answer one tiny question below, by giving an example:

Imagine you sit somewhere in a corner of a HUGE project, like a major commercial operating system with al the bells and whistles, the integrated air-traffic control system for a continent or the software for a state-of-the-art military gadget.

You maintain this library, which exports this function, which has a parameter which defaults to three.

For sound and sane reasons, you need to change the default to four now.

The compiler wont notice.

The linker wont notice.

People will need to know.

Who do you call ?

In the "Rational Environment" on the R1000 computer, you change 3 to 4 and, when you attempt to save your change, the semantic IDE refuses, informing you that it would change the semantics of the following three modules, which call your function without specifying that parameter explicitly - even if you do not have read permission to the source code of those modules.

The Rational Environment did that 40 years ago, can your IDE do that for you today ?

Some developers get a bit upset about that when we demo that in Datamuseum.dk :-)

The difference is that all modern IDEs regard each individual source file as "ground truth", but has nothing even remotely like an overview, or conceptual understanding, of the entire software project.

Yeah, sure, it knows what include files/declaration/exports things depend on, and which source files to link into which modules/packages/libraries, but it does not know what any of it actually means.

And sure, grep(1) is wonderful, but it only tells you what source code you need to read - provided you have the permission to do so.

In the Rational Environment ground truth is the parse tree, and what can best be described as a "preliminary symbol resolution", which is why it knows exactly which lines of code, in the entire project, call your function, with or without what parameters.

Not all ideas are good.

Not all good ideas are lucky.

Not all forgotten ideas should be ignored.

Poul, have you looked at the Mill Architecture? It doesn't provide capabilities but provides "turfs". A turf is a set of [base..limit) regions in a single address space. Threads within a turf can only see what the turf allows them to see. Regions can be shared between turfs if so desired (& how one may communicate large amounts of data). When a thread makes a "portal call" it is in another turf and can only see what is in that turf (+ call args, passed on the "belt"). Not clear if this will go anywhere & might get forgotten but it is an interesting architecture worth exploring.

What a impressively arrogant double-down.

You once again present no technical argument for your extraordinary claims and position, let alone the extraordinary evidence required. You present no technical analysis of known problems or limitations with historical or conceptual designs. You present no solutions, workarounds, or even argue those problems are no longer relevant.

You fail to even fallaciously argue that past success indicates future success. You jump straight to past failure indicates future success.

You just assert, without evidence, that old, flawed, failed, outcompeted technology is the future and anybody who uses facts and evidence to disagree is a arrogant, ignorant inferior to your staggering intellect. Bravo.

Word to the wise, if you let off on the self-aggrandizing arrogance and had a little epistemological humility when proposing we should revisit old ideas instead of implying people who disagree are troglodytes then you would not come across as clueless.