| A reminder that monolithic- vs micro-kernel is a spectrum. You can achieve the benefits of microkernels incrementally, as both Android and MacOS/iOS are proving out -- by moving components into userspace piecemeal, over time. And you can reap the benefits of microkernel ideas in isolated domains. Apple is choosing to benefit from microkernel style userspace APIs for third party code in particular, because that's a very likely vector for security and stability issues. You simply can't know what degree of testing and safety practices are being employed by third parties, and their crash analytics almost certainly bear out that most system crashes happen there. Microkernels are not an automatic antithesis of performance. As usual, you have to make informed tradeoffs. Do you keep components X in ring 0, or not? And if you move it out, how do you design the interface between the two to try and mitigate the performance impact of that choice. In the case of Apple with MacOS, additionally, how do you develop the SoC in tandem to make the context switch cheaper? (Really, Apple's apparent competitive advantage from vertical integration between hardware and software is a farce. There was never anything stopping Microsoft from approaching Intel and AMD and working jointly on making the same kind of improvements at the hardware level for the benefit of the software. They just didn't care enough to do so.) That the industry gave up on microkernels is not a testament to them being untenable from a performance perspective. It's a testament to the laziness and lack of willpower to advance the state of the art because insecure and unreliable systems were good enough for their customers. The way our technology looks today is not some utopian extension of all the best ideas we've come up with so far. Choices like monolithic kernels coming to dominate is not evidence that they're a more fit solution. It's evidence that defeatism is the path of least resistance. When I see Apple do stuff like move to deprecate kexts, I take it as evidence that they give more of a shit about the quality and robustness of their software than the next guys. Meanwhile, we still have Windows forcing EDR components to operate in ring0 and bring down entire industries when a bug happens because they couldn't be bothered to implement a safe API for EDRs in which a memory safety issue -- which we are all acutely aware happen all the time -- won't crash the kernel. Windows tacitly enabling the Crowdstrike debacle by underdesigning known vectors of failure is not a blameless situation. Crowdstrike has taken more flack than they deserve here, because we've known about issues like this at the platform level, and Microsoft's competitors have even taken the time to fix what Microsoft couldn't be bothered to. Ideas like microkernels are what you get when people analyze the technical deficiencies in the state of the art, and then go and try to come up with solutions. Of course there's challenges. But that pure microkernels on their own are at a performance disadvantage compared to monolithic kernels is not because that line of thinking is a dead end, but because nobody bothered to put in the R&D to solve it. |
Regarding Microsoft, they tried a couple of times already, but IBM PC clones culture kind of kills most attempts. Latest one was UWP, with Windows S, Windows WinRT, Windows 10X all supposed to be this kind of approach.
Windows 11 initially was based the tech they could savage from Windows 10X, after it being cancelled.
If anything Crowdstrike has given them a powerful argument to tell OEMs, now the time is come.