QNX has a long checkered history as an embedded operating system. QNX was always famous for being a real time operating system with a microkernel architecture. That is, kernel functions run as a set of coordinated tasks instead of as a single piece of code. A recent release of QNX 7 (see video, below) allows it to run on 64-bit desktop computers and [elahav] decided to tackle turning this embedded RTOS into a desktop operating system.
That might sound far-fetched, but QNX is a POSIX-compliant system and has all the features you’d expect in a system like Linux or BSD. It just isn’t aimed at the desktop market and therefore doesn’t have a lot of tools for running the desktop. QNX isn’t the kind of RTOS you’ll find on an Arduino. It is more common in things like automobile systems (for example, it runs General Motor’s OnStar system).
He started with a mini ITX board and installed QNX. Usually, you develop for an embedded system on a workstation and then just ship the code over to the target system, but [elahav] took the time to get a build system working on the target. There was one problem. The built-in vi editor was primitive by modern standards. He is usually an emacs user, but even vim would be better than the “stock” vi. While an emacs port would be possible, it would also require porting over a lot of libraries, so his first project was to get the vim source code to compile.
Turned out not to be as easy as he had hoped. The build system expected certain GNU tools that didn’t exist yet (although standard versions of the tools, like grep, did exist). So he had to figure out how to cross compile vim. In retrospect, [elahav] decided he should have just ported the GNU tools first. He did have to remove some old code from vim that was aimed at an older version of QNX.
The rest of the adventure went fairly well. He managed to build SDL and port over some games. Qt exists on QNX, but with a setup that favors the embedded system (for example, everything shows full-screen). Building Qt apps was possible, but without a proper window manager, it still wasn’t the desktop experience he wanted. A few weeks later he managed a window manager. Keep in mind, QNX’s display architecture is not X, so grabbing an existing piece of code wasn’t a likely option.
Is it practical? Maybe, although we didn’t see the actual code available. Is it desirable? Probably not, unless you are using QNX already, and even then we aren’t sure. However, it is a great story of the kind of difficulties involved in making something offbeat useful, a problem we’ve mentioned before when you build your own CPU. Of course, [elahav] started with a pretty rich environment. If you want to see someone bootstrap almost everything, check out A2Z. And if you’ve been around awhile and think you remember another QNX desktop environment, you aren’t wrong.