I'm sorry, I don't see the point here. As others mentioned on the thread, you praised OpenBSD, which is just as monolithic. It's a pretty common opinion that

I'm sorry, I don't see the point here. As others mentioned on the thread, you praised OpenBSD, which is just as monolithic. It's a pretty common opinion that the *BSDs are better architected as a whole unit and maybe a bit more care is taken with evolving kernel interfaces and so forth. I share that opinion. But what I don't understand is that you are unwilling to see where Linux has done something well, and cite the monolithic design as the critical flaw. We have your counter example of OpenBSD (monoliths done well) and we even have some examples of good design in Linux (lock-free path caching in VFS). Linux, despite criticisms that you or I may have, is thriving pretty well in many domains as well, so I might be tempted to say the proof is in the pudding. I still cite Windows NT as a microkernel design gone wrong, though I wouldn't confuse that as an inevitable property of microkernels. I am ex-MSFT by the way and have seen NT kernel source, and used to work on a filesystem driver there in 2008-2011. The NT I/O manager is this "message-based" thing, but the design that emerges from it is much worse than what Linux has, and the relatively bad I/O performance is a result. [In WSLv2, they opted to run a Linux kernel in a VM, rather than fix the inevitable performance consequences of the NT I/O design choices. The bad I/O performance of NT was specifically cited as a rationale for forking and embedding Linux.] It is actually a good example of how "microkernel" type thinking gives a poorer result if you are not careful about the big picture.