Inferno and Limbo, which tend to be ignored with too much focus on Plan 9, a middle stop in their whole experience designing OSes and programming languages after being done with UNIX and C.
Was there any reason for that? Were the CPUs not powerful enough, or were the compilers not quite there yet? Or did it have more to do with the business side of things?
Perfect is the enemy of good, and good enough is the perfect enemy of better.
Unix/Linux were/are good enough for vast majority of world's needs. So anything better is not worth the hassle.
There have been better ideas since then (including Plan 9) but nothing able to knock *n*x off its perch.
IMO, LMI and Symbolics might have done it, if their offering hadn't required enormously expensive machines (by the standards of the time), while *n*x would run on cheap hardware (again, by the standards of the time).
Perhaps we'll eventually see an innovative OS written in WASM. That's about the only way I see to get around the vendor lock-in (I mean, even Microsoft appears to be converging on a "Windows UI wrapped around a *n*x kernel" model... Apple, of course, has been using a "Mac UI wrapped around a *n*x kernel" for a couple of decades now).
For anyone who hasn't read it, I recommend Richard Gabriel's "Worse is Better" essay: https://dreamsongs.com/WorseIsBetter.html
(original essay and several followups at this link)
On "Cloud OS" the underlying kernel only matters for classical workloads being pushed onto the cloud.
Any language that doesn't depend on POSIX and has a rich library ecosystem, can happily run on top of type 1 hypervisors, which are in a way, the revenge of microkernels.
That's interesting. Can you run for example Golang programs on ESXI? Go isn't exactly POSIX-free but it also doesn't need all of it.
https://github.com/solo-io/unik
https://github.com/icexin/eggos
"Pure Go Unikernels - go metal with TamaGo"
My main side project at the moment involves trying to use QEMU+WHPX on Windows to sandbox selfhosted services. Long term I think it would be awesome to support unikernels, but I get the feeling a lot of the momentum for them has died down the last couple years.
Also, from parent comment, ops, can deploy to esxi/vsphere perfectly fine.
I hope that doesn't happen. No body wants a Nuclear War and 40 million refugees off the coast of Australia.
For thise wondering about this reference:
https://www.destroyallsoftware.com/talks/the-birth-and-death...
Also note that these ideas are quite old, IBM and Unisys mainframes and micro-computers are quite different from their original versions, yet most applications keep running thanks to their language environments instead of shipping pure native code.
1. They were primarily research OS', Singularity was never even meant to be used at all. Its successor Midori was, but again it never made it outside of MS. JavaOS was sort of targeted at embedded devices but again never had any real usage.
2. Operating systems are ideally very tightly programmed with minimal overhead. Given a choice between elegance and performance, people pick the latter. A slow app can be optimized but if your kernel/drivers are slow then you're often stuck. Whether it's microkernels or operating systems written in managed languages, these better designs sell performance to buy convenience for the implementors, but convenience for users is more important.
3. Midori tried to fix this but ended up spending all its design budget on trying to turn C# into C++ and do fashionable things with concurrency/thread safety, which isn't a compelling basis for an OS. Plan9 at least had features that were interesting for the actual users of the computer, but the Singularity/Midori approach was mostly just a PL nerdout.
Single address space operating systems have some design issues that have never been well addressed, or at least the solutions didn't seem convincing. Unfortunately OS research is stagnant so very little has changed over time.
For example, they need everything to be written in a single (GCd/managed) language, and so existing C/C++ libraries can't be used (without a win3.1 style stability model at least). But the VM itself is written in C/C++, so the first step is to either switch the entire model to AOT compilation (the MS approach) or to write the language VM in the language itself (the Sun approach, which eventually surfaced in real products in the form of GraalVM). The Graal approach seems to solve this problem by being able to run any kind of language on top fot the JVM, even C/C++ code, and it can run it safely/GCd.
Another problem is the question of what exactly replaces a process. Processes in classical operating systems do a lot of different things - sandboxing, data isolation, scheduling, but also things like defining a failure domain. The big advantage of a single address space OS is you can allocate objects and then just pass them around freely without needing all the IPC/serialization/socket bindings/etc stuff that classical kernels require. So the obvious approach is to just not have such a thing as a process - but if you do that, you hit the question of how to manage executing code. What's the equivalent of SIGKILL if you don't have a process? What does a CPU usage graph look like? What happens if a driver does a callback into a piece of code which then deadlocks? This problem combined with the difficulty of finding a one-size-fits-all garbage collection algorithm pushes SAS operating systems towards reintroducing a process-like concept, for instance the Singularity process equivalent was actually way more constraining than a UNIX process, and objects could no longer be passed around freely between subsystems but instead required a convoluted exchange heap + quasi-RPC approach.
Java and Inferno were designed to fix the abysmal portability problems other operating system vendors created.
"Alef appeared in the first and second editions of Plan 9, but was abandoned during development of the third edition.[1][2] Rob Pike later explained Alef's demise by pointing to its lack of automatic memory management, despite Pike's and other people's urging Winterbottom to add garbage collection to the language;[3] also, in a February 2000 slideshow, Pike noted: "…although Alef was a fruitful language, it proved too difficult to maintain a variant language across multiple architectures, so we took what we learned from it and built the thread library for C."[4]
Alef was superseded by two programming environments. The Limbo programming language can be considered a direct successor of Alef"