Embedded Linux?
My new company will need an operating system. While we’re not strictly in an “embedded” system environment, many of the same principles apply. Our environment will be restricted, in the sense that users will not normally login to the system, and there will be limited functionality available.
At first blush, given it’s popularity and extent, Linux seems a logical choice.
However, Linux is a moving target. And it’s moving at Mach 1!
Embedded Systems Design magazine has an op-ed (somewhat biased, but the facts they site seem plausible from my experience with Linux) detailing some of the issues. Key quotes:
“To keep abreast of the changes occurring on a daily basis a developer needs to monitor the email traffic of 11 different and unsynchronized open source projects… up to 5,000 messages a day with 1,000 of these being patches that need to be evaluated and possibly applied to the source base. Simply ignoring the traffic, figuring that the system in use seems to be working well enough, can lead to disastrous consequences later.
“A recent security patch that took all of 13 lines of code to implement against an embedded Linux system would have taken more than 800k lines of source patches to implement, if the previous trail of patches had been ignored. It’s a classic case of pay now or really pay later.
“If there ever were a situation where the ’software money pit’ could really take hold, it’s in owning 30 million lines of constantly changing source code. Even in the simplest case, the development costs are typically in the millions of dollars.”
More telling, though, are the economic impacts to both Monte Vista and Wind River:
Trying to fix embedded Linux for eight years, MontaVista is reported to have lost over $60,000,000, going through five rounds of venture capital, three rounds of layoffs, and three CEOs in the last two years. Since jumping on the Linux bandwagon, Wind River has gone from profitability to losses, recently announcing a layoff of 7% of their staff.
A recent customer of mine had to severely hack the linux kernel in order to obtain significant performance in their particular case. And this meant that they had to continuously back-port their hacks to newer versions of the kernel on an almost monthly basis.
An interesting perspective comes from Henry Newman. In an article for Enterprise Storage Forum, You Get What You Pay For, he notes:
There are a number of areas that limit performance in Linux, such as page size compared with other operating systems, the restrictions Linux places on direct I/O and page alignment, and the fact that Linux does not allow direct I/O automatically by request size — I have seen Linux kernels break large (greater than 512 KB) I/O requests into 128 KB requests. Since the Linux I/O performance and file system were designed for a desktop replacement for Windows, none of this comes as much of a surprise.
There are many other indicators that Linux is probably not the correct path for us.
So, we’re currently investigating OpenSolaris