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."
Linux is making slow progress into an area already claimed by DIY'ers and WindRiver. The massive market acceptance of devices like Tivo is a real feather in Embedded Linux's hat.
The fact that other companies are failing is simply a factor of business, not anything necessarily having to do with the viability of Linux as an embedded platform.
Kevin Fu wrote the article. Victor Yodaiken is behind RTLinux. Pretty simple.
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.
In theory using Linux on an embedded system can yield many benefits, but not all are very realistic. Certain applications, such as an MP3 player and manager lend themselves much more easily to the strengths of Linux, but the needs of many embedded devices can be met with something much less complete than Linux and that is what we are seeing in the "real world".
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.
It had a bad roll and had to draw up a new character.
Goat sex free since 2001
Correct. This is Slashdot, tech news for nerds. If you want to be alerted every time a CEO shuffles around, read the Times.
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
Everybody is always focussing on the fight between Windows and Linux regarding the desktop environments.
I personnaly think that the strenght of Linux is especially when you put it in an embedded environment.
I still hope we'll have a good surprise with the PS2 port of Linux, which should be a good exemple.
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
yes, there is.
Im building a linux distro for and embedded device
the developpers need X and a JVM
that all fits on a 128M Compact flash why wouldnt we use linux??
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
But to conclude or suggest that the product is inferior for starters because is not sending the commercial competitors to the pawn shop...thats bunch of malarkey.
I'm a platform agnostic. Sure, I'll ask people "why are you running Windows?", but I don't then immediatly plug Linux as the grand solution.
New users -and casual users- need Windows (or a Mac) so they don't have to worry about the details of configuring the system. Learning exactly how PnP works isn't something they are interested in. As long as the only thing they use the computer for is simple tasks -write letters or surf the net- Linux isn't for them.
And on the embedded scale, much the same applies. I use a Handspring Visor; all because I want a OS on my handheld that <i>gets out of my way</i>. The OS needs to pull up whatever app I need- be it the calendar or notepad or whatever- and then dissapear- because the more memory / processor / battery power needed, the more it costs, and the less I want it.
No system can be applied everywhere in the computing world and be the best solution everywhere. Linux has its' issues dealing with new users and embedded systems; this is not a flaw. Where Microsoft has failed is trying to write a system that can be used everywhere. It won't work; IMHO it <i>can't</i> work. Let's not drive Linux down that same road.
Do you like Japanese imports?
First, I'm not an embedded systems programmer.
But why the big fuss over Linux? As the article (or maybe a comment afterwards) mentioned, to get one of the RTOS distros/modifications costs money. So the licensing is a wash.
Except for some specific platforms, it's hardly optimized. So there is a great deal of vendor specific work to be done. So, marginal time savings, if any.
You aren't going to run Samba/Apache/LICQ on an embedded device, so the software availability doesn't really matter.
Now, the comment from the guy from Intel seemed to make sense: in certain areas on certain hardware, Linux is a good thing. Unfortunately, this article is largely a waste, as it ignores the breadth of embedded systems, and attempts to paint the entire Embedded Linux effort with one stroke. Were the author to say that one processor with one OS were the end-all/be-all of embedded systems, he'd get laughed out of a job (one would hope).
Saying that one OS has no/little place in embedded is merely the other side of this ludicrous coin. (BTW, again, I know next to nothing about embedded systems. If I can pick up on these glaring flaws, why should anyone give this article the time of day?)
Jesus was all right but his disciples were thick and ordinary. -John Lennon
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.
My embedded projects usually don't need virtual memory or processes, just memory protection and threads. So Linux is overkill as well as being too slow.
On the other hand, the driver sources, the libm and libc, have all been useful starting points for either roll your own, or extending another RTOS.
If this sounds appealing, and you need an RTOS, look at RTEMS an open source RTOS with many ports.
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.
perdida, you're the cutest troll girl I've ever met. Will you marry me?
...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
There is a problem with running any variant of UN*X with a real-time system: the fact that it is possible for any process to be interrupted for an arbitrary and unpredictable amount of time. You can play games by using nice with negative values to reduce the probability of this happening, but you can't be 100% sure.
Of course, "real-time" is poorly defined, and "embedded" is even worse. Nevertheless, in practice, these fuzzy blobs seem to go together. Embedded systems tend to need to be real-time, either because they are in an application that absolutely demands it (engine computer, perhaps) or the hardware on which they are running is so wimpy that time irregularities people wouldn't notice on much faster systems would be a big problem.
Probably, big chunks of Linux, suitably hacked, would form a good basis for a variety of embedded devices. The kernel is already small, and it would be smaller. However, just taking the kernel per se and building an embedded application on top of it is a bit like the tail wagging the dog.
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.
I just noticed that www.cicuitcity.com (CircuitCity misspelled) goes to Best Buy's website. That's gotta be a new low for an already crapping retail chain.
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.
I understand your points,
but at the same time I think you didn't realize one thing: if Linux weren't GPL, you would never been able to use it the way you did(including changes in the source code). Sure, competing businesses of yours would also be able to use YOUR changes, the same way YOUR business used the changes and contributions of thousands of other programmers. So I think it is a fair deal! The way you did it now, you wrote a PROPRIETARY system for your customer, effectively locking him IN into a contract with YOUR company. The GPL would have prevented that, giving YOUR customer the choice to contract someone else anytime, without having to buy a whole new bunch of software. So maybe this turned out to be better for YOUR company(software producer) but certainly it is a disadvantage for YOUR customer, probably he just didn't realize it. The time will come, when more and more customer will demand open source solutions because of the reasons I just explained.
And if you think it out, even if a competitor could read all your code, you still would always have an edge, besides being able to read HIS changes to the code also, so I think there is space for a fair competition, where the CUSTOMER will win.
Many problems arising today in the computing world is because of that kind of proprietary standards, that software companies love, but are a tragedy for the customers...
Btw, it is WRONG, that code compiled with GPL compilers like gcc have to be put under GPL.
I bet you suck cock real good. Grab on tight to my knob and suck away. I'll get Linus in here to bang you in the ass with his 4 centimetre cock.
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.
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
that the author don't know "jack"?
I can't see running Linux on anything that doesn't have a hard drive.
Linux can't go away.
But there is a scenario that would change it drastically:
Forking. With or without the GPL being declared invalid, it wouldn't be hard and it's surprising there haven't been more kernel forks.
If the GPL is found invalid in court, for a variety of reasons, there could be 130 different version of Linux within a year, none of which are completely compatible. Unix 1980's all over again.
That's pretty likely, as a matter of fact.
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
His name is egg TROLL for christs sake! he's a fuckin troll. And congratulation sir, You Have Been Trolled!
I guess it all makes sense to me now.
/* this is a hack */ scare you... Apparently not being able to see the source makes you feel better. "If I don't know about it, it doesn't exist." Of course when the code is right there, it's harder to pretend the code must be perfect.
The reason Linux (and other OSS software) has so much trouble being accepted is that it forces you to face reality.
So comments like
Or submitting a bug report and - snicker - witholding payment until it gets fixed. As if any proprietary vendor would ever let themselves get roped into a contract where customers could not pay if the software had bugs. That's pure fantasy on your part -- and yet I've heard the same argument repeated as to why they wouldn't choose Linux. But since Linux doesn't let you pretend that you can hold someone accountable it gets rejected.
In a way, it's the same with the whole UI problem. People will tell me how easy to use Windows is, and I'll sit next to them and listen to them cursing as it does things they don't expect. But Windows keeps telling you it's easy to use, so they can pretend it really is. Linux doesn't try to trick you that way, so they can't let themselves be tricked.
Okay, that was starting to get off topic, but it is related I think. Stop fooling yourself -- if something works for you, then fine, but don't prop up the system with self-delusion.
The enemies of Democracy are
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
So does an implementation of realtime linux:
http://os.inf.tu-dresden.de/drops
http://os.inf.tu-dresden.de/fiasco
http://os.inf.tu-dresden.de/LinuxOnL4
So does the DWCS scheduler for Linux Systems:
http://www.cc.gatech.edu/~west/dwcs.html
Huh?
Huh? The Linux kernel is also ROMable. If you want a microkernel (something I think is a bit wasteful in something like an embedded system), go back up to that fiasco link I put up on top.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.
The assumption that all development is in the corporate realm is most evident in this sort of article. Companies come and companies go, but the development of free software and hardware on which it can run goes on with or without corporate backing.
We have a project to develop free hardware designs to which free software is being ported, with no corporate backing. For an example of an embedded controller to which Linux is being ported, look here:
http://freeio.org/library/toast.htm
Soli Deo Gloria
Are there any companies that specifically design embedded Linux development kits for college courses? If any company is interested in becoming successful selling embedded products they should produce low cost versions of their products that can be used in electronic engineering courses. Documentation is also very important. Without good documentation it's difficult to convince people to learn how to use your product.
LOL! Have you never heard of the BSD license???
www.freebsd.org, www.netbsd.org, www.openbsd.org.
Those are the most commonly used OS's for embeded systems, and tons of them we don't even know it. That's the beauty of BSD over GPL.
Next time, do the research... You should have just used BSD.
Quite the opposite. Many embedded devices DO contain embedded HTTP servers. Some of them even run Samba. (I wrote the User Authentication code for one of the more popular firewalls, with used Samba to piggyback off of the NT user database.) The availability and ease of porting open implementations of protcols like OpenSLP and OpenLDAP is one of the main reasons I've been advocating switching from PSOS (which WindRiver bought out and is abandoning support for) to Embeded Linux here at my current job.
Secondly, Real-time Linux costs money, but most embedded applications don't really need a real-time OS!!! The aforementioned firewall vendor didn't license any embedded Linux, they just used a stripped-down version of the standard Linux kernel. There are far too many embedded Linux vendors chasing too few customers; competent developers can do their own Linux port.
And by the way, I _am_ an embedded systems engineer!
What many people are overlooking is that embedded systems are not necessarily small...they're just embedded.
The project I'm with at work is a phone switch. We've got dual boards, each with dual 100Mb ethernet, quad serial, fiberchannel, a 450MHz G3 cpu, and a gig of RAM. They run linux.
We looked at QNX, but they would make the required changes to their memory mapping to support our app. We considered Montavista, but decided that we didn't need what they were offering. The kernel mods that have original ideas (intellectual property type stuff) are segregated into a loadable module so that it doesn't need to be GPL'd. All the other incidental stuff will of course be made available to our clients as required.
The biggest advantage of using linux is the sheer user base. Except for the really far-out stuff, almost any normal issue has already been dealt with by someone and its just a matter of looking it up.
While the companies that specialize in embedded linux may not be rolling in the dough, that doesn't mean that there isn't a lot of work being done. It may be that companies have simply decided that they can hire a programmer (or a team of them) for less than they could licence a product from another company.
Where foes Marcello Tossitoff, the new stable 2.4 maintainer fit into this?
The car is just a variation on the DVD player which is just a variation on the space shuttle.
Do you think power tools and space shuttles will find much in common to talk about?
The author seems intent of finding someone or some group that is successfully leveraging Linux in the embeded market. Why doesn't he check out LynuxWorks?
You may remember these guys from LynxOS. This RTOS (in true defintion of the term -- not in the LinuxRT version) runs on countless embeded platforms. Ever setup a JetDirect card on an HP printer? That's LynxOS.
Well, these guys are doing a lot with Linux now. I attended a talk about two years ago, right before their product BlueCat (strikingly similar to RedHat, eh?) came out. My information may be out of date, but some of the stuff the guys talked about was very cool. An embeded tool-chain. Boot loaders. And most interesting source (and later binary) compatability with LynxOS (by which I mean that LynxOS would run Linux source). To quote from the web page: BlueCat Linux applications can be migrated to the LynxOS platform with no loss of functionality and with minimal effort or delay. LynuxWorks development tools support both operating systems so there are no new tools to purchase and no new learning curves. This all means that customers can develop using BlueCat Linux and then quickly migrate and deploy applications to LynxOS when real-time needs emerge. Anyway, as I said, my info maybe out of date, but these guys shouldn't be overlooked. Oh, and for all who are wondering, I am in no way connected to this company.
You can't get a blue screen on a black and white monitor.
PalmOS is embedded, but not realtime. Most folks don't need it.
Me, I'll take a cheap 386-class processor in a handheld, 32 megs ram, some flash, and I'll slap Linux on it. I'd love to compile gcc on battery power and have it not be on a laptop.
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
I now increase the number of comments posted to this story by 1!
Beautiful. Nice one, egg troll.
The author of the article has failed to make a distinction between embedded systems and embedded real-time systems. By bunching the two together he's managed to play down the significance of Linux as an embedded device plaform; set-top boxes, PDAs, network devices, mp3 players (on steriods!), and so forth.
Sure, an unmodified Linux kernel running natively (as compared to "on top of" a true RTOS) might not be able to provide a deterministic environment but that doesn't negate the fact that Linux is a stable and cost effective solution for embedded systems that don't require determinism.
Linux is not an RTOS so the author should not really be examining its impact in the RT embedded market. Instead he should be concentrating on the embedded systems market that does not required response within specific time restraints. If he did that I think he'd find that the Linux kernel is a remarkable resource for embedded systems development.
is an example of nothing. It's just another Linux port. Good for enthusiasts (i'll be getting one if the PAL kit ever comes out), but not much more. I don't believe that many future PS2 games will be using Linux as their basis - there's a native RT OS for that, which is much more suitable.
On a floppy, that is not big by today's standards. But is way bigger than lots of things in embedded systems. Does you know a lot of embedded systems use Z80 like (in terms of processing capacity) processors? That is why linux is not used that much in embedded systems. It is quite big in relation to most embedded systems.
by the way, if you metion floppy systems you should that a look at the QNX demo disk
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 don't know that I'm not wrong either, so I asked the local Solaris guru. He said that later versions of Solaris provide prioctl, which is somewhat better than nice, but that he hadn't heard of any kernel extensions that provided guarantees or any way to make such guarantees to the process. I looked at the description of prioctl in his book, and while it contains some hand-waving about "real-time" processes, it falls short of making any guarantees.
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.
That's a good definition, provided that it is clear we are talking about wall clock time. Unfortunately, it's a bit like the definition of "gender" (a grammatical marker in the sense that person and number are markers); nobody really pays much attention to it.
Except that it doesn't go to Best Buy, it goes to some online casino.