Embedded Linux Tools Market a Myth?

nadamsieee writes "EETimes is running a story that proclaims that the embedded Linux tools market is a myth The author, Dan O'Dowd, sites variety of problems (challenges?) with embedded Linux ranging from poor real-time performance to lack of broad developer support. Dan concludes: "Considering all of the possible support avenues, Linux support ends up being lower quality and more costly than the alternatives of using a homegrown operating system or purchasing a proprietary one." Maybe Dan should check out the success stories at LinuxDevices.com or perhaps try a more traditional embedded OS that also happens to be Free."

Comments

what's the meaning of this?

[gotem]

Linux support ends up being lower quality and more costly than the alternatives of using a homegrown operating system
why is a support from an open source OS diferent from a home grown one?

Re:what's the meaning of this?

[Anonymous Coward]

Homegrown support ends up being lower quality and more costly than the alternatives of using a linux operating system
why is a support from a closed source OS diferent from a linux one?

Re:what's the meaning of this?

[Shinobi]

Because, assuming basic competency, if you write it from scratch, it does _exactly_ what you want it to do, it's developed just the way you want it, and with the documentation that you want and need.

With Open Source, you can easily end up spending more time modifying it to your specific needs than it takes to write it from scratch, especially if the source you're looking at is using a method for doing things that is not suitable for your problems. Especially since lack of or inferior documentation is all too common among many projects.

Re:what's the meaning of this?

[CuriHP]

The people who wrote it will have the best understanding of how the system works. If they happen to be sitting next to you, it is easy to get support. That of caourse assumes that they aren't jerks.

Re:what's the meaning of this?

[mpe]

The people who wrote it will have the best understanding of how the system works.

With proprietary software these are likely to be the only people on the planet who know how it actually works.

If they happen to be sitting next to you, it is easy to get support.

Except in the case of very small companies the software writer is unlikely to be answering the "support" line. If the writer has left the company or was a contractor in the first place don't expect customers to be told :)

Re:what's the meaning of this?

[CuriHP]

Both valid points.

Regarding your first point. Open source software may very well still have the same problem. Just because a piece of software is open source, it does not necessarily mean that there a hundreds or thousands of people that understand the inner workings, and more importantly are willing to help. There may be, but there is no guarantee of it. And even if they are, you may not necessarily be able to find them.

As to the second I was speaking from personal experience to some degree. We have some custom in house software here and it is very easy to get the guys who wrote it to answer questions. That may not be true everywhere.

Re:what's the meaning of this?

[dgatwood]

Before I reply, I should disclose that I'm a minor stockholder in an embedded Linux company, so my opinion may be biased. There, now that that's out of the way....

Most embedded Linux developers do just that: they write their own system on top of a Linux kernel. The value-add from embedded Linux companies is having people with more Linux kernel experience porting Linux to your custom hardware.

The article's author shows a lack of understanding of the future of embedded systems. In the past, he would have been correct. Most embedded systems were historically devices where safety was a concern and real-time performance could mean the difference between a robot actuator arm killing an employee or stopping in time.

However, most modern embedded systems tend to be consumer devices---set-top boxes, iPod & friends, kiosks at the mall, video game consoles... the list goes on. These systems are where embedded Linux makes the most sense.

Think about it: you could buy an embedded OS, pay a per-unit royalty on every product you ship, pay extra money for a TCP/IP stack, more money for that driver you need, etc. and STILL possibly have to spend man hours porting it to your custom hardware. Alternately, you can go with Linux and pay up front for a cross-development kit, technical support, etc. and have someone ELSE port it to your custom hardware, generally pay no per-unit royalties, etc.

It's easy to see why old-world RTOS vendors are running scared. Linux offers more for less money, and frankly, people like this article's author will run all sorts of negative articles to try to stop it, but in the end, an RTOS vendor trying to stop embedded Linux is like a small animal trying to stop a buldozer. Short of some new environmental protection, it's not going to happen.

That's not to say that there isn't room for traditional RTOS vendors. I wouldn't want embedded Linux running the fly-by-wire systems in a jet aircraft. I wouldn't want it running automation at a manufacturing plant (at least at a robot unit level... managing a production line, maybe). I wouldn't want it running my digital watch.

Both sets of products have their uses, and I think the market as a whole would be much better off if RTOS vendors would focus on improving their products to try to compete with each other in the real-time space rather than trying to spread FUD about Linux and trying to pretend that soft real-time isn't good enough. For the types of devices that embedded Linux targets, soft real-time performance is more than adequate, costs less, requires less programming effort on the manufacturer's part, and often results in a faster time-to-market as well.

The two classes of products aren't competing with each other, hybrid Linux/RTOS designs notwithstanding, and in the case of those, most of his arguments are, in fact, outright lies. In short, this article has been moderated 100% troll. *sigh*

Re:what's the meaning of this?

[Sivaram_Velauthapill]

I was thinking the same thing. For things like set-top boxes, etc, embedded Linux or Windows or whatever should be suitable. I think the author's points are only valid for mission-critical real-time systems (like some you mentioned, along with medical devices, trains, etc).

Sivaram Velauthapillai

Re:what's the meaning of this?

[Anonymous Coward]

I write to a RTOS. I've tried embedded Linux--perhaps even from your company. Let me say: embedded linux is not worth my time as of now.

Who is that "someone ELSE"? Me. And I charge money for my services. My code is faster and more predictable than yours, well written, documented, and takes up a smaller footprint. This is different than what I have found in embedded linux.

Embedded linux offers less for less money. Soft real time? What a joke. Real time is real time. Not real time is not real time. Don't call yourself "close enough" when you are not meeting the real time expectation. Perhaps *you* can get by with less, but not on my plane, ship, medical device, or mission critical hardware.

Re:what's the meaning of this?

[Xabraxas]

Soft real time? What a joke. Real time is real time. Not real time is not real time. Don't call yourself "close enough" when you are not meeting the real time expectation.

Oh...so you mean something like this.

Re:what's the meaning of this?

[dgatwood]

By "someone else" porting to your custom hardware, I meant the embedded linux vendor. Most will do this for a fee, and can do it faster and cheaper than hiring people to do it yourself.

As I said in the grandparent post, embedded Linux is not intended for mission-critical applications. It is primarily intended for consumer devices. Its usability in those environments is not in any way contingent on its usability in a mission-critical real-time environment. They are totally different kinds of products with totally different performance needs.

Not a myth.

[Anonymous Coward]

Just so obscure and crappy people *think* they don't exist.

Get real....

Missing something from the article?

[AnswerIs42]

Did anyone catch the "Paid For by Microsoft" part they are supposed to put in these kinds of articles?

I may have missed it while reading and controlling fits of laughter.

Re:Missing something from the article?

[Anonymous Coward]

Well the link of the Author's name goes to GreenHill. They make their own Realtime OS. Maybe there's a hidden agenda here? No different than MS saying Windows is better than Linux.

The author has a point... as far as it goes

[j0keralpha]

The article is IMHO unnecessarily inflammatory, but the author highlights a problem not only for the embedded linux market but for the entire linux market. The lack of support for what are admittedly GOOD products is gnawing, and makes the enterprise usefulness of some of them fairly limited. You and I might be able to figure stuff out on our own, but Joe CEO wants everything he uses to be backed 24/7/365 by the company making it. And you know what? Hes right.

Re:The author has a point... as far as it goes

[lurvdrum]

Then let Joe CEO take out a paid for support contract - heaven knows there are enough companies getting into the Linux support game now. With all the money he saves avoiding proprietary operating software he can certainly afford it.

Re:The author has a point... as far as it goes

[IWorkForMorons]

You and I might be able to figure stuff out on our own, but Joe CEO wants everything he uses to be backed 24/7/365 by the company making it.

Yeah. That's why Joe CEO calls up Red Hat and buys Enterprise Linux and a 2 year support contract. Support is out there for those willing to pay for it...

Re:The author has a point... as far as it goes

[AndroidCat]

I'm not sure if the "give it away and make money on service" model will really work for small development companies. While being able to charge for support would be nice, most small companies don't have the people to handle it.

I've also seen what happens to a company that suddenly changes its income model from selling software to supporting some very large clients, and it's not always pretty. ("Why yes, we'll uproot an entire development team and have them live out of a suitcase onsite for a couple months--as long as it takes!")

Re:The author has a point... as far as it goes

[mpe]

You and I might be able to figure stuff out on our own, but Joe CEO wants everything he uses to be backed 24/7/365 by the company making it. And you know what? Hes right.

If Joe CEO want's this kind of support for anything then they had better be prepared to pay for it. As for this support comming from the company who made the widget this isn't usually a condition with anything else so why should it be with software. Anyway when it comes to proprietary software all you know is who supplied it to you. Did they actually write it? Did they buy it from someone else? Did they buy it from somewhere else and hack it about? Only with OSS do you have any way to find out who actually wrote the software.

Re:The author has a point... as far as it goes

[EmbeddedJanitor]

I'm sure a Linux support contract would be lower cost than an Microsoft one or Sun, IBM,....

The biggest problem is that people get it into there minds that Linux==free, therefore they feel they're getting cheated when they spend any money on Linux-based services and software.

Re:The author has a point... as far as it goes

[gosand]

The lack of support for what are admittedly GOOD products is gnawing, and makes the enterprise usefulness of some of them fairly limited. You and I might be able to figure stuff out on our own, but Joe CEO wants everything he uses to be backed 24/7/365 by the company making it. And you know what? Hes right.

You know, having 24/7 support doesn't always mean much. Here at work we use Rational tools (now owned by IBM). Sure, we have a big honking support contract, but you know what happens when I call them for support? Jack. I either get someone who runs down a standard support call sheet that I have heard 100 times, or I get someone good who says "yeah, we know about that issue, it might be fixed in our next release. But maybe not." Wheeee, that support did me a fat lot of good. I know several of their Test Manager support people by name, and I would say that 90% of the time I call them with issues, the result is that the problem is a limitation of the system. I don't need their support people to tell me that. But I guess I can get a useless answer to my question 24/7.

I find it interesting that the PHB thinks that Microsoft stands behind their product, but knows better than to actually call up Microsoft as an end user and try to get help. It is a joke around here, and I am sure elsewhere, when the system locks up or crashes to say "Call up Microsoft Support". However, I can usually always find help in the user community, whether it be a Linux forum, or on sites like dvdrhelp.com. Community support is usually much better than "official" support, IMHO.

Re:The author has a point... as far as it goes

[Anonymous Coward]

...but Joe CEO wants everything he uses to be backed 24/7/365 by the company making it.

I've heard this argument a lot, but having been involved in embedded development more years than I want to think about, it just doesn't pan out that way. Sure, it gives the boss a nice warm, fuzzy feeling that the vendor is gonna support their product, but I know damned well that I'm gonna have to find the problem, generate a test case that explicitly generates only the problem and then rub the vendor's nose in it before they will even admit that there is a problem! By the time I've done all that, if I had the source I would fix it myself!

Re:The author has a point... as far as it goes

[AnotherBlackHat]

... the author highlights a problem not only for the embedded linux market but for the entire linux market.

DYT?

This isn't just a problem with Linux, it's a problem with the all platforms.

Bad support? Poor/buggy software? High prices and low quality?
I've heard that about everything.

Of course, not everyone says that, but the ones that don't are trying to sell you something.

-- this is not a .sig

Re:The author has a point... as far as it goes

[HangingChad]

but Joe CEO wants everything he uses to be backed 24/7/365 by the company making it. And you know what? Hes right.

And where does he get that now? Certainly not from MS, IBM, CA, or any other vendors we deal with. We have to PAY for support like that. You can get 24/7/365 OSS support for less money if you're willing to pay for it. I don't know any CEO's with the mistaken impression that if they buy proprietary software there's going to be a company standing by to assist 24/7/365 and they're even starting to wake up to the fact that most software companies don't provide the end user with much in the way of indeminification.

If your CEO gains some kind of comfort because a software company has a building he can point to, then I'd suggest he has bigger problems than not understanding OSS.

Re:The author has a point... as far as it goes

[dgatwood]

But people in the embedded market don't care. They've gotten used to paying per-unit royalties on top of steep initial costs just to get up and running. Compared to that, a Linux support contract is a breath of fresh air. :-)

Re:The author has a point... as far as it goes

[Sivaram_Velauthapill]

Everything I say is my OPINION... that goes without saying I guess... :)

I find it interesting that the PHB thinks that Microsoft stands behind their product, but knows better than to actually call up Microsoft as an end user and try to get help.

It's more of a BUSINESS decision than a technical one. The reason management does that is to mitigate risks. That is to say, shift the blame onto someone else. As the saying goes "No one ever got fired for buying from IBM" (I hope I'm getting the quote right). Except this is more at a managerial level. Buying support, regardless of how good it is, means that there is SOMEONE to handle it. Without it, who will get the blame? Most likely the manager and his team.

