P.S. Just as a random aside, Amoeba has a UNIX emulator (running in user
space), but it is far from complete. If there are any people who would
like to work on that, please let me know. To run Amoeba you need a few 386s,
one of which needs 16M, and all of which need the WD Ethernet card.
Better -- meaning polished, thoroughly engineered, correct, etc. -- is often heavier in terms of hardware requirements. It's also often a lot of work by serious career devs or big companies and costs money and has a non-OSS license.
All that increases not only cost but more importantly friction. So the "worse" cheap/free unencumbered thing goes viral and takes over instead.
I should add the caveat though -- it's cheap/free up front but you pay later in bugs and ugly hacks to make it work at larger scale. But up front friction matters more than friction later. If it's cheap/free in terms of cost or friction now, you'll already have sunk cost by the time the real cost becomes apparent.
Another example is how C++ and Java, but not Smalltalk, became the dominant object-oriented programming languages in the 1990s, despite Smalltalk being older and (debatably) being closer to Richard Gabriel's "right thing". There were affordable C++ implementations from Borland and Microsoft, and Sun released the Java Development Kit for free. However, the leading Smalltalk implementations of the 1990s were much more expensive. Perhaps had there been a Borland Turbo Smalltalk or a Microsoft Visual Smalltalk in the 1990s, maybe things would have turned out differently.
Or about 2 months revenue of newspaper route.
Linux 0.98 shortly afterward and Donald Becker's Ethernet driver.
There was also Mosix, OpenMosix, Beowulf, etc. All those are worth a look. It's a path that was not taken, and IMHO could have been better, but "worse is better" won once again.
Had we taken this path, you might be able to create a distributed instance of an OS and just throw hardware at it -- boxes or VMs -- and tasks would run on it like a single OS with little or no modification. It'd be like having an infinite giant box.
Of course as soon as you started trying to do anything like geo-distributed or even multi-DC/multi-AZ work loads you'd be back to orchestration and the like. You'd also run into problems if you want to rev the hardware in any big way, since these systems generally depended on all the boxes being at least nearly the same. So if you threw in, say, some new boxes with AVX512 ISNs, you would not be able to use AVX512 until you'd rotated out all boxes without it. Bigger architectural shifts would require what amounts to a "reboot" of the big virtual OS instance. Mixing boxes with different performance characteristics or RAM amounts was also problematic. Making that work well would be hard to get right.
Under the hood these distributed OSes were orchestrators like K8S, just hidden from you for the most part behind a Posix emulation layer that made it look like one box.
Ultimately I think the type of architecture you see with "serverless" where everything is a "function" with no side effects that can talk to one or more shared global databases is the better architecture. Do away with the entire concept of a "box" in favor of a sea of functions that call each other, event queues, schedulers, etc. We do kind of have that, but only in the form of proprietary serverless platforms.
The amount of complexity we inflict on ourselves by dragging along the concept of unmanaged / unbounded global state, static state, and side effects is mind boggling. A function should only operate on what you give it.
I guess academia was too far from what industry needed. They where thinking about the future, and we needed more stable boxes and sometimes a cluster for critical loads.
All the microkernel stuff Tanenbaum defended makes a lot of sense if you have a distributed OS: you just need to talk with your "local" service with the API you have at hand... and it is the same everywhere (for instance, your SOAP server - which is the equivalent of etcd in K8s).
haunter•5h ago
Seems to be the source code was archived, I wonder if it's bootable in a VM. Well I know what'll do this weekend!
https://web.archive.org/web/20000901081815/http://www.cs.vu....
Edit: even better, found a mirror on Github (original file dates are not preserved though)
https://github.com/OSPreservProject/amoeba
mysterydip•4h ago
"Note that the RTFM system applies to these reports/questions (see the FAQ)."