Slashdot Mirror

I haven't used a new MS OS in quite a while, so you may be correct. Perhaps the red screen of death has replaced the blue screen of death, so you would be then quite correct:)

Actual, bonafide system crashes are virtually non-existent for most users, though of course they do occur for a small subset with shoddy hardware and/or shoddy drivers (though the same case exists for Linux as well. The OS can protect against crappy hardware, and both operating systems give kernel-mode drivers enough leeway to take down the system, which is why on both systems you need quality drivers. If one really wants super-stability, QNX is always available). I use both XP and 2003 daily, under very intense scenarios, and haven't seen an actual system crash in literally years. The same holds for my peers. Anecdotes suck, but I haven't heard from anyone (without an agenda) complaining about system crashes in a long, long time.

You're right that there still is a Microsoft tax, however that gets to the core of why I left the prior message: Linux has a tonne of things going for it, but instead of evangelizing the positives of Linux, somehow it always comes down to the negatives of Windows. To make matters worse, this hyperbolic evangelism oft resorts to gross exaggerations (the frequency of crashes and the cost of Windows) or completely made-up "facts". It diminishes the cause more than it helps it.

QNX isn't a Linux derivative. It's not even a UNIX derivative. It's a POSIX-compliant microkernel, with a totally different underlying architecture than Linux. Latency is much better than Linux, because the kernel just handles message passing, CPU dispatching, and timing - everything else, like file systems, drivers, and networking, is in user space and preemptable. Overall performance is slightly worse than Linux.

The newer real-time Linux variants based on the 2.6 kernel are getting to be decent. 2.6 finally got most of the long interrupt lockouts out of the kernel, and allowed preemption of some kernel tasks. Look at the MonteVista or BlueCat variants. You still have to be careful not to load any drivers that contain long interrupt lockouts, or real-time latency will go way up.

The original "RT Linux" was a hack which basically allowed running your real-time application as a loadable kernel module, like a driver. That's basically a dead end at this point in time.

QNX, unfortunately, was acquired by a larger company, which has changed the business strategy from opening up QNX to raising prices and cutting functionality of the base package. The main architect of QNX died a few years ago, and things really haven't been the same since. It's sad.

I think you mean the other alternatives...

On top of those mechanisms, even slower interprocess communication systems are typically implemented, such as OpenRPC and CORBA. (For even more inefficiency, there's XPC. In Perl. But I digress.)

Because of this history, there's a perception that interprocess communication has to be slow. It doesn't.

What you really want looks more like what QNX has - fast interprocess messaging that interacts properly with the scheduler. QNX has to have interprocess communication done right, because it does everything through it, including all I/O. This works out quite well. You take a performance hit (maybe 20% for this), but you get much of that back because the higher levels become more efficient when built on good IPC.

The QNX messaging primitives are available for Linux, although the implementation isn't good enough for inclusion in the standard kernel. That work should be redone for the current kernel.

IPC/scheduler interaction really matters. If you get it wrong, each interprocess transaction results in an extra pass through the scheduler, or worse, both the sending process and the receiving process lose their turn at the CPU. This is easy to test. Start up two processes that communicate using your IPC mechanism. Measure the performance. Then start up a compute-bound process and measure again. If the IPC rate drops by much more than a factor of 2, something is wrong. Don't be surprised if it drops by two orders of magnitude. That's an indication that IPC/scheduler interaction was botched.

Sun addressed this in the mid-1990s with their "Doors" interface in Solaris, which had roughly the right primitives. But that idea never caught on.

The article here implements a message-passing system via shared memory, which is not exactly a new idea, even for UNIX. I think it first appeared in MERT, in the 1970s. It's an attempt to solve at the user level something that the OS should be doing for you.

Shared memory is a hack. It's hard to make it work right. With it, one process can crash other processes in hard-to-debug ways. Sometimes you need it because you're moving vast amounts of data, (by which I mean more than just a video stream) but that's rarely the case.

Actually, all drivers should be outside the kernel, as in QNX, and now Minix 3. But it's probably too late to do that to Linux.

AFAIK simply working with Eclipse or donating money or plug-ins or whatever doesn't make you part of the steering comittees. Lots of folks use Eclipse for their products (including my company, QNX).

This is probably BO trying to generate some positive press, since Cognos has a much better product (ReportNet). I worked on the developer docs for that, too. ;-)

