Until those are dealt with wasm will never move past it's current status quo - malware in the browser.

We have only run C applications so far, so I'm unsure how it will all work for servers written in other programming languages. I think applications which rely on complex multi-process middleware (like Java JBoss, etc) will be hard or even impossible to port.

Hm, isn’t reboot just slightly more complicated than restarting your application? And most of the today’s apps would still require “rebooting” be it a container or a virtual machine

Not saying it is easy but at the end of the day it's just engineering work.

This can lead to some rather spectacular performance benefits. One thing is that you remove the syscall overhead, but more importantly you can do a lot more optimizations at the compiler/linking steps.

You can remove complex code that tries to dynamically model the world with rather plain code that does just what it is supposed to. With IncludeOS (C++17 unikernel) we did make a firewall implementation that instead of using complex data structures relied on preprocessing the rule set and translate it into C++ code. The code to do this was quite simple and resulted in pretty amazing figures wrt number of rules per packet per second. Metaprogramming can sometimes deliver amazing results.

Similar things can be done in a traditional kernel as well and we've seen eBPF firewall implementations that are able to get similar numbers. On the flip side eBPF and it's firewall implementation is order of magnitude more complex. However, you can push eBPF code onto the networking card which can be a huge benefit. And ofc you could make a kernel module that implements a specific firewall ruleset and get similar performance without eBPF.

I like unikernels because I feel I can understand them better. You can reason about them and they are easier to optimize for very specific workloads.

So why aren't we using them? Likely because we know Linux so well and we've invested a lot in it. It runs everywhere and is extremely well supported. Bringing a new operating system to market is challenging, bringing a new operating system with a entirely different architecture is even harder. Even if it, on a purely technical level, could yield better results.

From Wikipedia:

“A unikernel is a specialised, single address space machine image constructed by using library operating systems. A developer selects, from a modular stack, the minimal set of libraries which correspond to the OS constructs required for their application to run. These libraries are then compiled with the application and configuration code to build sealed, fixed-purpose images (unikernels) which run directly on a hypervisor or hardware without an intervening OS such as Linux or Windows.”

Whether it's good depends on what you're doing. UKL will[1] allow you to link a regular server application to Linux and then run that single binary on baremetal or in a hypervisor, and give you a decent performance boost over running the application on top of a normal kernel. How much of a performance boost depends a great deal on the program, almost everything will be a few percent faster, and some applications a lot more.

[1] I'm using the future tense here because although we do run real programs with it today there's still a bunch of development work to do before it works smoothly. The code is: https://github.com/unikernelLinux

Instead of installing an OS and installing your app on that OS, the OS is a library you use to talk to the hardware.

It's good for two reasons.

First security, if you only use the HDD and network, you don't have to include code for display or mouse etc. which could be a security risk.

Second, it's faster, because you don't have to do syscalls, since your app IS the OS, syscalls don't need to get out of userspace.

https://nanovms.com/dev/tutorials/assessing-unikernel-securi...

Edit: Thanks for the updated link. UKL can be compiled with usual hardening features like ASLR, stack hardening, RELRO.

As I said here (https://news.ycombinator.com/item?id=23202042) I'm dubious about the security story around unikernels, but most of the issues in this paper are not relevant to UKL specifically.

Actually achieving this is tricky: At the moment you need to use special compiler flags and a completely different link line from normal. Then there's the issue of how/whether the library Linux is configured generically or you somehow allow people to set CONFIG_* options.

Performance benefits: In truth we're still measuring this, there is a very smart student at BU who is investigating this and coming up with results for a forthcoming paper which I don't want to preempt too much. Almost all applications should see a small benefit, say of the order of 5%, but it's hoped that some will see a much larger benefit, and that it should be possible to make modest modifications in order to enjoy large benefits (perhaps only compiler and linker flags and such like).

These are very much hopes rather than firm promises at the moment.

getpid exists and returns a number - in fact it can return any number you like :-) Everything is linked into a single vmlinux which runs in a single address space. (As an aside I'll have to remember to ask Ali if he's thought about what number getpid() should return in UKL - I guess returning 1 would cause least surprise)

> Can I fork or create threads?

Fork no, threads yes. Threads are implemented using kernel threads.

> Can I directly access kernel's internal APIs like a kernel module?

Yes, although whether this is a good idea is another matter. Note that it's still Linux so internal APIs are unstable and can go away or change their meaning at any time, so if your application starts to rely on internal APIs you could quickly get into trouble.

There are no processes here. Everything runs inside the kernel. You don't have exec(), fork() or similar.