Think about it. If YOU didn't have the support contract with Rational, YOU will have a MUCH TOUGHER time. You'll be the person at the end and will have to handle all the blame. For instance, if something is a limitation of the software (as you pointed out), YOU will have to JUSTIFY that (if you didn't have support). But if you had support, you can always say that Rational said that it is a limiation of the software. That is a simple example but extrapolate that 100x and you'll see why companies do what they do. When your boss gets yelled at by his superiors, which is easier: "My team is working on it but I need more time" or "Rational/IBM has been notified and they are working on it". Your manager just shifted the blame from your team onto some large vendor like IBM.

The same thing is true for other business issues. In fact, one can argue that most business decisions are carried out for reasons like that. For instance, things like outsourcing, offshoring, downsizing, vertical integration, etc are simply based on POPULAR business views. When downsizing was popular (early 90's), managers and executives carried it out a lot. They did this, not because they knew it would work (this destroyed some companies in the long run), but because everyone else was doing it. It is easier to do something that everyone else is doing and which is justified in the Wall Street Journal, Forbes, and by the business academia, than not doing it at all.

Sivaram Velauthapillai

Re:The author has a point... as far as it goes

[stephanruby]

I'm sure a Linux support contract would be lower cost than an Microsoft one or Sun, IBM,....

Doesn't IBM provide support contracts for Linux-based systems?

Re:The author has a point... as far as it goes

[EmbeddedJanitor]

You miss my point. Even if the Linux solution is better,faster ancd cheaper overall, people are still reluctant to pay for any Linux stuff because "It is supposed to be free isn't it? So why am I paying anything?".

Re:The author has a point... as far as it goes

[Prior Restraint]

The way you describe things, support contracts sound more like an insurance policy. "Pay a periodic premium, and you're covered in the event of unexpected blame."

This is not to suggest you're wrong; I happen to believe the single largest factor in day-to-day business decisions is blame-avoidance. Someone pauses by my cube and asks my opinion on some random issue, and an hour later I get CCed on an email with the phrase, "I consulted with [my name], and he suggested I...". Meetings swell with extraneous attendees to ensure anyone looking to fling blame about will find no one in particular to strike.

It's really fascinating to observe, if you aren't emotionally invested in the incident.

Re:The author has a point... as far as it goes

[Sivaram_Velauthapill]

This is just my opinion so take it for what it's worth. I DO think that most business decisions are like insurance. I think this is pretty much true for management--especially for project managers. I have seen my bosses and their bosses make decisions that don't make much technical sense but are good business decisions (to alleviate risk & blame). Ultimately it makes sense from an external point of view. It is logical for management to do everything in their power to keep their job. In fact, finance theory has this notion of agency cost which is used to explain why CEOs get paid millions in stock options (according to this theory, it is to align their interests with that of the company. Otherwise, the executives will simply act in their own interests).

When I was in the field (only for a few years--I was in school at that time), I didn't really run into the problem you are talking about (some dude referencing you when in fact you were just giving some opinion). But I did hear about it. I guess it is more of an issue for senior people. I can imagine someone pinning the blame on some architecture or design issue on the person who "suggested" it, instead of they themselves (who made the decision to go with the "suggestion") take responsibility.

"It's really fascinating to observe, if you aren't emotionally invested in the incident."



heh :) When I did have a job, I was only a low level employee (entry level software developer,etc) so I know what you mean. Never faced anything big but I have seen stuff happen...

Sivaram Velauthapillai

This guy sells his own stuff?

[BoldAC]

Founded in 1982, Green Hills Software Inc. is the technology leader for real-time operating systems and software development tools for 32- and 64-bit embedded systems. Our royalty-free INTEGRITY(R) RTOS, compilers, MULTI(R) and AdaMULTI Integrated Development Environments and Green Hills Probe(TM), offer a complete development solution that addresses both deeply embedded and maximum reliability applications.

http://www.ghs.com/news/230325c.html

Doesn't this guy sale his own embedded options?

Wouldn't he push his own product over linux?

What am I missing?

AC

Re:This guy sells his own stuff?

[Anonymous Coward]

This makes him an expert in the field. Although he may be biased, he knows more about this market than 99.99% of the population.

Re:This guy sells his own stuff?

[Anonymous Coward]

You're missing the fact that he's right, too. If Microsoft says, "MS Operating Systems have approximately a 93% market share," it's still true.

Had this been "Joe Shmoe, Linux user" I'm sure most of the people here would take Joe at his word. God forbid someone from outside the fold try and illustrate some facts. The embedded market is larger than people hacking together home made STBs and MP3 players.

Re:This guy sells his own stuff?

[justsomebody]

This makes him an expert in the field. Although he may be biased, he knows more about this market than 99.99% of the population

This also makes him more biased in this market than 99.99% of the population;)

Re:This guy sells his own stuff?

[chthon]

You know what ? WindRiver also thought that they did not need Linux because they owned 70% of the embedded RTOS market. A couple of months later they turned 180 degrees and embraced Linux completely.

Re:This guy sells his own stuff?

[dgatwood]

I'll bet they embraced it... in much the same way that Microsoft embraces things... with intent to crush.

Ah, but Linux's soft real-time isn't good enough for playing audio over a network. You really need to move up to our hard real-time in pSOS.

</cynic>

Re:This guy sells his own stuff?

[Anonymous Coward]

Letters to the editor go to George Leopold:

gleopold@cmp.com

Re:This guy sells his own stuff?

[Stiletto]

I have to use the Green Hills compiler / debugger tools at work.

Trust me, they SUCK.

I could go into many examples of how the product is inferior to even a bunch of xterms running vi and gcc. From dongle/license frustration to waiting twice as long for builds than, say, gcc/make, to getting the right bit of magic scripts to work with their probe, I don't think there is one redeeming thing I can say about it.

Of course this guy is going to disrespect gcc and Linux tools. His own product is horrible.

Re:This guy sells his own stuff?

[macshit]

