A talk with Paul Leroux
Networked Clusters: The QNX RTOS is inherently network-distributed, so you can partition an application across any configuration of loosely coupled nodes, without need for network-specific code. Applications don't need to `know' whether they're talking to each other on the same processor or across the network; they simply pass messages to each other using standard POSIX functions, and the QNX C library takes care of the rest. This has some pretty interesting ramifications. For example, say you have a home network consisting of several connected appliances. If one appliance has an Internet connection or a Web browser or flash memory or an MP3 archive, whatever, then any other appliance could access that resource automatically. No user configuration or special networking code required.
SMP: With conventional Unix-style OS architecture, SMP often demands numerous performance-robbing modifications to drivers and kernel code. With QNX's microkernel architecture, however, SMP requires only a few tiny changes to the kernel. Better yet, all other multithreaded processes--drivers, applications, databases, file systems, etc--can gain the performance advantages of SMP without modifications. (Refer to image given below)
With QNX's microkernel architecture, drivers, protocol stacks, and OS modules can migrate from a single-CPU device to an SMP system - or be distributed across a network of loosely coupled devices - without recoding.
Easier driver development: With QNX's microkernel architecture, most OS-level services (drivers, file systems, and so on) exist as user programs that run outside the kernel, just like regular applications. As a result, developing drivers and OS extensions (e.g. custom file systems) doesn't require kernel programming or kernel debugging. Instead, you use standard source-level tools and techniques. Better yet, QNX lets you test changes in driver code without kernel rebuilds or system reboots: simply recompile and restart the driver. Great for productivity.