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!"

Comments

QNX is still around?

[RLiegh]

Wow. Do they still have the web-browser-on-a-bootfloppy offer?

Re:QNX is still around?

[$calar]

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.

Re:QNX is still around?

[njan]

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

spawn() hangs system

[Anonymous Coward]

We are running QNX 6.1 Patch B on PowerPC's with a custom BSP.

We have ported QNX to two custom boards, one based on the MPC7410 PPC and another based on the MPC755. The MPC7410 system is running fine. The new port to the MPC755 has a nasty problem. Anytime spawn() is invoked, the entire QNX system hangs. All processes stop, regardless of priority. This system hang doesn't happen on the MPC7410.

It looks like it's just spawn() that is the problem. We can start and kill large processes from the ksh shell just fine.

This problem does not happen on our MPC7410 system. Other than this spawn problem, both systems run great.

Both systems have MPC107 controllers, 128 MB of SDRAM, and the same Ethernet controller. The MPC7410 system has 2 MB of external L2 cache, the MPC755 system has 1 MB of external L2. We believe that memory and cache integrity are OK.

What could spawn() be doing to take down the whole kernel on the MPC755?

Here is a simple example program that runs fine on the MPC7410, but completely hangs QNX on the MPC755:

#include <stdio.h>
#include <spawn.h>

int main(int argc, char** argv)
{
char* path ="/bin/ls";
printf("About to spawn %s\n", path);
fflush(stdout);
spawn(path, 0, NULL, NULL, NULL, NULL);
printf("Spawn is done\n");
return 0;
}

Here are the PPC registers on the MPC755 board seen by typical applications:

MSR = 0000.9932
HID0 = 0010.C0A4
HID1 = 8000.0000
L2CR = BB00.0060

We've submitted a request to QNX support for help on this. However, if anyone has any thoughts regarding this problem then please share.

Thanks

Re:spawn() hangs system

[Anonymous Coward]

From the docs:

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

Re:um

[b0r1s]

You're missing a little ...

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!

[SmileeTiger]

I am currently working on a software development project migrating code _away_ from QNX to Linux. Every time I have to work on the old QNX project I want to bang my head against the monitor.

From what I have seen there is nothing that QNX does that Linux can't do that would justify the license cost.

Re:QNX? ICK!

[jjh37997]

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? ICK!

[alienw]

Actually, most people using GPL software send a patch back to the maintainer. Most companies using BSD software don't contribute anything back - usually, it's just an extra layer of process that's not worth the hassle. I haven't seen Microsoft send patches to BSD even though they used to use the TCP/IP stack and other stuff in Windows. In contrast, almost every large corporate user of Linux (HP, IBM, Compaq, etc) contributed tons of code back.

Re:QNX? ICK!

[b17bmbr]

I haven't seen Microsoft send patches to BSD even though they used to use the TCP/IP stack and other stuff in Windows

you really want microsoft code in BSD?

Re:QNX? ICK!

[dsplat]

I am currently working on a software development project migrating code _away_ from QNX to Linux. Every time I have to work on the old QNX project I want to bang my head against the monitor.

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:QNX? ICK!

[pHDNgell]

Right -- and also avoid receiving any improvements to the software performed by other users. A bug in a BSD program can stay unfixed until the author finds it. In a GPL program, it gets fixed as soon as ANYONE finds it.

That doesn't even make sense. I rely on BSD systems that have user contributions regularly, including fixes.

Also, can you name a single embedded device that uses BSD? Embedded linux is hot. Embedded BSD is unheard of.

You don't happen to work in an embedded sector, do you? You hear about embedded Linux because you're listening for info on Linux. I work for a company that produces embedded systems (we sell approximately 2,500/day) and we've just recently considered moving away from PSOS. Linux was absolutely not an option for a variety of reasons. The decision came down to NetBSD, OpenBSD or FreeBSD.