Ha ha, yeah definitely Green Hills has reason to be scared of free software: we use their stuff at my work for embedded type development, and it seems pretty clear that their presence in the market is slipping due to competition from free software (mostly gcc in my experience, in competition with Green Hills' compiler).

Not in asia

[Anonymous Coward]

article

Re:Not in asia

[Anonymous Coward]

Read The Article you linked to.

Its written by Raymond Mak, V.P. of Asia-Pacific MontaVista Software.

You know, the MontaVista Software that is making money selling tools for embedded linux?

Look who the author of the article is

[Anonymous Coward]

Dan O'Dowd is President and chief executive officer of Green Hills
Software,Inc.
Green Hills sells compilers and RTOS for embedded
systems. (They have been the market for a long time).
No wonder he does not like Linux.

Re:Look who the author of the article is

[October_30th]

Being a competitor does not make him automatically wrong. In fact, one might say that he's an expert on the matter.

Re:Look who the author of the article is

[leinhos]

... with a clear conflict of interest, as well as a biased point of view. Even if what he says makes sense, selective presentation of facts can be used to support any conclusion.

Re:Look who the author of the article is

[October_30th]

So? The readers should always exercise caution as always.

Many posters here seem to be upset that he's written an article when "he has a clear conflict of interest". I don't see any reason for that.

Re:Look who the author of the article is

[John Courtland]

The conflict is that he develops software that linux is directly competing with: embedded operating systems.

How can you not see that? He's getting run over by a free and agile OS.

Re:Look who the author of the article is

[October_30th]

My point is: of course he's biased/conflicted. So what?

Re:Look who the author of the article is

[k12linux]

I would have been satisfied if the mini-bio at the bottom of the article had said, "Dan O'Dowd is President and chief executive officer of Green Hills Software,Inc., which sells real time operating systems. (Santa Barbara, Calif.)" Or, preferably some type of disclaimer early in the article.

I'm certainly not saying he shouldn't be allowed to write an article. Just that, as it is, readers may not know there is any type of conflict.

Re:Look who the author of the article is

[Shinobi]

So? Slashdot links to stuff from pro-Linux biased people all the time, without any such disclaimers either. The really annoying part is that noone whines about biased PoV then....

Re:Look who the author of the article is

[110010001000]

No, what makes him wrong is tha fact that he challenges the Slashdotters worldview.

Lynch him.

Re:Look who the author of the article is

[ninejaguar]

So, why waste time reading questionable and logically faulty arguments from a competitor's clearly biased and conflicted opinion piece? That's what's called a commercial. A boring one at that. I'm simply peeved that my time was wasted reading the drivel. This is definitely a case where I could've simply skipped the article and read the comments on slashdot first. I would've at least have run across the warning of the author's conflict of interest and moved on to something relevant.

= 9J =

Re:Look who the author of the article is

[Anonymous Coward]

Why would we listen to linux people wither? They're just as biased and subjective as this Dan is.

Dan, Bill Gates, Linus, they're all credible experts on the subject. So there might be conflict, but there is always some truth to what they say. In the end the consumer will decide anyway.

Re:Look who the author of the article is

[Anonymous Coward]

Just cause he's a competitor doesn't mean shit. He could have adopted embedded linux and sold support, and probably made more money considering it ends up being more expensive in the long run.

Re:Look who the author of the article is

[Anonymous Coward]

As a competitor, he has every right to write the article. EETimes has a responsibility to insure the accuracy of his assertions and disclose that he has a vested interest in embedded Linux alternatives, to their readers.

Re:Look who the author of the article is

[John Courtland]

Yeah but slashdot isn't selling anything but crappy subscriptions.

Re:Look who the author of the article is

[Anonymous Coward]

My company makes a product which consists of a few components. Our terminal runs Montavista Linux and we develop with their crosscompiler etc and Qt, our controller uses Green Hills Multi to compile code for that device's proprietory OS.

Multi is a piece of shit and our developers would be glad to drop it for gcc.

Re:Look who the author of the article is

[bheading]

Amusingly, his company sells compilers and debugging products for Linux :

http://www.ghs.com/download/datasheets/multi_lin ux .pdf

Seems he's contradicting himself slightly. He obviously believes there is some kind of embedded market for Linux, otherwise he wouldn't be selling products supporting it.

Re:Look who the author of the article is

[k12linux]

Dan, Bill Gates, Linus, they're all credible experts on the subject.

Sure.. but at least with Bill and Linus you KNOW where the bias is. Dan comes accross in his article as just some poor embeded Linux developer who has been burned by using Linux, has seen the light, and is just warning the rest of us.

Again, I'm not saying his opinions are valueless, or that they should simply be dismissed. What I'm saying is that a little more disclosure would have been appreciated. What's wrong with that?

Re:Look who the author of the article is

[mcc]

The difference is that unlike EETimes, Slashdot is not considered to be a professional source of journalism.

Re:Look who the author of the article is

[Sivaram_Velauthapill]

He might not be wrong per se. However his articles, opinions, and thoughts will be BIASED. This is especially true if he is indeed an executive. A HUGE chunk of compensation executives are tied to company performance (whereas an engineer's is based more on personal performance or product design or whatever). Therefore, it is reasonable to expect this person to be biased AGAINST his competition. Whatever an executive says is pretty much straight out of company PR. In fact, many executive commentary is run through the company PR people first.

Therefore, this article is not valuable. Sure, he may be correct about some things he says. However his bias will mean that the reader can't tell how correct they are.

Sivaram Velauthpaillai

Re:Look who the author of the article is

[Anonymous Coward]

And greenhills support is crap. Thats what I'm getting now. They are more like accountants than software engineers.

Re:Look who the author of the article is

[Anonymous Coward]

So? Slashdot links to stuff from pro-Linux biased people all the time, without any such disclaimers either. The really annoying part is that noone whines about biased PoV then....

You must read a different Slashdot to me... all I ever is read is people whining.

Re:Look who the author of the article is

[Anonymous Coward]

You are a Slashdotter[1] as well.

[1] Daughter of Slash?

Re:Look who the author of the article is

[Kaz Kylheku]

No, selective presentation of facts cannot be used to support any conclusion. For example, it cannot support a conclusion that contradicts one of the facts themselves! A set of facts will always support correct conclusions. If you find some new knowledge that contradicts one of the facts, then it was not really a fact to begin with, but an incorrect assumption. Or perhaps the new knowledge isn't factual. Facts don't contradict each other, nor does a larger set of facts contradict any conclusions that follow from any of its subsets.

The speaker's bias doesn't have any bearing on whether or not something is a fact. Either what he is saying is factual or it is not.

Bias may be used to explain a writer's incorrect reasoning: like when he uses cherry-picked facts which appear to support his desired conclusion, but in fact do not due to faulty logic.

The identification of a bias is not a shortcut toward concluding that a writer is wrong! Nor does it make it more difficult to know that a writer is wrong. It only provides an after-the-fact hypothesis about why he is wrong, namely that he may be deliberately wrong not because his reasoning is faulty, but because his vested interests are leading him to make arguments that are deliberately persuasive of those who are unable to spot the faulty reasoning.

The loss of credibility has already taken place by this point, and doubt of character is beginning to take root.

Re:Look who the author of the article is

[In2Linux]

After reading the Green Hills' website pretty thoroughly, it's clear that Green Hills is promoting their operating system and tools specifically where they have obvious advantages over Linux. Their Integrity operating system claims to offer virtual address space protection for applications and device drivers, guaranteed resource availability, bounded kernel response time, POSIX support, very impressive performance claims for minimum interrupt latencies and fast context switch times, and it's royalty free. They also have an impressive list of middleware applications and support for a lot of embedded boards. Finally, we all see surveys about how Linux developers want better tools for application development, well Green Hills has a lot of graphics showing how they can debug multi-tasking embedded programs. If Linux had these kinds of tools, it would probably help in increasing more widespread adoption of Linux in the embedded world. Finally, it appears that, if you look at many of their customers vs. many of the typical companies that build products with Linux, the Green Hills customers seem to be those that make products that require very fast, bounded response times (unlike a PDA for example). I didn't see any PDAs on Green Hills' website. There was one posting that Green Hills must be losing a lot to Linux, but the Green Hills claims on their website that they grew 29% in 2003 and that they were profitable. In summary, I'd have to say that they offer a lot of the same advantages as Linux (royalty free operating system with memory protection) with integrated tools. I don't think that they are going after the same customers as Linux companies do (you'll see a lot of aerospace customers listed on their website), so I would guess that their customers (aerospace) are willing to pay for their proprietary software and operating system while companies that make PDAs and the like will still be ideal targets for Linux-based solutions.

Re:Look who the author of the article is

[BitGeek]

The point is, that everyone here is biased and just as conflicted in their interests-- only with the opposite polarity. So they see a problem in this guy that they cannot see in themselves.

Well. I'm not too surprised..

[Czernobog]

I had to work with Lineo Linux and a cross compiler (from a British company, the name of which I can't remember right now) on porting Apache (of all things...) on a MIPS/RISC board.
I have to say I was fairly underwhelmed by the whole experience and the quality of linux-related knowledge and support out there.
Mind you that was 3 years ago.

Re:Well. I'm not too surprised..

[beguyld]

I did the same thing, in about the same time frame, with similar results. Seemed to me that there was not enough money being made by Lineo (or the competitors we researched) to deliver the quality of support someone might want. I had to pretty much figure everything out myself, from the source code. They were not much help. Their utiltity to build a custom kernel was somewhat useful, and that is all.

From a business standpoint, it's not clear that having the source is worth more than having the support, and paying more up front or per unit. Depends on the project. It would have to be a low cost and high volume product to be worth using Linux I think. Or I would have to have more time than money...

Maybe over time things will get better, but for embedded systems, the key thing is stability, not more and more features. And if it got really stable, then the core OS would be free to everyone to use, and then how much support would you need? The embedded Linux tools biz does seem like a tough business to be in.

No wonder he said this...

[PlanetX 00]

He is from GreenHills software look at all of their OS offerings and you know why he is saying this. Linux is eroding his bottom line.

Well

[DAldredge]

So let me get this straight, a person who sells a competing product says that a less expensive product is not as good as the one he makes.

I also love there support for Native Win32 processors as you can see on this page. http://www.ghs.com/products/rtos/threadx.html

Re:Well

[sik0fewl]

Yes, it's really disappointing that they don't support the Intel architecture.

Oh well, I guess I'll go with Linux, I know it runs on the Intel architecture.

Re:Well

[Anonymous Coward]

There -- As in "There are"; Their -- As in "They have gum in their hair"; They're -- As in "They're doing this and that".

Re:Well

[dasmegabyte]

So let me get this straight. A person who works in the embedded market makes a comment on the embedded market and he's automatically wrong because he works in the embedded market?

Is it at all likely that the guy has worked with Linux himself and had it turn out badly? Or that his customers have come to him with cobbed solutions based on Linux? Is it possible he wanted to support Linux, but found so little quality development in his segment that he realized he'd be doing most of the work himself, AND have to support a community, AND not be able to make as much money off of the work?

The party line is that Open Source is always better than proprietary software. And in some case I've found that to be true (apache, blender, bsd, firebird). In other cases, I've found Open Source solutions to be sorely lacking when compared to their proprietary competitors (bind vs djbdns, sendmail vs qmail, Gnome or KDE vs OSX ;). In those areas where Open Source isn't ready, I support and suggest to my clients non-Open solutions. Why? Because they work better. Which means my clients come back. They don't come back if I suggest something that's complete, insecure, hard to use shit, but has FSF approval. That kind of brainless advocacy would make me look bad.

Look, I'm not saying this guy isn't a sleaze trying to sell his own products. But he doesn't mention them in this article...and he's not the only guy who sells products in the embedded market. He's saying that, in general, Linux isn't there yet, and he's as much in a position to say that empirically as he is to benefit off saying it without basis. What, can a market analysis only be true if it comes out of Stallman's mouth?

Re:Well

[DAldredge]

I did not pass judegement on his article, I just pointed out he was coming from a slanted position.

However, the website could use a editor/proofreader.

Re:Well

[bit01]

What, can a market analysis only be true if it comes out of Stallman's mouth?

Short answer? Yes. People have become far too innured to commercial propaganda masquerading as commentary. That's all it is. Propaganda. Selective quoting and sometimes complete untruths. The vast majority of commentary from industry "leaders" (90+%) is just self-serving crap with no attempt at balance. Generally, journalists are a little more objective though many are just marketting front men. At least Stallman thinks a little more deeply than most "commentators".

More specifically: I've used both Greenhills VxWorks and Linux on major projects. Linux leaves VxWorks for dead simply because it is open source. While Linux doesn't have the polish and finish of VxWorks the per-copy licensing of VxWorks and the need to deal with buggy, unfixable closed source binaries is a major pain that now puts in the bin as far as I'm concerned.

Their support is also a joke as well. They have a support website with login restrictions that make it impossible for a large company to use effectively. Why they need login restrictions for support of their own product is beyond me. And when you get in you find it's just a disorganised collection of essays, a minimum of downloads, a poor search engine and a completely useless support team - while they respond to emails they don't actually do anything useful, just do the search for related material that you've already done yourself. Heaven help you if you actually need any code fixed or changed - it'll take months.

More generally: I've been on the client end of dozens of different software support contracts while employed by large companies. Almost without exception they cost a bomb, provide a minimum of service, are completely inflexible, always assume a problem is your fault not theirs and have multi-month turn-around times. That experience has pushed me firmly into the open-source camp. Closed source software after-sales support is vastly overrated and I have the experience to prove it.

While your general point (closed source is sometimes a better option than open source) is of course true, it's true much less often than most commentary implies. Of the examples you gave I would say only OSX is the only potentially better closed source solution and that depends on the client. For all the others open source is better. For me, interroperability with existing software or hardware is pretty much the only reason left to get closed source.

---

It's wrong that an intellectual property creator should not be rewarded for their work.
It's equally wrong that an IP creator should be rewarded too many times for the one piece of work, for exactly the same reasons.
Reform IP law and stop the M$/RIAA/MPAA abuse.

Re:Well

[Drawkcab]

Maybe you've worked with it, but VxWorks isn't a Green Hills operating system, its an operating system by Wind Rivers, so your criticism is misplaced. It is possible to use Green Hills tools with VxWorks, but its equally possible to use Green Hills tools with Linux.

Re:Well

[bit01]

Sorry, thanks for the correction.

The systems I was thinking of were using WindRiver VxWorks and GreenHill Systems AdaMulti. The comments about support apply more-or-less to both.

Re:Well

[bit01]

Ah, not my day.

Green Hills Software, Inc.

Re:Well

[Senjutsu]

So let me get this straight. A person who works in the embedded market makes a comment on the embedded market and he's automatically wrong because he works in the embedded market?

No, his opinions are simply automatically untrustworthy because, as the president and CEO of a company that sells its own RTOS, he has a significant personal, professional, and financial stake in pushing a particular viewpoint (linux bad, my product good), and therefore has significant incentive to paint as distorted a picture of the market as is necessary to make his product look best. He's too damn close to the subject for any but the must gullible of rubes to consider him even remotely objective.

Look, I won't take advice on Buddhism from the Pope, I won't take advice on Linux from Bill Gates, and I won't take advice on non-FSF software from RMS, so I'm damn sure not going to take advice on RTOSes from this guy. What's so hard to understand about that?

Or...

[nonmaskable]

...perhaps Green Hills Software (Dan O'Dowd's company) has an axe to grind and came up with this agitprop.

Come on editors - at least point out the conflict of interest!

Your application has to need Linux.

[HotNeedleOfInquiry]

To throw Linux at any and all embedded applications is a big mistake. Unless you need stuff like multiple TCP/IP servers and multitasking, you are better off with a smaller OS. There are millions of DOS-based controllers out there that won't be replaced with Linux anytime soon because they are cheaper than the hardware needed to support Linux. Likewise, PIC controllers can do things cheaper than DOS controllers for trivial tasks.

There is no one-size-fits-all in the embedded controller market. Linux has it's niche, but it can't fit everywhere.

Re:Your application has to need Linux.

[Apreche]

http://tron.um.u-tokyo.ac.jp/TRON/ITRON/home-e.htm l

Itron, the #1 operating system in the world. Untouchable in the embedded world. Linux is nice because it makes interoperability with the desktop smooth if you have the same OS on both. But in terms of quality ITRON is #1 for a reason other than marketing (which is the reason Windows is #1).

Re:Your application has to need Linux.

[-tji]

But, Linux is not one single entity...

For the very small scale devices you mention, uClinux (microcrontroller linux) is probably more appropriate.

uClinux is used in everything from modems to DVD players.

Re:Your application has to need Linux.

[johnnyb]

Is ITRON a standard or an implementation? It looks just like a standard from the web site.

Re:Your application has to need Linux.

[Anonymous Coward]

"For the very small scale devices you mention..."

I'm not sure why, but part of me hopes that I'll never see Linux running on a PIC.

Re:Your application has to need Linux.

[Anonymous Coward]

I'm not sure why, but part of me hopes that I'll never see Linux running on a PIC.

The PIC is a despicable architecture. It's so ugly it physically hurts me to think about having to write in assembly for it. Seeing Linux on a PIC would have one bright side: there'd be a decent fucking C compiler that can target the PICs.

The entire microcontroller world is crying out for a decent uC programming model. There's a niche there if anyone wanted to fill it.

Re:Your application has to need Linux.

[jared_hanson]

I've heard about this TRON embedded OS and have spent some time looking over the materials you linked to on the site. My interest is piqued, but I am confused.

Is there any implementation of this that I can download and play around with? Preferrably something that runs on x86, but some cheap dev board would do. I see the link to the ItIts project, or whatever it is called, but I can't read Japanese so it doesn't help me too much.

Re:Your application has to need Linux.

[macshit]

Is ITRON a standard or an implementation? It looks just like a standard from the web site.

I'm not sure of the status of the original itron, but recently there's a GPL rewrite of itron called TOPPERS:

http://www.toppers.jp/

(sorry, japanese, but maybe you can find a download there somewhere...)

Re:Your application has to need Linux.

[kinnell]

I think the big mistake is that people keep talking about "the embedded market" as if it's sensible to lump a DVD player, a heart monitor and a fly-by-wire system into the same one-size-fits-all category.

Microsoft has a big lead in embedded too

[MrDigital]

With both Windows CE for small applications and Windows XP Embedded for more demanding apps, Microsoft has been making a strong push for what's an extremely hot market. With everything getting smaller and smaller embedded OS's are going to be far more important.

It's not free but the developer tools for embedded Windows devices are extremely similar to those normal Windows, so developers have less of a hard time migrating.

Re:Microsoft has a big lead in embedded too

[codepunk]

Oh yea just like when blaster hit us and our machinery quit working becase CE go smoked by it. Yep sounds like perhaps we should use xp or ce in medical equipment as well....

Re:Microsoft has a big lead in embedded too

[Anonymous Coward]

To bad they don't really understand the embedded market. Both of the OS's you mention force the hardware and application to be designed to them, not the other way around.

Re:Microsoft has a big lead in embedded too

[Anonymous Coward]

... parent is obviously a troll.

The CE dev tools are no match to gcc-3.3.x crosses in codegen for arm, powerpc, and x86.

Getting beat by free tools..... too funny.

Re:Microsoft has a big lead in embedded too

[Anonymous Coward]

CE isn't designed for use in medical equipment. But it makes a great car computer, or a set top box, or a video game OS (Dreamcast), or anything else where rapid development time, ease of use, and lots of built in features come in handy.

You get an SQL server, media player, lots of drivers, web browser, and all kinds of functionality for quick dev. And its a hard RTOS. If you're making the next set-top box you're set.

Re:Microsoft has a big lead in embedded too

[Anonymous Coward]

Yes. I see their blue screens everywhere.

He's biased, his company sells an embedded OS

[Anonymous Coward]

Go to his company's web site (search google
for Green Hills Software) and you'll see that
they make an embedded real time OS. He's hardly
an objective reporter. This is basically an
ad for his company disguised as an editorial.
Not to say that his arguments are wrong but
take everything he says with a grain of salt.

Re:He's biased, his company sells an embedded OS

[Anonymous Coward]

Not only that, do a traceroute on his website and DNS servers. There in India.

Re:He's biased, his company sells an embedded OS

[Anonymous Coward]

Um... No they're not. Try it again. They're all in the US

Re:He's biased, his company sells an embedded OS

[Anonymous Coward]

hehehe, I now own a little peice of your time.

Reliable unbiased article, not !

[polyp2000]

The guy that wrote the article...

Dan O'Dowd is President and chief executive officer of Green Hills Software,Inc. (Santa Barbara, Calif.)

Green Hills Software

Green Hills Software are a large RTOS manufacturer, so of course he is going to say that. Whether or not his statements are true or not I find it difficult to believe someone whose business relies on their own Proprietary OS.

They also have a not dissimilar marketing bumpf on their website

our product is so much better than everyone elses!

nick ...

Re:Reliable unbiased article, not !

[EulerX07]

From that page : "Microsoft Windows, MacOS, Unix, and Linux often crash, lock up, or go crazy."

Woah, these guys would have a field day on slashdot fighting all the zealots from all the sides simultaneously.

One thing that they do not mention in their little glorification, it's that these OS have to support thousands of devices, poorly written drivers, 3d graphic cards in conjonction with directx/opengl, run that recently released game that is really cool, and more.

I'm pretty sure any of those systems would be rock solid if they stripped EVERYTHING out of them.

Re:Reliable unbiased article, not !

[Kaishaku255]

Worst of all, we use Multi (GHS's development tool) for our embedded projects. It has some quirky behaviour of it's own. So it is hard to swallow his words of quality in commercial tools.

Still he raises some interesting points, but is it valid to say Linux won't work? Not really.

IMHO, the use of any OS for embedded projects should not be arbitrary (he seems to think that is how it is decided). Linux is a perfectly valid embedded OS if your project requires much of the kernel's functionality. It is equally bad to say embedded Linux projects won't work as to say you should only develop for an embedded Linux system.

Pure Fallacy!

Re:Reliable unbiased article, not !

[RevAaron]

I was reading that page, and can't help but wonder- what the hell does "go crazy" mean in context of one of those OSes? When the user fucks up, and the system doesn't work as they wanted it to because they did something wrong? They use the phrase "go crazy" a handful of times.

Real-time, embedded OSes are a world apart from MacOS, Windows, Unix and Linux. You don't use those OSes for most RT applications, but that is good. You should use the right tool for the job.

But even if you took Linux, Mac OS, or Windows 9x/NT and had solid hardware and solid drivers, deleted the services, subsystems, and other components you didn't need (remember that 4 MB Windows 95 install?), you would still end up with an OS that was no where near real-time and still very crashy compared to a real-time system. It'd be more solid than it was before, but still not perfect.

I have no idea whether its right...

[tkrotchko]

I know little about embedded OS's, but the article is a bit self-serving in that the author, Dan O'Dowd is president and CEO of Green Hills Software, (http://www.ghs.com) that makes "Integrity", an ...you guessed it... embedded OS.

Take a look. http://www.ghs.com/products/safety_critical/integr ity-do-178b.html

So while he may be right, the information is coming from the wrong person to be trustworthy.

I think Dan needs to hire a PR flak.

Re:I have no idea whether its right...

[skink1100]

It's not that he's completely wrong, but he is assuming worst-case scenario in every case. For example, he asserts that community support is inadequate because so many embedded ports exist. I assert, however, that support can be quite excellent. Three or four years ago I did some embedded development on the StrongARM variant of arm-linux, and the community was extremely helpful and responsive.

Just because a potential solution CAN be difficult doesn't mean it will be. As an earlier author said, there are appropriate solutions for every project, and they vary according to the requirements.

S

Where are the Linux devices?

[NineNine]

That's great that Taco included the link to Linuxdevices.com, but I went to look, and they were mostly stupid consumer gee-whiz gadgets, or some Net tool (ie: router). What IT people don't seem to understand is that there are many, mayn industries out there that dwarf the IT industry. "Embedded" OS's can be used in all kinds of devices in all kinds of industries. I didn't see a single manufacturing tool using Linux as an embedded OS, for example. So other than the "this is neat, we're using Linux" devices, where are these real world applications?

Re:Where are the Linux devices?

[WatertonMan]

This is a good point. And I don't just think in the big corporate embedded systems. How about some lowend consumer grade automated routers or cutters? I know lots of people with home woodshops who'd love that. There are lots of little markets like that where Linux could do great.

Of course everyone wants the bigger companies, but I think if they could demo products outside of traditional geek tools they could really generate more interest for bigger companies.

Re:Where are the Linux devices?

[RevAaron]

What else would you expect to be listed at LinuxDevices.com?

Most of the "embedded" Linux devices are the bigger, more powerful things like you mention- PDAs, routers, kiosks, etc. Linux couldn't run on a lot of the hardware in a lot of other "embedded" operations without running ELKS or uClinux. For instance- Linux plus the Qtopia GUI on my Zaurus C760 takes up a whopping 18 MB on boot- absolutely gigantic compared to the 2-4 MB of WinCE or something even less on PalmOS.

I too would be interested in finding out about in-use embedded Linux setups, working in 0.5-4 MB of RAM.

Re:Where are the Linux devices?

[mrjatsun]

1) TIVO
2) Stuff I work on that I can't tell you about
3) that video player that mplayer is claiming they
stole their code.
4) lots of other stuff

