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