Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Red Hat Software Businesses

Red Hat Dissolves eCos Team, Changes Embedded Strategy 111

Posted by chrisd 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."
This discussion has been archived. No new comments can be posted.

Red Hat Dissolves eCos Team, Changes Embedded Strategy More

Red Hat Dissolves eCos Team, Changes Embedded Strategy

Comments Filter:
  • 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 (Score:5, Informative)

      by Anonymous Coward on Monday June 24, 2002 @02:22PM (#3758264)
      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.
    • 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....

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

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

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

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

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

    • Screw RootHack (Score:2, Interesting)

      by softweyr ( 2380 )
      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

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

  • Embedded OS, Windows XP and Nonsense. (Score:3, Interesting)

    by Vengie ( 533896 ) on Monday June 24, 2002 @02:17PM (#3758226)
    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. =)

  • GPL to blame ? (Score:2, Insightful)

    by brain-in-a-box ( 168001 )
    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.
    • 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?
      • 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.
    • 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 [redhat.com]

    • Re:GPL to blame ? (Score:3, Interesting)

      by Arandir ( 19206 )
      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.
    • 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.

  • Long live CYGNUS!!!!! (Score:3, Interesting)

    by BLAG-blast ( 302533 ) on Monday June 24, 2002 @02:20PM (#3758248)
    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...

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

  • Linux in the BIOS (Score:2, Interesting)

    by Anonymous Coward
    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.
    • 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
    • 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?

  • I am very disappointed. (Score:3, Informative)

    by rice_burners_suck ( 243660 ) on Monday June 24, 2002 @02:28PM (#3758298)

    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.

  • This is bad news for open source. (Score:4, Interesting)

    by Ludwig668 ( 469536 ) on Monday June 24, 2002 @02:28PM (#3758299)
    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.
    • This may be a "terrible blow" for eCos, but open source embedded Linux development is doing just fine.

    • Is it really bad? Remember Eazel? (Score:5, Insightful)

      by qweqwe ( 104866 ) on Monday June 24, 2002 @03:38PM (#3758742) Homepage
      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.

  • WHy OS in embedded apps? (Score:3, Interesting)

    by josh crawley ( 537561 ) on Monday June 24, 2002 @02:30PM (#3758318)
    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).

    • Re-inventing the wheel (Score:3, Insightful)

      by wiredog ( 43288 )
      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?

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

  • bad news for Linux? (Score:1, Interesting)

    by tps12 ( 105590 )
    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.

  • Merchadising (Score:3, Funny)

    by LowneWulf ( 210110 ) on Monday June 24, 2002 @02:48PM (#3758435)
    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 understood that RedHat somehow managed to dissolve the Co$ on the net.

    Sigh.

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

  • 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
  • Linux companies are laying people off in large numbers and this is just a continuation of that trend.

  • Idiots guide to embedded computers (Score:4, Informative)

    by Eric Seppanen ( 79060 ) on Monday June 24, 2002 @03:38PM (#3758736)
    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.

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

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

Slashdot Top Deals

Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker

Close