Rapid development. There's probably things you'd get out of the latest Linux kernel's networking stack or video stack or btrfs driver or something, but your upgrade option is all-or-nothing, and you certainly don't to upgrade all of it. A microkernel could let you upgrade just the component you want to try a newer version of; it also means that there's a larger base of people like you testing the latest versions of each component, so the kernel improves more quickly.

Of course, this presupposes things about API compatibility/stability between microkernel components that may not be true in all microkernel designs.

It sounds like a really cool idea, but to some extent we already have this with Linux out-of-tree modules - it doesn't work very well, but it's there, you can build a new version of the module, unload the old one, and load the new one. I suspect the microkernel version of this would be hard to implement for most of the same reasons, and probably fail in most of the same ways, which boil down to "APIs change a lot so things don't stay compatible for long".

I would expect that for some modules (networking, video, and FS can be loaded as modules) you can just put the new version of the module in a somewhat-earlier version of the kernel.

I mean, if the ABI or internal kernel macros change, you're in for some porting work, but most of the kernel stuff can be configured as loadable modules. :)

Can't we have some kind of compiler technology that allows us to have the advantages of both microkernels and unikernels?

You have to decide for yourself what is relevant to your application-visible needs. If you deem that Linux is better for running your Java app than QNX, no one wants to take that decision away from you. I don't think that's where the real discussion is. The real discussion involving microkernels is about the future of OS development. Should it just be the same as Linux, forever, with no architectural changes? Have we literally written the last OS?

As a layperson, I can be persuaded microkernels are a good idea that could yield some reliability and security improvement. I can be persuaded that the performance issues are avoidable. But I'm also pretty sure that most of the problems we have with current systems are in code that would now be outside the microkernel anyway. We are going to end up with, optimistically, about the same number of lines of code. So to me it seems much more important what the development process looks like. Unfortunately there is not a lot of accessible research about that kind of thing, relative to things like microkernel performance which are at least easy to generate demonstrative benchmarks for.

There's a different way to look at costs and downtime here in certain rather core applications. Think about your average server here for a moment. It's got a motherboard, a CPU, some RAM, a few network ports, and a hard disk. Now, let's take, for example, running a redis-like node. The job you care about -- looking up key/value pairs -- only touches memory. Any hard disk access is a slowdown to some part of the system, as a slowdown implies that there's been a context switch, a travel through a few layers of virtual filesystem, before being sent to or fetching from a pile of spinning rust. Most of those accesses, you don't care about, at all. Your logfiles are all being sent on the network anyway, your executables are already in memory, and your scheduled tasks haven't changed in a month.

For this sort of task, there's a remarkable amount of dead weight that can be cleared out. For starters, because your binaries are so small, serving them over PXE or the like becomes a triviality in regards to bandwidth. Your system will start faster because it doesn't have to do things like initialize the various pseudo-filesystems Linux has, or initialize the virtual file system, or any number of other tasks. This now means you don't need that hot, failure prone hard disk at all, nor its buffers and journals and other context switches that occur because of it. Because you've gotten rid of the hard disk, you've gotten rid of its heat, meaning you can pack servers more densely.

Similarly, you can eliminate a considerable amount of the networking stack. You know what the messages it's going to send and receive look like, and any other messages are going to be dropped anyways, so why have the code to handle them loaded in memory at all?

Because of their minimalism, microkernels allow you to ask a lot more fundamental questions about your applications. This means you can build a system much more oriented around your needs, with minimal superfluous framework. This now means your apps are faster, because they have to fight less OS bureaucracy, more reliable because they're much more simple, and more secure, because the system as a whole is smaller, and thus easier to audit. Sometimes, asking yourself what you don't need is just as important, if not moreso, than what you do need.

So you save a few milliseconds if you don't initialize some filesystems, good but makes very little difference in the end.

Not having a hard disk? Doesn't require a microkernel at all. Booting over LAN has been practical for a long time.

