Linked by Thom Holwerda on Thu 18th Nov 2004 10:19 UTC
QNX I think that everyone reading OSNews 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.
Order by: Score:
yeah right!!
by Andre4s on Thu 18th Nov 2004 10:38 UTC

"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.

RE: yeah right!!
by Eugenia on Thu 18th Nov 2004 10:41 UTC

>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.

Good article
by juca on Thu 18th Nov 2004 10:42 UTC

Never saw QNX in action, it is indeed very interesting. And it is free to use.

woah.. anyone else see...
by Anonymous on Thu 18th Nov 2004 10:45 UTC

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 ;)

Andre4s:
by Ilyak on Thu 18th Nov 2004 11:07 UTC

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.

A warning about QNX for desktop use!
by Jonathan Thompson on Thu 18th Nov 2004 11:17 UTC

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.

RE: A warning about QNX for desktop use!
by Jon on Thu 18th Nov 2004 11:20 UTC

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.

v GPL
by Anonymous on Thu 18th Nov 2004 11:23 UTC
QNX desktop NO
by johnlein on Thu 18th Nov 2004 11:30 UTC

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.

open source desktop...
by Eugene on Thu 18th Nov 2004 11:37 UTC

@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...

So damn sad...
by Buck on Thu 18th Nov 2004 11:52 UTC

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.

RE: Various
by Thom Holwerda on Thu 18th Nov 2004 12:04 UTC

@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.

Nice article
by malkia on Thu 18th Nov 2004 12:08 UTC

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?

Good work Thom
by Michael Saunders on Thu 18th Nov 2004 12:14 UTC

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.

Question about window decorators
by Michael Saunders on Thu 18th Nov 2004 12:21 UTC

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.

RE: Michael Saunders
by Thom Holwerda on Thu 18th Nov 2004 12:25 UTC

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.

shelf?
by interested on Thu 18th Nov 2004 12:31 UTC

Whoa, talk about a screen hog - can that Shelf be moved around, or hidden?

Marketing Slogan
by Anonymous on Thu 18th Nov 2004 12:41 UTC

"QNX. Because you feel the software library for Macintosh is too large."

RE: interested
by Michael Saunders on Thu 18th Nov 2004 12:49 UTC

Yeah, that massive right-hand pane can be resized or disabled.

Lots...
by sn0n on Thu 18th Nov 2004 12:50 UTC

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.. :-x

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..

v Re: GPL
by helf on Thu 18th Nov 2004 14:10 UTC
v Hehehe
by Chris on Thu 18th Nov 2004 14:34 UTC
tried
by jeanmarc on Thu 18th Nov 2004 14:35 UTC

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

v Re: Re: GPL
by marcell mars on Thu 18th Nov 2004 14:38 UTC
Surprise
by Nathan Johnson on Thu 18th Nov 2004 14:53 UTC

Unexpected Surprise? A bit redundant, ain't it? ;)

v Re: GPL
by Lucas on Thu 18th Nov 2004 15:00 UTC
QNX Design
by Luke McCarthy on Thu 18th Nov 2004 15:08 UTC

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.

@helf
by renoX on Thu 18th Nov 2004 15:15 UTC

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..

v RE: Various
by Thom Holwerda on Thu 18th Nov 2004 15:16 UTC
another bonus
by int argc on Thu 18th Nov 2004 15:18 UTC

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.

RE: int argc
by Thom Holwerda on Thu 18th Nov 2004 15:23 UTC

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.

RE: Thom Holwerda
by Jonathan Thompson on Thu 18th Nov 2004 15:36 UTC

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???)

RE: Jonathan Thompson
by Thom Holwerda on Thu 18th Nov 2004 15:48 UTC

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!

Hate Linux/Unix now
by SFX on Thu 18th Nov 2004 16:08 UTC

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.

@ JohnLein
by Jean-Louis on Thu 18th Nov 2004 16:32 UTC


"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 ... ;)

Nice update
by JP on Thu 18th Nov 2004 16:35 UTC

