QNX: When an OS Really, Really Has to Work 514
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!"
Re:um (Score:4, Insightful)
QNX is a great operating system, but it's a much different market. It's not made for PCs, it's made for embedded, real time applications. You'll find QNX in routers, you'll find it in medical devices, and you'll find it in nuclear power plants.
What you won't find in QNX is USB support, drivers for a Sound Blaster 16, or Accelerated 3D drivers.
It's a great operating system, but comparing it to things like Windows, Mac OS, Linux, FreeBSD, or even Solaris and AIX are silly. QNX isn't designed to have any frills: it manages resources, incredibly well, and that's it. It doens't do complex scheduling, it doesn't do advanced 3d tricks, and it's not going to do much with the latest firewire hard drives. It will, however, guide a laser over someone's eye for Lasik and other such procedures a thousand times a year without a glitch.
QNX? ICK! (Score:3, Insightful)
From what I have seen there is nothing that QNX does that Linux can't do that would justify the license cost.
Re:A couple things (Score:5, Insightful)
Ummm...it is the operating system that matters -- the O.S. is the software that controls the hardware. Just like software on a PC can make the hardware do things it ought not do, software can make a precision laser be off by 1/100 of a millimeter, destroying someone's retina in the process.
Re:Inaccurate microkernel claims? (Score:1, Insightful)
BeOS was a microkernel. Wasn't necessarily commercially successful by some people's metrics, but it was certainly a sellable product.
Mac OS X is based on the Mach 3 microkernel.
The NT kernel is monolithic. About the only part that's segmented out is that it takes advantage of the 386 protected-mode privilege rings.
The rest of the article is alright, but that's one hell of a technical error.
OS crashes. (Score:3, Insightful)
The purpose of an operating system is to provide an abstraction layer between the hardware and application software, and between all of the tasks running on a machine. If done right, this prevents most crashing no matter what you're doing (as most software doesn't have the privileges needed to take down the whole system). If done wrong, application software can muck with things it shouldn't, and the whole system comes crashing down when something goes wrong.
Any of the 9x series of Windows, and WinME, fall into the second category. Windows NT (including 2K and XP), and various Unix flavours and clones (including MacOS X), fall into the first category.
While a general-purpose system has more potential points of failure in software - as you're running more software - this is not an excuse for it to be crash prone. A well-protected OS is vulnerable to bugs in the OS core and in the drivers interfacing with hardware, which will for the most part still be there even in a single-purpose system.
In summary, you can't blame windows crashing on it being a general-purpose operating system. There are plenty of general-purpose OSs that crash far less. There are special-purpose OSs that are designed shoddily, as well (it's just easier to catch that before it goes to market, because the test space is smaller).
FWIW, re. another thread, my understanding is that WinCE is a stepchild of NT (heavy rewrite to make it modular and to pare out functionality that isn't needed in embedded systems, while keeping most of the core OS design). That should make its behavior similar to that of NT.
Re:um (Score:1, Insightful)
Re:QNX? ICK! (Score:2, Insightful)
From what I have seen there is nothing that QNX does that Linux can't do that would justify the license cost.
Except not crash.....
I'm sorry but as much as I like linux I want something a little more robust running my nuclear power plants and laser eye-surgery machines. I think that warrants a little extra cost.
Re:QNX rules (Score:5, Insightful)
Microkernels have gotten a bad reputation because Mach/Hurd, for one reason or another didn't deliver. But that doesn't mean the approach itself is flawed.
Traditional monolithic kernels like Linux (and UNIX and NT/XP--and don't try pretending that NT/XP is a "microkernel") are appealing for budding operating system projects because it's easy to hack something together quickly. But those architectures don't hold up in the long run. You can see the same in ecology: fast growing, non-native plants often displace native plants quickly, but in the end, they die because they aren't well adapted to the long-term conditions.
Well, maybe if SCO wins, we can look on the bright side: it will finally get Linux out of its rut and create more opportunities for other kernels. Don't get me wrong: like everybody else, I'd much rather not change from the Linux kernel, but if I do have to change, I don't view it as all bad. (Of course, I don't think SCO has any legal grounds at all, but that is probably not related to whether they can win.)
Re:A couple things (Score:2, Insightful)
Any software/hardware device that is going to be used in the medical field is going to undergo many hours of intensive stress testing, whether it is running WinCE, Linux, QNX, VxWorks, iTron, or a homegrown solution.
No OS can be trusted implicitly, nor can hardware be trusted completely. However, at some point the definition of "good enough" must be decided and testing done to ensure that "good enough" level of availability.
You want to implicitly distrust a medical device running WinCE or Linux, but it is simply a gut reaction and not based on anything more than that. 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. They are for all intents and purposes equivalent, with the same possibility for failure.
Re:OS crashes. (Score:5, Insightful)
Re:A couple things (Score:3, Insightful)
the layered microkernel system is there to make sure the os never crashes. how does it do this better than wince or linux? well, since the drivers are out of "kernel space", even if one crashes, it will not bring down the whole os. in linux, if you yank out [device of your choice] while the system is using it, you may very well get a kernel panic. in qnx, the driver crashes, and the os moves on (maybe reloades it, maybe sends a warning to someone).
the second part that you're missing is that in many super-tight embedded systems, the driver IS the application. obviously this is not true for your palm or digital camera, but for software in a pacemaker or in a car brake management system, there is no "app".
and finally, if you've ever seen linux crash or wince bluescreen, for whatever reason, consider that in some places, that is just *not acceptable*. that is the difference, and that is why qnx and vxworks and psos and friends exist.
Re:QNX? ICK! (Score:1, Insightful)
Just because you don't hear about something doesn't mean it doesn't exist. Nowadays you hear a lot about Linux just because it's Linux: it's good PR to do it. It's the cool thing to do, and everyone wants their 15 minutes of fame.
(Not knocking Linux, just the attitude of some of its 'followers'.)
The Power of the niche. (Score:3, Insightful)
Comparing Microsoft v. Linux Is like comparing a Swiss Army Knife with a Leatherman. But systems like QNX and other niche OS's are more like a Hammer and Screwdriver. Although they don't have as much functionality as the Swiss Army Knife. They do their job better and are more reliable for their jobs.
Re:You're mistaken (Score:3, Insightful)
If you want to take that definition of "Good Enough," fine. It's "Good Enough" when it doesn't crash for it's entire 20 year expected lifetime. And now that we have defined what is "Good Enough" for this situation, it definitely isn't going to be WinCE or Linux. And that, of course, is the point of the argument. Someone keeps trying to say that WinCE and Linux are "Good Enough" to reach any targets assuming you can define what those targets are.
In the real world, we call that Hogwash. Ok, we call that something else, but I doubt Slashdot's lameness filter would let it through.
Re:A couple things (Score:3, Insightful)
Sure, you can take a huge luxury SUV and strip it into a go cart(sp?) (somehow), but it makes more sense to build a go cart from the ground up to be a go cart.
Re:QNX? ICK! (Score:5, Insightful)
That can depend a great deal on which version of QNX you are looking at. It you really have an older project that is running on say, QNX 4, then it would be painful. I've worked quite a bit with it. The most painful thing about it is that I remember when Linux looked and felt like that years ago. That's because QNX 6 is current. Most of the things that you've come to expect under Linux are available under QNX.
Where QNX really shines, is in faster context switches, and a predictable real time scheduler. Of course, if you invert the priority of your processes, good luck. The QNX folks have also provided a nice message passing library. Okay, there are other ways to handle interprocess communication. But their stuff just keeps on working.
The only reason that I would recommend porting away from QNX to Linux is if there was a specific need driving the port. If all of your other code is under Linux, or you need to save the licensing costs, or there are specific tools or libraries that haven't been ported. QNX has a pretty familiar feel to anyone familiar with multiple Unices.
Now the GUI libraries (I'm talking QNX 4 here, not the newer Photon stuff), are a bit of a pain. They harken back to darker days. The effort to port QNX 4 GUI code to anything else would be bigger than it is worth in a lot of cases.
QNX gets the embedded, real time stuff right. Don't underrate that.
Re:Inaccurate microkernel claims? (Score:3, Insightful)
The company never made money and went completely bankrupt. By whose metrics were they commercially successful?
I went to thier geek road show at U of Illinois in 1996 and was VERY impressed. This was when they were hyping the BeBox dual processor machine along with the OS. They were too afraid to challange MS on Intel hardware, so they went after the then floundering Apple and Motorola hardware. I think that if they had set thier sights higher, and on more common hardware, that they might still be around.
-B
Re:Some interesting points to note (Score:5, Insightful)
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.
What particular Windows design flaw are you thinking of here? (In other words, I'm far from a Microsoft apologist, but it's nice to back up your statements. :3 )
Protected memory space for the kernel or microkernel: Even Windows has that. The only problem is that "protected" is a very loose term for Windows. Unlike Windows, Unix and Linux doesn't allow any ordinary application to write to the kernel.
That's funny, I don't seem to remember being able to write to addresses above 0x80000000 on NT4, although I haven't tried loading a pointer with such an address and dereferencing it in purpose. Somebody with immediate access to a Win32 system could try this and tell us what happens:
The expected outcome and possible outcomes should be clear.(Win32 userland/kernel split is 2:2, unlike Linux's default 3:1. 2:2 seems a bit excessive to me, but ah well; i haven't thought that much about it. I know there are issues in 3:1 for stuff like page tables on large memory machines). If you're thinking of the bad old days of 16-bit Windows, please say so; it's important to know that you're comparing a broken OS implementation.
Re:you can download a free copy of Neutrino (Score:1, Insightful)
Re:QNX rules (Score:5, Insightful)
10 different ones passing messages to each other are clearly cleaner and often more efficient as well. It's the UNIX way. I mean, do you run one command line interface that has all programs linked into it, or do you run a command line shell that invokes programs as separate processes?
The detailed Mach approach itself is broken--far too complex and messy. But you can view Plan 9 as a kind of "microkernel"; that would be a UNIX-style "microkernel". And, of course, QNX is successful as well. The original Amiga OS was a kind of microkernel and worked like a charm.
Note that you can't compare Linux to the original UNIX design. The original UNIX design was kept religiously simple: one file system, a few machine types, etc. Linux, on the other hand, has zillions of modules and features.
So far, it didn't work for any real systems.
It has worked in plenty of real systems. But kludgy monolithic kernels simply have an easier time to attract developers initially--that's why systems like Linux and Windows have managed to grab a lot of market share in the OS area.
Why not expect QNX-like reliability everywhere? (Score:4, Insightful)
I grant that this is not a requirement for desktop users, for example, because no one's life is usually at stake if your instant message or e-mail doesn't go through (in fact that might be a blessing considering the content of some of them). And it would be really expensive to require all computer programs to be as robust as QNX appears to be.
But leaving that aside for a second, why shouldn't people expect all computer programs to be that reliable? Why do I have to put up with the annoyance of killing processes or rebooting even if it is just an annoyance? Shouldn't we try to making computing that reliable always? Is it possible?
I guess it might not be for certain kinds of applications since a user could theoretically input or try to process anything, but it seems that the QNX system isn't written to be bulletproof in that way, it is just written with the assumption to trust nothing and recover gracefully from all errors. Should programs just be that way? Or is it improbable to be able to create a 3-D graphics card/word processor/what-have-you with that kind of reliability?
Maybe we can't do this because of the anomaly that will become the One or maybe I should have laid off the peyote before writing this, or maybe I would remember something from my CS degree that reveals I am being stupid but can't because I'm too tired. I'm getting ver-clemped: feel free to discuss amongst yourselves or mod me down.
Re:QNX rules (Score:5, Insightful)
A lot of the decision depends on the architecture involved. I hope someone more knowledgable than myself will comment on this, but as far as I know, the reason BeOS started to implement networking into the main kernel instead of making it a microkernel "server" was because the x86 architecture is much slower in switching between sub-functions than the PowerPC was (I've read 10 times slower but can't remember the source).
The two monolithic operating systems you criticize are both i386-centric, so a true microkernel probably wouldn't be such a hot idea.
QNX's design is great for certain applications but not all. I looked into it for an intel based SMP homebrewed but critical (as in the systems behind it cost over $1 million) firewall and decided a more traditional i386 operating system would be better.
I know you're not a culprit here, but being a fanboy for one design approach or another is just bad engineering sense. It's something I see all the time and I'd wish they'd teach a lot more critical thinking skills at the high school level because of it.
Re:QNX rules (Score:5, Insightful)
Well, first of all, a microkernel architecture doesn't require any address translation or additional overhead at all; there have been microkernels that run without any MMU at all. And QNX seems competitively fast.
But let's say, just for the sake of argument, there were overhead associated with it. I would rather have a reliable if slower 2.6 or 3.0 kernel now with the features I need than see the 2.4 kernel limp along from bug regression to bug regression.
Even QNX has faculties for 'lightweight processes' that have independant stacks and a common global data sandbox.
Which only goes to show what I was saying: a microkernel architecture does not require that every single little OS process runs in a separate address space. In fact, a good design would let you decide on the fly whether to isolate a process (and pay the overhead) or run the process in a global address space.
Re:Why not expect QNX-like reliability everywhere? (Score:2, Insightful)
I think that much of Windows' market strength is owed to the multitude of RAD (Rapid Application Development) options available behind it that give it such a huge software library, and Linux is beginning to share this same strength. Of course, I am no expert, and this is all wild proposition, but that's my two cents.
Re:QNX rules (Score:5, Insightful)
I agree with you that address translation is a problem, however, this is mostly a problem with the x86 architecture. The x86 flushes the TLB on every address space switch. If we had a decent tagged TLB, this wouldn't be a problem. Indeed, it isn't a problem on most architectures that QNX is asked to run on. Repeat until enlightened: Context switching is only expensive on the x86 architecture.
The "additional costs" for IPC are mostly an illusion, since we're talking about IPC which is tightly integrated with the kernel, not SysV IPC. Yes, it costs to copy memory, but the cost is there in Linux too; it's just a user space -> kernel space copy rather than a user space -> user space copy.
Having said that, it may be possible to write an OS for which the context switching is much cheaper. L4 uses a neat scheme where a small part of everyone's address space is allocated to other small processes, so context switching only requires a change of segment, rather than a change of address space mapping. IPC is very fast under L4 if you're doing it with a small address space task.
I've wondered that myself. I can only conclude that these projects are either experiments which accidentally escaped the lab, or the hackers who wrote them have no sense of sound software engineering principles.
Re:QNX vs. Linux (Score:2, Insightful)
But faster? Can we have some evidence?
Re:QNX rules (Score:3, Insightful)
Leaving asside the figures, that's an odd definition of "worthwhile". Do you actually need to serve 10,000 static web pages per second on one box? Do you need it so much that you're prepared to have your machine's kernel (not just the superuser) compromised if an attacker finds a bug in Tux?
We modularise our machines for a very good reason. Tux is a cool hack, but I'd quietly retask any sysadmin working for me who tried to use it in a production environment. An extra box or two plus a load balancer are a small price to pay if we find we really need more pages per second.