I wish someone would make a studly cross-platform DTD/XSD/XSLT editor plug-in for Eclipse.

With QNX 4 up, they dumped the proprietary APIs and tools and made the thing POSIX compliant. At that point, it's hard to fault it. It's just another Unix clone from a programming perspective. While I wouldn't say for a second that it's comparable to Linux for its desktop experience (though neither is BSD), it is very, very compact and stable. I know there was a live CD at one point but at present it seems to be a 30 day trial version. I guess that's as close as you'll get. At one point, they had a version which booted from a single floppy disk and offered networking, a GUI and webbrowser. That's a stunningly compact OS, no matter how you look at it.

It still doesn't answer the debate about micro vs monolithic kernels, but it does dispell the idea that you can't produce a decent OS around a micro-kernel. Personally I think monolithic is just fine except for niches but given the right requirements, micro can work out to be a lot better. I certainly don't believe GNU Hurd is a good example of a microkernel even without the politics and lethargy that have caused it to become a running joke over its grossly extended life.

They have one right here.

QNX Neutrino is an example of a microkernel which doesn't suck. In fact QNX sees heavy use in realtime environments, where both space and performance matter a great deal. Some applications of QNX put considerable importance on the thing not collapsing in a heap after a failure of some part.

It is even worse than that. A monlithic kernel means that almost everything (kernel, device drivers, filesystems, etc.) runs in kernel mode. A microkernel uses messaging to move everything but the kernel out of kernel mode. An exokernel runs on a skeleton of code in kernel mode and everything else (including the kernel) runs in userland. An example of an exokernel is QNX. An exokernel provides very very reliable system uptime but at the expense of performance.

I believe that Linux, Solaris, and BSD are all monolithic kernels as are the Windows kernels (NT and others). OS X is a microkernel.

The three types of kernels are a spectrum trading performance for reliablity. Like most everything else in programming it is a trade off between two inversly related goals.

I've seen another RTOS, QNX http://www.qnx.com/, achieve 7usec interrupt latencies on a P100.

RTlinux looks like it has some catching up to do.

Everything else, including drivers, file systems, and networking, is a user program. This doesn't limit extensibility. USB and FireWire support were added without kernel changes. (Hardware drivers do need some privileges, but they really are user programs. You can kill them without a reboot and start another copy. I've written and debugged drivers without rebooting.) Even hardware drivers work through the standard POSIX API; there's no special "driver mode".

If Microsoft designed a system that modular, removing, say, Internet Exploder or Media and DRM Player would be trivial. Microsoft needs a tangled system to lock in users. Ballmer has admitted this.

They use QNX.

http://www.qnx.com/company/customer_stories/ss_197 _1.html

QNX(R) Neutrino(R) RTOS is powering the Neptec Laser Camera System (LCS) for NASA's Return to Flight mission. Designed and built by Neptec, a developer of space vision systems, the LCS will play a key role in ensuring the safety of this mission, the first since the Columbia disaster in 2003. This mission is scheduled for takeoff Wednesday, July 13, from NASA's Kennedy Space Center in Cape Canaveral, Florida.

The crew of the space shuttle Discovery will use Neptec's LCS to inspect the exterior of the shuttle during the 12-day flight. The LCS, which will be attached to a boom at the end of the shuttle's Canadarm, uses a scanning mechanism to generate three-dimensional maps of the shuttle's exterior surface in real time. During the mission, NASA will use the generated images to identify even the smallest amount of damage to the outside of the spacecraft.

Neptec has also used QNX RTOS technology in earlier devices it developed for NASA, including the QNX-based Advanced Space Vision System (ASVS), which helped guide the Canadarm in previous shuttle missions as well as on the International Space Station." The LCS is a critical element of NASA's Return to Flight mission and we have to be sure it is running on the most reliable operating system available," said Iain Christie, vice president of research and development at Neptec. "Selecting the QNX Neutrino RTOS was an easy decision because we already know that the system can handle the extreme conditions found in space and that it meets our demands for ultra-reliability. We will continue to use QNX technology in all of our real time embedded projects."

