The QNX Neutrino RTOS (from now on referred to as simply "QNX") was designed to facilitate in the development of applications for the embedded market; developers can write and build applications on their 'normal' machines using the same microkernel that the developers will use for their devices.
Merits Of The Neutrino
QNX is an operating system based on a true microkernel design. Microkernels are the opposite of monolithic kernels; instead of having all functions, drivers, filesystems and so forth inside the kernelspace, microkernels keep them outside of kernelspace, in userspace. The advantages a microkernel has to offer over a monolithic kernel are therefore quite obvious; one can replace and restart drivers, filesystems and so forth on the fly, without having to shutdown the entire system. Also, when part of the operating system crashes, it does not bring down the entire system, because the crashed part is outside of kernelspace. Theoretically, QNX could run without any downtime for ages and stay up-to-date at the same time. You can imagine that such a fault-tolerant, crash-insensitive design is very important in mission critical situations; and this is indeed the case. QNX powers all sorts of devices; ranging from hospital equipment (such as MRI scanners) to parts of the International Space Station, to in-car multimedia devices. Now that's scalability! Another major advantage of a microkernel design is simplicity; since the operating system is 'chopped' into smaller parts running in userspace, it is supposed to be easier to maintain and easier to program. In the early days of the microkernel, people also expected it to be faster and more efficient than a monolithic kernel.
Do all these advantages sound too good to be true? Well, simply put: yes, they indeed sound too good to be true. If not, all operating systems would be using microkernels today. I can explain the main drawback of the microkernel design with a very simple illustration (with thanks to CTO):
"Thinking that microkernels may enhance computational performance can stem but from a typical myopic analysis: indeed, at every place where functionality is implemented, things look locally simpler and more efficient. Now, if you look at the whole picture, and sum the local effects of microkernel design all over the place, it is obvious that the global effect is complexity and bloat in as much as the design was followed, i.e. at every server barrier. For an analogy, take a big heavy beef, chop it into small morsels, wrap those morsels within hygienic plastic bags, and link those bags with strings; whereas each morsel is much smaller than the original beef, the end-result will be heavier than the beef by the weight of the plastic and string, in a ratio inversely proportional to the small size of chops (i.e. the more someone boasts about the local simplicity achieved by his microkernel, the more global complexity he has actually added with regard to similar design without microkernel)." (Source)
Now, this clearly explains the drawback of the microkernel design: a microkernel design inevitably gets heavy and bloated (contrary to what the name 'microkernel' implies), thus reducing its speed-- simply not acceptable for everyday users. QNX, on the other hand, feels everything but bloated and sluggish, and that is probably also why it is one of the current market leaders in the embedded world. Now, why does QNX' microkernel (named 'Neutrino') seem to perform better than other microkernels? This is where it gets really technical, and I can not give a crisp explanation, since I am not qualified. My technical knowledge is simply too limited. A post by Bernd Paysan, though, in alt.os.multics explained why QNX performs better than other microkernels:
"[...] Unix's syscalls all are synchronous. That makes them a bad target for a microkernel, and the primary reason why Mach and Minix are so bad - they want to emulate Unix on top of a microkernel. Don't do that.
If you want to make a good microkernel, choose a different syscall paradigm. Syscalls of a message based system must be asynchronous (e.g. asynchronous IO), and event-driven (you get events as answers to various questions, the events are in the order of completion, not in the order of requests). You can map Unix calls on top of this on the user side, but it won't necessarily perform well."
QNX' applications do exactly what Bernd Paysan concludes-- "[...] if you design the application to use [QNX'] message passing APIs, it will work well." (I got this information from Christopher Browne's Web Pages, under "3.2. The Fundamental Challenge of Microkernels")
There is a lot more info on microkernels to be found on the internet. If you enjoy discussing matters such as proprietary vs. open-source, PPC vs. x86, GUI vs. CLI and so on, you will certainly find the microkernel vs. monolithic kernel discussions extremely interesting. A must-read on this subject is the classic discussion between Andy Tanenbaum (creator of Minix) and Linus Torvalds (creator of the Linux kernel). With Andy Tanenbaum being a proponent of the microkernel, and Linus Torvalds being a supporter of a monolithic design, all the ingredients were there for a very interesting 'flamewar' (according to 1992 standards this was very much a flamewar). An extract of this discussion, held in comp.os.minix in 1992, can be found here. Even if you are not interested in microkernels, it is still a good read. Especially the attitude towards the future of the Intel platform would prove to be... Sort of wrong.
So far for a short description on the merits of the microkernel, with the Neutrino kernel in particular. I strongly believe that a lot of people have a lot more interesting things to say about this subject than I do, seeing my limited knowledge on kernel design. Therefore, please feel free to correct me.
I now wish to move on to the actual goal of this article: how does QNX perform as a desktop operating system?