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."
It's a pretty strange coincidence. Today I had to get information about a company for Professional Communications class. I went to the library, picked up an IT trade magazine, and went to the section about emerging companies in the new year. There is apparently a company called Kada Systems. That has created an extremely small JVM that can run very powerful applications on very small portable devices. Take that and your tiny linux kernel, and you're set.
The GeekNights podcast is going strong. Listen!
Most embedded componants that I know of use an in house OS. Where I work we bought vxWorks, but we are seriously considering replacing it with something cheaper. Not linux, something we write in house. It turns out that most real time systems cannot afford the overhead of a OS. Sure we need something to deal with hardware, and schedualing, and if you have networking it is nice to have sockets are similear. In the end though, a OS gets in the way more then helps.
In our particular case we have a lot of code to jump out of interupt context and then back in every 15 seconds. That really hurts performance. (Yes, we often want to spend more then 15 seconds processing interupts, with out hardware it turns out to be a good idea, though I don't want to give away why) Of course the OS clocks get all screwed up when we do that.
The people who need the hand-holding which Lineo, etc. are trying to sell, those people are too conservative to choose Linux, they just go with the Microsoft of the embedded word, Wind River.
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.
Like so many things in the computer world, there is a need for education in the Real-Time embedded arena. When I was at the Embedded Systems Conference - Boston 2001, Red Hat's CTO gave a presentation on Embedded Linux, and touted RTLinux as the up and coming 'official' Real Time approach. In a later discussion with him, we agreed what everyone seems be missing here
Most embedded systems are *NOT* hard real time systems. For those that are, there it the RTLinux wrapper that runs Linux as one of it's (lower priority) processes. Yet the people writing for sites like this have no clue and spread FUD, which the unfortunate reader often mistakes as factual.
Will Embedded Linux ever be popular? It all depends on if the Embedded Systems Engineers ever get properly educated as to what it can do, and how. The only real drawback is footprint size. If you need your embedded application to be small and run on 8-bit Microcontrollers, then Embedded Linux clearly isn't for you. However, for the vast majority of serious applications, Moore's law continues to make Embedded Linux a more and more viable solution if the Engineers start addressing the learning curve. Of course, first, they have to know that such an effort is worthwhile. With FUD like this article spreads, it will unfortunately be longer until people get it. No big surprise here. Almost everyhting worth while gets early adopters, goes on hiatus, and then comes back as the new latest and greatest thing that everyone always new was going to fly. You gotta love the cycles of life!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
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
There was a famous comment in the SunOS proc.h header file that said something like /* Please forgive me for this hack */
And I've seen plenty of commercial code that should have had comments like that, but didn't, which is a whole other kettle of fish.
Why didn't your company want to release the kernel mods back to the community? It's not like they were gonna make any money off them - they get paid for the embedded app, not the OS it runs on. I could understand if you were giving away something proprietary, but it doesn't seem to me that releasing those changes would have hurt your company one little bit. In fact, if you had released them, someone else might have come along and improved on your improvements.
Admit nothing, deny everything and make counter-accusations.
Hey, didn't Dell lay some people off? Gee, Windows must be dying.
Didn't @Home go bankrupt? The Internet must be dying.
FedEx has a hiring freeze; oh, no, people must be using the Post Office more!
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
I'm a junior engineer at a small company producing (a fairly killer, IMO) embedded-linux (ix86 atm, but that could change next release) device. Although the RT side of things is not my schtick -- I'm writing some custom web software and working on our in-house embedded-linux distro --- I *do* know that our RT guy is the biggest linux fanatic I know. He seems to have no problems using the RT stuff that's freely available for the linux kernel, and kernel-versus-license-wise, we're simply going to release the stuff we need to keep proprietary (FPGA drivers and firmware-adjustment/config stuff) as kernel module(s).
:)
In fact, RT guy *regularly* slams anything that doesn't have adequate RT support, so I am left to assume that he deems to have a set of RT capabilities which is more than adequate.
We're a small company, and running (like everyone else) under some rather tight fiscal constraints.
AFAIK, linux is what is currently saving our collective bacon -- if we're going to compete with the economies of scale of the big boys (not to mention their 'Deep Pocket Error Correction Algorithm') we can't afford to license some proprietary OS or development environment and pass that cost on to our customers. We have to be clever; therefore, we use Linux.
(Aside: I wish I could provide more details, but really, I'm more of a CS geek. My ideal level of abstraction is somewhere just south of lisp and north of Java. Assembly makes me go *bew*bew*bew*bew* (imgine index finger oscillating in front of lip). )
- undoware.ca
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.