8 ms·

Ask HN: Why are all major operating systems monolithic?

44 points by achenet 2y ago

Why are all major OS's (Windows, macOS, Linux, *BSD) all monolithic kernels? Why aren't there more microkernel operating systems, like for example Redox or Minix?

nullindividual 2y ago
The NT kernel and XNU (macOS) are considered hybrid kernels. QNX, a microkernel, is absolutely everywhere (i.e., cars). Performance of microkernels is or was a hotly debated topic back in the '90s; microkernels generally had lower performance than their monolithic counterparts. There was a famous argument comparing Linux (monolithic) to MINIX (micro) [0]. Wikipedia has simple explanations for the differences between hybrid, mono, and micro kernels that serve as a decent primer [1] and a visual that I find helpful [2]. [0] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb... [1] https://en.wikipedia.org/wiki/Kernel_(operating_system) https://en.wikipedia.org/wiki/Kernel_(operating_system) [2] https://en.wikipedia.org/wiki/Hybrid_kernel#/media/File:OS-structure2.svg https://en.wikipedia.org/wiki/Hybrid_kernel#/media/File:OS-s...
- wzdd 2y ago
  Not to mention Minix running on ~every recent Intel system: https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine Microkernels still have lower performance than their monolithic counterparts. It makes sense really: the major difference between the two is protection barriers between components. All else being equal, a system without those barriers is faster than one with them unless crossing those barriers has zero cost -- which it only really does in the case of proof-carrying code and similar software solutions, where the "barrier" is more of a guarantee that the subsystem behaves as it should. A lot of microkernel research in the past focused on the "all else being equal" aspect, attempting to come up with innovative ways to reduce protection domain crossings in microkernels. For example, mapping graphics card memory or network device buffers directly into the address space of the client means that the hardware can deliver data directly to the client. However, monolithic kernels can also benefit from these sorts of innovations! As to why consumer OSes are all monoliths (yes, this includes Darwin and NT -- "hybrid" is a marketing term as all the important stuff runs in a single kernel address space; see https://en.wikipedia.org/wiki/Hybrid_kernel https://en.wikipedia.org/wiki/Hybrid_kernel): in consumer OSes, the 5% (or lower) performance hit of a microkernel is a big deal. In other spaces, such as embedded, the benefits of microkernels (reliability, security guarantees) are sometimes more important than raw performance.
  - area51org 2y ago
    > Microkernels still have lower performance than their monolithic counterparts This is what I've understood, that the idea sounds good but in practice isn't as good as it seems like it would be.
    - pclmulqdq 2y ago
      You necessarily cross from userland (end program) to OS to userland (driver) for most tasks that monokernels just do with the first userspace->OS transition.
      - Findecanor 2y ago
        There have been architectures specifically designed to support some form of IPC or other directly between processes without going through the kernel, and thus without having more overhead. But those are a bit esoteric. The Mill is one, that has been in development for a while, but its company hasn't published much lately and its current status is a bit unclear. It would have had something very similar to Spring/Solaris "Doors" in hardware, where the caller could have passed temporary permissions to memory ranges. A "kernel" would have been a process like any other, just with more permissions.
  - deleted 2y ago
    [deleted]
  - microtonal 2y ago
    Not to mention Minix running on ~every recent Intel system And L4 on every Apple device with a secure enclave: https://support.apple.com/nl-nl/guide/security/sec59b0b31ff/web#:~:text=The%20Secure%20Enclave%20Processor%20runs,against%20clock%20and%20power%20attacks https://support.apple.com/nl-nl/guide/security/sec59b0b31ff/....
  - AnimalMuppet 2y ago
    >Not to mention Minix running on ~every recent Intel system: https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine But not as the actual system OS. Minix is doing a very little, running on a little side processor that also does very little. It's not running on the main CPU, nor having to interact with the insane number of possible peripherals that real CPUs and OSes have to interact with, nor with real system loads, nor with many of the other constraints that real OSes have to deal with. Yes, it's there. Yes, it's there in really massive numbers. But, compared to what the OSes are doing on the main CPU, Minix is doing a toy job. So I'm not sure that it counts as evidence for much of anything.
- asdfman123 2y ago
  The Tanenbaum-Torvalds debate Wikipedia page seems to be missing a sidebar listing the combatants, strength of each side, causalities, etc.
  - PartiallyTyped 2y ago
    > # Intel Management Engine revelations > In 2017, it was revealed that Intel was running MINIX inside the Management Engine, a separate processor incorporated in Intel processor chipsets since 2008. As a response to this, Tanenbaum wrote an open letter to Intel claiming MINIX to be "the most widely used computer operating system in the world".[17] Hilarious. I only wish I had a bucket of popcorn before I began reading this. https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
- deleted 2y ago
  [deleted]
- ape4 2y ago
  QNX is everywhere - including space http://www.qnx.com/news/pr_1446_4.html?lang=en http://www.qnx.com/news/pr_1446_4.html?lang=en
  - RobotToaster 2y ago
    FreeRTOS too
- Findecanor 2y ago
  There have been attempts at using QNX for a mainstream OS though, neither that gained major success but not because of lack of technical merit. In the mid 1980's, the ICON microcomputer system, perhaps known mostly for being used in Canadian schools. In the early '00s, QNX got jealous of Linux's success and started opening it up to try to attract app developers from the open source community.. but closed down the program before it could gain traction. In the early '10s, it was bought by Blackberry and used for the OS of a new wave of Blackberry smartphones and a tablet.
  - adamomada 2y ago
    BlackBerry 10 devices were even capable of running Android (kitkat?) apps, which is an amazing feat by QNX. I wonder how they did it
- kazinator 2y ago
  QNX is promoted as a microkernel, but I'm skeptical. Microkernel doesn't just mean that we have modules that have their own threads. It refers to actually moving kernel functionality outside of the protected kernel space: device drivers, file systems, protocol stacks and such are in userland.
racional 2y ago
A good starting point for this question would be this famous discussion: https://en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate https://en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate Which in a nutshell comes down to Linus's view that producing a system that meets current needs (for example by offering a simple API) and is reasonably performant -- even if it ran on but a single architecture such as the i386 -- was more promising than a design offering "theoretical" benefits (such as portability) but which either didn't deliver the goods today or just wasn't reasonably performant. This is a vast simplification of a much broader set of issues but if one digs into the notes of why subsequent projects (e.g. Windows NT) moved away from microkernel designs, or the roughly analogous microservices debate of the past decade -- one often finds echoes of the same basic considerations.
bluGill 2y ago
Because once something works it is hard to start over from scratch and also hard to do a major refactor. It can be done but few can dedicate the time needed and so you stick with what is even if not ideal.
- jmull 2y ago
  > even if not ideal Also, it was never really clear that, in the end, a microkernel would offer significant practical benefits over what could be accomplished (with less work) within one of the established non-microkernel OSs.
0xbadcafebee 2y ago
Linux wouldn't really exist today if it wasn't for GNU Hurd being a microkernel. It took so damn long for Hurd to become stable that nobody wanted to use it. But people did want to use the GNU tools. So Linus made the Linux kernel a simple monolith, shipped it quickly, integrated patches quickly, and everyone started using it. By the time Hurd was stable, Linux was popular. So microkernels are hard and monoliths are easier, and the first one to the party tends to stick around the longest.
- wslh 2y ago
  Based on your comment and this question [1] I wonder how well GNU Hurd runs the open source stack and what problems you will find in the road (e.g. GPU support). I really like the approach of separating, in some way, the kernel, from the user space and interchange them but why you would do that, except for playing and research, if the kernel doesn't give you an advantage and it just an alternative? [1] https://unix.stackexchange.com/questions/282046/can-gnu-linux-software-run-on-gnu-hurd https://unix.stackexchange.com/questions/282046/can-gnu-linu...
  - RobotToaster 2y ago
    > what problems you will find in the road (e.g. GPU support). My understanding is it can't really run on actual hardware at all in it's current state, it's mostly run virtualized.
  - yjftsjthsd-h 2y ago
    On the software side, it's passable; as that post notes, there's a Debian spin on HURD that's basically functional. In practice, though, GPUs are the least of its concerns; AFAIK, HURD still doesn't support USB:( > I really like the approach of separating, in some way, the kernel, from the user space and interchange them but why you would do that, except for playing and research, if the kernel doesn't give you an advantage and it just an alternative? Well I think a lot of it is that we thought it would be easier; in theory, separating concerns and putting drivers in userspace sounds like it should make it a lot easier to write the OS. That didn't really turn out, but it seemed like a good idea at the time. On the more practical side, microkernels can have security and reliability benefits (if drivers run in userspace, they have less access to exploit, and crashing a driver doesn't crash the whole machine). I mean, diversity is also useful for its own sake, but there are more immediate benefits.
yjftsjthsd-h 2y ago
Very oversimplified answer: Microkernels still have a performance hit, end-users care more about performance than stability/security (at least at the ratio/margin in question), therefore we use the faster monolithic kernels for most user-visible systems, with carve outs where the performance hit isn't so bad (hence NT/Darwin really being more hybrid now, and even Linux can do some drivers in userspace). As other comments note, this only applies to places where performance matters; lots of embedded systems do in fact care more about reliability than performance so the outcome is different.
nimish 2y ago
Linux has more microkernel features than you'd think. You can run all of networking, filesystems, HID and more in user space with BPF/Fuse. What else is left?
- anyfoo 2y ago
  By that measure, a passenger bus is a modern sports car, because you can lower its suspension to be close to the road at the push of a button…
  - perihelions 2y ago
    (That's a feature for helping wheelchair-type passengers board at ground-level without assistance—just to explain for those who live in places without public transit).
    - renonce 2y ago
      Thanks for the explanation. I live in a place with lots of public transit but no suspension in any passenger bus. Fortunately I've been to the US before so I now know what it is.
  - renonce 2y ago
    From wikipedia: > A sports car is a car designed with an emphasis on dynamic performance, such as handling, acceleration, top speed, the thrill of driving, and racing capability. How would lowering suspension turn a passenger bus to a sports car?
    - anyfoo 2y ago
      That’s my point.
  - nimish 2y ago
    Well, what are we missing if networking, file systems and human IO are now run as user space servers? Process management? Graphics (ignoring X)? What low-level hardware interaction can't be done microkernel style? It's a bad analogy unless the button makes the bus change Transformers style into a completely different car.
pclmulqdq 2y ago
New OSes that have come out are pretty much universally microkernels. Fuchsia from Google is on a lot of their devices, and is a microkernel. SeL4 and QNX are microkernels for security and safety critical devices. I believe that Firecracker from AWS is also sort of microkernel-like (but pretends to be Linux). If you are building the device, the kernel, and the software, chances are that you are using a microkernel in 2024. Windows and the Unix OSes just have a lot more market penetration, strong network effects, and a big first-mover advantage. That means that when you are buying your OS or your hardware or your software, you're probably stuck with a monokernel.
- RetroTechie 2y ago
  Let's hope monolithic kernels are indeed an historical artefact, and over time microkernels will replace them in most popular OSes. A few % performance hit? (if that) Who cares. Security & reliability is where it's at these days.
  - Xarodon 2y ago
    Lots and lots of home users care more about the few % of performance than the nebulous "extra security". I have friends who use their desktop for gaming only, literally nothing else, I guarantee they don't care about the extra security a microkernel claims to offer.
- mike_hearn 2y ago
  Firecracker is a hypervisor, it pretends to be hardware not Linux.
23B1 2y ago
1. There is value in 'central control' several reasons; - the people required to work on it - in a timely fashion - in a coordinated fashion - the resources required - bugs, updates, maintenance 2. The competition for aforementioned talent 3. The competition for aforementioned resources 4. Profit motive
- sdwr 2y ago
  Had to scroll a long way to find this, I suspect this is far more important than any technical issue. Having an "owner" is a strong incentive/coordination point to get stuff done. You need the right owner, but the 95% of projects that don't get it right, we don't hear about. We hear all the time about how code structure mirrors org structure. A distributed project encourages fiefdoms, a centralized one asks for a taskmaster with final say.
  - anyfoo 2y ago
    And what prevents a microkernel from having the exact same owners as a monolithic kernel, working on the exact same things? This isn't web development, where "microservices" came up as a way to distribute complex software across stakeholders. There are very hard purely technical reasons for (or against!) microkernels, and the majority of microkernels (if not all) are still released and distributed in a "monolithic" model, i.e. an update distributes all components of it (modulo delta updates, which is also just a technicality).
    - 23B1 2y ago
      > And what prevents a microkernel from having the exact same owners as a monolithic kernel, working on the exact same things? Nothing inherent to the software is preventing anything. You could be right about the technical justifications. But OP's question wasn't "which is better?" it was "why?"
      - anyfoo 2y ago
        I am addressing the “why” that you both claim. The person I replied to said, I quote: > A distributed project encourages fiefdoms, a centralized one asks for a taskmaster with final say. What does the distinction between microkernel and monolithic kernel have to do with whether the project is “distributed”, or whether it is a “fiefdom”?
nottorp 2y ago
Because if the difference is still meaningful, the monolithic kernels are good enough?
PmTKg5d3AoKVnj0 2y ago
[flagged]
- ganbatekudasai 2y ago
  I’m going to venture a guess that you haven’t ever applied a single patch to any existing operating system, and that your knowledge of operating systems is pretty much based entirely on your experience as a user of them.
- sdwr 2y ago
  Makes more sense than "because they're 5% faster than microkernels"! That would also explain the current crop of microkernels - once the tech has been ironed out, architecture isn't life-or-death anymore.
freedomben 2y ago
Definitely read up on the Torvalds/Tanenbaum debate as there are lots of moving pieces and interesting theories. My opinion summed up ridiculously concisely is that the reasons are largely accidents of timing (i.e. there was room in the market for new entrants), mixed with trivial-at-the-time but high-impact choices. Had Tanenbaum been permitted by his publisher to give away copies of minix freely, Linux may never have been started at all. Had Tanenbaum chose raw performance over teachability (the kernel was a teaching tool after all), it may have made a difference. (warning: this part is controversial) There's also a lot of question about whether the GPL licensing kept Linux relevant, or if it was largely inconsequential. My opinion is that GPL made a big difference. Had the licensing of Minix been GPL flavored, it probably wouldn't have been used by companies like Intel for the Management Engine, but there might have been enough "forced sharing" to keep it relevant. Impossible to say for sure, but that's my two cents.
gwd 2y ago
For one thing, writing things in a microkernel are far more complex. In theory the isolation can mean lower impact of bugs and security issues; but in practice, the complexity means more bugs which are harder to debug. That's why you don't really see microkernels outside of embedded use cases -- the lower functionality requirement makes the complexity manageable. You can write a rocket OS as a "proper" microkernel, but there's no way you could write a full-blown Windows OS as a "proper" microkernel. That said, Windows or Linux can take leaves out of the microkernel playbook and apply them judiciously: KVM's architecture is arguably an example of this, where the core kernel does only the minimum necessary, and everything else is pushed to the user-mode component (QEMU, Firecracker, etc).
stracer 2y ago
Monolithic systems allow their authors much greater control over software that runs on computers.
- anyfoo 2y ago
  Again, absolute nonsense. Microkernels were designed for entirely different reasons than microservices. There are hard technical reasons for and against them, and most, if not all, microkernel OSes are still distributed in a rather monolithic model, not piecewise.
  - stracer 2y ago
    Where did I mention microservices? How does the fact current microkernel OSes are being distributed using a monolithic model imply my point is nonsense? A real microkernel OS with stable interfaces would mean its developers do not want control of all the kernel-like servers, and allow even basic users to easily install and use many alternative user servers, as opposed to Linux kernel services sanctioned and controlled by the Linux distribution kernel maintainers.
    - anyfoo 2y ago
      Those things are completely orthogonal. A microkernel can arbitrarily restrict what user servers are viable (for example just the ones it ships with), just like a monolithic kernel can arbitrarily restrict what loadable kernel modules are viable (for example just the ones it ships with).
      - stracer 2y ago
        A compiled microkernel can restrict, I agree. But if you want to restrict, why would you do a microkernel. It's much easier to justify with a monolith. One big point of making a microkernel as opposed to making a monolith is that you want to give other developers more freedom to develop, distribute, fix bugs on their own time schedule, while keeping compatibility with new kernels easily. In other words, not wanting to control what and when they do, and what users run on the kernel. Monolithic kernel like Linux, with its constant stream of little changes in interfaces, creates problems for developers of modules, and this leads to selection - those who keep up and satisfy the kernel requirements get in, those that don't keep up or do not satisfy requirements, can't get in, and are degraded to developing against some old kernel version. This is a kind of control.
renonce 2y ago
Is Linux really a monolithic kernel? I mean yeah for most use cases such as desktops and servers it is but there's nothing preventing you from disabling most of its features and drivers and keeping a very minimal core (I'm sure lots of embedded Linux does this) and you can, right now, make it act as a microkernel by putting any component in userspace, mounting filesystems and devices via FUSE and networks via TUN, at its current state. Now the question becomes why these components are built in the kernel and not in userspace? The answer is clear for each individual component. See how the in-tree NTFS driver eventually replaces NTFS-3g. Basically when an in-tree solution exists it just gets preferred over userspace solutions because of performance and reliability etc.
- anyfoo 2y ago
  Making a monolithic kernel slightly smaller does not make it a microkernel. And those userspace fs and tun drivers still build upon VFS and an entire network stack as part of the monolithic kernel.
fsflover 2y ago
According to Qubes OS, they are not realistic today: https://www.qubes-os.org/faq/#what-about-safe-languages-and-formally-verified-microkernels https://www.qubes-os.org/faq/#what-about-safe-languages-and-...
squarefoot 2y ago
Because microkernel was born in an era when cpu cycles were precious and albeit minimal, the difference in performance would be noticeable. Also, back then there were no security reasons to choose one over another; those were the days of NNTP and unencrypted email, and the web didn't even exist. I can't comment about other OSes, but in the case of Linux, when microkernels became stable enough, Linux had already taken over and was already running from supercomputers down to embedded systems (also 8088 based ancient hardware if one also counts ELKS). As of today, in my opinion, the biggest obstacle are device drivers; that's the biggest battleground that determines the success or failure of an OS. Linux runs pretty much everywhere and where hardware manufacturers stubbornly refuse to document their hardware, there are thousands of developers around the world spending time and money to reverse engineer closed drivers so that Linux can support more hardware. Of course once they're written they can be ported to other OSes, but that requires more time and more people devoted to the job.
mike_hearn 2y ago
Nobody actually wants microkernels. Remember that the microkernel design is just a pessimistic mitigation. It assumes code will be crashy and full of exploits forever, and that it's worth significantly complicating the design as well as sacrificing performance to try and mitigate that. If you're making an OS you could invest resources into micro-kernelling everything and then trying to resolve the many hard problems and bugs that mitigation itself creates, or you could just .... fix the bugs! Kernels aren't infinitely large and the latter is actually much preferable if you can do it. Some kinds of code are inherently in the core failure domain and trying to use restartable processes for them is impossible. For example if the code configuring your PCI controller crashes half way through, well, you need to reboot. You can't just restart the driver because you have no idea what state the hardware is in. A reboot gets you back into a known state, a server restart doesn't. Likewise if your root filesystem server segfaults, you can't restart it because your process start code is going to involve sending RPCs to the filesystem server so it'd just deadlock. Finally, it's a spectrum anyway. Microkernel vs monolithic is not a hard divide and code moves in and out of those kernels as time and hardware changes. The graphics stack on Windows NT started out of kernel, moved into the kernel, then moved back out again. In all OS' the bulk of the code resides in userspace libraries and in servers connected via IPC.
kazinator 2y ago
In the world of Linux, "micro-kernel-like things" are done when they are beneficial. An example of this is FUSE: filesystems in user space. There is a benefit to being able to run a filesystem in its own address space as a user process, so it is done. Also the model of a Unix kernel with services (daemons) in user space is kind of similar to the microkernel model. The graphical desktop is not in the kernel, the mail server isn't in the kernel, crond isn't in the kernel, the web server isn't in the kernel, the database server isn't in the kernel ... and maybe that's as close as we need to get to the microkernel. Speaking of web servers in user space: at least for serving a static page, it's faster for that to be inside the monolithic kernel, where it can access the protocol stack and filesystem code without crossing a protection boundary. Over the history of Linux, we have seen experimentation both with moving kernel things into user space (like with FUSE) as well as user things in to the kernel (TUX server, now evidently unmaintained).

44 points by achenet 2y ago

Why are all major OS's (Windows, macOS, Linux, *BSD) all monolithic kernels? Why aren't there more microkernel operating systems, like for example Redox or Minix?

nullindividual 2y ago

The NT kernel and XNU (macOS) are considered hybrid kernels. QNX, a microkernel, is absolutely everywhere (i.e., cars). Performance of microkernels is or was a hotly debated topic back in the '90s; microkernels generally had lower performance than their monolithic counterparts. There was a famous argument comparing Linux (monolithic) to MINIX (micro) [0]. Wikipedia has simple explanations for the differences between hybrid, mono, and micro kernels that serve as a decent primer [1] and a visual that I find helpful [2]. [0] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb... [1] https://en.wikipedia.org/wiki/Kernel_(operating_system) https://en.wikipedia.org/wiki/Kernel_(operating_system) [2] https://en.wikipedia.org/wiki/Hybrid_kernel#/media/File:OS-structure2.svg https://en.wikipedia.org/wiki/Hybrid_kernel#/media/File:OS-s...

wzdd 2y ago
Not to mention Minix running on ~every recent Intel system: https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine Microkernels still have lower performance than their monolithic counterparts. It makes sense really: the major difference between the two is protection barriers between components. All else being equal, a system without those barriers is faster than one with them unless crossing those barriers has zero cost -- which it only really does in the case of proof-carrying code and similar software solutions, where the "barrier" is more of a guarantee that the subsystem behaves as it should. A lot of microkernel research in the past focused on the "all else being equal" aspect, attempting to come up with innovative ways to reduce protection domain crossings in microkernels. For example, mapping graphics card memory or network device buffers directly into the address space of the client means that the hardware can deliver data directly to the client. However, monolithic kernels can also benefit from these sorts of innovations! As to why consumer OSes are all monoliths (yes, this includes Darwin and NT -- "hybrid" is a marketing term as all the important stuff runs in a single kernel address space; see https://en.wikipedia.org/wiki/Hybrid_kernel https://en.wikipedia.org/wiki/Hybrid_kernel): in consumer OSes, the 5% (or lower) performance hit of a microkernel is a big deal. In other spaces, such as embedded, the benefits of microkernels (reliability, security guarantees) are sometimes more important than raw performance.
- area51org 2y ago
  > Microkernels still have lower performance than their monolithic counterparts This is what I've understood, that the idea sounds good but in practice isn't as good as it seems like it would be.
  - pclmulqdq 2y ago
    You necessarily cross from userland (end program) to OS to userland (driver) for most tasks that monokernels just do with the first userspace->OS transition.
    - Findecanor 2y ago
      There have been architectures specifically designed to support some form of IPC or other directly between processes without going through the kernel, and thus without having more overhead. But those are a bit esoteric. The Mill is one, that has been in development for a while, but its company hasn't published much lately and its current status is a bit unclear. It would have had something very similar to Spring/Solaris "Doors" in hardware, where the caller could have passed temporary permissions to memory ranges. A "kernel" would have been a process like any other, just with more permissions.
- deleted 2y ago
  [deleted]
- microtonal 2y ago
  Not to mention Minix running on ~every recent Intel system And L4 on every Apple device with a secure enclave: https://support.apple.com/nl-nl/guide/security/sec59b0b31ff/web#:~:text=The%20Secure%20Enclave%20Processor%20runs,against%20clock%20and%20power%20attacks https://support.apple.com/nl-nl/guide/security/sec59b0b31ff/....
- AnimalMuppet 2y ago
  >Not to mention Minix running on ~every recent Intel system: https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine But not as the actual system OS. Minix is doing a very little, running on a little side processor that also does very little. It's not running on the main CPU, nor having to interact with the insane number of possible peripherals that real CPUs and OSes have to interact with, nor with real system loads, nor with many of the other constraints that real OSes have to deal with. Yes, it's there. Yes, it's there in really massive numbers. But, compared to what the OSes are doing on the main CPU, Minix is doing a toy job. So I'm not sure that it counts as evidence for much of anything.
asdfman123 2y ago
The Tanenbaum-Torvalds debate Wikipedia page seems to be missing a sidebar listing the combatants, strength of each side, causalities, etc.
- PartiallyTyped 2y ago
  > # Intel Management Engine revelations > In 2017, it was revealed that Intel was running MINIX inside the Management Engine, a separate processor incorporated in Intel processor chipsets since 2008. As a response to this, Tanenbaum wrote an open letter to Intel claiming MINIX to be "the most widely used computer operating system in the world".[17] Hilarious. I only wish I had a bucket of popcorn before I began reading this. https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
deleted 2y ago
[deleted]
ape4 2y ago
QNX is everywhere - including space http://www.qnx.com/news/pr_1446_4.html?lang=en http://www.qnx.com/news/pr_1446_4.html?lang=en
- RobotToaster 2y ago
  FreeRTOS too
Findecanor 2y ago
There have been attempts at using QNX for a mainstream OS though, neither that gained major success but not because of lack of technical merit. In the mid 1980's, the ICON microcomputer system, perhaps known mostly for being used in Canadian schools. In the early '00s, QNX got jealous of Linux's success and started opening it up to try to attract app developers from the open source community.. but closed down the program before it could gain traction. In the early '10s, it was bought by Blackberry and used for the OS of a new wave of Blackberry smartphones and a tablet.
- adamomada 2y ago
  BlackBerry 10 devices were even capable of running Android (kitkat?) apps, which is an amazing feat by QNX. I wonder how they did it
kazinator 2y ago
QNX is promoted as a microkernel, but I'm skeptical. Microkernel doesn't just mean that we have modules that have their own threads. It refers to actually moving kernel functionality outside of the protected kernel space: device drivers, file systems, protocol stacks and such are in userland.

racional 2y ago

A good starting point for this question would be this famous discussion: https://en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate https://en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate Which in a nutshell comes down to Linus's view that producing a system that meets current needs (for example by offering a simple API) and is reasonably performant -- even if it ran on but a single architecture such as the i386 -- was more promising than a design offering "theoretical" benefits (such as portability) but which either didn't deliver the goods today or just wasn't reasonably performant. This is a vast simplification of a much broader set of issues but if one digs into the notes of why subsequent projects (e.g. Windows NT) moved away from microkernel designs, or the roughly analogous microservices debate of the past decade -- one often finds echoes of the same basic considerations.

bluGill 2y ago

Because once something works it is hard to start over from scratch and also hard to do a major refactor. It can be done but few can dedicate the time needed and so you stick with what is even if not ideal.

jmull 2y ago
> even if not ideal Also, it was never really clear that, in the end, a microkernel would offer significant practical benefits over what could be accomplished (with less work) within one of the established non-microkernel OSs.

0xbadcafebee 2y ago

Linux wouldn't really exist today if it wasn't for GNU Hurd being a microkernel. It took so damn long for Hurd to become stable that nobody wanted to use it. But people did want to use the GNU tools. So Linus made the Linux kernel a simple monolith, shipped it quickly, integrated patches quickly, and everyone started using it. By the time Hurd was stable, Linux was popular. So microkernels are hard and monoliths are easier, and the first one to the party tends to stick around the longest.

wslh 2y ago
Based on your comment and this question [1] I wonder how well GNU Hurd runs the open source stack and what problems you will find in the road (e.g. GPU support). I really like the approach of separating, in some way, the kernel, from the user space and interchange them but why you would do that, except for playing and research, if the kernel doesn't give you an advantage and it just an alternative? [1] https://unix.stackexchange.com/questions/282046/can-gnu-linux-software-run-on-gnu-hurd https://unix.stackexchange.com/questions/282046/can-gnu-linu...
- RobotToaster 2y ago
  > what problems you will find in the road (e.g. GPU support). My understanding is it can't really run on actual hardware at all in it's current state, it's mostly run virtualized.
- yjftsjthsd-h 2y ago
  On the software side, it's passable; as that post notes, there's a Debian spin on HURD that's basically functional. In practice, though, GPUs are the least of its concerns; AFAIK, HURD still doesn't support USB:( > I really like the approach of separating, in some way, the kernel, from the user space and interchange them but why you would do that, except for playing and research, if the kernel doesn't give you an advantage and it just an alternative? Well I think a lot of it is that we thought it would be easier; in theory, separating concerns and putting drivers in userspace sounds like it should make it a lot easier to write the OS. That didn't really turn out, but it seemed like a good idea at the time. On the more practical side, microkernels can have security and reliability benefits (if drivers run in userspace, they have less access to exploit, and crashing a driver doesn't crash the whole machine). I mean, diversity is also useful for its own sake, but there are more immediate benefits.

yjftsjthsd-h 2y ago

Very oversimplified answer: Microkernels still have a performance hit, end-users care more about performance than stability/security (at least at the ratio/margin in question), therefore we use the faster monolithic kernels for most user-visible systems, with carve outs where the performance hit isn't so bad (hence NT/Darwin really being more hybrid now, and even Linux can do some drivers in userspace). As other comments note, this only applies to places where performance matters; lots of embedded systems do in fact care more about reliability than performance so the outcome is different.

nimish 2y ago

Linux has more microkernel features than you'd think. You can run all of networking, filesystems, HID and more in user space with BPF/Fuse. What else is left?

anyfoo 2y ago
By that measure, a passenger bus is a modern sports car, because you can lower its suspension to be close to the road at the push of a button…
- perihelions 2y ago
  (That's a feature for helping wheelchair-type passengers board at ground-level without assistance—just to explain for those who live in places without public transit).
  - renonce 2y ago
    Thanks for the explanation. I live in a place with lots of public transit but no suspension in any passenger bus. Fortunately I've been to the US before so I now know what it is.
- renonce 2y ago
  From wikipedia: > A sports car is a car designed with an emphasis on dynamic performance, such as handling, acceleration, top speed, the thrill of driving, and racing capability. How would lowering suspension turn a passenger bus to a sports car?
  - anyfoo 2y ago
    That’s my point.
- nimish 2y ago
  Well, what are we missing if networking, file systems and human IO are now run as user space servers? Process management? Graphics (ignoring X)? What low-level hardware interaction can't be done microkernel style? It's a bad analogy unless the button makes the bus change Transformers style into a completely different car.

pclmulqdq 2y ago

New OSes that have come out are pretty much universally microkernels. Fuchsia from Google is on a lot of their devices, and is a microkernel. SeL4 and QNX are microkernels for security and safety critical devices. I believe that Firecracker from AWS is also sort of microkernel-like (but pretends to be Linux). If you are building the device, the kernel, and the software, chances are that you are using a microkernel in 2024. Windows and the Unix OSes just have a lot more market penetration, strong network effects, and a big first-mover advantage. That means that when you are buying your OS or your hardware or your software, you're probably stuck with a monokernel.

RetroTechie 2y ago
Let's hope monolithic kernels are indeed an historical artefact, and over time microkernels will replace them in most popular OSes. A few % performance hit? (if that) Who cares. Security & reliability is where it's at these days.
- Xarodon 2y ago
  Lots and lots of home users care more about the few % of performance than the nebulous "extra security". I have friends who use their desktop for gaming only, literally nothing else, I guarantee they don't care about the extra security a microkernel claims to offer.
mike_hearn 2y ago
Firecracker is a hypervisor, it pretends to be hardware not Linux.

23B1 2y ago

1. There is value in 'central control' several reasons; - the people required to work on it - in a timely fashion - in a coordinated fashion - the resources required - bugs, updates, maintenance 2. The competition for aforementioned talent 3. The competition for aforementioned resources 4. Profit motive

sdwr 2y ago
Had to scroll a long way to find this, I suspect this is far more important than any technical issue. Having an "owner" is a strong incentive/coordination point to get stuff done. You need the right owner, but the 95% of projects that don't get it right, we don't hear about. We hear all the time about how code structure mirrors org structure. A distributed project encourages fiefdoms, a centralized one asks for a taskmaster with final say.
- anyfoo 2y ago
  And what prevents a microkernel from having the exact same owners as a monolithic kernel, working on the exact same things? This isn't web development, where "microservices" came up as a way to distribute complex software across stakeholders. There are very hard purely technical reasons for (or against!) microkernels, and the majority of microkernels (if not all) are still released and distributed in a "monolithic" model, i.e. an update distributes all components of it (modulo delta updates, which is also just a technicality).
  - 23B1 2y ago
    > And what prevents a microkernel from having the exact same owners as a monolithic kernel, working on the exact same things? Nothing inherent to the software is preventing anything. You could be right about the technical justifications. But OP's question wasn't "which is better?" it was "why?"
    - anyfoo 2y ago
      I am addressing the “why” that you both claim. The person I replied to said, I quote: > A distributed project encourages fiefdoms, a centralized one asks for a taskmaster with final say. What does the distinction between microkernel and monolithic kernel have to do with whether the project is “distributed”, or whether it is a “fiefdom”?

nottorp 2y ago

Because if the difference is still meaningful, the monolithic kernels are good enough?

PmTKg5d3AoKVnj0 2y ago

[flagged]

ganbatekudasai 2y ago
I’m going to venture a guess that you haven’t ever applied a single patch to any existing operating system, and that your knowledge of operating systems is pretty much based entirely on your experience as a user of them.
sdwr 2y ago
Makes more sense than "because they're 5% faster than microkernels"! That would also explain the current crop of microkernels - once the tech has been ironed out, architecture isn't life-or-death anymore.

freedomben 2y ago

Definitely read up on the Torvalds/Tanenbaum debate as there are lots of moving pieces and interesting theories. My opinion summed up ridiculously concisely is that the reasons are largely accidents of timing (i.e. there was room in the market for new entrants), mixed with trivial-at-the-time but high-impact choices. Had Tanenbaum been permitted by his publisher to give away copies of minix freely, Linux may never have been started at all. Had Tanenbaum chose raw performance over teachability (the kernel was a teaching tool after all), it may have made a difference. (warning: this part is controversial) There's also a lot of question about whether the GPL licensing kept Linux relevant, or if it was largely inconsequential. My opinion is that GPL made a big difference. Had the licensing of Minix been GPL flavored, it probably wouldn't have been used by companies like Intel for the Management Engine, but there might have been enough "forced sharing" to keep it relevant. Impossible to say for sure, but that's my two cents.

gwd 2y ago

For one thing, writing things in a microkernel are far more complex. In theory the isolation can mean lower impact of bugs and security issues; but in practice, the complexity means more bugs which are harder to debug. That's why you don't really see microkernels outside of embedded use cases -- the lower functionality requirement makes the complexity manageable. You can write a rocket OS as a "proper" microkernel, but there's no way you could write a full-blown Windows OS as a "proper" microkernel. That said, Windows or Linux can take leaves out of the microkernel playbook and apply them judiciously: KVM's architecture is arguably an example of this, where the core kernel does only the minimum necessary, and everything else is pushed to the user-mode component (QEMU, Firecracker, etc).

stracer 2y ago

Monolithic systems allow their authors much greater control over software that runs on computers.

anyfoo 2y ago
Again, absolute nonsense. Microkernels were designed for entirely different reasons than microservices. There are hard technical reasons for and against them, and most, if not all, microkernel OSes are still distributed in a rather monolithic model, not piecewise.
- stracer 2y ago
  Where did I mention microservices? How does the fact current microkernel OSes are being distributed using a monolithic model imply my point is nonsense? A real microkernel OS with stable interfaces would mean its developers do not want control of all the kernel-like servers, and allow even basic users to easily install and use many alternative user servers, as opposed to Linux kernel services sanctioned and controlled by the Linux distribution kernel maintainers.
  - anyfoo 2y ago
    Those things are completely orthogonal. A microkernel can arbitrarily restrict what user servers are viable (for example just the ones it ships with), just like a monolithic kernel can arbitrarily restrict what loadable kernel modules are viable (for example just the ones it ships with).
    - stracer 2y ago
      A compiled microkernel can restrict, I agree. But if you want to restrict, why would you do a microkernel. It's much easier to justify with a monolith. One big point of making a microkernel as opposed to making a monolith is that you want to give other developers more freedom to develop, distribute, fix bugs on their own time schedule, while keeping compatibility with new kernels easily. In other words, not wanting to control what and when they do, and what users run on the kernel. Monolithic kernel like Linux, with its constant stream of little changes in interfaces, creates problems for developers of modules, and this leads to selection - those who keep up and satisfy the kernel requirements get in, those that don't keep up or do not satisfy requirements, can't get in, and are degraded to developing against some old kernel version. This is a kind of control.

renonce 2y ago

Is Linux really a monolithic kernel? I mean yeah for most use cases such as desktops and servers it is but there's nothing preventing you from disabling most of its features and drivers and keeping a very minimal core (I'm sure lots of embedded Linux does this) and you can, right now, make it act as a microkernel by putting any component in userspace, mounting filesystems and devices via FUSE and networks via TUN, at its current state. Now the question becomes why these components are built in the kernel and not in userspace? The answer is clear for each individual component. See how the in-tree NTFS driver eventually replaces NTFS-3g. Basically when an in-tree solution exists it just gets preferred over userspace solutions because of performance and reliability etc.

anyfoo 2y ago
Making a monolithic kernel slightly smaller does not make it a microkernel. And those userspace fs and tun drivers still build upon VFS and an entire network stack as part of the monolithic kernel.

fsflover 2y ago

According to Qubes OS, they are not realistic today: https://www.qubes-os.org/faq/#what-about-safe-languages-and-formally-verified-microkernels https://www.qubes-os.org/faq/#what-about-safe-languages-and-...

squarefoot 2y ago

Because microkernel was born in an era when cpu cycles were precious and albeit minimal, the difference in performance would be noticeable. Also, back then there were no security reasons to choose one over another; those were the days of NNTP and unencrypted email, and the web didn't even exist. I can't comment about other OSes, but in the case of Linux, when microkernels became stable enough, Linux had already taken over and was already running from supercomputers down to embedded systems (also 8088 based ancient hardware if one also counts ELKS). As of today, in my opinion, the biggest obstacle are device drivers; that's the biggest battleground that determines the success or failure of an OS. Linux runs pretty much everywhere and where hardware manufacturers stubbornly refuse to document their hardware, there are thousands of developers around the world spending time and money to reverse engineer closed drivers so that Linux can support more hardware. Of course once they're written they can be ported to other OSes, but that requires more time and more people devoted to the job.

mike_hearn 2y ago

Nobody actually wants microkernels. Remember that the microkernel design is just a pessimistic mitigation. It assumes code will be crashy and full of exploits forever, and that it's worth significantly complicating the design as well as sacrificing performance to try and mitigate that. If you're making an OS you could invest resources into micro-kernelling everything and then trying to resolve the many hard problems and bugs that mitigation itself creates, or you could just .... fix the bugs! Kernels aren't infinitely large and the latter is actually much preferable if you can do it. Some kinds of code are inherently in the core failure domain and trying to use restartable processes for them is impossible. For example if the code configuring your PCI controller crashes half way through, well, you need to reboot. You can't just restart the driver because you have no idea what state the hardware is in. A reboot gets you back into a known state, a server restart doesn't. Likewise if your root filesystem server segfaults, you can't restart it because your process start code is going to involve sending RPCs to the filesystem server so it'd just deadlock. Finally, it's a spectrum anyway. Microkernel vs monolithic is not a hard divide and code moves in and out of those kernels as time and hardware changes. The graphics stack on Windows NT started out of kernel, moved into the kernel, then moved back out again. In all OS' the bulk of the code resides in userspace libraries and in servers connected via IPC.

kazinator 2y ago

In the world of Linux, "micro-kernel-like things" are done when they are beneficial. An example of this is FUSE: filesystems in user space. There is a benefit to being able to run a filesystem in its own address space as a user process, so it is done. Also the model of a Unix kernel with services (daemons) in user space is kind of similar to the microkernel model. The graphical desktop is not in the kernel, the mail server isn't in the kernel, crond isn't in the kernel, the web server isn't in the kernel, the database server isn't in the kernel ... and maybe that's as close as we need to get to the microkernel. Speaking of web servers in user space: at least for serving a static page, it's faster for that to be inside the monolithic kernel, where it can access the protocol stack and filesystem code without crossing a protection boundary. Over the history of Linux, we have seen experimentation both with moving kernel things into user space (like with FUSE) as well as user things in to the kernel (TUX server, now evidently unmaintained).