Slashdot Mirror

1. As a straightforward RTOS for device control (e.g., the fire-suppression systems are mentioned - and online, things like propulsion, missile launch systems, etc. are mentioned here)
2. (and here's what's confusing people) In the form of LynxSecure, a multilevel secure (MLS) variant of LynxOS that acts as a type 1 hypervisor for the workstations that are mentioned, the CDS; LynxSecure in this case, per the article, hosts Linux VMs, and this "allows the workstation to connect to various networks partitioned by security level and purpose". The basics of how this works is described on the company's website

1. As a straightforward RTOS for device control (e.g., the fire-suppression systems are mentioned - and online, things like propulsion, missile launch systems, etc. are mentioned here)
2. (and here's what's confusing people) In the form of LynxSecure, a multilevel secure (MLS) variant of LynxOS that acts as a type 1 hypervisor for the workstations that are mentioned, the CDS; LynxSecure in this case, per the article, hosts Linux VMs, and this "allows the workstation to connect to various networks partitioned by security level and purpose". The basics of how this works is described on the company's website

Yes, a static baseline is great for certification programs such as EAL and FAA approval, but it's not the only sort of "stable" that you want. Data centres want a "carrier-grade" OS (which means five nines reliability). They don't necessarily care if they have to patch, since you can now hot-patch the kernel without taking it down, but they absolutely do not want the software to show any unreliability whatsoever. They'd likely get upset at having to patch more than once a year, since in-situ patching isn't always safe, but if you're limited to a few minutes downtime a year on a server as an absolute maximum (this is ignoring failover, etc, that's a whole different issue than a specific physical or virtual server instance being five nines) then I could see it being tolerated a whole lot more than a blind kernel upgrade at year's end.