Full Article
Older QNX PR Piece

No I'm not confusing the two. Accelerated graphics drivers have been buried so deeply into OSes nowadays that they are extremely hard to separate them from all internal APIs.

That is not in fact the case. Both NeXTSTeP and X11 have a very carefully defined formal interface between applications, and the graphics drivers. Cocoa takes this even further, even in the very first verions of OS X it cleanly separated rendering and compositing, and limited acceleration to what could be provided by OpenGL.

If your driver allocates memory

That's a standard Mach call. It doesn't require access to the kernel.

Or accesses the PCI bus

That's memory-mapped.

And Mach is *too* a microkernel.

L4 is a Microkernel. QNX is a microkernel. The Amiga Exec was a microkernel. Mach is far too large and complex to be considered a microkernel. It implements far too many capabilities that microkernels normally delegate to servers to qualify.

[HFS+ is] one of their more significant contributions.

If you were familiar with HFS+ you wouldn't say that.

There's a lot more stuff that's a lot more interesting than HFS+, but I guess it's going to be as hard for you to find as HFS+.

Such as the class of problems falling between wristwatches and the world's top supercomputer?

The Linux Watch isn't exactly practical, and a wristwatch isn't a particularly hard or tight real-time or embedded problem these days... and systems like Blue Gene are really only useful for "embarassingly parallel" problems. Yeh, that's a pretty narrow band.

NT became successful after they dropped their devotion to a pure microkernel design.

NT was never a pure microkernel design. Like Mach, it's always implemented an awful lot of stuff explicitly rather than through services. I assume what you're talking about was them moving GDI into the kernel in NT4.

1. Whether a server runs in the same address space or a separate address space is an implementation detail: having the X server running in user space on UNIX doesn't make it a microkernel design, and there's nothing in the microkernel model that requires you to cross a protection boundary on a message send. Many real time microkernels don't run on protected-mode systems, and others make the space a server runs in entirely arbitrary.

2. Moving GDI into the kernel came at a terrible cost in reliability and stability for servers. We kept most of our servers on NT 3.51 and jumped straight to 2000.

3. What "made NT a success" wasn't anything to do with the kernel design, it was the shims they added that let them run Windows 9x device drives in 2000 and (even more) in XP, which let them drop the 9x line. They could really have done it with Windows 2000... Windows Me was a mistake on all fronts.

4. Loadable kernel modules have nothing to do with microkernel design.

Forget what academia and the popular press have to say about microkernels. Ask anyone in the real-time controls industry, where we've been using what came to be called "microkernel design" since the '70s, they'll set you straight.

No, speed does NOT necessitate that drivers run in the kernel. A GOOD microkernel architecture like QNX Neutrino is a perfect example. QNX powers Cisco's CRS-1 Carrier Routing System - a router which Guinness World Records has certified as the highest capacity internet router ever developed. It can handle up to 92 terabits/sec total throughput.

Also, the Mac OS X kernel, XNU, contains code which is based on Mach, but it isn't Mach - I.E. it's not a true microkernel.

I imagine realtime, up-to-the-second updates of servers are important in the finance world. I suppose stock exchanges and such have a lot to deal with given the volume and speed of the markets. That said, do such OSes as RTlinux or QNX have any place here?

For an embedded RT system QNX would be the go.

So the question is, Where are the new operating systems likely to come from?

Plan 9, MacOS, z/OS, AmigaOS, MorphOS, QNX, or other embedded OS.

Then how do you explain the incredible performance which QNX Neutrino sports? QNX Neutrino is built around a true microkernel, yet its performance is higher than a skyscraper.

huh, another contender ... I'll have to check it out. I used to work at QNX who also make a real-time posix-compliant OS, but it's geared more for embedded systems than desktop use (although it *can* be used on a desktop)

