Hacker News Reader

Comment by talex5 | Hacker News Reader

It depends on which lightweight OS and which unikernel. But e.g. a stripped down Linux will still have a huge amount of C. If you're going to write your kernel in something safer, then you might as well make a unikernel, rather than creating a kernel/userspace split.

It's hard to see how you'd get a traditional OS stripped down anywhere close to e.g. the mirage-firewall unikernel (http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewal...)

View on HN

Not necessarily.

NodeOS cut out everything but the absolutely essential parts of the linux kernel. No c libraries, no c compiler, no POSIX utilities, no user space, etc.

Instead, everything runs on V8 (ie which also takes care of sandboxing) and minimal tools were rewritten in pure javascript, incl a git clone tool.

It's amazing how much you can cut out and still have a decent platform to build servers.

You're still running the linux scheduler in C, and you're still context switching for system calls. And can you run your whole stack as a user-mode program by changing one line in the build file the way you can with Mirage?

This is a red herring. Presumably you'll be running unikernels in multi-tenant environments. There will still be scheduling and context switching overhead from the hypervisor. The Hypervisor isn't going to allow a VM full access to the hardware. Also, if you're the only process running, the Linux scheduler shouldn't actually have any overhead.

NodeOS, like most projects, is likely just a duct-taped jenga tower of the usual suspects. The attack surface will be huge. For example, OpenSSL will be in there with all of its gotos and malloc-reinventions. From a security point of view, I don't see a contest. The Mirage guys even clean-room implemented SSL in OCaml. This is no ordinary OSS project.

What's next PythonOS, RubyOS? Just learn OCaml, its really not that hard.

In itself, beside being a ridiculous amount of work, it would be a good thing.

If all apps ran on its own hypervised runtime instead of a "native" runtime, the world you be a better place.

The overhead of starting a VM is actually in the 2 digit milliseconds and can be done while the initial I/O are performed.

The XDG-App project is trying to make it easier to sandbox Linux desktop and server applications by defining all the interfaces between the sandboxes and the OS. This work, while initially designed for containers, will eventually work on VM too.

Reply on news.ycombinator.com