[kev009]

I can't help but think this is just a severe reaction to the tire fire that most Linux distros are, especially RedHat/CentOS and Ubuntu. BSD or Alpine Linux get in the way a lot less, are much more customization and compact, and have a smaller attack surface while still catering to production operations where you can run shells, profiling, logging, etc inside the execution environment.

[bcg1]

There's more to unikernels than just being another virtualization technology. Most of the conversation on HN (as well as the content of this article) seems centered around unikernels vs. containers vs. a traditional OS in a VM, etc. But that conversation sort of misses the point.

Rather than just being a competing virtualization solution, "Unikernels" are really about eschewing the existing OS paradigm altogether. For example, the Mirage folks seem to have asked themselves about how they could create a "safe" OS and landed on the solution that they could achieve that by trusting the OCaml compiler and runtime for "safety" and so wrote a brand new OS from scratch in OCaml. That is a very different thing than a reaction to the "tire fire" that you are describing!

Similarly, for rump kernels Antti Kantee (with the help of others I presume) took several years to re-architect the NetBSD kernel to minimize the inter-dependency of different components of the kernel through the creation of a "hypercall" interface[0] and a carefully thought out separation of concerns.[1] One of the end results of this architecture is that you can run NetBSD drivers outside of the NetBSD kernel "just" by implementing the rumpkernel hypercall interface. Want to write your own OS (in a "safe" language language like OCaml for instance) but don't want to write a tcp stack or a filesystem implementation or USB driver from scratch? Rumpkernels could be an solution to that problem. Again, that is a very different problem space than the "tire fire".

[0]: http://netbsd.gw.com/cgi-bin/man-cgi?rumpuser++NetBSD-curren... [1]: http://lib.tkk.fi/Diss/2012/isbn9789526049175/isbn9789526049...

[pjmlp]

The Mirage folks didn't discover anything new in that regard.

It is how the safe OS from Burroughs, DEC, Xerox Parc, ETHZ and many others used to work.

Those OSes were written in strong typed systems programming languages, the whole stack.

Part of their security was based on the language type system.

[bcg1]

Fair enough! I definitely wasn't trying to suggest that is a completely new feature, nor that it is the only feature of Mirage OS ... really was just trying to make the point that there is more to the unikernel story than just figuring out whether it is better or worse for running my buggy crud application than some other virtualization technique. Thank you for the info though, I will have to read up on those things you mentioned.

[pjmlp]

You can find some links to those systems here

https://news.ycombinator.com/item?id=11856479

[viraptor]

I'd rather say it's a response to technical advancements in virtualisation. You want an app that can talk to other things, but is otherwise completely isolated as far as crashes and exploitation goes. We wanted that before protected memory was a thing. We wanted that when networks happened. We wanted that when selinux was created. etc. etc.

This is just the next step. I've got an app which needs communication channels and possibly persistent storage - isolate everything else. This is what unikernels provide. If it gets rid of some of the redundant system parts is just a cherry on top.

[XorNot]

The problem is you reinvent kernels when doing this before too long. Containerization is a reaction to virtualization being too expensive - and unikernels are still pulling in huge amounts of redundant code and runtime compared to containers where the kernel af least is shared.

[viraptor]

I'm not sure that's a bad thing. If you're running only one app, there's a lot of things you don't need. No process groups, no scheduling hierarchies, no user privilege checks, likely no filesystem caching (maybe even no filesystem?), no legacy device handling, no terminals. We're kind of going towards replacing the big kernel with a posix-to-virtio layer already, and it may not be a terrible idea.

[eru]

Same arguments as those in favour of exokernels in the 90s.