The big win with a microkernel is that you don't have to patch it all the time. They're small enough you can get the bugs out. Microkernels like VM and QNX settled down into stability years ago.

I'm posting this from Mozilla on a QNX machine. QNX isn't going anywhere on the desktop, but that's a business problem, not a technical one. Desktop QNX actually works reasonably well. I'm not fanatical about QNX, but technically, it's fundamentally sounder than the Microsoft and Linux messes.

If you want to try QNX, you can downoad it here. Get the "30 day evaluation version". It will still run after 30 days, but the Eclipse development environment turns off when the timer runs out.

• Put virtual machines on top, like Java and .NET. Claim that they're more secure than the OS.
• Put virtual machines underneath, like VMware. Claim that they're more secure than the OS.
• Add software to catch known attacks, like firewalls, virus scanners, and spyware removers.
• Patch, patch, patch.

It's not just a Microsoft problem, either; Linux is acquiring exactly the same set of problems as the kernel grows and grows.

It doesn't have to be this bad.

Dave Cutler, the architect of Windows NT, tried to fix it. NT 3.51 was the last version he controlled, and the last one that looks even vaguely like a "microkernel". He once told Bill Gates "I won't pollute it [NT] with crap!" So he was taken off NT, and for NT 4, the kode kiddies from the Windows 95 team were allowed to put huge volumes of crap Win95 code in the kernel, for "compatibility". The end result is XP, which in practice is only slightly less vulnerable than Windows 95.

It's striking to run QNX, which is a true microkernel (about 60K of code), with drivers, file systems, and networking outside the kernel. It can run X windows, Firefox, multimedia players, and now has OpenGL. That's a demonstration that you don't need a bloated kernel. Nor do you need one that changes much. The QNX kernel changes very slowly; new capabilities are added outside the kernel, in user space. Unfortunately, QNX on the desktop is going nowhere, because there are few applications and the current marketing push is for automotive applications. Nor is QNX intended as a secure operating system, just a reliable real-time one. Despite this, it's a clear demonstration that the basic OS does not have to be big or constantly changing.

If the Hurd guys had a clue, and could write something as good as QNX, there might be some hope from that direction. But after ten years of screwing up, there's not much hope there.

The reason this is so important is that if all the source is openly available, nobody can make it go away. It's essential to avoid "drug dealer marketing" - the first one is free, but then it's going to cost you. There have been too many products that started out "open", and then started to cost money once they had users locked in.

The typical progression for psuedo-free software is

• The product is free for download. A user community emerges.
• A new version comes out, with modest restrictions and price, and the free version is deprecated.
• The free version disappears.
• The price goes up, and copy protection is added.
• Market share declines.

Examples are Intellicad, Sendmail, and QNX

LynxOS is not Linux. It's a completely different, and much smaller, kernel. It's not as minimal as QNX; LynxOS has drivers in the kernel. But it's far smaller than Linux. It's small enough to get through the expensive and difficult examination process required for avionics.

Confusingly, the company that sells LynxOS recently changed their name to LynuxWorks, and also distributes BlueCat Linux, an embedded Linux distro based on the 2.6 Linux kernel. LynuxWorks had a huge booth at the Embedded Systems Conference last month.

LynxOS, BlueCat Linux, and QNX all use the GNU compilers and tools. All are POSIX compatible, and will run most commmand line programs with a recompile.

The aforementioned RedHat based Q70 is interfacing to a Single Board Computer running XP-Embedded

NB: the only ECDIS-N certified voyage management system runs on Windows

There is something to be said for an OS baseline that doesn't change monthly/weekly/daily.


What, like QNX?

I thought it was designed specifically for mission-critical, has-to-work, has-to-have-great-support, musn't-change-often kind of situations. I'm sure there's other OS's like it, too. Why Windows?


OT, but incidentally if anyone's wanting to make good use of older (Pentium or early PII) hardware as a dedicated MP3 Jukebox or 'net browsing box, you can do worse than QNX for x86. BeOS is a good choice, too, if you can find a copy. They both outperform every Windows version since '95 and every modern Linux/BSD on old hardware, when it comes to graphical operations, like managing a playlist, browsing the web, or watching video.

