At first it seemed strange that a Node.js-replacement needs a full IP stack including DHCP.
As far as I understood this, they are building a whole operating system to be run in a VM like QEMU which then acts like a Node.js-instance - except that it's programmed in C++ and linked as one whole exeutable which also is a complete OS.
I wonder how this compares to Docker or Sandstorm where the existing kernel API is used in a virtualized container instead of emulating a whole machine.
> I wonder how this compares to Docker or Sandstorm where the existing kernel API is used in a virtualized container instead of emulating a whole machine.
Short answer is probably: Better at security, but less efficient.
Xen bugs notwithstanding, the VM boundary has a better security record than the kernel API boundary. (Though Sandstorm -- my project -- has been pretty successful at dodging kernel bugs through aggressive attack surface reduction.)
The problem with VMs is that they're heavy-weight. The hardware interfaces were never intended to be a clean abstraction boundary between software. For example, it's tricky to reclaim unused RAM back from a VM, because within the VM the guest would by default assume it has a fixed amount of RAM that is exclusive to it. Communication probably has to happen in the form of network packets, requiring setting up and traversing a whole IP network stack in the guest, which is a lot more expensive (in both CPU time and memory use) than pipes, unix sockets, or shared memory would be.
However, if you're designing a kernel specifically for use in a VM, you can probably do better on these things, e.g. you can define some virtual hardware interface by which the kernel marks RAM pages unused so that the host can take them back, or you can define a cleaner communication interface. But as you define these interfaces, your "virtual hardware API" ends up looking more and more like a kernel API -- and has greater risk of security bugs.
So one way (containers) you start out with a wide interface and high efficiency but a large attack surface, and you try to narrow the interface to improve security. The other way (VMs) you start with a narrow but inefficient interface which you try to widen to improve performance.
What they want to do is to implement the concept of a unikernel (https://en.wikipedia.org/wiki/Unikernel). That's a very different approach then running a complete OS with their software stack on top. Take a look at the two links in my other comment.
As far as I understood this, they are building a whole operating system to be run in a VM like QEMU which then acts like a Node.js-instance - except that it's programmed in C++ and linked as one whole exeutable which also is a complete OS.
I wonder how this compares to Docker or Sandstorm where the existing kernel API is used in a virtualized container instead of emulating a whole machine.