If I glance the closest linux machine I have, it has a 6MB kernel with 10MB initrd. To put that on a server with gigabytes of ram? Trimming an unused networking stack here is not the use case where a microkernel will help performance.

I agree, this doesn't seem very compelling.

Perhaps there is a use case that is compelling, but this particular one doesn't do it for me.

A single disk seek takes a few milliseconds. If you need to do any kind of disk verification, it will take longer than a few milliseconds.

The "few milliseconds" was a response to "Your system will start faster because it doesn't have to do things like initialize the various pseudo-filesystems Linux has, or initialize the virtual file system, or any number of other tasks." Doing that init takes very little time and zero disk accesses. That and a few megabytes of ram are all you save by using a microkernel instead of linux in this situation.

Linux won't access the hard drive if it's unnecessary, same as the microkernel.

Security. You ever run a process in its own VM for security reasons? A hypervisor is a microkernel with bloaty processes and even more hardware protections.

This, especially sel4: the microkernel is small enough for formal verification.

Hypervisors are much closer to exokernels. General distinction between kernel types:

Monolithic kernel = all familiar kernel abstractions (processes, IPC, filesystem, virtual memory, device drivers, networking stack) are built into the kernel.

Microkernel = Most kernel abstractions run as separate processes. Kernel communicates with them over IPC.

Exokernel/unikernel = There are no kernel abstractions. Instead, these abstractions are built into runtime libraries that are then linked into applications. The kernel's only job is to securely multiplex the hardware, and it exports an interface that is similar to bare metal. In 2016, the exokernel is called a hypervisor, and the libOS is called a unikernel.

Neokernel = the programming language's runtime library provides the primary kernel abstractions, along with any interprocess security. Machines are limited to a single programming language.

I'm quite aware :)

Most people have experience running processes in isolated VMs for security reasons. I was trying to use that as an anchor point to explain why one might want to have components of a single operating system run as separate servers, for much the same reason -- compartmentalized security.

The general trend is away from this and towards containers which leave it up to a monolithic kernel to secure individual processes.

Most people run VMs for hardware utilization purposes.

That was the trend five years ago. We're on unikernels now.

Who is "we" ? I had the impression unikernels were still a highly experimental work in progress you could only use with ocaml and that noone had ever used in production for anything serious.

It's beyond experiments now and there are clear uses for such things. For example, a recent post describes using MirageOS to build a firewall VM [1]. There are also network security/intrusion-detection systems [2].

There are a number of ways to build unikernels and they're not all OCaml (which is just MirageOS) -- http://unikernel.org is trying to bring these together.

[1] http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewal...

[2] https://galois.com/project/cyberchaff/

Don't forget standard posix stuff with rumprun.

Yes, of course. I should also have linked to the Unikernel+Docker demo [1], which is taking legacy software and using Rump Kernels and the Docker toolchain to deploy unikernels (to show how all these things can create a multiplier effect in terms of benefits).

It would be great to get a list of live unikernel deployments listed somewhere to address questions like this when they come up.

[1] http://unikernel.org/blog/2015/unikernels-meet-docker/

They're pretty cutting edge still but not that experimental. I think we'll see unikernels explode in popularity towards the end of 2016 or in 2017.

"Who is "we" ?"

Hipsters.

Recovering from individual components crashing is a nice property, but in practice we don't use it at the kernel layer. But it does show up in other places -- when designing datacenters and web services (Netflix, Chaos Monkey, horizontally scaled web servers behind a pair of load balancers), and, in web browsers (Google Chrome is a bunch of processes; if Flash takes down one tab/process, the others keep running).

> The main issue I have with microkernels is that they don't solve any problem that I have. > > […] > > Do microkernels offer any application-visible features that I don't have today with Linux? To the best of my knowledge they do not.

Don't you hate having to upgrade your whole kernel (memory manager, scheduler, fs, network stack) just to fix a small-but-annoying problem with your GPU (for example tearing)?

