Meanwhile, the world runs on QnX. The fact that you don't realize it and don't see it is testimony to its success.

I know that QnX is widespread, but far more devices run Android than QnX. It's a bit of a philosophical debate whether the software that runs most smartphones "runs the world" more or less than the stuff covered by QnX, but I'd say that's its a bit of a stretch to just give the win to QnX :)

But you're right, QnX is the one (probably the only?) micro-kernel that has seen widespread adoption. Almost all of it has been in the context of embedded systems, which doesn't invalidate the substantial success, but it does leave QnX as the exception that proves the rule. It also leaves QnX as yet another example of the general failure of microkernels as general purpose computing platforms. QnX design is excellent for the contexts where it is deployed, but there's a reason you don't run it on PCs, tablets, data crunchers, smartphones and many other sorts of computing contexts.

Lots of devices run on Android but that's because there isn't a valid alternative. QnX and it's brethren are used where failure is not an option.

I used it daily on my PC for years and it was hands down the best environment I've used with distance (mostly compared to IRIX, Windows and Linux). Super responsive, never locks up, no weird delays it just works, 24x7, year after year. The whole throughput argument never worked anyway, that was just Linus talking about something that he didn't have direct experience with, it's latency that is far more important than raw throughput in interactive computing because interactive computing is a real time task.

> "real micro kernel based OS based on a message passing core", and they too, by almost any metric, have been a failure.

BeOS wasn't half bad. The failure was probably mostly commercial. It is true that they moved their networking stack into the kernel, but it's not entirely clear to me that they had to do that, it was just the most expedient way to get acceptable performance and stability given the (programmer-time) resourcing constraints of the project.

> BeOS wasn't half bad. The failure was probably mostly commercial.

Fair point. You could probably say this of other attempted microkernels too, to be even fairer. But that doesn't really change the fundamental point that just cooking up "a better OS design" doesn't lead to it being successful. There's a lot more in play that "mere quality".

well if that sort of "successful" is your key metric, this is true for a lot of things and has been known since biblical times: "a person may labor with wisdom, knowledge and skill, and then they must leave all they own to another who has not toiled for it"

you did say "by almost any metric".

the metric i was mostly thinking was inspired by the parent to my post, which seemed to me to imagine that Rust+microkernel => widescale deployment.

BeOS wasn't a microkernel.

Depends on your definition of microkernel. Maybe it wasn't pure, but It was in many ways closer to a microkernel than a monolith; sure the filesystem ran in ring 0, but it was scheduled onto its own threads by the scheduler just like any other process.

I should have (and did) know better. Thanks for the reminder.

Mach is of course doing quite well and moving back towards being microkernel-y as hardware gets fast enough to support it and Apple needs a better security story.