Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Interest in Embedded Linux Remains Low 270

burnin1965 writes "According to EE Times interest in embedded linux remains low. I was surprised to see their headline considering I just purchased a Sony TV which runs linux and I assisted my brother in setting up an Actiontec DSL modem which runs linux. A few years back I had only heard of devices that ran embedded linux and now that they are starting show up everywhere interest is low? The survey did bring up three issues which should be addressed by the embedded linux community, whether those issues are misconceptions or actual problems. 1) Incompatibility with software, applications, and drivers. 2) Performance or real time capability. And 3) support."
This discussion has been archived. No new comments can be posted.

Interest in Embedded Linux Remains Low

Comments Filter:
  • Dlink (Score:2, Informative)

    by Shinaku ( 757671 )
    My D-Link DSL604t is Linux based too, and so is my PDA..
  • Is 17% low (Score:3, Insightful)

    by Chrisq ( 894406 ) on Wednesday April 05, 2006 @06:14AM (#15064799)
    I would have said that 17% of designers using embedded Linux is quite respectable. I wonder what their target penetration was.
    • by soloport ( 312487 )
      I'd guess the numbers don't reflect reality -- developer reality. They probably reflect economic reality (where numbers are easier to track). There are three companies I know of, just off the top of my head, that use embedded Linux in their products (and have worked at two of them, myself). If you asked their PR department, "Do you use Linux in your products?" you'd probably either get a blank stare or a dismissive "No. Our products work with Windows." i.e. Only Engineering has a clue.
  • by Anonymous Coward on Wednesday April 05, 2006 @06:15AM (#15064803)
    If I'm going to make a million of something, I'm willing to spend a lot of money on engineering to save fifty cents per unit. I'm willing to spend the extra effort required to use Linux.

    On the other hand, if I'm making ten units of something, engineering time is my largest expense. In that case, I don't particularly care about license fees or the cost of the tools, I just want to get the job done as fast as possible.

    So, consumer goods will use Linux but most developers don't design those. Most developers work on projects that won't be produced in large numbers. Therefore most developers will continue not to use Linux.
    • by dhasenan ( 758719 )
      Related to that principle, to avoid licensing fees for WinCE, you'll be willing to write your own drivers for a large-scale product, especially since it's one you designed and manufactured yourself. Microsoft doesn't write drivers for Sony televisions, after all.
    • by ricklow ( 124377 ) on Wednesday April 05, 2006 @09:21AM (#15065589)
      You've got it exactly backwards. If you're going to make a million of something, you want the bill of materials cost to be as low as possible, whereas you aren't as worried about the non-recurring engineering. That's why Linux, with it's larger memory footprint, but lower development cost, is often non-competitive.

      Look at the latest Linksys WRT54 router. They've abandoned Linux and gone to VxWorks, despite the huge up-front cost for WindRiver tools, but they can use half the memory chips. This is a big win on a large production run.

      On a limited production item, you often can't afford commercial tools, because it will make the selling price of your product non-competitive. Just the price of one copy of the VxWorks tools will probably add about $20 to the BOM cost on a production run of 1,000.
  • by bill_mcgonigle ( 4333 ) * on Wednesday April 05, 2006 @06:15AM (#15064804) Homepage Journal
    Only 17 percent of embedded systems designers are currently using embedded Linux, and 66 percent say they are either not interested in using it or do not expect to be using it anytime soon

    So, reading this backwards, a third of embedded systems developers are interested in embedded Linux and/or expect to be using it soon.

    Compared with where the market was five years ago this is huge. Of the other two thirds, a large percentage goes to TRON [] and probably VxWorks. And if you want vendor-provided qualified platforms and support, you can get that [] from the same folks who make VxWorks.

    Surely a change in survey results from a year ago is something to be curious about but there's no indication it's a trend.
    • Err, 1/3? More like one fifth of the market. Still not bad, but nowhere near one third.
    • Microsoft said the exact same thing about business interest in Linux []. In that case, however, almost a third of respondents were already running Linux and more than half were planning to evaluate it. A year later, the numbers were largely unchanged, and they made it a part of their "Get the Facts" FUD []. They can, and will, say this about any competing software that does not have a majority market share. They can also say it, even if they don't have a majority share themselves. They've said it so much, man
    • The EE Times article, and the conference survey are not news at all. This has been reported in the past over at In fact, the numbers are in the same ballpark last I looked.

      However, what's NOT being reported by the EE Times is what's significant here.

      If you look at the survery, the number of systems using linux is about 20-25% IIRC. Say it's 20%. This is in line with the survey.

      But the REAL interesting thing here is that Linux has come from virtually nowhere in the pa

  • GPL? (Score:4, Informative)

    by Anonymous Coward on Wednesday April 05, 2006 @06:16AM (#15064805)
    I developed an embedded device using NetBSD. I would love to use Linux, but the agressive stance of the GPL license (Linksys!!) keeps me away. I know many others that share the same view.

    Linux won't take over the embedded world, mainly becuase embedded is a commercial market. Who wants to invest money in developing a product, only to have the open source community go after you? And you get bashed for trying to earn a living.

    Before you flame me, I did make a good portion of the code used in my embedded device available to the BSD community. I won, they won. Nobody twisted my arm.

    I'm posting AC, STOP KARMA WHORING!!!

    • Re:GPL? (Score:2, Insightful)

      by kg4czo ( 516374 )
      The problems come when a company doesn't comply with the GPL. The thing is, you can use your closed and proprietary stuff in your products which you don't have to release the source to should you distribute it. Many companies are doing it, and still complying with the GPL. I would venture to guess that companies that don't get it and fail to follow the license would find themselves in trouble. It's the same for any other licensing schema: You break the rules, you either comply and make it right or you don't
    • Re:GPL? (Score:3, Insightful)

      by grimwell ( 141031 )
      Who wants to invest money in developing a product, only to have the open source community go after you? And you get bashed for trying to earn a living.

      I don't think the GPL crowd is "going after people for trying to earn a living", they are simply protecting their work. If you use GPL'd code, you have to make it available it... those are the conditions of use. Pretty simple.

      I developed an embedded device using NetBSD. I would love to use Linux, but the agressive stance of the GPL license (Linksys!!) keeps
    • I did make a good portion of the code used in my embedded device available to the BSD community. I won, they won. Nobody twisted my arm

      You're the exception. The number of GPL violations (specially in embedded products) is increasing at an alarming speed. We're lucky that Linux is GPL, if they're not collaborating even when licenses forces them it's easy to imagine what would happen if the license wouldn't force them

      Who wants to invest money in developing a product, only to have the open source community go
    • So you made the code available anyway, but the GPL is somehow unacceptable? The GPL is arm twisting? You have a problem with people putting some restrictions on code they give away for free, yet you want to reserve the right to keep your code proprietary? I find that pretty hypocritical.

      Just FWIW, I recently bought a Sony TV. It included a copy of the GPL. You can get the code for all the GPLed software the thing runs.

    • Re:GPL? (Score:4, Insightful)

      by gowen ( 141411 ) <> on Wednesday April 05, 2006 @07:48AM (#15065045) Homepage Journal
      And you get bashed for trying to earn a living.
      I think you mean "You get bashed for trying to earn a living off other people's work, without giving anything back."

      The rules are simple : reciprocate or fuck off.
      • The rules are simple : reciprocate or fuck off.

        That's what I dig about the BSD license. It comes without the attitude and ideological baggage. It actually is free software, no strings attached. It's not a shoehorn to get you to buy into a philosophy.

        Most embedded systems are one big statically-linked executable. If you use any GPL code at all, you're required to place the entire work under the GPL. Not only that, but you must provide the tools needed to compile and install it. This is the bit tha

        • Re:GPL? (Score:2, Informative)

          by gowen ( 141411 )
          scripts used to control compilation and installation of the executable.
          GNU GENERAL PUBLIC LICENSE, Version 2, June 1991
          That doesn't mean you need to supply the compilers/parsers/toolchain.
          It just means you need the Makefiles / install scripts etc.
    • Re:GPL? (Score:2, Insightful)

      by Anonymous Coward
      I agree that the GPL is largely to blame.

      It's not at all about not wanting to give back your changes. The main problem is the static linking clause (LGPL kindof solves that).. in most of the projects we made, there is some part (think decoders, etc) that's licensed from a third party and simply can't be shared.
      So that rules linux right out, cause more often that not everything's linked together into one big image.

      We've considered using open source libraries quite often.. it'd be great to be able to use a ne
  • by dattaway ( 3088 ) on Wednesday April 05, 2006 @06:16AM (#15064807) Homepage Journal
    Nothing is going to change the fact it is a Sony.
    • you mean it will always be good quality? :p I wasnt affected by the rootkit fiasco as far as I know - I do consider that low, but I've always thought of music publishers as bastards, and it hasnt affected how I view Sony as a laptop/console maker. The companies are linked by the brand name, but I doubt an engineer working on the PS3 would have installed a rootkit on people's machines without their knowledge. Also, wasnt it a 3rd party company that developed the software? The decision to add it was probably
      • I'll never buy another Sony product.
        But for me, the rootkit fiasco was just the final nail ... imho, the quality is no where near what it was 15-20yrs ago. Their products still command the price premium of the brand, but don't deliver any better quality than Samsung (as one example).
        No, I don't have any actual stats or failure rates, it's just my opinion based on personal experience of me and others I know (yes, a small sample blah blah blah...still my opinion)

        What I do think this shows is that companies

        • "[Sony]are part of IBM's OIN which (if I read it right) is a bunch of companies agreeing to share their innovations (and patents) for the greater common good...that's very contrary to the Intellectual Monopolists that normally lurk the patent hallways...and seems contrary to the general patents-are-necessary! propoganda, no?"

          Isn't this a good thing? I dont doubt that Samsung are a good company also, my last 2 mobiles have been Samsungs, and if I were buying a laptop then I likely wouldnt go for a VAIO b
    • Nothing is going to change the fact it is a Sony.

      You expect it to work as well or better than your Play Station. If it came from Microsoft, you probably would not expect the same. There are levels of hell in the non free world.

  • by Neo-Rio-101 ( 700494 ) on Wednesday April 05, 2006 @06:23AM (#15064822)
    Perhaps this is just a wake up call to companies who support embedded Linux to perhaps spend more on advertising and marketing (i.e. "hello world, we support Linux embedded because we made a pile of decent kernel patches so we can be trusted.")

    Compatibility testing, and wedging in those RTOS kernel patches and supporting those where appropriate can't be a bad thing either.

  • by DrXym ( 126579 ) on Wednesday April 05, 2006 @06:23AM (#15064823)
    My feeling is the latter. My Netgear ADSL modem / firewall uses embedded Linux. If not for a "debug mode" hidden in the advanced settings which enables you to SSH into a busybox shell, I wouldn't know nor care. The thing just works and it works very well. I expect millions of people are running Linux in their homes in their modems, TVs, audio / DVD players, washing machines or elsewhere and simply don't know it.
  • by BadAnalogyGuy ( 945258 ) <> on Wednesday April 05, 2006 @06:25AM (#15064827)
    Issue 1 is not a big problem. The programming model is well-understood, so at the application level there really isn't a lack. However, there is little support for specific stuff that hardware vendors may want to do (like say a CDMA RIL) and the implementation of those features is pretty difficult.

    The second issue is a real concern. User experience is significantly degraded when the interrupt latency is longer than the expected reaction time. There are ways to reduce the interrupt latency in Linux, but the side effects are undefined.

    Support is only an issue because it is so expensive. Likewise, there are only a few top-tier Linux vendors who can offer good support. Montavista, for example, is one of the premier (if not the premier) embedded Linux vendors, but they can't support everyone who wants to build a Linux-based embedded solution. They pick and choose their support contracts, and anyone not selected needs to find someone else with the relevant support capabilities.
  • by gb7djk ( 857694 ) on Wednesday April 05, 2006 @06:38AM (#15064857) Homepage
    Which question were people answering? Are you intending to use an "embedded linux" or just "linux" in a small standalone device? We use a "standard" linux in several standalone devices. We have no need for, nor do we want to use a "specialist" distribution because we do want to be locked in. It is no coincidence that one of the more fertile areas of cpu support development in the kernel, at the moment, is for ARM devices.
  • dont forget #4 (Score:3, Insightful)

    by nurb432 ( 527695 ) on Wednesday April 05, 2006 @06:41AM (#15064868) Homepage Journal
    Most embedded applications dont even need an OS.. thats overkill for them and would only serve to raise the end cost. You dont need linux in your Microwave for example.
    • Most embedded applications dont even need an OS

      Eh? Anything with more than 2 components (aka, every electronic consumer product) needs an OS. Devices don't just cooperate on their own.

      • Eh? Anything with more than 2 components (aka, every electronic consumer product) needs an OS. Devices don't just cooperate on their own.

        And if the device is going to have an friendly interface for the point and click crowd, a web server is also needed.
      • Re:dont forget #4 (Score:2, Informative)

        by sglow ( 465483 )

        Most embedded applications dont even need an OS

        Eh? Anything with more than 2 components (aka, every electronic consumer product) needs an OS. Devices don't just cooperate on their own.

        That's ridiculous. Just because something has a processor in it doesn't mean it's running an operating system.

        Most embedded products still run on simple 8 bit microcontrollers. These all run some software, but most don't run anything that could be called an operating system.

        Think along the line

        • Someting in a loop waiting for an event to work on is a pretty good description of what an operating system actually does. According to my CS class on operating systems an OS is "a program that controls all resources, starts and stops tasks (processes, programs...) and assigns ressources to and withdraws them from the tasks".

          Please, this is a site for nerds, and nerds should be able to distinguish between 'OS' and 'OS + Shell + Tools + User Interface' (which the layman was told by the marketing to call an o
          • Re:dont forget #4 (Score:3, Insightful)

            by Valdrax ( 32670 )
            According to my CS class on operating systems an OS is "a program that controls all resources, starts and stops tasks (processes, programs...) and assigns ressources to and withdraws them from the tasks".

            Such a thing is generally referred to as an OS if it's responsible for handling the execution of other programs that are loaded and unloaded from memory. However, if such a program is the only program running on a device, then it's generally not considered an OS. Most embedded systems have only a single p
          • Someting in a loop waiting for an event to work on is a pretty good description of what an operating system actually does. According to my CS class on operating systems an OS is "a program that controls all resources, starts and stops tasks (processes, programs...) and assigns ressources to and withdraws them from the tasks".

            That's a pretty broad definition of "OS". And even so, it doesn't fit many embedded systems. The "starts and stops tasks" bit just plain doesn't exist for simple event-loop driven

          • All OSes are not created equal.

            What is ment in this article with "OS" vary quite a bit from person to person. Point is that there is a very large difference between the "while (1) { run all apps once }" and a complete OS environment like Linux.

            If you have a small embedded system it's quite probable that the while loop approach will do just fine. It may even do better than a Linux solution.

            Furthermore standard Linux requires a MMU in order to run; there are many processors out there without MMU. (You can get
    • could never benefit from an OS? ave.html [] this one surely could.
    • You dont need linux in your Microwave for example.
      So how do you SSH into your toaster then???
    • Great point. Embedded developers need to ask what they want from an OS. Threading? There are several lighweight OS independant packages out there. pt threads is my favorite. Maybe you just need a round robin processing loop. Device driver frameworks for chip peripherals? Posix-like drivers are also easily developed without an OS. If you get to the point where you must run multiple processes and you need interprocess communication or full blown networking and have a larger device (ARM, PPC), then yes reach f

  • Not surprising (Score:5, Informative)

    by Wackston ( 80353 ) on Wednesday April 05, 2006 @07:13AM (#15064947)
    I work for a large CE company that is using Linux for a major TV-related project.

    This, sadly, is very much an pointy-headed-boss driven decision. From the perspective of the HW/SW teams its just plain stupid. The problems are probably pretty representative why those 66% aren't looking into Linux.

    Its gross overkill. Linux architecture is for general-purpose multi-user information processing loads. It does a whole bunch of things that are simply ballast for an O.S. that is there simply to control some special-purpose hardware and run a simple on-screen-display. Bigger micro, larger flash footprint, more on-chip RAM gobbled. This really really hurts in a genuinely cost-competitive marketplace. If you're building an Net appliance type of thing of course Linux is almost a turn-key solution. For embedded control... its the wrong kind of OS.

    Licensing is a pain if you have non-trivial know-how you don't what to gift your competitors realised in your Firmware. You end up doing really vile hacks like doing stuff in user space via 'dummy drivers'. Debugging becomes fun fun fun....

    The abstract machine doesn't fit. In the embedded control space sometimes the cleanest solution really is to do direct HW access. However, the hard kernel/userland divide of Unix O.S. makes doing this in a systematic, safe, way rather clumsy. You end up writing around a bazillion special-purpose HW-dependent ioctl's where what you really wanted was some selective access to the I/O bus. Then you need a HW workaround with hard real-time requirements and the 'fun' really starts.

    In short Linux is a fine information processing /network O.S. for embedded or general-purpose systems. Its very far from ideal for one-off embedded/control applications.

  • Midas XL8 (Score:2, Informative)

    by tehmorph ( 844326 ) *
    Don't know if any /.ers are familiar with the mixing console industry, but Midas are doing some pretty neat things [] with Embedded Linux on their new digital console (XL8).
  • Missing figures (Score:3, Insightful)

    by 1u3hr ( 530656 ) on Wednesday April 05, 2006 @07:33AM (#15064998)
    Well, TFA tells us haow many are using Linux, 17%, and are thinking about it, etc. But how can we make any conclusions form this when it isn't even hinted at what the other 83% are using? Some version of Windows? QNX? DOS? Is Linux at 17% the largest or much smaller than the others? Maybe the EETimes readers have the context, but I don't.
  • It's not just a case of features, but of mindset. A lot of embedded programmers prefer writing their entire software stack with direct access to the metal. To do otherwise takes a big adjustment in mindset, and a lot of companies simply don't have the time for it and therefore Linux.
    • NO ! Embedded programmers write to the metal because thats often the BEST way to eke performance from your LIMITED hardware/memory/battery life. Avoiding a whole OS makes enormous sense.

      Embedded programmers have a different mindset, because that why they're embedded programmers. If everyone started on embedded programming we might put an end to bloat.

  • Designers vs Units (Score:3, Insightful)

    by LordLucless ( 582312 ) on Wednesday April 05, 2006 @07:37AM (#15065015)
    The article talks about the number of designers who are working on Embedded Linux projects. It says nothing at all about Embedded Linux's market penetration.

    If, for example, you have 1000 projects using an embedded OS of some kind. Let's say 900 of these are going to be either small-run, specialised devices, or flops. The remaining 100 are consumer items, mass-produced and sold around the world. If Linux's 17% happens to account for a large proportion of the top 100 projects, their market penetration is huge. If it's 17% accounts only for small-run projects, then it's not doing that great.

    A better heuristic, IMO, would be how many units are being produced with embedded Linux, rather than how many designers are using Linux.
  • by deacon ( 40533 ) on Wednesday April 05, 2006 @07:45AM (#15065037) Journal
    Other possibility is that this publication is doing what mainstream media has been doing for years:

    Trying to create a trend or perception where there is none. Witness all those smarmy "the suit is back" articles.

    In addition to accepting paid and free propaganda, trying to create public hysteria to influence political outcomes, the MSM survives on renting reader's eyeballs to advertisers. Whatever it takes to do that, they will do. Slashdot itself has fallen into that same cycle, with regular articles about "political" subjects sure to get 800 replies (and corresponding ad impressions) but with no valid technical content.

    New SuperSig:


    Make the requirements to vote the same as to own a gun.

    Simply go to the polling place, fill out a Form 4473 [], show your ID [], and the poll worker will check with the FBI database [] to make sure that you're not prohibited from voting. If everything is working correctly, you will be allowed to vote in a few minutes.

    If the GCA/Brady system doesn't violate the rights of gun owners, then what possible objection could there be to implementing the same system for voting?

    Robert Racansky

  • big surprise. (Score:5, Interesting)

    by nblender ( 741424 ) on Wednesday April 05, 2006 @07:50AM (#15065056)
    Hardware designers generally start with an eval-board of some sort so they can hack up their add-on hardware and get something running on the bench before drawing schematics on napkins and starting to do a layout. As such, they need a 'board support package'. You generally buy that from an embedded systems vendor. You generally don't just download the latest linux kernel and start porting drivers and vm maps. Your management will likely want you to get a BSP from a commercial vendor to whom they pay maintenance so your engineers can hassle them about bugs in the bootloader, etc... Your choices are limited. Generally something like Montavista, Windriver, QNX. In my experience, Montavista makes it hard to do business with them. You practically have to bribe them to talk to you in the first place; even when you're waving around PO's. You've already bought the hardware from Intel or RadiSys and now you need support for the BSP. When you finally get a price, it's $18k per seat for a GCC license, and support is $5k/year; maximum of 5 incidents.

    QNX on the other hand, will practically send an engineer on site to hold your hand while you get your BSP running. Support is cheap and the runtime licenses are down in the noise threshold.

    Sure, QNX has a few issues. So does VxWorks. But Linux is a real lose, and I've tried.

    Frankly, if I was starting from scratch and rolling my own BSP, I'd choose NetBSD. Embedded friendly license, code purity, and it probably already has your processor arch.

    • Re:big surprise. (Score:2, Informative)

      by girmann ( 34561 )
      There's a fundamental misunderstanding here - GOOD Hardware engineers start out by asking "What OS vendor are you going to use?" before buying an eval board and dictating what OS to use by their choice of processor vendors.

      It's true that once the OS and eval boards are selected, a BSP has to be created by one of those vendors. This is much further down the line and usually must be well thought out in order for a project to be successful. Working with MontaVista is a pain, though.

      Not to be a shill for Cirr
      • That's a qualitative statement and not a fundamental misunderstanding. I've worked in/with embedded sw/hw for 21 years across a half dozen companies (large and small). I know a good hardware team from a bad hardware team. Generally, unless there's religion, the software guys are OS agnostic. Good software guys are OS agnostic. Sure, everyone has their personal preferences, but you do what the product needs. On a good hardware project, you choose your primary devices based on the performance level
    • Re:big surprise. (Score:3, Interesting)

      Yup you got it. Thats absolutely right about MontaVista, Eval Boards and licensing costs. Although I will add a few more tokens to the mix.

      Another thing that happens is if your product uses DSPs, the hardware people will expect that you will not even use an embedded OS and write the application directly to hardware. As one HW engineer told me, "Its very easy, what do you mean you need a driver? When I did it it was just one line of C code (to write data to memory)." Once I pointed out we were upgrading
    • Frankly, if I was starting from scratch and rolling my own BSP, I'd choose NetBSD. Embedded friendly license, code purity, and it probably already has your processor arch.

      I noticed our Ricoh Afficio copier/printer/scanners run NetBSD embedded. I wondered why then thought "of course it runs NetBSD!" I haven't tried hacking into them, but there doesn't seem to be many accessible commands.
  • But they are mostly behind schedule []

    "A new survey released at the Embedded Systems conference reveals that more than half of all current embedded design projects are running behind schedule."

    "The survey -- dubbed the "2006 State of Embedded Market Survey" -- indicated that some 55 percent of current embedded design projects are late or have been cancelled."

    How accurate can any survey be when over half the projects are late and/or are being canceled? Bad mojo in the field of EL and not a good time t
  • found that 34 percent of respondents were not interested in using Linux.

    66% are using or are somewhat interested?
    So that's a good thing.
  • The article talks only about the number of programmers using embedded Linux. It fails to mention the percentage of shipped devices that use embedded Linux. It could be that the embedded world is more specialized, requiring more specialized function from an OS. The devices that can use a more general purpose OS (DVRs, webcams, ADSL routers, etc.) don't need many programmers, but ship a lot of units.
  • OK, I am a firm beleiver in embedded Linux, extreme SFF computers and/or "OS-on-a-chip". After review of the Article and posting it appears most ppl think of embedded devices as strictly "consumer" type products. Rightful so as the article did not address "who" (read end-user) target the embed was targeted for. Yet there are hundreds products on the market for Industrial control applications and thousands of consumer products. If the the designers surveyed where from the industrial controls sector then yes
    • I do agree with you that industrial computers generally are cheaper for data processing. I'm not so sure that means that PLCs will totally disappear though. There are quite some smallish PLCs that are cheaper than a PC, althogh their computation power is severly limited. I have worked with $100 PLCs and although they aren't any powerhouses they are totally acceptable for simple tasks, like controlling a small machine. And they are far easier to program for the typical person to get the task. The graphical p
  • If you have a single application device, it really does not need a comprehensive, separate "OS". If and when you need process management and memory management and sharing of I/O resources between modules/processes, you need SOME libraries/headers to do that. If you want to have layers of abstraction (say, high level I/O or media codecs) to help in development, you need also some libraries for that.

    But up to a point you are free to use per application designed common libraries and run-time systems, you don't
  • The other opinion (Score:2, Informative)

    by FreakGeek ( 145457 )
    Interestingly, there are other voices that seem to report the contrary. [] for example features the "Great Gadget Smackdown" where the numbers of embedded deployments of Linux vs. Windows in end user devices are compared.

    This is interesting stuff, as Linux, although behind Windows embedded in certain device types like smartphonse, is constantly gaining market share, and clearly leads in devices like firewall, router and wifi appliances.


  • There are a few problems running Linux in an embedded environment, but as far as I have seen the problems are more of the questions regarding power economy and ability to go into suspension and deep sleep for a defined period of time and then wake up and continue from where I was when I got to sleep.

    There are already a surprising large amount of drivers around that actually works well on embedded devices as well, as long as you behave nicely and issues ordinary shutdowns. And if there isn't a device drive

  • Bogus Survey? (Score:2, Insightful)

    by alas_anon ( 856853 )
    I can't find the actual survey online. I found some other articles by people with the same frustration. I want to see how the questions were framed.

    I have done embedded design for more than 20 years. I have been subjected to many goofy surveys than were written by marketing suits who were clueless about how to ask proper questions. The typical survey says "Will you be doing an embedded design in the next 6 months? Y/N" and then it gives some kernels to choose from. The category of "hand rolled" is always

  • My Experience (and my current job) says that the post is wrong.

    We're developing an embedded medical device with millisecond lantency needs.
    We get to use a 192MHz arm chip which is more then enough to use a linux kernel and drive our application. It's not hard real-time like a rocket control but it's more then enough for us.

    Kernel and framework support for the popular embedded boards and chips (arm) is growing extremely fast, so much so that its better (for us) to use the latest distributed kernel then attem
  • Embedded Linux, even as ucLinux with uclibc etc is still fat for an embedded OS. Others like ecos, freertos etc are a much better fit. And so are the nice commercial offerings like qnx palmos and vxworks. You just have to add expensive ram and flash to make it boot linux in any form, and it cant be a 16-bitter. The only reason you see Linux being used is for hardware support and its nice networking, which is almost matched now by ecos' offerings.

    I think for most small devices Linux is just too big. However
  • I frequently connect to Freenode for IRC'ing and automatically join several programming channels (#zaurus, #squeak, #ruby, #python, #scheme, etc.) and I check out the #openembedded channel as well. Not sure if channel users is a fair metric of an offering's popularity, but typically the #openembedded channel only has three users listed.

    I personally have dabbled in developing on Embedded Linux PDA's and enjoyed it. But it seems as the hardware vendors out there (at least based on what's available in the U.

  • Embedded Linux is show up everywhere that I've encountered. Linksys routers, cell phones, PDAs. I was even surprised to find it in Quantum DLT Tape Libraries, controlling the robotic arm, etc.
  • by alaloom ( 966252 )
    17% of embedded market is absolutely amazing imho. Unlike PCs, there are many choices for an embedded operating system. Most commercial embedded OS vendors could not even dream about reaching such high audience. I've read somewhere (and I agree) that if you need a filesystem and/or a TCP/IP stack you should consider Linux for an embedded system.Maybe I would expand this to include a USB host. If you don't need TCP/IP stack/Filesystem/USBhost then my personal favorite is Labrosse's microC/OS-II (amazing c

e-credibility: the non-guaranteeable likelihood that the electronic data you're seeing is genuine rather than somebody's made-up crap. - Karl Lehenbauer