4 ms·

I've always wondered. Bell Labs' Inferno, Sun's JavaOS, and Microsoft's Singularity were built on the same principles of OS being almost entirely built on top

I've always wondered. Bell Labs' Inferno, Sun's JavaOS, and Microsoft's Singularity were built on the same principles of OS being almost entirely built on top of a virtual machine, and it's a very interesting idea from many points of view. But all of them seem to have failed to gain enough traction to enter the mainstream. 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?

e3bc54b2 4y ago
> Was there any reason for that? 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.
- Turing_Machine 4y ago
  Yep. *n*x is a victim of its own success. Thompson, Ritchie, Kernighan, et al built something so much better than most of the competition that it ate the world. 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 https://dreamsongs.com/WorseIsBetter.html (original essay and several followups at this link)
  - pjmlp 4y ago
    WSL is running on its own VM. Windows kernel still owns the game. 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.
    - anderspitman 4y ago
      > Any language that doesn't depend on POSIX and has a rich library ecosystem, can happily run on top of type 1 hypervisors 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.
      - pjmlp 4y ago
        Not on ESXI, but as unikernels, sure, https://github.com/solo-io/unik https://github.com/solo-io/unik https://hermitcore.org/ https://hermitcore.org/ https://github.com/icexin/eggos https://github.com/icexin/eggos https://nanovms.com/ https://nanovms.com/ "Pure Go Unikernels - go metal with TamaGo" https://www.youtube.com/watch?v=aOEl5BCfHv0 https://www.youtube.com/watch?v=aOEl5BCfHv0
        anderspitman 4y ago
        Awesome, thanks. Do you have a take on unikernels in general? 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.
        eyberg 4y ago
        I work with NanoVMs and nanos.org can work under both qemu (by default) and deploy to hyper-v under WSL2. Also, nanos.org itself is a go unikernel so we have excellent go support. Also, from parent comment, ops, can deploy to esxi/vsphere perfectly fine.
  - ksec 4y ago
    >Perhaps we'll eventually see an innovative OS written in WASM I hope that doesn't happen. No body wants a Nuclear War and 40 million refugees off the coast of Australia.
    - thesuperbigfrog 4y ago
      >> 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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  - ahartmetz 4y ago
    I wouldn't say that Plan 9 has better (basic) ideas than Unix, it's more like a Unix that follows the old ideas even for new things. AFAIU many of the ugly aspects of "contemporary Unix" stem from the Unix wars and later additions by people with less design sense than the Bell Labs group.
- origin_path 4y ago
  Well, most of the world uses Windows (not a UNIX), macOS/iOS (owes more to NextSTEP than UNIX) and Android (owes more to BeOS than UNIX). The latter two use a UNIX kernel to get basics like scheduling and a filesystem but the userland APIs look nothing like UNIX or Linux, and both have a strong micro-kernelish vibe to them with Mach and the Binder respectively.
pjmlp 4y ago
The mainstream version of those ideas are Android, ChromeOS and servless computing on cloud environments. 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.
origin_path 4y ago
At least for JavaOS and Singularity there were a bunch of problems: 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.

e3bc54b2 4y ago

> Was there any reason for that? 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.

Turing_Machine 4y ago
Yep. *n*x is a victim of its own success. Thompson, Ritchie, Kernighan, et al built something so much better than most of the competition that it ate the world. 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 https://dreamsongs.com/WorseIsBetter.html (original essay and several followups at this link)
- pjmlp 4y ago
  WSL is running on its own VM. Windows kernel still owns the game. 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.
  - anderspitman 4y ago
    > Any language that doesn't depend on POSIX and has a rich library ecosystem, can happily run on top of type 1 hypervisors 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.
    - pjmlp 4y ago
      Not on ESXI, but as unikernels, sure, https://github.com/solo-io/unik https://github.com/solo-io/unik https://hermitcore.org/ https://hermitcore.org/ https://github.com/icexin/eggos https://github.com/icexin/eggos https://nanovms.com/ https://nanovms.com/ "Pure Go Unikernels - go metal with TamaGo" https://www.youtube.com/watch?v=aOEl5BCfHv0 https://www.youtube.com/watch?v=aOEl5BCfHv0
      - anderspitman 4y ago
        Awesome, thanks. Do you have a take on unikernels in general? 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.
        eyberg 4y ago
        I work with NanoVMs and nanos.org can work under both qemu (by default) and deploy to hyper-v under WSL2. Also, nanos.org itself is a go unikernel so we have excellent go support. Also, from parent comment, ops, can deploy to esxi/vsphere perfectly fine.
- ksec 4y ago
  >Perhaps we'll eventually see an innovative OS written in WASM I hope that doesn't happen. No body wants a Nuclear War and 40 million refugees off the coast of Australia.
  - thesuperbigfrog 4y ago
    >> 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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- ahartmetz 4y ago
  I wouldn't say that Plan 9 has better (basic) ideas than Unix, it's more like a Unix that follows the old ideas even for new things. AFAIU many of the ugly aspects of "contemporary Unix" stem from the Unix wars and later additions by people with less design sense than the Bell Labs group.
origin_path 4y ago
Well, most of the world uses Windows (not a UNIX), macOS/iOS (owes more to NextSTEP than UNIX) and Android (owes more to BeOS than UNIX). The latter two use a UNIX kernel to get basics like scheduling and a filesystem but the userland APIs look nothing like UNIX or Linux, and both have a strong micro-kernelish vibe to them with Mach and the Binder respectively.

pjmlp 4y ago

The mainstream version of those ideas are Android, ChromeOS and servless computing on cloud environments. 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.

origin_path 4y ago

At least for JavaOS and Singularity there were a bunch of problems: 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.