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.
I'd like to see a Linux kernel in ROM :-) Then you could just switch on, and use the machine.
It'd be like having an 1980's 8-bit machine again, only better.
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).
Well, I'm always in favor of reorganizing -- rallying the troops, as it were -- when things go amiss. But I can't help but think RedHat blew it this time.
The embedded world, unlike the desktop and server markets, operates on a nano time scale. Companies pop up and evaporate faster than you can blink your eyes. In this dog-eat-dog environment, a week's hesitation can cause a lifetime's poverty.
I think RedHat may have faltered, and I don't think their competitors will let them get away with it. If history is any indication of future events, it's time to kiss eCos goodbye.
Karma: Good (despite my invention of the Karma: sig)
http://www.linuxdevices.com/links/LK8294110575
... sounds like a pretty neat idea to me :) (there are some similar projects besides this, but this one sprung up high on the list ...)
Definitely not ready for Best Buy, but
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
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
---"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?"
I DIDN't say GUI's.
For example, don't you consider a UI in a vehicle is the gear-shift, the brake, the gas pedal, and the speedometer ? I do. I see no point in writing disk driver codes or to filch code from a keyboard ps-2 driver in Linux, as there is NO need. You just write your own, as it's not hard.
Second example: what about microwaves? They use a simple touchpad and a computer interface to do the timing. The main computer just controls a driver that causes the tuntable to spin and the tubes to be powered on/off. Nor is there a Windows Microwave.vxd you can use. You write it yourself, as many (if not all) embedded projects.
My main point is that MANY embedded devices have no need for an OS, nor will ever need one. Most devices like that are RT devides that operate from a streamed input (usually some sort of sensor or output from another device). If you wanted to carry this argument to an extreme, look at a smoke alarm.. Is there a UI, yes (the reset button). Is there a controller? Yes. It takes 2 inputs (reset line and americum radiation smoke line). This processing is quite simple, that I could easily do it with a 1 MHz pic.
For shrunken computers, Linux seems viable. Shrunken computers (what many call embedded) are still computers. So what if they run on a flash card or e^2. Sounds like that the meaning of embedded isn't here. Well then, lets call sone of my confusion...
I call my Athlon 1GHz Tower an embedded computer since my BIOS image isn't booted off my hard disk. Am I right? Seems to be that "embedded" (well, here in slashdot) means something is taken from a chip.
Nobody cares. Most programmers don't care if it runs on your RISC box. They have written code that is usefull to them. If you can use it, fantastic. If not than keep your mouth shut.
For those of you who actually know a little bit about the embedded market, go surf the RTEMS web pages for info about another fine embedded OS. This is is actually covered by the GPL, with a sensible amendment that you CAN do binary-only distributions of your product that includes RTEMS. The folks there are quite nice and very knowlegable, too.
http://www.oarcorp.com/RTEMS/rtems.html