Interest in Embedded Linux Remains Low

burnin1965 writes "According to EE Times interest in embedded linux remains low. I was surprised to see their headline considering I just purchased a Sony TV which runs linux and I assisted my brother in setting up an Actiontec DSL modem which runs linux. A few years back I had only heard of devices that ran embedded linux and now that they are starting show up everywhere interest is low? The survey did bring up three issues which should be addressed by the embedded linux community, whether those issues are misconceptions or actual problems. 1) Incompatibility with software, applications, and drivers. 2) Performance or real time capability. And 3) support."

Dlink

My D-Link DSL604t is Linux based too, and so is my PDA..

Is 17% low

I would have said that 17% of designers using embedded Linux is quite respectable. I wonder what their target penetration was.

It's about economics

If I'm going to make a million of something, I'm willing to spend a lot of money on engineering to save fifty cents per unit. I'm willing to spend the extra effort required to use Linux.

On the other hand, if I'm making ten units of something, engineering time is my largest expense. In that case, I don't particularly care about license fees or the cost of the tools, I just want to get the job done as fast as possible.

So, consumer goods will use Linux but most developers don't design those. Most developers work on projects that won't be produced in large numbers. Therefore most developers will continue not to use Linux.

Re:It's about economics

You've got it exactly backwards. If you're going to make a million of something, you want the bill of materials cost to be as low as possible, whereas you aren't as worried about the non-recurring engineering. That's why Linux, with it's larger memory footprint, but lower development cost, is often non-competitive.

Look at the latest Linksys WRT54 router. They've abandoned Linux and gone to VxWorks, despite the huge up-front cost for WindRiver tools, but they can use half the memory chips. This is a big win on a large production run.

On a limited production item, you often can't afford commercial tools, because it will make the selling price of your product non-competitive. Just the price of one copy of the VxWorks tools will probably add about $20 to the BOM cost on a production run of 1,000.

1/3 of the market is huge

Only 17 percent of embedded systems designers are currently using embedded Linux, and 66 percent say they are either not interested in using it or do not expect to be using it anytime soon

So, reading this backwards, a third of embedded systems developers are interested in embedded Linux and/or expect to be using it soon.

Compared with where the market was five years ago this is huge. Of the other two thirds, a large percentage goes to TRON [wikipedia.org] and probably VxWorks. And if you want vendor-provided qualified platforms and support, you can get that [windriver.com] from the same folks who make VxWorks.

Surely a change in survey results from a year ago is something to be curious about but there's no indication it's a trend.

GPL?

I developed an embedded device using NetBSD. I would love to use Linux, but the agressive stance of the GPL license (Linksys!!) keeps me away. I know many others that share the same view.

Linux won't take over the embedded world, mainly becuase embedded is a commercial market. Who wants to invest money in developing a product, only to have the open source community go after you? And you get bashed for trying to earn a living.

Before you flame me, I did make a good portion of the code used in my embedded device available to the BSD community. I won, they won. Nobody twisted my arm.

I'm posting AC, STOP KARMA WHORING!!!

TDT

Re:GPL?

With a BSD license, you'd know they ripped you off but had no way of forcing them to release the code.

Well hold on, surely it's impossbile to 'rip off' BSD-licensed code, by definition.

Re:GPL?

And you get bashed for trying to earn a living.

I think you mean "You get bashed for trying to earn a living off other people's work, without giving anything back."

The rules are simple : reciprocate or fuck off.

"Sony TV which runs linux"

Nothing is going to change the fact it is a Sony.

What the companies should be doing perhaps

Perhaps this is just a wake up call to companies who support embedded Linux to perhaps spend more on advertising and marketing (i.e. "hello world, we support Linux embedded because we made a pile of decent kernel patches so we can be trusted.")

Compatibility testing, and wedging in those RTOS kernel patches and supporting those where appropriate can't be a bad thing either.

Is interest low or do these devices simply work?

My feeling is the latter. My Netgear ADSL modem / firewall uses embedded Linux. If not for a "debug mode" hidden in the advanced settings which enables you to SSH into a busybox shell, I wouldn't know nor care. The thing just works and it works very well. I expect millions of people are running Linux in their homes in their modems, TVs, audio / DVD players, washing machines or elsewhere and simply don't know it.

a lot of people probably do run linux...

...without knowing it. as i've pointed out before you can download sources for Sony devices from here: http://www.sony.net/Products/Linux/Download/search .html [sony.net]

anyone got anything on the list? [hint: try under the 'game' section]

