I think that part of it is that relatively few people use bare-metal servers these days, and nested virtualisation isn't universally supported. I also found this technical critique [0] compelling, but I have no idea if any of it is accurate or not.

[0]: https://www.tritondatacenter.com/blog/unikernels-are-unfit-f...

They kind of did, that is basically how serverless works.

Managed runtimes on top of hypervisors.

Security, it isn't only memory footprint.

Which architecture can boot it in 150ms ?!

Hey! Co-founder of Unikraft here.

Unikraft aims to offer a Linux-compatible environment (so it feels familiar) with the ability to strip out unnecessary internal components in order to improve both boot-time/runtime performance and operational security.

Why would you need a memory allocator and garbage collector if you serve static content? Why would you need a scheduler if your app is run-to-completion?

Linux gives you the safety-net of generality and if you want to do anything remotely performant, you by-pass/hack it altogether.

In the article, Unikraft cold-boots in 150ms in an emulated environment (TCG). If it was running natively with virtualization hardware extensions, it can be even shorter, and without the need for snapshots which means you don't need to store this separately either.

Because it will be slightly faster and you will use less resources? For a lot of use cases that probably does not matter but for some it does.

This is a common myth. Debugging unikernels is indeed possible[1][2]. It may not be the type of debugging you're already used to, but then again, unikernels are very different from containers and VMs, so some adjustment is expected.

As for observability, why is that the concern of unikernels? That's something your application should do. You're free to hook it up to any observability stack you want.

[1]: https://nanovms.com/dev/tutorials/debugging-nanos-unikernels...

[2]: https://unikraft.org/docs/internals/debugging

Easy the very same kind of mechanisms for rootless/no-ssh containers are available.

once you login with github there's a start button on top left for that

They can generally be run on bare metal, to my knowledge.

I personally don't remember exactly what was meant with "executive".

Amiga: https://wiki.amigaos.net/wiki/Introduction_to_Exec

> The Multitasking Executive, better known as Exec, is the heart of the Amiga's operating system.

> All other systems in the Amiga rely on it to control multitasking, to manage the message-based interprocess communications system, and to arbitrate access to system resources.

There is no need in the operating system to run Unikernels. Every Unikernel includes parts of operating system needed for interacting with the underlying hardware. So Unikernels can run on bare metal if they know how to interact with the underlying hardware (i.e. if they have drivers for that hardware). Usually Unikernels are targeted to run on virtual machines because virtual machines have unified virtualised hardware. This allows running the same Unikernel on virtual machines across multiple cloud providers, since they have similar virtual hardware.

Yes, there is a certain irony when you look at the cloud workloads with a type 1 hypervisor managing either serverless or container workloads.