When's the last time you wondered what OS your digital answering machine or VCR uses. The nature of an embedded OS is that, for the most part as an end customer, you don't know, and you don't care...

Re:Where are the Linux devices?

[Anonymous Coward]

Devices which can run embedded linux are everywhere - just go order a cheeseburger.

Oh, sorry. That's running an embedded unixware.

Re:Where are the Linux devices?

[Anonymous Coward]

If you look around on EETimes and other journals; and as anyone familiar with the industry is aware; a lot of new business for RTOS vendors (probably Dan too) come from people switching FROM linux. How amusing.

Re:Where are the Linux devices?

[NineNine]

lots of other stuff

Well between "lots of other stuff", and the Tivo, you've got a good opposing article. Answering machines, VCR's... sure. I have no idea what OS's they run, but I didn't see them on "Linuxdevices". What I saw on there were a bunch of very niche market geek things (like the Tivo), that aren't even a blip on the embedded industry because they have such tiny markets. Now show me, say, a company building CNC machines running Linux, or say, digital alarm clocks made by GE running Linux, or Toyota cars running Linux, and I'd say you have a case. The Tivo abd "other stuff" pretty much doesn't say much.

Re:Where are the Linux devices?

[imroy]

I think I can answer this very well. I just happen to have recently been looking around for lower-power embedded controllers, preferably running Linux. On linuxdevices.com go click on their "products" link at the top of their page. Those pages contain short blurbs from announcements. Just go looking for boards and don't overlook the little "more..." link at the bottom of the page. There's pages of announcements, but they're not all for boards.

Here's some boards that have piqued my interest:

• Axotec Phoenix-SBC-500/520 and Phoenix-ECM
• Strategic Test has some interesting embedded systems in a DIMM-module format.
• Technologic Systems TS-5300 and TS-5400, among others.
• Simtec has some StrongARM-based boards.
• A Canadian company with a MIPS-II-compatible set-top style box

Re:Where are the Linux devices?

[Anonymous Coward]

Why would linux be 'great' when compared to a commercial embedded system. They're usually had from one to two dollars per unit. Sometimes 4 or 5 depending on the features. If you're buying a low end automated consumer grade cutter it's still going to cost several hundred bucks or more. If the embedded tool saves you a month or so of development time its worth it to pass a few bucks on to the consumer.

I mean, a 400 dollar router, and a 404 dollar router isn't going to make much of a difference in the consumer's eyes. Esp if you can cram more features in less time on the 404 router.

Re:Where are the Linux devices?

[Anonymous Coward]

2) Stuff I work on that I can't tell you about

I see. So which SCO product are we talking about? :-)

Re:Where are the Linux devices?

[WatertonMan]

The difference is in customizability. A linux open source router software could be customized.

Re:Where are the Linux devices?

[Anonymous Coward]

Well the customizability will be great when you're getting killed in time to market.

Re:Where are the Linux devices?

[Tim C]

By a woodworker? You may be a programmer, and I know I am, but the vast majority of people aren't, and don't want to be.

Re:Where are the Linux devices?

[Anonymous Coward]

Yea...and Microsoft dosen't have an embedded OS.....

yuo is teh smrt!

Re:Where are the Linux devices?

[NineNine]

AC troll... what does MS have to do with anything?

He's not just a competitor, he's the President

[Anonymous Coward]

The author of this "article" is the president and CEO of a company that sells a proprietary embedded Real-Time Operating System.

No

[glenrm]

Embedded Linux Tools Market a Myth? No. When I read that Wind Rivers was looking into Linux you knew which way things were going.

Rio Karma runs Redhat's ecos and kicks butt

[linuxguy]

I sold my iPod and bought a Rio Karma. Finally
after 5 mp3 players I have one that I think I will
keep for a while.

I am not going to do a review here as there are
plenty of good reviews of this product on the web
that google will help you find.

However to me this truly remarkable embedded
device based on a free OS says a lot.

Excellent. Somone found her.

[Anonymous Coward]

Rhonda... troublemakers don't prosper...

Oracle telling us what we need to hear

[Anonymous Coward]

I read an article by someone a while ago, berating the Linux-as-server market. The writed explained that Linux is not ever going to happen because of x and y and z. It pissed me off, and i wanted to prove him wrong. A year later, every shop I'd worked in (and have worked in since) uses Linux in some form or another. Thinking about this, and the article, it seems to me that he's taunting us, and forcing those in the embedded Linux RTOS market to leave no doubt.

This is Industrial Flamebait.

[torpor]

Move along.

I work in embedded systems in Germany, and there is -plenty- of linux going on ... lots and lots.

Linux levels the playing field in grand new ways, even for the embedded folks, even for the snooty ones.

Dan will eat crow.

Re:This is Industrial Flamebait.

[mpe]

Linux levels the playing field in grand new ways, even for the embedded folks, even for the snooty ones.

The last thing companies who are doing fairly well out of proprietary software want is a level playing field. Especially if it means they have to work hard to gain and retain ("lock ins" are rather more difficult with OSS) customers.

Re:This is Industrial Flamebait.

[torpor]

cool, coz lockin is really old-school.

Re:This is Industrial Flamebait.

[Anonymous Coward]

Even for the snooty ones? Hear, hear.

Strange, I work in embedded systems in Germany too, and there is -almost nothing- of linux going on.

I do projects in telecom, automotive and industrial automation applications for about 15 years now, mostly for, ehm.., let's say well known corporations. Vxworks and QNX are dominant, then there's PSOS, Nucleus and others, sometimes even small systems like eCos and RTEMS are used. Embedded Linux isn't even considered right now at the companies I work. I doubt you can find one Linux project in twenty for these applications and I would not at all be surprised if the ratio is even worse than 1:50. The problem is not so much the OS but the missing infrastructure. Frankly, I wonder whether people touting embedded linux really do know what they're talking about.

Linux levels the playing field in grand new ways? Yeah sure, in a few years maybe, but not now. Dream on.

Processor support and realtime

[fatwreckfan]

"For embedded use, Linux must be ported to appropriate processors and modified to work in diskless, resource constrained, and custom hardware environments. Real-time performance capabilities are also often required."

Sweet jesus no! Not different processor architecures! Apparently this guy hasn't heard of Debian.

And real-time capabilities? How about the Real-time Application Interface

This guy simply sounds like he has a grudge against GNU and Linux.

Re:Processor support and realtime

[The Bungi]

Sweet jesus no! Not different processor architecures! Apparently this guy hasn't heard of Debian.

The embedded market is full of wacky microprocessors made by companies you've never heard of, with wildly different clock speeds, alignments and memory and I/O interfaces. These are chosen by device makers and integrators based on their needs, and then put into things other than desktop PCs and PDAs. Your ridiculous snide remark aside, I suggest you at least Google a bit before posting. That will help you understand what it is the article is talking about. The Debian ports collection indeed.

This guy simply sounds like he has a grudge against GNU and Linux

He has a differing opinion from the slashbot group think, so I guess that makes him evil. "Oh look, he's criticizing Linux!!! let's kill him!!".

And the fact that he runs a company that makes an embedded OS is besides the point - it's made clear in the article and gives him credibility to talk about the subject. You're more than welcome to disagree, assuming you understand the subject to begin with.

Re:Processor support and realtime

[Anonymous Coward]

Tell me how to run Debian without a disk and I'll give you a cookie.

Re:Processor support and realtime

[Svartalf]

In actuality... Anyone considering the use of most of the RTOS choices out there are typically looking at one of the following CPUs:

x86
PPC
ARM
MIPS
Coldfire
DragonBall

The goof-ball stuff usually ends up using the roll-your-own stuff and is not typically used in most contexts because you have to find silicon, find tools to begin with (since it's custom, there's no standard tools- uh, gee whiz, what do you know, you have to build tools, just like he said...), and you have to certify the operation of the damn thing.

It's simpler and easier to use an off the shelf part from one of the usual suspects than to use something else.

Now, having said this, you've got choices, depending on what you want to do because you've got standard tools and standard operating system choices...

VxWorks
QNX
Lynx
pSOS
RTEMS
eCos
Linux

Of the aforementioned, the licensing on the last three are very attractive and depending on what you're trying to do, you really want to use them instead of the others.

The article from the author in question is guilty of lying by omission of key facts in the embedded systems industry. He's right about all of it. But what he doesn't tell you is that for most everything done, you're either not using an OS and using something like a PIC, Z8, or Z80 or you're using a more robust CPU with an OS and much more memory- something that Linux, RTEMS, and eCos do well with on most counts for embedded systems. IF you know what you're doing in the first place- you have do design your code for read-only conditions, etc. in the first place and most of Linux is happy fine with it. I know, I DO embedded Linux stuff. Real time? Don't need it all that often- most embedded devices just need memory and resource management, they don't need rate monotonic scheduling of tasks, etc. Real time is actually bandied about far more than is really, really needed- and worse yet, it's more defined by the box you draw around things. Throw enough CPU and memory Muscle at something and even Desktop or Server NT can be "real time" for the purposes of the definition.

Re:Processor support and realtime

[Anonymous Coward]

You mean like this?

Come on, a 10s google.

This is a marketing white paper

[dtidrow]

The author of this 'article' is the president of a company that sells embedded RTOS's and related tool - therefore, he's biased to begin with. Most likely, he sees his company's market being deeply penetrated by Linux and is trying to stop the erosion with this article.

I'm using embedded Linux right now

[Helmholtz Coil]

Good thing I read the article, now I know to drop the last two years' worth of work and get a "real" OS!

Sarcasm aside, while I could maybe grant that there isn't a very large market in commercial compilers for Linux in the embedded space, there is definitely a market for Linux itself in the embedded space.

I just finished a proof of concept project in December. Now that we're moving towards a commercial system, we're looking to reduce power draw and size. Because we're using Linux, I can switch to a different SBC with a different processor and architecture without too much trouble (the compiler toolset was provided by the SBC manufacturer, basically just a cross-compiling GCC).

My application isn't a real-time system, so I can't comment on whether Linux is applicable as a real-time OS, but on the other hand I need to be able to resolve time on the nanosecond scale, and Linux/GCC does that just fine. So despite the article I think I'll stick with what works for me.

Re:I'm using embedded Linux right now

[devphaeton]

Sarcasm aside, while I could maybe grant that there isn't a very large market in commercial compilers for Linux in the embedded space, there is definitely a market for Linux itself in the embedded space.

but would you say that the linux embedded market is increasing or will increase? I don't know exactly what a lot of embedded stuff runs, but i assume a real small bare-bones OS as a controller that's not much more than a fancy 64K asm program?

As stuff is expected to become more "intelligent", will we see more linux embedded stuff (or netbsd for that matter)?

Re:I'm using embedded Linux right now

[barawn]

My application isn't a real-time system, so I can't comment on whether Linux is applicable as a real-time OS, but on the other hand I need to be able to resolve time on the nanosecond scale, and Linux/GCC does that just fine. So despite the article I think I'll stick with what works for me.

Realtime performance means fast interrupt servicing, and this is the part I don't understand: uClinux gives interrupt latencies of about 10-40 microseconds to the top half of the interrupt handler, about 50-100 microseconds to the bottom half of the interrupt handler, and about 300 microseconds from interrupt -> data read if the bottom half is putting data through the I/O and another process is reading it. That's on a 66MHz system - so it's about a thousand clock cycles or so to the top half. That's not bad. Granted, other RTOSs are better - I've also used Microware's OS-9000, and that's got an interrupt service latency in the tens of microseconds, and that's even after using system events to signal another process. So that's really quite good. But depending on what you need, I can't see how uClinux could really hurt you that much. If you desparately need speed, try to put as much as you can in the top half, and you should get quite good performance. (Plus I think there are other ways to get the latency down, but I've never bothered, as it's never been important)

Plus having the source is incredibly helpful. You can actually figure out what the heck is going on in certain cases without wasting days upon days trying to talk to crappy customer support for commercial RTOSes. Ugh. Maybe if the project I work with had infinite money, sure, but...

Re:I'm using embedded Linux right now

[Anonymous Coward]

Try working on embedded control where that interrupt comes up every 10 microseconds and needs to be serviced more or less immediately so that you don't wind up with frequency skew and all the fun that goes with that.

Then again, my "RTOS" that operates the entire control system runs about 1500 lines, including serial command-interpreter code.

Linux is *not* good for hard realtime, very small devices. But if you need TCP/IP, graphics, etc, it's great!

Re:I'm using embedded Linux right now

[Anonymous Coward]

Sarcasm aside, while I could maybe grant that there isn't a very large market in commercial compilers for Linux in the embedded space, there is definitely a market for Linux itself in the embedded space.

This is the crux of the issue: indeed, with recent kernel and gcc releases getting better and better performance-wise, and staying the same price-wise (free), there is less of a market for competing, proprietary compilers and kernels.

I would love to see a codegen analysis between gcc-3.3.x and green hills on powerpc, x86, and arm. I doubt very seriously that green hills is able to keep up.