They are actual problems

Issue 1 is not a big problem. The programming model is well-understood, so at the application level there really isn't a lack. However, there is little support for specific stuff that hardware vendors may want to do (like say a CDMA RIL) and the implementation of those features is pretty difficult.

The second issue is a real concern. User experience is significantly degraded when the interrupt latency is longer than the expected reaction time. There are ways to reduce the interrupt latency in Linux, but the side effects are undefined.

Support is only an issue because it is so expensive. Likewise, there are only a few top-tier Linux vendors who can offer good support. Montavista, for example, is one of the premier (if not the premier) embedded Linux vendors, but they can't support everyone who wants to build a Linux-based embedded solution. They pick and choose their support contracts, and anyone not selected needs to find someone else with the relevant support capabilities.

cell phone?

Are cell phone counted? Say this to motorola :)

Linux is everywhere...

My WLAN AP / router runs Linux. My nokia 770 internet tablet runs Linux. Many many media player type devices run Linux.

(embedded) linux in standalone devices

Which question were people answering? Are you intending to use an "embedded linux" or just "linux" in a small standalone device? We use a "standard" linux in several standalone devices. We have no need for, nor do we want to use a "specialist" distribution because we do want to be locked in. It is no coincidence that one of the more fertile areas of cpu support development in the kernel, at the moment, is for ARM devices.

dont forget #4

Most embedded applications dont even need an OS.. thats overkill for them and would only serve to raise the end cost. You dont need linux in your Microwave for example.

Saturated markets

Is embedded systems a worth dominion for open source projects?

Unlike the desktop space, the embedded systems space has a multitude of vendors, and a huge variety of configurations to choose from.

There is hardly any motivation to build upon embedded linux.

liability, litigability, and "excessive" openness

One issue that prevents linux being used in automotive systems is the ability of a vendor to accept liability (and be in a position to defend it meaningfully).

Auto companies get sued all the time (rightly and wrongly), as to their major suppliers (Delco, Denso, Bosch etc.). If a supplier's part is defective, a class action against the supplier may result. If the supplier is big like Delco they'll be in a position to defend against that action, and have enough money and insurance to survive if they lose the action.

But linux comes largely from little guys like Montevista. Even if they do accept liability, they're still too small to survive a huge automotive-defect class action. So GM or Toyota or BMW would be left holding the bill. The major automotive electronics suppliers will accept liability, and are big enough to be credible partners in a litigative society. Microsoft sells (very limited) automotive electronics products, and are again credible (from a business perspective).

IBM could sell automotive linux, as could HP, but they don't (or rather they want to supply technology to automotive electronics partners).

Now why don't guys like Denso install linux - at least partially because they all want to be little microsofts, to "own the car", and open systems and generic technogies prevent that - they think they benefit from wacky proprietary OSes and weird undocumented software stacks.

No Compaiibilty?

Well whoose fault is that? Not the Linux people, maybe if they wrote their own linux driver it would work? Its the product developer's job to make sure somthing is compatible.

Not surprising

I work for a large CE company that is using Linux for a major TV-related project.

This, sadly, is very much an pointy-headed-boss driven decision. From the perspective of the HW/SW teams its just plain stupid. The problems are probably pretty representative why those 66% aren't looking into Linux.

Its gross overkill. Linux architecture is for general-purpose multi-user information processing loads. It does a whole bunch of things that are simply ballast for an O.S. that is there simply to control some special-purpose hardware and run a simple on-screen-display. Bigger micro, larger flash footprint, more on-chip RAM gobbled. This really really hurts in a genuinely cost-competitive marketplace. If you're building an Net appliance type of thing of course Linux is almost a turn-key solution. For embedded control... its the wrong kind of OS.

Licensing is a pain if you have non-trivial know-how you don't what to gift your competitors realised in your Firmware. You end up doing really vile hacks like doing stuff in user space via 'dummy drivers'. Debugging becomes fun fun fun....

The abstract machine doesn't fit. In the embedded control space sometimes the cleanest solution really is to do direct HW access. However, the hard kernel/userland divide of Unix O.S. makes doing this in a systematic, safe, way rather clumsy. You end up writing around a bazillion special-purpose HW-dependent ioctl's where what you really wanted was some selective access to the I/O bus. Then you need a HW workaround with hard real-time requirements and the 'fun' really starts.

In short Linux is a fine information processing /network O.S. for embedded or general-purpose systems. Its very far from ideal for one-off embedded/control applications.

Midas XL8

