Nobody actually wants microkernels. Remember that the microkernel design is just a pessimistic mitigation. It assumes code will be crashy and full of exploits f

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.