Hacker News Reader

Comment by mercurial | Hacker News Reader

> However, afaik, these days the designs of Mach and Hurd aren't looked upon very highly, the stability advantages of microkernels aren't as important anymore with rock solid traditional kernels, and instead of figuring out how to empower non-root users on Unix systems we just give everyone their own VM.

On the other hand QNX, a closed-source Unix-like microkernel OS, has been used commercially for a long time - for instance, it powers Blackberry phones nowadays, and I heard the performance is quite decent.

View on HN

It's surreal to me that this conversation still happens in these terms.

People doing real work for which they need an OS don't care that QNX/HURD are microkernels or that Linux/NetBSD aren't. They care that one solves their problem better than the other.

Nobody cares about kernel architecture unless they're writing (or learning about) kernels. Everybody else is looking for an OS that meets practical requirements. QNX's architecture might help it meet some requirements better than Linux's architecture, but the architecture itself is not a determining factor in commercial success.

I don't understand your argument. We are talking about kernel architecture (and specifically, monolithic kernels vs microkernels).

Specifically, I brought up QNX as an example of microkernel-based OS used in the wild, as opposed to Hurd and (presumably) Minix - which gets to show that they can be made to work. However QNX is marketed is no concern of mine.

First, my comment was not directed solely at you but at the conversation in general.

Second, the original context of that conversation isn't kernel architectures, but what particular kernels "offer".

Discussing kernel architectures as if they're a practical advantage is surreal.

You're splitting hairs. Microkernels do offer practical advantages by virtue of their architecture, while suffering from other drawbacks again caused by their architecture.

I'm not trying to "split hairs", I'm trying to address a problem that has repeatedly made my life difficult -- people seeking particular technologies instead of solutions.

But since that has obviously made some people upset, I'll trouble you no more about it. I'm sorry to have intruded.

Your life must be very difficult...

Why do you automobile engineers keep talking to each other about pistons and transmissions, and all that nonsense, it's absurd. I just want a car that gets me from A to B and doesn't use too much gas. I don't see what that has to do with engine seals.

Right here and now, we're doing it because it's fun. At the end of the day, most of us go back to practical solutions, but we have to get this stuff out of our system. :)

One of the benefits of microkernels is supposed to be their resilience (since code that would otherwise be in the kernel is now in servers and can be restarted if it goes wrong or upgraded in place without taking down the whole kernel).

That sounds like a pretty good practical benefit to me.

Resilience is the requirement. "Microkernel" is a possible means to an end, not the end itself.

Do we know of any other mean?

Well, if you have X units of effort (dollars, man-years, whatever) you can choose to allocate some of it to creating a mechanism for tolerating buggy drivers, and some to debugging the drivers. Micro- vs monolithic- in the real world is an argument over this exact allocation.

There are two practical problems with microkernels:

(1) Hardware. Some driver locks up your PCI bus. Your whole system grinds to a halt, whether it's a microkernel or not. This could probably be solved by having hardware that doesn't suck, but unfortunately here in the real world we've settled on the cheapest option, PC hardware which does suck.

(2) Division of responsibilities. Some OS structures like the process table are inherently connected to multiple components (memory management, filesystem, etc). Doing process creation or fork in a microkernel results in a flurry of internal messages between the different parts which is hard to reason about and fragile. Minix especially suffered this problem.

I don't know what you specifically mean by a driver locking up PCI (and we've moved on to PCIe now), but I suspect the general category of (1) is largely addressed by the io virtualization facilities and RAS features that have recently come to amd64 hardware. That stuff has existed on big iron hardware since times immemorial.

There's no such thing as real work, in much the same way that there's no such thing as the real world. Everyone creates bubbles and cushions around themselves.

Reply on news.ycombinator.com