Don't know if any /.ers are familiar with the mixing console industry, but Midas are doing some pretty neat things [prosoundweb.com] with Embedded Linux on their new digital console (XL8).

Missing figures

Well, TFA tells us haow many are using Linux, 17%, and are thinking about it, etc. But how can we make any conclusions form this when it isn't even hinted at what the other 83% are using? Some version of Windows? QNX? DOS? Is Linux at 17% the largest or much smaller than the others? Maybe the EETimes readers have the context, but I don't.

Mindset

It's not just a case of features, but of mindset. A lot of embedded programmers prefer writing their entire software stack with direct access to the metal. To do otherwise takes a big adjustment in mindset, and a lot of companies simply don't have the time for it and therefore Linux.

Designers vs Units

The article talks about the number of designers who are working on Embedded Linux projects. It says nothing at all about Embedded Linux's market penetration.

If, for example, you have 1000 projects using an embedded OS of some kind. Let's say 900 of these are going to be either small-run, specialised devices, or flops. The remaining 100 are consumer items, mass-produced and sold around the world. If Linux's 17% happens to account for a large proportion of the top 100 projects, their market penetration is huge. If it's 17% accounts only for small-run projects, then it's not doing that great.

A better heuristic, IMO, would be how many units are being produced with embedded Linux, rather than how many designers are using Linux.

None of these problems actually exist

>Incompatibility with software, applications, and drivers
What software he is talking about ? Almost all software that is available for desktop Linux can run on embedded Linux, which is a few orders of magnitude more software than is available for other embedded operating systems. Regarding drivers - almost all HW vendors that work with embedded products supply linux drivers.

>Performance or real time capability
95% of embedded applications do not need hard real time capability. And average performance is once again typically higher than that of other embedded operating systems.

> Support
I'm really tired of hearing that one. Everybody and their mother is providing Linux support now. Take Windriver, for instance.

Creating perception, not reporting reality

Other possibility is that this publication is doing what mainstream media has been doing for years:

Trying to create a trend or perception where there is none. Witness all those smarmy "the suit is back" articles.

In addition to accepting paid and free propaganda, trying to create public hysteria to influence political outcomes, the MSM survives on renting reader's eyeballs to advertisers. Whatever it takes to do that, they will do. Slashdot itself has fallen into that same cycle, with regular articles about "political" subjects sure to get 800 replies (and corresponding ad impressions) but with no valid technical content.

New SuperSig:

....


Make the requirements to vote the same as to own a gun.

Simply go to the polling place, fill out a Form 4473 [atf.gov], show your ID [aclu.org], and the poll worker will check with the FBI database [fbi.gov] to make sure that you're not prohibited from voting. If everything is working correctly, you will be allowed to vote in a few minutes.

If the GCA/Brady system doesn't violate the rights of gun owners, then what possible objection could there be to implementing the same system for voting?

Robert Racansky

big surprise.

Hardware designers generally start with an eval-board of some sort so they can hack up their add-on hardware and get something running on the bench before drawing schematics on napkins and starting to do a layout. As such, they need a 'board support package'. You generally buy that from an embedded systems vendor. You generally don't just download the latest linux kernel and start porting drivers and vm maps. Your management will likely want you to get a BSP from a commercial vendor to whom they pay maintenance so your engineers can hassle them about bugs in the bootloader, etc... Your choices are limited. Generally something like Montavista, Windriver, QNX. In my experience, Montavista makes it hard to do business with them. You practically have to bribe them to talk to you in the first place; even when you're waving around PO's. You've already bought the hardware from Intel or RadiSys and now you need support for the BSP. When you finally get a price, it's $18k per seat for a GCC license, and support is $5k/year; maximum of 5 incidents.

QNX on the other hand, will practically send an engineer on site to hold your hand while you get your BSP running. Support is cheap and the runtime licenses are down in the noise threshold.

Sure, QNX has a few issues. So does VxWorks. But Linux is a real lose, and I've tried.

Frankly, if I was starting from scratch and rolling my own BSP, I'd choose NetBSD. Embedded friendly license, code purity, and it probably already has your processor arch.

Other EL News....

But they are mostly behind schedule [embedded.com]

"A new survey released at the Embedded Systems conference reveals that more than half of all current embedded design projects are running behind schedule."

"The survey -- dubbed the "2006 State of Embedded Market Survey" -- indicated that some 55 percent of current embedded design projects are late or have been cancelled."

How accurate can any survey be when over half the projects are late and/or are being canceled? Bad mojo in the field of EL and not a good time to take a survey on Embedded Linux me thinks. As was stated in the blurb, EL is everywhere....