(This assumes that the hot upgrades can be made fault-tolerant enough that a brown-paper-bag release - you know they're going to happen on any tree eventually - can be backed out without violating five nines.)

We need a few special-purpose boxes that are highly secure, as examples. The components exist. There are hypervisors certified to EAL-7. They show up in industrial systems, DoD systems, and avionics. They should be showing up in routers, firewalls, DNS servers, and ATMs.

A push by Homeland Security to increase the security level of critical infrastructure would not be out of place.

Understood. Difficult to find off the shelf stuff for free, but there's this; http://www.lynuxworks.com/embedded-linux/embedded-linux.php

Lynx OS is EAL 7, and has been for a while. It will be quite some time before Greenhill makes it to EAL7.

Of course it's a marketing joke, this is what they do, they lie, they lie and they lie. If their OS was that secure and bug free, they wouldn't mind releasing the code as Open Source.

Lynx OS is EAL 7, and has been for a while. It will be quite some time before Greenhill makes it to EAL7. In the mean time, Lynuxworks uses Linux API, so that you have your choice of a real linux solution, or if needed, you can switch up to LynuxOS.

Yeah, you could program most stuff on DOS. And put up with incompatible and glitchy graphics libraries just to have that arrow cursor and some minimal widgets for your app. You could write your own interrupt-based thread simulation, 'cause DOS didn't come with any support for that. And write your own spinlock semaphores at that, and wonder why your app deadlocks. You could still do your own pointer arithmetic to put up with 16 bit addressing in a world of gigabyte-sized data sets, and do your own shitty XMS/EMS block copying just to address more than 640 KB. You could even reimplement most of the network protocols and half the other libraries, because nobody else ported those libraries to DOS. Etc.

At least come up with a realistic implementation that someone would do. Such as implementing medical systems ontop of MontaVista or Lynuxworks and the problems you would have on those compared to doing it on Windows.

Right now, your 'argument' is just fluff to me.

Yeah, you could do that, just to willy-wave about your app not needing a full-featured OS at all.

I'm pretty sure people said 'bloat' not 'not needing a full-featured OS'. The systems I have mentioned are fully featured.

http://www.openbsd.org/

http://www.lynuxworks.com/solutions/security.php

http://www.coyotos.org/

There are worst-time patches and CPU binding patches for Linux. Not only that, but many embedded applications are not, in fact, in need of an RTOS at all. Linux won't displace QNX, LynxOS, and VxWorks completely, but to say it's not making gains in the embedded space is either disingenuous or ignorant of the facts.

It'd also be pretty big news to, for example, MontaVista, Nokia, Cisco, and the BlueCat folks that embedded Linux isn't making any sales.

http://www.lynuxworks.com/solutions/milaero/in-action/ddx.php

http://www.spacewar.com/reports/Concurrents_Redhawk_Linux_Selected_For_THAAD_Missile_Defense_Program.html

The military is already embracing real-time linux distros. . .

May I be the first to say Domo Arigatou .... any ways...

Here's a tidbit of Linux/iRobot/John Deere information for you all.

Which distribution did you do embedded Linux development with? LynuxWorks is the only distribution I know of which provides a comparable embedded systems OS to QNX, Green Hills, vxWorks, et al. These are all hard real-time, safety-critical OSes with certification packages for deployment in a regulated environment.

My company went with Lynuxwork's BlueCat as our embedded Linux and continually regretted it. We had no Linux expertise and so wanted the professional services that was available from Lynuxworks along with their distro. However, we found that 1) we had a hard time getting them to honor our business priorities, and 2) the distro was based on a kernel old enough that we couldn't update to the latest releases of things to get bugs fixed. It would have been much better to hire a good Linux guy (which we ended up needing to do anyway) and going with a standard distro. The amount of support we could rustle up from the community and consultants was at least as good and sometimes better than the support from Lynuxworks that we were paying for.

When I see something like this of course my brain starts to pick apart how it may work and what went into it. TFA didn't mention much about what was controlling it .. however this is my guess:

LynxOS

Damn I wish I got paid to make stuff like that. Anyone find any other info giving more detail as to exactly what went into that system? This would be an invaluable safety system on vehicles, if nothing less just shielding the driver from the initial crash.

LynuxWorks? Yes, I'm sure that's a complete, good faith coincidence... How am I supposed to pronounce that without saying Linux? I don't like the use of confusion here.

LinuxWorks was founded in 1988. Linus Torvalds began work on Linux in 1991.

From the LynuxWorks website:

"Established in 1988, the company is a technology leader in the real-time operating systems (RTOS) industry....LynuxWorks is a trademark and LynxOS and BlueCat are registered trademarks of LynuxWorks, Inc. Other brand or product names are registered trademarks or trademarks of the respective holders. Linux is a registered trademark of Linus Torvalds."

This is great and all, I just don't see why this is front page news. I would consider ARM-DSP hardware with Linux support mainstream rather than a bold step taken by TI. A random grab from sponsored adds on google:
http://www.sandorlabs.com/
http://www.compulab.co.il/
http://www.plexxa.com/
http://www.atmel.com/products/AT91/
http://www.xbow.com/
http://www.lynuxworks.com/

All products seem to support Linux on ARM/XScale and (at least) some in combination with a DSP.
Sure, Texas instruments is a heavyweight in the embedded world, but is this just another clueless ScuttleMonkey post or did I miss something?

HIL simulations are hard realtime applications. Do you even know what the definition of "hard realtime" is? In a nutshell it's "If a task fails to run at it's scheduled time, it's a fatal error.". Soft realtime means it's not a 'fatal' error if the task schedule isn't met (i.e. a dropped frame in a game).

Moreover, not only is Linux inappropriate for real-time primary defense system..

Baloney.

it is generally strictly prohibited (almost uniformly) by military specification because it is not a true real time operating system. Back at the old job, VxWorks [xs4all.nl] variants were most common.

Also not true. Linux (with an appropriately modified kernel) is in fact a "true" realtime OS. Here's a list of military projects using Lynuxworks (only one flavor out of several).

This page has a good description of the Lynuxworks product, along with some RT certification information.

WindRiver is also offering Linux, though I see their version isn't RT capable. Guess they still haven't figured out that vxWorks is on the way out...

(BTW, I'm a certified vxWorks developer myself...)

HIL simulations are hard realtime applications. Do you even know what the definition of "hard realtime" is? In a nutshell it's "If a task fails to run at it's scheduled time, it's a fatal error.". Soft realtime means it's not a 'fatal' error if the task schedule isn't met (i.e. a dropped frame in a game).

Moreover, not only is Linux inappropriate for real-time primary defense system..

Baloney.

it is generally strictly prohibited (almost uniformly) by military specification because it is not a true real time operating system. Back at the old job, VxWorks [xs4all.nl] variants were most common.

Also not true. Linux (with an appropriately modified kernel) is in fact a "true" realtime OS. Here's a list of military projects using Lynuxworks (only one flavor out of several).

This page has a good description of the Lynuxworks product, along with some RT certification information.

WindRiver is also offering Linux, though I see their version isn't RT capable. Guess they still haven't figured out that vxWorks is on the way out...

(BTW, I'm a certified vxWorks developer myself...)

what about a complete embedded linux distribution for x86. Just think how much faster your system would become.

This has already been modded as a troll, but giving you the benefit of the doubt, do you mean something different from things like Monta Vista or Lynuxworks ?

Of course, it's also worth mentioning that "real time" doesn't necessarily mean "fast." In fact, rather the opposite is typically true: a real-time system must (by nature) make the worst case predictable -- but often compromises the average performance to do so.

--
The universe is a figment of its own imagination.

The reason it takes a LONG time to write safety-critical (not enterprise-critical) code is that test environment you mention. It takes weeks or months to create the perfect test environment.

Fast Company did an article on how NASA does the coding process here. It's not fast. It's not glamorous. It's demanding, complicated, and hostile.

You want a word processor that works perfectly, ever single time? To follow the "safety-critical" model and still make it happen quickly you would need a system that was designed from the blueprints up to service that precise need in those precise conditions. Every line in the code must line up perfectly with the requirements. Independent inspection is required.

The zOS stuff and the Alpha systems were examples of this. You will use ONLY the correct peripheral, and ONLY when it has been installed by authorized personnel. You will NOT deviate from this. The software will be ONLY the software certified to run there. ONLY in the combinations that are supported. In return, you will have a rep from the company there (virtually or physically) to help you in minutes. I think our record was physical, in-person assistance on an OS/390 issue within 30 minutes. You also pay an amazing amount for it. The FAA for example requires that a product be certified as a whole. OS, hardware, software, the works.

People don't think MS Word is worth $60k per seat, and they probably would be pissed if MS said "You can't install MS Word on the IBM T42... it is only supported on the T40 and T41 so far".

Oh, and I would be pretty impressed if Java were ever life/safety certified . It would require some amazing JRE, that's for sure. I'd expect to see a Perl script certified long before.

BTW, I would personally love to find some more OSS software products that were more or less DO-178A/B certified (on specific hardware, obviously). There is a version of linux that is. Even on IA-32 architecture.

-WS

Sorry people, Linux is not "safe."

Depends on which Linux your talking about. Maybe if you were talking about a Linux that is geared towards military use, and that underwent formal methods of software verification (which is a standard practice in that industry), you wouldn't say that. Or, to keep it at a more prosaic level, if only Linux hackers looked thouroughly at their source code and adopted counter-measures to buffer overflows, maybe you would have a resonably safe Os at your home.
However, at the current state of: 1) hacker sloppiness (99% couldn't give a shit about proving and algorithm correct - let alone construct software with formal specification and verification); 2) languages used (C/C++ used everywhere is a disease we must cure ourselves of - we're all in trouble.
And what fucks the software industry is this attitude that there's nothing you can do about. Or, as is the philosophy in the Linux Kernel community: ship fast, fix later, because "there are many eyes looking at the source code and somebody will fix it. Bullshit. May 2005 - Linux already has 9 kernel exploits from this year.

If you do not want anything do not compile it. simple

http://openwrt.org/
http://www.uclinux.org/
http://www.lynuxworks.com/
http://www.windriver.com/

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.

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.

Yup. I must have entered in the HTML incorrectly when I posted originally.

Here is the link I indended to include originally.

Here is a recent press release about a Rockwell Collins Program that is going to use it.

Here is a press release from when it was first announced.

Yup. I must have entered in the HTML incorrectly when I posted originally.

Here is the link I indended to include originally.

Here is a recent press release about a Rockwell Collins Program that is going to use it.

Here is a press release from when it was first announced.

Linux has been evaluated and certified for safety critical applications. LynuxWorks and Rockwell Collins worked together to certify a specific Linux kernel and distribution to
DO-178B Level A certification.

DO-178B is the standard for software on commerical aircraft. It's difficult and expensive to do, but it's required by the FAA. Level A is the highest level of certication. Level A certification is required for critcal components like the displays, fight controls and the auto-pilot.

There really aren't any software certification standards that are more rigorous than DO-178B, and Linux already has been certified.

Yep, plus others in Green Hills' own industry see what he's trying to do: FUD at it's best. The CEO at LynuxWorks has issued what seems to be nearly a direct response to O'Dowds' on the subject.

Do you mean MontaVista, LynuxWorks, Metroworks, or some other company?

Each company should be in charge of auditing, testing and validating its products. It should also be noted that embedded realtime Linux distributions are much smaller than regular desktop/server distributions. Most DOD systems aren't accessible over a network, so that type of vulnerability is largely not a problem.

BTW, this complaint from Dowd is old news - it first surfaced this spring. Not many are buying his argument, from what I can tell.

Accelerated-X!!! There's also Metro-X, though Metro Link's webpage appears to be down and I can't find them otherwise.

Laugh all you want about paying for commercial software, but when it comes to these quality products, it's worth it.

Well, ignoring that your login tells it all, I find it funny that you would knock Linux for support.

I am not knocking Linux or BSD support. I am just saying that I have had situations where support from commercial vendors is really worth it, especially when you need the same level of support for old versions where upgrading is not an option.

In addition, the Linux/OSS world gives you the source code...

Yes, the Linux and BSD kernel and userland source is available for free. That is a huge bonus. However, most RTOS vendors will make their code avaialble for a fee (last time I looked into this, it was pretty big, though.

Linux and BSD are both fantastic systems, but IMHO, I do not think they belong in mission critical realtime applications. There are some companies like LynuxWorks that support embedded Linux, but given the choice I would almost always choose LynxOS over Embedded Linux, but most of the embedded systems I have work on require hard-realtime and I tend to choose very conservatively on embedded projects.

Well, ignoring that your login tells it all, I find it funny that you would knock Linux for support.

I am not knocking Linux or BSD support. I am just saying that I have had situations where support from commercial vendors is really worth it, especially when you need the same level of support for old versions where upgrading is not an option.

In addition, the Linux/OSS world gives you the source code...

Yes, the Linux and BSD kernel and userland source is available for free. That is a huge bonus. However, most RTOS vendors will make their code avaialble for a fee (last time I looked into this, it was pretty big, though.

Linux and BSD are both fantastic systems, but IMHO, I do not think they belong in mission critical realtime applications. There are some companies like LynuxWorks that support embedded Linux, but given the choice I would almost always choose LynxOS over Embedded Linux, but most of the embedded systems I have work on require hard-realtime and I tend to choose very conservatively on embedded projects.

Well, ignoring that your login tells it all, I find it funny that you would knock Linux for support.

I am not knocking Linux or BSD support. I am just saying that I have had situations where support from commercial vendors is really worth it, especially when you need the same level of support for old versions where upgrading is not an option.

In addition, the Linux/OSS world gives you the source code...

Yes, the Linux and BSD kernel and userland source is available for free. That is a huge bonus. However, most RTOS vendors will make their code avaialble for a fee (last time I looked into this, it was pretty big, though.

Linux and BSD are both fantastic systems, but IMHO, I do not think they belong in mission critical realtime applications. There are some companies like LynuxWorks that support embedded Linux, but given the choice I would almost always choose LynxOS over Embedded Linux, but most of the embedded systems I have work on require hard-realtime and I tend to choose very conservatively on embedded projects.

Actually SCO systems were used in some tanks. There were stories going around about patches etc being downloaded in the field in the early 90's.

That's probably this one. Way back in REM-time, with BBS's still going strong.

The control system for the cabin of the Boeing 777 also used to run on UnixWare.

Not anymore; but I never really understood what a browser has to do with an operating system.

What might that navigation system be?

• I can't make out the logo under the navigation display screen. A wave, followed by "ware"?
• ECDIS-N seems to be the Navy paperless navigation design. Electronic charts (maps) exist for navigation of federal vessels with ECDIS-N.
• Navy is using two navigation systems: USCG COMDAC INS and Litton Marine's (now Sperry Marine) IBS (VMS). The Swift seems to use a new IBS, thus it is using Litton's VMS.
• Sperry Marine makes Navy's ECDIS-N: In a separate effort to extend the open-architecture concept, PEO IWS in late 2003 awarded a contract to Northrop Grumman Sperry Marine in Charlottesville, Va., to act as the Navy's sole supplier of electronic charting, display, and information systems, called ECDIS-N, in a competition that rejected two Navy-developed systems. Confirmed.
• Search for ECDIS-N on Sperry Marine produces only the Military IBS page. Apparently ECDIS-N might be there. Sperry Marine products
• Apparently ECDIS-N systems must follow DII COE for the operating environment. POSIX is also involved.
• LynxOS might be involved in real time situations: LynxOS(R) was selected as the reference RTOS implementation for the DII COE configurable RT kernel.
• Thus there may be Unix influences in those designs for the navigation system.

The phrase Joint Interoperable Mission Planning and Rehearsal System is found by Google only in this document. There is a Joint En-route Mission Planning and Rehearsal System (JEMPRS), but no hints of its platform.

The COMBATSS site doesn't have much info. Another site mentions an HP Unix workstation with COMBATSS. And the COMBATSS Platform Equipment doesn't sound like a description of MS-Windows. Using Mozilla as an interface is mentioned in the original article, which doesn't reduce the possibilities much.

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

As you can see, FBCB2 was developed on Solaris, ported to VxWorks and then LynxOS. No MS OS or Exceed.

It's being adopted.

Cheers.
~ ~ ~ ~ ~

LynxOS. We're working on porting a VOIP switch from VxWorks to LynxOS right now.

Lynux Works has just announced that it will support the Open Source Development Lab's Carrier-Grade Linux® specification (CGL) v1.0 and that it plans to features of CGL v1.0 into BlueCat® Linux, in early 2003. The details here (Press release).

The context was that of software for an unmanned microsatellite, not the shuttle.

Crewed spacecraft have an even more strict set of rules attached to the software development process. Have a look at some of the articles on DO-178B, the software development standard for avionics. Similar issues apply, but even more so.

Look, people - not Geniuses - just normal, everyday programmers - have been making software you can bet your life on for a long time now. We know how to do it even more cheaply than the normal buggy commercial work (though testing is radically expensive and blows out the total cost). There's no need, and no excuse, for BSDs and security problems. None. You just have to have the right tools, the right training, and the right attitude. If you like, the Right Stuff. Here's a quote from that article:

It's strictly an 8-to-5 kind of place -- there are late nights, but they're the exception. The programmers are intense, but low-key. Many of them have put in years of work either for IBM ( which owned the shuttle group until 1994 ), or directly on the shuttle software. They're adults, with spouses and kids and lives beyond their remarkable software program.

That's the culture: the on-board shuttle group produces grown-up software, and the way they do it is by being grown-ups. It may not be sexy, it may not be a coding ego-trip -- but it is the future of software. When you're ready to take the next step -- when you have to write perfect software instead of software that's just good enough -- then it's time to grow up.

One area I disagree with in the "Right Stuff" article is that the work doesn't involve creativity. This is balderdash - we're doing stuff no-one has ever done before under really tight resource constraints. To get a reliable architecture often requires significant smarts, lateral thinking. Anyone can make a complex solution to a complex problem, the really good guys and gals make solutions so drop-dead simple, obviously-correct and efficient that it's miraculous how much such simple, obvious and readable code actually accomplishes.

Looking at the general world of InfoTech, we see that most programmers out there would rather write the winning entry for the "Obfuscated C" contest than make some software that gets us around the solar system. And that people who make reliable software hit the unemployment queue on project completion, while those making buggy stuff have jobs-for-life in maintenance. Of course, they often have 80-hour weeks too, and are driven by PHBs who know b* all, and can't even take pride in the product, so there is some justice.

while companies that waste tons of $$ like Lineo are suffering, other embedded linux/RTOS companies like my former employer are doing very well, making business deals etc. etc. It helps to have a real business model. (Notice that my former employer has now shifted its focus to its original product, LynxOS.)

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

The author seems intent of finding someone or some group that is successfully leveraging Linux in the embeded market. Why doesn't he check out LynuxWorks?
You may remember these guys from LynxOS. This RTOS (in true defintion of the term -- not in the LinuxRT version) runs on countless embeded platforms. Ever setup a JetDirect card on an HP printer? That's LynxOS.
Well, these guys are doing a lot with Linux now. I attended a talk about two years ago, right before their product BlueCat (strikingly similar to RedHat, eh?) came out. My information may be out of date, but some of the stuff the guys talked about was very cool. An embeded tool-chain. Boot loaders. And most interesting source (and later binary) compatability with LynxOS (by which I mean that LynxOS would run Linux source). To quote from the web page: BlueCat Linux applications can be migrated to the LynxOS platform with no loss of functionality and with minimal effort or delay. LynuxWorks development tools support both operating systems so there are no new tools to purchase and no new learning curves. This all means that customers can develop using BlueCat Linux and then quickly migrate and deploy applications to LynxOS when real-time needs emerge. Anyway, as I said, my info maybe out of date, but these guys shouldn't be overlooked. Oh, and for all who are wondering, I am in no way connected to this company.

The author seems intent of finding someone or some group that is successfully leveraging Linux in the embeded market. Why doesn't he check out LynuxWorks?
You may remember these guys from LynxOS. This RTOS (in true defintion of the term -- not in the LinuxRT version) runs on countless embeded platforms. Ever setup a JetDirect card on an HP printer? That's LynxOS.
Well, these guys are doing a lot with Linux now. I attended a talk about two years ago, right before their product BlueCat (strikingly similar to RedHat, eh?) came out. My information may be out of date, but some of the stuff the guys talked about was very cool. An embeded tool-chain. Boot loaders. And most interesting source (and later binary) compatability with LynxOS (by which I mean that LynxOS would run Linux source). To quote from the web page: BlueCat Linux applications can be migrated to the LynxOS platform with no loss of functionality and with minimal effort or delay. LynuxWorks development tools support both operating systems so there are no new tools to purchase and no new learning curves. This all means that customers can develop using BlueCat Linux and then quickly migrate and deploy applications to LynxOS when real-time needs emerge. Anyway, as I said, my info maybe out of date, but these guys shouldn't be overlooked. Oh, and for all who are wondering, I am in no way connected to this company.

three cheers for my former employer!

Linux is good but I think stuff like "devices that tell our antilock brakes when to unlock" will go to private firms or pre packaged stuff that's made specifically for it like LynxOS. It has been argued that linux is not made for the desktop, more servers. And while that can be debated I think this one is a little bit harder battle.

While I can't claim to have done that much homework on the subject either, I did find something along the lines of what you were talking about in Linux Journal a few months back. LynuxWorks (lynuxworks.com) is in the business of marketing a real-time Linux compatible OS. They also are involved in the embedded Linux market, from what I understand. Doesn't it seem like whenever you've got an idea, someone else has already beaten you to the punch? :)