The only strange thing was that FreeBSD was chosen because they were further along in granular locks that are required for a preemptive kernel.

There are many reasons for people to go with BSD systems...licensing is a big one, but take off your blinders and you'll find lots of technical reasons as well.

Re:QNX? ICK!

[ComputerSlicer23]

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.

Kirby

Re:QNX? ICK!

[smallpaul]

Most companies using BSD software don't contribute anything back - usually, it's just an extra layer of process that's not worth the hassle. I haven't seen Microsoft send patches to BSD even though they used to use the TCP/IP stack and other stuff in Windows.

Yeah, well, you're talking about Microsoft. Obviously they are a special case. Compare to Apple/Darwin. Or Apple/KHTML. Or IBM/Apache. It only makes sense to let someone else maintain your patches for you rather than do it yourself!

Re:QNX? ICK!

[scrytch]

I'm a denizen of LambdaMOO, one of the longest-running social MUDs out there. It chugged along for nine years on a SparcCenter 1000, with uptime of hundreds of days, going down for maintenance because of bugs in the moo process itself. It just recently moved to a linux box, which is much quicker, but I just got this news item on login.

Saturday, June 14, 2003
OUTAGE
Network card driver randomly decided to shut itself down at around 8 this morning. Actually it's done this a few times before already (most of which I was around to catch after a few minutes; we weren't quite so lucky this time). I originally thought this was dhcpd rising from the grave but now I'm not so sure anymore. Time to see if a reboot helps.

It's not so much that Linux is unstable, it's just that the stability seems to be a function of whatever mood Linus and random driver writers are in at the time of whichever version is released. Right now the OS randomly kills processess when you start running out of memory. Randomly.

There's a reason people use QNX, and the fact that their lunch money won't buy a copy of it isn't usually a factor.

you can download a free copy of Neutrino

[lingqi]

Neutrino being the QNX-based PC OS.

This should prove to be interesting in several ways:

1) hands on experience with an "never-crash" OS
2) if QNX is the inmmoveable object, and /. is the unstoppable force, will this cause the universe to end?

p.s. specialized OS don't crash because it's exactly that - specialized. I think windows crash so much because (part of the reason) it runs on so many kinds of hardware, for one. As much as I will get flamed, in OEM applications, like, say, most of the new fancy I-will-never-be-able-to-affort oscilloscopes and the likes, windows usually don't crash.

software and hardware goes together - you can't ALWAYS blame on the software; i am not saying MS writes good code, it's just that I don't think is 100% their fault.

maybe 98%...

Re:you can download a free copy of Neutrino

[Anonymous Coward]

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.

Re:A couple things

[aggieben]

It isn't the operating system controlling the grinding of lenses or correcting the tilt of the TGV. It is a function of the hardware to do these things. That they report back to some software (which could frankly be run on any embedded OS) which then tells them what to do next is almost irrelevant.

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.

QNX rules

[CausticWindow]

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.

Re:QNX rules

[73939133]

Let me second that. I think that's the direction open source operating systems should go.

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:QNX rules

[OldMiner]

Linux and Windows arent "bad" they are just profoundly LAZY. Microkernels and doing everything right is way too much work.

My brain says: don't feed the trolls, but I'm compelled anyhow.

The NT kernel, meaning NT, 2000, XP, 2003, is a microkernel. Although obviously different in design, the habit of Linux to push almost everything into userland using modules keeps the kernel relatively small and object orientedish.

I won't go into memory management, rings, IRQLs, and all that fun stuff as I'm pretty sure you were just trying to incite debate to begin with.

Re:QNX rules

[73939133]

what's cleaner and more efficient, a single program or 10 different ones passing messages to each other?

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.

Re:QNX rules

[xenocide2]

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:QNX rules

[CoolGuySteve]

I question the validity of blindly praising microkernels.

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

[73939133]

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.

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:QNX rules

[Pseudonym]

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.

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?

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 rules

[MarkSwanson]

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 rules