The numbers aren't that far off from 2005, but what about the years before that? Project running behind schedule are a bit less from 2005, but cancelations are also a bit up. Dunno, maybe I'm just looking for something to weaken the argument that EL is losing ground. I've always seen it as the grass-roots to keep pushing what I see as the future of operating systems, Linux....

34 % of respondents were not interested, 66% are?

found that 34 percent of respondents were not interested in using Linux.

66% are using or are somewhat interested?
So that's a good thing.

Programmers vs. devices

The article talks only about the number of programmers using embedded Linux. It fails to mention the percentage of shipped devices that use embedded Linux. It could be that the embedded world is more specialized, requiring more specialized function from an OS. The devices that can use a more general purpose OS (DVRs, webcams, ADSL routers, etc.) don't need many programmers, but ship a lot of units.

Don't forget the PS3

From what I've heard, the PS3 will use the Linux kernel.

Embedded Linux, Industrial controls

OK, I am a firm beleiver in embedded Linux, extreme SFF computers and/or "OS-on-a-chip". After review of the Article and posting it appears most ppl think of embedded devices as strictly "consumer" type products. Rightful so as the article did not address "who" (read end-user) target the embed was targeted for. Yet there are hundreds products on the market for Industrial control applications and thousands of consumer products. If the the designers surveyed where from the industrial controls sector then yes Linux embedded devices and their use is low. If from a consumer product stand point then the article is flawed. Multi embedded Linux systems in an automated industrial enviroment would be much better, far more reliable, much more expandable and more easier to manage then the "old" tech in use today, namely the PLC. Look at it. A famous named PLC offers 16k-32k of program storage, communicates via a modified 485 or Ethernet with a $1200.00 piece of hardware. Takes a $1000.00+ software bundle to program it (just One class). OH I forgot... Starting price NEW for an expandable controller is as much as its ID number. I have seen PLC rack add $15000.00 to a project (single piece of equipment) and that is not a very big rack at all. Don't forget the software - PLC, Scanner, HMI, Ethernet Interface and wares for a computer to talk to it.(another $5g) For that kind of cash you could put in embeds to control the whole process and be redunant. Bottom line . . . That is really what it is about. IMO PLCs are relics from the past that need to be trashed and embedded PCs is the now and future

An OS is only for multi-sw-part systems

If you have a single application device, it really does not need a comprehensive, separate "OS". If and when you need process management and memory management and sharing of I/O resources between modules/processes, you need SOME libraries/headers to do that. If you want to have layers of abstraction (say, high level I/O or media codecs) to help in development, you need also some libraries for that.

But up to a point you are free to use per application designed common libraries and run-time systems, you don't need to have a general purpose interface/protocol between "applications" and the "operating system". This is what many light-weight embedded toolkits are: just run-time systems and shared libraries with shared data structures. They are far simpler and smaller than any version of Linux, and more tailored to typical needs here.

But if you want to have a user extendable system and an ecosystem of independent code modules and libraries all running smoothly on a variety of hw versions, with standard programming interfaces, then Linux probably is a reasonable choice. (Though I would go with Plan 9 or Inferno.) This kind of system needs more expensive hw and is more complex, but it is also kind of easier to build, because it is more "common" and more "standard". With the cost of hw falling, this type of system is going to be more and more the most cost effective way to engineer the life cycle of several product generations, when design time and itellectual property costs are bigger than costs of general purpose processors, DSPs and memory.

The other opinion

Interestingly, there are other voices that seem to report the contrary. http://www.linuxdevices.com/ [linuxdevices.com] for example features the "Great Gadget Smackdown" where the numbers of embedded deployments of Linux vs. Windows in end user devices are compared.

This is interesting stuff, as Linux, although behind Windows embedded in certain device types like smartphonse, is constantly gaining market share, and clearly leads in devices like firewall, router and wifi appliances.

-FreakGeek

"The rumors of my death are exaggerated."

There are a few problems running Linux in an embedded environment, but as far as I have seen the problems are more of the questions regarding power economy and ability to go into suspension and deep sleep for a defined period of time and then wake up and continue from where I was when I got to sleep.

There are already a surprising large amount of drivers around that actually works well on embedded devices as well, as long as you behave nicely and issues ordinary shutdowns. And if there isn't a device driver around - it's not that hard to write one!

Another problem is that the size of the kernel and support applications sometimes are a little large for an embedded solution.

Linux much easier