Also, I doubt their toolchain can compare on standards-compliance (C/C++).

The free stuff is just too good. The lower-level proprietary compilers and kernels cannot compete, and have to get out of the business.

Interestingly, as the free tools become better and better, they get even better, faster. More people use them, and more people fix the bugs and tweak for performance.

In a couple of years I think Green Hills will have to move over to supporting the free software systems, like Montavista and Wind River.

Re:I'm using embedded Linux right now

[Anonymous Coward]

Do you know if eCos can do hard real-time? Or how it compares to linux kernels in this respect?

What are the free options for hard real-time?

Re:I'm using embedded Linux right now

[Svartalf]

Realtime performance acutally means having very specific and guaranteed worst-case interrupt servicing and task scheduling that is fast as well.

Draw a big enough box around the problem and even stock Windows can be "real time".

Re:I'm using embedded Linux right now

[neomorph]

On PowerPC, GHS kills gcc, on x86, the Intel compiler beats gcc pretty well, and on ARM, both GHS and ARM Ltd. absolutely kill gcc, by 20-30% in most cases.

There's a lot of good compilers out there. gcc is just the lowest common denominator. Hey, you get what you pay for.

That's funny about Montavista and Wind River. Both companies are losing money hand over fist.

Re:I'm using embedded Linux right now

[robslimo]

Do you know if eCos can do hard real-time? Or how it compares to linux kernels in this respect?

What are the free options for hard real-time?

I don't know about eCos, but hard realtime for Linux can be had using RTLinux.

It is a sort of kernel that lies between the hardware and the real Linux kernel. It has its own API for the hard realtime functions and leaves the Linux kernel API alone.

Re:I'm using embedded Linux right now

[Anonymous Coward]

Realtime performance means fast interrupt servicing,...

Nope. Real-time is all about repeatable timing. The system can never, ever take too long to respond. A repeatable engine controller that's burning 99.9% of the available CPU cycles is acceptable. An engine controller that is half a revolution late once in the lifetime of the engine is a total loss.

Re:I'm using embedded Linux right now

[Anonymous Coward]

RTLinux can't provide acceptable performance for high-frequency control systems. Not much can, though. Which is why many of them are still done in OS-less setups.

Also, RTLinux is just another RTOS that allows a modified Linux to run on top of it. It does NOT make Linux a RTOS, it just lets Linux run on top of and get some access to a RTOS. Sort of VMWare, for embedded solutions.

Re:I'm using embedded Linux right now

[SylvesterTheCat]

Realtime performance means fast interrupt servicing

No... not necessarily.
Real-time is about predictability, not speed. More precisely, hard real-time is about absolutely, positively meeting deadlines.

A real-time system could have as a hard deadline a periodic task which must be completed no later than 24 hours from start.

While that is rarely the case, the correct definition does allow for this.

Re:I'm using embedded Linux right now

[Helmholtz Coil]

From reading what others are doing I tend to think that there are two markets for embedded devices, and I think Linux won't be able to make much of a dent in one (at least for now) but will come to rule the other.

In embedded systems like traffic lights, I don't think that Linux will be able to make much inroads. To me that's along the lines of the embedded app you mention-bare bones OS, running a pretty tight control system, doesn't necessarily need some or all of the niceties Linux can offer. For now-it could be five, ten years from now that somebody does come up with the need.

The other market is more like what I'm doing-there what you're really doing is miniaturizing a full-fledged PC. Similar to internet appliances, those fancy new photocopiers, etc. In this kind of market Linux really shines because (in my experience anyway) you'd be surprised how often you think you've figured out everything you need only in six months to say "wouldn't it be great if..." And Linux has you covered.

Anyway, my personal experience is that manufacturers for embedded hardware that hadn't heard of Linux three years ago now have at least rudimentary support for it. Even over the past year I've noticed a rapid uptake of Linux support-there must be a lot of us clamoring for it. :)

Re:I'm using embedded Linux right now

[Howlett]

> Realtime performance means fast interrupt servicing

Sorry, but I think you are mistaken on this one. "Realtime" OS's have nothing to do with serviceing interrupts in "Real Time". The primary concern with a real time OS is that the absolute worst case interrupt latency is known in advance. Raw performance is not usually the limiting factor in these designs, worst case performance is always what is considered.

[OT] Good

[Anonymous Coward]

The legendary internet site, goatse.cx, has been suspended by the registrar as a result of public complaints. Copies of the complaints are available as PDF at the aforementioned site.

Good.

No kidding

[JoeBuck]

EE Times regularly gives space to marketing droids to flog their stuff, and regular readers know how to distinguish these marketing puff pieces from the very good stuff that the full-time staff writes.

If someone at one of the embedded Linux companies asks, EE Times will probably be happy to give them equivalent space next week to answer.

Re:No kidding

[robslimo]

As a regular EETimes reader, I have to agree with your post.

And... as a developer of and for embedded systems since 1986, I have a little insight on the issue. For the record, we use a proprietary OS in our (1) deeply embedded systems, ROM-DOS on some (2) lightweight PC platform embedded systems and Windows 2000+ on (3) MMI (Man Machine Interface) systems.

We have investigated using RTLinux in the first 2 cases and found the footprint/overhead to be far too great for item (1).

For item (2), we're not sure. The overhead and learning curve have kept us away for the time being, though we're interested in the capability advantage over ROM-DOS. Two very nice things about ROM-DOS: It can have a _very_ small footprint (as little as about 4K to 6K in ROM IIRC) and it's only $25 per runtime license (at least at our negotiated quantities).

For item 3 (yeah I know, it's not really an embedded system) we would love to use Linux (not necessarily RTLinux), but our customers demand Windows workability (desktop apps, Excel, Access, Oracle databases, etc).

So, in our outfit, we only use Linux (Red Hat) for a file server with Samba (to avoid a Windows Server license).

Re:No kidding

[robslimo]

Whoops!

On the ROM-DOS footprint, the 4K to 6K is for the mini-BIOS. The ROM-DOS min size is probably more like 30 to 40K, depending on options.

Re:No kidding

[RevAaron]

I think one of the problems is that a lot of folks who haven't done any embedded systems programming think that 16 MB is a small amount of RAM. Sure, it is a small amount of RAM on a desktop running Linux or Windows, but on a high-volume embedded system it's a ton. An "embedded" Linux system like the Sharp Zaurus SL-C760 may seem light because it's using 18 MB after the kernel and Qtopia are started up, but in the world of embedded (and PDAs), that is a huge footprint.

Re:No kidding

[t0ny]

Maybe Dan should check out the success stories at LinuxDevices.com or perhaps try a more traditional embedded OS that also happens to be Free."

So once again, the Linux community ignores constructive criticism by somebody in the real world, and just pedals excuses and anecdotes to make themselves feel better.

Oh well, I guess its easier making excuses than actually doing the work to improve things. If Linux ever went mainstream, people would just flood over to whatever other 'alternative' OS they could, anyway. They are just trying to show the world how interesting they *really* are by doing things different than everyone else. Its a sad little man who needs an operating system, web browser, or other program to define himself as a person.

Re:No kidding

[Anonymous Coward]

Its a sad little man who needs an operating system, web browser, or other program to define himself as a person.

Every time I read this sentence here, it was posted by you, t0ny. Is this some kind of obsession or something? I'm just asking, because I'm concerned about you.

"The red or the blue pill? Err, I swallowed the whole package!"

Re:No kidding

[Anonymous Coward]

Its just that he's a sadder little man who needs to be negative and snide about others overexuberance and excitement about the possibilities of an operating system, web browser, or other program to define himself as a person.

Re:No kidding

[Anonymous Coward]

Yes, those were my thoughts. I wish we could do something to make this sad soul happy again. He's desperately trying to make his mediocrity appear superior by attacking straw men he built himself.

Re:No kidding

[Anonymous Coward]

The problem is that there's actually three types of embedded systems - resource starved, resource constrained, and resource abundant.

Three decades ago, these types formed a continuum - there was little difference between the largest "resource starved" system and the smallest "resource constrained" system, with a similar blurring at the border of constrained/abundant systems.

Over the years, though, gaps have appeared and expanded between these categories of systems. "Resource starved" systems haven't changed much - they're still at the low end of the spectrum, in terms of system resources like processing power and memory. On the other hand, "resource constrained" and "resource abundant" systems have seen components that provide more significant system resources showing up on the market at roughly the same price point as in previoud years.

For "constrained" and "abundant" systems, the "minimum spec" hardware you can purchase for $X or $Y keeps getting more and more impressive. In fact, there's no reason to go fore something less powerful than the least powerful comodity on the market, because then you get into custom fabrication costs. At that point it's cheaper to buy 4MB of COTS flash storage than it is to buy custom-made flash storage that's just large enough for your device.

Anyone who's bought a hard disk in the past two years can probably identify with this... we've reached a point where the cheapest hard disk you can find is probably around $70. 2 years ago, that would get you a 20 gig disk. 1 year ago, a 40 gig disk. Today, an 80 gig disk... and you'd be hard pressed to find a COTS disk that is cheaper. All other things being equal, you would have to be nuts to buy an older model with less storage capacity for the same price as.

You can make similar comparisons for memory and static storage - for a constant price, as years have gone by, you're capable of getting increasingly more for your money, and the capacity provided what constitutes the constant cost "low end" of the spectrum is generally increasing each year.

Where does that leave everything? Well, in today's market, I'd hazzard a guess that you have:

• Resource starved systems using 8-bit CPUs, less than 4MB of memory and less than 4MB of permanent storage. These are the classic "embedded systems".
• Resource constrained systems using 16-bit or 32-bit CPUs, between 8MB and 64MB of memory and less than 1GB of permanent storage. These are "set top box" devices.
• Resource abundant systems, with 32-bit or 64-bit CPUS (potentially even SMP), with the potential of multiple GB of memory and hundreds of GB of permanent storage. These are "turn a desktop into a manufacturing control unit" type of devices.

As time goes by, these gaps will continue to widen. In two years, a low-end "constrained" system might have 64MB of memory and half a gig of permanent storage, and a low end "abundant" system might be have 2GB of memory and a 200GB hard disk.

While Linux will probably never move into the "resource starved" embedded system space, it has already moved into the other two spaces. As Linux gains more and more RTOS capabilities in the stock kernel, you'll see it's usage in the resource constrained and abundant spaces start to spread from soft real-time into hard real-time applications.

Re:No kidding

[Anonymous Coward]

Yes, Im a sad little man who keeps replying to myself.

The only thing worse than a total fuckhead like myself is a total fuckhead like myself, talking to myself.

PS. Im gay

Re:No kidding

[t0ny]

Ya, that was just what I was thinking.

BTW, Im gay too. Want to get together and do homo stuff?

Re:No kidding

[Anonymous Coward]

No, you are just toying with me. I know you arent gay: after all, you are a Windows user. Everybody know faggots only use either Linux, MacOS, or OSX.

Sigh, Im just going to have to stay here and whack off to gay bondage porn. But at least I can watch it with the Mozilla browser, on my iMac, which is running Linux!

Its great being both gay and alternative! Now excuse me while I shove this 14" black dildo up my ass.

Re:No kidding

[Anonymous Coward]

Hey, silly, dont bogart the black dildo- us BeOS users can use some butt-lovin too!

BTW, I define myself by telling everyone how superior to Windows other operating systems are, too. So you see, we have SO much in common!

Im working on a thesis which shows how gay pornography was really the first open source project. Why dont we get together and I can show you all my 'research'?

two types of embedded

[Anonymous Coward]

Red Hat has definitely seen a drop in the open source embedded market; business for eCos dried up, and embedded Linux isn't filling in the gap. For the traditional embedded market, Linux is slow, unpredictable, bloated and lacks flexibility. Without huge changes it stands no chance, and the number of people trying to use it is decreasing.

On the other hand, there is a growing class of devices that have an embedded computer that looks a lot like a pc. For these heavyweight machines, time to market and new gizmos and features are more important than cost or stability. Linux is gaining marketshare here, and may be the prime player already. People making these things aren't talking to the traditionaly embedded systems people anyway, though.

Obligatory grammarnazi post

[wurp]

The author, Dan O'Dowd, sites variety of

I think you mean

The author, Dan O'Dowd, cites a variety of

Yea Sure!

[codepunk]

You should have seen the look on all of our faces when a well known PLC manufacturer recently showed us their new unit that has a linux mini computer in it. Every single person in the room asked when we could lay our hands on one of them as we want and need it immediately. Or wait somebody had better tell linksys that it will not work.

Bizarre opinion.

[Performer Guy]

Seems downright bizzarre that anyone would suggest homegrown as a cost effective option.

IT is full of idiots yelling at the tide though, move along, there's nothing to see here folks.

Re:Bizarre opinion.

[LarsG]

Seems downright bizzarre that anyone would suggest homegrown as a cost effective option.

Depends on the particular product.

For many types of net-connected appliances (NAS servers, routers, firewalls, webcams,..), advanced PDA/cellphones, TiVo'ish media players and similar, Linux makes a lot of sense. Most of these devices are really mini-PCs, and Linux runs well on those.

But if we're talking washing machines, refridgerators, watches and other tiny stuff Linux is often the wrong choice because the hardware required for even a scaled down Linux kernel and libc is more expensive than a microcontroller + RT-OS.

Re:Bizarre opinion.

[Anonymous Coward]

Seems downright bizzarre that anyone would suggest homegrown as a cost effective option.

I'd have to say that it depends on what you are trying to do. I've been in embedded development for a while and the one thing I have noticed about commercial RTOS's is that they try to be all things to all people. In general, that makes them overlarge, slow and too damned complicated for some of the simpler things I have needed to do.

As a quick example, I had one project where I needed nothing more than a simple time-slicer for background tasks. The company I was working for had already purchased an RTOS and insisted I use it. But it had all the trimmings; prioritization, mailboxes, queuing, etc, etc.

After struggling with it for a week, I wrote a simple switcher that just maintained 3 stacks and picked which one to return to at the end of each clock interrupt where most of the work was actually done anyway. In the end, it took 1/10 the code space, added nothing to interrupt latency for the real-time clock and was so simple to understand that no one who looked at the code had any questions about it.

Particularly in the low end of embedded development where cost and real-time response are paramount, homegrown is definitely an option.

Facts?

[McLoud]

The author exposes a lot of "facts" about using linux in embedded device, but doesn't open the tests made, which linux version he made the tests or with what kind of software. All the problem I've seen in software for embedded generally lies in bad written software, so what? I can make the same claims targetted at any SO/device and will this make that SO/device bad?

the success stories?

[Rock Ridge]

Doesn't linuxdevices.com have an interest in posting "success" stories? Why don't they ever offer "failure" stories?

As for alternatives, there are others beside ecos: rtems, itron, maybe more that are also available.

Re:the success stories?

[Anonymous Coward]

Would you run a bunch of stories stating that you failed at this, that, and the other, but you suceeded at this that and the other? Really?

I've never seen ANY business, club or person who will advertise failures. They are almost always taken out of context, proportion and perspective.

Re:the success stories?

[jared_hanson]

Why don't they ever offer "failure" stories?

Have you ever been to LinuxDevices? They offer prominent failure stories. I'd guess well over half the devices listed their are either no longer available, vaporware, or very obscure.

Over the last year

[devphaeton]

Over the last year there have been a lot of criticism in the press about linux. Now, i do understand that linux, in its infinite forms, will still never be a "be-all, end-all" perfect solution for everything. It's an OS, it's got its faults like any other.

However, why suddenly all the criticism and negative press? I have a few theories:

1) The SCO case introduced linux to a lot of journalists that previously had never heard of it. Kind of hard to swallow, since "linux" *is* damn near a household name now, even for joe sixpack. Maybe the SCO case has introduced it in an unfavourable light, or maybe not.

