Slashdot Mirror
Living in a Linux Embedded World
krow writes: "Embedded.com is running an article where the author is making some assumptions of Linux's use in the embedded markets based on the opinion of one consultant and the fact that Lineo had to lay off some people this year. It's still interesting reading though for some insight into a different world for Linux and there is a nice reference in the comments to the interview of Victor Yodaiken of RTLinux fame by by Kevin Fu on the ACM site."
Part of the issue may be that embedded systems have pretty long development cycles, compared to typical software apps of similar size and complexity. If your PC application doesn't work, you simply issue a new revision with fixes. Embedded systems are much more difficult to upgrade. I'm not talking about PDA's here, I'm talking about your set top boxes, industrial systems, data collection, etc. These systems cannot be easily patched. As a result, embedded linux development efforts take much more time to certify than those using RTOS's that have been around for years. Also, it is true that linux doesn't have a native method for doing hard-real-time events, there are add-ons, and it isn't the fault of linux developers, such a thing simply isn't needed for desktop and server OS's, but for running an industrial robot, a 10ms delay can be disastrous.
Where's my lobbyist? Right here.
Unfortunately, if the many features of Linux and the transition from assembler to C didn't hurt us, the licensing did. Things went very smoothly until we needed to make some big changes to the kernel to accomodate a newer version of our hardware. At that point, there was a schism in the group: some of the developers wanted to change the kernel and release the product without source (the "who would find out?" crowd) and the rest of us knew that Linux was not going to fit our needs anymore unless we wanted to give our work away to competitors.
Well, the "who would find out?" crowd won the first round, and because of release deadlines we "slipped" the kernel changes into the next version of the product. And nobody knew. Except one of us told the legal department about what happened and they became very agitated.
Now our software runs on embedded NetBSD. It wasn't quite as robust as embedded Linux but it works well and we really can't complain. Transitioning to a new OS took a lot of effort but it was a necessary evil. After all, we couldn't risk getting sued out of existence to save a little money.
But the question I draw from this is: why not relax the GPL restrictions a bit for embedded applications? It seems like this area of the market will never be dominated by Linux until companies can stop fretting about licensing problems and start concentrating on coding instead.
df
Sorry to anyone who believes Linux is THE choice for everything, its not. As a real time embedded developer who has done some work on Linux device drivers I have yet to suggest Linux as an option when the OS choice has come up. I agree with the author when he cringes at some of the commentary in the Linux source code, I'm supposed to stake my name and my company's name on an OS with comments like: "/* This is a hack..." in the kernel? And say we do go with Linux and a problem with the OS comes up what should we do? Post to the linux-kernel mailing list and hope it gets fixed? Assign one of our developers to fix it? We don't hire OS programmers for the very reason that we buy our OS, we're DSP engineers. Most companies won't go with Linux because of the fact if something breaks they can't submit a bug report and withhold payment until it gets fixed.
/. where a major fault has been introduced or missed in the Linux kernel I may rethink my opinion but until then I'll be suggesting that we buy our RTOS.
I'm an avid Linux user at home but for fault-intolerant real time systems, I would feel a bit uneasy recommending Linux for an embedded system just yet. Once I go 6 months without a story on
I've looking for a new job. My current job is Linux-related and I'd like something similar. So I search for "Linux".
Let me tell you, about 80% of the Linux jobs out there are asking for embedded experience as well. If Linux is hot anywhere, it's in the embedded market.
Now, it may just be that embedded is hot and, because I'm not searching for it, I never see the non-Linux ads. That doesn't change the fact that nearly the only Linux ads I see are for embedded stuff.
324006
I don't see a big problem with that, nay, I'd think it a good thing for there to be some diversity of licenses, OSes, and approaches.
Supposing there turned out to be some horrible situation where NetBSD turned out to have killer bugs for particular purposes, it's a good thing to have some alternatives. Or vice-versa, and the potential causes can remain "n'importe quoi."
I don't see any reason why it is forcibly necessary for Linux to be "dominating" the area, either. I would think dominance would lead to all sorts of Bad Results as it denied the availability of choice.
And as for licensing, if you're going to use Linux, that certainly has some implications on being mandated to release source code. If you reject that mandate (and there's some "ethic" behind it; the authors are unlikely to let go of this), then Linux obviously isn't going to be the right choice. Which makes it fortunate that the market wasn't dominated by Linux, as if it were, you wouldn't have had other choices like NetBSD.
If you're not part of the solution, you're part of the precipitate.
Embedded BSD is not as stable as Linux?
Perhaps it's because all the companies that made extensions to BSD did not make their changes public?
It's this issue, the very issue you raise, that makes Linux the long-term sensible choice. You benefit from the work of other companies, and they benefit from your efforts as well.
Notice that your changes to the BSD kernel are not available to other indivuals and companies. Thus, your efforts do not contribute to the stability of BSD for embedded applications.
The "Share and share alike" philosophy of Linux is the heart of the Linux movement, and your suggestion to "ease up" would represent the very death knell of its forward momentum.
It's really a question of "Pick your poison". Which flavor do you prefer? You can either A) leverage the efforts of others and let them leverage off of yours, or B) Go your own route.
Either route has its advantages and disadvantages - but don't complain when you can't have it both ways!
-Ben
I have no problem with your religion until you decide it's reason to deprive others of the truth.
...in the commercial OS as well- you just don't get to see those. And the who'll fix it argument, well, I've seen both sides- the closed source route DOES NOT insure things will get fixed.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
How many designs and implementations did you go through before settling on the current one?
VY: The current version is the result of three total re-writes and there is a new version in the works. The number of minor revisions is much larger than three.
Heh... In a sense, this is a nice retort to the interview with the former Microsoft PH manager, whose interview was recently published on Slashdot. Sure, rewriting from scratch is a mistake. Whatever.
Bush Lies Watch
Is anybody else here getting a little tired of the very stale "Linux is doomed" mantra? Linux gets tried out in a new environment, and surprise, it isn't immediately successful. So then a bunch of writers publish articles about Linux being doomed in whatever arena it was tried in.
:)
Linux is doomed in the enterprise...
Linux is doomed on the desktop...
Linux is doomed in the embedded device market...
How long have all of these other RTOS's been in use and development? How long has Linux been an option it this field? A company that is making good money developing under an RTOS they've been using for years and know every quirk of isn't going to switch to Linux overnight just because it's cool. In the long run Linux may provide some advantages that will give it a better market share, but to suggest it is doomed because it hasn't been an overnight success is ludicrous.
The funny thing is that Linux can't ever be doomed because it will never go away. If Microsoft is blown up tomorrow by a government backed anti-trust commando squad, Windows will cease to be. But Linux, being GPL'd will continue to go merrily along no matter how many people conduct bad business ventures around it. I'll believe embedded Linux and enterprise Linux and desktop Linux are doomed when Linux goes out of business. Oh wait, it can't
This sig has been temporarily disconnected or is no longer in service
Actually, I believe Solaris has kernel extensions which can be used to garuntee a process a minimum amount of runtime. But I could be wrong.
I agree with most of your comment, though. Although "real-time" has a very good definition (A real-time problem is any problem in which the time taken to arrive at the answer is part of its correctness) people abuse the definition horribly. Embedded has no agreed on meaning.
This reminds me a bit of the previous slashdot article on "XP-embedded". That's the product I think Linux has a chance to beat. High reliability, fat budget systems--embedded but not really real time.
Oh--and I am an embedded developer. I love Linux. But 60us interrupt latency on a 800 MHz CPU* just ins't acceptable for a hard real-time system. If it means a compression artifact in my Tivo, no problem. If it means 60 kb of data loss from my Gigabit ethernet card, that's not cool. If it means none of my avionics systems respond for that long, it's out of here!
*The guy says "Pentium" which is probably incorrect--I don't think they ever clocked those old chips that high. Not a very good author.
For the majority of embedded applications Linux is more then is needed. Sure something like Tivo profits from a 'full blown' OS, but most embedded situations don't need this. For most all that is really need is a fast task switcher and a couple of communication stacks.
This is exactly the issue I am considering aswell.
Lets say our company invents a device and plans to sell the device with Linux loaded terminal with Linux device driver. The hardware+software is our IP and we can't give it away. please don't lecture me of how everything should be free...etc. I know that, and I also like a roof above my head. Letting people download my driver for free from a FTP server doesn't quite pay my bills.
So the solution:
we need to have something like FSF or Linux Fund. If I want to keep my driver closed source say for 1 year then I pay a license fee for them (it can be a one time thing or royality based). The 'foundation' distributes the money as it see fit, funding developers, funding new projects..etc. After a year, I have 2 options
- release the source to kernel main tree and make it open. Now it doesn't matter as competitors can't abuse my work to overtake me.
- continue with closed source for another year and keep paying (may be revised) licese fee / royality.
This has best of both worlds
- I get to use a stable well maintained software (in this case Kernel). so I don't have to re-invent the wheel inhouse everytime.
- I keep my IP intact for a short period and at the same tiem paying for other developers efforts.
any one know any similar licences like this?
LinuxLover
Linux will fit into spaces as small as a floppy and do very useful embedded tasks while being that trimmed down. You might also want to note that many embedded applications aren't needing rate monotonic scheduling, etc. like QNX offers (which is what you're referring to)- a substantial amount of embedded systems need a stable OS that provides some network and maybe some file support. QNX does this well, but at a rather large per-unit price for most embedded systems. Linux also does it well and offers NO costs other than providing source code for extentions to the kernel, etc.- and in many cases you don't need to alter the kernel or provide drivers as people have already done that for you.
No, I'm not saying Linux is a panacea for embedded system designs, but QNX isn't the ultimate answer either. For things that QNX is a good candidate for, choose it, or the open sourced RTEMS (Which does a very good job of the realtime things). For everything else, why spend the cash on something that you'll never use even 10% of the functionality of?
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Reading Mr. Ganssle's view in the article on utilizing Linux as an embedded OS has really suprised me. I'm afraid that I'll have to disagree with his opinion on the issue simply because I actually have hands-on experience utilizing Linux within the embedded space. I've found that the Linux OS is a natural match to embedded platforms because the kernel and POSIX APIs of the OS can be customized in an intelligent manner to meet the size and processing requirements of a number of projects.
Most engineers that are shopping for an embedded OS want an "out of the box" solution for their embedded device. They want to simply be able to pay X number of dollars and get an OS so that they can quickly move on with their embedded software development. "Generic" embedded OSs, such as WinCE, are indeed a quick fix to that problem. Those same "generic" solutions also lock your project into continous OS licensing costs for the lifecycle of the project, a kernel that can't be touched for optimization (at least, not without paying a hefty fee to the OS manufacturer), and often require larger system resources to compensate for being generic.
Linux offers a unique alternative to these three problems. By leveraging against the open source development of the Linux kernel and the GNU POSIX APIs and OS structure, licensing costs for the OS can be considerably less per device (if you pay any licensing costs at all), simply because the licensing isn't priced to recover the hundreds of thousands of man hours put into developing Linux and the GNU toolchain. This can potentially turn a software cost of tens of dollars per unit into a few dollars per unit. When dealing with high volumes of product, this savings can be quite considerable.
The Linux kernel can most certainly be optimized. Whether your organization optimizes the kernel itself (and you will have the kernel source code, thanks to the GPL) or if you pay another organization to do it, you won't find yourself staring at a kernel that is a black box. And make no mistake... you will need to optimize the kernel in some manner for your embedded platform. Many companies choose to leverage their savings on OS licensing costs towards kernel customization costs (i.e. spend less money on the OS and spend more making it BETTER). Also, if you are using Linux as an OS, you aren't left "holding the bag" if your embedded OS manufacturer goes out of business. Switching OSs can be an extremely costly process because it precipitates a porting processes of the embedded software as well.
A generic Linux kernel straight out of a RedHat distribution will, as Mr. Ganssle has stated, require too many resources of an embedded device. That is why customization work is needed. The core of the kernel (memory management, process management, etc.) needs to be customized, and other portions of the kernel can be removed entirely in order to perform the needed optimizations. You certainly wouldn't want to put Windows 2000 on a simple embedded device... the required hardware resources would most likely be inflated in order to support the OS. In the same way, you wouldn't use a generic Linux kernel.
The Linux embedded space is poised to explode in the near future, and I'm glad to see it happening. The Linux kernel lends itself well to customization, and the GNU toolchain offers a low-to-no cost alternative to expensive development tools, such as Tornado (VxWorks) or Microsoft Visual Studio. All in all, it looks like a bright future for the penguin.