I work for a company that uses embedded linux. We also have a division that uses embedded windows. I can tell you for sure that the linux product is much easier to configure, is much more intuitive, and work a whole lot better for what the product is designed to do.

Disbelief

I can only speak for the industry I work in but we are rapidly porting all our applications to embedded Linux platforms. Our systems run an RTOS but with the abundance of Linux savy programmers in the world it makes very good sense to use a widely deployed system.

Bogus Survey?

I can't find the actual survey online. I found some other articles by people with the same frustration. I want to see how the questions were framed.

I have done embedded design for more than 20 years. I have been subjected to many goofy surveys than were written by marketing suits who were clueless about how to ask proper questions. The typical survey says "Will you be doing an embedded design in the next 6 months? Y/N" and then it gives some kernels to choose from. The category of "hand rolled" is always the winner (~50%). This is because most embedded designs are quite small (8 and 16 bit) and buying a canned kernel is too much bother. Linux is not an option on these little processors (gross overkill and no MMU protection anyway).

The survey should ask "Will you be doing a 32 bit embedded design and if so, what will you use as a kernel?" If the design does not require TCP/IP networking, I still would seriously consider hand rolled as an option. When you make the kernel yourself you are not dependant on the support of the kernel provider.

I've never done an embedded Linux design, but I sure would like to. My only concern would be the complexity of dealing with the GPL (I ain't no lawyer). I'm accustom to hiding the source to prevent knock-off designs. In government research designs I willingly release the full design, but in commercial design it sets off alarm bells in my mind. I'm not sure what the reaction of a customer/employer would be if I told them I was going to release their code to the internet. I'll have to figure that part out.

Linux is being used in highend embedded devices

My Experience (and my current job) says that the post is wrong.

We're developing an embedded medical device with millisecond lantency needs.
We get to use a 192MHz arm chip which is more then enough to use a linux kernel and drive our application. It's not hard real-time like a rocket control but it's more then enough for us.

Kernel and framework support for the popular embedded boards and chips (arm) is growing extremely fast, so much so that its better (for us) to use the latest distributed kernel then attempt to get Montavista to support us. Performance is more then enough so why shouldn't people use linux in the embedded devices. It's makes a hell of a lot more sense then trying to hack around a properitary kernel and toolchain.

The big win for linux is the similarity between using desktop linux and the embedded device. Also all of the services (ftp, NFS, ethernet, ping) which are available on desktop linux are also available on embedded with just one recompile. Setting up the toolchain was the hardest thing to do (and gdb still doesn't work 100%) but after that, everything WORKs exactly as before....

And don't even get me started on Qte

Cheers,
Ben

PS. For the hardware complainers who don't know what ioperm is for, try looking it up.
You get direct access to registers.

Needs Refinement

I'd like to see this data broken up by market segment. Obviously Linux makes no sense whatsoever in a wrist watch, thermostat, or automotive ignition (ECM) system.

But it makes lots of sense in network appliances (NATs, firewalls, routers, print servers, etc) and certain consumer electronics. The latter includes things with disk storage for DVR functionality and network connectivity for services or content/conditional access. In many cases the choice of Linux in this segment is determined by the chip vendor; they may only offer reference software and tools on Linux. This is true for at least a couple of dominant vendors today.

EET should look at Linux penetration in market segments where it makes sense. Not just numbers, but also why. E.g., "everyone already knew it here", "cheapest", "chip vendor mandated", "allows us to use a gcc tooolchain", etc. I'd also like to see the numbers as a percentage of all shipped units as well as a percentage of market share (in US$).

Shes fat

Embedded Linux, even as ucLinux with uclibc etc is still fat for an embedded OS. Others like ecos, freertos etc are a much better fit. And so are the nice commercial offerings like qnx palmos and vxworks. You just have to add expensive ram and flash to make it boot linux in any form, and it cant be a 16-bitter. The only reason you see Linux being used is for hardware support and its nice networking, which is almost matched now by ecos' offerings.

I think for most small devices Linux is just too big. However it works better on routers and PVRs where space is not an issue. I will not buy a Linux watch or cellphone anytime soon, unless the battery can support it.

IRC Channel Metric?

I frequently connect to Freenode for IRC'ing and automatically join several programming channels (#zaurus, #squeak, #ruby, #python, #scheme, etc.) and I check out the #openembedded channel as well. Not sure if channel users is a fair metric of an offering's popularity, but typically the #openembedded channel only has three users listed.

I personally have dabbled in developing on Embedded Linux PDA's and enjoyed it. But it seems as the hardware vendors out there (at least based on what's available in the U.S.) aren't leaning toward Embedded Linux as the platform of choice. A shame because it has so many available packages to make the hardware shine. Embedded Linux PDA's can function as anything you can imagine --- Samba client/server, FTP client/server, VNC client/server, SSH client/server, DB client/server, HTTP client/server, telnet client/server, etc. The Windows Mobile PDA's I have played with don't have nearly that toolset available that I could tell. At least for free :-)

