This feels like IBM/RedHat are playing the "me too" game with Kata or Firecracker. Or maybe, at a higher level, IBM needs something in this space to compete with what AWS has in their Nitro architecture. But, as you say, I'm not sure that "unikernel" means anything specifically at this point other than to, maybe, generate buzz. I don't understand these fluff pieces that sound interesting but are currently vaporware.

Red Hat works by following open source trends. With Kata we have been following it upstream very closely since the Clear Containers days, as well as having people being involved with the project, and now we're productizing it.

You should talk to the Nabla containers and related work team https://nabla-containers.github.io/people/ in IBM Research, that is where I believe most of the context of this article comes from.

They also have a slack team for nabla http://slack.nabla-containers.com/

So if I understand correctly, you end up with some sort of binary, that you can run on top of some system that abstracts away the hardware and manages resources, correct?

You end up with a self-contained application binary which runs anywhere that you could run a Linux kernel.

However it's different from embedding an initrd into a kernel image in several ways: The kernel is minimal, containing only the bits which are needed by your application or drivers required to run on the hardware. The application runs in kernel space and is linked with the kernel which gives you a nice performance boost because you never context switch (which is the driver behind the whole project actually). You can also call kernel functions which aren't syscalls, eg. for specialized memory management.

What's so wrong with the context switch? You need to have some anyway if you want threads in your unikernel.

This is a common misunderstanding. There are many different types of context switching and you need the context (heh!) To compare apples to apples.

Kernel to userland, thread to thread, process to process, kernel thread vs user thread, etc. It's conflated because different threading models and different kernel/userland separations exist.

Generally speaking (in linux) threads perform much much faster than switching processes.

This is right, and the other mistake people make is measuring just the context switch, and not the many hundreds of thousands of cycles after the context switch spent repopulating the cache.

64-bit DOS?

but with permissions you can conveniently ovveride by default!

It doesn't even make sense to think about permissions for unikernels. There is exactly one application running. The trust boundary is at the edge of this application/kernel/VM thing, not anywhere within it.

> You link your application directly to Linux and get a vmlinuz binary which can be run in a variety of places including on cloud VMs, in qemu, in a Kata Container [in theory - not actually tried this one], or even on baremetal.

sounds like the promise java made when they started. but java abstracted away the OS but not the hardware resources. right here the hardware is but not the OS.

very curious to see how this turns out.

Is what you're doing anything like MirageOS (NetBSD rump kernel linked with an OCaml application [Note, this was an error, see below])? It sounds really interesting – I wonder what advantages Linux vs *BSD have as unikernels, when most hardware details are out of the picture.

MirageOS does not link to the NetBSD rump kernel. It is a standalone unikernel.

Thanks for the correction :)

> You link your application directly to Linux and get a vmlinuz binary

How does this work with proprietary applications and the kernel's GPL license?

I assume all these Unikernels Are targeting the Cloud and Server Usage? Which is perfectly fine for GPL.

"Consult a lawyer" would be the best answer I could give here. The applications we're actually targeting are open source servers of various kinds (think memcached, apache, etc.) so it's not an issue we need to consider ourselves as the licenses will be compatible.

No one really knows if the Linux "userspace is not covered by GPL" applies if you link an application to the kernel. Or if you then apply link time optimisation.

In the cloud no one can hear you violate the GPL.

This is why AGPL exists. I think it is agreed that deploying your app to the cloud is not distribution and doesn’t run foul of plain GPL.

In the cloud you usually don't distribute binaries, so you don't have to distribute sources either.

so that's basically like putting the whole app in a initrd? One could have done that for some time...

No, it's nothing like that. See my other reply: https://news.ycombinator.com/item?id=21920909