That's nice, but late. QNX had that 10-15 years ago. With hard real time scheduling, too.
All you really need in a practical microkernel is process management, memory management, timer management, and message passing. (It's possible to have even less in the kernel; L4 moved the copying of messages out of the kernel. Then you have to have shared memory between processes to pass messages, which means the kernel is safe but processes aren't.)
The amusing thing is that Linux, after several decades, now has support for all that. But it also has all the legacy stuff which doesn't use those features. That's why the Linux kernel is insanely huge. The big advantage of a microkernel is that, if you do it right, you don't change it much, if at all. It can even be in ROM. That's quite common with QNX embedded systems.
(If QNX, the company, weren't such a pain... They went from closed source to partially open source (not free, but you could look at some code) to closed source to open source (you could look at the kernel) to closed source. Most of the developers got fed up and quit using it. It's still used; Boston Dynamics' robots use it. If you need hard real time and the problem is too big for something like VxWorks, QNX is still the way to go.)
QNX is fascinating on its own, but MINIX 3 is still a different project in that its full adoption of a NetBSD userland will probably make it more useful for generic servers and workstations as well. They also seem to be going much deeper with checkpointing and dynamic upgrades/hot code reloading.
If you need hard real time and the problem is too big for something like VxWorks, QNX is still the way to go.
There's all sorts of much tinier RTOS like FreeRTOS, MicroC/OS and Contiki that are used out there for particularly critical and/or constrained environments.
QNX has a big advantage in that from userland it's basically a Unix. You can develop on it completely self-hosted on a desktop PC. The GUI's pretty good; it even comes with Java and Eclipse.
They've downplayed that recently, alas, but I believe that if you hunt around on their website you can find a bootable CD. I think platform support has slipped a bit so you might have trouble making it boot.
Way back when, there was a QNX demo floppy, which was a bootable 1.44 MB floppy disk which contained a full GUI, web browser, dialup modem support, etc. It'd run on a 386 with 8MB of RAM.
Are you interested in this? I am planning to get the NetBSD rump kernel running on sel4 at some point soonish, not quite the same but you would get much of userland. (Email in profile).
> the most fundamental difference between VxWorks and QNX is as you have described, QNX lends itself to a message passing architecture while VxWorks lends itself to a shared memory architecture.
>
> My personal opinion is that a message passing architecture is easier to get to grips with and as such is potentially easier to understand and debug.
> However, the majority of software engineers with experience of an embedded RTOS will be very well informed about the Shared Memory architecture.
I think it's less of an issue now than say 10 years ago. VxWorks 6.x added support for protection domains (MPU/MMU support) and RTPs (real time processes). VxWorks 5 everything operated in the kernel. Even with 6.x very little typically runs by default in user space on a VxWorks setup.
With respect to the message passing - both support messaging. VxWorks has several types of message queues - vxworks proprietary msgQLib API, POSIX api etc. QNX has much the same MsgSend/MsgRecv which is the microkernel API and POSIX. QNX has an add-on PubSub middleware that the OP of the usenet group may be thinking of.
I'm watching the video now, but are you suggesting that QNX, which is not Free and Open Source, has already accomplished MINIX's stated goals of OS reliability?
I would like to hear Mr. Tanenbaum's answer to the less provocative form of the sentiment: "What design decisions were made with MINIX3 that other RTOS with microkernels didn't consider?"
Tanenbaum cited QNX in Round 2 of the microkernel debate between he and Linus. It's had all sorts of great traits for a long time. It also had plenty of development time and a rip-off open source model to give it capabilities. Like Tanenbaum said in his paper, Minix 3 has had a small amount of core developers working on it for a relatively short amount of time. There's no way Minix 3 will trump QNX with such small resources and I doubt they planned to. It's more a start on building something using better engineering principles that might eventually become a great alternative to other UNIX's and Linux.
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.
That's when it suddenly went from open source to closed source. One day, RIM removed the sources from the web and FTP servers.
QNX used to be a standalone company. They declined a buyout by Microsoft. Then one of their key people died, and they sold out to Harmon, the car audio company. So then they were heavily into automotive dashboard applications, which continues. Then RIM bought them, which gave the Blackberry a better underlying OS but didn't fix Blackberry's problem of an obsolete UI and business model.
Meanwhile, QNX still sells to real-time and industrial automation customers, but those customers feel kind of neglected. Incidentally, the Boston Dynamics robots all have QNX managing the balance and the hydraulic servovalves. You need reliable hard real time for that.
I don't really think that BBOS 10 has an obsolete UI. The Hub is actually really convenient and I wish more smartphones had something like it.
Blackberry isn't failing because of their OS, they're failing because they were way too late to market with robust smartphones and lost a huge amount of mindshare after Apple and Google ate their lunch.
Yeah they have huge problems which QNX itself can't begin to fix. Yet, the Blackberry Playbook (running on QNX) totally screamed in performance and responsiveness in the tests against the iPad. Showed how smart a decision they made to use a proper RTOS for their devices. I gave product manager props for the decision.
I think they should stick to their strong suit and build on strengths in business world. Collaboration, integration with legacy stuff, bake in more security than iPhone/Android, and so on. Build services on top of that like IBM does with all their stuff. And so on.
All you really need in a practical microkernel is process management, memory management, timer management, and message passing. (It's possible to have even less in the kernel; L4 moved the copying of messages out of the kernel. Then you have to have shared memory between processes to pass messages, which means the kernel is safe but processes aren't.)
The amusing thing is that Linux, after several decades, now has support for all that. But it also has all the legacy stuff which doesn't use those features. That's why the Linux kernel is insanely huge. The big advantage of a microkernel is that, if you do it right, you don't change it much, if at all. It can even be in ROM. That's quite common with QNX embedded systems.
(If QNX, the company, weren't such a pain... They went from closed source to partially open source (not free, but you could look at some code) to closed source to open source (you could look at the kernel) to closed source. Most of the developers got fed up and quit using it. It's still used; Boston Dynamics' robots use it. If you need hard real time and the problem is too big for something like VxWorks, QNX is still the way to go.)