[Nevyn]

a microkernel architecture does not require that every single little OS process runs in a separate address space.

Then, by that definition, Linux 2.4.x is a microkernel. The filesystems, and the networking layer (and each of the different protocols) are all seperate modules ... which are only very loosly tied to the core.

Sure, most of those don't have a specific process associated with them ... but that's mainly an efficency thing. Even then on my laptop there are eleven different processes that are kernel spawned/owned processes.

Re:QNX rules

[Pseudonym]

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.

Kids In The Hall

[niko9]

Just picture Bill Gates with a fro, runnning amok on the street of Canada fully armed with thumb and index finger yelling: "I will crush your little precocious head!"

download link here

[lingqi]

sorry for being a dork and replying to myself, but look here for Neutrino. right side of the page.

Re:A couple things

[wfberg]

WinCE a good embedded system? Hmm.. Isn't that the WinCE that is at the heart of PocketPC? The embedded OS that brought blue screens of death (well, ok, depending on your color scheme a light khaki screen of death) to PDAs? Yeah. I trust WinCE to run my heart monitor if I ever end up in an Intensive Care Unit... *cough*

Pronouciation?

[hoser]

Kyu-nicks? or Kyu-Enn-Eks?

Re:Pronouciation?

[heli0]

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.

Re:Pronouciation?

[JerryKnight]

According to this the pronunciation is the former.

Re:um

[Cylix]

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

[SoSueMe]

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

[christurkel]

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.

Re:Inaccurate microkernel claims?

[Anonymous Coward]

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

[Dolphinzilla]

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

Some interesting points to note

[UnknowingFool]

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.

Re:Some interesting points to note

[Kourino]

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:

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
char *p;
p = (char *) 0x80000001L; // start of kernel address space + 1
*p = 0; // this *should* terminate process
MessageBox (NULL, "Nyah nyah, Kourino doesn't know what he's talking about", "Ha!", 0);
return 0;
}

The expected outcome and possible outcomes should be clear. :D

(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:Some interesting points to note

[evilviper]

Well this is somewhat of a generalization.

I usually call them FACTS, not "generalizations".

The difference is that it the way Unix and Linux are designed, it is far less likely.

I've had it happen many times. A few of the reasons Windows is so unstable is that so many programs run with root privlidges, and that the system itself is so bloated and crappy. However, even as bloated and crappy as it is, if it was a microkernel, it would run wonderfully because that COULDN'T CAUSE A PROBLEM assuming the very small base was written properly.

Could someone please tell me why no other OSes are microkernels? You would get 100% stability, and as an added bonus, there are never any times when one part of the system can even slow down another part even slightly... Really incredible things they are... Why don't we see any good microkernel systems, preferably designed and written by pros? OpenBSD likes security, why don't they take up the job? That's really the only way to ever get 100% security (even if you want to run buggy and/or untrusted apps).

Unix and Linux doesn't allow any ordinary application to write to the kernel.

No, but programs running as root, or SUID are. Also, all the drivers in the kernel are as well. I've had Unix system freeze up because of writing CDs, loading videocard drivers, and other privlidged things which wouldn't happen with a microkernel.

but their market is really a niche.

It's on hell of a niche...

Besides, that's their niche because that's where the money is, and what they've designed it for. If they would invest some resources into the things most people want in a desktop, I have no doubt they could do a good job of taking over that as well.

Since it is a niche, it doesn't offer the interoperability that other OS offers.

It's a plain Unix system as far as the user/developer is concerned. What more interoperability could you want?

Re:Some interesting points to note

[evilviper]

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

Re:Some interesting points to note

[rabidcow]

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)

I remember using qnx in a Canadian Highschool

[Billly Gates]

Canada's school systems are strange compared to American schools I have previously attented. I have found their computers horrible inadaquite and out of date.

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.

Re:I remember using qnx in a Canadian Highschool

[Yaztromo]

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.

