Slashdot Mirror

FeeBSD? Is that a new name for BSD/OS?

Why not Symbian, QNX/a> or any of these ? This unhealthy obsession of "one size fits all" that abounds in the Linux world is exactly the sort of thing that people on Slashdot complain about the Microsoft world. You can't shoehorn these things without getting a poorer product as a result.

Wouldn't it be a better open source project if someone did what Linus did when he wanted to build an Open Source Unix and do the same for a proper RTOS ? By viewing Linux as the "only" solution it turns into the old "everything is a nail if you only have a hammer" discussion.

News for Nerds would be detailing what is happening in the RTOS and embedded world, rather than just being "News about Linux" to the detriment of better technologies. I know it sounds like a rant, but people like Wind River really do know what they are doing, this isn't a crappy Microsoft driven arena, this is where people really do know their shit, and the customer will not accept failure as part of the package.

Uh, "Linux development tools" would be cross compilers, IDEs, etc for VxWorks (or one of their other embbeded OSes) which run on a Linux workstation. AFAIK, Wind River doesn't sell an embedded version of Linux (or they don't advertise it well).

My company recently went down the path of evaluating several embedded linux suppliers, including Hard Hat Linux, LynuxWorks, RTLinux, and others. This evaluation was for an embedded communications platform.

There are many "real-world" issues that will arise when considering Linux instead of some of the more established embedded OS players (WindRiver/pSOS, Green Hills, Keil, QNX, et al -- see Embedded Systems Programming magazine for a pdf summary of embedded OS providers). These real-world issues, which will vary in importance among organizations for various reasons, include:

• Existing non-linux OS usage (e.g., WindRiver)
• Staff familiarity with Unix-like programming (most embedded developers know traditional RTOS-like architectures, not unix IPC methods or socket programming)
• Ease/difficulty with which already-written application software can migrate to a new OS
• OS support for preferred hardware devices (processor, communications peripherals, flash, etc. -- writing drivers from scratch isn't desirable)
• Internal corporate or organizational resistance to change (don't underestimate this one, folks!)
• Product life cycle phase
• Existing customer experience(s) with any previous OS-related behavior that may change under linux (customers like seeing behaviors they've seen before, not something new)
• Hard real-time versus soft real-time requirement(s)
• Communications stack and protocol requirements

In short, development in the embedded world tends to have many more complications associated with it. That's not necessarily bad -- in fact it often makes it more technically challenging and thus professionally satisfying -- it's just something that ought to be recognized, acknowledged, and taken into account when OS decisions are being made.

Andy

What of embedded systems? For a long time, there've been folks making money off having the dominant embedded systems OS be proprietary. Nonetheless, some open source companies are making an impact. (I work for MVista, btw, and so am more than a bit biased on the subject). There've been folks for a long time who've seen money in operating systems for routers, set-top boxes and PDAs, yet there are companies using Linux for all of these purposes.

The point I'm trying to make is that while there may be money to be made doing the proprietary thing, if going to open source drives your costs and development time down sufficiently (and it drives them down pretty darned far!), it can still be the most profitable thing to do in the long run. Maintaining your own OS and development tools is expensive; use OSS for your base (and outsource all the parts that only support your application) and focus on whatever distinguishes your product, and you can get more done faster -- and that's good for the bottom line.

Considering the rate at which they are acquiring and gutting their competition (PSOS, BSDI), let me tell you, you are not alone in your thinking.

Trust me.

...when these kind of resources are used to attack what is essentially a straw man. If they were going to attack a target with FUD, why wouldn't they attack the market leader, WindRiver VxWorks?

Proof positive they're irrationally scared by Linux.

But that's a brute-force approach. A better solution would be to profile applications, feed the profile info into the linker, have it put the most-used stuff first, and put a hint in the executable that indicates how much needs to be preloaded to get through the first few seconds of running without a page fault. That would lead big improvements in application launch times.

The Wind River DIAB System does things like that. So does Sun Workshop. But I don't see the Linux world doing anything like that yet.

I see the point about mod_perl. mod_perl is essentially a way to move some loading and memory management from the OS to the web server. If the OS were good enough at transaction processing and program initial load, the need for mod_perl would be much less. But mod_perl is a good tradeoff, because most CGI scripts are tiny. The poor program load performance inherent in a load-by-page-fault approach may have driven the server world into that solution. mod_perl, after all, was developed as a reaction to slow CGI program load times.

It's too late now, but at least this will be in the story when it gets archived.

There are more than 100 computers on the space station, just counting built-in. Indeed, each individual experiment rack -- about the size of an apartment fridge -- will include its own computer and custom software written for that experiment, all intended to link into the ISS network for data transmission and science interface. Many of the racks in Destiny (and future modules like Columbus and Kibo) provide station functions such as robot arm control, and each of these has its own computer as well.

But the core functions are called CDH (Command and Data Handling), including everything from navigation to turning the lights on and off: really, it's just the network infrastructure. Cabling is Thinnet. These computers are provided to NASA under contract by Honeywell, and are called MDMs, for Multiplexer/Demultiplexer. Think of a rack-mount swappable-processor system and you'll be close. These run the RTOS (Real Time Operating System) called VxWorks (from Wind River) -- the same RTOS used on the successful Mars Pathfinder mission, and custom software written by Honeywell and specific system vendors using Matrixx from the same vendor.

The crew use laptops, and there are quite a number of them judging by photographs, many seemingly permanently linked into one or more MDM functions. Since the MDMs have no other interface to the crew, this makes sense. The laptops that link to the MDMs use Sun Solaris and a custom client that provides data feedback and a semi-graphical user interface, depending on function. These laptops go by the generic name PCS (Portable Computer System) and conform to specifications set during the mid-1990s. The PCS model in use is the IBM Thinkpad, and contrary to popular belief, these models have evolved along with the Shuttle and Station programs -- just more slowly than the commercial market. Models need to be constructed with higher-quality components and undergo flight qualification. The laptops available to Expedition One were (I believe) at least Pentium I-MMX class machines.

Some of these laptops are dual-boot with Windows NT on the other partition. Windows NT does have a function on the space station, but it is in no way linked to the command and control systems as outlined above. The major purpose it serves seems to be e-mail, but probably also record-keeping and recreation in the form of games or playing portable media such as CDs or DVDs. (There is also a built-in DVD player in one module that the astronauts can gather around for "movie night".) Windows NT can behave perfectly well when given a known, well-defined set of hardware and a well-tweaked configuration. The astronauts have access to spare hard drives that have images created on Earth using Norton Ghost. In one incident during Expedition One this was insufficient, and a spare hard drive was sent up during the current shuttle mission in order to bring that laptop back into service. But since they have plenty, it probably did not materially affect operations to be missing one.
----
lake effect weblog

It's too late now, but at least this will be in the story when it gets archived.

There are more than 100 computers on the space station, just counting built-in. Indeed, each individual experiment rack -- about the size of an apartment fridge -- will include its own computer and custom software written for that experiment, all intended to link into the ISS network for data transmission and science interface. Many of the racks in Destiny (and future modules like Columbus and Kibo) provide station functions such as robot arm control, and each of these has its own computer as well.

But the core functions are called CDH (Command and Data Handling), including everything from navigation to turning the lights on and off: really, it's just the network infrastructure. Cabling is Thinnet. These computers are provided to NASA under contract by Honeywell, and are called MDMs, for Multiplexer/Demultiplexer. Think of a rack-mount swappable-processor system and you'll be close. These run the RTOS (Real Time Operating System) called VxWorks (from Wind River) -- the same RTOS used on the successful Mars Pathfinder mission, and custom software written by Honeywell and specific system vendors using Matrixx from the same vendor.

The crew use laptops, and there are quite a number of them judging by photographs, many seemingly permanently linked into one or more MDM functions. Since the MDMs have no other interface to the crew, this makes sense. The laptops that link to the MDMs use Sun Solaris and a custom client that provides data feedback and a semi-graphical user interface, depending on function. These laptops go by the generic name PCS (Portable Computer System) and conform to specifications set during the mid-1990s. The PCS model in use is the IBM Thinkpad, and contrary to popular belief, these models have evolved along with the Shuttle and Station programs -- just more slowly than the commercial market. Models need to be constructed with higher-quality components and undergo flight qualification. The laptops available to Expedition One were (I believe) at least Pentium I-MMX class machines.

Some of these laptops are dual-boot with Windows NT on the other partition. Windows NT does have a function on the space station, but it is in no way linked to the command and control systems as outlined above. The major purpose it serves seems to be e-mail, but probably also record-keeping and recreation in the form of games or playing portable media such as CDs or DVDs. (There is also a built-in DVD player in one module that the astronauts can gather around for "movie night".) Windows NT can behave perfectly well when given a known, well-defined set of hardware and a well-tweaked configuration. The astronauts have access to spare hard drives that have images created on Earth using Norton Ghost. In one incident during Expedition One this was insufficient, and a spare hard drive was sent up during the current shuttle mission in order to bring that laptop back into service. But since they have plenty, it probably did not materially affect operations to be missing one.
----
lake effect weblog

Why do I say this? Well it should be obvious now. RTLinux is not a Linux distribution, but rather a realtime executive that can ran a "Linux image". Similar approaches have been taken by several groups, like Radisys and Nematron, to make Windoze a "realtime OS". The results are generally all the same. Because of the special tricks that must be used, you end up with an OS that is less stable than the off-the-shelf product. And you really do not get many of the benefits of using an off-the-shelf OS, because anything you do that needs to be realtime has to be run by and programmed for the "realtime kernel" (not the OS kernel!)and its proprietary API.

As far as realtime performance is concerned, the last numbers I heard at the 2000 ISA show showed that RTLinux (actually it may have been Montavista) was well behind the major players (i.e. QNX, VXWorks) in terms of realtime performance. Worst case interrupt latencies were on the order of 40 microseconds, compared to sub-microsecond latencies for others. This is only to be expected with the overhead of running two OS's. In all fairness, it did beat Windows CE. :-) An interesting thing to note if you read about Nematron's HyperKernel (above) is that realtime latencies actually get worse when the Windows NT side is heavily utilized! I would guess the same is true of the realtime Linuxes. So don't play Quake or your reactor may meltdown... ;-)

Embedded applications have an extra requirement called "Real-Time". This means that many tasks must execute within a certain number of ms. Many commercial operating systems such as VxWorks have made a living out of providing just that service.

Linux, of course, does not have a real-time scheduler. But many linux vendors such as Mvista are providing linux distributions with a real-time kernel module to take care of those tasks with a real-time requirement, and allowing the standard linux scheduler to take care of the rest.

This provides the following advantages to embedded developers over commercial RTOS's:

1) It's WAY cheaper
2) The support for linux is actually much better, due to the open source nature
3) Closed source RTOS hardware integration bugs are nearly impossible to debug, because the source is CLOSED. You have to wait for a Field Application Engineer to get flow in, on your dollar, to write your stupid driver.