There's a surprising amount of software available for both of them, too. Plus, they're both *nix(ish)!

VM is really a hypervisor, or "virtual machine monitor". The abstraction it offers to the application looks like the bare machine. So you have to run another OS under VM to get useful services.

The PC analog of VM is VMware. VMware is much bigger and uglier than VM because x86 hardware doesn't virtualize properly, and horrible hacks, including code scanning and patching, have to be employed to make VMware work at all. IBM mainframe hardware has "channels", which support protected-mode I/O. So drivers in user space work quite well.

QNX is a widely used embedded operating system. It's most commonly run on small machines like the ARM, but it works quite nicely on x86. You can run QNX on a desktop; it runs Firefox and all the GNU command-line tools.

QNX got interprocess communication right. Most academic microkernels, including Mach and L4, get it wrong. The key concept can be summed up in one phrase - "What you want is a subroutine call. What the OS usually gives you is an I/O operation". QNX has an interprocess communication primitive, "MsgSend", which works like a subroutine call - you pass a structure in, wait for the other process to respond, and you get another structure back. This makes interprocess communication not only convenient, but fast.

The performance advantage comes because a single call does the necessary send, block, and call other process operations. But the issue isn't overhead. It's CPU scheduling. If the receiving process is waiting (blocked at a "MsgReceive"), control transfers immediately to the receiving process. There's no ambiguity over whether the message is complete, as there is with pipe/socket type IPC. There's no trip through the scheduler looking for a process to run. And, most important, there's no loss of scheduling quantum.

This last is subtle, but crucial. It's why interprocess communication on UNIX, Linux, etc. loses responsiveness on heavily loaded systems. The basic trouble with one-way IPC mechanisms, which include those of System V and Mach, is that sending creates an ambiguity about who runs next.

When you send a System V type IPC message (which is what Linux offers), the sender keeps on running and the receiving process is unblocked. Shortly thereafter, the sending process usually does an IPC receive to get a reply back, and finally blocks. This seems reasonable enough. But it kills performance, because it leads to bad scheduling decisions.

The problem is that the sending process keeps going after the send, and runs until it blocks. At this point, the kernel has to take a trip through the scheduler to find which thread to run next. If you're in a compute-bound situation, and there are several ready threads, one of them starts up. Probably not the one that just received a message, because it's just become ready to run and isn't at the head of the queue yet. So each IPC causes the process to lose its turn and go to the back of the queue. So each interprocess operation carries a big latency penalty.

This is the source of the usual observation that "IPC under Linux is slow". It's not that the implementation is slow, it's that the ill-chosen primitives have terrible scheduling properties. This is an absolutely crucial decision in the design of a microkernel. If it's botched, the design never recovers. Mach botched it, and was never able to fix it. L4 isn't that great in this department, either.

Sockets and pipes are even worse, because you not only have the scheduling problem, you have the problem of determining when a message is complete and it's time to transfer control. The best the kernel can do is guess.

QNX is a good system technically. The main problem with QNX, from the small user perspective, is the company's marketing operation, which is dominated by inside sales people who want to cut big

Now I look at my regular computer. Just my email client alone, Thunderbird, takes up 20 MB on my hard drive. Fat. Fat. Fat.

I'm afraid no ones going to bother optimizing code until Moore's law runs up against some physical engineering walls.

Your roadmap leads here... or perhaps here :)

RunTime: Context switching, Part 1
High-performance programming techniques on Linux and Windows

RunTime: Context switching, Part 2
High-performance programming techniques on Linux and Windows

COMPARISON BETWEEN QNX RTOS V6.1, VXWORKS AE 1.1 AND WINDOWS CE .NET
PDF DOCUMENT

Let's not forget QNX... :) But I know what you meant.

My puzzlement: Windows NT == VMS? Really? Are you serious?

More of a stab at M$FT - I think the gentleman's agreement they reached was that DEC wouldn't sue them over theft of proprietary trade secrets [i.e. theft of "Intellectual Property"] if M$FT agreed to port NT to Alpha hardware.

