Live data from Hacker News

Maybe we should revisit microkernels

notes.hella.cheap

31–34 of 34 posts

Re: Maybe we should revisit microkernels

#31
post #28

Earlier quoted context omitted.

You did not claim that microkernels were less commercially successful. You claimed that microkernels suffer from the same security problems that plague commercial monolithic kernels such as Linux, Windows, macOS, iOS, Android, etc. You claimed without evidence, and I quote, “none of the upsides have panned out”. In contrast, microkernels have completely dominated the field, displacing prior monolithic kernel solution…

You claimed without evidence, or more accurately, bad evidence, confusing RTOS with "reliability and security." And you were somehow confused that security mattered for systems with no network connection. FYI: For most commercial network equipment (internet backbone and similar), reliability and security are the highest priority. Most of that is Linux, BSD, and friends.

> You claimed without evidence, or more accurately, bad evidence, confusing RTOS with "reliability and security."

That sentence is grammatical nonsense. Try again to articulate your point so it is coherent.

Furthermore, you have still failed to present any historical examples for literally any of your bullet points or articulate any of the claimed upsides you purport have failed to pan out. In contrast, I have pointed out two frequently claimed upsides, reliability and security, that have demonstrably succeeded to such a degree that prevailing monolithic systems were largely replaced with microkernel systems in domains where reliability and security are highly valued such as aerospace and defense. To the extent that monolithic systems are still used, they were either the legacy option that has not been replaced or chosen where cost reduction is the highest priority, not security and reliability.

> FYI: For most commercial network equipment (internet backbone and similar), reliability and security are the highest priority.

Frankly, I find it baffling that you think that nuclear weapon systems, military jet fighters (which are network connected by the way), and commercial jetliners (also network connected) have lower reliability and security requirements than commercial networking equipment. And this is ignoring the fact that commercial networking equipment is some of the worst with respect to reliability and security. Cisco, one of the largest vendors in the space, routinely has trivial remote authentication bypasses allowing complete takeover. Here is one from last month: https://app.opencve.io/cve/CVE-2026-20181. One from earlier this year: https://app.opencve.io/cve/CVE-2026-20079. Or this one: https://app.opencve.io/cve/CVE-2026-20127. How about this one: https://app.opencve.io/cve/CVE-2026-20182.

Commercial networking equipment security is a joke. Find me literally any technical person who would claim that Cisco can defend against state actors. I will wait.

Re: Maybe we should revisit microkernels

#33
post #8

Earlier quoted context omitted.

Yes, but they remain confined to niche applications because none of them has been designed to be incorporated in a framework that would allow the gradual migration to them of the legacy applications and device drivers. Only Fuchsia might have a chance, because of the disproportionate control that Google has over the Android applications and because of the constraints imposed on those.

Unfortunately Fuchsia seems all but dead these days

Fine by me. Technology-wise, it doesn't seem to do anything cool that hasn't been done before, and its business goals seem to be to get rid of that pesky GPL2 licensed stuff and to introduce a stable ABI for drivers (i.e. no accidental drivers for "real Linux" because of Android anymore).

Re: Maybe we should revisit microkernels

#34
post #27
post #20

Earlier quoted context omitted.

What about Minix 3? Probably the most widely deployed microkernel ever: it's inside every Intel CPU for the last ~20 years. Already has a mostly-working port of the NetBSD userland. It was shaping up quite well until Andy Tanenbaum retired. Since then, nothing. Of course, Intel has never released any of its code, which is terrible -- but legal and license-compliant. https://www.osnews.com/story/136174/minix-is-dead/

I spent a lot of time with Minix 3 (see https://github.com/rochus-keller/Minix3/tree/Minix3_Book_TCC ). The intention was to make the book version compile with TCC. It turned out that this version only covers a fraction of the relevant parts necessary to build a working system. Minix 3 in addition includes hundereds of assembly files. The impression created by the book of a lean C implemented kernel, or the claim "fo…

Wow! Thank you for this. I had no idea -- except for the performance delta, which does not surprise me at all.
Post reply on HN