Linux is creating real fear in the embedded RTOS market space.

For true real-time, it's not as stable. But for complex network applications with a lower real-time requirement, it's a killer.

If Wind River is going to "integrate" FreeBSD the same way they "integrated" PSOS, then you can kiss it goodbye.

The BSD license allows for proprietary modules built on top of open software. When people at my workplace refer to "Microsoft embedded", they mean Wind River.

Embrace, extend, extinguish.

Go to their web site you'll see PSOS listed as a product. Then call them up and try to buy it without buying VxWorks.

Good luck!

...or how about VxWorks from WindRiver?

- j

This is interesting in light of an article published on The Motley Fool on Monday. They predicted that Wind River would be the winner over Linux in the embedded systems market. Their reasons? Apparently, the nature of open source is one problem; another one they cited is the "lack of real-time capabilities"in Linux (and I thought these guys did their research!!!) MS is a loser from the get-go, apparently because it takes 18 months to fix anything.

Rack another one up for Linux!

I work at IPC. We use VxWorks, an embedded UNIX-like OS and Solaris. Contact HR through the web page.

If you are a programmer, at least, look at companies that develop so-called embedded systems. The operating systems of choice in this industry are UNIX-like: WindRiver vxWorks and LynuxWorks LynxOS/BlueCat Linux. Indeed, many embedded designs are starting to utilize plain Linux.

What are embedded systems, you ask. Damn smart question - you should be proud of yourself. Fact is, probably most programmers in the world are actually developing such systems. Basically, any electronic/computing device that is not a conventional computer. For instance, gaming devices, cd-rom drives, DNA analyzers (I do that), telecommunications devices, power utility switches, routers/bridges, medical instruments, .. ..

Keywords to look for would be firmware development, embedded systems programming, real-time development.

Best part of it all is that you'll probably get to deal with some of the most interesting development environments that exist. For instance, we developed our said DNA analyzer using ObjecTime, and going forward we'll be using Rational RoseRT - tools that automatically generate C++ code based on the model that you visually draw! (You just fill in the "meat" of each function - the action that takes place in a transition, say). Logic Analyzers, emulators/simulators, virtual platforms, cross-compiler environments -- this is all the stuff that teach you everything about computers - and nice OS designs.

