Slashdot Mirror

The latest incarnation of IOS is actually a Cisco custom version of QNX. To the best of my knowledge Cisco is still the only organization on the planet with a source code license to QNX.

Who says a microkernel lacks performance, hmm? QNX can do a full process-to-process context switch in under 250 nanoseconds on a 2Ghz Pentium, less for thread switches.

A link to an interesting post from yesterday.

You use QNX everyday without knowing it. QNX is used in the front-end networks of both Visa and Mastercard, it's used in nuclear reactor control systems, chip manufacturing, FDA approved medical equipment, and high-speed postal sorting systems.

Not to mention... eight tightly coordinated QNX controlled robots stretch the aluminum onto the F-16's wings...

The latest incarnation of IOS is actually a Cisco custom version of QNX. To the best of my knowledge Cisco is still the only organization on the planet with a source code license to QNX.

Who says a microkernel lacks performance, hmm? QNX can do a full process-to-process context switch in under 250 nanoseconds on a 2Ghz Pentium, less for thread switches.

A link to an interesting post from yesterday.

You use QNX everyday without knowing it. QNX is used in the front-end networks of both Visa and Mastercard, it's used in nuclear reactor control systems, chip manufacturing, FDA approved medical equipment, and high-speed postal sorting systems.

Not to mention... eight tightly coordinated QNX controlled robots stretch the aluminum onto the F-16's wings...

The latest incarnation of IOS is actually a Cisco custom version of QNX. To the best of my knowledge Cisco is still the only organization on the planet with a source code license to QNX.

Who says a microkernel lacks performance, hmm? QNX can do a full process-to-process context switch in under 250 nanoseconds on a 2Ghz Pentium, less for thread switches.

A link to an interesting post from yesterday.

You use QNX everyday without knowing it. QNX is used in the front-end networks of both Visa and Mastercard, it's used in nuclear reactor control systems, chip manufacturing, FDA approved medical equipment, and high-speed postal sorting systems.

Not to mention... eight tightly coordinated QNX controlled robots stretch the aluminum onto the F-16's wings...

IOS XR is not based on Unix.

IOS XR _is_ QNX.

And QNX is a 100% proprietary design and 100% proprietary code, but it looks and and smells like POSIX/Unix. So... as far as that goes it's as much based on Unix as Linix is. :-)

QNX Rocks.

QNX Powers Universal Media Gateway for Next-Generation Digital Video Networks
QNX Software Systems today announced that the QNX® Neutrino® realtime operating system (RTOS) will be shipping as part of the Cisco uMG9850 QAM Module, a new quadrature amplitude modulation product designed to let cable operators use Gigabit Ethernet to deliver video-on-demand and other multimedia services efficiently and cost-effectively to TV set-top receivers.

'Little OS that could' just might
"In a deal signed two years ago, Cisco (csco) chose QNX as its preferred real-time OS vendor as part of Cisco's 'ongoing efforts to increase the reliability and availability of data-voice-video networks.' Since then, not much seems to have materialized from the partnership."

Cisco's HFR is here
"The IOS-XR operating system kernel was acquired from QNX Software Systems, a small Canadian developer of realtime operating system code to companies in the automotive, communications, defense, industrial automation and medical device markets. Cisco already ships QNX operating system code in its uMG9850 QAM digital video module for the Catalyst 4500 Gigabit Ethernet switch."

Cisco Unveils the HFR
" The transition is analagous to Microsoft Corp. (Nasdaq: MSFT - message board) moving from DOS-based operating systems to Windows NT, says analyst Stephen Kamman of CIBC World Markets.

Just as NT did, IOS XR could begin trickling down to lower-level systems, eventually permeating Cisco's entire portfolio, including edge and enterprise boxes. "The question is how quickly they can push that software through the product line," Kamman says."

"The software is based on a kernel licensed from QNX Software Systems, but tailored for the job. 'We have made some pretty substantial modifications to [the QNX code] that are Cisco proprietary,' Volpi says."

[Disclaimer: This is a very happy QNX Employee.]

Who says you can't get performance from a microkernel?

This was the product whose internal development code name was HFR (Huge Fscking Router).

Sweet!

p.s.
Note the other key word "self-healing".

The file systems and networking are user programs. You can add new file systems; there's one that mounts .zip files, there's NFS, and there's Samba. In Linux terms, visualize a system where there's the /proc file system for inter-program communication, and everything works through that mechanism.

