The Ethos Operating System(ethos-os.org) |
The Ethos Operating System(ethos-os.org) |
1. My initial impressions is that the idea is to build an OS that breaks from the past, but then later there is a promise to port to POSIX. Doesn't that restrict some of the design decisions that could be made when starting with a clean slate?
2. What does this offer over unikernel-based operating systems such as MirageOS, HalVM, LING, OSv, etc...? Basically seems like they already do what Ethos plans to do.
This implies that unikernels still need to have an underlying OS to drive their logic. The specific choice is wonderfully flexible though: right now we have numerous Xen-based unikernels, and via the Rump Kernel project MirageOS now also boots on KVM and bare metal targets as well.
Ethos has an interesting capability and crypto model that unikernels could map their distributed communication primitives too as well. In this world, the name resolution libraries used by unikernels could use CurveCP (or whatever equivalent version Ethos provides), and provide a multi-tenant, fine-grained capability-based, runtime for dust clouds of unikernels.
From the Ethos homepage...
> "The solution to both of these problems is Virtual Machines (VMs). Since VMs allow multiple OS to run on a computer, it is no longer necessary to choose one OS; multiple OSs can be used simultaneously. Hence, one significant application can justify running an OS. Second, the VM provides an abstract hardware architecture which is far simpler then the vast variety of computers extant. The drivers for the real hardware are provided by the VM. We are using Xen as our VM because we believe it is a good security architecture on which to build an OS."
So the plan is to run on baremetal hypervisors like Xen, just like MirageOS and the rest.
> "Ethos has an interesting capability and crypto model that unikernels could map their distributed communication primitives too as well."
If that's the main aim, then I don't see why they don't build their capability/crypto model into one of the unikernel OSes, specifically one of those that has the strong type safety and process isolation they are also aiming for. I don't see what they gain from having a custom OS requirement when a lot of the groundwork has already been done for them.
Has anyone poked the authors recently to hear what's going on?
It's cool that Go is being used in a project like this. For some reason I found that a bit surprising.
Now if someone would bother to write a bare metal runtime, Go could follow Oberon's footsteps.
They seem to be doing just fine with their current efforts, from which really interesting things like the MinimalT protocol has emerged. If I have one frustration, it's that they haven't released a reference implementation of it. I had a f2f conversation with DJB at Real World Crypto a few months ago and the explanation was completely reasonable: they are still working on cleaning it up and making it suitable for external consumption. I still want it today though :-)
David Sheets did some work on rebuilding portions of the protocol in MirageOS: https://github.com/dsheets/ocaml-dnscurve . This level of interproject coupling is just fine by me -- the whole point of library OSs is that we can pick'n'mix these things much more easily over the years, and that's working out fine.
Yes, collaborating in that way seems like a good approach.