Slashdot Mirror
QNX: When an OS Really, Really Has to Work
An anonymous reader writes "Fortune has this article about how QNX's OS has found a niche and is doing well. Especially after 1996 when Microsoft executives said they would crush them in 2 years. When your software absolutely positively needs to work!"
Kyu-nicks? or Kyu-Enn-Eks?
hoser: Slashdot reader since 1987.
Anyway I took 2 programming courses in basic and pascal. The labs used some strange Unisys dumb terminals connected to a builky black looking box. Very XT-ish and looked like it was from the early to mid 80's. Anyway it ran a no name OS called QNX. I believe it was powered by a 286 or 6800 with about 4 megs of ram for all 20 students. It had no display but a teletype printer where we would print out our programs. It handled quite well for such a limited server.
Its Very old and I remember a 1984 copyright that showed up whenever I booted. I had no idea it was a unixlike system.
It seemed just as fast as a standalone 286 and it had a "$" as the prompt sign with a strange scripting system. I considered it underpowered and old but was supprised by the included gcc, sed, gmake, and other utilities and powerfull scripting. It had some nice api's for 2d graphics displays.
Anyway 2 years later I wanted to try Unix after playing with NT 4 when after it just came out. I tried Caldera (shudder )Linux and I was supprised that I have been running gnu and unix all long. The shell scripts and everything were identical and I have been using Unix without even knowing it.
Linux felt quite old without X in the old days( before kde was stable and gnome was around). But I have qnx running on that horribly ancient system to thank.
http://saveie6.com/
The US Navy has used a CD-ROM tech library called ATIS for years. It is based on a Kubik 240 CD-ROM changer with an external controller called a Mediator. The mediator runs QNX. I worked on some ATIS systems and found the CD-ROM changer to be an extremely fragile and unreliable electromechanical beast, but NEVER saw a failure, glitch, or error on the QNX based mediator. This was a tribute to the hardware it ran on as much as well as the OS. Interestingly enough, I am intimately familiar with the inside of the Kubik changer, but have no idea what CPU, memory, or disk the Mediator ran on. This was simply because the changer was always broke and the Mediator never had to be touched from the day it was installed.
People in white lab coats are the primary cause of cancer in rats.
Any technology distinguishable from magic is insufficiently advanced. - Geek's corollary to Clarke's law
In the mid-80's I frequented a multi-user BBS which ran on Qnx. The machine? A 4.77 MHz 8088 IBM PC clone. It had 10 or 12 lines each running a 300 baud modem. It had email, newsgroups, chat, games, and downloads. I had a developer account and could compile C programs. All while the system was full. Without anyone even noticing. The OS is smooth as silk.
Later, the BBS was upgraded to an 8 MHz AT clone and 2400 baud modems. Still, smooth as silk, even at capacity.
The BBS never crashed once and always ran smooth.
I can't say much about today's Qnx, because I haven't used it. But yesterday's Qnx displayed a level of quality I've never seen in another OS. If I ever find myself needing medical attention, I usre as hell hope the OS running under the hood is Qnx. There is nothing more reliable.
-Teckla
Only partly true.
The operating system provides the framework within which the software works. For things like a desktop where things like the occasional 1/2 second ~ 3second delay isn't fatal, and blue-screening a couple of times a week (or day, as the case may be) is mostly just an annoyance, then yes -- the two are pretty much equal.
For things like nuclear reactor control, precision robotics and medical instruments, where a 1 miliseond (much less 1 second) hickup can result in death and destruction. they are most definitely not equal. The hard realtime in Windows is, well, not that hard. It's pretty easy to get Windows to lock up for the better part of a second. Linus is only slightly better -- but only when you install the realtime patches.
As far as reliability, Microsoft is still proud of being able to (sometimes) run for 3 months at a shot without rebooting. Linux has a much better history, but it's still far from bulletproof. As far as I know, neither one is certified to run things like nuclear reactors and medical equipment.
The Navy's decicision to use Windows to run their battleships has been the source of some amusement -- having managed to bluescreen one ship and leaving it 'dead in the water'. As to whether this could happen during a battle, converting 'dead in the water' to 'dead and in the water' is a matter of conjecture. All I can say with certainty is that I'm glad I'm not a US sailor.
Free Software: Like love, it grows best when given away.
I work for a robotics company. We use QNX as the OS on our PC based control. The following is an example of how QNX has impressed me.
One November a customer called and complained that they were not getting their log files. These log files were written to a ftp shared directory. One of my coworkers logged into the robot via modem and started looking around. When he tried to get a directory listing he got an Input/Output error instead. After a little digging around in the logs in ram he determined the hard drive had died. The most interesting thjing is that the hard drive had apparently died in August. The robot had run continually from August to November and the only trace of any problems was the lack of log files. There was no other permament storage in the system. The OS, UI and all the robot applications were running in RAM for 3 months without problems.
I Love QNX
I Don't Work Here
Well, yes and no. It is in some ways, with the Hardware Abstraction Layer (HAL), and other features. But it doesn't strictly follow the microkernel methodology since components can run in kernel-space (namely kernel mode drivers. those are typically only the very essential items like filesystem and whatnot.)
Sorta like Linux isn't really monolithic, since you can load kernel modules.
The NT kernel is extremely stable. Typically, drivers are what bring a 2K/XP/server system down. In fact, that is all I've ever seen bring a system down. QNX is unique in that it can restart any system component that has failed, and it isolates everything a lot more. Make no mistake - that is slower than having drivers run in kernel space, but it has its benefits. The microkernel can axe drivers and restart them in realtime, something that cannot be done for NT's kernel mode drivers (although programs and other drivers can be dynamically loaded and unloaded.)
And yes, the display driver was also moved into kernel land for NT4 and higher. Trust me - you would NOT be happy with 3d game performance or GUI performance if it were not (although some may argue for the server version that would be a better idea, but honestly my servers run headless so I don't care.)
Natural != (nontoxic || beneficial)
Or you have tried it as a "normal" desktop type OS? Have any thoughts on it if
so?
Yea, I tried it for a while, couple of weeks or so, just playing around with it. I
thought it was pretty cool, it had a ports like software installation program,
you clicked on what you wanted to install, and it took care of dependancies and
the like, very nice browser, supported everything my test box had (Dell GX110)
with an i810 video card. No problems, Solaris x86 gave me much more. I
thought it was pretty cool. Felt *nixy, gui-wise, all in all, not bad at all.
I have it running on a Audrey, as I said earlier, and I like it.
SealBeater
-- Its survival of the fittest...and we got the fucking guns!!!
I've seen a release from Hyperion Entertainment that stated QNX RTOS had context switching times of 40 microsecons. In the same paper, it asid MacOSX was around 400.
The announcement was that AmigaOS4 PPC on a 600Mhz AmigaOne had around 4 microseconds, give or take a few micro. Im not sure how correct my figures were, but AmigaOS turned out a little better...
I wonder if theres room for more playsers in this niche.
Good article.
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
QNX was actually developed by two Waterloo students as their final assignment. It was very very basic but it was soooo good that the they could sell it. And thats just what they did, they worked on it, made it what it is today and are now being mentioned on Fortune.... lucky fucks. ...I'm not jealous, nooo not at all. =P
That's not surprising. QNX costs money, and Linux is free.
What's disappointing is that the Hurd kernel was such a dud. They've been trying to write a microkernel for a decade. Unfortunately, they started with the Mach interprocess communication model, and never escaped. Microkernel architecture depends crucially on getting the basic design decisions right. You can just hack together a UNIX-type OS, and fix stuff until it works, but microkernels have to be done right.
The other downside of a message-passing microkernel is that you do more data copying. But modern CPUs do data copying quite well, and it's not the issue it used to be. In a world where SOAP converts subroutine calls to XML, the overheads of a message-passing OS are trivial.
If message-passing OSs were more popular, hardware support could make the overhead of message passing even lower. Copying, after all, is infinitely parallelizable.
There are a couple of things qnx does that are somewhat quirky, but also unspeakably cool:
integration of memory, proccess, and file systems. You can address memory as a file. you can refer to processes as file. want a snap shot of your process? just copy it to disk some where.
linking programs together at run time. Have a constant you want to change, grab it into a simple gui slider with ease. Want to grab images from a frame grabber, just register to recive them. What? they are comming from a frame grabber on another machine? no difference. and this is being routed to a gui running on a third? also not a problem.
Want to start a bunch of processes on your cluster, link them all via scripts, then move proccesses around to load ballance, relinking as you go? Also not a problem, you can do it with a single script on one machine.
Having that level of fast comunication primitives is great.