I think that everyone reading OSAlert will have heard at least something about QNX. You can regard this article as an introduction, but also as a review, and as a “Is-QNX-Ready-For-The-Desktop? article”. To start off, I put together a short explanation of the merits of using a microkernel. Let me start off by saying that QNX Software Systems (QSS) does not aim towards the desktop with their Neutrino RTOS.
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?
Getting QNX
For this experiment I used the QNX Neutrino RTOS 6.3.0, for x86. In order to obtain the Neutrino RTOS, you have to get the QNX Momentics Development Suite 6.3.0, the version which uses the QNX Neutrino as development host (one can also use Windows, Linux or Solaris as hosts). The Neutrino host version includes the QNX Neutrino RTOS, and this can be installed from the bootable CD. This all might seem very confusing, but remember that QSS’ main goal is not to let your run the Neutrino kernel on your desktop.
You will have to sign up here, then go to the download center, and then select the “Product Evaluation”-link. Once there, sign up for the “QNX Momentics Professional Edition – Evaluation”. Do not let this fool you- it is not the Neutrino RTOS that has been restricted to 30 days of use; it is the QNX Momentics Development Suite Professional Edition (running on top of Neutrino) that is restricted. Which makes perfect sense, since without this suite, developing software based on QNX for your device is pretty hard. The operating system (and its applications) will not expire.
Installation
The specifications of my test system are as follows:
I burnt the 512 MB .iso file onto a CD-R using Toast, a Macintosh burning program. The burn went fine. I put the CD into the DVD drive, and rebooted my computer. It correctly booted from the CD, it scanned for hard disks, and then it would hang, stating that it could not find any space to install QNX on. This was rather peculiar, since I had 16 gigabytes of unformatted space on my hard disk. This error did not occur when I installed QNX 6.1/6.2, on the same hardware, a long time ago (I am rather happy with my current x86 setup; it works with basically all operating systems, so I am not keen on changing it).
After several reboots, I looked up OpenQNX, and after a forum search I quickly discovered someone else with the same problem. I have the advantage that 6.3.0 has been out for a while now, and therefore I can rely on others for solutions to my problems. This particular person solved the issue by doing a forced installation, from the boot menu, accessible by pressing space during bootup. It indeed worked; I was now ready to install.
QNX’s install procedure is very easy to use, text-based, but lacks any advanced features seen in, for example, several Linux or BSD installation programs. The first option it presents you with is whether or not to use verbose (debug) mode, and seeing I was not interested in doing any debugging, I chose ‘no’. After selecting ‘no’, it asked for my license key, which was sent to my email-account after signing up for the evaluation. I entered the key, agreed to the EULA, selected my hard disk as target for the installation, and enabled support for large disks. Then I selected the installation source, and the very basic partitioning tool loaded. The partitioning tool is basic because you can only delete a partition, or create a QNX partition. The creation of partitions is rather odd, since you can only select preset sizes; if you have 16 gigabyte free, you can select to create a 16 gigabyte partition, or a 8 GB, or 4 GB and so on. That is something advanced users will not like, but I must say that I like it. The easiest thing to do is just to install QNX as the last one in your multiboot setup, letting it fill up the remaining space on you hard disk.
After confirming I wanted the QNX partition to be 8 GB in size, the actual installation started. And this is where I encountered a second error: install was unable to mount the QNX disk. I am pretty confident that QNX is not the one to be blamed for this one; my DVD drive (LG Electronics) has had minor issues before, and therefore I am willing to give QNX the benefit of the doubt on this one. I simply restarted the installation, but this time using my CD-R(RW) as source drive. All went fine this time.
After the main system was installed, the installer asked me wether I wanted to install the various optional components of the development suite; I installed all these options. To install only the QNX Neutrino RTOS, without the Momentics Development Suite, do not install all these optional components. Next up was bootloader installation. Just like QNX’ partitioner, the bootloader is also extremely Spartan, and only able to boot four partitions (no support for extended partitions). Luckily QNX can be booted by any bootloader (BeBootMan, Grub, Lilo) without much work. Simply pointing your bootloader to the QNX’ partition should suffice. After this, the installation was completed and I was asked to remove the installation media and reboot.
Photon MicroGUI
If you come from a Windows/Linux environment, the first thing you will notice when booting into QNX is the short time it actually takes; about 11 seconds (from bootmanager to PhotonUI login screen). Personally, I find this very important; there is nothing that annoys me more than slow-booting operating systems.
The PhotonUI login screen has received a facelift since 6.2. You can now simply select a user, while in previous versions you could only enter a username/password. After logging in, we encounter the most impressive feature of QNX: PhotonUI.
PhotonUI has been designed with the same design principles in mind as the microkernel: highly modular. Just like the Neutrino kernel, Photon utilizes a small core, with most of the services it can provide located in optional memory-protected processes. The result is the same high fault-tolerance and modularity as provided by the Neutrino kernel.
Photon has a very good font manager, supporting multiple font formats, i.e. TrueType. QNX also supports font anti-aliasing. You can enable anti-aliasing in the fonts settings panel, located in the Launch/Configure menu. Because of the anti-aliasing, fonts on QNX look very crisp, as you can see in this screenshot:
A very distinctive feature of PhotonUI is its sidebar; it holds shortcuts to various applications, and plugins. These plugins include a CD-player, mail checker, a workspace manager, and a system monitor. This sidebar, ‘Shelf’, is configurable through an easy-to-use configuration program. The sidebar is quite vital, since PhotonUI does not support desktop icons, and therefore, if you do not want to dive into the Launch menu all the time, you will have to resort to the sidebar. As you can see in the following screenshot, the sidebar is divided into various sections that can be hidden:
Overall, PhotonUI is an amazing interface, with a clean and elegant design, and high consistency. PhotonUI also proves that a highly modular design can be very responsive and fast. In fact, I think that Photon is one of the most responsive UIs I have ever used, only beaten by BeOS’ Deskbar/Tracker. For me, it outperforms Explorer, Finder, KDE and others anytime, but, to be fair, this is just my opinion, and it is not based on any actual benchmarks.
Usage
This is of course the most vital part of this article. For QNX to be truly viable as a desktop operating system it must be capable of the following tasks:
Remember that this is just a selection of tasks; these are the things that I find important in a secondary desktop operating system. Your criteria may very well differ from mine.
Web browsing
Concerning browsers, QNX comes standard with Voyager (QNX’s native browser) and Mozilla 1.6. Voyager is a browser capable of using several engines; it uses Gecko as default. Voyager is Macromedia Flash enabled. Also, FireFox 1.0PR is available for QNX. Get it here. Here is a screenshot, showing off all three browsers, displaying OSAlert.com:
Email
QNX does not come with an email application pre-installed. Luckily, Thunderbird 0.8 is available for QNX, as well as several text-based clients. You can download Thunderbird here. I do not think Thunderbird requires an introduction.
Instant Messaging
QNX has various protocol-specific IM clients. Gaim is also available in the form of of a GTK+ port, but the versions available are pretty old (0.59 and 0.76), and therefore I recommend using the protocol-specific clients. However, there is no MSN client for QNX, so MSN users (like me) are left in the dark.
Word Processing
There is a native AbiWord port available for QNX from AbiSource (version 2.0.1). This port performs extremely well, and it would definitely satisfy word-processing needs for most people.
Easy Software Installation
This is one of QNX’ strong points: its package management system. It is repository-based, using xml. With the QNX Software Installer you can easily connect to any QNX Repository, in much the same way as you would surf to a website; you enter the location of the repository (i.e. ‘http://www.whatever.com/software/qnx/repository’) and the Installer automatically downloads all the necessary info. When selecting and installing a package, dependencies are automatically found and installed. Repositories do not have to be on the net; they can also be located on your harddisk or a CD-ROM. In fact, every package (i.e. AbiWord.qpr) is in itself a tiny repository. After installation, links to the programs are installed into the Launch menu, in the appropriate category. The obligatory screenshot:
Easy to configure
I find QNX and PhotonUI extremely easy to configure– but of course I realize that not everyone will agree with me on that one. I included a screenshot showing a few configuration windows. Judge for yourself:
Multimedia
QNX is fully equipped when it comes to multimedia; various formats are supported, and support for more formats can be downloaded.
Software
A desktop operating system needs more applications than the ones mentioned above. And that is, not surprisingly, one of QNX’ weaknesses. For instance, cdrecord has been ported to QNX, but there is no GUI front end for it. Another problem is that there is no graphical mounting available; CD’s will automount, but floppies will not. Furthermore, there are no means of accessing a digital camera.
On the other hand, there are also a lot of things that QNX does have. Full featured FTP client, IRC clients (both graphical and console), lots of audio players, ect. All sorts of software is available to QNX users. The ‘3rd Party Software Repository’ is pretty vast, and it is not the only repository around.
Hardware Support
Hardware support has always been a tricky thing for smaller desktop operating systems. We all know that for smaller projects it is extremely difficult to support all the hardware that is available to x86 users. For bigger operating systems like Windows and Linux it is less difficult; the companies behind the hardware will develop drivers for those operating systems themselves.
Still, QNX does quite well. All the hardware in my system was properly detected and configured, with no extra editing required. Of course it would be impossible for me to list all the hardware available. Luckily, QNX Software Systems provides an up-to-date, easy to use hardware compatibility list. Check for your hardware here.
Conclusion
It is very difficult to draw a conclusion on whether QNX is an operating system one can use on the desktop; mainly because of the fact that QSS does not even pretend to be making a desktop operating system. Vital functionality of a desktop OS are missing, like easy support for consumer USB devices, a CD recording application, native Email client, and more.
However, what makes QNX so interesting is the amazing potential it has. QNX is one of the most POSIX-complient operating systems; porting any *nix application should not take more than a recompile. Secondly, the availability of GTK+ 1 and 2 should also be noted. But most interesting of all is the comprehensive graphical development environment known as QNX Momentics. I really suggest reading up on Momentics, and the possibilities it provides, here.
Can QNX be an operating system for your grandmother? Well, if she is like my grandmother, who only browses the web and reads her email; then, yes. But if she requires anything just a bit more advanced, like CD-Writing, or digital camera access, QNX will not do.
Still, this does not mean QNX is useless as a desktop operating system. Especially if you want to try something completely different, with a different design, different internals and different goals than the more mainstream operating systems, then QNX will definitely be your game. I especially recommend QNX for ‘second’ systems– since it lacks features a main operating systems must have (in my opinion).
I happily used QNX 6.2.0 on my PII 366 laptop, which only featured 64 megabytes of RAM. It provided me with a full featured operating system, running at a very acceptable speed. I can surely recommend anyone with an interest in alternative operating systems to try out QNX– you will be pleasantly surprised.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSAlert.
“porting any *nix application should not take more than a recompile”
Claim something like that is stupid. You always end up in problems you did’t expect.
>porting any *nix application should not
> take more than a recompile”
QNX is one of the very few certified POSIX OSes. However, that doesn’t mean that any Linux app will or should compile out of the box. Older, Unix command-line applications, probably should be. But GUI or too modern Linux apps that depend on Linux-only features or other non-standard dependencies should not be expected to.
Never saw QNX in action, it is indeed very interesting. And it is free to use.
The size of gimp on QNX? 46Mb?? yikes~!
However… From the screenshots, it looks very clean and simple. might even take it for a spin myself
I tried to build some apps on QNX (like dotgnu pnet, uqm (sc2.sf.net), centericq), and they always worked after some tweaking.
P.S. QSSL was sold, so i beleive now QNX’s status is uncertain.
It was an older version (I don’t remember which version: the first freely downloadable version, which I have since uninstalled) installed on my laptop, that demonstrated something I didn’t expect or want: the inability to leave the system clock working in a consistent fashion!
Every time the screensaver was activated, it seems the system clock (time of day, etc.) was put on pause, since the computer then lost time for the amount of time the screensaver was active. I found this quirk extremely annoying, and inexcusable. I have no idea why they thought they had to do this. I don’t know if that was a stupid creation by the writer of that particular screensaver, or of the architect of the OS itself, but the net result had me needing to reset the date/time every time I rebooted.
BeOS has the opposite problem with *some newer* machines: the clock would run faster than it should. This usually happens when development is really at a stand still and no updates are made in a timely fashion.
QNX sucked as a desktop. To get new apps I started browsing QNXs site and found what I needed. Unfortunately Voyager is the most unstable piece of crap I’ve ever seen. It crashes, it crashes a lot, it crashes when you need it the most, and when it crashes it often takes QNX with it. There was another browser, I think it was Mozilla but I can’t quite remember. The problem with it was that it wasn’t integrated with the package manager the way Voyager was, so you couldn’t just click on a package and have Voyager install it over the internet. Then there where the apps, most of the apps for QNX are GTK apps, not native apps.
QNX was a catastrophe, probably still is, but if Voyager was fixed and some extra native apps where written it COULD be a nice desktop OS.
@Anonymous: when u only use ur os as a desktop os… i think there is no need for an open source os… but i guess you are using ur machine like me for developing software and for operating system research maybe… so then you would be absolutely right.
another issue: if a microkernel is better but slower when emulating unix we have a problem i guess… its very hard to tell people why they have to switch from unix to another system… because unix is just the thing we all know and love… and for me i guess event driven sounds like object oriented… and i dont wanna see it spreaded all over the kernel… then ne next step could be using c++ for kernel or worse… for example i find it not so easy to program for gtk+ in pure c because it looks like its not designed to be used that way, though its possible :-)) i dont know exactly what that gui builder stuff for qnx is… but i know i just dislike not coding the gui by hand…
The worst thing that may happen to QNX is the same thing that happened to BeOS. Although this seems to be very unlikely, this recent buyout and main GUI designer departure mean that QSSL doesn’t care anymore. And this is just gross! Because QNX has this charisma, that perhaps only BeOS (again) used to have… Everyone who used it and tried writing apps for it knows that. I wish someone with desktop-oriented business would have bought QSSL, not Harman.
@Jonathan Thompson:
QNX was a catastrophe, probably still is, but if Voyager was fixed and some extra native apps where written it COULD be a nice desktop OS.
No offence, but I found that post of yours rather much flamebait.Still, I reply, in order to make sure others do not fall for it. Voyager was indeed a lacking browser in the 6.1/6.2 releases, I will not counter that. BUT, Voyager, as it is now, is in my opinion a better browser than FireFox or Mozilla. Why? Well, because Voyager can use other engines as default. For example, one could also run Voyager with the Opera engine.
What I’m really waiting for is for someone to port webcore/khtml over to QNX
.
And how did you manage to bring the entire OS down with a crash of Voyager? That is highly unlikely. I’m looking forward to a more detailed description.
@Buck
The worst thing that may happen to QNX is the same thing that happened to BeOS. Although this seems to be very unlikely, this recent buyout and main GUI designer departure mean that QSSL doesn’t care anymore.
This is definitely something i’m afraid of as well. I don’ think it will happen any time soon, but if it happes, it won’t surprise me at all. The whole buyout happened during the writing of this article, so I didn’t mention it, for the sake of clarity.
I wonder if there is java, and eclipse for it running… Oh.. wait a minute
– QNX were the ones who did CDT (eclipse.org/cdt) for Eclipse.
That said, isn’t Momentics eclipse based?
Detailed, entertaining review. Nice one. Last time I tried QNX was, ooooh, when 6.2 came out — hugely impressed by the performance and slick GUI. The usual lack of drivers and native apps that afflicts most non-mainstream OSes, but still worth playing around with nonetheless.
Thom, or indeed anyone else running 6.3, is that decorator (ie titlebar and buttons) in those shots the default now? IMHO it looks horribly garish, and much worse than 6.2’s as can be seen here:
http://msa.section.me.uk/qnx-shot.jpg
Crisp grey buttons instead of those bright, loud OTT efforts.
Don’t get me started– I liked the “old” Photon theme better as well– but hey, progress is progress. The new theme does look more desktop friendly, and that’s exactly what I want: more people using QNX (and thus generating more attention, and therefore more developpers
).
But, yeah, the older decors looked better from a my viewpoint (being a GUI-consistency freak). For end-users, this is better IMO.
Whoa, talk about a screen hog – can that Shelf be moved around, or hidden?
“QNX. Because you feel the software library for Macintosh is too large.”
Yeah, that massive right-hand pane can be resized or disabled.
Shelf can be hidden.
Voyager can use opera’s engine (in the version i used back in the day *apr 2003ish*.. LoL)
http://www.killerstuff.net/ was a site from cdm who worked for qnx *think thats what his name was* who left the project (from what i hear)..
just wish i could get the 6.3 working for me..
i did use it as my main desktop for about 2 months.. and didnt have any problems or roadblocks.. such a nice lil desktop it was.. miss it a bit..
I tried QNX few years ago and i was really impressed. Even though the company make money, they don’t plan to make a DesktopOS.. that’s sad but it’s understandable, the embedded market is still huge and not dominate by Microsoft
Unexpected Surprise? A bit redundant, ain’t it?
From what I can gather, the QNX designers spent a lot of time deciding the best place to put functionality (whether the kernel, the ‘extra bit’ which I can’t remember the name of, or in servers) and normalising concepts to simplify implementing POSIX. A lot of good engineering has gone in to this OS.
Think a little bit about BeOS, Amiga before criticising someone refusing to use a “minor” closed source OS.
For these non-mainstream closed OS, there is a real risk that the parent company will close, loose interest, etc.. And that the OS goes into unmaintained mode, whatever the interest of the users..
With open-source OS, users have at last the additionnal possibility of becoming developpers or paying other to become developpers if they need some feature that don’t exist..
for QNX, which wasn’t mentioned in this review, is that it performs surprisingly well in low-end systems, PROVIDED that they have adequate RAM. OTOH, the versions of QNX that I used (6.1 and 6.2) performed very poorly when they had to do a lot of paging. ‘Course, that’s what you get when you try and run Mozilla on a computer with 32Mb of RAM…
I [heart] QNX and I think it would make a great “Grandma” OS because it can run on older hardware and is difficult to break.
It was mentioned in the final paragraph, but indeed, I did not emphasize it. I did not have the option to try QNX on a low-end system, so therefore I wasn’t sure as if 6.3.0 would also perform well on those systems. 6.2.x certainly does.
Thom, you really should be more careful! You quoted me saying something that someone else did, and complained it was flamebait!
Now, if what I wrote you considered flamebait, please, quote what I said that you thought was flamebait, not someone else!!!
Thank you
(and, considering that what I posted was observable fact on my system, without otherwise making any judgment calls on the quality of QNX or the company, is that truly still flamebait???)
Yeah you’re right! I’m sorry, I accidentally entered the wrong name! I stand corrected, it was “johnlein” who posted the flamebait.
Excuse me!
Have a look at QNX ! It runs better then all other X-OS. Forget the f…..g(sorry) KDE and whatever Desktop. All these
things are to slow. QNX is fast. Why not Unix/Linux?
The Photon micro GUI works faster then every windowmanager on x-window systems.
Mozilla and Thunderbird are not native programms. They come with there own GUI –> like the windows version
QNX6.3 new browser voyager2 works with mozilla rendering engine and looks like a QNX-application.It’s fast starting but it renders windows scrollbars and radiobuttons (in forms).
QNX will never be a desktop OS because the QNX company doesn’t want this.
“Then there where the apps, most of the apps for QNX are GTK apps, not native apps.”
Not too far from the true (sadly) .. however there IS some native apps … the main problem is that there isn’t enough developers for QNX …. nor users …
Interesting article. Thanks Thom:-)
The download is too slow. I am getting a 2Kbps.
>>porting any *nix application should not
>> take more than a recompile”
>QNX is one of the very few certified POSIX OSes.
>However, that doesn’t mean that any Linux app will
>or should compile out of the box. Older,
>Unix command-line applications, probably should be.
>But GUI or too modern Linux apps that depend on Linux-only >features or other non-standard dependencies should
>not be expected to.
Proving once again that Linux is not Unix.
It is its own animal.
thx – this was quite interesting…
christian
I used to use QNX as my desktop. Then I moved, and become one of the people that had the weird ‘modem disconnects after connecting to isp’ problem that (as far as I know) was never figured out or solved. I’ve been meaning to try it out again, maybe I will now. Since I hardly play games anymore, my windows partition could do with a format.
Do they have modern drivers for ATI and NVidia cards? I seem to remember graphic support not being up to date. If I’m mistaken, then forgive me!
I have some friends who used to work at QNX so I guess I’m biased in favour of the company. I always thought the OS was cool, but was disappointed that it didn’t take off and generate some more desktop steam. I think they tried, but they probably failed to make any momentum and stopped pushing in that direction. Which really is a shame.
Give QNX a 100% native email client, web browser (sounds like they almost have one) and you have a good start. I disagree with porting apps using the Gtk toolkit for example – I much prefer native apps.
Is it possible to install it on a less than 1GB partition? I read about the 16/8/4 GB issue, just wondering if i can put it on my tests partition
any hint appreciated!
PS: I tried the QNX floppy demo quite some time ago and it was very interesting, i had a working OS with X and modem detection and a browser… and all very _fast_
Yes it is possible. QNX doesn’t take much HD space. Once you have installed the base, you can then select some extra packages to be installed from a repository (on-line or in a CD).
When I was using 6.2, I only had about 300mb partition available for it …. Sure, it was a bit thight, but it’s depending on what you will be using it for.
jl
great! going to d’load it
thanks man
I tried QNX early this year and I was impressed that it was so zippy on my way old play-around-with box — and that it got my sound working right out of the box, no muss or fuss. Too bad the desktop’s so ugly and there’s a dearth of cool (Linux) apps that can be easily used with it.
“The size of gimp on QNX? 46Mb?? yikes~!”
That’s because it is statically linked with GTK rather than dynamically linked. Most Linux applications are dynamically linked, which means they rely on an already installed GTK runtime. However, if you were to statically link GIMP on Linux with GTK (so that it could run without needing GTK installed), you would end up with about the same size. Around 45 or 46 Mb.
from Thom Holwerda
>And how did you manage to bring the entire OS down with a
>crash of Voyager? That is highly unlikely. I’m looking forward
>to a more detailed description.
Voyager had the tendency to choke on webpages and die. One of those webpages was the QNX site itself. After Voyager died it left clipping fragments on screen and the OS slow. Sometimes logging out and then back in would resolved both problems sometimes only a restart would.
Yes, the version of QNX that I used was 6.2.
Tom, calling me recounting my encounter with QNX >> flamebait<< is insulting in my opinion. So pleas either watch your tong as you want others to or take it with a grain of salt.
hmm. i’m gonna have to give this a shot. i’m actually i never took a look at qnx before… photonui looks a lot like the mockups i’ve been making for years.
great article and a good read… thanks!
@ johnlein
It is most likely that you where seeing vserver spinning. Voyager is a client<->server application. The front end, voyager, starts a backend process to render the pages (vserver, opera, mozserver, …). So if you hit a page that caused vserver to hang up you could kill the app but still have vserver hanging around. A nice “slay -9 vserver” would do it for you.
There was also an issue in some versions of QNX where the font server could crash on some fonts/string combos. This made it look like the system crashed since the UI stopped updating (io-graphics had crashed). Such systems would still pass the numlock test and if you could telnet/ssh into the box, io-graphics could be restarted and the GUI would pop back to life.
I downloaded the QNX 6.2 eval, it installed some files to my hd but I couldn’t get it to run, all that I could start was a program that looked like it was a development environment. I tried rebooting and everything with no results or way to start the os.
//KDE and whatever Desktop. All these things are to slow.
//QNX is fast. Why not Unix/Linux?
//The Photon micro GUI works faster then every windowmanager on
//x-window systems.
AFAIK, This is due to two factors:
– the very fact Neutrino is a microkernel, and a microkernel designed for HARD REAL TIME: by this any task outside is potentially granted the possibility of satisfying required time constraints, so if the “user input -> update view” loop is given adequate priority, the kernel cant be blamed for lack of the UI’s responsiveness
– the fact Photon is not X11 compliant: by not having to support the (IMO unnecessary in a desktop environment) features X11 implementations support (though i notice x servers have added “local” improvements lately), it can afford being more optimized (if i’m not mistaken, it also embeds the toolkit) to minimize the “update view -> draw widget -> send command to Graphics card” sequence, thus reduceing latency and increasing responsiveness
qnx is good….i useit on my desktop os some times…..
QNX should be a lesson to you folks who claim that the client/server architecture causes X to be slow. Photon is even more client/server than X. The Photon core is a server, the font manager is a server, even the graphics driver is a server. All communicate via IPC. Yet, the GUI is quite responsive.
Hello there,
Citing the article:
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.”
If you read the “QNX System Architecture” document and took a quick look at QNX’s C library implementation, you would see that its read/write are just wrappers to MsgRead/MsgWrite. Message passing in QNX is fully _synchronous_ (if you don’t count those “enhancements” in 6.3, aimed primarily at better mqueue manager implementation): MsgSend will send the message to the channel and wait for the reply from the server. No buffering, no “callbacks”, and only limited usage of MsgDeliverEvent and signals.
And AFAIR, message passing in Mach is asynchronous (in contrary to QNX).
Great article Thom, very good reading. I’m gonna give QNX a shoot once more
In the release notes and other docs as well as the original announcement the ‘3D acceleration through hardware’ … “OpenGL acceleration” .. blah blah, well what I want to know is it accelerated through the CPU lol? Or is their [Mesa]GL acceleration actually supported through any of the video cards? I remember the Voodoo3 was the only one to have any real hardware 3D in the older versions, so please don’t just tell me that ok
Most likely I am thinking they only put the framework in to let developers WRITE the video drivers for real GL accel, but [hoping] maybe atleast some ATI cards have hardware 3D on it…
Anyone please clarify??
TYIA
I actually work with students on using QNX in an embedded course. I agree with most things that’s said but I have several things to add:
1. Photon in QNX4 is much more stable than 6. I saw numerous times that the whole QNX system froze. Without virtual consoles there’s no way to recover except for a reboot.
The cause is that poorly written application (by students) will bombard the IPC channels and prevent all other things from communicating. So in other words he microkernel can be an issue in itself. I have seen far too many hangs in recent days.
2. QNX, being a RTOS, actually uses a simple O(1) scheduler. What it means is that, if multiple GUI applications are run the performance would start to go downhill much faster compared to other *NIX OS.
3. On top of it all, security is never QNX’s strong point. It’s a development platform and can be easily hacked. For example, if the remote debug server is used, then any code that come in through remote debug would get root privilages, unless remote debug is run as a user process. In that latter case however, so many remote debug functions are disabled that it’s almost useless. There are many other exploits possible so I don’t think it’s a viable Desktop OS from that standpoint
As I said in the article– I’m no programmer, let alone a kernel programmer. So, you may very well be right about all this. I simply read a lot of documents and info pages on the web about this whole issue– but as said, I could very well be wrong here.
Maybe Chris McKillop could expand on this?
Interesting article, but why use QNX for the desktop?
QNX Neutrino is a RTOS. The normal desktop environment does not require a RTOS, and does not really benefit from it, or the microkernel architecture. RTOS are used where they are needed, embedded systems, mission critical system, and in special cases in some form of a desktop systems. QNX is not intended to be used on a normal computer, for normal use. Use Linux or MacOS for that instead.
QNX is not intended to be used on a normal computer, for normal use. Use Linux or MacOS for that instead.
All the more important to notify people about how good QNX performs at something it isn’t designed for.
target and philosophy of an RTOS: having a kernel capable of granting user applications to safely satisfy deadlines, temporal constraints
(One can also think a media player has to respect a time constraint: the next frame of an MPEG4 movie must be rendered within 40 ms, otherwise artifacts will be noticeable)
in a real time environment a situation as deterministic and predictable as possible is required , so the application must be allowed to preempt other applications with lower priority, and the threads generated by her in the kernel should preempt lower priority kernel threads (if any). to enhance the deterministic factor , virtual memory and paging is typically disabled: the application is constantly kept in memory (optimal case: application in cache), scheduling times are kept as constant as possible
(anyway, if the user application computation is algorithmically too complex to be feasible within the 40 ms, the application will fail, but it will be not the kernel’s fault , but of the one who didnt choose a better cpu or more memory)
With this said, RT concepts are also useful in the desktop world, because they can inspire the design of the OS kernel to achieve low or at least predictable SYSCALL latencies, and to design elegantly for kernel thread concurrency and mutual preemptability (unless the kernel has no services potentially interfering with RT user applications), and low overhead IPC
BTW, i believe IPC shouldnt be classified in “sync” or “async” only … QNX’s may be synchronous but this doesnt impede the OS’s being fully realtime supportive
Mach’s IPC is poorly efficient, because of an actual management overhead (one thing other OSs, for example DragonFlyBSD try to solve)
1. Photon in QNX4 is much more stable than 6. I saw numerous times that the whole QNX system froze. Without virtual consoles there’s no way to recover except for a reboot.
The cause is that poorly written application (by students) will bombard the IPC channels and prevent all other things from communicating. So in other words he microkernel can be an issue in itself. I have seen far too many hangs in recent days.
_Any_ application running in a tight loop at a piority higher then 10 will not let you use your teminal(s) which run(s) shell at priority 10. It is not an OS, it is “poorly written application” as you rightfully pointed out. The common practice is to run a shell session at a higher priority in order to be able to identify & slay “unfriendly” applications. So, the point is the OS does not hang actually.
2. QNX, being a RTOS, actually uses a simple O(1) scheduler. What it means is that, if multiple GUI applications are run the performance would start to go downhill much faster compared to other *NIX OS.
Care to elaborate on this?
3. On top of it all, security is never QNX’s strong point. It’s a development platform and can be easily hacked. For example, if the remote debug server is used, then any code that come in through remote debug would get root privilages, unless remote debug is run as a user process. In that latter case however, so many remote debug functions are disabled that it’s almost useless.
You are mixing up security of a development and a production system. I recognize a problem when you run a lab _development_ QNX server where you are running a debug agent and, thus, this system can be hacked. But that’s what firewalls for.
Hey, enjoyed the article. Just want to toss my 2 cents in. CenterICQ supports aim/msn/yahoo/irc/jabber/icq etc if you can handle a console based messenger client. You can grab it here.. http://windoze.doesntexist.com/qnx/ along with other apps/libs i compiled or ported. Also i believe MSN still works in gaim-0.76.
As for desktop usage, i’ve been using QNX as my main OS for ohh about 3 years now. It meets all my basic needs and then some. Its blazing fast, even during compiling now that fs-pkg has been removed from the latest release.
For me it’s more a hobby OS that turned fulltime OS as i got bored of win32 / BeOS (PhOS) / Linux / *BSD etc. Still have a multiboot machine with 7 OS’s on it, just rarely boot anything other than QNX. To each his own. Different users have different tastes. But if you havent tried it, do so. It’s a fun ride.
Is there an OS designed to use as little power as possible on a laptop, say, to make its battery last much longer than on Windows? Maybe this QNX would make a good low-power OS. If it can run off a floppy, it can run off a ramdisk & save to the internet. Hrmmm….
2. QNX, being a RTOS, actually uses a simple O(1) scheduler. What it means is that, if multiple GUI applications are run the performance would start to go downhill much faster compared to other *NIX OS.
Care to elaborate on this?
Sounds like the scheduler is similar to AmigaOS, simple priority based round-robin scheuler. Very simple and efficient and predictable provided you have minimal active applications.
If your apps don’t do huge amounts of background work, then this shouldn’t be an issue, but having several apps actively sharing the CPU can reduce responsiveness noticably, though tweaking priorities will resolve this (I used to let Imagine ray-trace on my Amiga in the background by dropping its priority to -1 so that any application I was actively ineracting with always had priority and there was no slow down to the user, though clearly Imagine would take longer to render…)
Of course, on the Amiga there were 3rd party schedulers you could plug in with minimal effort that offered more sophisticated systems.
I would not jump to conclusion that “QNX, being a RTOS, actually uses a simple O(1) scheduler.” FYI: to addition to FIFO (typical RTOS) and Round-Robin (typical UNIX) QNX also provides sporadic scheduling:
http://www.qnx.com/developers/docs/momentics621_docs/neutrino/sys_a…
The question only if you use it or not, QNX itself does not care.
Again, there is an application-centric approach (desktop market) where a designer assumes that OS will take care of her/his application(s). Unlikely desktop market, majority of real-time & embedded products shiped as a whole system and you are in full charge of it but also you want (and you have) a full control of system modules, including predictably behaving RTOS. QNX is no exception to that.
It is simply wrong to acuse QNX in lacking desktop features: it is not meant to be a desktop. QNX is just a self-hosted system which allows embedded & real-time developers also prototype their algorithms/solutions/applications w/o real target h/w but still having native OS, not sort of emulated. This feature (sure among others, equally important) wins many designs for QNX. Vmware+[Windows|Linux]+QNX is quite usual setup for a commercial QNX developer.
QNX is a great OS. It is a real time OS, and I have used it as one of the many OS’s that I tinker with. With just a little work it could flat out kick ass. Voyager is a moot point because both FireFox and Opera are available for QNX. Porting Linux apps to QNX requires nothing more than a recompile…period! However, drivers are another issue alltogether. That is where problems may arise. It seems that many here have never used QNX RTOS, thus you don’t hava a clue! Any Linux app can be ported to QNX with nothing more than a recompile, nothing more but you have to have the QNX compiler.
>Let me start off by saying that QNX Software Systems (QSS) >does not aim towards the desktop with their Neutrino RTOS
That is a crying shame, it really is! :/
A microkernal is the way to go, and the AmigaOS has such a kernal. I realize QSSL has the target of imbedded market, but with very little work QNX RTOS would be a fantastic desktop environment.
It looks like this new version of QNX won’t work under VMware – the error is can’t open /dev/par1, no such file or directory.
Bummer – especially since I don’t have 6.2 anymore.
OK, here’s a test – go grab all the GNOME 2.8 tarballs, compile ’em under QNX and show me a running GNOME 2.8 desktop, then I’ll believe you.
[/i]OK, here’s a test – go grab all the GNOME 2.8 tarballs, compile ’em under QNX and show me a running GNOME 2.8 desktop, then I’ll believe you.
[i]
Depends on how much Gnome relies on Linux specific features– if it doesn’t rely on any, it means that once all dependencies are provided, Gnome could compile.
Or am I talking crap now?
Egads. Why would you want the “bloat” of gnome on QNX? But i agree, not “all” linux apps are a simple recompile. Look at FreeBSD’s ports tree. All those applications sources had to be tweaked in order to compile, same goes for QNX. Linux applications arent 100% POSIX compliant, nor is linux itself.
Sure some basic console apps will build without a hitch, but try just about anything else and you run into problems. Granted not hard to fix, messing with makefiles and source code a tiny bit is about all it takes, but it still isnt as simple as untarring a src tree and compiling.
Also the quote about “having to have to QNX compiler” is false. I NEVER use QCC, never. Everything i’ve built was with GCC.
kind of a bummer since it means I need to boot windows to run it in a sandbox. It has both Voyager and Mozilla 6.3 for web browsing and has its own PPPoe dialer and DHCP so broadband connections should be a breeze.
It’s a bit slow running under emulation but that may be the fault of VirtualPC. I’ve used earlier QNX products including their OS-on-a-floppy and I’ve always been impressed.
Once I’ve freed up enough space, I’ll try a laptop install