Slashdot Mirror
Red Hat Dissolves eCos Team, Changes Embedded Strategy
Anonymous Coward writes "This article at LinuxDevices.com, which includes an Interview with Red Hat CTO Michael Tiemann, probes Red Hat's dissolution of its eCos project team and the reasoning behind Red Hat's newly adjusted embedded linux strategy. Tiemann says his company is still in the embedded business, but considers embedded to be an aspect of a broader 'platform OS' strategy."
I love how the article draws the line between embedded and _deeply embedded_ real-time systems. [Note the sarcasm: It's vague and left as a one shot deal] Many of the roll-your-own type systems are naturally highly specific, and so the general case fails to apply (or needs serious hacking). This was the reason why Windows XP embedded didn't get nearly as much hype for anything as it did for the concept of a stripped down windows os; A generalized OS isn't really what you need in these type of devices. How often do mission-critical _real time_ systems have extensive virtual memory systems? More often, they try to have enough memory that VM isn't intensive or only used by non-critical processes. http://www.ddj.com/topics/realtime/ for a great series of discussions. (Heavily java oriented, albeit) STILL, saying that _RedHat_ has effectively won out the "embedded linux market" wasn't saying a whole lot; the real market is for stripped down _exceedingly_ generic systems that are designed for extreme platform-specific customization and optimization. But hey, at least we know they wont BSOD. =)
When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. (Larry Wall)
If find it amazing how hard Red Hat seem to find the embedded systems industry. Cygnus where around since 1989 providing Open source support for the embedded systems industry. They still have Cygwin...
We need another cool Open source embedded support company to take up the void left by Cygnus...
M0571y H@rml355.
Hi.
I work with embedded OS and hardware, so I can tell from your niave statments that you don't.
Size, power consumption, etc dictate components, and upgrading from 100k to 2 meg of memory just isn't possible most of the time. Since linux is a memory hog (compared to other embedded OSes), and has poor latency, it's not a viable option.
Since the minix license has changed, that's one of the most popular "free" OSes available. And it doesn't have the legal entaglements linux has.
I like linux - we use it for our web, mail, and samba servers. But we don't use it for embedded devices.
I am particularly upset about this, because my company began development on an industrial product with eCos at its core. We invested at least $50,000.00 in development. Now, management is freaking out, and we have to investigate new operating systems, and possibly re-develop some key portions of our system.
Just kidding. We didn't really do any of that. But seriously now, my company was seriously considering eCos as the operating system for our upcoming project. Personally, I would have greatly preferred eCos over the other solutions we're evaluating, particularly because I'd much rather support eCos than some proprietary solution. (And because the money spent on the proprietary solution could be spent on better analysis tools and whatnot, and because you don't normally get the sources for proprietary stuff, which is a huge problem in hard-core embedded systems, and because... ten thousand other reasons.) I was looking forward to working on eCos, as it appeared to be a very promising system. So this is pretty disappointing news.
As a long time RTOS programmer, and being a contributor to the ECOS project, I think that this is a terrible blow for the open source community. Is open source (and LGPL) viable? This decision suggests not.
The best thing about open source is that you don't have to rely on an inept customer service person to figure out that they in fact have problems in their system. I've spent weeks asking a large closed source and very expensive RTOS vendor to fix some of the dumbest OS bugs (admittedly in a new JVM product they'd hardly released yet)--they still don't believe the one page test programs I send them; in fact, I've just been simply astounded at the dumb things I've been told to do. There's nothing worse than knowing that if you had the source, you'd just simply fix the problem, submit the change, and move on. And you know what's worst? The development tools for this expensive RTOS were cygnus anyway.
The eCos source code was very well written, it's confiuration understandable (and scriptable!), and all in all, a very well concieved project. I will do a CVS update now; and hang on tight to that system... it will be well worth it.
Most projects I see that use embedded software is in "all in 1 chips" that hold a decent line of I/O, a watchdog (nearly every chip), decent "IPS"/"FLOPS" (whichever one is more needed) rating for job being done and onboard memory.
If your device is fairly simple, you can easily get away from coding the whole thing in the chip ASM and feel comfortable. Anyways, if you need more memory, you have extra address lines.
If something more is required (some sort of a UI), build from the ground up tailoring the whole OS to your hardware. Linux is NOT needed in this type of device. Hoever, it seems viable for palmtops and other small computing environments, as windows seems to take more hardware power to do the same things (though slightly beter).
Linux the platform.
Linux the project.
Linux the tshirt.
Linux the lunch box.
Linux the flame-thrower (the kids love that one).
And of course, Linux the doll.
I've done work in industrial automation, and a real-time system is not necessarily embedded, no is an embedded system necessarily real time.
Best Slashdot Co
Why should I spend weeks to months writing disk drivers, gui's, keyboard interfaces, etc, when there are OS's that have already done that?
Best Slashdot Co
Neither the GPL nor the LGPL are appropriate for commercial embedded products for precisely the reason you mention.
If you're a hardware manufacturer, opening the source also opens up your proprietary hardware. If you're a software company and you GPL the source, you've just become a support or consulting company. Good luck. Software makes a good complement to hardware, but only if it doesn not commoditize the hardware.
For copyleft to work in the embedded field, we need a new paradigm. Perhaps Trolltech's idea is the way (you can buy a proprietary license to free (as in speech) yourself from the GPL). Perhaps we need a new license that does not require disclosure of source if the software is distributed embedded in the hardware. Perhaps copyleft won't work at all in this field. Just pondering.
A Government Is a Body of People, Usually Notably Ungoverned
2. Yes, some embedded designs (those at the smaller end of the scale) don't use an OS or a kernel of any kind. But it's equally important to realize (as some 5-rated slashdot poster invariably doesn't) that the embedded CPU in a piece of $100,000 network equipment probably does run a hefty OS kernel, especially if it needs multitasking, networking, field debugging, or upgrading (as many pieces of $100,000 network equipment do).
3. Note that I say "OS kernel", not "OS". Most PC users tend to think of an "OS" as a giant 500MB distribution that includes everything from printer drivers to web browsers. Even heavyweight embedded systems are a lot slimmer (kernel+libraries+app, perhaps), but may still bear some resemblance to what you consider an "Operating System".
4. There's as many penny-pinching companies doing embedded designs as there are penny-pinching companies of other flavors. Some companies have big issues with the costs of VxWorks and similar products.
5. Support is really important in the embedded world, where you're always going to have to customize somebody else's code. As a corollary, survival of the company you're buying from is very important too (definitely an concern with today's crop of embedded-linux companies). Note that this and #4 are in conflict.
314-15-9265
It doesn't necessarily mean it's bad news. It may even be good news.
When Eazel died, Nautilus development didn't die. Instead, it expanded and resulted in a really nice, more focused and componentized part of GNOME. Why? Becuse Nautilus now grows in the direction the community wants, not in the direction that the Eazel wanted, so business model-related features/bloat and GNOME-duplicated functionality were stripped away.
If you feel strongly about eCos, set up a CVS on sourceforge or savannah.gnu.org and see if anyone on the Debian mailing list is interesting in porting Debian to eCos (like they do for HURD, FreeBSD, Linux, and Win32 (although this port is *really* basic)). Or submit an "Ask Slashdot" call for developers and see who is interested. Either way, the source gives you a lot of power to control your OS choice.
You obviously don't work in the embedded field. For many embedded fields, minimizing unit cost is the utmost priority. A few cents(or several dollars in the case of moving from a 1 megabit to a 32 megabit flash) of difference makes a huge difference when you are talking hundreds of thousands or even millions of units. Spending the money on non-recuring engineering expenses pays off in the long run.
And many embedded systems don't even have much of what most people consider an OS. They can get away with a very simple timed loop type OS or a simple scheduler. For the majority of embedded systems, Linux, and any other real time operating systems is just plain overkill.
btw, here is how to access Red Hat's eCos CVS repository: eCos v2.0 CVS source repository.
cpeterso