Re:I remember using qnx in a Canadian Highschool

[wing03]

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.

Re:I remember using qnx in a Canadian Highschool

[uw_dwarf]

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.

Re:Inaccurate microkernel claims?

[be-fan]

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.

Crap...

[SoSueMe]

Should have linked here.

OS crashes.

[Christopher Thomas]

p.s. specialized OS don't crash because it's exactly that - specialized. I think windows crash so much because (part of the reason) it runs on so many kinds of hardware, for one. As much as I will get flamed, in OEM applications, like, say, most of the new fancy I-will-never-be-able-to-affort oscilloscopes and the likes, windows usually don't crash.

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:OS crashes.

[Ivan the Terrible]

Er, WinCE doesn't provide "real-time performance", and least not the way the phrase is understood in the embedded world. It has too much latency and not enough determinism. It does, however, provide a familar GUI for embedded devices, so it is only useful in embedded systems where missing a deadline is not catastrophic.

Re:OS crashes.

[IronChef]

It does, however, provide a familar GUI for embedded devices...

I think it is reaching to call WinCE's interface familiar. My first reaction upon using a PocketPC was, "wtf is going on?!"

I guess it is more familiar than, I dunno, cattle prod torture, but that isn't saying much.

I love my iPAQ anyway though.

Zzzzot!

I read slashdot using QNX

[leighklotz]

I read Slashdot using QNX, on an Audrey. I almost bought another one at a garage sale today for $20, but it had no power supply. Plus the keyboard was Lime.

Re:um

[imnoteddy]

What you won't find in QNX is USB support

Sorry, wrong. QNX USB support.

Re:um

[Anonymous Coward]

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

[hendridm]

If you haven't taken the challenge yet, it's pretty cool. You can get it here too.

Re:QNX Floppy Challenge

[DrXym]

This is not to knock the demo which is cool, but I'm surprised that something similar hasn't been attempted with Linux. While the QNX microkernel is small (which helps) after throwing in the various disk, network, mouse, drivers it's probably no different than what you could achieve in Linux. We have already seen the likes of Toms RTBT which pack a single disk with an amazing amount of command line stuff.

I wonder if some of that could be jettisoned for some kind of microwindows based GUI and perhaps a browser of some kind. Having tried Knoppix and LNX BBC also, I think these things are inherently cool and more importantly useful.

It gives a warm fuzzy feeling to know that you can carry around a disk or CD which boots into a full blown emergency repair kit or demos what can be done with Linux. The best that has so far been mustered for Windows is the excrable recovery console - something while better than nothing is still incapable of solving all but the most basic problems.

Dan Hildebrand would be happy!

[farrellj]

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.

ttyl
Farrell

Re:Only commercial microkernel?

[csirac]

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?

[cgenman]

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:Interesting?

[Aussie]

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

Does that mean it crashes on leap years ?

Re:We Will Crush You?

[100lbHand]

1. Crush your enemies 2. See them driven before you 3. Hear the lamentations of their women 4. ? 5. Profit!!

Wait until...

[Bull999999]

I'm pretty sure AOL, RealPlayer, and Bonzi Buddy will find a way to crash QNX.

Re:A couple things

[ObviousGuy]

That is a ridiculous statement.

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:A couple things

[cgenman]

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?

[Horizon_99]

What you won't find in QNX is USB support, drivers for a Sound Blaster 16

are you sure about that?

Re:We Will Crush You?

[saden1]

Last time I checked Microsoft is always crush mood. Microsoft doesn't have to utter the words, it is always implied.

If it was legal, they'd have âoeKicking Devisionâ who's whole objective is to kick the competition in the gonads.

Re:A couple things

[joe_bruin]

ah, but you're missing several points of the embedded system design.

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:We Will Crush You?

[napoleonin]

We Will Crush You...

Waiting for the inevitable joke comparing Bill Gates to Khrushchev...

Speaking of live CDs

