Always fun to see Multics pop up; the influence it had on computing is pretty impressive and its influence lives on in many projects. As just one personally relevant example, the SCOMP mentioned in the glossary [0] and described in more detail on the history page under 5.4.1 [1] became the STOP operating system which is still in active development and is what I still work on today. (Technically, the SCOMP was the whole machine, and STOP "SCOMP Trusted Operating Program" was its operating system). Up until pretty recently, we still had a Multician working on STOP, and have a guy from the Honewell days still plugging away on it.
I've been gainfully employed for well over a decade working on it and it's been around in one form or another for over 40 years. We're constantly improving performance and capabilities, adding support for more hardware, supporting the specific needs of our customers etc... Just like any modern operating system, it's never really "complete". STOP is a "security from the ground up" OS, where security isn't just a first-order priority, it's the entire point, typically used in/as multilevel security solutions.
There's a link in my profile to the company products page for my group, which includes a link to the STOP OS page. There used to be additional documents you could download from those pages, but it looks like they're not working any more.
The short version is that it implements three different MAC (mandatory access control) policies (RBAC, Bell-LaPadula, Biba) and the standard *nix DAC policies. It's designed for safely handling/moving data on/between multiple classification levels. (See the SCOMP section in [0] for history). From a user perspective, it's very similar to Linux, with a largely Linux-like ABI and similar user interfaces, including a full X/xfce GUI environment if you want, though most actual deployments tend to run headless with only required software loaded. It runs on both small embedded boards and large enterprise servers and a bunch in between.
The data diode one reminds me of a null-modem cable I once did where I forked the TX line to a second DB-25 so that a server could eavesdrop the data coming from the PABX to the call tracking box. The server would then push it to all stations connected to a socket, where a Java applet would display the proper greeting the support agent would use when the call came in.
We used Multics when I was at Bristol Uni in the UK c.1980. I can only remember two things about it:
1) The system was initially deemed slow, so they installed an extra 256 KB of RAM (for a system serving dozens/hundreds of students - Bristol was regional computing center), and that made a difference! This was a big deal - apparently quite expensive!
2) Notwithstanding 1), it was fast, and typical student FORTRAN assignments of a 100 or so lines of code would compile and link essentially instantly - hit enter and get prompt back. I wish compilers were this fast today on 2025's massively faster hardware!
My Operating Systems class as an undergrad used a book written by the Multics guys.
I hated it. It would present a bunch of apparently incompatible techniques for e.g. job scheduling, and then say that Multics implemented all of them. I immediately understood why UNIX came about: the Multics designers appeared incapable of having opinions, which led to an OS that was bloated and hard to understand.
That class was a long time ago, and I was a young, arrogant, and uninformed programmer, and maybe that take was wrong. But it left a strong impression at the time, and it was one of the few books from my undergrad days that I sold back instead of keeping.
AIM and MAC seem like a very interesting system for enforcing security guarantees, and they partially solved the malicious dependencies problem as well.
A few multics features that I wish unix/linux had:
- ring based security (allows for multilevel containers at user level, among other things)
- better permissions by default (mandatory access control, acls, etc.)
- finer-grain memory permissions (segments vs. pages, etc.)
- no buffer overflows (and minimal memory errors)
- 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())
and some features I wish unix didn't have (and which multics didn't need):
- dumping new kernel APIs into /proc
Ironically linux is much larger than multics ever was, but much (most?) of it isn't basic kernel functionality but things like libraries, tons of drivers for everything imaginable, lots of network protocols, file systems, etc., and a bunch of kernel modules.
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.
I certainly agree that drivers and portability are Linux's best features (NetBSD scores even better on portability and compatibility.) The point of the comparison was to say that the code and memory size cost of Multics (and its core functionality and abstractions) was considered prohibitive in 1969 when Unix was being created, but is basically in the noise for systems like Linux in 2025.
Sadly segmentation fell out of vogue and was dropped from x86 because ... no OS ended up using it! (Though it was used in the 32-bit implementation of Google Native Client, a sandboxed environment for safely running x86 code.)
But a Multics-informed design is not inherently unportable or antithetical to drivers. Ring-based security can allow for better isolation and easier driver development. Maybe even ingesting and reusing all of those linux drivers?
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.
> I'm a little surprised things like tagged memory and CHERI
I think we're seeing some improvements in memory safety for C (e.g. -fbounds-safety in clang) and C++ (e.g. -fsanitize=address) as well as adoption of more memory-safe languages (Rust, Swift, Java, Go, etc.) And I wouldn't be surprised to see Apple eventually add some hardware support for memory safety to Apple Silicon (note that Morello was a prototype implementation of CHERI for ARM.)
> And is there a benefit to calling directly into an executable instead of making a shared library and a thin executable that uses it?
I think so - having one thing instead of two, and being able to use it for either purpose with minimal effort.
Thanks! This is a really useful source for computer science history, I was just thinking to myself that I keep reading UNIX history, but that I know very little about Multics. Looks like I can keep my evening busy for quite some time with this one.
For a little while at the university I became what happens to many software engineering students, a UNIX zealot that used to write email signatures with the usual M$ joke back then.
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"
This such a rabbit hole. I only really knew of multics as 'the thing before unix'. I had no idea it was interesting in its own right. I have to stop myself reading or I'll be downloading the papers (I love old comp sci papers)...
From the front page: "preserve the technical ideas and advances of Multics so others don't need to reinvent them"
Which ideas and advances from multics do we not do anymore?
Always fun to see Multics pop up; the influence it had on computing is pretty impressive and its influence lives on in many projects. As just one personally relevant example, the SCOMP mentioned in the glossary [0] and described in more detail on the history page under 5.4.1 [1] became the STOP operating system which is still in active development and is what I still work on today. (Technically, the SCOMP was the whole machine, and STOP "SCOMP Trusted Operating Program" was its operating system). Up until pretty recently, we still had a Multician working on STOP, and have a guy from the Honewell days still plugging away on it.
[0]https://www.multicians.org/mgs.html#SCOMP [1]https://www.multicians.org/history.html
This operating system sounds very interesting! How active is the development? I would imagine it's the type of thing that eventually gets "complete"
I've been gainfully employed for well over a decade working on it and it's been around in one form or another for over 40 years. We're constantly improving performance and capabilities, adding support for more hardware, supporting the specific needs of our customers etc... Just like any modern operating system, it's never really "complete". STOP is a "security from the ground up" OS, where security isn't just a first-order priority, it's the entire point, typically used in/as multilevel security solutions.
Are there any documents we can use to learn more about it? What does it look like to the user? Is it intended to be embedded?
There's a link in my profile to the company products page for my group, which includes a link to the STOP OS page. There used to be additional documents you could download from those pages, but it looks like they're not working any more.
The short version is that it implements three different MAC (mandatory access control) policies (RBAC, Bell-LaPadula, Biba) and the standard *nix DAC policies. It's designed for safely handling/moving data on/between multiple classification levels. (See the SCOMP section in [0] for history). From a user perspective, it's very similar to Linux, with a largely Linux-like ABI and similar user interfaces, including a full X/xfce GUI environment if you want, though most actual deployments tend to run headless with only required software loaded. It runs on both small embedded boards and large enterprise servers and a bunch in between.
[0] https://multicians.org/b2.html
The data diode one reminds me of a null-modem cable I once did where I forked the TX line to a second DB-25 so that a server could eavesdrop the data coming from the PABX to the call tracking box. The server would then push it to all stations connected to a socket, where a Java applet would display the proper greeting the support agent would use when the call came in.
I guess I’m dating myself quite a bit.
We used Multics when I was at Bristol Uni in the UK c.1980. I can only remember two things about it:
1) The system was initially deemed slow, so they installed an extra 256 KB of RAM (for a system serving dozens/hundreds of students - Bristol was regional computing center), and that made a difference! This was a big deal - apparently quite expensive!
2) Notwithstanding 1), it was fast, and typical student FORTRAN assignments of a 100 or so lines of code would compile and link essentially instantly - hit enter and get prompt back. I wish compilers were this fast today on 2025's massively faster hardware!
Same where I went at Leeds Uni in the mid 80s.
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.
My Operating Systems class as an undergrad used a book written by the Multics guys.
I hated it. It would present a bunch of apparently incompatible techniques for e.g. job scheduling, and then say that Multics implemented all of them. I immediately understood why UNIX came about: the Multics designers appeared incapable of having opinions, which led to an OS that was bloated and hard to understand.
That class was a long time ago, and I was a young, arrogant, and uninformed programmer, and maybe that take was wrong. But it left a strong impression at the time, and it was one of the few books from my undergrad days that I sold back instead of keeping.
The “ Recent Changes” part of the site is depressing
Recent Changes 08/03 Multicians: Jim Bush died in July 2025.
07/14 Multicians: Norm Barnecut died Dec 09, 2023.
05/24 Multicians: Nate Adleman died Sept 19, 2022.
05/15 Simulator: Release 3.1.0 of the DPS8M simulator was released.
05/12 Multicians: Richard Gardner died in 2025.
05/05 Multicians: Art Bushkin died in Feb 2024.
You can see exactly how many people have died on their log page: https://www.multicians.org/changes-old.html
At this moment in time, 125.
20- & 30- somethings in the 80s are now mostly past retirement age. Actuarial attrition is a fact.
I went and looked up my former CS professor who I knew had worked on Multics. And unfortunately learned that he had passed away a few years ago.
Quite interesting are the collection of myths,
https://www.multicians.org/myths.html
And naturally, B2 Security Evaluation,
https://multicians.org/b2.html
The Data Security page is very interesting as well: https://multicians.org/multics-data-security.html
AIM and MAC seem like a very interesting system for enforcing security guarantees, and they partially solved the malicious dependencies problem as well.
It's also the home of the Three Questions (about each bug you find): https://www.multicians.org/thvv/threeq.html
A few multics features that I wish unix/linux had:
- ring based security (allows for multilevel containers at user level, among other things)
- better permissions by default (mandatory access control, acls, etc.)
- finer-grain memory permissions (segments vs. pages, etc.)
- no buffer overflows (and minimal memory errors)
- 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())
and some features I wish unix didn't have (and which multics didn't need):
- dumping new kernel APIs into /proc
Ironically linux is much larger than multics ever was, but much (most?) of it isn't basic kernel functionality but things like libraries, tons of drivers for everything imaginable, lots of network protocols, file systems, etc., and a bunch of kernel modules.
> tons of drivers for everything imaginable
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.
I certainly agree that drivers and portability are Linux's best features (NetBSD scores even better on portability and compatibility.) The point of the comparison was to say that the code and memory size cost of Multics (and its core functionality and abstractions) was considered prohibitive in 1969 when Unix was being created, but is basically in the noise for systems like Linux in 2025.
Sadly segmentation fell out of vogue and was dropped from x86 because ... no OS ended up using it! (Though it was used in the 32-bit implementation of Google Native Client, a sandboxed environment for safely running x86 code.)
But a Multics-informed design is not inherently unportable or antithetical to drivers. Ring-based security can allow for better isolation and easier driver development. Maybe even ingesting and reusing all of those linux drivers?
>better permissions by default (mandatory access control, acls, etc.)
i thought some unixen had acls?
i remember reading some man pages about that, i think on an svr4 box, back in the day.
> - ring based security
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.
> I'm a little surprised things like tagged memory and CHERI
I think we're seeing some improvements in memory safety for C (e.g. -fbounds-safety in clang) and C++ (e.g. -fsanitize=address) as well as adoption of more memory-safe languages (Rust, Swift, Java, Go, etc.) And I wouldn't be surprised to see Apple eventually add some hardware support for memory safety to Apple Silicon (note that Morello was a prototype implementation of CHERI for ARM.)
> And is there a benefit to calling directly into an executable instead of making a shared library and a thin executable that uses it?
I think so - having one thing instead of two, and being able to use it for either purpose with minimal effort.
Thanks! This is a really useful source for computer science history, I was just thinking to myself that I keep reading UNIX history, but that I know very little about Multics. Looks like I can keep my evening busy for quite some time with this one.
For a little while at the university I became what happens to many software engineering students, a UNIX zealot that used to write email signatures with the usual M$ joke back then.
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...
I wonder who the appropriate musician is for Windows?
(Note Windows also has a Posix compatibility layer - WSL1; WSL2 probably qualifies as using Linux, albeit wrapped in a VM.)
my personal favourite page: https://www.multicians.org/memorabilia.html
This such a rabbit hole. I only really knew of multics as 'the thing before unix'. I had no idea it was interesting in its own right. I have to stop myself reading or I'll be downloading the papers (I love old comp sci papers)...
From the front page: "preserve the technical ideas and advances of Multics so others don't need to reinvent them"
Which ideas and advances from multics do we not do anymore?
Related:
Unix and Multics (2019) - https://news.ycombinator.com/item?id=40315724 - May 2024 (76 comments)
Unix and Multics History - https://news.ycombinator.com/item?id=40065928 - April 2024 (3 comments)
Multics and AS400：DPS8M on IBM PASE for I (OS/400) - https://news.ycombinator.com/item?id=39308420 - Feb 2024 (4 comments)
Multics Simulator - https://news.ycombinator.com/item?id=37304367 - Aug 2023 (15 comments)
So! You want to use Multics? (1979) [pdf] - https://news.ycombinator.com/item?id=33366716 - Oct 2022 (5 comments)
Wordmul: Wordle for Multics - https://news.ycombinator.com/item?id=31636949 - June 2022 (3 comments)
Nobody learned the most important lesson from Multics vs. Unix - https://news.ycombinator.com/item?id=29783423 - Jan 2022 (1 comment)
Multics MR12.7 released - https://news.ycombinator.com/item?id=28006036 - July 2021 (25 comments)
Multics Public Access - https://news.ycombinator.com/item?id=27128765 - May 2021 (33 comments)
Ban.ai Public Access Multics - https://news.ycombinator.com/item?id=25611468 - Jan 2021 (6 comments)
Multics Simulator - https://news.ycombinator.com/item?id=22994027 - April 2020 (20 comments)
Multics: An Ancestor of Unix - https://news.ycombinator.com/item?id=21892923 - Dec 2019 (33 comments)
Multics Intro Course (1978) - https://news.ycombinator.com/item?id=18715014 - Dec 2018 (9 comments)
Thirty Years Later: Lessons from the Multics Security Evaluation (2002) [pdf] - https://news.ycombinator.com/item?id=16956386 - April 2018 (3 comments)
Public Access Multics - https://news.ycombinator.com/item?id=16875552 - April 2018 (3 comments)
48-Year-Old Multics operating system resurrected - https://news.ycombinator.com/item?id=14728441 - July 2017 (9 comments)
Multics Execution Environment (2014) - https://news.ycombinator.com/item?id=10364234 - Oct 2015 (1 comment)
Introduction to Multics - https://news.ycombinator.com/item?id=6985277 - Dec 2013 (1 comment)
There was at least one Multics server with users at RPI when I graduated in 1999. I wonder how long it persisted.
Can't find anything about RPI, but apparently the last known site was shut down in 2000: https://multicians.org/site-dndh.html
One unix, two multics. /jk
zero xenix :)
cuz (almost) no one uses it any more.
i did, a bit long ago.