But as to the underlying question of the NT kernel: Folks, it ain't all that bad. In just about every test anyone ever throws at it, the NT kernel bitch slaps the competition.

Compare e.g.:

RunTime: Context switching, Part 1
High-performance programming techniques on Linux and Windows

RunTime: Context switching, Part 2
High-performance programming techniques on Linux and Windows

COMPARISON BETWEEN QNX RTOS V6.1, VXWORKS AE 1.1 AND WINDOWS CE .NET
PDF DOCUMENT

I wouldn't consider this to be new...rather it's the idea of this that is starting to propigate.

CISCO's new 92 terabit/sec router already has some of these features. The OS they used to build the system supports many of these features (high availability, self healing, etc).

http://www.qnx.com/markets/networking_telecom/cisc o/

http://www.cisco.com/en/US/products/ps5763/index.h tml

It's a self healing system. It uses the services and functionality of the OS to accomplish it.

QNX's networking system is really neat because it allows processes to be independent of where they actually run on a network. And the network can be anything (i.e. a backplane, Ethernet, whatever). So it lends itself to solving such a problem.

I believe the operating system you are thinking of is QNX.

If we want to maintain the quality and stability that the Linux kernel has, we need to resist binary drivers.

Firstly, I agree. BUT if need to allow third party vendors to ship binary drivers (and maybe we do, in the IP crazy world) then a QNX user-space driver model might be smarter?

Have you ever worked with QNX Momentics? It can be used to build programs in a variety of languages for a variety of platforms. I found it a lot more comfortable than MS Visual Studio .NET. Also, it's not restricted to just one platform. It costs quite a bit, though.

I've heard that Microsoft made a presentation to some big car company, and insisted that Microsoft had to control the content of the startup screen. The car people did not like that at all.

I hope QNX fights them tooth and nail.

Is that all you wanted to say?

That's all.

Why the hell not just include the real-time business as options? Is the maintenance really that much more challenging?

Well, maintenance isn't the worst of it. Having a kernel qualify as "real-time" requires a whole lot of reworking and is probably best attempted at design-time.

