Please create an account to participate in the Slashdot moderation system


Forgot your password?
Operating Systems Software

QNX: When an OS Really, Really Has to Work 514

Posted by michael
from the abnormal-termination dept.
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!"
This discussion has been archived. No new comments can be posted.

QNX: When an OS Really, Really Has to Work

Comments Filter:
  • by Anonymous Coward on Sunday June 15, 2003 @08:32PM (#6207721)
    From the docs:

    A pointer to an argument vector. The value in argv[0] should point to the filename of program being loaded, but can be NULL if no arguments are being passed. The last member of argv must be a NULL pointer. The value of argv can't be NULL.

    Argv is the second to last parameter for spawn. You have it set to NULL.
  • by $calar (590356) on Sunday June 15, 2003 @08:32PM (#6207723) Journal
    Yes they are around, in fact some more recent news about them came out of the JavaOne conference: They are going to be integrating IBMâ(TM)s WebSphere Micro Environment.
  • QNX rules (Score:5, Informative)

    by CausticWindow (632215) on Sunday June 15, 2003 @08:34PM (#6207739)

    QNX is designed like a modern os should be. It's straigt out of an Operating Systems 101 textbook.

    If only Linux had more of QNX's design niceties and robustness.

    Too bad the Amiga/QNX desktop thing never became a big hit.

  • download link here (Score:2, Informative)

    by lingqi (577227) on Sunday June 15, 2003 @08:36PM (#6207756) Journal
    sorry for being a dork and replying to myself, but look here [] for Neutrino. right side of the page.
  • Re:um (Score:3, Informative)

    by Cylix (55374) * on Sunday June 15, 2003 @08:40PM (#6207779) Homepage Journal
    I do believe it is made for PC's. (It at least was at one time)

    It also happens to have a nice niche in the embedded market as well.

    At an embedded systems conference, a while ago, the QNX guys showed me tablet pc's, citrix servers, remote X stuffs and my favorite at the time... the QNX port of quake. The quake port was a little buggy and I don't believe their system had sound support on or no speakers.

    We chatted, grabbed the install floppies (2 or 3 at the time), and got some cards.

    All in all, it was one of the better booths to visit.
  • Re:um (Score:5, Informative)

    by SoSueMe (263478) on Sunday June 15, 2003 @08:43PM (#6207799)
    Here's what you DO get (from the Neutrino [] page):
    The QNX Momentics Development Suite Non-Commercial (NC) edition gives you a full self-hosted development environment with the QNX Neutrino RTOS, plus tools, device driver kits, a desktop class browser, and more.

    QNX Neutrino RTOS v 6.2.1

    * Symmetric Multiprocessing (SMP)
    * QNX Photon microGUI
    * Hundreds of POSIX, UNIX, and QNX utilities
    * Distributed processing

    Self-hosted C/C++ development environment for x86 & ARM development only. Reference Platform:

    * iPAQ (ARM development target)

    Driver Development Kits (DDKs)

    Libraries and Tools:

    * ANSI C, GCC v2.95x optimizing compiler, GDB 5.x, Binutils 2.10.x
  • QNX NC (Score:5, Informative)

    by christurkel (520220) on Sunday June 15, 2003 @08:44PM (#6207805) Homepage Journal
    You can download a bootable CD from that runs "Live", from the CD, so you kick the wheels, so to speak. You can then install it, if you wish.
    The QNX floppy demo was for QNX4, while the CD is QNX 6, a vastly improved OS. The floppy can still be found but its not half the OS that QNX 6 is.
    QNX is POSIX compliant and can run all Unix utilities, Besides the Photon GUI, you can run various window managers. You can run X Windows apps seemlessly rootless using XPhoton. Already Gimp, AbiWord and others have been ported. There are many native apps as well, irc clients, a mozilla and opera port. Worth a try, at least!
    QNX isn't the easiest OS to use (try getting a USB printer to work and you'll find a new definition of pain and suffering) but it is rock solid and fun to geek with.
  • by Anonymous Coward on Sunday June 15, 2003 @08:44PM (#6207807)
    I thought Darwin/OS X/Mach was microkernel, too, but take a look at this [], where it says "This modular structure results in a more robust and extensible system than a monolithic kernel would allow, without the performance penalty of a pure microkernel." Evidently OS X is neither monolithic nor microkernel.
  • QNX is a nice RT OS (Score:4, Informative)

    by Dolphinzilla (199489) on Sunday June 15, 2003 @08:45PM (#6207810) Journal
    I have used QNX and I can tell you it is great for embedded systems - it is like an affordable VxWorks - a real time OS with lots of bells and whistles and super stability. However like VxWorks it does lack a lot of hardware support - but you can write your own drivers (of course). You use to be able to download the OS for free for evaluation in a single executable that runs kind of like Knoppix - no real install necessary. Its a cool way to kill an afternoon if your bored (and a geek).
  • by UnknowingFool (672806) on Sunday June 15, 2003 @08:46PM (#6207821)
    The problem with this approach, still followed in widely used operating systems such as Windows and Linux, is that a trivial error in any one of the many functions that share the same memory space can shut down the whole system.

    Well this is somewhat of a generalization. Yes some errors can cause the whole system to crash in both Linux, Windows, and Unix. The difference is that it the way Unix and Linux are designed, it is far less likely.

    All the components of their OS were isolated from the microkernel and from one another in their own protected memory spaces.

    Protected memory space for the kernel or microkernel: Even Windows has that. The only problem is that "protected" is a very loose tem for Windows. Unlike Windows, Unix and Linux doesn't allow any ordinary application to write to the kernel.

    Other than that, QNX does have some potential, but their market is really a niche. Since it is a niche, it doesn't offer the interoperability that other OS offers.

  • by be-fan (61476) on Sunday June 15, 2003 @08:49PM (#6207843)
    NT is hardly a microkernel. A microkernel, according to strict definitions, doesn't include anything like drivers, paging or the filesystem. QNX fits this definition --- the filesystem runs in userspace, and even drivers run as seperate processes that communicate via message passing. In Win2k and WinXP, almost everything runs in kernel space. Heck, in the next version, rumor has it that large parts of SQL and the .NET runtime are going in kernel space! And OS X isn't a microkernel either. It uses Mach, but the BSD server runs in kernel space, and message passing between the two has been replaced by procedure calls.
  • Re:Pronouciation? (Score:5, Informative)

    by heli0 (659560) on Sunday June 15, 2003 @08:49PM (#6207845)
    1) What is QNX? []

    QNX pronounced like "queue nicks" is a commercial operating system that runs on intel processors, mainly the 386, 486, and Pentium, and their clones, such as MD, Nat Semiconductor, Cyrix, and SGS Thompson.

    The simple answer is that QNX is a realtime, microkernel, preemptive, prioritized, message passing, network distributed, multitasking, multiuser, fault tolerant operating system. This is a "true" microkernel, with the largest QNX kernel to date being less than 10K.

    The QNX/Neutrino microkernel is about 32K, but can run standalone, something the QNX4 microkernel cannot. The QNX/Neutrino microkernel + process manager is about 64K, which is half the size of the QNX4 microkernel + process manager, and it does more.

  • Crap... (Score:3, Informative)

    by SoSueMe (263478) on Sunday June 15, 2003 @08:49PM (#6207847)
    Should have linked here [].
  • Re:QNX rules (Score:1, Informative)

    by beee (98582) on Sunday June 15, 2003 @08:51PM (#6207866) Homepage
    Your description of QNX, though elegant, is a little off. If QNX is straight out of any book, it'd be "Unix for Dummies". Its endless striving towards reckless simplification, abstraction, and minimalism is what keeps it from being one of the "big boys".

    QNX's major problem is its lack of focus on who its userbase is (or should be). They're catering to the wrong people, not realizing that their core userbase could (and should) be the typical knowledgable Linux geek. Instead, they seem to be chasing after an elusive "newbie" core of users.

    I, for one, am glad Linux lacks QNX's "design niceities". That's what seperates the two, and I am more than glad to have an OS which isn't concerned with things I consider to be a waste of code -- which seems to be where QNX spends most of its development time.

    Robustness is definitely comparable, so I wouldn't give QNX the upper hand in that corner -- all you need to do is take a look at the GPH support in both to figure out which is more robust.

    My view on QNX is this: Good, but not great. I'm actually a little suprised to see such support here at Slashdot.
  • Re:Pronouciation? (Score:2, Informative)

    by JerryKnight (465510) on Sunday June 15, 2003 @08:52PM (#6207871) Journal
    According to this [] the pronunciation is the former.
  • Re:um (Score:5, Informative)

    by imnoteddy (568836) on Sunday June 15, 2003 @08:53PM (#6207880)
    What you won't find in QNX is USB support

    Sorry, wrong. QNX USB support [].

  • Re:um (Score:2, Informative)

    by Anonymous Coward on Sunday June 15, 2003 @09:00PM (#6207925)
    Yes, it can and does run on PC hardware. However, it's not a PC OS. Was never meant to be, likely will never be
  • QNX Floppy Challenge (Score:5, Informative)

    by hendridm (302246) * on Sunday June 15, 2003 @09:04PM (#6207950) Homepage
    If you haven't taken the challenge yet, it's pretty cool []. You can get it here [] too.
  • by farrellj (563) on Sunday June 15, 2003 @09:04PM (#6207951) Homepage Journal
    Dan Hildebrand was one of the early luminaries of QNX in Kanata, just outside of Ottawa. Although I only met him once, I knew him well via the local Fidonet and Unix communities. It's too bad he isn't around to enjoy this story. But I am sure he is smiling about it wherever he is! Slashdot story about his death [] It's hard to believe it's been 5 years.

  • by csirac (574795) on Sunday June 15, 2003 @09:04PM (#6207952) Homepage
    They should have said "... possibly the best commercial microkernel-RTOS OS for embedded systems.."

    A life support system, pick'n place robot, or a plant monitoring/control system, or your submarine's navigation and control system etc. running Mac OS X is going to need 256MB RAM and 10GB HDD...

    By comparison QNX is designed from the ground up to be a true RTOS, responding to real time signals reliably and FAR faster than MacOS X or any other desktop OS could possibly hope for. It's not just bragging, it is fact. It was designed to beat normal OSes in this regard. And it does it with less.

    IIRC QNX will boot quite happily with little more than 16MB RAM, a 100MHz CPU, and some flash rom. Perfect for tiny mission critical embeded systems; a single board computer, no HDD, low power consumption, low profile, with performance, features, a good dev enviornment and flexibility to boot. Environmental considerations: you can easily box up a custom SBC to be x-ray/microwave/radiation/water/weather/vibration proof. Big companies with lots of money use custom embedded systems. An iBook running MacOS X 'aint gonna get you there.

    Also, IIRC QNX has extensive, documented, certified/standards based QA in testing and development, which companies using an OS for mission critical embedded systems just can't get (but really need) from many other solutions.

    - Paul
  • Interesting? (Score:5, Informative)

    by cgenman (325138) on Sunday June 15, 2003 @09:06PM (#6207963) Homepage
    I'm trying not to comment on this, but as two people modded it "interesting," obviously this fallacy needs to be shot down. While true for PDA's, which is obviously what ObviousGuy has experience with, it is not at all true for many real embedded systems.

    QNX is for those times when "Good enough" isn't good enough. An associate of mine used to run the network for a major medical responce company. They used to count downtime in the number of people dead due directly to the lack of a network. If you accidentally pulled a plug on the way to lunch, 4 people would be dead because of you.

    Their uptime target was 24-7-365-20. There was no such thing as "Good Enough."

    Ideally, any OS should do. It should be a flawlessly written middleman layer between flawlessly written hardware and flawlessly written software. But we all know that software is flawed, hardware drivers are flawed, and OS's are flawed. When WinCE comes across a problem in the kernel, it panics and comes crashing down. When Linux comes across a problem in the kernel, it panics and comes down. According to this article, when QNX comes across a problem in the kernel, it cuts off, shuts down, and reboots just the offending section, cutting downtime from 30 seconds to microseconds. That's pretty darned cool.

    Sure, the foundation of your house is just the interface between the ground and your software creation. But if your foundation is bad, no matter how much support the system integrator can provide, your house won't stay up for long. If you're building apartments, that might not matter. If you're building a hospital, your negligence could cost lives.

    And by the way, it's the software that controls the grinding of the lens. If the hardware knew how to grind a lens already, it wouldn't have electronics. The software controls the OS, the OS controls the hardware. Your Software->OS->Hardware diagram should have proven to you how important it is to have a reliable OS in the middle.

  • Re:QNX rules (Score:1, Informative)

    by Duncan3 (10537) on Sunday June 15, 2003 @09:10PM (#6207978) Homepage
    But the floppy disk driver NEEDS free access to every users process memory space.

    And I dont wanna impliment anything more then the supervisor bit of the 1000+ pages of memory and security protections intel chips have, *whaaaaaaaaaaaa*

    Linux and Windows arent "bad" they are just profoundly LAZY. Microkernels and doing everything right is way too much work. OK, wait, they are kinda crap becasue there is no memory protection aren't they.
  • Re:A couple things (Score:5, Informative)

    by cgenman (325138) on Sunday June 15, 2003 @09:15PM (#6208014) Homepage
    A device in the wild running WinCE or Linux has had to undergo and pass the same level of testing as a device running another OS to be admitted into medical usage.

    That's why LASIK systems don't run on WinCE.

  • ehm? (Score:5, Informative)

    by Horizon_99 (58767) on Sunday June 15, 2003 @09:16PM (#6208019)
    What you won't find in QNX is USB support, drivers for a Sound Blaster 16
    are you sure about that []?
  • Speaking of live CDs (Score:4, Informative)

    by Joe Tie. (567096) on Sunday June 15, 2003 @09:25PM (#6208081)
    A project worthy of any Robot finds kitten fan, QNX for the Dreamcast [].
  • Bullet Proof (Score:4, Informative)

    by the eric conspiracy (20178) on Sunday June 15, 2003 @09:30PM (#6208114)
    From Fortune :

    As a delighted user has put it, "The only way to make this software malfunction is to fire a bullet into the computer running it."

    Didn't Tandem actually run an ad claiming that if you shot a bullet into their servers they would keep running?

  • Re:A couple things (Score:5, Informative)

    by alienw (585907) <alienw,slashdot&gmail,com> on Sunday June 15, 2003 @09:32PM (#6208133)
    Sure, I trust testing. After all, if an OS seems to work right most of the time, it's fine. If my copy of mozilla doesn't crash within an hour, it will never crash. Since the Therac-25 [] underwent stringent testing, it was perfectly safe, right?

    BZZZZZT! Wrong answer. Evidence shows that testing cannot be trusted to reveal all defects. No matter how much you test a system, there is still a very significant risk that it will contain a defect. That's why practically all critical systems use a PROCESS to prevent errors from getting in. That's why the military forces Ada for all systems, why off-the-shelf components aren't used for life-support systems, and why MIL specs are not just based on reliability tests. Since neither Linux nor WinCE underwent any type of certification, code audit, or specialized quality-control processes, they cannot be trusted despite what tests might indicate.
  • Re:You're mistaken (Score:3, Informative)

    by OldMiner (589872) * on Sunday June 15, 2003 @09:42PM (#6208201) Journal
    This is why WinCE and Linux are Good Enough as well.

    I'm sorry, but, no. The problem is that WinCE (it's WinCE.NET now, if we want to be anal) is not a hard real time OS. [WinXP embedded also exists. It provides no real time support at all.] WinCE is "real time", but not good enough for applications that require a high priority interrupt never be dropped. It doesn't have true guarantees about minimum time for an interrupt to be serviced. However, a hard real time version of linux (RTLinux) is available last I checked.

  • by njan (606186) on Sunday June 15, 2003 @09:45PM (#6208223) Homepage
    Actually, as far as I remember, they released a bootable iso which had complete hardware support with a huge library of software, and network support - a la knoppix.

    But their floppy was phenomenally useful - on a site of several thousand people, I used to use it in preference to windows to troubleshoot network equipment - until the company stopped to buy floppy drives for their workstations by default...
  • Re:um (Score:5, Informative)

    by SealBeater (143912) on Sunday June 15, 2003 @10:03PM (#6208314) Homepage
    I can't believe this got a +5 insightful.

    It's not made for PCs

    You are mistaken, I'm afraid. See below.

    What you won't find in QNX is USB support

    QNX most defiantly has USB support, as I have a Audrey that has it sitting in front of me.
    As for the "not meant for PCs", QNX runs extremely well on a PC, with just about everything you need.
    QNX also has 3d support, as evidenced in the FAQ here [].

    To quote:
    Photon supports rapid animation, 3D graphics, and realtime trending
    through off-screen memory, bypass mode, video overlay, and other
    advanced features.

    QNX also supports the following:

    * XScale processors and boards
    * >4G address spaces on PowerPC boards
    * more video hardware
    * UDMA 66 chipset (high-speed disk interface)
    * Enhanced TCP/IP stack - includes IPv4, Unix domain sockets, multicast support
    * NFS v3
    * Resource database for better device mapping
    * Bi-directional pipes
    * Block driver DMA
    * Enhanced support for shared memory, with full support for creation mode and ownership information

    And SMP, which OpenBSD still hasn't included, for instance.

    I recommend that anyone who is interested download the free ISO and install it on
    a spare computer you may have laying around and see for yourself. Get it here [].
    Don't rely on /. or me to give accurate information, go see for yourself.

  • by HidingMyName (669183) on Sunday June 15, 2003 @10:53PM (#6208623)
    Interestingly, one of the QNX founders is named Gordon Bell, which is coincidentally the name of a very famous system architect at Digital and later at Microsoft Research. Finally this article gave enough information I was able to convince myself that it was just a name space collision, they aren't the same fellow.
  • by CrackersnSoup (517698) on Sunday June 15, 2003 @10:59PM (#6208668)
    My ass they dont crash. There are plenty of placed embeded Windows crash's. The latest: Parking ticket machines around Houston. I had the chance to talk with a tech working on the parking garage machine's. He said they were great before the OS upgrade to Windows.

  • Re:QNX? ICK! (Score:5, Informative)

    by ComputerSlicer23 (516509) on Sunday June 15, 2003 @11:07PM (#6208716)
    Can I call Bullshit on you? As I worked for the first QNX reseller in the United States, I've never worked on QNX 6, but I did a lot of work on QNX 4, and did a bit of porting work from QNX 2 -> QNX 4. I've stayed in touch with some friends there, and they did a lot of the work of writing certain portions of the QNX 4 compatibility layer for QNX 6.

    What security problems did you have?

    There are 2 that I know of offhand. First, they used a reversible hash for passwords, or they used one that was trival to brute force. It's my understanding that breaking a password on QNX is relatively simple. Second, if you are user X on a given machine, you are user X on all of the machines when you are using the QNX networking.

    QNX isn't meant to be an on the public Internet OS. It's meant to be used in a closed loop networking environment when in production use. Don't configure anyone else as on your QNX network, and the problem is solved.

    2. Networking was trivial. The damn network just worked, the biggest trick was coordinating who had what node number. It worked all the time once you got is correctly configured. It always worked. Other then getting the TCP/IP stack installed which took the sacrifice of a small fury animal, and asking my co-worker Bob how to do it. Once it was configured and running, it was trivial, it always worked without fail on the machines I used.

    IPC, was cake. It was stock off the shelf redevous style message passing. About the trickest thing there was calling returning a negative value from a inside of a interrupt service routine (not the real ISR, because you should never reprogram the ISR's, but the function you registered to be called when an interrupt happened), that would call issue a Trigger. That was a little weird. The networking itself was simple. Here's the buffer with the message, here's who I want it passed to, call the send message API. Done.

    Now, the style you had to use was a little awkward, because you blocked on a receive message call. However, that was a function on the hard real time requirement of processing a message. You could use stock TCP/IP functionality if you wanted to. They had the standard UNIX sockets as I recall. The had shared memory (in fact shared memory was how they implemented all of the Dev Server functionality). I can't remember if it did stock UNIX signals (I'm pretty sure it did). However, you never needed to use those, you could send real QNX messages, which was orders of magnitude easier.

    Now, if you want to bitch about the structure of the Photon programs I understand. If you want to bitch about the lack of a number of highly useful utilities, and that all things are freeze/PAX encoded instead of TAR'ed, I'd agree. Networking isn't a problem. IPC is the core of the entire OS, that's literally how it implements everything. Everytime you call open/read/write, a message gets sent to the process that is registered to handle calls to that. I know this because I write a RAM disk buffer as a proof of concept that we could re-implement chunks of the OS if we needed to. Message passing and IPC are what QNX excels at. It's security model is that, don't use it when it's connected to something that isn't trustworthy.


  • That would be the Unisys Icon, either series 1 or 2. They were _not_ dumb terminals however -- the Series 2 used an 80186 (you read that correctly) with 1MB of RAM. The "bulky black box" was the storage system (it had the hard disks and floppy drives) and handled network control. I don't recall what was in the series 1 hardware wise, but it was similar.

    The systems used to be popular in Canadian schools because the OS was developed in Canada, as were most of the tools and applications (which were primarily by Watcom). Plus students generally weren't going to be able to install whatever gunk they brought from their DOS machines at home, nor were DOS based virii any sort of threat to these systems. They were easy to manage and maintain, and were good for teaching programming basics.

    Do you prefer todays alternative of brainwashing students in The Microsoft Way(tm)?

  • by wing03 (654457) on Sunday June 15, 2003 @11:34PM (#6208897)
    Unisys Icon computers.

    Pretty expensive buggers at the time (mid 80s).

    If memory serves, the Icon was to the computer industry much like what Bob and Doug Mackenzie was to SCTV. The Canadian government in all its paranoia wanted "Canadian content" and exposure.

    Hence the Unisys Icon which was supposed to permeate schools around and eventually industry...

    One network server box and dumb terminals with a built in track ball with two "Action" buttons. All attached via 10-Base-T.

    It was 1986 and I was 13 when I came across my first so I only got to play with the educational software. The only one that comes to mind is something having to do with a pioneer family by the name of Bartlet.

    Anyhow, a bunch of lights turned on when a decade later, my boss commented that QNX ran on those Icons.

    I guess the logic was that the gov't would sponsor the Icon by putting them in schools everywhere, get the next generation students familiar with it and when they grew up, they would be so familiar that it would become industry standard.

    Little did they realize that by not pushing it on the home front, Wintel would eventually win out.

  • by ignorant_newbie (104175) on Sunday June 15, 2003 @11:43PM (#6208949) Homepage
    >We Will Crush You...
    >Waiting for the inevitable joke comparing Bill Gates to

    who actually said "my was pokhoronim", which means "we will bury you". Which was not a threat. It's better translated as somthing like "we will dance on your grave" - he was saying that the soviet system was so superior that it would outlast the american one, and thus the USSR would be presant at the funeral of american capitalism, and help bury it.
  • by virtigex (323685) on Sunday June 15, 2003 @11:54PM (#6209000)
    IMHO, by far the biggest advantage of the QNX is the environment for developing device drivers. Device drivers are just processes that make special system calls that make themselve visible under the /dev/ file system. When a device driver crashes, the process dies and unless it got stuck in an interrupt, you are free to restart the driver. You can run the device driver in a debugger, since it is a regular program. This makes device driver development a breeze compared to Linux, where a crash in a kernel module will require a reboot.

    As an added bonus, the /dev file system is entirely dynamic, showing only the drivers that are running. Thankfully, Linux is going in this direction.

    Two areas where QNX falls down are the lack of USB profiles for mass storage and the lack of a journalling file system. The lack of a journalling file system is particularly worrisome, since QNX is often operating in an environment where the power could be pulled at any time.

  • by evilviper (135110) on Sunday June 15, 2003 @11:58PM (#6209017) Journal
    Because they make the system run more slowly.

    From your signature: "I'm glad I don't put much basis on yammerings on slashdot"... "In fact, I'm real glad." --Theo de Raadt

    Hehe... The funny thing is, that quote was taken from a mailing where Theo said, if he took messages on slashdot seriously, he would think that a 2% drop in performance isn't worth the increased security (of propolice, W^X, et al.).
  • by Animats (122034) on Monday June 16, 2003 @12:04AM (#6209047) Homepage
    First, QNX really is a microkernel OS, with networking, drivers, file systems, windowing, etc. running as protected mode processes. MacOS X, Mach, the Hurd, NT, etc. have far, far more in the kernel. Their kernels are an order of magnitude (or worse) bigger.

    The key idea behind QNX is that it does interprocess message passing between protected-mode processes really, really well. Everything else is built on top of that. In most other OSs, interprocess communication was an afterthought, and it shows. Typically, message passing is built on top of the I/O system. In QNX, the I/O system is built on top of message passing.

    The QNX kernel is very stable because it only does a few basic things, and those few things are heavily exercised and well debugged. New system calls are very rarely added. New features go in new user processes.

    Development on QNX is straightforward. The whole GNU command-line toolset is available. The API is Posix-compatible. The QNX calls are well integrated with the Posix calls; there aren't separate "Posix threads", like some other OSs.

    QNX is the last OS vendor that competes commercially with Microsoft on x86 desktop machines. The fact that they're still alive says something.

    You can run QNX as a desktop OS, and I have a machine on my desk that does so. But there's not much desktop-type software. Mozila, AbiWord, and Eclipse have been ported, but that's about it for graphical desktop applications. OpenOffice has not been ported, and it would be a huge win if somebody did that.

    QNX has its own windowing system, Photon, which is like nothing else out there. It's quite good, and much cleaner than most windowing systems. But it's different.

    Hardware support is spotty. Graphics support is mostly for obsolete boards, although anything that supports VGA or VESA modes will work. (NVidia refuses to release enough information to allow development of QNX drivers.) USB 1 is supported, but only for a few peripherals. USB 2 is not, nor is FireWire. (I've been writing FireWire camera support.)

    QNX runs our robot vehicle for the DARPA Grand Challenge. [] It has to work.

  • Re:QNX rules (Score:4, Informative)

    by xenocide2 (231786) on Monday June 16, 2003 @12:45AM (#6209234) Homepage
    I appreciate QNX as an embedded platform, but I have yet to hear convincing arguments as to how QNX manages to overcome the address translation and additional costs reguarding interprocess communication, with respect to performance.

    Why would linux kernel hackers be adding tools like HTTP servers and packet filtering into the kernel, if it was somehow the UNIX way to keep them as seperate processes managed by the kernel? The answer is that by keeping programs in the kernel space, context switching is lower costed, address translation is not required, and IPC generates two or three context switches compared to one or two with a kernelspace program. Even QNX has faculties for 'lightweight processes' that have independant stacks and a common global data sandbox.
  • Re:A lil history... (Score:1, Informative)

    by waldo2020 (592242) on Monday June 16, 2003 @02:20AM (#6209687)
    You are correct. Students were required to write their own RT OS for the year 3/4 rtos course to control an elaborate model train setup- strangely enough, built by Mark Tilden of BEAM critter fame. I have the listing of it I picked up by accident- it was printed off a line printer on a Honeywell Gecos machine running a unix like OS;)
  • Re:Imagine........ (Score:5, Informative)

    by Rolman (120909) on Monday June 16, 2003 @02:24AM (#6209704)
    I know you were being funny, but actually, a cluster in QNX is the easiest thing to do ever.

    QNX's architecture is very much oriented towards message passing, and every piece of hardware is abstracted, even processors. This means you can have a lot of CPUs or machines working on a network running your applications and the load will be evenly distributed, without you having to specifically code your applications. Your only limit is your network performance and latency.

    Hell, you'd need to code your application with special system calls for it to know it's not running locally!

    I had a wonderful experience with QNX4 a couple of years ago. QNX4 back then didn't have SMP support, but I called QNX Support and they told me how to run one kernel on each CPU of my server and Voila! I had the equivalent of a cluster in one box. Performance was very good, too, context switching was not even worth to measure.

    QNX Neutrino is even more powerful, and now it supports SMP... Beowulf clusters are sooo 1999...

  • by ComputerSlicer23 (516509) on Monday June 16, 2003 @02:41AM (#6209763)
    Well yes and no. Having modules does not make you not a monolithic kernel. Micro kernels aren't terribly well defined, but QNX doesn't do loadable "modules", like Linux does. In QNX, the modules are generally completely independent of the kernel. The micro kernel in QNX 4 did roughly this:

    Message passing,
    Process scheduling,
    Address space management.
    Setup the timing hardware on the ISR.

    That's it. The serial driver, done in a process. The keyboard, floppy, IDE, SCSI driver, done in a process. About the only piece of hardware you didn't control in user space was the PIC interrupt processor. Other then that, all interrupts did was call user process-space callbacks.

    In Linux, if your IDE driver dies the whole system could lock up. In QNX4, if your IDE driver dies, the only reason your system will lock up, is because you application locks up on failure to write to the filesystem, or the hardware goes crazy. If the CPU works, and the RAM chips don't get hit by gamma rays to cause inadvertant bit flips, QNX will in fact work. Period. Full stop, end of discussion. That's why most applications on QNX use no moving parts, so there is an extremely low likelyhood of failure after running burn in tests on the hardware.

    Now, Linux on the other hand, I've seen the SCSI drivers on it, where a single SCSI card will fail, and the identical SCSI card that works fine will have it's driver lock up because the other piece of hardware failed, which creates a situation where RAID 1 won't continue working, so the filesystem fails, which causes an ext3 journalling error, which then causes your kernal to panic. That wouldn't happen under QNX4.


  • by Anonymous Coward on Monday June 16, 2003 @03:19AM (#6209906)
    Absolutely ignorant article. Linux and Windows have a monolithic kernel yes, but protected memory spaces. QNX is not the only company to market a microkernel OS, try NeXT and then Apple. Mach has been around for ages in many 'commercial' applications. Blah Blah Blah.
  • by rabidcow (209019) on Monday June 16, 2003 @03:42AM (#6209987) Homepage
    Win32 userland/kernel split is 2:2

    You sure about that? In Win9x, the top half of memory is shared by all processes. NT is different, although I don't remember exactly how it works.

    Win9x is pretty weak tho, you can take down a machine from a dos box. (iirc: echo f f000-ffff {garbage} | debug)
  • Re:QNX vs. Linux (Score:3, Informative)

    by Anonymous Coward on Monday June 16, 2003 @05:24AM (#6210292)
    Linux is a UNIX, don't use it for safety crit. How many nukes do you think are running Solaris, AIX, xBSD, HPUx, Irix etc, etc, etc... ?

    "Can we say, without lying, that Linux can measure up to QNX on that front ?"

    It'd be nice to see some informed comments on /. for once. QNX has very different goals to Linux. It's an RTOS for a start (real-time OS), developed by a relatively small group of people to very tight design constraints. We can't expect Linux to 'reach the same standard' soon because it's not trying to measure up on that front.

    It's like asking an RV to 'reach the same standard' as a roadster.

    On the other hand, there's things Linux does which QNX will probably never compete with - fast support for emmerging standards, truly infrastructure-class networking hardware support and of course the massive software and user base.

    > QNX tuns a microkernel, which is known to be much faster and much more stable than a regular kernel.

    Hmmm. Copy that out of the WinNT marketing materials did ya? Of course, I run HURD because it's much faster and more stable than Linux - don't you?
  • Alternative sources (Score:5, Informative)

    by OzJimbob (129746) on Monday June 16, 2003 @06:15AM (#6210450) Homepage
    If you're still struggling to get it off the offical site, you can find QNX here:

    Planet Mirror [].

    A couple of different ISOs are offered - one with all the packages, and a basic ISO. It's able to install within a Windows partition, apparently.
  • Re:QNX rules (Score:2, Informative)

    by MarkSwanson (648947) on Monday June 16, 2003 @09:17AM (#6211283) Homepage
    If you use the assembly language instruction RDTSC right before and after getpid() to determine how many clock cycles a simple (maybe the simplest) context switch can take you will find some interesting results:

    (RDTSC gives a correct result +- 20clks)
    400MHz PII: 44,000
    PIV: 18,000
    266MHz Athlon 1.3GHz: 6000

    These numbers are from memory from my tests several years ago. I have seem posts on lkml that glibc/Linux may have the PIV case down to about 9,000 ckls but I haven't tested it. However, I am fairly certain the PII case is correct - and the 66MHz FSB was mostly to blame for the bad numbers.

    Let's take Apache using on average 10 (guess) system calls for 10 x 44,000 = 440,000 clks for a 6-line index.html file.
    Apache would only be able to serve 909 index.html files/second using 100% of the CPU. (simplistic)

    Using Tux, we would be able to serve 10,000 index.html files/second using 100% of the CPU.

    In the real world, Tux is able to server 10,000/s on my 400MHz PII, and Apache is able to server over 2,000 so perhaps it doesn't use 10 System calls/page (I was guessing). In any case, the performance difference can obviously be worth while.
  • Re:QNX vs. Linux (Score:4, Informative)

    by cait56 (677299) on Monday June 16, 2003 @10:35AM (#6212097) Homepage

    QNX is an embedded OS. As embedded OSs go its very complete. You can get far smaller kernels with fewer pre-packaged solutions, and depending on your application that can be preferable.

    I haven't double-checked things recently, but my recollection was that QNX emphasized distributed systems (especially locally distributed, as in within a factory) more than most kernels. If you're building a distributed message passing system, QNX is great. If you're building a real-time state machine, there are other kernels that might be a better fit.

    Kernels are most applicable for applications where the processor has a very defined purpose and frequently must have very predictable responses. Linux and BSD can be abused to behave that way, but their real strength is their flexibiilty.

    If you need to add new daemons quickly and be confident that you aren't breaking other applications, then you want a "full OS" such as any of the Unixes.

    Personally, I've found the "loaded" kernels (such as VxWorks and QNX) to be of dwindling importance. When I do a system design I tend to end up with environments where I want a full Linux or BSD in order to have the latest in network stacks, or I want complete and total control of the processor. In the latter case I want the smallest kernel that will boot my state machine possible. I don't want efficient thread context switching, in those environments I don't want threads, just objects and state transitions.

  • Unisys didn't build the first ones. A company called Cemcorp (Canadian Educational Microcomputer Corporation) did, using the resources of a couple of other companies. Cemcorp's parent company was a holding company called Meridian Technologies []. At the time, Meridian also held MicroDesign (which did the hardware for the Icon, and eventually became part of Cemcorp) and Jutras Die Casting, among other companies. (Now Meridian does only light metal diecasting.) The first two series of Icons were manufactured in Brockville, Ontario, by a company called Microtel.

    The processor was the Intel 80186, as an earlier poster noticed. The reason was simple: it was effectively an 8086, and it was available. But with other Canadian companies like Dynalogic/Bytec-Comterm (makers of the Hyperion []) wanting 8086s, and Canada being a single distribution region as far as Intel was concerned, there weren't enough 8086s to go around. But nobody else (except the odd controller manufacturer) wanted 80186s. The QNX C compiler had flags to enable '186- and '286-specific instructions, but Cemcorp never used the '186-specific functionality.

    The Ontario Ministry of Education provided the seed money for the project. They mandated mostly Canadian content, so QNX was chosen for the operating system. The Waterloo microlanguages, already proven on the Commodore SuperPET [] were ported for teaching programming, and QNX's own C compiler was included if students wanted to write their own system stuff. It also had a bug-compatibile version of Logo. The Ministry of Education contracted out the development of a graphical shell called Ambience [] that had three levels of access control: the administrator, teacher, or student. Teachers had access to students' files; the administrator saw everything. There was shared space for showing off good stuff. It was a great concept. But execution was, well, part of the reason the Icon didn't really succeed, because it didn't work like an Apple, and it didn't work like DOS.

    So where'd Unisys come in? Well, in 1983 or so when this was getting started (I did co-op stints with Cemcorp from 1984 to 1987), the guys at Cemcorp didn't have the ability to support or market the product. They contracted with Burroughs for support, quality assurance, and marketing. Burroughs and Sperry became Unisys []in 1986, and took a greater interest in promoting the Icon, just as the government subsidy was running out. Unisys had taken over all but the design and integration of the product by the time I did my last work term with Cemcorp. With the dropping of government funding, the demand for DOS compatibility, and competition from Apple, the Icon ceased to be viable.

  • by William Tanksley (1752) on Monday June 16, 2003 @11:21AM (#6212680)
    VSTa [] is a free software OS inspired by QNX and Plan 9. Very nice looking, although when you run it very disappointing (it's slow).

    Much more interesting to me is the concept of exokernels [], a completely different OS organization which allows for /extremely/ fast operation. Some have suggested that Linux be refactored into an exokernel-like arrangement for multiprocessing: rather than trying to build a 256-processor single memory image Linux kernel (with all the horrid locking issues that implies), just build a 4 processor kernel, and when more processors are available, run multiple instances of it under an exokernel.

    (The most significant person who's pushing for this plan for Linux, by the way, is Larry McVoy, notorious author of BitKeeper.)


"If you want to eat hippopatomus, you've got to pay the freight." -- attributed to an IBM guy, about why IBM software uses so much memory