Now, if you were not actually asking as a programmer, but as a systems administrator or other IT drone, here is the (more limited) tip: Go for the back ends - i.e. web servers, IBM's Net.Commerce development, DNS/Firewall administration, that type of stuff. But those are not real people - the I.T. world is just to stuffed with "management types". If you still have the choice, look for software/firmware development environments - much cooler people and more casual atmosphere.

If you are a programmer, at least, look at companies that develop so-called embedded systems. The operating systems of choice in this industry are UNIX-like: WindRiver vxWorks and LynuxWorks LynxOS/BlueCat Linux. Indeed, many embedded designs are starting to utilize plain Linux.

What are embedded systems, you ask. Damn smart question - you should be proud of yourself. Fact is, probably most programmers in the world are actually developing such systems. Basically, any electronic/computing device that is not a conventional computer. For instance, gaming devices, cd-rom drives, DNA analyzers (I do that), telecommunications devices, power utility switches, routers/bridges, medical instruments, .. ..

Keywords to look for would be firmware development, embedded systems programming, real-time development.

Best part of it all is that you'll probably get to deal with some of the most interesting development environments that exist. For instance, we developed our said DNA analyzer using ObjecTime, and going forward we'll be using Rational RoseRT - tools that automatically generate C++ code based on the model that you visually draw! (You just fill in the "meat" of each function - the action that takes place in a transition, say). Logic Analyzers, emulators/simulators, virtual platforms, cross-compiler environments -- this is all the stuff that teach you everything about computers - and nice OS designs.

Now, if you were not actually asking as a programmer, but as a systems administrator or other IT drone, here is the (more limited) tip: Go for the back ends - i.e. web servers, IBM's Net.Commerce development, DNS/Firewall administration, that type of stuff. But those are not real people - the I.T. world is just to stuffed with "management types". If you still have the choice, look for software/firmware development environments - much cooler people and more casual atmosphere.

A better comparison is QNX to Cygnus eCos, the Linux-preemptive RT/Linux kernel/system, WindRiver's VxWorks, etc... It is really unfair (for both sides) to compare a "lightweight" OS for small, embedded systems against a be-all/do-all behemoth like Linux (which does have a minimum size limitation).

I'm sure you'll be able to find some overlap, but it's really a question of "which is better for this application" and not "which is better period".

-- Bryan "TheBS" Smith

[ Note: I was a Software Engineer at Coleman Aerospace for 3 years ]

Many of the early computers in ballistic missiles and space probes borrowed heavily from the military. Much of the gyros and computing systems were produced by Bendix for the Department of Energy (according to various public documents from about a year ago, Bendix development is still located at the DoE's Kansas City Plant). In case you aren't familiar with how the government works, the DoE was and still is the non-military, government agency tasked with the creation of numerous components of our nuclear arms technology (as well as their normal energy details, a natural tandem role). Looking at their "most advanced computer" in the early 1980s (the Bendix 930 in the Pershing II MRBM), you essentially had a 16-bit CPU and database with 64KB of memory on various cards in a wire-wrapped backplane. And, yes, all the target code for these machines are done in assembler.

Today, both the military and NASA contractors "better, faster, cheaper" attitude of using off-the-shelf hardware, tools and software revolves mainly around the VME architecture (usually for 68300 and, increasingly, PowerPC boards -- military spec/hardening) with WindRiver's VxWorks RTOS. VxWorks is heavily BSD 4.3-based OS with response times in the tens of microseconds (on a 40-50MHz processor). Development is done using GNU development tools using a customized Cygnus GNUPro (now under RedHat's services group) product called Tornado (customized for WindRiver by Cygnus) so it can target various VxWorks architectures with Linux, Solaris and Windows being the most popular host development platforms. [ I personally found Windows to be a real pain if you also install Visual Studio on the same system because which tries to take over your system -- have to be careful you run the right make, etc... binary ].

A well-known 68K/VxWorks-based mission was the Mars Pathfinder. Today, the combo is used in a wide variety of launch and space vehicles. At my former employer, we used it for our ballistic target and booster vehicles for the military and LEO (low earth orbit) launch vehicles for NASA (and they continue to do so). A future mission to the outer planets will be PPC/VxWorks-based, all written with the GNU development system. [ Since Linux nor most other general-purpose OSes cannot guarantee such "hard" real-time response times (let alone no Windows platform can seem to deliver even deliver any "soft" real-times either), it is my hope that Cygnus' (now RedHat's) eCos takes off and cuts into VxWorks' market in the next 5 years). ]

