The Evolution of Operating Systems (2000) [pdf] | Hacker News Reader

The Evolution of Operating Systems (2000) [pdf]

brinch-hansen.net

33 pointsvezzy-fnord9 comments

There's some great stuff here, and some favorite historical systems are represented (e.g., the B5000). Still, I can't help but see this as a hold-over from the mid-1990s -- the anti-Unix Dark Ages of Operating Systems.[1] For example, on Unix itself: "Still, after three decades, it can be argued that the widespread acceptance of Unix has become an obstacle to further progress." For evidence for this (absurd) assertion, the author cites a Stonebraker piece[2] that was already two decades old when this was written. And even by 2000, Stonebraker's assertions were either no longer true, or no longer relevant -- and the biggest database systems at the time were on Unix.

Fifteen years further down the track, the Unix assertion is (blessedly) comically wrong -- and many of the advances in operating systems since have been underneath the Unix abstractions and/or orthogonal to them. That is, we are (mostly) no longer developing grand new systems with entirely new programmatic models -- but we continue to make important progress on how the abstractions that we have agreed upon (i.e., Unix) are implemented and deployed. Further, I think that the philosophical contribution of Unix (that is, the Unix philosophy[3]) continue to be as important as ever -- and very clearly influential far beyond the bounds of the operating system per se. In short: I would love to see a modern update of this -- especially one that puts Unix in its proper historical context.

[1] https://news.ycombinator.com/item?id=10138765

[2] http://db.cs.berkeley.edu/cs286/papers/os-cacm1981.pdf

[3] https://en.wikipedia.org/wiki/Unix_philosophy

Pers Brinch Hansen is correct. I enjoy Unix, but it doubtlessly has led to a widespread creative drain among the hacker community. Occasionally there is something like DragonFly BSD, MINIX 3 and to a lesser extent Solaris/illumos which tries to do something more daring (a shame QNX is proprietary), but the Unix architecture entails subscribing to quite a lot of assumptions which imply a level of path dependence. You can see this in the way that OSes which tried to improve on Unix like Spring (which you ostensibly revile -- by the way, is there any way an amateur like me could possibly obtain a copy, or is it lost?), Amoeba and Sprite, failing to gain traction.

