| You describe microkernels are if there is only one way to implement them. > A different process can just ignore your message > arbitrarily get stuck on something and not act in time This doesn't make sense. An implementation of a microkernel might suffer from these issues, it's not a problem of the design itself. There are many ways of designing message queues. Also: > In a microkernel, there can't be such trust [between processes] Capabilities have solved this problem in a much better and scalable way than the implicit trust model you have in a monolithic kernel. Using Linux as an example of a monolith is wrong, as it incorporates many ideas (and shortcomings) of a microkernel. For example: how do you deal with implicit trust when you can load third-party modules at run-time? Capabilities offer much greater security guarantees than "oops, now some third-party code is running in kernel mode and can do anything it wants with kernel data". Stuff like the eBPF sandbox is like a poor-man's alternative to the security guarantees of microkernels. Also, good luck making sure the implicitly trusted perimeter is secure in the first place when the surface area of the kernel is so wide it's practically impossible to verify. If you allow me an argument from authority, it is no surprise Google's Fuchsia went for a capability-based microkernel design. |
It’s design largely failed at being a modern generic operating system and it’s become primarily an os used for embedded devices which is an entirely different set of requirements
It’s also not that widely used. There’s only a handful of devices that ship fuschia today. There’s a reason for that.