Interesting article. Thanks Thom:-)

Download
by juca on Thu 18th Nov 2004 16:46 UTC

The download is too slow. I am getting a 2Kbps.

@Eugenia
by Paul-Michael Bauer on Thu 18th Nov 2004 16:50 UTC

>>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.

nice article!
by christian paratschek on Thu 18th Nov 2004 17:36 UTC

thx - this was quite interesting...

christian

The goodness that is QNX
by Rho on Thu 18th Nov 2004 17:40 UTC

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. :-)

Graphics card drivers?
by Mike on Thu 18th Nov 2004 17:51 UTC

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.

Install it on a 950MB partition?
by felipe on Thu 18th Nov 2004 18:15 UTC

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_

Re: Install it on a 950MB partition?
by Jean-Louis on Thu 18th Nov 2004 18:22 UTC


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

Re: Install it on a 950MB partition?
by felipe on Thu 18th Nov 2004 18:25 UTC

great! going to d'load it

thanks man ;-)

Sound OS
by memer on Thu 18th Nov 2004 18:25 UTC

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.

re: Size of GIMP
by Simba on Thu 18th Nov 2004 18:36 UTC

"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.

@Thom Holwerda
by johnlein on Thu 18th Nov 2004 18:36 UTC

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.

very nice!
by david on Thu 18th Nov 2004 18:41 UTC

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!

Re: Voyager Crashing System
by Chris McKillop on Thu 18th Nov 2004 18:50 UTC

@ 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.

QNX
by Anonymous on Thu 18th Nov 2004 19:08 UTC

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.

@SFX
by M^2 on Thu 18th Nov 2004 19:27 UTC

//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
by poundsmack on Thu 18th Nov 2004 20:05 UTC

qnx is good....i useit on my desktop os some times.....

A lesson to you folks
by Rayiner Hashem on Thu 18th Nov 2004 20:32 UTC

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.

QNX message passing _is_ synchronous
by teletype on Thu 18th Nov 2004 20:59 UTC

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
by Mads on Thu 18th Nov 2004 21:10 UTC

Great article Thom, very good reading. I'm gonna give QNX a shoot once more ;)

3D OpenGL Acceleration ??
by Anonymous on Thu 18th Nov 2004 21:16 UTC

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

QNX could be better
by flav on Thu 18th Nov 2004 21:23 UTC

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

RE: teletype
by Thom Holwerda on Thu 18th Nov 2004 21:24 UTC

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
by Latem on Thu 18th Nov 2004 22:32 UTC

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.

RE: Latem
by Thom Holwerda on Thu 18th Nov 2004 22:53 UTC

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.

Latem
by M^2 on Thu 18th Nov 2004 23:18 UTC

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)

@ flav
by pkj on Fri 19th Nov 2004 04:34 UTC

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.

MSN client
by wicked on Fri 19th Nov 2004 06:11 UTC

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.

another Penix OS clone
by Gerber on Fri 19th Nov 2004 06:58 UTC

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....

v Penix OS
by Gerber on Fri 19th Nov 2004 07:06 UTC
@ pkj
by djm on Fri 19th Nov 2004 14:20 UTC

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.

@ djm
by pkj on Fri 19th Nov 2004 15:09 UTC

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 could rock with very little work...
by Zippy on Fri 19th Nov 2004 22:32 UTC

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.

QNX not aiming for desktop...
by Bonoho on Fri 19th Nov 2004 23:11 UTC

>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.

QNX and VMware
by Bannor99 on Sat 20th Nov 2004 14:50 UTC

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.

@zippy:
by AdamW on Sat 20th Nov 2004 17:16 UTC

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. ;)

RE: AdamW
by Thom Holwerda on Sat 20th Nov 2004 17:59 UTC

[/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?

why gnome??
by Matt on Sat 20th Nov 2004 19:25 UTC

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.

QNX 6.3 runs under Virtual PC 2004, not VMware
by Bannor99 on Sun 21st Nov 2004 23:25 UTC

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