Hacker News Reader

Comment by m0th87 | Hacker News Reader

Hurd is one of those pieces of tech that just makes me sad. Performance implications aside, micro-kernels feel so much more "right". It feels like proper software engineering techniques applied to the kernel-level. How cool would it be to be able to, e.g. replace the default scheduler with something that satisfies your niche requirements?

But in Hurd's quarter century of life, it's gone nowhere, while Linux, Windows and OS X have zipped by. It feels like nothing short of an apocalypse will bring the micro-kernel back. I think the only major one in the wild in QNX (Blackberry OS), and that's waning. OS X / NT are no longer microkernels.

"Worse is better" still rings true, in more ways than one.

View on HN

I wouldn't say QNX is waning... It's used in trains, nuclear power stations, cars, embedded systems etc. If anything, QNX is a good counter-example to your argument because it's one of the few really successful microkernels out there.

edit: a broader list of where QNX is used: http://www.qnx.com/company/30ways/

Interesting. I'm so deeply embedded in the web/mobile world that I forgot there are some very real RTOS requirements that drive QNX uptake to this day.

Remember that microkernels aren't just trying to achieve modularity - they also take a stab at robustness by failure recovery. This is IMO doomed to fail - you are much better off trying to achieve robustness by correctness. Monolithic kernels focus more on correctness and therefore progress much faster.

MINIX seems to be working pretty well these days.

Most of the kernels that try very hard to achieve correctness (in the embedded / real-time space that would be used in military or aerospace applications) are microkernels. Microkernels have a smaller number of primitives that are more orthogonal, so they are easier to implement correctly and audit them, and you get some amount of preemptibility for free.

Also, as far as I know, the only kernel that has been proven correct with a mechanically verifiable proof is an L4 variant.

proven correct with a mechanically verifiable proof is an L4 variant

seL4, which is microkernel of course

http://www.sigops.org/sosp/sosp09/papers/klein-sosp09.pdf

Monolithic kernels don't "focus on correctness". Some people might when writing one, plan 9 for example. But plenty don't, like linux as the most obvious example.

Interestingly, important parts of the Linux kernel are proven correct (e.g. the scheduler). But yeah...not the whole thing.

What? When and where has any part of linux been proven correct?

Reading the Plan 9 kernel code hasn't convinced me that its authors focused on correctness. The kernel code is pretty, and its twenty-year-old architecture could pass as only ten years old; but even excluding drivers, there is no shortage of bugs.

You found lots of bugs reading the plan 9 kernel source, and forgot to report them?

What I mean is that they try to achieve stability by eliminating bugs, not by doing damage control. Proactive vs reactive.

And what I mean is that is simply not true. Monolithic kernels give us unstable systems like windows, linux, BSDs, etc. Virtually ever highly reliable operating system is built on a microkernel.

Exactly - and I don't think OS X was ever truly a microkernel, it used Mach as the base for XNU, but it was always a hybrid kernel even going back as far as the NeXTStep days.

QNX is all that is left and as you say, it's waning -- fast. And ironically, QNX in BlackBerry OS has lost many of the so-called advantages it had in the past, because a large portion of the OS is dedicated to running Android in an emulation layer, thus using a monolithic kernel anyway. sigh

Stallman failed and that's OK. Giving the world emacs and GCC was enough, frankly. He used to always make it seem like Linus just got "lucky" and happened to make a kernel before Hurd was done -- but that wasn't the case at all. Linus got a working kernel working faster and Linux proved to be better than anything Hurd could achieve, full-stop.

Exactly - and I don't think OS X was ever truly a microkernel, it used Mach as the base for XNU, but it was always a hybrid kernel even going back as far as the NeXTStep days.

Well, it uses it now. (But yes, not as a microkernel.)

You never know how something will come handy — learnt Hurd programming => now not afraid of Mac OS X kernel'ish stuff

> Linus just got "lucky" and happened to make a kernel before Hurd was done -- but that wasn't the case at all.

The funny thing is it's not even the case that there's only room for just 1 production-quality open source kernel. Through all this time the *BSDs have done rather well in comparison. We might just conclude that despite a great body of work that we all respect and owe a lot to, maybe GNU/FSF isn't all that great at managing a project. (See also: Emacs Schism, GCC vs. ECGS, GCC vs. LLVM.)

(Aside: Personally, I booted Debian GNU/HURD on a Pentium II more than ten years ago to try it out. At the time it was slow and had a bunch of drivers ported from Linux 2.0. It sounds like not much has changed, however I never did get X working, so good job there.)

Components were very successful with Visual Basic, but (despite the C# description[1]) haven't really been front and center in languages and operating systems. I honestly think it is because we don't have something at the bottom that was built components first. Decoupling designs is hard, and we get systems of objects and not components.

1) 2nd paragraph of introduction http://www.microsoft.com/en-us/download/confirmation.aspx?id...

Reply on news.ycombinator.com