# Thoughts on unikernels



## bcomputerguy (Jan 8, 2017)

I recently came across a term, unikernel that basically seems like they might become big in the future, mainly because of Linux and the way their kernel is becoming so large and complex.

I think the way FreeBSD works will allow it to dodge that unikernel bullet since on BSD you select what modules to load while linux is going towards windows where the kernel is bloated with stuff for all types of device drivers, etc.... At least this is what I feel. It would be interesting to hear some other opinions on unikernels, linux, FreeBSD and the future.

talk





another chat


----------



## tingo (Jan 8, 2017)

There is a tool for everything. Unikernels is also a tool. It is not going to replace the current system for operating systems on a personal computer any time soon. In the appliance / server space, well, we'll see.


----------



## bcomputerguy (Jan 9, 2017)

actually after looking at unikernels some more, it seems like it's just a natural reaction to the base linux kernel becoming bloated. Linux seems to be shoving everything into the kernel.


----------



## unitrunker (Feb 13, 2019)

I was looking at nanos today so I checked the forums to see what others have to say. I like the idea that nanos works with ELF binaries. However, nanos is a wrapper for QEMU whereas I'd rather use bhyve - in a jail. Really though, if all I want is isolation, it seems like I could pick an app, wrap it with Super Capsicumizer 2000, and call it day. 

Aside from some nice Go scripts to spin up and shut down instances - with way less configuration hassle than a full VM image - what else is there that the unikernel has to offer?


----------



## ralphbsz (Feb 13, 2019)

I don't think Unikernels are a reaction to Linux.  The idea started in the research sphere in the late 90s, and at that time, Linux was a tiny kernel (it was just getting its first module loading mechanism), and used mostly for amateurs and research.  What the idea came out of was the "death of systems research" (as aptly described by Rob Pike), together with the observation that more and more systems were being used for a single purpose (the whole OS does nothing but run one application), often run under virtualization (which was just getting real for mass-market computers back then, Sun, IBM and HP and other microprocessor vendors were starting to have partitionable machines, such as AIX'es LPARs, VMware was starting to get real, but the concept of VMs was ancient (IBM had been shipping it since the late 60s or early 70s).

So you have these (virtual) machines, and you run an OS that runs just one application.  Why do you need more than one address space?  Why do you even have to pre-build the OS and use it to start the application?  Why don't you just turn your OS into a set of small libraries, link them against the application, and boot the application on bare metal?  Sounds like an obvious idea?  So Dawson Engler (who now works right here at Stanford) did this as his PhD thesis, under Frans Kaashoek's group at MIT.  The idea is actually ancient.  The first operating systems were actually (in the 50s and early 60s) were actually intended to run a single-task, and the machine was rebooted for the next task.  So the way it was run was just like this: You take your program (often in FORTRAN or COBOL), compile it, link it against the IO libraries appropriate for your hardware (how to punch cards, how to do tape IO), and boot the resulting executable.  The "IO libraries" were really the operating system in those days.  All Dawson with his Exokernel thesis did was to take the implementation into the 20th century, and make it an interesting piece of modern OS research, rather than a historical oddity.  By the way, Dawson is a really nice guy, and has done great work since: his research on finding bugs in programs by doing static analysis in the code is really good, and has turned into a good startup and a small industry of improving software quality.  No, the Linux kernel is not "bloated with drivers", nor is Windows; in both you can unload all the stuff you don't need.

I don't think it has anything to do with FreeBSD versus Linux.  And it has nothing to do with the common Linux hate that one so commonly sees in this forum.  From a modularity point of view, there is no architectural difference between Linux and FreeBSD: Both a systems with a single large kernel (not microkernel based), and both allow loading of subsystems, filesystems, and drivers as modules.  Very similar architecture.


----------



## rigoletto@ (Feb 13, 2019)

People behind unikernels/microkernels like MirageOS (OCaml) and Muen (SPARK) are researchers and/or commercial business usually focused in high-integrity safety-critical systems. They live in "another world" where AIX, FreeBSD, Linux, Windows, MacOS etc. are nothing more than random platforms they use to develop their software.

When they need an OS for something, they build they own for that specific purpose or buy something like WxWorks. What happens in the general purpose OS world is more or less irrelevant because they will use wherever be available just as tools to archive they objective.

PS. the objective behind MirageOS is to make it general purpose OS at some point (but with a lot more overhead than a monolitic/hybrid kernel).

*[EDIT]*

For the sake of the information, MirageOS runs on Bhyve.


----------



## Spartrekus (Feb 13, 2019)

bcomputerguy said:


> I recently came across a term, unikernel that basically seems like they might become big in the future, mainly because of Linux and the way their kernel is becoming so large and complex.
> 
> I think the way FreeBSD works will allow it to dodge that unikernel bullet since on BSD you select what modules to load while linux is going towards windows where the kernel is bloated with stuff for all types of device drivers, etc.... At least this is what I feel. It would be interesting to hear some other opinions on unikernels, linux, FreeBSD and the future.
> 
> ...



Bravo !! Good point.

This is what I always say at some point a "program" comes to explosion.
Either you make choice  to leave it working as it - very basically functioning, create a new one, or it will "explode"...
I feel that there is law of physics behind.


----------



## kpedersen (Feb 13, 2019)

So we won't be seeing a Muen/kFreeBSD any time soon?


----------



## rigoletto@ (Feb 13, 2019)

Some words about Muen.



kpedersen said:


> So we won't be seeing a Muen/kFreeBSD any time soon?



Nobody is holding anyone of doing that.


----------



## rigoletto@ (Feb 13, 2019)

Oh, there is the Qubes OS too.


----------



## xtremae (Feb 13, 2019)

pyret said:


> Also, there is nothing different between the FreeBSD and Linux kernels. Both are monolithic and allow the loading and unloading of modules during runtime.


Apparently, people are still confused about this. They think that if a monolithic kernel ships with more modules it is more _bloated_.


----------



## kpedersen (Feb 13, 2019)

xtremae said:


> Apparently, people are still confused about this. They think that if a monolithic kernel ships with more modules it is more _bloated_.



I think it is more all the SystemD hooks that makes the Linux kernel bloated .

I am not at all qualified to make a judgment but the video driver layer that supposedly makes it easier to port Linux KMS drivers to FreeBSD leaves me feeling a little uneasy. It will probably always be more "bloated" than if the drivers were 100% native. But I suppose it is necessary for the foreseeable lifespan of FreeBSD.


----------



## xtremae (Feb 13, 2019)

kpedersen said:


> I think it is more all the SystemD hooks that makes the Linux kernel bloated .



I must have missed it but I'm not sure systemd was mentioned in the context of the original or subsequent posts.
Regardless, there are no systemd _hooks _in the kernel. systemd as a userspace entity utilizes kernel primitives like namespaces and cgroups but those aren't _hooks _and most definitely don't make the kernel more _bloated. _For example, most kernels provide packet filtering facilities that are used by userspace services like firewalls. Packet filtering however is not a _hook._


----------