[Joe Tie.]

A project worthy of any Robot finds kitten fan, QNX for the Dreamcast.

Bullet Proof

[the eric conspiracy]

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:Bullet Proof

[Idarubicin]

Reminds me of a story from this page:

About a year ago, I was called out to do field service. When I got to the lady's house and was let in, the first thing I noticed was the smell of gunpowder. The second, the double barreled 12-gauge shotgun lying on the couch. Third, the big gaping hole in the side of her computer. (It was one of those Macs where the CPU and monitor are in the same housing.)

I looked at her. She was a little grey haired woman, around 60 or so. Had she? Not possible. Still, I had to ask.

Me: "Did you shoot...?"
Customer: "Yes, I got a little mad at it. They told me I couldn't hurt it, but I think they were wrong. Can you salvage anything?"

I mumbled something about not being a Mac tech and told her I would send one out as soon as I could. Then I burned rubber out of there.

About a month later, my boss called me in; he had the woman on hold. She had apparently complained that I was not competent and that I had lied when I said I would send out a competent Mac tech -- or perhaps I just hadn't been able to find anyone competent working for us. I filled him in. He paused for a second, picked up the phone, and said, "Ma'am? Did you put a shotshell into your computer? ... Uh huh...I'm sorry, ma'am, we really can't...well, no.... I'll try to send one out.... Nice doing business with you...." He hung up, looked at me, and said, "You think any of our Mac techs will go?" I shook my head. "Me neither."

We heard from her again last week, when my boss told me that the woman had called up to cuss me out, saying not only was I a "young whippersnapper" but also a liar, since one of our competitors had fixed her computer just fine, even fixing the little scratches and stuff on the monitor glass. That sounded fishy, so I went over and talked with the techs. After a case of canned drinks and a few bags of junk food, I wormed the whole story out of them. Apparently, about the only salvagable part was the hard drive (which the buckshot had missed), so they took it out, went out and bought a whole new computer, slapped the hard drive in, and presented it to the lady as her repaired computer -- of course charging her an arm and a leg.

Re:Bullet Proof

[nordicfrost]

Having worked with Tandem, I can tell you that a bullet stopping the system would have to be very, very well fired. In our Tandem systems EVERYTHING was at least redundant. Often put in two mirrored cabinets with internal redundancy. This meant that if you shot a bullet into one of the cabinets, it would probably function on the internal redundancy. If not, the other cabinet would take over. The system I know did not have a single unplanned second of downtime in 13 years. Actually, it did not have any downtime in that time, since the dual cabinet layout made it possible to do large scale updates of hardware and software without bringing the system down.

Re:A couple things

[alienw]

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.

The Power of the niche.

[jellomizer]

There is defiantly a value in the niche markets. Unfortunately people/companies/communities like Microsoft and Linux are targeting the be the best general purpose OS, And when people get an OS they always try to find the best General Purpose OS. Even if they are using the OS for 1 or 2 jobs. The smart thing to do is to find OS's that actually specialize in the jobs that need to be done. Designing General purpose software comes with a lot of tradeoffs in its design, so you are getting a best OK system for the job. While if you actually find the OS that handle the niche job. You will often find that they come with a lot less tradeoffs or better focused tradeoffs in its design, is works a lot better for the job it is intended.
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.

A fire-and-forget controller...

[PSaltyDS]

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.

Qnx: Microkernel, real-time, small, and fast

[Teckla]

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

Re:You're mistaken

[cgenman]

The individual components of the system, the main, 1st, and 2nd local backups, were due to be replaced every 20 years. It couldn't crash, but it could be swapped out in a controlled (and very carefully planned, programmer intensive) fashion.

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:You're mistaken

[OldMiner]

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.

Re:We Will Crush You?

[lostchicken]

No. There's no comparison. One was the head of an evil empire, the other is the head of the Evil Empire.

Re:A couple things

[rzbx]