Real Time Operating Systems (RTOS's) require that the kernel respond within a certain timeframe, usually in the microseconds. They are especially used for embedded/safety-critical systems, where if the system doesn't respond quickly enough, people die.

In order for a kernel to do this, it must have very, very tight syscall functions, and a really stingy scheduler. Both of these are really hard to do in a simple patch, without, in essence, abstracting away the entire kernel and having a real time microkernel on top of it. In effect you get a very drastic decrease in throughput.

This is fine for certain things like fly-by-wire control systems, where its not important to do something well and often as much as it is to do something NOW. This differs from the server/desktop markets linux is currently oriented towards, for which a RTOS patch may not just add bloat, but rather quite a bit of unnecessary hindrance.

If you want to see the differences first hand, check out QNX (I think they still have feely downloadble developer versions). In it, start a resource intensive task and then from another terminal, load any other program. Notice how the first task stutters? If you imagine the first program to be your company's mission-critical application server, and ther second to be your office's alarm dispatcher, it's very easy to see the dilemna Linus must choose between.

If you want hard real time and protected mode, you need an architecture like that of QNX, where almost everything runs in user space. File systems, drivers, and networking are all user programs, intercommunicating by message passing. The kernel only handles CPU dispatching, memory management, and message passsing.

In an architecture like that, everything in user space is preemptable, without any extra work in the system services. There are no long latencies in the QNX kernel; they were all taken care of years ago.

As Linus points out, though, few consumer embedded devices really need hard real time. Most media-related stuff can paper over delays with buffering. A classic comment is, "You run your web server on Linux. You run your nuclear reactor on QNX".

Automotive systems, though, really need it. QNX is big in that market.

How about QNX, at least it has a Q in it.
http://www.qnx.com/

As cool as this hack is, and I personally think it is pretty cool, for my money an old 3Com Audrey makes a much better media system UI. The Audrey is a diskless "internet appliance" from a few years ago that failed in the market. Originally about $500, they are now commonly available on EBay for about $80-90. The screen is larger and you can do a lot more things with it.

The Audrey looks like a Jetsons style Etch-a-sketch. It was designed to sit on the kitchen table and do email, read the morning news, look up recipes on the Internet, stuff like that. It has has a 7" diagonal 640x480 color touch screen, wireless keyboard, some specialized buttons on the front, 2 USB ports, built in speakers, microphone and audio jack. There is no disk drive; it uses 32 Mb RAM and a 32 Mb Compact Flash card that holds the OS (QNX, an embedded microkernel).

A thriving Audrey hacking community has evolved; people have replaced the original software with things like mp3 players, a better web browser, home automation stuff, etc. I own five of them, which I use to stream music all over the house. The tiny built-in speakers are crappy but the sound card is decent, and sounds fine plugged into a stereo or boom box. My winter project is going to be to implement a home intercom system using my network of Audreys. I can't say enough good things about this cool toy!

Hate to play the role of the troll here [better say goodbye to those Karma points], but Linux has pretty lousy numbers for an embedded OS. Heck - "pretty lousy" is being generous - I've never seen Linux come in anywhere but dead last in an RTOS review.

In fact, the dirty little secret of the embedded OS marketplace is that WinCE is a rather solid, stable, and flexible platform:

http://www.windevnet.com/documents/s=7636/ddj0302g /0302g.htm

http://www.qnx.com/download/download/8124/QNX_Neut rino_v61_vs_VXAE_and_WinCE.pdf
[PDF DOCUMENT]

Of course, some of the problem here may be semantics - people seem to think that if you build a SBC/PICMG platform, load it with "Linux," and call it a "firewall," then you're doing realtime work. Well, guess what - you're not. Realtime is an OS in a USAF jet, flying at Mach 3, reacting to a gazillion interrupts per second, trying to keep the pilot from both killing himself and from being killed by that SAM missile on his tail.

That's when you call in the grown-ups and the grown-up RTOSes.

Anyway, you can argue about what the words "embedded" and "realtime" mean, but, when the rubber hits the road, Linux is a very poor substitute for the real thing.

Well, apparently Microsoft think they can do operating systems for medical applications. Personally, I can think of more suitable operating systems for the task...

I agree with you in general, but would probably use QNX

And I don't mean Linux or *BSD. There are high-reliability OSs out there, and for life critical systems, why can't these vendors use a grown up OS like QNX or WindRiver's VxWorks.

I don't understand this obsession with using Windows in embedded situations! Especially critical systems. Why?? There are other OS's designed for safety, reliability and embedding. Why are these medical equipment companies ignoring these better alternatives?

I thought most hospital medical devices ran an embedded operating system like QNX?

I'm looking. I found a 30-day evaluation, but I'm waiting for the confirmation email for my "myQNX" account so I can look at their downloads page. Has anyone else noticed GMail being slow?

QNX isn't a Linux clone. QNX is a POSIX based OS that has a history that goes back a decade before Linux was even a glimmer in Linus's eye.

There is nothing given away for "free" either, there is an evaluation that is free - much the same as vmware has a 30 day eval of their product. After that 30 days, Neutrino will fall back into a more limited mode but will remain operational (like it was with NC before 6.3.0).

www.qnx.com

www.qnxzone.com

www.openqnx.com

Some reading to bring you up to speed on things.

We needed a real time OS (or at least close to it) so thats why its running on QNX. The QNX box is communicating with embedded microcontrollers over an external bus.
[snip]
My preference would have been an old Sparc box running SunOS.


The words, "non-realtime OS" keep coming to mind...

They deviate from standards and make you have to dig to find where that deviation is. Is having man pages too much to ask??

Fair enough. But it *is* an embedded system. Footprint is everything. My guess is that you're simply not used to the QNX way of doing things and are thus frustrated. Many of the QNX deviations are actually quite sensible, and some of them are actually choices made by the person customizing the system.

Do yourself a favor. Learn to use offline docs (or at least installable docs) and stop expecting dumb things like BASH on an embedded system. If you don't stop complaining, your boss may decide to give you VxWorks (note the oxymoron here) as a punishment.