Interesting how reliability is measured in the context of OS kernel? Also I'm sure someone took a look to the QNX source code to understand which technics were used to achieve that.
Since code is available but not opensource, perhaps someone even re-implemented those ideas. Are there any good up to date source on the subject ?
Reliability of an OS kernel is measured exactly the same way as any other complex piece of technology: you note how often it does not do what it should do. In the case of a large QnX deployment over all the time that I worked for the company involved (several years), 0 incidents that we could attribute to the QnX kernel (or even any part of QnX).
If something didn't work it was either hardware or our own code, the way it should be. It's not magic but it is very good at what it does. And it is a way of building things that just works, message passing is a very powerful technique for making reliable distributed systems.
> Reliability of an OS kernel is measured exactly the same way as any other complex piece of technology: you note how often it does not do what it should do.
To me this sounds a bit funny - isn't the whole point of microkernel architecture that you achieve the reliability by simplifying the kernel - it's a less complex piece of technology, so it can be more reliable, and the complexity is offloaded into user space processes.
Yes, it does not do what it should not do, because it does less.
A microkernel is simple but the whole OS is not and when you have all the lines counted a micro kernel + associated programs will be about the same complexity as a macro kernel + associated programs.
It's just that with the microkernel more of the code will be in stand-alone programs. Every driver, file system, network layer and so on will be a program all by itself.
Exactly my point. Now, the interesting question is whether you have a smaller total number of bugs, and amount of impact, with this architecture or that architecture. I don't know about that, but if you are measuring the reliability of microkernels "exactly the same way as any other complex piece of technology", you must keep in mind that you are probably measuring the behaviour of a smaller and simpler thing, and the risk for bugs has been offloaded somewhere else, it has not disappeared.
You have a much smaller number of bugs because (a) each component is much simpler (b) runs as a separate process and so can be debugged and worked on by mere mortals and (c) works using a well defined interface (message passing) which makes testing and debugging a much simpler affair.
And Minix isn't a micro kernel in the same way that QnX is.