Which brings me to my final point: I think people get caught up with the whole this OS versus that OS issue when the argument should be GNU development versus Microsoft Visual development for "mission critical" purposes. The GNU cross-compilers and tools allow you to target dozens of platforms and massive code reuse whereas Microsoft changes its Visual Studio products on a whim. I mean, it's really harder to port Windows code just for a version change than it is to port to another, completely different architecture with GNU. I personally don't see why Windows developers put up with it because Cygnus makes some damn good IDE and tools for development.

Personally, I think the best remedy for the whole DOJ v. Microsoft trial would be to force Microsoft to support GNU-based development tools for the Windows platform (both target and host) -- and set a time-frame in which they would have to drop their current, non-GNU-based Visual product (e.g., 5 years). This would do several things: actually force the documentation of the API, thus increase overall stability of the Windows platform, finally address multi-user ignorance as the main problem with Windows security (98% of even Microsoft's own applications are multi-user ignorant!), and many, many other benefits to the developers as well as the consumer. Of course no one in the trial has the forsight to see this as the best remedy, and I seriously doubt we will see any discussion of it either.

-- Bryan "TheBS" Smith

[ Note: I was a Software Engineer at Coleman Aerospace for 3 years ]

Many of the early computers in ballistic missiles and space probes borrowed heavily from the military. Much of the gyros and computing systems were produced by Bendix for the Department of Energy (according to various public documents from about a year ago, Bendix development is still located at the DoE's Kansas City Plant). In case you aren't familiar with how the government works, the DoE was and still is the non-military, government agency tasked with the creation of numerous components of our nuclear arms technology (as well as their normal energy details, a natural tandem role). Looking at their "most advanced computer" in the early 1980s (the Bendix 930 in the Pershing II MRBM), you essentially had a 16-bit CPU and database with 64KB of memory on various cards in a wire-wrapped backplane. And, yes, all the target code for these machines are done in assembler.

Today, both the military and NASA contractors "better, faster, cheaper" attitude of using off-the-shelf hardware, tools and software revolves mainly around the VME architecture (usually for 68300 and, increasingly, PowerPC boards -- military spec/hardening) with WindRiver's VxWorks RTOS. VxWorks is heavily BSD 4.3-based OS with response times in the tens of microseconds (on a 40-50MHz processor). Development is done using GNU development tools using a customized Cygnus GNUPro (now under RedHat's services group) product called Tornado (customized for WindRiver by Cygnus) so it can target various VxWorks architectures with Linux, Solaris and Windows being the most popular host development platforms. [ I personally found Windows to be a real pain if you also install Visual Studio on the same system because which tries to take over your system -- have to be careful you run the right make, etc... binary ].

A well-known 68K/VxWorks-based mission was the Mars Pathfinder. Today, the combo is used in a wide variety of launch and space vehicles. At my former employer, we used it for our ballistic target and booster vehicles for the military and LEO (low earth orbit) launch vehicles for NASA (and they continue to do so). A future mission to the outer planets will be PPC/VxWorks-based, all written with the GNU development system. [ Since Linux nor most other general-purpose OSes cannot guarantee such "hard" real-time response times (let alone no Windows platform can seem to deliver even deliver any "soft" real-times either), it is my hope that Cygnus' (now RedHat's) eCos takes off and cuts into VxWorks' market in the next 5 years). ]

Which brings me to my final point: I think people get caught up with the whole this OS versus that OS issue when the argument should be GNU development versus Microsoft Visual development for "mission critical" purposes. The GNU cross-compilers and tools allow you to target dozens of platforms and massive code reuse whereas Microsoft changes its Visual Studio products on a whim. I mean, it's really harder to port Windows code just for a version change than it is to port to another, completely different architecture with GNU. I personally don't see why Windows developers put up with it because Cygnus makes some damn good IDE and tools for development.

Personally, I think the best remedy for the whole DOJ v. Microsoft trial would be to force Microsoft to support GNU-based development tools for the Windows platform (both target and host) -- and set a time-frame in which they would have to drop their current, non-GNU-based Visual product (e.g., 5 years). This would do several things: actually force the documentation of the API, thus increase overall stability of the Windows platform, finally address multi-user ignorance as the main problem with Windows security (98% of even Microsoft's own applications are multi-user ignorant!), and many, many other benefits to the developers as well as the consumer. Of course no one in the trial has the forsight to see this as the best remedy, and I seriously doubt we will see any discussion of it either.

-- Bryan "TheBS" Smith

[ Note: I was a Software Engineer at Coleman Aerospace for 3 years ]

Many of the early computers in ballistic missiles and space probes borrowed heavily from the military. Much of the gyros and computing systems were produced by Bendix for the Department of Energy (according to various public documents from about a year ago, Bendix development is still located at the DoE's Kansas City Plant). In case you aren't familiar with how the government works, the DoE was and still is the non-military, government agency tasked with the creation of numerous components of our nuclear arms technology (as well as their normal energy details, a natural tandem role). Looking at their "most advanced computer" in the early 1980s (the Bendix 930 in the Pershing II MRBM), you essentially had a 16-bit CPU and database with 64KB of memory on various cards in a wire-wrapped backplane. And, yes, all the target code for these machines are done in assembler.

Today, both the military and NASA contractors "better, faster, cheaper" attitude of using off-the-shelf hardware, tools and software revolves mainly around the VME architecture (usually for 68300 and, increasingly, PowerPC boards -- military spec/hardening) with WindRiver's VxWorks RTOS. VxWorks is heavily BSD 4.3-based OS with response times in the tens of microseconds (on a 40-50MHz processor). Development is done using GNU development tools using a customized Cygnus GNUPro (now under RedHat's services group) product called Tornado (customized for WindRiver by Cygnus) so it can target various VxWorks architectures with Linux, Solaris and Windows being the most popular host development platforms. [ I personally found Windows to be a real pain if you also install Visual Studio on the same system because which tries to take over your system -- have to be careful you run the right make, etc... binary ].

A well-known 68K/VxWorks-based mission was the Mars Pathfinder. Today, the combo is used in a wide variety of launch and space vehicles. At my former employer, we used it for our ballistic target and booster vehicles for the military and LEO (low earth orbit) launch vehicles for NASA (and they continue to do so). A future mission to the outer planets will be PPC/VxWorks-based, all written with the GNU development system. [ Since Linux nor most other general-purpose OSes cannot guarantee such "hard" real-time response times (let alone no Windows platform can seem to deliver even deliver any "soft" real-times either), it is my hope that Cygnus' (now RedHat's) eCos takes off and cuts into VxWorks' market in the next 5 years). ]

Which brings me to my final point: I think people get caught up with the whole this OS versus that OS issue when the argument should be GNU development versus Microsoft Visual development for "mission critical" purposes. The GNU cross-compilers and tools allow you to target dozens of platforms and massive code reuse whereas Microsoft changes its Visual Studio products on a whim. I mean, it's really harder to port Windows code just for a version change than it is to port to another, completely different architecture with GNU. I personally don't see why Windows developers put up with it because Cygnus makes some damn good IDE and tools for development.

Personally, I think the best remedy for the whole DOJ v. Microsoft trial would be to force Microsoft to support GNU-based development tools for the Windows platform (both target and host) -- and set a time-frame in which they would have to drop their current, non-GNU-based Visual product (e.g., 5 years). This would do several things: actually force the documentation of the API, thus increase overall stability of the Windows platform, finally address multi-user ignorance as the main problem with Windows security (98% of even Microsoft's own applications are multi-user ignorant!), and many, many other benefits to the developers as well as the consumer. Of course no one in the trial has the forsight to see this as the best remedy, and I seriously doubt we will see any discussion of it either.

-- Bryan "TheBS" Smith

Bwahahahaa!

What's next? Free-as-in-beer VxWorks? Nahhh....

Wind River Systems would disagree with you on qnx being the undisputed king of embedded. they just bought their second place competitor and are the market leader in embedded operating systems.

--
J Perry Fecteau, 5-time Mr. Internet
Ejercisio Perfecto: from Geek to GOD in WEEKS!

Uh, no. That would be almost as bad as running on NT. Unless you happen to have a realtime, fully rudendant, fail-safe, ultra secure version of Linux in your pocket. No, I thought not. I like Linux as much as the next hack, I also like SunOs and FreeBSD but I would never run a milatary app on any of those os's. If you want to see a Mil-grade os check out the fellos at Wind River not that they are perfect and I would not want to run a word prosseser that runs under ther stuff but If I wher to try to control a flying robot that could blast the hell out of a city I might consiter them.

And yes I know that I have bad spelling!!!

Hello? Can you say VxWorks? pSOS? OS-9? VRTX? There is more to operating systems than just the behemoths used on peoples desktops...