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."

Comments

I think this is a good move for redhat

[Squeezer]

If IBM can fit Linux and X Windowing System into a 8meg watch, then You can fit linux onto almost anything. I don't see the point of having several thousand man hours used to develop an embeded OS that uses >100K of memory when you can use linux and just buy a slightly bigger memory chip. Its cheaper to use linux and buy a bigger memory chip (memory, even flash rom and CF) is cheap these days. It is especially cheaper to do that then hire a team of programmers to write an OS and applications from scratch just so you can use 100K of memory instead of a couple of meg of memory. And a couple of megabyte sized flash chip won't be *that* much larger then a comparable chip that holds 100K of memory.

Re:I think this is a good move for redhat

[BLAG-blast]

You know, the problem with programmers these days is that they don't know their born. Generally, once computers got more than 64K (some claim this figure is lower) of memory, programming styles got slopply.

If IBM can fit Linux and X Windowing System into a 8meg watch, then You can fit linux onto almost anything. I don't see the point of having several thousand man hours used to develop an embeded OS that uses >100K of memory when you can use linux and just buy a slightly bigger memory chip.

Things aren't that simple, so now that you've increased the memory requirement of the device by 80x, where will you put the battery that has to be 80x bigger (or more) to last the same amount of time? Why bother having laptops when we've got desktops?

Why bother making car more efficient when we can just drill more oil wells?

Sub 100K OSs are a really dream come true for a lot of embedded device developers. BTW, for many embedded systems developers 100K is a lot of memory, many are working on devices in 2K to 16K range....

Re:I think this is a good move for redhat

[Nighttime]

And a couple of megabyte sized flash chip won't be *that* much larger then a comparable chip that holds 100K of memory.

But where do you stop? As the Urban Legend goes, "640K ought to be enough for anybody." If you don't give the programmers a size to work to, they'll keep pushing the limits. Rather than fitting into a 100KB flash chip, you now have to budget your manufacturing for using 2MB flash chips. Oh, and you now have to redesign the PCBs to use the different capacity chips.

Re:I think this is a good move for redhat

[MisterBlister]

The good programmers (which admittedly aren't ALL programmers) didn't so much get sloppy as they stopped sweating the small details.

Sure, someone could rewrite Microsoft Excel in x86 assembly and maybe make it run twice as fast in 1/3 the memory space, but it would take years of dedicated effort just to port what they have now, nevermind ongoing maintenance, which would then be a nightmare.

Of course, on embedded systems you often have to have the small & simple mindset that was around when 64K of memory was a huge amount on any system...But trying to extend that to saying people who program so-called "bloatware" for PC level systems are bad programmers is completely wrong.

Re:I think this is a good move for redhat

[BLAG-blast]

The good programmers (which admittedly aren't ALL programmers) didn't so much get sloppy as they stopped sweating the small details.

I guess it depends on your definition of "good programmers". Things like "stop sweating the small details" are the number one reason that open source projects have so many endian problems.

Of course, on embedded systems you often have to have the small & simple mindset that was around when 64K of memory was a huge amount on any system...But trying to extend that to saying people who program so-called "bloatware" for PC level systems are bad programmers is completely wrong.

"If an accountant buys an object for $2000, which he could have gotten for $64 if he'd taken the right approach, would that make him a bad accountant?"

I guess it's a trick question, because he'd only be a "bad accountant" if he goes over budget, of course I wouldn't call him a good accountant either. This could apply to programmers as well...

Re:I think this is a good move for redhat

[MadShark]

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.

RedHat is a large company....

[HowlinMad]

So it is not unusual for it to look like it is going in two different directions. I just hope this is an actual strategy.

GPL to blame ?

[brain-in-a-box]

I think this is actually one of the first
occuarances where the GPL fires back.

For most customized embedded systems you
need to modify the kernel.

And you are distributing this stuff
commercially. This would force you the
uncover the code. However this would
reveal too much of your design
to your competitors and therefore you
don't use Linux, but *BSD instead.

Additionally distros don't make much sense for embedded
systems - the designer of the
system has to chance so much at Linux
that he is in fact creating his personal distro
on his own. No reason for RH/Debian/BlubbBlubb/what ever based systems.

Embedded != real time

[wiredog]

I've done work in industrial automation, and a real-time system is not necessarily embedded, no is an embedded system necessarily real time.

Re-inventing the wheel

[wiredog]

If something more is required (some sort of a UI), build from the ground up tailoring the whole OS to your hardware

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?

Is it really bad? Remember Eazel?

[qweqwe]

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.