Slashdot Mirror
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."
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?
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.
There is no one-size-fits-all in the embedded controller market. Linux has it's niche, but it can't fit everywhere.
"Eve of Destruction", it's not just for old hippies anymore...
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.
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
Electronic Music Made Using Linux http://soundcloud.com/polyp
Embedded Linux Tools Market a Myth? No. When I read that Wind Rivers was looking into Linux you knew which way things were going.
Onward to the Aether Sphere!
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.
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.Being a competitor does not make him automatically wrong. In fact, one might say that he's an expert on the matter.
The owls are not what they seem
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.
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.
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?
sign(c14n(envelop(this)), x509)
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.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
... 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.
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.
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.
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.
Tsunami -- You can't bring a good wave down!
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?
;). 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.
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
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?
Hey freaks: now you're ju
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.
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.
= 9J =
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.