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!"
Yes they are around, in fact some more recent news about them came out of the JavaOne conference: http://rcrnews.com/cgi-bin/news.pl?newsId=13840 They are going to be integrating IBMâ(TM)s WebSphere Micro Environment.
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.
How small a thought it takes to fill a whole life
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
You can download a bootable CD from QNX.com 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.
CDE open sourced! https://sourceforge.net/projects/cdesktopenv/
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.
A deep unwavering belief is a sure sign you're missing something...
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.
Whenever the offence inspires less horror than the punishment, the rigour of penal law is obliged to give way...
Sorry, wrong. QNX USB support.
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
If you haven't taken the challenge yet, it's pretty cool. You can get it here too.
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.
The ______ Agenda
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.
The ______ Agenda
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.
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...
I am a viral sig. Please copy me and help me spread. Thank you
I can't believe this got a +5 insightful.
/. or me to give accurate information, go see for yourself.
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
SealBeater
-- Its survival of the fittest...and we got the fucking guns!!!
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.
Kirby
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)?
Yaz.
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.
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...
- Otaku no naka no otaku, otaking da!!!
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.
-"I still believe in revolution; I just don't capitalize it anymore." - srini!
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.