The drivers really are outside the OS. I've written a FireWire camera driver for QNX, and it's a user program. It's privileged in that it does map some real memory shared by the device, and it can talk to the device directly, so it could potentially cause a crash by making the device write someplace it shouldn't. (That's really a weakness in the PC's I/O architecture; there's no MMU between devices and memory, for historical reasons dating back to the original IBM PC.)

Debugging a driver is like debugging a normal program. You can even run a driver under a debugger. You can kill a driver while it's running, and it's no big deal. (If you have real memory mapped, it's not recovered until the next boot, so I had to restart my machine about once a week while doing driver development.) Mainframe people have been doing this since the 1960s, but it's rare on PCs.

The basic penalty for using a microkernel is one extra copy and context switch for every file system operation. If your system is doing anything besides I/O, you'll probably never notice. If you're running a web server that serves mostly plain pages (little Perl, Java, PHP, etc.), you'd probably notice the overhead.

So why are microkernels so rare? They're hard to write well. You can't just hack them together like a UNIX clone. There are some tough design problems to be solved. If those are botched, message passing performance will be terrible. Message passing and CPU scheduling need to work together. This forces certain design decisions in the scheduler. It's also why adding message passing to an existing system tends not to work well. The Hurd crowd has been thrashing on this issue for a decade. I would have loved to see something as good as QNX from the Hurd people. But it didn't happen.

Mach didn't really work out as a microkernel. Mach started from 4.3BSD (considered bloated in its day), and versions of Mach below 3 had 4.3BSD in the kernel. MacOS X is not a microkernel system; the BSD stuff is in the kernel. Basically, retrofitting a microkernel architecture to an existing UNIX kernel didn't work.

What you do get from a microkernel like QNX is predictablity. The kernel changes very little and is very reliable. Good microkernels, like QNX and IBM's VM, settle down into versions that almost never change and have very long MTBFs. This brings down total cost of ownership.

QNX

So micro it hurts.

Also fast, small, secure, and hard realtime.

The free version of QNX comes with no inbound services enabled. Most of the standard UNIX-type services are available, but they're not installed by default. It's a pure client. In fact, it's very close to what the iOpener ran. Both dial-up and LAN connections are supported.

Mozilla 1.1 runs, but without Flash. There's a word processor, ABIword. The whole GNU toolchain is available. Unfortunately, OpenOffice hasn't been ported.

It's refreshing to run a system without all the Microsoft crap, or the Linux emulations of it.

...and obviously not Minix, the immediate ancestor of Linux.

Or Idris or Coherent.

Without claiming to be any kind of kernel guru I believe that the Minix and Linux kernels are so different that it is not useful to call Minix the immediate ancestor of Linux.

The Linux kernel is a "monolithic" kernel. The Minix kernel is more like Hurd, or QNX, with a "microkernel", and tasks communicate via message passing. Minix was written as a teaching tool, aimed to run on an 8088. So it had performance limiting bottle-necks. IIRC the file system task could only handle a single file system request at a time.

But it makes me wonder about Xenix - the one Microsoft owned, for a while. Guess that didn't exist, either.

Microsoft liscensed Xenix. They didn't own it. I used a version of Xenix in the early 80s. The Xenix I used was clearly just a rebranded version 7.

I hope they run FreeBSD in lieu of Windows NT. We've only had about four stalled destroyers due to that operating system. They'll probably end up running something like QNX or VxWorks, though, which are realtime operating systems. Still much better choices than Windows NT/2K/XP.

Bryan [iamcf13 (736250)] here:

I am posting this anonymously to avoid the risk of the mod points I got and spent on this topic being automatically revoked by the 'Slashcode' running Slashdot for posting to this topic.

On the subject of software liability, QNX is the only software company I know of who will stand by their work no matter what (it seems).

For all the other software vendors out there, it's a 'we're not liable' mentality which I talk about in this post. In a nutshell, the post says simply that software vendors will not warrant the fitness of their software simply for the fact said software is not running on a computer system they have complete control, access, and influence over.

If you had read the article, you would have realized that they do not carry arms themselves - they merely assist the guards by carrying equipment and the like into dark and unsafe places. They're primarily built to be surveillance robots, that is all!

It's not just the software being Windows or Linux or whatever - its the hardware too. There is a reason NASA had chosen x86 for a lot of its missions - reliability and hardware dependability.

And quite honestly, I find it really unlikely for any of these things to be running anything close to Windows (if they ever wanted, it would be CE, which again is not really a good option). These things would have to be built for realtime apps, coupled with networking capabilitis and the like and would perhaps be happier running something like QNX.

Or ofcourse, customized Linux/*BSD kernels.

And oh, Naval ships do run Windows within the ship - perhaps not the control centers, but still, a significant chunk of the (active and on-duty) Navy does use Windows.

No, I think software makers must be able to continue making these disclaimers, for two reasons:

• If they couldn't, no one would ever release free (as in beer) software anymore. Would you want to assume that level of liability for no gain?
• Even in commercial software, it would slow down everything tremendously. Testing everything to the level that they test life-supporting systems is just not reasonable.

Instead, here's a radical idea: understand that software with such disclaimers was never intended to be used in situations where its failure could kill someone. So don't.

There is software out there that does not have blanket safety disclaimers. I believe QNX Neutrino does not, for example. I know they're using it in safety-critical systems at nuclear power plants.

The preemptive kernel work has made the user-space real time variants of Linux, like Hard Hat Linux from MonteVista, more competitive. Vendors now claim worst-case interrupt latencies under 1ms, which is far better than it used to be. But they usually mean interrupt latency for kernel-mode drivers, not response time for user programs. QNX can provide worst case hard real time interrupt response to a user program in well under 1ms. Direct interrupt response is far better. See this benchmark in Dr. Dobbs Journal, demonstrating worst case 8 microsecond (not millisecond) latency over hours of testing on a 200MHz computer.

Linux is getting better at real time. Two years ago it was a joke.

You can download the free version of QNX here. This is for desktop PCs. The cross-compilers and kernels for embedded systems cost money. It's a cute little desktop OS. Even runs Mozilla.

The issue here is whether the x86 platform's issues, like excessive heat and power consumption and the requirement for a separate memory controller, outweigh its advantages, like the large variety of hardware already available to interface to everything under the sun and the fact that it's a well-understood architecture.

Now that's out of the way, here's my two cents: the x86 architecture, or at least the implementations currently available, simply isn't cut out for most embedded applications. While x86's limitations have been addressed with lots of extensions (MMX, SSE, 3dNow, etc.), those end up adding complexity and drawing more power than a chip designed without those limitations. Also, the x86's pitiful lack of registers compared to architectures like the PowerPC (another choice for embedded applications that require a good deal of power) means that almost any complex operations mean lots of going in and out of cache, or, worse, main memory. While x86 is acceptable in an environment with a 300W+ power supply and user tolerance for a good deal of noise, it won't cut it in your VCR. x86 might see some use in applications which require rapid development and lots of power, but in most cases there is already a good solution available.

If you are allowed to pour you hart out about how vxworks sucks for your router/broadband project then can I offer some clues and guesses as to why NASA might have chosen it?

The article stated that NASA needed to be able to patch code while it was running, a very reasonable demand as one cant just get the rocket back to earth and start the whole thing over.

Qoute: "In addition to VxWorks' reliability, the system allows users to add software patches -- such as a glitch fix or upgrade -- without interruption while a mission is in flight. "We've always had that [feature] so you don't have to shut down, reload and restart after every patch,""

Iirc from the nat. geographic documentaries the spirit code was still being developed while the rover was on its way to the planet. (How is that for missing a deadline, they must have learned this one from the game industry ;-) ) I may be mixing things up with the orbiter though. This would be a perfect explanation as to why there apears to be a bug/situation which would have been found with running long tests collecting lots of "science data" on earth.

Now you go on about the vxWorks malloc implementation (dynamic memory managment features). NASA may actually have little need for having the OS manage the memory. It apears most of the colected data is stored in a filesystem on flash ready for pickup by a comunication system sending it back to earth (By any available orbiter). Now the problem with fragmentation is that it is likely to get worse as soon as it starts, but with 128 MB of ram and *very* few procecsses I dont see how you could get a problematic or fatal amount of fragmentation unless there are multiple procecses collecting a lot of data at the same time in very high resolution mallocinging tiny amounts (less then a page) at a time with little memory left to spare. Neither of these conditions seem to be likely to be met in any big way, but I havent seen this codee ofcourse.

Now you mention tcp/ip is bad, and I fully believe you. (eventhough my motorola cable modem claims to be running vxworks, consumer broadband must be at least possible with this rtos ;-) ). But, obiously, NASA is not gona use tcp/ip as a protcol and the drivers for the radio hardware are not gona be a standard part of vxworks. I think these pieces of code for sending stuff over high frequency duplex radio data links have been laying around at nasa (or defence contractors) tested and proven on many applications just like many other components of this machines software. This bring me to my other guess as to the choicec of vxworks, the rover has to pretty much plot its own course over the planet. It seam possible that the rover now on mars uses the excact code for that that early prototypes used while spending months in american deserts. VxWorks might have been the os of choice by the prototye engineers, but porting this code to another OS might introduce bugs which goes for all the code nasa already had (tested, and perhaps even proven in space)

Now unlike VxWorks I have run QNX, (as has everyone who has had the time to go over here, have a look If only to brag about using another os on your desktop). While I agree that it is a very very nice os, I could very well see it not having any features over vxworks that would make it worth it for nasa to port all their current vxworks stuff over only to have to test it again while still not knowing for sure if it will run *excactly* like on vxworks. And ofcourse any features vxworks did lack (or rather did have while not being supposed to ;-) ) could have been fixed by nasa coders in no time just like you did only with the help of the source.

I'd like to remind you Linux guys that QNX owns your ass.

Ergo, it is a software problem.

Next time, I hope to hell that NASA uses the world's best and most reliable RTOS. That would be QNX, of course.

And no more freakin Java!

Hi, I've been using QNX for the last few weeks on my 1 GHz Penium III system, and I'm quite baffled by the performance or lack thereof that I've been seeing.

I downloaded the QNX 6.2.1 ISO, burnt a CD, and installed onto my hard drive. This was after erasing an old Windows 2000/Linux dual-boot install. Things went smoothly, and I was easily able to connect to the Internet for updates to various packages. I was really impressed at this point.

After a couple days of playing with it, however, I was boggled at how much like Windows the system acted. Here I was with a 1 GHz processor (the minimum required is 600 MHz) and 1 gigabyte of RAM and Photon, the GUI, was lagging. If I have a few programs open and an MP3 playing in the background, I can watch widgets redraw. Tweaking some options helped a little, but this is not in line with what I have read about QNX performance.

Isn't this supposed to be a hard realtime operating system that runs on medical devices meant to save peoples' lives? How is it that it runs on 33 MHz processors with 128k of RAM in an IV drip yet skips MP3s on a system 100x beefier in every way imagineable? Do they release a different version for free that doesn't try for realtime performance or what?

After less than a full month I've grown dissatisfied with something I'd hoped I could replace my Windows and Linux installs with for leisure and hobbyist purposes. My main system is a dual 3 GHz Pentium4 box with 4 gigs of RAM, but that's a DV workstation and I can't use it just to see how QNX scales with more robust hardware and a dual processor configuration. Something tells me it might not, though.

Can anyone offer me any insights? I realize that this is a free operating system and that I have little room to bitch, but I want to make sure there's nothing I'm missing before I discount QNX altogether and go back to Windows or Linux, which while performing slugglishly are more familiar to me.

Thank you.

Please remember: RT means NOT to be fast, but to guarantee certain worst-case-latencies under all circumstances, load and IRQ-storms.
If you look for an open-source RT-system, here you go:

1) my favourite, eCos from RedHat/ex-Cygnus.
It has a very, very sophisticated configuration tool (almost everything(!) you don't need is rippable from the kernel), has even a Linux-Compatibility-Module and so on

2) RTEMS is also free, configurable and so on. IIRC it was used to steer the cruise-missles. The configuration is a bit more complicated.

3) number three ... i forgot about it just this moment, sorry

If you want to pay, there is always:
QNX and VxWorks.

If Microsoft Built Cars..

An interesting proposition.. /me peers into his crystal ball...

If Microsoft Built Cars...
If Microsoft Built Cars...
If Microsoft Built Cars...
If Microsoft Built Cars...
If Microsoft Built Cars...
If Microsoft Built Cars...
If Microsoft Built Cars...
If Microsoft Built Cars...
If Microsoft Built Cars...

Whoa.. stick with QNX, please.

Hi, I've been using QNX for the last few weeks on my 1 GHz Penium III system, and I'm quite baffled by the performance or lack thereof that I've been seeing.

I downloaded the QNX 6.2.1 ISO, burnt a CD, and installed onto my hard drive. This was after erasing an old Windows 2000/Linux dual-boot install. Things went smoothly, and I was easily able to connect to the Internet for updates to various packages. I was really impressed at this point.

After a couple days of playing with it, however, I was boggled at how much like Windows the system acted. Here I was with a 1 GHz processor (the minimum required is 600 MHz) and 1 gigabyte of RAM and Photon, the GUI, was lagging. If I have a few programs open and an MP3 playing in the background, I can watch widgets redraw. Tweaking some options helped a little, but this is not in line with what I have read about QNX performance.

Isn't this supposed to be a hard realtime operating system that runs on medical devices meant to save peoples' lives? How is it that it runs on 33 MHz processors with 128k of RAM in an IV drip yet skips MP3s on a system 100x beefier in every way imagineable? Do they release a different version for free that doesn't try for realtime performance or what?

After less than a full month I've grown dissatisfied with something I'd hoped I could replace my Windows and Linux installs with for leisure and hobbyist purposes. My main system is a dual 3 GHz Pentium4 box with 4 gigs of RAM, but that's a DV workstation and I can't use it just to see how QNX scales with more robust hardware and a dual processor configuration. Something tells me it might not, though.

Can anyone offer me any insights? I realize that this is a free operating system and that I have little room to bitch, but I want to make sure there's nothing I'm missing before I discount QNX altogether and go back to Windows or Linux, which while performing slugglishly are more familiar to me.

Thank you.

I downloaded the QNX 6.2.1 ISO, burnt a CD, and installed onto my hard drive. This was after erasing an old Windows 2000/Linux dual-boot install. Things went smoothly, and I was easily able to connect to the Internet for updates to various packages. I was really impressed at this point.

After a couple days of playing with it, however, I was boggled at how much like Windows the system acted. Here I was with a 1 GHz processor (the minimum required is 600 MHz) and 1 gigabyte of RAM and Photon, the GUI, was lagging. If I have a few programs open and an MP3 playing in the background, I can watch widgets redraw. Tweaking some options helped a little, but this is not in line with what I have read about QNX performance.

Isn't this supposed to be a hard realtime operating system that runs on medical devices meant to save peoples' lives? How is it that it runs on 33 MHz processors with 128k of RAM in an IV drip yet skips MP3s on a system 100x beefier in every way imagineable? Do they release a different version for free that doesn't try for realtime performance or what?

After less than a full month I've grown dissatisfied with something I'd hoped I could replace my Windows and Linux installs with for leisure and hobbyist purposes. My main system is a dual 3 GHz Pentium4 box with 4 gigs of RAM, but that's a DV workstation and I can't use it just to see how QNX scales with more robust hardware and a dual processor configuration. Something tells me it might not, though.

Can anyone offer me any insights? I realize that this is a free operating system and that I have little room to bitch, but I want to make sure there's nothing I'm missing before I discount QNX altogether and go back to Windows or Linux, which while performing slugglishly are more familiar to me.

Thank you.

Hi, I've been using QNX for the last few weeks on my 1 GHz Penium III system, and I'm quite baffled by the performance or lack thereof that I've been seeing.

I downloaded the QNX 6.2.1 ISO, burnt a CD, and installed onto my hard drive. This was after erasing an old Windows 2000/Linux dual-boot install. Things went smoothly, and I was easily able to connect to the Internet for updates to various packages. I was really impressed at this point.

After a couple days of playing with it, however, I was boggled at how much like Windows the system acted. Here I was with a 1 GHz processor (the minimum required is 600 MHz) and 1 gigabyte of RAM and Photon, the GUI, was lagging. If I have a few programs open and an MP3 playing in the background, I can watch widgets redraw. Tweaking some options helped a little, but this is not in line with what I have read about QNX performance.

Isn't this supposed to be a hard realtime operating system that runs on medical devices meant to save peoples' lives? How is it that it runs on 33 MHz processors with 128k of RAM in an IV drip yet skips MP3s on a system 100x beefier in every way imagineable? Do they release a different version for free that doesn't try for realtime performance or what?

After less than a full month I've grown dissatisfied with something I'd hoped I could replace my Windows and Linux installs with for leisure and hobbyist purposes. My main system is a dual 3 GHz Pentium4 box with 4 gigs of RAM, but that's a DV workstation and I can't use it just to see how QNX scales with more robust hardware and a dual processor configuration. Something tells me it might not, though.

Can anyone offer me any insights? I realize that this is a free operating system and that I have little room to bitch, but I want to make sure there's nothing I'm missing before I discount QNX altogether and go back to Windows or Linux, which while performing slugglishly are more familiar to me.

Thank you.

There's some performance penalty for microkernels, because you do more copying. But it pales in comparison with the penalties associated with Perl, Java, PHP, VB, etc.

Back in the 1980s, DARPA was very unhappy with BSD because it crashed. (Back then, kiddies, OSs weren't supposed to crash.) V6 and V7 UNIX boxes used to go years between crashes. Fixes were rare. Patches were unheard of. BSD was being fixed constantly.

Arguably, BSD was the first "modern" OS - a gonzo kernel with an ongoing stream of crashes, fixes, and patches, and updates, rather than a rock-solid stable kernel that didn't do much.

Every day I go past bus schedule kiosks displaying Windows errors. It's a shame and a waste of money to not use something more stable or even designed for embedded systems. QNX and Linux come to mind right away.

Sorry, but their testing equipment runs QNX.

I should know, I've got close friends and relatives who write the software for it. I look forward to the day when strict realtime extensions find their way into the main kernel tree.

True microkernels, with no drivers in the kernel, are hard, much harder than writing an UNIX clone. The only successful one is QNX. It's quite hard to make a microkernel interface safe, usable, and efficient. If you're going to work on this, look at the QNX API. The MsgSend/MsgReceive/resource manager framework in QNX 6 is quite effective. Yes, you pay one extra copy per I/O transaction for using a microkernel architecture. You don't notice it much in practice.

I had hope for Eros at one time, but that's going nowhere. The Eros people went off on a tangent with "persistence", which was a hot idea a few years back, and had to redesign to get that out of the kernel. Meanwhile, everybody lost interest.

Still, if we're ever going to get a secure OS, it's going to be via a microkernel. That's the only way to get the size of the trusted code down.

if implemented properly, could revolutionise governance in general - pity it's being so badly implemented thus far. If voting were faster and cheaper it could be involved more regularly in all manner of decision making processes. I simply cannot believe that someone would implement such a critical system on any Microsoft platform, especially when there's plenty of alternatives out there. QNX comes to mind. Mind you it is no surprise to me that a company who chooses to start behind the 8 ball by making such a poor choice in platforms is subsequently found to show a disregard for security in general ('compromised' servers, serious flaws, etc.). I hope they're enjoying 'whack-a-mole' because you can bet that for every site they manage to take down, 10 others will pop up!

I have a hard time believing this given that I've lived here all my life. In the three major cities, the immigrant population is so overwhelmingly large, that in many places, it outnumbers Canadian-born people (just take a look at Richmond, BC if you don't believe me). I really don't think employers look at foreigners with distaste out of xenophobia. Instead, it's more of a question of how well you fit in. It comes down to the age-old question of how good your communication abilities are and how well you work with the people around you....

For ages, Canadian immigration had next to zero requirements on the ability to speak either official language. And I think employers are rightfully cautious about hiring immigrants because they don't want someone who's going to stick out like a sore thumb in the workplace.

That said, if you can prove your communication abilities, and by the sounds of it, you're an English-speaker, then you've got a leg up on the majority of immigrants who arrive here.

At the same time, if you're looking for CS work, then be careful, because the Canadian computer industry has never really had an explosion Sillicon-valley style. It's strengths lie behind small startups trying to innovate their way into being successful, minus a few big-name companies like Bombardier, Corel (whether you like them or not), or ATI. Think ACD systems of ACDsee fame, or QNX, though that one's grown a lot over the years....

How does this compare with the kernel that was reviewed [and thoroughly trashed] by Dedicated Systems last August?

PDF DOCUMENT: http://www.qnx.com/products/ps_neutrino/benchmarks /elds/qnx62_elds.pdf

**********

NO - I'm not a QNX employee.

I am, however, about to embark on a huge project that involves real-time collection of massive amounts of biometric data, and I've spent the last several weeks investigating the state of the art of RTOS's.

We are looking at five possible candidates: VxWorks, Linux, CE.NET, QNX, and LabVIEW Realtime. VxWorks has a lot of market share, but the consensus seems to be that, under the hood, it's a little shaky. The consensus also seems to be that Linux just ain't ready for primetime; in fact, Linux realtime performance is so bad that people believe the kernel will need to be re-written from the ground up before it's ready to play in this league. Don't know much about LabVIEW Realtime, except that the National Instruments salesdroids are happy to sell it to you. QNX looks like it's got the nicest kernel of all, but it's not clear that it's got the driver & third party application support we might need.

Which leaves us with CE.NET: It's got surprisingly good performance [bests VxWorks in tests], it's got all the multimedia codecs of Windows, and it's got built in support for ActiveDirectory [so technicians could upload data directly into the database and sign their work right then and there].

On a purely performance-based evaluation, I'd probably choose QNX, but because of its flexibility, we'll probably go with CE.NET.

Anyway, back to my original point: How is this new 2.6.x "realtime" kernel any better than the 2.4.x "realtime" kernel that failed so miserably in the Dedicated Systems review?

Thanks.

PDF DOCUMENT: http://www.qnx.com/products/ps_neutrino/benchmarks /elds/qnx62_elds.pdf

I can't agree more. OS X is my personal GUI of choice these days -- and yeah, since the beta release I've seen this thing go down maybe 4 times (not the "server" edition, not that it matters much). I was, each time, completely beating the hell out of the system -- and one of the times I had successfully mounted the core _live_ OS X file system (/) in a Linux based VirtualPC running on said file system. It didn't last too long... :)

I've run Linux for years upon years without interruption and my record keeper was a Netware 3.12 box that ran a few weeks shy of a decade. Still unacceptable for some kind of failure that could end a life (!)

The big benefit to many of the Un*x's is that 99% of the updates (pretty much short of a kernel swap out) can and are updated with no reboots needed. Simply restart the given service leaving all other services up and running. The end user typically may notice a "hickup", but not much more.

Three letters for you then: QNX>

I highly recommend QNX real-time OS. It is top notch. We have embedded devices here where I work that have *never* failed and some of them are running QNX. Just amazing stuff.

> What hardware does QNX Neutrino support?

The QNX Neutrino RTOS supports numerous processors from the x86/Pentium, PowerPC, ARM, StrongARM, XScale, MIPS, and SH-4 processor families. In addition, the QNX Momentics development suite provides board-support packages for a large variety of reference boards.

QNX(R) Neutrino(R) RTOS FAQs

One was told to do it or he'd be replaced by someone who would follow instructions

One who didn't say no ended up with a work-comp injury that the company, eventually, fired them for (illegal, but "prove it" in writing)

One who said "No. Not possible, given the constraints" was replaced by a 'yes-man' Manager wasted about 21 engineer months (15 real months) before the implantation was mathematically proven to be impossible in a public paper (due to race conditions where locks couldn't be used). Entire project was canned, manager was promoted for having the "smarts" to cancel such an ill-conceived project (no one remembered it was he who conceived it :-))

It's sorta like the saying "Easier to get forgiveness after the fact than ask for permission up front." Stoopid managers don't like to hear no, but prefer "yes" with shoddy work and bugs over all else. Knew one manager (managing a government security project) who was proud of having hidden bugs and problems and having beaten another company in competing for a contract (because they were "stupid" and were forthright and outspoken about problems or questions). This manager's motto was "it's not a bug unless the customer finds it" [so any work on "correcting" such "features" was a waste of company resources and an indication of the fixer's inability to follow orders (or so it said on reviews of his employees)].

It really depends on what type of company/manager you work for. But bottom line with global competition for your job is that those who follow orders without question rise the most quickly. Only if there are post-disaster or post-war investigations/tribunals are such ethics questioned -- otherwise, it's just "par for the course" in the battlefield of capitalism (lowest quality product that the consumer will bare for least price).

That's why the government had to create laws to stop exploitation of children, create minimum safe working conditions, minimum wages, product safety commissions, building codes (designed to be the _minimums_ necessary for a safe building, but are used by most builders as the target to shoot for -- because, again, in a capitalistic sense, shooting for anything higher than the minimum will cost more and make you less competitive than those that barely scrape over the minimums.

Of one of these 'do the minimum' managers, a government evaluator, who didn't like the manager's attitude, but had to *pass* him because he met the letter of the law on the minimums: "if you always shoot to just roll over the rim, sometimes you're going to miss".

But things are going to have to get worse before they will get better. Until such managers (and companies) are held accountable for failures, the situation won't change. Until customers stop buying buggy software, product quality will continue to decline (because if the customer is buying it, it still must be over the minimum -- let's try even lower quality the next time!). Anyone who cut their programming teeth during the dot.bomb era has been taught that software bugs are inevitable and to be expected. Software quality has been "spin doctored" to be something that is "not really possible" in real life. Everyone has been given _ALOT_ of propaganda about why software quality is impossible - to the point that most people are now believers. Though occasionally, there comes along a privately held company that disproves the myth (from slashdot, summary on qnx website) that probably got its biggest boost as MS FUD and propaganda.

Only when enough people die wil

One was told to do it or he'd be replaced by someone who would follow instructions

One who didn't say no ended up with a work-comp injury that the company, eventually, fired them for (illegal, but "prove it" in writing)

One who said "No. Not possible, given the constraints" was replaced by a 'yes-man' Manager wasted about 21 engineer months (15 real months) before the implantation was mathematically proven to be impossible in a public paper (due to race conditions where locks couldn't be used). Entire project was canned, manager was promoted for having the "smarts" to cancel such an ill-conceived project (no one remembered it was he who conceived it :-))

It's sorta like the saying "Easier to get forgiveness after the fact than ask for permission up front." Stoopid managers don't like to hear no, but prefer "yes" with shoddy work and bugs over all else. Knew one manager (managing a government security project) who was proud of having hidden bugs and problems and having beaten another company in competing for a contract (because they were "stupid" and were forthright and outspoken about problems or questions). This manager's motto was "it's not a bug unless the customer finds it" [so any work on "correcting" such "features" was a waste of company resources and an indication of the fixer's inability to follow orders (or so it said on reviews of his employees)].

It really depends on what type of company/manager you work for. But bottom line with global competition for your job is that those who follow orders without question rise the most quickly. Only if there are post-disaster or post-war investigations/tribunals are such ethics questioned -- otherwise, it's just "par for the course" in the battlefield of capitalism (lowest quality product that the consumer will bare for least price).

That's why the government had to create laws to stop exploitation of children, create minimum safe working conditions, minimum wages, product safety commissions, building codes (designed to be the _minimums_ necessary for a safe building, but are used by most builders as the target to shoot for -- because, again, in a capitalistic sense, shooting for anything higher than the minimum will cost more and make you less competitive than those that barely scrape over the minimums.

Of one of these 'do the minimum' managers, a government evaluator, who didn't like the manager's attitude, but had to *pass* him because he met the letter of the law on the minimums: "if you always shoot to just roll over the rim, sometimes you're going to miss".

But things are going to have to get worse before they will get better. Until such managers (and companies) are held accountable for failures, the situation won't change. Until customers stop buying buggy software, product quality will continue to decline (because if the customer is buying it, it still must be over the minimum -- let's try even lower quality the next time!). Anyone who cut their programming teeth during the dot.bomb era has been taught that software bugs are inevitable and to be expected. Software quality has been "spin doctored" to be something that is "not really possible" in real life. Everyone has been given _ALOT_ of propaganda about why software quality is impossible - to the point that most people are now believers. Though occasionally, there comes along a privately held company that disproves the myth (from slashdot, summary on qnx website) that probably got its biggest boost as MS FUD and propaganda.

Only when enough people die wil

• A web developer with a clean record
• A web developer who is a convicted felon
• A DBA with 10 years experience

Somebody has already mentioned QNX, but here's a quote from their 'licensing agreement:

B3.2. High Risk. Unless QSS has provided its express written consent for each Runtime Component in the Runtime Configuration, the Software may not be, and OEM will ensure that it is not, used in any application in which the failure of the Software could lead to death, personal injury or severe physical or property damage (collectively, ?High-Risk Applications?), including but not limited to the operation of nuclear facilities, mass transit systems, aircraft navigation or aircraft communication systems, air traffic control, weapon systems and direct life support machines. QSS expressly disclaims any express or implied warranty or condition of fitness for High-Risk Applications.

So if you fork out the cash, you can get a license that says, "yes, you can use this software to run a nuclear power plant."

A bold statement, but apparently it's well founded. I've heard nothing but good things about the reliability of QNX.

J

Somebody has already mentioned QNX, but here's a quote from their 'licensing agreement:

B3.2. High Risk. Unless QSS has provided its express written consent for each Runtime Component in the Runtime Configuration, the Software may not be, and OEM will ensure that it is not, used in any application in which the failure of the Software could lead to death, personal injury or severe physical or property damage (collectively, ?High-Risk Applications?), including but not limited to the operation of nuclear facilities, mass transit systems, aircraft navigation or aircraft communication systems, air traffic control, weapon systems and direct life support machines. QSS expressly disclaims any express or implied warranty or condition of fitness for High-Risk Applications.

So if you fork out the cash, you can get a license that says, "yes, you can use this software to run a nuclear power plant."

A bold statement, but apparently it's well founded. I've heard nothing but good things about the reliability of QNX.

J

Use a Unix/Linux machine

Not QNX! QNX drivers run in protected mode. Hell yeah, Microkernel biznatches!

Okay, a lot of pro-Linux studies have their own problems (frankly, I don't put much stock in "studies" any more, especially vendor-funded ones).

I've been drooling over embedded platforms for nearly a decade--jeeze, I hate the look of that word combination, but, moving right along...

The truth is that I'm a fan of all of them. Here, in no particular order, are some links.
Lynx is a link on the bottom left at this page.
An old standby, which really isn't that different from GNU HURD.
Sun's "telephone system"
This might very well be the most generic.
I even like this kind of thing, which displaces quite a bit of O/S purpose.

And why shouldn't I! Why shouldn't you? Well, the truth is that neither is a rhetorical question. That is my point. There are too many specific considerations, many of which are important, to declare dogmatically that any one operating system ought to be embedded--or even embedded "most often". This is not efficient executive decision-maker thinking. This kind of "debate" is about topics that permit/encourage the deadness of brains of said executives. (And we wonder why tech equity share prices stay in the gutter?)

First, let me be honest. I just skimmed the LinuxDevices article and didn't read the Microsoft article.

One thing I've noticed among PHBs is an ever-broadening definition of "embedded systems". I've seen more than one project go down the road of using a cPCI system running Windows NT 3.51 (yes these are current systems running this old version) on a harddrive. These systems are calling themselves "embedded".

This has been especially in systems that had serious size, weight, and power needs. Had I designed the system, I guess I would've used something like QNX or Linux on a much smaller processor, compact flash card, etc.

I guess my point is that these days it seems like general-purpose computers are being called "embedded" when I see embedded as much, much smaller (e.g. no moving parts, a microcontroller, etc...).

I dunno, I'm rambling...

Underneath is a completely different architecture, a true microkernel system, with all drivers, file systems, networking, etc. outside the kernel. So there's no way it can infringe anything from UNIX legacy code. It offers symmetrical multiprocessing and clustering, but again, the kernel-level approach is completely different than that of Linux/UNIX/BSD/etc.

But it's not open source. The QNX OS is free for individual use. Download here. But commercial use requires payment, and it's not cheap in small quantities. Nor are there enough desktop applications to make it usable in office environments. (There's Mozilla and ABIword; that's about it. If somebody ported Open Office to QNX, the desktop situation would look much better.)

The new version of the HURD kernel, based on L4, would have many of the same properties, but it's nowhere near ready for prime time. Based on the track record of the HURD crowd, completion of that project is many years away.

Anyone tried running QNX on the IPAQ? Available here There used to be some nice screenshots as well but they seem to have disappeared.

I wonder, if TRON was embedded system - how could they use it for school computers,
or maybe we should compare it to QNX ?

Isn't a PDA OS better suited to be a low-footprint gem like QNX?

In general, office parks, libraries, class rooms, and computer labs have a lot of idle time that could be exploited. Generally in cases like these the power is on anyway during certain hours and maintenance is covered anyway, so distributed computing might be used for many things.