NetBSD is a very portable BSD-licensed operating system.
This is CoreCLR, the open source .NET framework from Microsoft.
Why is this important?
Programs for NetBSD can be run in a stripped down NetBSD kernel and libc (a unikernel) called rumpkernel, which can be run on any platform, including on bare metal.
It is also extremely minimal - an operating system image for nethack was a mere 4MB.
Rump can also run on any architecture that NetBSD runs on (including MIPS, VAX, m68k, as well as standard platforms like amd64 and ARM) and also on those without fully NetBSD support, but just with a functional C compiler (like RISCV).
Many people use rump as an extremely lightweight container - it can run on Linux and others.
Rump was recently used to port NetBSD audio drivers to GNU/Hurd.
Caveats: doesn't run in rump yet, but this is a big step towards it. .NET is also not self-hosting yet, and requires assemblies (CoreFX) to be cross-compiled from Linux.
The work was done almost entirely by Kamil Rytarowski, a NetBSD developer, in his free time. Good job Kamil!
I was wondering "why NetBSD???", other than as a possible hobby project, but your explanation gives a pretty clear answer. I've never even heard of rump, and know little to nothing about NetBSD, but this sounds really, really interesting. In my spare time I'm writing a "fantasy console" (along the lines of pico-8) that will run in a framebuffer. I wonder if this would be a good fit.
Forget Docker, the future is unikernels! [0] I haven't gotten to play with them much, and the ecosystem is very, very young, but the idea of it all is very intriguing to me.
How can you compare a kernel application vs a process isolation layer? Containers will be adopted to dynamically load kernel modules and then we'll have dynamic "rump" kernels, but saying to forget Docker and the future is Unikernels, doesn't make a lot of sense technically.
Think of rump kernels as a portable library of drivers with a well-specified API.
What is unique about NetBSD is that they have been structuring their driver code on top of well-specified portable APIs inside the kernel (AFAIK beginning with bus_space in NetBSD 1.2 in 1996: http://netbsd.gw.com/cgi-bin/man-cgi?bus_space++NetBSD-curre...). At first this was to increase portability by making it possible to write a single device driver that would work on different architectures and over different buses (contrast to Linux, where you basically have to write a new driver for the same device over PCI vs USB).
Having these well-specified API layers is what makes it easy to take the NetBSD drivers and use them outside of the NetBSD kernel, which is what rump does. This makes it possible to write and debug drivers in NetBSD userspace (and run them too, there are proposals that are essentially steering NetBSD into a microkernel: https://wiki.netbsd.org/projects/project/userland_pci/). You can also implement the NetBSD APIs that the drivers use in your own kernel and run the NetBSD drivers.
There was a similar project for Linux drivers (DDEKit: http://os.inf.tu-dresden.de/ddekit/) but the ad-hoc nature of how Linux device drivers interact with the rest of the Linux kernel and the major changes across different Linux versions make such a project much harder to use and keep current.
The rump kernel can be used as the basis of a unikernel (see: Rumprun). But, the rump kernel theoretically has applications beyond just use in a unikernel, by providing a common, documented API on one end and hypercall interface on the other which (in theory) enables robust driver and application portability even when used in "traditional" userland / full-OS environment.
So, in short, a rump kernel is a building block that can be used to build a unikernel, but the rump kernel can also be used in other contexts as well.
Why is this important? Programs for NetBSD can be run in a stripped down NetBSD kernel and libc (a unikernel) called rumpkernel, which can be run on any platform, including on bare metal. It is also extremely minimal - an operating system image for nethack was a mere 4MB.
Rump can also run on any architecture that NetBSD runs on (including MIPS, VAX, m68k, as well as standard platforms like amd64 and ARM) and also on those without fully NetBSD support, but just with a functional C compiler (like RISCV). Many people use rump as an extremely lightweight container - it can run on Linux and others.
Rump was recently used to port NetBSD audio drivers to GNU/Hurd.
Caveats: doesn't run in rump yet, but this is a big step towards it. .NET is also not self-hosting yet, and requires assemblies (CoreFX) to be cross-compiled from Linux.
The work was done almost entirely by Kamil Rytarowski, a NetBSD developer, in his free time. Good job Kamil!