this shouldn't be a surprise

Most people dont give a rats ass which OS runs on their embedded hardware. Only linux fan-bots care if the latest gadget has their favorite OS on it. Most of the rest of us, just want the damn thing to work without hassles.

Quantum Tape Libraries

Embedded Linux is show up everywhere that I've encountered. Linksys routers, cell phones, PDAs. I was even surprised to find it in Quantum DLT Tape Libraries, controlling the robotic arm, etc.

File and TCP/IP stack

17% of embedded market is absolutely amazing imho. Unlike PCs, there are many choices for an embedded operating system. Most commercial embedded OS vendors could not even dream about reaching such high audience. I've read somewhere (and I agree) that if you need a filesystem and/or a TCP/IP stack you should consider Linux for an embedded system.Maybe I would expand this to include a USB host. If you don't need TCP/IP stack/Filesystem/USBhost then my personal favorite is Labrosse's microC/OS-II (amazing collection of CPUs that will run this, starting with 4K-ROM 8-bit processors to PowerPC type processors, not many OSes can claim such diversity).

Really? What about this one...

According to EE Times interest in embedded linux remains low. [...]

In other news, Trolltech has just released the Qtopia platform for mobile embedded Linux [trolltech.com] I don't think the guys at TrollTech haven't done a market study before investing in the development of this new platform.

What are they designing?

66 percent say they are either not interested in using it or do not expect to be using it anytime soon...

If I were making a microwave oven, I probably wouldn't be interested in using linux either.

How many said they weren't considering it because they didn't think they needed any os?

-- Should you believe authority without question?

GPL Rules and the Linux KERNEL Exception!

I think many are confused by GPL and propriety software, first you just need to make sure you only link against LGPL libs. GNU C and C++ libs are LGPL so your covered there. Ah but what about the kernel!! it is GPL, if you open the COPYING file in the root of the kernel source you will see Linus has added the following clause to allow accessing the kernel with system calls even if its from propriety software, see below qoute: "NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. Linus Torvalds"

The points are somewhat valid (except 2)

The survey did bring up three issues which should be addressed by the embedded linux community, whether those issues are misconceptions or actual problems. 1) Incompatibility with software, applications, and drivers. 2) Performance or real time capability. And 3) support."

The points are somewhat valid. I've used a few embedded style solutions such as GeeXboX [geexbox.org].

Firstly, they rely on being minimalistic first and foremost. This means removal of unnecessary things which could use up more space and resources such as X.org for many of them. They remove a lot of things not absolutely required for the product. To that end, the first point, incompatibility applies. A lot of other software will fail to function correctly or even perhaps to run at all. Usually the saved resources are worth it, but, it does make it a LOT harder to integrate major changes such as using a new program for some part or other. This encourages the reuse of already in place stuff. For example, for the sake of maintaining the current setup, interface, software, etc, GeeXboX is using mplayer for TV rather than some of the other more popular utilities such as MythTV and one that I thought looked pretty promising to replace a lot of GeeXboX's functionality, FreeVO.

Well, my first point kind of brushes on the second point made above on performance. In fact, #2 is way off base with a real embedded linux solution. Due to the minimalistic nature of the systems, they actually perform BETTER at what they were made to do. It's only things they were not where they will do worse. For example, GeeXboX's official requirements are listed as:
* x86 Pentium-Class CPU or above (P2-400 should be quite enough) or Macintosh G3 (G4 highly recommended)
* a VESA 2.0 compliant graphics card (for x86 PC only).
* an ALSA compatible sound card.
* at least 64 MB of RAM
* CD-ROM or DVD-ROM drive
* Motherboard which supports booting on CD-ROM (should be ok for everyone ;-)
* Keyboard, Joystick or Remote Controller, using a Lirc-compatible IR (InfraRed) receiver (check http://www.lirc.org/ [lirc.org] to build yours), e.g. Miro PcTV's one or ATI Remote Wonder.

In fact, those little $100 laptops should be able to boot GeeXboX and play current gen DVDs...