The myth of the embedded Linux tools market

Yes, unabashed rip off of slashdot.  Reason: better discussion from actual developers here, not kiddie porn p2p network hosts.

Anyhow, http://www.eetimes.com/story/OEG20040112S0043, that's the link.

What I found true:
1. "... there is no sustainable embedded Linux tools market. In the end, embedded software developers who value commercial tools enough to pay for them will eschew Linux."

Two points made:
a. no embedded tools market,
b. those who want commercial tools, will not like Linux.

The corollary should be noted:  the reason there is no market is that those who know and love Linux (and BSD) find the free tools very capable.

2. "Most manufacturers attempting to use Linux in embedded applications start with freely available source code from a general-purpose Linux distribution and then port, extend, and optimize it for use in their devices."

Yup.

3. "In order to work out-of-the-box, tools must target a commercial distribution. A tools supplier could never predict the changes a customer would introduce while creating its own Linux derivative."

Double-Yup.

4. "Those manufacturers who care about size assume that Linux can be configured to fit in a small memory footprint. Reality is quite different. A minimal Linux configuration, which is usually closer to two megabytes than to one, actually omits most of the networking features and standard interfaces that comprised its appeal. With these capabilities included, embedded Linuxî often requires more than five megabytes."

A true and acurate statement regarding Linux footprint size.  Back in the day, sonny, we did the original DSS receiver in 128K, using a home-grown OS (in reality a POS, with POS tools too). It would be interesting to know who really cares that an embedded project fits inside 2 MB any longer.  Any takers?

5. "Because nearly every embedded Linux project is using a unique hardware-software environment, the expected support adantage from the broad Linux community does not exist."

6. "Cost is another factor. An annual “subscription” to a commercial Linux distribution typically costs more than a permanent license for a traditional embedded operating system."

Again, similar to item 1, if you're happy with the gnu tools, there is no reason to pay for anything else.


What I found false:
1. "The reality is that most--if not all--embedded Linux implementations cannot guarantee any real-time performance."

Nope, I truly doubt it.  PDAs, cell phones, entertainment boxes (DVD players, set top boxes, etc.), home/SOHO network interfaces are examples of devices which have no real-time requirements and represent a huge market segment.  Interrupt and scheduling latencies and determism are not factors here.  Where they are factors, real-time patches are available which significantly improve kernel performance for near real-time applications.

There are precious few true real-time applications out there.  One true real-time application is the ATM switch, and at least one switch vendor is delivering an embedded Linux product today (Occam networks).

There is a wealth of information readily available:
http://www.linuxdevices.com/articles/AT8073314981.html
http://www.linuxdevices.com/articles/AT8906594941.html
http://www.ittc.ku.edu/kurt/
just to name a few.

2. "The last resort available to developers is to support it themselves. This requires that they learn the inner workings of Linux in addition to the investment they have to make in their own integration and optimization. As a result, we have seen early adopters of Linux vastly increase their support costs over what had been required for their homegrown system. The potential impact is even more dramatic for a manufacturer that had previously relied on a commercial solution and does not have an internal operating system group."

This is truly his worst argument.  In the mid-90's embedded markets homegrown and modified "free" (non-Linux/BSD) OS's were in far more use than pay for license OS.  Learning the inner workings of Linux is no different than learning the inner workings of a homebrew OS - the main difference (speaking from 1st hand experience) is that Linux is clean, the tools are good, and the homebrew SUCKED.

What is truly false about the author's implication is that somehow the embedded application engineer is an OS ninkumpoop that is loathe to dealing with the OS scheduler, file system and tools.  No.  The embedded engineer is used to fixing problems that the OS has created or omitted, writing the device driver that has no shrink wrap support, and measuring missed interrupts and debugging the hardware that wasn't documented properly.  What's new?  It keeps him employed, its what he does.

My conclusion:  There are some companies out there successfully leveraging Linux growth in the embedded market.  My guess is that Green Hills is not one of them.  I've worked with 2 of the successful products: LynxOS and MontaVista.  I really like the LynxOS kernel myself - but anyway...

I think that the overall tenor of the article was a combination of:
1. Some objective truth:
1.a. Size and performance do matter (the subject of so much email these days).
1.b. The tools market for embedded Linux may never be profitable - at least from a purely tools perspective.
2. Much sour grapes and frustration.
3. A small attempt at poisoning the embedded Linux waters.  If you can't join em, hate 'em.

hoser
Thursday, January 15, 2004

I really think it depends on your definition of embedded.  My brother designs gear for the telecom industry.  It turns out that their systems are about the baddest x86 systems that money can build, with huge in memory databases. They use RedHat AS. 

christopher baus (www.baus.net)
Thursday, January 15, 2004

QNX.

Don't waste time on embedded Linux.

HeWhoMustBeConfused
Thursday, January 15, 2004

Who are you trying to convince?  Us, or you?

Mike
Thursday, January 15, 2004

"2. "Most manufacturers attempting to use Linux in embedded applications start with freely available source code from a general-purpose Linux distribution and then port, extend, and optimize it for use in their devices."

Yup."

Double Yup.  Red Hat 8.0 base, embedded x86 target.  Compile my own Linux kernel, add a few drivers, write some code, onto the flash, and into the box it goes.

The only way I could see paying for embedded Linux is if I had a short time to market and had to deal with a completely unfamiliar (read: non-x86) platform.

Alex
Thursday, January 15, 2004

Just a note, the writer is President of a company that develops a non-Linux embedded OS.

Doesn't change his argument perhaps, but could explain his motivations....

Nigel
Friday, January 16, 2004

There's definitely a sweet spot for Embedded Linux Tools.

I've just come off a project where I had to strip down a Red Hat distro to fit it into an embedded PC-104 system.  Would I have paid a reasonable price to have that work done for me?  Probably.  Even though there's lots of helpful hints on the net, it wasn't exactly one stop shopping to get what I wanted.  That said, I may get around to packaging the whole thing into a baby distro for the next guy.

That said, I've done some large projects with an embedded OS vendor who will remain nameless (although it was Wind River Systems...)  and we couldn't get what I would consider reasonable support from them.  Did it make it impossible to use their product?  No, but it does make me wonder about how much support you actually get from commercial vendors.

And, as ususal, YMMV.

erics
Saturday, January 17, 2004

  Recent Topics

  Fog Creek Home