
The Evolution of Operating Systems (2000) [pdf] - vezzy-fnord
http://brinch-hansen.net/papers/2001b.pdf
======
bcantrill
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](https://news.ycombinator.com/item?id=10138765)

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

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

~~~
vezzy-fnord
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.

~~~
bcantrill
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](https://news.ycombinator.com/item?id=10138958)

~~~
vezzy-fnord
_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.

~~~
paxcoder
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.

------
nickpsecurity
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.

~~~
hga
_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](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.

~~~
nickpsecurity
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...