Still, which would you trust with your "gut", a stripped OS to operate on you or an OS built from ground up to never fail?

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:Inaccurate microkernel claims?

[Ralph Wiggam]

"BeOS was a microkernel. Wasn't necessarily commercially successful by some people's metrics."

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:um

[SealBeater]

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.

SealBeater

Re:A couple things

[Stephen Samuel]

1) It isn't the operating system controlling the grinding of lenses or correcting the tilt of the TGV. It is a function of the hardware to do these things. That they report back to some software (which could frankly be run on any embedded OS) which then tells them what to do next is almost irrelevant.

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.

QNX reliability

[Space]

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

Re:QNX reliability

[xenocide2]

Interesting question reguarding the software though. What should you do when the log writing (for now lets ignore error logging) fails? On one hand its not a catastrophic failure in itself. As you mentioned the device was working fine. On the other hand, if anything was going wrong imperceptibly then you're in big trouble.

First, you clearly can't write another error to the log stating you cant write to the log. It sounds silly, but sometimes people write this and plan to consider the question later. When later never rolls around, problems can occur.

Second, you could shut the system down alltogether. After all, the system is failing and if left unchecked could cause loss of life and/or property. But it seems a bit paranoid to shutdown over a diagnostics error; downtime is money lost. But on the plus side, you know the problem will receive attention.

A third alternative is to add some form of low level error system. The downside is even the warning 'lights' can go unnoticed, or simply ignored. This happens especially with things like "error code: 4343." The THERAC 25, in part suffered from such an enigmatic design.

Another is to just wait for an error more catastrophic to come up, and decide what to do then. Indeed, the parent post implies that this is an acceptable procedure: rather preemptively strike the hardware down, and incur delays on production, one can just wait for a real problem to arise. But this surmounts to just ignoring the problem.

Sadly, I don't think any reliable consensus on what to do will be geared towards safety for a long time. Professional Engineers are liable for any disasters that may occur as a result of their failure in design or inspection. Until software designers (or perhaps "software engineers") are assigned the same level of liability, I doubt that anyone will consider these topics seriously.

Re:QNX reliability

[WinPimp2K]

I also love QNX - even though I have not done any active work in it for over five years.

QNX Trivia: when QNX Software was still called Quantum Software Systems Ltd., they called their operating system QUNIX (which should answer any questions about how to pronounce the name). However, after a visit from AT&T's lawyers, they decided to drop the vowels.

Back in 1985 I wrote a Point-Of-Sale application for video stores. It used QNX version 2 in real mode (8088s and 8086s) or in protected mode (80286, later 386 and beyond). And even on the lowly 8088 machines, it was possible to run the application for two users (main console and one dumb terminal in 640K). With a 286 machine, and a multiport serial card, 11 users could be supported with just 4 megs of RAM (but the hard drive could be a bottleneck) At one point (1990) over 600 video stores used that software. That app was written and compiled under the "K&R C compiler - not ANSI C" that QNX provided back then. The OS came on two 1.2M floppies, the compiler came on a third floppy.

There are still 30 odd video stores running that software and they will be using it as long as their hardware holds out. (It is getting harder to find P166 or 486 class machines...QNX 2 will not run on anything faster and the upgrade path is expensive)

They use it because the only problems they experience are hardware problems and operator error. The OS can't protect you from a failed power supply or a direct hit from lightning. It also can not protect you from the superuser (root) person who types in something like:
"zap /cmds [ENTER]"

Several places just do not turn their machines off - ever. So far as I know the best record for uptime was nearly ten years. Some would have been better, but there was an occasion requiring some mandatory "downtime" a few years ago when everyone had to upgrade their apps - but not their OS.

Imagine........

[ONOIML8]

Just imagine a Beowolf cluster of these.

Doh! Wait! QNX doesn't do that.

Never mind.

Re:Imagine........

[Rolman]

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

Re:A couple things

[AndroidCat]