2) Is linux not the holy grail we thought it was? I have as hard a time believing this as most any other slashbot. Linux is free, it's good, and it's fun. But maybe it's not what *other* people wanted. We (the geeks) love linux as a free re-implementation of minix that is fundamentally quite "unix-like" on purpose. It invites tinkering, experimentation and all the things that appeal to the ADHD crowd. But Joe Sixpack or Journalist Types might be lead to believe the whole "linux is going to kill microsoft" hype. They go into looking at linux expecting "a free windows" and come away with the impression that it's "antiquated, crude, ugly, dificult to use" etc. I do not know where this "linux is going to replace windows on the desktop/linux will kill MS" stuff is coming from. That's not the point of linux. If that was going to happen, FreeBSD or Apple would have done it years ago.

3) ????

4) Profit!!!! MS/SCO/SUN is funding these journalists to present negative data about linux, be it factual or not. The common conspiracy theory. Yes we know that MS *is* guilty of doing this sort of thing, but in many cases it shows up relating to "linux is the poorest choice for X", where X is a market that MS doesn't seem to care about.

Your thoughts?

He is right though

[scorp1us]

He is 100% right, provided it is 2003. The 2.6 kernel goes a LONG way in supporting the embedded segment. In 2004, average ram and flash will almost double, clock cycles will almost match that growth.

He is right about size - Linux is too big when compared to the competition.

What he does fail to understand is the real reasons people switch to embedded linux. Not for gains today, but gains tomorrow. EL (Embedded Linux) provides hardware abstraction, simplifies programming and opens you up to standard technologies.

The problem with most EL projects today is that they are ports of legacy systems. One will realize much benefit int he now if the start from scratch. Backwards compatibility is the problem here.

If you look at all the sucessfull EL prodects, 90% are new designs or use 20% or less old code. It realyl does shorted your TTM and maintance costs, if you don't bother porting old code.

In the end EL is about the future, not the now. But we must use it now to bring about the future.

I've worked on 2 embedded linux projects professionally, and those is my opinions.

What do you want your heart monitor to run

[codepunk]

For 200 points what operating system would you like
your heart monitor to be running?

1. Linux
2. XP Embedded
3. Windows CE

Survey says.....Linux...

Re:What do you want your heart monitor to run

[Anonymous Coward]

Jesus, dude. The only correct answer is "none of the above".

Linux on medical equipment? Christ what a horrifying idea.

Re:What do you want your heart monitor to run

[gregarican]

Out of curiosity have you ever worked at a hospital or have any idea what underlying software runs at a hospital? When one of my infant sons was in for multiple heart procedures I actually saw monitoring PC equipment running Microsoft software. And lo and behold I didn't see the nursing staff coming in to reboot every 3-4 hours!

The point is that the software Microsoft scales down for industry-specific usage probably isn't the crap caliber of a Windows ME or XP Home Edition. Many ATMS run a stripped down Windows version and (although I've seen some funny pictures of BSOD's posted on the 'Net) I haven't seen them hacked or crashed everywhere I go.

Re:What do you want your heart monitor to run

[Anonymous Coward]

No, this sort of an application requires a realtime os with a fixed responce time, what is called a HARD RT in the business, systems with RT extensions like Mac OSX/OS9, WinXP and Linux can replace many RT applications but not HARD RT systems.

And never will, not a flamebait, it's just that one size/design platform really does not fit all

Re:What do you want your heart monitor to run

[Anonymous Coward]

what part of "none of the above" did you have trouble understanding?

Re:What do you want your heart monitor to run

[codepunk]

Obviously you where not here when our fax machines and manufacturing equipment got smoked by blaster and took down our network. If my kid had a heart monitor hooked to him running windows I would have to politely kick someones ass.

Re:What do you want your heart monitor to run

[Anonymous Coward]

If your kid was attached to a networked heart monitor, I'd like to know where you're getting your health care.

Re:What do you want your heart monitor to run

[Anonymous Coward]

Don't mind him. Anyone still making BSOD jokes in 2004 is either a troll or a kiddie.

Re:What do you want your heart monitor to run

[ddama]

How ridiculous. None of the above, of course.

I'd expect them to be running something small, light, and reliable. Either a roll-your own job on an 8- or 16-bit processor or something from Wind River or Green Hills. I mean, really, have you never heard of "the right tool for the job?"

Re:What do you want your heart monitor to run

[myklgrant]

QNX

Re:What do you want your heart monitor to run

[beguyld]

I want it to run something that has been *proven* to be bug-free and stable. Given that most Embedded Linux distributions are constantly changing, based on the latest kernel changes, it's out too. I'd probably go with a stable version of VxWorks that has a history in medical devices.

Products and their kernels

[Anonymous Coward]

Along the same lines... It would be nice to have a database of commercial products and the embedded kernel and/or chipset. For example, some wireless networking cards of the same model have chipsets from different companies. A belkin router (F5D6231-4 version 2000) I used has a ATI Nucleus PLUS kernel, which I found after decompressing gzip data in the firmware file. It would have been nice to know this before purchasing it, as I have already found several bugs in their firmware... and am at the mercy of Belkin tech support (which is quite helpful) to fix. A linux-based router would come with source code, so it would be much easier to fix the small bugs that slipped past QA and/or tip them off to what exactly the problem is. Does anyone know of fair priced routers that are linux based?

What about embedded Development tools

[Fubar420]

Slightly O/T, but what about a nice IDE for developing on (for) non-linux platforms? I know for my job I have to develop on the palm, which as any palm developer can tell you, is a poorly documented bitch to program for.

There are a couple of Windows IDE's (Falch.net, CodeWarrior) that all cost at least a reasonable chunk of change, and ironically all appear to use the PRC-Tool chain to do everything. You know, the same tools that we can all rpm -ivh, dpkg -i, apt-get install, emerge, whatever. The only difference is when I develop on a palm, debugging it in Linux is a pain in the arse, if only because of the lack of most of the nicer IDE's lacking an ability to alter the default compiler, debugging method, kick-starting an emulator, etc.

Speaking of which, I've gotta get back to work :-)

Ciao S/D

I guess my question is . . .

[dlharper]

. . . why haven't 30,000 of us emailed the EE Times and told them what a bunch of bullshit this article is. Since the The author of this 'article' is the president of a company that sells embedded RTOS's and related tools - the least they should have done is charge him for the (obvious) ad space . . .

Right and wrong

[Alinraz]

Ok, first my quals:
* I am an embedded programmer.
* I've used a variety of embedded OSs including both vendor (pay) and home-grown (free except for labor) and Linux.
* I love Linux. I use it at work and home as my desktop, and at work on servers. I have contributed to several projects including ALSA and gcc and binutils.

The way I see it, Dan is both right and wrong.

He's right in that Linux is not approprate for many "true" embedded applications. Most apps have very stringent memmory requirements, don't need most services, and work on severly limited chips (over 70% of all processors sold are 8-bitters). Also, Linux can not meet the real-time reqirements of many applications (feel free to flame me, but it is definately true, despite any "real-time layers" that have been added to Linux). For example, I work on a product that has 512k of SRAM, with a processor clock speed of 156 MHz, and it's "clock tick" has to be less than 40 usec (typical times of Linux include 5 msec). We use an in-house "OS" which isn't a true OS anyway, just a tightly coded main loop in order to meet our requirments.

On the otherhand, we have another "embedded" project that does use Linux. It is the best OS for the job in this case.

As usual in engineering, one must chose the right tool for the right job.

But, for companies that make development tools, we'd be a poor choice on that Linux system because it is highly modded and they'd not be able to support it econommically.

What it comes down to is embedded projects MUST chose the right tools for the right job, and Linux is not allways the right tool.

For embedded tools vendors, Linux OSs will be difficult to support for the very reasons that Dan mentions.

But this doesn't mean that there's no place for Linux in embedded or psudo-embedded applications (psudo-embedded apps look like embedded systems on the surface, but are usually full-featured general purpose systems on the inside. Think TiVo).

The Linux support I'd like to see from tools vendors is better tools on the Linux workstations. Support gcc and binutils for more processors or optimize the code output better on gcc. Help with gdb, insight and DDD to make your hardware emulators work with them on the workstation. I'm tired of having to keep a dual-boot system just to run VisionClick so I can debug my 5407 embedded systems.

Re:Right and wrong

[Anonymous Coward]

The Linux support I'd like to see from tools vendors is better tools on the Linux workstations. Support gcc and binutils for more processors or optimize the code output better on gcc.

Amen!!! I'm so sick of f**king windows or solaris hosted tools I could cry.

I don't understand why some vendor like redhat (or some tools company like montavista) can't just have a yum or up2date channel for embedded tools.

Wouldn't you love to have

embedded-glibc
embedded-newlib

channels with

powerpc-elf
powerpc-eabi
arm-elf
mips-elf
cr is-elf
v850-elf
i486-elf

toolchains based on latest gcc-3.3.x releases (whatever is stable)

Having these toolchains, plus documentation and support would be worth paying for, I think.

Having a good debugger would be nice but I'd rather have better simulators. It's nice to develop natively and use simulators for the first 75% of the work, and then deal with the real hardware when the simulated code is ready and working.

Re:Right and wrong

[neomorph]

Actually, Dan's company sells a Linux-hosted debugger and compiler for your Coldfire 5407 board, so you can pitch VisionClick and erase your Windows partition.

MULTI Debugger

Re:Right and wrong

[red_gnom]

Also, Linux can not meet the real-time reqirements of many applications (feel free to flame me, but it is definately true, despite any "real-time layers" that have been added to Linux). For example, I work on a product that has 512k of SRAM, with a processor clock speed of 156 MHz, and it's "clock tick" has to be less than 40 usec (typical times of Linux include 5 msec).

Linux with RTAI on 150MHz CPU has no problem with delivering Hard Real-Time with jitter not exceeding 20 usec (It can be much less).

RTAI

RTAI Shedulers

RTAI: Real-Time Application Interface

Re:Right and wrong

[Anonymous Coward]

20 usec is way too much for a lot of hard real time apps. Way, way too much.

Re:Right and wrong

[Alinraz]

We evaluated MULTI back when we were researching tools. First off, I didn't want a full IDE solution, but that's neither here nor there. If I remember correctly, at the time (about 2 years ago) MULTI didn't support Linux. Also, it had a number of issues with automagically doing things and the user not being able to undo some of it.

I've been trying to get Insight working with a basic P&E wiggler, but so far no luck due to gcc not having patches (there are patches out there, but not for the current gcc version and for some reason no one has managed to get them commited to the mainline gcc) for the coldfires and me not having time to deal with it.

Re:Right and wrong

[torpor]

disclaimer: i also work in embedded, also love linux, and also agree that its not always the best tool for the job...

The Linux support I'd like to see from tools vendors is better tools on the Linux workstations

The 'cocktail distro' front has some interesting advances in this department. I think its getting easier and easier to do the RYE linux setup for embedded too, and still get a cross-platform development environment (%embedded_cpu, linux-x86).

The more and more distro tools evolve, the more we'll see complete platform coherency - matched libs across multiple platforms on a common kernel core - so the possibiities are very interesting.

Particularly if you consider the system-on-chip advances in silicon fabrication recently, it makes for some interesting hardware times ahead. I think a whole new battle of OS's/computer technology is on the horizon in the realm of embedded and 'deployed' computing, but then I'm pretty biased in that regard ...

Re:Right and wrong

[Alinraz]

RTAI simply wouldn't help in our particular appliction domain. Jitter of more than about 100nsec would be too much for our system to work properly. And, ALL stuff our system does must be done each 40 usec. The scheduler alone from Linux would cost too much time.

We don't even use an "OS" as you know it. Basically we've got one piece of code that runs in a loop with some hardware interrupts (the period on the hw interrupts is about every 3.65 usec with each interrupt taking ~2 usec with 11 interrupts per loop) and that's it. Linux would just add too much overhead to get our stuff done.

Re:Right and wrong

[red_gnom]

20 usec is way too much for a lot of hard real time apps. Way, way too much.

You Ser obviously have absolutly no idea about Real Time Operating Systems. On my PentiumI 166MHz with Linux + RTAI I have max jitter 9usec (110 000/sec), and this is as fast as expensive Real-Time Operating Systems like QNX, or VxWorks can deliver.

RTAI

RTAI Shedulers

RTAI: Real-Time Application Interface

Re:Right and wrong

[Anonymous Coward]

You, ser, misinterpret.

I said *apps*. I never said I bothered with QNX, or VxW, or any of that bunch. But when I'm sampling at 320 kHz on a 80 MHz processor, you wanna tell me how badly 9us jitter is going to screw me up (and by inference, make your car drop into second gear when you're going 90)?

Linux is NOT always the right choice.

No conflict of interest here

[decaf_dude]

From the article:

Dan O'Dowd is President and chief executive officer of Green Hills Software,Inc. (Santa Barbara, Calif.)

So I Googled for Green Hills Software and found that Green Hills Software is "The Leader In
Real-Time Operating Systems". Their Products page lists several RTOS, development platforms, debuggers, compilers, etc.

So much for disclosure at EETimes...

I'll be sure...

[ivanmarsh]

...to tell my buddy who ports linux to telecomm boards for a living that his tools don't exist. That should amuse the hell out of him.

Big lead in embedded?

[Anonymous Coward]

Where did you hear that Microsoft has a big lead in embedded?

Why does everyone choose Symbian or Linux instead of Microsoft has such a big lead?

Back up your claims please.

Re:Big lead in embedded?

[MrDigital]

Here.

For your benefit:
While not disclosing specific market share numbers publicly, VDC provided the following list indicating the market share position in terms of sales revenue, for the leading vendors in the embedded operating system market . . .
1. Microsoft
2. Wind River
3. Symbian
4. Palm
5. QNX
6. Enea Data
7. Green Hills Software
8. LynuxWorks
9. MontaVista Software
10. Accelerated Technology (Mentor Graphics)

Re:Big lead in embedded?

[ddama]

There is no such thing as "the embedded market," no more so than you can speak of "the computer market," anyway.

You can tell from some of the companies listed that VDC included everything from the tiniest 8-but microcontrollers to 64-bit RISC video and server appliances as "embedded." A rational view of this marketspace would segment it into many categories, because, obviously, a company making 8-bit microcontrollers for traffic signals will have no need for Windows, and a company making server appliances is not going to want PalmOS or Eneas's OSE.

Microsoft is in server appliances, Xbox, and PDAs.

WindRiver is in a lot of traditional embedded apps, such as industrial control, telecoms, consumer electronics and transportation.

Symbian is in cellphones.

Palm is in PDAs, expanding into cellphones.

QNX is usually found these days in medium- to high-end embedded apps, such as industrial control and consumer electronics.

Enea is more traditionally found in lower-end embedded apps, like transportation systems.

So the list is basically meaningless. Half the top six companies aren't in 'traditional' embedded markets, and most of them are not, for the most part, direct competitors with each other, in spite of their marketing claims. (Yes, M$ wants to be in cellphones and more deeply embedded apps and WindRiver wants to be in server appliances, etc., but realistically speaking, they ain't.) Just about the only thing they got right is that Linux share in this space is awfully small. Unfortunately for Linux, claims otherwise also come from marketing departments.

Stupid zealot.

[NineNine]

It's not there. That's probably because MS isn't in the embedded devices market. Troll.

Re:Stupid zealot.

[Anonymous Coward]

Never heard of Windows CE or XP Embedded? [Insert insult here].

Alternatives to Linux/RT

[Anonymous Coward]

Linux was never meant for REAL real-time usage. Linux will never be suitable for real-time usage and more so, never for hard real-time; the kernel is simply not structured to be 100% predictable in it's code-paths, plays various tricks to speed things up and tries to be a very good alround system; and it does this wonderfully well if used correctly. It has 2 basic RT-like scheduling-clases, SCHED_RR (round-robin) and SCHED_FIFO (Fist In, First Out), where the application has more control about the scheduling-decisions.

Please remember: RT means NOT to be fast, but to guarantee certain worst-case-latencies under all circumstances, load and IRQ-storms.
If you look for an open-source RT-system, here you go:

1) my favourite, eCos from RedHat/ex-Cygnus.
It has a very, very sophisticated configuration tool (almost everything(!) you don't need is rippable from the kernel), has even a Linux-Compatibility-Module and so on

2) RTEMS is also free, configurable and so on. IIRC it was used to steer the cruise-missles. The configuration is a bit more complicated.

3) number three ... i forgot about it just this moment, sorry

If you want to pay, there is always:
QNX and VxWorks.

Green Hills, eh?

[Anonymous Coward]

I remember them.

Their Pascal compiler is a blatantly bolted-on hack job on top of their C compiler. For example, the Pascal compiler blindly accepts all C operators (!=, ==, >>=, =, etc). There is nothing about this in their manuals. Good luck hoping to find syntax errors with their compiler.

At least dangerous, home-grown compilers like GCC can parse multiple languages correctly.

Re:Green Hills, eh?

[Sivaram_Velauthapill]

So what happens with those comparison operators? Does it convert them to Pascal-equivalent? Or does it compile (without error) but doesn't do anything?

Sivaram Velauthapillai

he is missing the point

[markov_chain]

The author points out several times that Linux, due to its general purpose design, is too inefficient/memory hungry/not real-time capable/etc. for embedded applications. However, he failed to account for the current trend of hardware becoming capable enough for those things not to matter any longer, especially in non-critical applications like Web interface for devices, home routers, media gateways, etc. The phenomenon of not coding PC software in hand-optimized assembler is spreading to high-end embedded devices.

There's more than one embedded market

[DCheesi]

The authoer has a point when it comes to "hard" real-time applications, or extremely cheap/tiny systems for throwaway-type products. There's no point adopting one of the rather tortured real-time linux adaptations, when there are plenty of solid RTOSes out there that are built from the ground up to do this job.

Where Linux is useful is in the larger, more flexible products (handheld devices, etc.). Here you can often get away with using a more-or-less normal linux distro adapted to your processor architecture. I guess his point here is that you can use linux in these larger applications without ever buying a commercial tool. While this is certainly possible, in my experience companies often shell out for commercial toolkits rather than trying to make their own APIs from scratch. So I think he's a bit out of line when it comes to this embedded market-space.

Of course I guess it depends on which "tools" he's criticizing, which isn't clear from the article...

MY BUTT

[Anonymous Coward]

my butt has MYSTICAL and MAGICAL powers!

WRONG.

[Anonymous Coward]

Linux embeds you.

Extra space in URL

[Anonymous Coward]

http://tron.um.u-tokyo.ac.jp/TRON/ITRON/home-e.htm l

eCos config shot

[Anonymous Coward]

Sorry, forgot the important screenshot:
Screenshot
From the documentation

You're missing the point

[Anonymous Coward]

He's talking about the embedded world, where things like this ALWAYS matter.
You've clearly never worked in the embedded sector.

Re:You're missing the point

[markov_chain]

We are disagreeing about what "embedded world" is here. If you define it as "environments where optimization is always important" then of course my arguments don't make sense. But the applications for which such extreme efficiency was needed in the past can now be served by much more forgiving hardware thanks to Moore's law. For example, I'm working with some StrongArm-based hardware with multiple megabytes of RAM and flash which runs Linux easily. It would be a waste of effort trying to run something more compact-- what would be the benefit besides saving a couple of percent of available system memory?

ITRON #1 by what measurement?

[Anonymous Coward]

Number of developers?

Number of units shipped?

Other?

Re:ITRON #1 by what measurement?

[Anonymous Coward]

Number of units shipped

Inside almost every Japanese product shipped since the early 90's, except bicycles of course.

Possibly by number of developers as well, althoug I think QNX actually may be bigger but QNX deployments tend to be smaller

Re:ITRON #1 by what measurement?

[ams001]

Hmmm, by that token any highly specialised RTOS written and used by a single person for a highly successful product could be considered the most popular in the world.

Surely you would measure the most popular RTOS by the number of developers or projects using the RTOS?

eCos has a uITRON compatabile API as well as a POSIX and native API, so I guess as a superset of ITRON it must be the most popular RTOS.

/me crawls back under a rock

The article is about Linux Tools, not Linux

[leinhos]

This article seems to be about commercial tools for embedded linux, and how the market is soft for such software products. A few of the posters here seem to think he is putting down Linux, but rather states that, in order to make money in software tools, developers need to go somewhere else.
From the article:

Because most embedded Linux users roll-their-own, that leaves less than half of the market to the six-or-so major commercial distributions. Since none of them is dominant, no specific integration is able to address more than 10 percent of the market.

The author's concern is exactly what kind of market exists for commercial sofware development tools for embedded Linux, not whether Linux is a good OS for embedded applications. He does take a few swipes at Linux, but they are in support of his thesis that, while embedded Linux-based system developers will need support (for a host of reasons the author presents, be them good or bad), but will not want to pay for them:

The obvious refuge for embedded Linux users is to seek support from a commercial supplier. Unfortunately, most embedded Linux users are not willing to consider commercial vendors.

The author concludes that, because there will not be a strong market for Linux-embedded support, there will be few vendors able to support Linux-embedded (and still make money) applications/development, and therefore the will be no market for anyone selling Linux-embedded development tools (emphasis mine):

As manufacturers recognize the real impact of embedded Linux, the tools market will dissipate. Those inclined to buy tools will abandon Linux. Those who stick with embedded Linux will have no interest in tools.

The author does not, however mention what percentage of developers are those that are "inclined to buy tools".

Can't Imagine

[WindBourne]

Why CEO's of competeing companies to Linux keep saying these things. They must be correct, since there are so many studies by learned people.

LOL ROTL.

Re:Can't Imagine

[Anonymous Coward]

I also can't imagine why /.ers believe that Linux == 42

Neither

[melted]

What are you, kamikaze or something?

Get a clue already

[Anonymous Coward]

The guy posting this is both clueless and clueless^2. It is the standard post of the guy that thinks:

Oh, gee, I'm working for a company that does just another embedded OS, and Linux is eating us alive about market share. Let's post some FUD ...

Suggestion. Go buy a Clue-Hat and wear it for the whole 2004 ...

A Friend

Article isn't a criticism of Linux per se

[Anonymous Coward]

Perhaps all the people defending Linux as an appropriate embedded OS need to re-read the article. The point O'Dowd is making is not that embedded Linux is an inappropriate embedded OS. It's that the set of things it's appropriate for, and the capabilities it has, dictate a customer set unwilling to spend enough mony to support an Embedded Linux _Tools_ industry. In other words, he's suggesting that while Linux may be acceptable or even desirable for some customers in some applications, there aren't going to be a wave of people spending money for commercial Embedded Linux compilers, commercial Embedded Linux IDEs, etc. The customers that would do those sorts of things are the ones that aren't going to be using Embedded Linux as their embedded OS. Thus he sees no real market for companies which seek to exist solely as Embedded Linux providers/enablers. And on that point I suspect he may be right, at least for the near term.

Stop being so defensive people.

Confused Article - yes, no market for Proprietools

[tz]

First, he seems entirely unaware of RTLinux which is a full speed RT layer that sits below Linux and has the reliable near-zero latency he calls for, and it is a commercial product (with an open source side).

IF you need that hard real-time, it is probably the best solution. The 2.6 kernel might be "soft" real-time, but again, that means quantifying the required latency.

For many things including lots of existing systems you need a smart peripheral or second small processor (like a UART with a FIFO).

Much of the rest is confusion.

First, it is easier to "roll your own" OR buy proprietary? He says that it would be to difficult to look inside the Linux kernel to figure out something (not possible with most proprietary OSes without a big $ source license), buy you can apparently recode the whole easily.

There are places where "roll your own" fits - I typically can do most things in careful interrupt driven events, and foreground (every N milliseconds) and background loops. When you get into task switching or MM, it gets hard.

If you are very limited, e.g. using existing hardware that doesn't have room and can't be upgraded, the proprietary uOSes are probably best. One thing to note - if he is comparing like to like, the proprietary OSes get big when you add things like network stacks and filesystems (which may not have things like journaling - can you scandisk your flash?).

