Slashdot Mirror
Requirements for Embedded Linux
An anonymous reader sent in: "As Embedded Linux becomes established as a solid alternative to many proprietary OSes and RTOSes, demands on embedded Linux developers and providers are increasing. This detailed technical article by Nicholas McGuire sketches the top requirements for Embedded Linux systems including considerations of user interface, network capabilities, security issues, resource optimization, performance requirements and issues, and compatibility and standards issues."
One thing that I think may detract folks from using Linux as an embedded OS is its hackability. For example, TiVo is now hacked 10 ways from sunday. As long as it's adding hard drives and so on, the TiVo folks have been pretty cool about it, but when the encryption scheme for storing recordings was hacked, that leaves them open to legal problems.
While proprietary EOS's are more difficult (for many of the reasons outlined in the article), they can be much more secure (in the weak sense of security through obscurity) than Linux.
But the question I draw from this is: why not relax the GPL restrictions a bit for embedded applications?
To which, I'm afraid, the only reply is: "Why not go write your own closed kernel - or actually pay money for one someone else has already written ?"
The whole point of the GPL is that, in return for the millions of lines of code you receive, you are expected to return the few hundred/thousand you produce. If you don't want to share, no-one is making you.
What would Lemmy do?
When it comes to embedded systems, most companies dont easily fall into hardware or software, they produce solutions that unify hw and sw. Since most hardware can easily and legally be reverse-engineered and produced in some third world country, the only thing makers of embedded systems have standing between being successful and dying from inability to compete in a commodity market is their software.
It's really very similar to Apple's market position.
"Prefiero morir de pie que vivir siempre arrodillado!"
I guess the distinctions between embedded and non-embedded systems are disappearing.
Traditionally, embedded systems have a minimal user interface (number pad and 7-segment displays come to mind), minimal ROM and RAM, no mass storage, and hard real-time requirements. For a system like this, Linux (or any desktop, mini, or mainframe OS) seems both inadequate and bloated.
Today's definition of an embedded system seems to be "a portable general purpose computer system". Perhaps we should just call it that rather than use the term embedded system.
This is common issue in the embedded world and sometimes is the main reason linux isn't used. I have been in a situation where linux was considered and one of the reasons it lost out was that we felt the amount of real intellectual property we could put into it was limited. We make our systems from parts that other vendors could also buy and so our software really makes a big difference. In these cases, we felt that we had to use either a BSD based system or a proprietary one that allowed us rights to change the full source. We are currently with the proprietary model but the licensing charges are keeping us looking BSD again.
-- soldack
I've just completed a 3 month development contract for an automotive company using embedded linux, and NO WAY is it that simple. Embedded Linux has a long way to go before it can compete with other systems, most notably in the areas of configuration management (the kernel configuration process for embedded targets is particularly poor) and device drivers (Linux in the embedded world badly needs a Hardware Abstraction Layer). On some popular embedded platforms (think Motorola, and telecoms), it took a major kernel revision (2.2 to 2.4) to fix problems with the UART driver.
The fact that the two most successful embedded architectures have forked their own kernels suggests that Embedded Linux is still quite badly fragmented, and no-one designing a system from scratch wants to see that.
Jon.
You've hit the nail on the head for some embedded applications. We must draw a distinction between embedded systems which are tooled for a single purpose (routers, switches, storage appliances, caching appliances, accelerators, firewalls, etc), and systems which rely more on an application and service layer (PDA's, game consoles, cell phones, etc). Clearly both are technically suited for Linux, but it is unlikely that the first catagory will ever be dominated by linux given the licensing. This is especially true for the high end. Few will build a $100,000 box with GPL'd kernel modifications. The risks in building hardware are too high as it is, (because its so damn expensive todo!).
Someone you trust is one of us.