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

111 comments

  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 Anonymous Coward · · Score: 0

      Well, I suppose it depends on how long the accountant took to research the $64 purchase and how much he makes an hour. Picking the right trade-offs is all part of good design. There is no absolute right or wrong. I would agree that many modern programmers are sloppier than they should be, but I think those that harken back to the days of 64K being a lot are missing the point just as badly to expect their kind of thrift in the mainstraim.

    8. Re:I think this is a good move for redhat by 1010011010 · · Score: 1

      Why, you stop when NVidia is making the display chips for your wristwatch, of course.

      --
      Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
    9. Re:I think this is a good move for redhat by nurb432 · · Score: 1

      In the embedded world size *does* matter. ( and hard timing )

      Plus im not so sure linux really is approprate for use in embedded produts where failure is *NOT* an option. ( like in my ABS module ).

      Linux has its place, just not sure its here.

      I admit ive been out of the business a while, but some of the fundamental principles still apply.

      --
      ---- Booth was a patriot ----
    10. Re:I think this is a good move for redhat by Anonymous Coward · · Score: 0
      Memory size has very little to do with it. Many embedded systems designs run on CPUs without MMU's. Also many run on 8 or 16 bit CPU's. The embedded universe is much larger than what Linux alone can satisfy. (Ever.)

      eCos was a good product for most situations where Linux wouldn't work. As an embedded software engineer with 12 years experience, I considered eCos and Linux to be complementary tools in the Open Source toolbox.

      Hopefully the OS community can keep eCos alive after Redhat drops their support. That's why we do Open Source, right?

    11. Re:I think this is a good move for redhat by tius · · Score: 1

      Here we go again: people thinking that "embedded system" means a PDA.

      A digital thermostat is an embedded system. It certainly doesn't require linux or 100K of RAM to implement this.

      A major aspect that is often overlooked is that something like a 100K of RAM is worth maybe $5 whereas a couple of meg is going to seriously out price that. Now, consider building a 100,000 units. That extra cost becomes very significant.

      I think it was already mentioned, but power consumption can be a major issue; ie. more RAM sucks more power. Not a good idea for battery powered apps.

      Yadda yadda.

    12. Re:I think this is a good move for redhat by LordByronStyrofoam · · Score: 1

      eCos's main competition was Wind River's VxWorks, and pSOS (which was bought by Wind River a couple of years ago). RTEMS (an open source RTOS) remains free. eCOS was in my opinion the best-of-breed of the free RTOSs, with ports for a few modern low-power highly integrated processors. Our SA1110 device, under VxWorks, needs about 600K for the OS and our application, and about 1.5M for data (the app used ~1.1M of that. Our app needed hard real time - we werre monitoring a cardiac patient's heart, and the sampling interval doesn't tolerate a lot of jitter. Linux just wouldn't shrink to our space constraints.

      --
      Slashdot's name? When my compiler sees /. it generates a warning about a badly formed comment.
    13. 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.
    14. Re:I think this is a good move for redhat by Anonymous Coward · · Score: 0

      we do and you are naive

  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. Re:Great news for Linux! by Anonymous Coward · · Score: 0

    ya wanna know something, Physics[non-]Genius, you suck

  5. 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 BLAG-blast · · Score: 1
      I think this is actually one of the first occuarances where the GPL fires back.

      Erm, how did the GPL back fire?

      Why don't you read the eCos license before spouting BS.?

      eCos is not GPL'd

      --
      M0571y H@rml355.
    2. 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
    3. 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.

  6. Doesn't make sense by Anonymous Coward · · Score: 0

    This doesn't make sense. Embedded systems customers have very different needs to ordinary customers. For them to have dissolved their embedded systems division means only one thing: they weren't getting enough business.

    It looks like Linux isn't making much impact on the embedded market after all. Right now, embedded just isn't its forte.

  7. 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.
    1. Re:Long live CYGNUS!!!!! by Anonymous Coward · · Score: 0

      Yes, but Cygnus wasn't exactly up to their eyeballs in customers either. Regardless of whether RedHat bought them or not, they would still be struggling.

    2. Re:Long live CYGNUS!!!!! by Anonymous Coward · · Score: 0
      Yes, but Cygnus wasn't exactly up to their eyeballs in customers either. Regardless of whether RedHat bought them or
      not, they would still be struggling.


      Maybe, but when Red Hat bought Cygnus, Cygnus
      had a higher revenue than Red Hat. Then again,
      Cygnus was privately held and had a regular customer
      base, so maybe Cygnus could be looking at buying
      Red Hat now..... ;-) Customers and quality start to fall off after the 'merge'....

  8. related interview by redtoade · · Score: 1

    here at CNET:
    http://news.com.com/2100-1001-938685.html

    Interview with Chief Executive Matthew Szulik on Red Hat's view of the desktop world.

  9. 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.
  10. Re:dissolution of eCos? by Anne+Thwacks · · Score: 1
    You'd have to ask a chemist.

    You could ask mine - their Point of Sale terminals are running Win98, and they had all crashed when I went there a few minutes ago. It took me ten minutes to persuade them to try re-booting one so I could buy something. Other customers just left, bewildered.

    Perhaps embedded Linux is just what the doctor ordered?

    --
    Sent from my ASR33 using ASCII
  11. 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
    3. Re:I am very disappointed. by softweyr · · Score: 1

      eCos is not GPLd, you dork. Why bother posting when you don't know anything about the thread?

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

    1. Re:This is bad news for open source. by andersen · · Score: 1

      This may be a "terrible blow" for eCos, but open source embedded Linux development is doing just fine.

      --
      -Erik -- --This message was written using 73% post-consumer electrons--
  13. Re:The trend is negative by Anonymous Coward · · Score: 0

    Another manifestation of the linux is dying phenomenon

    What color? red - that has to be about the most fractured sentance I've ever read

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

  15. bad news for Linux? by tps12 · · Score: 1, Interesting

    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)
  16. Unethical question: by Sheetrock · · Score: 1

    Assuming a tiny bootstrap program was created that altered the kernel and loaded it into memory on-the-fly, would either the program or the alterations need to be made public?

    --

    Try not. Do or do not, there is no try.
    -- Dr. Spock, stardate 2822-3.




    1. Re:Unethical question: by beswicks · · Score: 1

      I'm not sure about 'altering' the kernel but Sony's PS2 Linux offering uses a 'runtime' enviroment to 'hide' (or should that be emulate to aid compatability?) some of the PS2's hardware from the linux kernel. That way they do not have to opensource drivers for the hardware.

      That runtime is commercal 'payware' (although is bundled with the kit) so I guess something simliar would be legal.

      Whether it would make sense to do so though is another matter.

  17. 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
  18. There's definitely something fishy here by Anonymous Coward · · Score: 0

    In a nutshell: "We're leaving the embedded market because we want to focus on the embedded market." Dubious statements like these raise questions about what the true rationale is. I'm just hoping they aren't feeling the squeeze that most Linux businesses have been since the collapse of the heady .COM era.

    1. Re:There's definitely something fishy here by Anonymous Coward · · Score: 0

      You bet they are. There's ongoing pressure to drive up revenues.

      The eCos group was more profitable than the other groups, including Red Hat's Embedded Linux group, for longer. Then the first quarter the group didn't make a profit, they were canned.

      Now that's employer loyalty :-(.

  19. Stop spreding vile FUD! by Anonymous Coward · · Score: 0

    Nobody ever got fired for buying Microsoft!

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

    1. Re:Merchadising by Anonymous Coward · · Score: 0

      may the source be with you!

  21. Re:The trend is negative by Anonymous Coward · · Score: 0

    Whole PC industry is dying. As well as telecomunication market.

  22. 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
  23. 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.

    2. Re:Re-inventing the wheel by ClosedSource · · Score: 1

      It depends on the nature of the UI and the nature of the hardware. Traditionally an embedded keyboard might just be a dumb matrix of keys that are scanned by the CPU and the "display" might consist of a handful of discrete LEDs. Desktop based OS's aren't likely to be very helpful for such a product.

      On the other hand if you're talking about scaled-down PCs that are often mistakenly referred to as embedded systems, then yes, a desktop OS (Linux or whatever) is a slam-dunk.

  24. I read the title too fast and... by Snake · · Score: 1
    I understood that RedHat somehow managed to dissolve the Co$ on the net.

    Sigh.

  25. Re:dissolution of eCos? by Fiver-rah · · Score: 1
    You'd have to ask a chemist.

    You mean dissolution as in eCos --> e- + Cos+? I guess it depends on the solvent. Try United Linux.

    --
    Read Bujold. Free (as in
  26. If this were microsoft... by FearUncertaintyDoubt · · Score: 1
    ...then they would just close the book, and that's it. Poof! Call MiniTrue: XP Embedded OS doesn't exist, XP Embedded OS never existed. But being open-source, anyone who thinks that Red Hat made a mistake and is abandoning a viable product has the right and the ability to take that source code and make it work.

    So don't bitch about it unless you also want to admit that you don't have the ability or the inclination to do anything about it.

  27. Mandrake is working Raster by Anonymous Coward · · Score: 0

    Well, the embedded business is tough. Not sure how one makes it in that part of the industry without the demaded for embedded chips. The logical course is to do what Redhat is doing and change it slightly so that the structure is more benifical..

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

    1. Re:confusion regarding term embedded by doctormetal · · Score: 1

      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.

      That's where you're wrong. A modern car needs a complex multithreading realtime os to get it running. It isn't just about letting the engine hum. There's much more to that.

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

  30. What this is really about... by Rotten168 · · Score: 1

    Linux companies are laying people off in large numbers and this is just a continuation of that trend.

  31. 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
  32. 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.

  33. In other news.... by Ian_Bailey · · Score: 1

    Red Hat is dropping hints about a common Desktop Linux. Article on C|NET

    "We think we can deliver a fully integrated solution that is based on open-source technologies," Szulik said. A year ago, information technology executives didn't consider the issue, but "I would say it's accelerating (and) showing up in three to four conversations a month now with chief information officers."

  34. Red Hat Dissolves... by Kevin+DeGraaf · · Score: 0, Troll

    Darn it! I read the first three words, got exited, and then was crushed with disappointment to see "eCos Team" (whatever the hell that is) afterward.

    Down with Red Hat!

    --
    We have more to fear from the bungling of the incompetent than from the machinations of the wicked.
  35. 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.

    1. Re:Take your RISC and shove it. by Anonymous Coward · · Score: 0

      If your 'programmers' have problems with endianness, I can't imagine wanting to use any of their code.

  36. 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
  37. actually, the strategy is... by Anonymous Coward · · Score: 0

    the "save money because we're gonna be dead in the water in two years" strategy.

    good luck.

  38. Tip of the Day by Anonymous Coward · · Score: 0

    If you make a product with a license hostile to business, you are not going to profit. Until the GPL is dropped, Linux will continue to falter. My suggestion is to switch to MacOS X or FreeBSD.

  39. Is CLIT right for me? by Anonymous Coward · · Score: 0

    How do I know if CLIT is right for me?

    --A different AC than the other guy

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

  41. eCos is GPLd by Anonymous Coward · · Score: 0

    eCos 1.3.1 is indeed not GPLd (it is under the RHEPL, an MPL derivative), however the stuff in the eCos CVS repository is GPLd. Or more accurately it is GPLd with a special exception to make it more suitable for embedded systems.

  42. *BSD Is Dying by Anonymous Coward · · Score: 0

    Netcraft has now confirmed BSD is dying Yet another crippling bombshell hit the beleaguered BSD community when recently IDC confirmed that BSD accounts for less than a fraction of 1 percent of all servers Coming on the heels of the latest Netcraftsurvey which plainly states that BSD has lost more market share this news serves to reinforce what weve known all along BSD is collapsing in complete disarray as further exemplified by failing dead last samagcom samagcom in the recent Sys Admin comprehensive networking testYou dont need to be a Kreskin amdestcom to predict BSDs future The hand writing is on the wall BSD faces a bleak future In fact there wont be any future at all for BSD because BSD is dying Things are looking very bad for BSD As many of us are already aware BSD continues to lose market share Red ink flows like a river of blood FreeBSD is the most endangered of them all having lost 93 of its core developersLets keep to the facts and look at the numbers OpenBSD leader Theo states that there are 7000 users of OpenBSD How many users of NetBSD are there Lets see The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1 Therefore there are about 70005 1400 NetBSD users BSDOS posts on Usenet are about half of the volume of NetBSD posts Therefore there are about 700 users of BSDOS A recent article put FreeBSD at about 80 percent of the BSD market Therefore there are 700014007004 36400 FreeBSD users This is consistent with the number of FreeBSD Usenetposts Due to the troubles of Walnut Creek abysmal sales and so on FreeBSD went out of business and was taken over by BSDI who sell another troubled OS Now BSDI is also deadits corpse turned over to yet another charnel house All major surveys show that BSD has steadily declined in market share BSD is very sick and its long term survival prospects are very dim If BSD is to survive at all it will be among OS hobbyist dabblers BSD continues to decay Nothing short of a miracle could save it atthis point in time For all practical purposes BSD is dead BSD is dying