Needs citation: what is this "widespread creative drain among the hacker community" that Unix has somehow induced? (Also, what are the levels of "path dependence" that you're referring to?) To me, the advances in operating systems in the last fifteen years have been deeper than the programmatic abstractions -- ZFS, jails/zones/containers, DTrace, MDB, etc. Unix has inspired these advances, not confined them.

Finally, in terms of Spring: I think it's more accurate to describe you as romanticizing it than me as reviling it. As I have outlined for you before[1], I merely ran the beast -- and it was horrific, even when used as intended. It's certainly not lost: I have a copy in my basement, if no other copy exists, and I would gladly make it available to you if only to force you to see it as it was and not as you wish it to have been.

[1] https://news.ycombinator.com/item?id=10138958

Also, what are the levels of "path dependence" that you're referring to?

A process model which makes checkpointing and migration difficult, hierarchical file systems, lack of OS-level typed modules, strict kernel-userspace segmentation, the various flavors of user and group IDs for isolation and privilege segmentation, global namespaces (somewhat minimized these days, but nothing close to a Spring name service or even Plan 9 namespaces), the file interface and the pseudo-file travesty of "special files" (fuck ioctl(2)s), Berkeley sockets, units of execution/threads bound to address spaces/tasks (at least in userspace), no capabilities (modulo bolt-ons like Capsicum which are still experimental), lack of reliable kernel process management and child tracking primitives necessitating supervision schemes, general trend towards monolithic kernel subsystems rather than userland services, lack of reliable messaging IPC mechanism but instead proliferation of many primitive and homegrown solutions, lack of orthogonal persistence, frequent lack of proper metadata indexing/relational querying beyond seeking for byte streams, dynamic linking instead of dynamic binding, lack of network transparency, etc. etc.

ZFS, jails/zones/containers, DTrace, MDB, etc.

Nothing about those are innovative. You just have an obvious bias for Sun, given your origins. ZFS was an incremental evolution from VxFS and IBM systems. Same for containers, coming from IBM i and possibly earlier. DTrace isn't even necessary on systems with dynamic object introspection. mdb? Seriously? If you consider that one of the great advances in OS research over the past 15 years, may God help OS research.

I have a copy in my basement, if no other copy exists, and I would gladly make it available to you if only to force you to see it as it was and not as you wish it to have been.

I will gladly accept that challenge and write an article documenting my experiences. Please give me an email address to contact.

Nice overview of unix systems legacy. Would you be interesting in contributing your vision of a modern operating system to a common document? I've been wanting to start a casual WG for this purpose with someone for a while now.

The paper actually illustrates many advances in OS abstractions and techniques before and after UNIX that was superior to them. There's others outside this paper as well. Many, even on limited systems, smashed it in terms of IPC performance, fault-isolation (esp drivers), concurrency safety + throughput, shared memory support, management, and so on.

It was discovered far back that there were limits to how reliable or secure the UNIX API could get when improvements were attempted. Look up UCLA Secure UNIX, LOCK/ix, Trusted Xenix, Mach ports, L4Linux ports, and so on. Outside of isolating a whole OS (i.e. virtualization), they had to change the behavior of and/or eliminate many calls because they had too many negative effects on system state in fault or malicious conditions. This was not true of many alternative architectures that naturally decomposed systems, isolated faults, protected at interfaces, and/or implemented language-based protections. It's just a UNIX + C thing.

Let's re-illustrate this economically. MINIX 3 took a few people a few years to get it to a stage where it was quite reliable ("self-healing") as a console OS and easily modified due to architectural choices. How long did it take UNIX/Linux kernels to do that? No, really, because Sun's and Linux's kernels were still crashing on me in the late 1990's plus corrupting my filesystems on occasion. I'm wondering if it took two decades with hundreds of contributors or three decades? Either way, I think the effort vs results says something about their architecture and implementation strategy.

Similarly, Oberon was thrown together in a short time with few people while achieving more reliability, consistency, language-oriented protection, and concurrency performance (with AOS vs forking etc).

Many examples of systems doing it better with better results across the board. That also directly contradict UNIX model. It never won for superiority: just simple enough to run on the "cheap" hardware back then, open-source, and lots of users already.

Thanks for another great link, as usual, embodying the field's old wisdom. :) Some thoughts come to mind as I read it.

re Atlas. Didn't know it invented demand paging, supervisors, and VM's! Plus, given description of the paper's "prose," I might have to read it to see for myself. Cool system.

re Burroughs and HLL's. I sort-of disagree about it not being a HLL if you can do low-level stuff. The point of HLL's was to raise our abstraction and/or our level of implementation detail. Going from raw assembly to something w/ HLL syntax and better structure gives numerous improvements. I think it counts as HLL. Just a niche that focuses on higher-level respresentation of low-level operations. Macro assemblers were another example with Bedrock-style stuff (or x86 in Coq macros/tactics) being next level over that.

re Exec II. Modern PC's still don't do steady 90% utilization despite mainframe Channel I/O showing how & doable with cheap chips, too. So, Exec II still kicks ass as does mainframe I/O.

re MULTICS. I found that section totally unfair. They eventually built a usable, reliable system with microkernel and HLL. Got turned into first B2-class system after the pen test. Quite a system. Let's be sure to note failures and mistakes. However, anyone reading that section would've thought it had only one, good attribute and wonder if it was even built as a product. Wonder why he wrote it up that way.

re Titan. That it invented what's become the most influential access-control model for files (and now memory) is new to me. Good work for them.

re UNIX. I'm just going to remain silent on this except to say it was a great architecture and implementation for the PDP 11 and other minicomputers.

"A superior tool like Unix often feels so natural that there is no incentive for programmers to look for a better one."

(cough) UNIX Hater's Handbook (cough) Well, I tried to be silent.

re THE. Dijkstra shows applying engineering principles to OS's and software produces better results, sometimes nearly flawless. First methodology & exemplar done in 1968. Good to know IT industry kept that stuff in mind, leading to my near-flawless PC...

re RC4000. Credit to Hansen for nucleus approach: foundation of strong, security engineering to this day. Also news to me as I mistakenly thought it started with GEC's Nucleus kernel. So, goes back 1968 w/ first kernelized system running in 1969. And three months of reliability under the conditions of that time & with such radical changes seems impressive to me.

re Boss 2. Concurrent to the core, deadlock free, relatively low overhead, and error free in practice after first year. Great stuff. Replace the semaphores with BeOS's "benafores" and I bet the utilization would go up to levels near other systems.

re Solo. Security result is an amazing statement that we celebrated in late 90's and early 2000's prototypes as well. Being 20+ years ahead on that is another high five to Hansen. Give points to Wirth, too, for Pascal as an aid to this stuff. First to do access checks at compile time and also being able to publish source in one paper were also impressive.

re Alto. The 1-minute, filesystem fix is news. Now I know how much better the DOS's filesystems could've been. (sighs)

re BCPL. That, relaxed restrictions, and so on mark the decline of OS reliability and security at least from the paper's vantage. As I start to type this, I see him say essentially same thing noting that Solo, Pilot, Cedar, etc demonstrated practicality and advantages of using secure languages. Again, appreciate the paper for new examples it gives in addition to Lilith/Oberon, Ada, LISP, and Java examples I had from 80's onward.

re Star. Great rework of existing ideas. Inspired an alternative, desktop OS for Windows users not technical enough for Linux. ;)

