At this moment in time, 125.

Then the university library opened my eyes to the world of Xerox PARC, and the computing decades that predated UNIX, and my point of view changed forever, that cloning UNIX all the time couldn't be the epitome of OS design.

At least I agree with Rob Pike in something,

"Using Unix is the computing equivalent of listening only to music by David Cassidy"

From https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...

AIM and MAC seem like a very interesting system for enforcing security guarantees, and they partially solved the malicious dependencies problem as well.

Ours was just for CS undergrads mostly when I was there, and wasn't too overloaded. I guess we had about fifty terminals maybe on campus at least.

I remember we could dial it up from a couple of terminals in our Halls of Residence over JANET.

You are right, I never found it that slow either - loved that machine and the terminal to terminal messaging was crazy fun.

cuz (almost) no one uses it any more.

i did, a bit long ago.

i thought some unixen had acls?

i remember reading some man pages about that, i think on an svr4 box, back in the day.

Better than going the Multics way, which was being theoretically portable but not actually capable of being ported off a very short list (two... a list of two) mainframe computers that implement an architecture with no future.

STOP (see my other comments) still used all four rings for quite a long time. Shortly before I joined, they had rearchitected the kernel in a way that could achieve the same levels of security without them. My colleagues joke about having to be good at writing kernels because they needed four of them for a single system. Performance when running at/transitioning between different hardware levels was less than stellar.

The problem today, though, is that the hardware stopped supporting them. x86-64 now only has ring 0 and 1 (plus -1, -2 for virtualization and SMM, etc... but those aren't quite the same). aarch-64 has four (flipped, so 0 is user, 1 is OS, etc...) but I'm still not certain how these are actually used in practice. 3 and 4 seem similar to x86's -1, -2, but I need to study that more. So in a sense, Linux/Unix do use all four but not necessarily at an OS level and not in the multics way.

> - better permissions by default

I agree. STOP is built around this model; it doesn't even have the concept of root and I personally think it's the right way to go. But Linux does have something similar in SE Linux.

> - finer-grain memory permissions

I'm curious about what you have in mind. STOP used segments back when that's what the hardware expected, but now hardware is designed around the paging and virtual address model. I'm not sure there's a whole lot of room for the OS to experiment in this space, but happy to be proved wrong.

> - no buffer overflows (and minimal memory errors)

At some level, dealing with memory requires trusted hardware access, and it's always possible for a programmer to screw something up there. I'm a little surprised things like tagged memory and CHERI (which require hardware support) haven't taken off. Maybe it's still coming, but it seems not many know or care about it.

There's also the write-not-execute (W^X) model started by PaX linux that removes the writable attribute from memory used to store instructions. I don't remember now if that's actually used in any of the nix's. I implemented support for it in STOP, but there's a lot of software (especially JIT'd languages) out there that breaks when enabled. At the end of the day, it's a mitigation, not a "fix."

> - long command names in addition to short abbreviations (easy to implement in linux/unix, just missing)

> - multiple entry points for commands (currently faked with symlinks)

> - (related) being able to call into an executable like a library

> - unified storage model (can sort of be faked with mmap())

I'm not familiar enough with multics to understand the benefits of these. Would you consider hard links to be the same as symlinks for multiple commands? And is there a benefit to calling directly into an executable instead of making a shared library and a thin executable that uses it? Would love to hear more about what it is you want for all these.