|
|
|
|
|
|
by bcg1
3659 days ago
|
|
|
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... |
|
|
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.