- [name] is a kernel thread not a user space process.
- its libssl, not "libopenss"
- installing rpc, some obscure 55k listening port, and calling it bloated.. heh so cheap.
Once past all this FUD - what does a unikernel (basically the same as running linux and your app as /sbin/init except it's in Erlang and not C here)?
- its obscure. you get security mainly because nobody knows what you're running.
- its library based. like regular OSes.
- it runs only one program. or a million of them, like a regular OS, but with zero separation between them so compromise one means compromise all, actually. Else you have to add the separation layer yourself by writing more apps per "system" and make them communicate.
- its undebuggable without a lot of knowledge
- 'script kiddies' will run ./erlang-hack-for-x instead of ./rootshell.sh, this changes nothing to that. Remember the XEN exploit a few month ago? That'd still work and give access to all the Erlang instances. Its not that hard.
- its not faster, its actually slower, when compared to C kernel+code.
- it doesnt compile itself, you need a "regular OS" to deploy it
- it uses the same memory space for mostly everything (regular OSes use protected memory per process, its hardware enforced by the CPU)
- namespaced linux boots in There are much better implementations of safer, faster, cleaner OSes with better paradigms that also do away with backward compat and using modern, memory safe languages (http://en.wikipedia.org/wiki/Singularity_%28operating_system... for a well-known one). For the record MS also developed Drawbridge (process+lib, so not exactly a unikernel) because they could not do away with windows compatibility. So yeah.
If you have doubts, look at the example code at https://github.com/technolo-g/unikernel-demo