

The Ethos Operating System - fractalcat
http://www.ethos-os.org/

======
ZenoArrow
I'm confused. Two things.

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.

[http://wiki.xenproject.org/wiki/Unikernels](http://wiki.xenproject.org/wiki/Unikernels)

~~~
avsm
Unikernels are a little different from Ethos. What unikernels need is a
library interface to any underlying operating system, as opposed to a
conventional syscall style interface that dynamically calls into a different
privilege level. This lets the developer supply an appropriate set of "OS
libraries" that fill in the functionality needed by the application, and no
more, and for this to be resolved at application build time instead of
execution time.

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.

~~~
ZenoArrow
> "This implies that unikernels still need to have an underlying OS to drive
> their logic."

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.

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

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](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.

~~~
ZenoArrow
> "David Sheets did some work on rebuilding portions of the protocol in
> MirageOS: [https://github.com/dsheets/ocaml-
> dnscurve](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.

------
zokier
This would be so much more interesting if it was actually available for
download. It's sad that djb's minimallt seems to be stuck with ethos non-
release. I remember them promising open source release 'soon' back in 2013
when it was initially published, but there doesn't seem to have been any
progress in that direction.

Has anyone poked the authors recently to hear what's going on?

------
TimFogarty
> Most of our programming is done in C (kernel) or Go (user space). [1]

It's cool that Go is being used in a project like this. For some reason I
found that a bit surprising.

[1] [http://www.ethos-os.org/background.html](http://www.ethos-
os.org/background.html)

~~~
klibertp
Why? Go seems like a reasonable choice here: it's much, much safer by default
than C and much, much simpler than C++. I mean memory safety, mostly. To me it
seems that Go is actually much better suited for things like these than for
webapps that some people use it to write.

~~~
pjmlp
Not only that, it follows the Inferno model, just that Go has a native
compiler instead of a VM like Limbo has.

Now if someone would bother to write a bare metal runtime, Go could follow
Oberon's footsteps.