* Starting Laser
! Garbage collection interrupt
! Garbage collection complete
* Now where was I...

I'm not saying WinCE couldn't do it, mostly, but Microsoft usually hangs too much stuff in the OS for me to trust it. (There's a reason for that "not to be used in medical uses" legal weasel disclaimer on lots of software.)

If the Air-Control Syetems ran MS software...

[Dr Reducto]

Good thing the FAA uses QNX, cause if they ran MS software, it would go something like this:

Air Traffic Boss: How's it going?

Air Traffic Controller: Fine.

Boss: What's That? (Points to blue screen)

Controller: Oh, that happens when we try to track more than three planes.

Boss: Why does it do that?

Controller: We only purchased a 3-plane license. If we try to track 4, Palladium kicks in, and the whole thing locks up.

Boss: Doesn't that sound, you know, dangerous?

Controller: Not as dangerous as this! (plays an illegal mp3, sirens blow, and all machines are shut down, power is cut off, forcing runway lights to turn off, while planes crash like crazy.)

and attracting developers isn't important?

[dh003i]

It is important that whatever approach you take -- if you want it to succeed in the long run -- should attract developers to your idea and keep them there. Obviously, micro-kernel's haven't done that. Irrelevant of their *theoretical* advantages if done just right. Who cares if they might be more efficient or faster theoretically if they don't attract any developers and take forever to evolve? Monolithic kernels, despite their theoretical inferiority, will be faster and more efficient because more developers will be working on them, and will be able to resolve inefficiencies faster.

Gordon Bell - I thought he worked for Microsoft

[HidingMyName]

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.

Embeded Windows dont crash...

[CrackersnSoup]

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.

Crackers

Re:Old article!

[ozric99]

Hey! I read the article. It's something about SCO being naughty, right?

Re:Inaccurate microkernel claims?

[rabtech]

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

Re:We Will Crush You?

[ignorant_newbie]

>We Will Crush You...
>Waiting for the inevitable joke comparing Bill Gates to
>Khrushchev...

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.

Re:you are using it?

[SealBeater]

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

QNX Pro (driver devel) and Con (no usb strg, jfs)

[virtigex]

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.

Message passing is basic

[Animats]

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.

Compare Context Switching times

[POds]

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.

Re:Compare Context Switching times

[SuiteSisterMary]

My question would be, are those hard numbers?

IE, is it 'QNX will switch in 40 microsecs, period. AmigaOS will switch in 4..usually...but sometimes, it takes a lot longer...depends on what you're doing, really...'

Why not expect QNX-like reliability everywhere?

[Knight2K]

I've seen a lot of posts in this thread that make the point that QNX isn't really for workstations/PCs etc... it is for when things absolutely, positively must work always.

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:Why not expect QNX-like reliability everywhere?

[RobHornick]

It's definitely an admirable goal to have all of computing be rock-solid like this. But I think that it's somewhat illuminating that QNX is not the "system of choice" for many of the applications where you see Linux in use. It must be to some extent reliant on the ability to develop software for that environment, and based on the company behind QNX's considerable investment in making it as easy as possible to develop for QNX, it must be assumed that while QNX's architecture makes it very stable, it also makes it more costly (perhaps not in dollars per se, but in some aspect) to develop either the applications or drivers that would make QNX an operating system "for the masses."

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:Why not expect QNX-like reliability everywhere?

[Animats]

But I think that it's somewhat illuminating that QNX is not the "system of choice" for many of the applications where you see Linux in use.

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.

A lil history...

[Thelonious Monk]

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

QNX vs. Linux

[Taco Cowboy]

Now, we have the article describing QNX as the quintessential "When Software Really, Really Has to Work" OS.

How about Linux ?

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

If not, when can we expect Linux to gain that status ?

Re:QNX vs. Linux

[Anonymous Coward]

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?

Re:QNX vs. Linux

[Eunuchswear]

More stable? Arguable.

But faster? Can we have some evidence?

Re:QNX vs. Linux

[cait56]

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.

Re:Inaccurate microkernel claims?

[ComputerSlicer23]

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.

Kirby

Inaccurate microkernel claims, i.e: lies

[frovingslosh]

Isn't the Windows NT kernel supposed to be a microkernel?

According to Microsoft sworn testimony, the OS has the browser so tightly intigrated into it that it can't be removed. That's hardly a microkernel.

Alternative sources

[OzJimbob]

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.

If Microsoft made cars

[SilentReproach]

From the article: Big Blue's Skip McGaughey, who has worked on making QNX the software behind IBM's new automotive computer systems, says the company chose QNX because it represents the "very best" of real-time operating system technology. "The typical automotive end user would have no patience with a unit that freezes up or experiences systems errors," he says. Wonder which archrival company's software he's thinking of.

This reminds me of the time when at COMDEX, Bill Gates reportedly compared the computer industry with the auto industry and stated "If GM had kept up with technology like the computer industry has, we would all be driving twenty-five dollar cars that got 1000 miles to the gallon.

In response to Gates' comments, General Motors issued the following press release (by Mr. Welch himself, the GM CEO).
If GM had developed technology like Microsoft, we would all be driving cars with the following characteristics:

1. Every time they repainted the lines on the road, you'd have to buy a new car.

2. Occasionally your car would just die on the motorway for no reason, and you'd have to restart it. For some strange reason, you'd just accept this, restart and drive on.

3. Occasionally, executing a manoeuvre would cause your car to stop and fail to restart and you'd have to re-install the engine. For some strange reason, you'd just accept this too.

4. You could only have one person in the car at a time, unless you bought a "Car 95" or a "Car NT". But then you'd have to buy more seats.

5. Amiga would make a car that was powered by the sun, was twice as reliable, five times as fast, twice as easy to drive - but it would only run on five percent of the roads.

6. Macintosh car owners would get expensive Microsoft upgrades to their cars which would make their cars go much slower.

7. The oil, engine, gas and alternator warning lights would be replaced with a single "General Car Fault" warning light.

8. People would get excited about the "new" features in Microsoft cars, forgetting completely that they had been available in other cars for many years.

9. We'd all have to switch to Microsoft gas and all auto fluids but the packaging would be superb.

10. New seats would force everyone to have the same size butt.

11. The airbag system would say "Are you sure?" before going off.

12. If you were involved in a crash, you would have no idea what happened.

13. They wouldn't build their own engines, but form a cartel with their engine suppliers. The latest engine would have 16 cylinders, multi-point fuel injection and 4 turbos, but it would be a side-valve design so you could use Model-T Ford parts on it.

14. There would be an "Engium Pro" with bigger turbos, but it would be slower on most existing roads.

15. Microsoft cars would have a special radio/cassette player which would only be able to listen to Microsoft FM, and play Microsoft Cassettes. Unless of course, you buy the upgrade to use existing stuff.

16. Microsoft would do so well, because even though they don't own any roads, all of the road manufacturers would give away Microsoft cars free, including IBM!

17. If you still ran old versions of car (ie. CarDOS 6.22/CarWIN 3.11), then you would be called old fashioned, but you would be able to drive much faster, and on more roads!

18. If you couldn't afford to buy a new car, then you could just borrow your friends, and then copy it.

19. Whenever you bought a car, you would have to reorganise the ignition for a few days before it worked.

20. You would need to buy an upgrade to run cars on a motorway next to each other.

Not as freezesafe as I thought

[1110110001]

About one year ago an other student and I tried the QNX live CD. Neutrino looked quite fine and it was an interesting OS.

But after doing a floodping at the QNX machine it stopped doing anything. I don't know if it crashed but even the window is able to handle these floodpings.

However maybe it got fixed - I'll test it again in the next days.

b4n

Free software inspired by QNX:

[William Tanksley]

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

-Billy