Slashdot Mirror

← Back to Stories (view on slashdot.org)

Red Hat Dissolves eCos Team, Changes Embedded Strategy

Posted by chrisd on from the red-hat-goes-well-with-orange-socks dept.

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

34 of 111 comments (clear)

  1. I think this is a good move for redhat by Squeezer · · Score: 2, Insightful

    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.

    --
    Does the name Pavlov ring a bell?
    1. Re:I think this is a good move for redhat by Anonymous Coward · · Score: 5, Informative

      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.

    2. Re:I think this is a good move for redhat by BLAG-blast · · Score: 2, Insightful
      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....

      --
      M0571y H@rml355.
    3. Re:I think this is a good move for redhat by Nighttime · · Score: 2, Insightful
      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.

      --
      I've got a fever and the only prescription is more COBOL.
    4. Re:I think this is a good move for redhat by MisterBlister · · Score: 2, Insightful
      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.

    5. Re:I think this is a good move for redhat by BLAG-blast · · Score: 2, Insightful
      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...

      --
      M0571y H@rml355.
    6. Re:I think this is a good move for redhat by MadShark · · Score: 3, Insightful

      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.

    7. Re:I think this is a good move for redhat by scrytch · · Score: 2

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

      Makes him a lousy purchasing manager. He's still a fine accountant if he credits and debits the $2000 in the right places...

      --
      I've finally had it: until slashdot gets article moderation, I am not coming back.
  2. RedHat is a large company.... by HowlinMad · · Score: 2, Insightful

    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.

    --
    Great Linux Site
  3. Embedded OS, Windows XP and Nonsense. by Vengie · · Score: 3, Interesting

    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)
  4. GPL to blame ? by brain-in-a-box · · Score: 2, Insightful

    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.

    --
    You are the dot in slashdot !
    1. Re:GPL to blame ? by Arandir · · Score: 3, Interesting

      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. Re:GPL to blame ? by Oestergaard · · Score: 2

      You are right about the differences and the implications of the GPL. However, this is exactly the reason why Linux supports as much hardware as it does, and *BSD keeps lacking.

      First of all, most likely you don't need all that much of a change in the kernel. There are the readl-time patches if you need those, and the kernel config options can do a lot. If you need special configurations, you're not really expsing yourself or your hardware by putting the patch on a publicly available FTP server which no-one would care to visit anyway.

      If you need real code changes in the core kernel, there are two scenarios usually: either you're smoking crack and the problem already has a nice solution in the kernel - in which case the point is moot. Or, you're really on to something that could be used in general in the kernel, in which case you are not expsing your own hardware design, but will get the kernel changed for you (or at least have your patches accepted).

      In the latter case, Linux moves a step forward. In either case, you get what you want without exposing your hardware significantly.

      Finally, you may need to drive proprietary hardware pieces. Well, surprise, this is what modules are for. You are perfectly free to write a closed-source top-secret proprietary driver and load it as a module, without ever telling anyone that you even wrote it. And you can ship the binary module in your product, along with the kernel. No problem.

      Oh, and in case you feel that you are not smoking crack and the kernel definitely needs a core change that you cannot get anyone to accept for inclusion, place hooks in the kernel code and make that patch publicly available. Now you can write your secret module and have it use those hooks.

      No problem with the GPL as I see it. Just a general encouragement to make the kernel we all use a little better.

  5. Long live CYGNUS!!!!! by BLAG-blast · · Score: 3, Interesting
    I'm sad to see eCos go, it's a great idea. When Red Hat talk about embedded systems they mean the people they got from buying Cygnus.

    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.
  6. Linux in the BIOS by Anonymous Coward · · Score: 2, Interesting

    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.

    1. Re:Linux in the BIOS by Junta · · Score: 2

      Acually, if you get the right system, it can be nearly that way. For example, this laptop I'm on barely flashes a logo for about a second for keypresses before diving into GRUB. A lot of Desktops do too lately. If you fine tune your BIOS, it doesn't take that much time to get to init anymore... Now the main problem with booting linux for me is the time taken for init to finish. I would like to see the possibility of starting multiple things in parallel rather than in series, for example if two scripts both begin with S45 then they both should run simultaneously.
      Also, some services are good to have, even for a workstation, but it would be nice to have a point where the gui comes up and services follow for those workstations where gui comes before network service functionality. For example, I want my desktop to run ssh and some other things, but interactive login is more important to have things up quickly. Does anyone know about work along these lines?

      --
      XML is like violence. If it doesn't solve the problem, use more.
  7. I am very disappointed. by rice_burners_suck · · Score: 3, Informative

    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.

    1. Re:I am very disappointed. by capt.Hij · · Score: 2

      It sounds like there are 7 experts in eCos who are now available. Your company could be the center of the eCos universe in a short time! Then again you could consider one of the other ten companies for embedded linux.

    2. Re:I am very disappointed. by cpeterso · · Score: 2


      eCos is GPLd, so feel free to adapt and maintain it yourself. :)

      There are offer non-proprietary embedded operating systems, such as Linux and NetBSD.

      --
      cpeterso
  8. This is bad news for open source. by Ludwig668 · · Score: 4, Interesting

    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.

  9. WHy OS in embedded apps? by josh+crawley · · Score: 3, Interesting

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

    1. Re:WHy OS in embedded apps? by John+Whitley · · Score: 2

      Say what?!? Reinventing and/or reimplementing error-prone RTOS functionality and primitives (semaphores, queueing, resource locks, multi-level queue scheduler (or the few other popular variants thereof) makes no business sense for most companies.

      Specifically: RTOS writing is a cost-center (as opposed to a profit-center) for most organizations. The great thing about eCos was its promise to help distribute this cost center across many organizations that need a lightweight small-footprint RTOS for their application. RedHat's service0based business model was appealing, also. Service and/or modification contracts were substantially cheaper than most proprietary RTOS upfront, per-unit, or ongoing licensing fees. Heck, OSes in general are cost centers for everyone except MS (possibly for RedHat, depending on how you view their business model). Moreover, few developers really understand how to competently code even a basic RTOS these days. Once an RTOS has been produced in-house, it will have to be maintained by at least one developer, with a backup maintainer on-hand for safety. I know of lots of organizations where the firmware team is only 2-5 people, who get "graded" by how quickly they complete the whole application, not on how much time they spent writing boring infrastructure code. Still, RTOS writing does make sense for a few companies, especially ones with a larger firmware staff and unique needs.

      So what happened with eCos? Because corporations looking for a product platform RTOS choice often seek a few things 1) a known, supported, stable OS platform which 2) has a body (in house or in the marketplace) of knowledgable developers available. To be specific, Linux itself has whomped eCos. Despite the economies that can be had by lightweight firmware architecture designs (in the bill of materials for req'd hardware, etc)... many large companies seek out OSes for which their staff has prior experience, and/or which meet a corporate safety objective. Particularly in Japan, Linux is becoming an embedded imperative.
      RedHat's move is simply responding to percieved (and quite real) demand in the marketplace for 'real' embedded Linux.

      So remember kiddies: Plenty of RAM and an MMU are your friends! 8-)

  10. Re:Linux in the BIOS (why funny? :)) by timothy · · Score: 2, Interesting

    http://www.linuxdevices.com/links/LK8294110575

    Definitely not ready for Best Buy, but ... sounds like a pretty neat idea to me :) (there are some similar projects besides this, but this one sprung up high on the list ...)

    timothy

    --
    jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
  11. Merchadising by LowneWulf · · Score: 3, Funny

    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.

  12. Embedded != real time by wiredog · · Score: 3, Insightful

    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
  13. Re-inventing the wheel by wiredog · · Score: 3, Insightful
    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?

    --

    Best Slashdot Co
    1. Re:Re-inventing the wheel by josh+crawley · · Score: 2, Interesting

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

  14. confusion regarding term embedded by sheldon · · Score: 2

    You're right, most embedded devices do not have operating systems, or have any such need. i.e. the computers which control engines in cars, various monitoring devices and so forth.

    They're usually something like an 80186 with 16K of RAM hand coded in assembler.

    But the term embedded has become confused as of late with appliance computing where you make a special purpose computer using fairly generic parts, but configure the OS and software so it provides only a specific function. Things like those Cobalt servers, and so forth.

  15. eCos developers don't seem to care by tdrury · · Score: 2

    I've been developing an embedded system with eCos for only a couple months, but the general feeling on the eCos developer and user lists with respect to Redhat dropping eCos is "who cares?". Apparently Redhat's support for the product wasn't stellar which is really the only value-add you are paying for (except perhaps for the gnupro toolchain). eCos 2.x in cvs is gpl'd with one exception to allow some embedded software not be be gpl'd itself. Redhat says that eCos will continue to be hosted at sources.redhat.com. Should that not happen, there is always sourceforge. The eCos developers, however, are out of work and updates to the source tree will probably be slower since they all have to find new jobs now. Patches seem to be submitted by everyone and they seem to have slowed down the review and acceptance of patches.

    None of this is not a problem for me. I will continue using eCos.

    -tim

  16. Idiots guide to embedded computers by Eric+Seppanen · · Score: 4, Informative
    1. "Embedded" is not a coherent market. It's an incredibly wide span from dinky 8-bit CPUs that you'd use if you were building a toaster, or maybe super-efficient CPUs for cheap cellphones, through medium-sized CPUs that run industrial machines, or maybe cheap routers or automotive engine controls, all the way up to very hefty CPUs that drive expensive routers, giant room-sized printers, or networked test equipment.

    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
  17. Is it really bad? Remember Eazel? by qweqwe · · Score: 5, Insightful

    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.

  18. Take your RISC and shove it. by glrotate · · Score: 2, Interesting

    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.

  19. eCos CVS by cpeterso · · Score: 4, Informative

    btw, here is how to access Red Hat's eCos CVS repository: eCos v2.0 CVS source repository.

    --
    cpeterso
  20. Screw RootHack by softweyr · · Score: 2, Interesting
    Squeezer, you really don't understand the dynamics of the embedded market. Every cent on the Bill of Materials (BoM) is 3 or 4 cents in the customers hand. You're also not realizing the correct scale. When you roll out 5 servers or 20 desktops, management doesn't freak out if you say you need to spend an additional $20 each for memory, blowing a few hundred dollars. When you propose adding $2 to the bottom line on a half-million units, you get laughed out of your product planning meeting.

    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