With a microkernel you could update that driver without updating the rest of the kernel, or of the OS. Yes "OS", because an update of the kernel often requires an update of the corresponding user-space programs (lmsensors, libdrm, mesa, X11, libalsa, iptables). If our systems were built upon microkernels and developed with strict boundaries between components it would be much easier to maintain them.

However I think Torvarlds has a point when it says that going down the path of microkernels means turning many low-level problems into IPC problems, most of which are not yet solved or not solved in a way that is compatible (performance-wise) with current hardware. Let's hope research and the brewing libre hardware community will tackle this problem.

You can already switch/upgrade graphics drivers without rebooting, thanks to dynamically loaded modules. Just stop X, rmmod the old driver, modprobe the new one, and start X again.

For consumer applications, you are limited by the ecosystems, such Android or iOS or Windows, so you can't choose kernel anyway.

For cloud applications, what is more important is the system architecture, not the kernel. If we assume docker is the preferred way to deploy an app. We only need very limited features from kernel:

- If I specify the CPU and RAM requirements, the kernel simply allocates them to the container. There is no need for complicated dynamic scheduling and balance.

- Network within the same data center has much lower latency than hard disk (<<1ms vs 10ms). We will be much better of using network storage or database.

- If we assign network address to each container, the kernel can deliver network packets to container, and the container uses its own CPU and RAM to process the network traffic. This will avoid the situation that kernel spend a lot of CPU/RAM to process network traffic for all containers and find the correct way to charge the cost.

If we do all above, there is not much kernel features are needed by cloud applications, as such features will be replaced by cloud services like cloud storage/database. It will make develop and deploy cloud services easier and more productive.

I'm under the impression that in the 90s, a lot of Blue Screen of Death errors in Windows 9x were caused by poorly written drivers.

And lack of tooling and lack of OS design. With NT they had actual isolation to allow local crashes, and MS has the static checker to ensure a level of quality to reduce said crashes.

Windows 3.1 had a VMM that could have isolated drivers just fine. But the drivers that people needed to run were DOS drivers that were shoddily written with precisely-controllable (i.e. non-virtualizable) interrupts in mind. "Consumer" Windows couldn't get around the fact that they had to support hardware that came with crap drivers. The reason NT worked so well was that it targeted an extremely reduced machine profile in the form of "workstations", where Microsoft could write all the drivers themselves.

It took Microsoft until XP to actually be able to stop supporting the old crap VXDs and just force all the hardware manufacturers to "write a new driver or else". That they then also instituted the WHQL program to certify those drivers—and later added tooling to make that certifying job more rigorous—was just icing. It was moving away from VXD drivers that solved most of the problem.

So because of social pressure, from 3.1 to Me, Windows had to cave down to VxD model shipped by manufacturers even though they had an adequate layer in place ? that is .. something.

Not social pressure; rather, Microsoft's continued revenue stream depending on an implicit guarantee of upgrades not breaking backward compatibility, even when what "broke" was an invalid assumption about undocumented APIs made by a third-party. To consumers, it all looks like "Windows broke the app."

See also, everything Raymond Chen has ever written. For example: https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=...

You get something of the same with the "do not break user space" policy that Torvalds is holding the kernel devs to.

Just wish that the user space libs would adopt the same policy, rather than try to paper over it by stuffing everything into containers (liable to turn into the Linux equivalent of DLL hell).

> A robust system is designed such that any machine in it can randomly crash.

This assumes that every robust system can consist of multiple machines. One thing I've learned from the article, and other comments in favor of microkernels, is that they're successful in applications where a single machine has to be a robust system all by itself.

Note that an embedded system is usually such a machine.

At scale 10% could be anywhere from 100(s) of racks to ten(s) of datacenters

Erm. I suppose I should mention that I'm an SRE at Google, but I'm very carefully not talking about my current job here (which is special in ways I can't discuss). Interpret my perspective as relating to personal projects and a career of working at assorted medium-to-large companies.

Google published a paper about Borg (confidential until recently). Is that what you're referring to? http://research.google.com/pubs/pub43438.html

There's some nice egg on my face. Don't mind me, I'll be eating crow over there in the corner.