re RPC's. Tried to make it faster by eliminating reliability guarantees. Spent several decades exploring all the ways that made it unreliable. Reinvented battles of 1950's. It was kind of stupid in foresight and totally retarded in hindsight.

re Amoeba. Gotta give Unix United, which I didn't know of, credit for getting this sort of thing going. However, Amoeba seems to be the first, true distributed OS with its own style. With capabilities, too! Also introduced us to Tannenbaum and Guido van Rossum: two names that would appear on reliable, solid systems in the future. ;)

"We do not stabilise on something nice and simple and say “let’s do it again, but do it very well this time.”"

Good conclusion. I'm doing my part in promoting design & implementation strategies that worked. I hope the actual builders do the same. Might also make an interesting student project (err Master's thesis) to prototype THE, RC 4000, Boss 2, or Solo again with small, modern changes.

re MULTICS. I found that section totally unfair. They eventually built a usable, reliable system with microkernel and HLL. Got turned into first B2-class system after the pen test.... However, anyone reading that section would've thought it had only one, good attribute and wonder if it was even built as a product. Wonder why he wrote it up that way.

Indeed, I assume ignorance. When he said "Multics was never widely used outside MIT." ... well, MIT-MULTICS certainly ran more of MIT than the Pentagon's system ran the DoD, but the military appreciated its security, among other things did their budget (or looking at the site linked below, maybe just the Air Force's).

Ford and GM had them, the latter with 17,000 registered users, Honeywell Bull (France) was really fond of it; the Multicians web site lists 84 sites, 30 with histories: http://www.multicians.org/sites.html.

I don't know if it would have succeeded in the long term if Honeywell had ran the project with more intelligence (blamed the decision to microcode the first pure Multics processor on their deciding to can that project because of algae in the cooling system), and without crippling infighting (they tried to slam together their original computer effort, GE's GECOS and Multics and minicomputer? systems, and the SDS/Xerox's), but even with those problems it sold so well on its own merits that Honeywell had to actively kill it off.

Interesting details. That they had to kill it off rather than accept its market-induced death tops off evidence it went somewhere. I think the $7 million price tag along with the politics did more than anything to hurt it.

Of course, seeing what he did with MULTICS, gotta wonder what other huge inaccuracies might be in there. Suddenly goes from a really nice paper to something review just in case.

EDIT: Just noticed the author I'm critiquing is the smart guy I complimented by name in my post for past work. Oh the ironies lol...

Reply on news.ycombinator.com