The current "small" platforms run linux fine. ARM and MIPs (think Zaurus and AMD's PDA platform) are well supported, and there is uCLinux. Here again, if you can get beyond a certain hardware threshold, you can find a lot of things available.

His article was titled "The myth of the embeddedLinux TOOLS market". That is probably true in that most people are likely to prefer GCC to something else (or it would be nice if they took the same command line switches instead of having to redo complex compiler invocations just to use the proprietary version). And they would probably prefer to mix and match (use GNU ld and ELF or whatever the Linux target object format is).

But what does that have to do with Linux? Or Windows CE (which isn't doing too well either and has far worse timing and resource problems).

Support? It's there, but harder and probably not at the same level, but a Linux wizard isn't an Embedded wizard, and vice-versa and if you are already being cheap, you aren't going to pay me (who happens to know both spaces) what I'd ask any more than you would buy a support contract.

Let me summarize my perspective (I do embedded for a living).

1. Linux isn't a panacea, but is or can be an acceptable solution for a very wide range of embedded products. The rest fall into the custom or proprietary niches. Linux tends to get better and hardware gets cheaper. It also helps in many things having the desktop and target run the same thing.

2. The free tools (compilers, etc.) aren't broken, so the market for "good" or better tools isn't going to be large. A tool cannot correct a design error (trying to run Linux in 64K which seems to be his example). Specialty tools have a better chance, but not "Our proprietary IDE now can compile the Linux Kernel" type tools.

(Think filesystems - even if you had a "better" filesystem, it would have to be a lot better or have some critical feature for someone to want to pay for it instead of using one of the various systems already there).

3. There are add-ons and products in other areas that have a market - like RT-linux which can be used as-needed. There are prototyping boards and systems that come with Linux preconfigured with most of the configuration work done. There are consulting and support services - if you want or need to pay for them, and are competetive with the proprietary OS.

He is correct with the basis of his article - It isn't easy to sell bottled watter in the rain next to a public fountain. But his criticisms of Linux and of the development process and targets are way off. But he doesn't consider reasons for picking Linux legitimate though the engineers probably did consider things carefully.

Vendors

[Anonymous Coward]

The gripes I have with the Embedded Linux Vendors such as Lynuxworks or MontaVista is that they are really really expensive (many 10's of K$$$) and they don't publish their prices. You have to wrangle with a sales guy.

They sell by 'development seats'. Thats fine, but I asked the sales guy if their distribution is open source. He didn't know what that meant. (Their literature says it is). I said it means I can buy one 'seat' and use it freely. He said I couldn't do that. I asked if they have any runtime license manager and he said they use the 'honor system'.

I agree that the vendors provide a lot in the way of porting and BSP's, and they need a viable business model, but the buyer experience they present is objectionable to one who is used to the open source/fs world.

Re:Vendors

[Memetic]

Which company was that sales guy from?

I know one of them well and would be shocked if it was them.

My guess it it is not the one who's CEO is chairman of the Embedded Linux Consortium.

Have you given...

[Svartalf]

Source Navigator or Eclipse a try?

Both are cross-platform IDE's that allow you to change out compilers, do class browsing and analysis, etc. One is a mix of C/C++ code and Tcl/Tk code, the other is based on Java.

Re:Have you given...

[Svartalf]

Ooops... Should have previewed...

Here's the link to Eclipse.

Embedded Linux

[Anonymous Coward]

As a hardware engineer developing MIPs based SoC's, I used 'C' code to excerise the chip in verilog simulations. Previously, it was done using Green Hills. Our license had expired and I pushed to move off of Green Hills over to GCC. Everyone was running Linux by now or was planning to. The bad thing about Green Hills was that it ran on Windows. So you had to copy code back and forth for development.

Linux and GCC offered us a very cost effective cross compiler which also gave us complete control over the opcode's emitted from the compiler (testing those pesky opcode sequence's).

Another plus was that the test code in the lab was written in GCC and when something failed, I could easily throw the code into the verilog simulator and see if it was related to hardware.

IMHO, Linux can be a complete engineering solution from hardware design to customer end product applications, embracing cross-functional engineering design practices.

Maybe the Green Hills guy see's his market drying up and not adapting to the change. Green Hills needs to embrace Linux and evolve, otherwise they will be dust.

For some embedded news check here.

http://www.linuxelectrons.com/index.php?topic=em be dded

Byte

What Slashdot is saying

[Overly Critical Guy]

Basically, what Slashdot is saying with this article summary is that articles that are pro-Linux are good and truthful, and articles that aren't pro-Linux and point things out are misguided and false and simply must be uneducated.

And people accuse Microsoft of bias.

Re:What Slashdot is saying

[Anonymous Coward]

There was evidence to prove that Overly Critical Guy is a lying cocksucker, but he deleted it. Think independently.

Typical...

[jasno]

Hello, Embedded Developer here.

First, let me point out that the article was written by the president and CEO of Green Hills, a vendor of proprietary development tools and several RTOSes.

Second, let me point out a mistake made by many, many analysts when talking about 'embedded' linux. The 'embedded' market ranges from 8-bit microcontroller based devices, to PC style hardware, to cell phones and set-top boxes, satellites and mars rovers. So it is very difficult to come up with an assessment of any technology that applies uniformly to the entire space.

I've worked in practically every segment of the embedded market(DSP based consumer electronics, 8-bit control systems, headless PC's, set-top boxes, cell fones, networking appliances). I've used a variety of tools/solutions ranging from expensive and proprietary to free and open.

I recently had a client interested in using embedded linux for a cell fone design. They were put off by the $80k price tag for vxWorks, and so they decided to try linux. They were able to squeeze the system down to around 2MB on an ARM9/TI-OMAP. The realtime performance was acceptable. And to support the development they purchased several JTAG BDM debuggers. Its not that they were looking for a free ride, but $80k for a proprietary OS with limited features didn't seem like good business sense.

Also, the support I've received on mailing lists and IRC is above and beyond anything I've ever seen from a commercial vendor. In fact, I used to work for one of the biggest RTOS vendors around, and I found it more difficult to get answers out of my own company than the linux community.

Definite lack of one embedded tool...

[CheapScott]

...sites variety of problems...

Like missing a good semantic checker to look over your shoulder and make sure you cite the problems correctly.

Real time?

[El]

Most embedded applications have real-time performance requirements. Really? I can think of very few for which "real time" is really a requirement. Certainly it is not necessary for all those routers, firewalls, access points etc. running Linux. In fact, I beleive in most cases the real time requirement results from bad design; memory is cheap, buffer up the events and process them at your leisure. Can anybody cite an application which actually requires "real time" performance that can't be addressed by intelligent buffering?

Re:Real time?

[Anonymous Coward]

A pace maker?
The real-time control systems in your car?
Flight Control Systems?
Anything which has to read and react to events in real time?

Re:Real time?

[froody]

Anything that deals with real-world physics kind of things. Stuff that controls whether your airbag will deploy or not. All kinds of airplane stuff. Assembly line robots. By extension, if you're talking to that kind of devices over your router, simple user-interface button-thing, or whatever then for those it suddenly also becomes important to be hard real time.

Tim

Re:Real time?

[El]

Ethernet isn't real-time, so by extension any application communicating over ethernet cannot be real-time. The internet isn't real time, so anything communicating over the internet cannot be real time (that includes Voice over IP). Yes, your airbag is real-time, but I wouldn't use a microprocessor just to control an airbag, and I wouldn't trust my general-purpose car computer with airbag actuation. Yes, fly-by-wire would be real-time. I don't beleive anybody is even thinking of using Linux for those two applications. Assembly lines are not necessarily real-time; most tasks are repetitive and don't require responding to an input within a bounded number of microseconds. User interfaces are never real-time; can you tell whether it took your computer 10 milliseconds or 11 milliseconds to respond to your input? Didn't think so. I stand by my original statement -- 99% of embedded devices don't require real-time capabilites; "reasonable time" response is good enough.

Re:Real time?

[froody]

You make some good points. I drew my analogy too far. I was mainly trying to give you examples of hard real-time embedded systems, which it looked to me like you asked for. I have no idea what percentage of embedded systems those comprise.
In my assembly line example I was thinking of something that lines up something right next to something else. The motor control is real-time because once the sensor says we're close enough, we don't want to go any further at all.
At any rate, it sounds like we both agree that for some things Linux is appropriate, and for others it isn't.

Tim

Re:Real time?

[Anonymous Coward]

but I wouldn't use a microprocessor just to control an airbag

Got an airbag in your car?

Then I bet you do, in fact, have a microcontroller whose job is to check data regarding crashes and to trigger the airbag.

And no, there's no one stupid enough to use Linux for drive-by-wire or airbags. At least not where I work.

Re:Real time?

[gnalre]

Ethernet isn't real-time, so by extension any application communicating over ethernet cannot be real-time.

Rubbish, Industrial ethernet is making big inroads in the industrial control market, and that is real time.

We do real time with all the control over ethernet.

The question is what are your timing requirements, what are your hardware limits, then you can decide which OS to use.

Re:Real time?

[El]

How does any protocol using collision detection guarantee delivery time? Rememeber, in Ethernet, delivery is never guaranted. However unlikely, it is always possible to collide 16 times and give up on the transmission. Maybe using Token Ring, ATM, or some modification of Ethernet real time communication may be possible. But not with anything that can properly be called "Ethernet". The latencies of Linux are trivial compared to the latencies introduced by Ethernet, so if you are not bothered by Ethernet worst case round trip times, you might as well be running Linux.

Can you say "bias"?

[El]

Dan O'Dowd is President and chief executive officer of Green Hills Software,Inc.

Gee... don't they sell non-Linux tools? Do you think there is any possibility that the author might have some bias on the subject of embedded Linux tools?

Re:embedded linux

[Anonymous Coward]

Its good. At least I think it is, hold on I will go check.

One example

[TheSync]

Here is a Linux-powered satellite receiver appliance. I actually use these.

RTEMS is a well known OSS real time kernel

[ClarkEvans]

The people who make RTEMS, Online Applications Research Corporation are a very cool bunch who were early adopters in the real time operating system space. They have worked very closely with RMS on licensing in the mid 90's and were one of the first groups using GCC as a cross compiler. Their business model is support oriented plus government contracts.

(I have no financial stake in OAR or RTEMS, other than having good feelings about their involvement in OSS)

Yeah right

[soccerisgod]

If it's a myth, I have to say it's a pretty profitable one. All the money I've been making last year I've been making writing mythical software for an automotive company... If only there were more myths like this - I'd be filthy rich! :)

Re:Yeah right

[Anonymous Coward]

Are you writing linux tools, or linux applications? If you're writing linux applications (not tools), then you're not what the article was talking about. Read more closely.

Re:Yeah right

[soccerisgod]

Both, my young friend. Both.

exactly what is "embedded" anymore?

[hansoncoyne]

no disk? no monitor? no keyboard?
what's the definition?
as the x86 platform gets smaller and smaller, linux makes perfect sense. Yes you need to read a bit, but you can get console over RS232, boot off Compact Flash, and build a kernel to do what ever you want. Not to mention x86 hardware is cheap.

My perspective

[viewtouch]

My market specialty is colorgraphic touchscreen point of sale, a vertical market software category which I first created on the Atari ST about two decades ago. These days I make use of an embedded development environment I developed named ViewTouch. It's not free software, but it makes heavy use of X and runs, therefore, with Linux, FreeBSD, OS-X and any OS which runs X. For my company, developing embedded applications running Linux and any free operating system is a walk in the park. No, my embedded development is not GPL-licensed, but the apps it turns out do run on Linux & X, they are solid, and they are among the easiest-to-use, lowest cost embedded apps you'll find anywhere.

By the way, I evaluated the Green Hills products years ago and found them incredibly primitive and, well, quite useless, not to mention incredibly expensive. The next article I'd like to see on slashdot would be one which does not ignorantly slam the value of a GPL OS like Linux but which highlights the things being achieved by operating systems which sit under X, such as I listed above.

Re:My perspective

[Anonymous Coward]

Well, I evaluated Windows and MacOS years ago and found they didn't even have memory protection!

Perhaps before you use criticism of a companies' products to bolster you arguments, you should at least state "how many years ago" or "what version" your recollections are based on. Someone with Linux 2.0, Windows 3.1 or MacOS 5 is not going to be in a position to speak with any accuracy on the current quality of those OSes.

Why This Article is Stupid...

[13Echo]

This article is stupid...

Why? Because the author has HIS OWN operating system products and services at:

http://www.ghs.com/

In fact, this guy claims to be the authority on operating systems... Read on to learn just why you should choose their "INTEGRITY" product over Microsoft Windows, MacOS, Unix, and Linux, etc.

http://www.ghs.com/RTOSLeader.html

It's Andrew Tanenbaum all over again.

Glad we have an author here that can back his article up with facts, and not just crap.

supply is not market

[Doc Ruby]

The complaints about the tools are a supply-side problem. The demand is there, so there's a market. But the suppliers are not meeting that demand properly (bad tools and delivery models). That means there's still a market demand there. It's the tools that are a myth; the market is real, and evolving.

Microsoft embedded software in cars.

[cheesybagel]

So I can get trapped inside my car? No thank you.

Labor Intensive vs Capital Intensive

[Anonymous Coward]

It's a matter of business plan. Linux is the labor intensive solution. If you have more man hours than dollars, dive in and put the work in. If you have relatively more dollars to invest in a project, buy tools and components and libraries and OSes.

Yeah, Linux is awesome because it gives a guy with a garage and time the chance to make something really first rate. The established businesses still have the money to invest and get something for it, though.

Aside: If anyone is afraid of getting outsourced, it should be the people with expertise in the labor intensive model. Software costs the same everywhere. Programmers are cheaper elsewhere.

thank you thank you

[Bohemoth2]

I never heard of ecos before! thanks for the link. it could be useful for me

Bite me! No XP or CE embedded shit in MY devices!

[Anonymous Coward]

When considering embedded OS's....
Microsoft isn't even a distant desire.

Go peddle your crapware elsewhere

Almost Anything BUT Microsoft anything.

[Anonymous Coward]

What did Commodor64's run again???

Embedded tools

[Anonymous Coward]

One has to look no further than here here to find that Linux has a solid embedded market. http://www.linuxelectrons.com/index.php?topic=embe dded

Re:Confused Article - yes, no market for Proprieto

[Anonymous Coward]

"(Think filesystems - even if you had a "better" filesystem, it would have to be a lot better or have some critical feature for someone to want to pay for it instead of using one of the various systems already there)."

Unix file systems are crap. The whole everything is a file structure of *Nix falls apart. Read the Unix Hater's Handbook chapter on file systems if you need to see what *Nix has badly wrong.

And how do you know if the support is good?

[fmaxwell]

There is a level of expertise when a company designs, codes, and supports a product that's usually not there when the company is just selling support. I'm no Linux guru, but there's nothing to stop me from selling Linux support contracts. If a customer calls, it's not like I will be able to walk into Linus Torvald's office to ask an esoteric question about interrupt latencies. So I could bumble along and the customers would either renew the contracts or not.

If, on the other hand, I had a company that wrote, sold, and supported a software product, I'd have a support team that could escalate problems to developers. I'd have an incentive to do the support right: bad support = lost sales. What the hell does "Joe's Linux Consulting and Screen Door Company" care if you never buy another copy of Redhat? He got the contract for a year's support, made no guarantees that he could solve your problems, and he's paying off his car loan with your company's yearly support subscription fee.

That's one of the things that's broken about the Linux model. There's no guarantee that the people selling the support know anything more about Linux than your own staff does.

The word is "cites", not "sites"!

[wibblylemoende]

cite
tr.v. cited, citing, cites

1. To quote as an authority or example.
2. To mention or bring forward as support, illustration, or proof: cited several instances of insubordinate behavior.
3.a. To commend officially for meritorious action in military service.
3.b. To honor formally.
4. To summon before a court of law.

as opposed to:

site
n.
1. The place where a structure or group of structures was, is, or is to be located: a good site for the school.
2. The place or setting of something: a historic site; a job site.
3. A website.

tr.v. sited, siting, sites
1. To situate or locate on a site: sited the power plant by the river.

Do you have an editor over there?

oh?

[fznck]

you dorkuses all are trolls.

Re:Confused Article - yes, no market for Proprieto

[Tough Love]

he seems entirely unaware of RTLinux which is a full speed RT layer that sits below Linux and has the reliable near-zero latency he calls for

Don't forget RTAI: unlike RTLinux, no patent problems.

Paid for by Wind River

[Anonymous Coward]

Wind River must have paid for this. They missed the boat while soaking the market. Now they pay the price. Linux can be as real time as you want if you know how to write system code.

Har Har, I agree.....

[thenarftwit]

Yes, of course EETimes is going to push articles that promote proprietory OS's from people who advertise in thier magazines, why else would corporate america not want to sell you stuff, the more high-quality software you can get for free, the less money corporate america can get for thier propriatary OS's (microsoft is an excellent example of what the rest of the corporate world can look forward to (ie: haveing to charge less, more realistic prices for their products,...they like to use the free tools (MS's hypocritical use of Linux is a good example), but they want you to buy thier software, not use free software).