Slashdot Mirror


Linux in Embedded OSs

Carnage4Life writes "ZDNet has an article on the viability of Linux as the future belle of embedded OSes. It quotes Linus as mentioning the fact that since license fees are free and developer support is relatively abundant, Linux is a prime candidate for startups creating Web appliances and the like. It lists Sony's, tiVo, Lineo, Transmeta, Intel and national Semiconductor as major industry players who are embracing embedded Linux. "

26 of 75 comments (clear)

  1. Re:Here's what the GPL says: by AstroJetson · · Score: 2

    I don't presume to speak for Stallman on this issue (or any issue for that matter), but I'm fairly certain that the spirit of the GPL is to allow proprietary code to co-exist with GPL'd code where appropriate. The more I think about this the more I think that the GPL needs to be modified to make it more explicit. To not do so only hurts Linux in the embedded arena. Which incidentally, I think is an area where Linux stands to make some of the biggest gains against other OS's.

    How should we go about contacting Stallman to see if he is in agreement with this and hopefully get either a clarification or modification to the document?

    On a different note, as I understand it, the BSD license doesn't suffer from this problem due to its 'non-viral' nature. Is this correct? Are there any BSD-based embedded solutions out there? If so, is source available?

    --
    Admit nothing, deny everything and make counter-accusations.
  2. What does "Embedded" mean these days? by AstroJetson · · Score: 4

    Let me preface this by saying that I've been an embedded developer for about 9 years.

    Traditionally, the term "embedded" denoted a system with minimal (or no) UI. Code for such a system could not be developed natively so development was done on a host and 'installed' on the target via an emulator, debug port, PROMs, etc. Typical examples are heating/cooling systems, flight control systems and microwave ovens. In my case, they are traffic controllers and other associated equipment.

    Things like Web Pads and Palm Pilots seem to blur the distinction between embedded and non-embedded systems. While code is still developed on a host (for the most part), many of these devices have quite sophisticated UI's (even GUI's). What do you think? Should they still be considered embedded or should there be some new term to describe them? Maybe I'm just old-fashioned, but I have a hard time thinking of anything with a GUI as embedded.

    --
    Admit nothing, deny everything and make counter-accusations.
  3. Application Appliances by MattMann · · Score: 2
    We really need a new term to be able to remove this confusion.

    The word people are using for a bunch of this stuff is "appliance". This generally refers to the "instant-on" category, where you don't see an OS "booting", and then you don't see a shell either, except to implement what is generally considered an Application. Problem is, appliance by itself is not distinguished from washing machines, so there's the urge to say information appliance which works great for palms and webpads but not for "gameboys" or who knows what. How about application appliances, or "app-apps". Catchy?

  4. The GPL makes Linux the wrong choice. by Brett+Glass · · Score: 2
    Even Cygnus, which has always promoted GPLed software, recognized that the GPL's anti-business nature and "viral" terms made it the wrong choice for an embedded OS. Hence the eCOS license, which is much different.

    As an embedded system developer, you cannot afford to use anything GPLed. PicoBSD, QNX, and other OSes without "poison pill" licenses are better choices in this realm.

    --Brett Glass

  5. Re:Too much OS? by GregWebb · · Score: 2

    Palm user here :)

    My take on it isn't actually that at all - more that Palms succeeded mostly due to having just enough functionality while being cheaper. WinCE boxes are more powerful but the benefits aren't always clear to the user comparing the two in Dixons, while the Palm costs £100 less. So which do they buy? ;)

    They're nice machines, sure, but I don't think the interface is actually as nice as some people seem to think.

    Greg

    --

    Greg

    (Inside a nuclear plant)
    Aaaarrrggh! Run! The canary has mutated!

  6. OK, but why is it REALLY being chosen? by GregWebb · · Score: 2

    It's certainly interesting to see this, but...

    I remember moans about covermounted applications 5-6 years ago with the Amiga magazines. The main problem from the developers was that, when something was essentially free, it doesn't have to be better, just good enough. And good enough is a pretty low threshold - people will put up with quite a bit if it saves them money.

    I'm glad to see Linux expanding into new markets. It's not for me right now, but it's good to see community development having such a huge impact. But is it chosen because it's better or because it's good enough and free?

    Sure, there's the cost of porting (well, sometimes) and the cost of striping it down to what you need (well, sometimes again) but after that it's free. You give the code back - not a problem, it was cheap to modify anyway in the corporate scheme of things - and it's suddenly zero unit cost as well as short development time. Plus, sites like slashdot give them free publicity! Now, how many bean counters are going to work against that one?

    I'm sure there are companies who've chosen Linux purely thanks to technical superiority. Really, I am. But I suspect most are simply using a cheap shortcut that generates them good publicity via the Linux bandwagon.

    Greg

    --

    Greg

    (Inside a nuclear plant)
    Aaaarrrggh! Run! The canary has mutated!

  7. Re:BSD vs GPL for embedded systems by Embedded+Guy · · Score: 2

    Yes, licensing is the real problem. As an embedded developer I've often found that some functional component I need in my system is right there in the linux sources. But for a variety of reasons it isn't possible to release the source for our product, as the GPL requires. We usually end up buying commercial packages or reinventing the wheel. The GPL has been great for promoting linux and a lot of software for the workstation/desktop environment but its more like a poison pill for embedded software in commercial products. Until someone clarifies how GPL code and proprietary code can coexist in one product without compromising the proprietary part, I think embedded system developers will tend to stay away.

  8. Windows CE by SheldonYoung · · Score: 5

    There is already a project to port Linux to devices which currently run Windows CE. They have already made excellent progress and Linux now boots on several MIPS and SH3 handhelds, such as the Casio E-100 and IBM WorkPad Z50.

    See the Linux CE Project.

    1. Re:Windows CE by T-Punkt · · Score: 3

      Same for NetBSD:

      See NetBSD/hpcmips for MIPS based PDAs.

      There's of course a SH3 port as well: NetBSD/SH3, but they currently don't support any SH3-handhelds (AFAIK).

  9. Multi-Jesse Theory by Industrial+Disease · · Score: 2

    It ain't just Linux. If you read his column regularly, you'll see him flip-flop on every issue of contoversy in the industry: MP3, net appliances, Chipzilla, etc. Either the guy has a serious case of Multiple Personality Disorder, or "Jesse Berst" is a pen name being used by a pool of writers. I suspect the latter.

    --
    Weblogging Considered Harmful:
  10. poison pill vs. vitamins by MattMann · · Score: 2
    Clearly, the poison pill for you is the uncertainty, rather than the GPL itself. This is what I was referring to: it would seem to make sense for the embedded platform vendor to do all the leg and legal work on this so they could deliver software with no uncertainties attached. They might be able to contact all of the individual licensors that they include in their distro to get agreement in advance.

    So, the question in this case is: is there any inherent problem with the GPL? It doesn't seem that there is because Transmeta has crossed this bridge. If there is no problem, that needs to be made clear by... ? by advocates who wish to see either linux or the GPL adopted.

    But, Embedded Guy, have you looked at BSD licensed stuff at all? Also, who are you embed with? ha ha.

  11. Re:ZDNot by Carnage4Life · · Score: 2

    Hi Signal,
    I submitted the story and I disagree with your post. Yours is a case of ignoring the message because you do not like the messenger. The primary reason you give for disliking ZDNet seems to be Jesse Berst who isn't even a reporter but an opinion columnist this is similar to disregarding news from CNN (which is the premier news service in the world and watched in over 100 countries) because they have a show with Johnny Cochran as a host. I primarily read ZDNet because they report more Windows bugs and security leaks faster than any other mainstream Tech news provider (not before Bugtraq but they aren't mainstream), they are good at reporting industry trends and Dvorak's opinions are interesting. Up until i started reading Slashdot I had never heard of Jesse Berst and after I read one of his articles I realized he didn't know his head from a hole in the ground and stopped reading his opinion pieces (Linus as hardware man of the year?!?). So dismissing ZDNet because of Jesse Berst is not only an illogical decision but also robs you of hearing different views on the technology industry beside linux r00lz, MSFT sUx that fills the threads on Slashdot.
    The main reason I submitted the story was because I though it was neat that Playstation 2 would run linux as well as web appliances from Intel and National Semiconductor. On slashdot I've read discussions on Lineo and Transmeta several times but didn't know about Sony, Intel or National Semiconductor and their work on using embedded linux. Therefore I thought it would be nice to hear the views of informed hardware people on these developments.
    Thanks for your time :)

  12. ZDNot by Signal+11 · · Score: 3
    Hmm, another filler article for mass consumption by slashdotters, and pleased to be clickink on the banner ads. Quick, somebody pass me the salt, this article tastes bad!

    It may be flamebait, but I think ZDNet has become see-through in the lip-service it's paying to linux. I point you no further than Jesse Berst, who in his "berst alerts" went from "linux sucks - it'll never compete with windows!" to "I always said linux could be a contender" to "linux rulez" in a span of 5 months. Something ZDNet should try someday: balanced reporting. It's a novel concept I urge any reporter (slashdot included) to employ - *represent both sides equally and without bias*.

    1. Re:ZDNot by Gurlia · · Score: 3

      OK, at the risk of being flame-bait... may I point this out: has it ever occurred to you that Jesse Berst might have gone through a "conversion"? Is it so inconceivable for a person to believe in popular FUD against Linux and to speak out his belief? Is it so inconceivable that this same person may have found out eventually that there is more to Linux than the FUD would have people believe? You have to realize that reporters usually do NOT have the means nor the time to do a 100% accurate research about their subject. They go by what they judge to be an accurate picture based on the majority of information they collect -- if this majority happens to be tainted with FUD, it should not be surprising that their views show this too.

      But after 5 months, if the reporter is worth his salt at all, he'd have dug deeper and perhaps discovered that Linux really isn't what the FUD depicts it as, and that there is a glimmer of truth to the claims made by Linux supporters.

      I hate to say this, but Slashdot seems to be home to a lot of paranoid people who believes that popular media is a Big Satan that is totally clueless and always inaccurate. While it *might* be true that popular media is usually inaccurate, that doesn't justify the conclusion that *anything* from the media is not reliable. So please, people, before flaming this article to death, let's do some research and let's show some hard evidence of why this article is so lousy, as it's claimed to be. Pointing fingers at a reporter's reputation is not sufficient grounds to dismiss an article.

      --
      mikre he sophia he tou Mikrosophou.
  13. An important point was missed by dsplat · · Score: 4

    Writing the code for an embedded product under Linux provides one huge benefit. The embedded OS does not depend on the plans of an outside company for porting to the next hardware platform you choose. And the application should port easily as long as you avoid, or isolate, hardware dependent code. For companies for whom the OS they deliver their product on is a commodity item, open source OSs offer them a measure of control over the future of their product. Any hardware they choose can run the OS if the port is worth the effort. If having Linux run on your next hardware platform is worth enough to pay a few good programmers to do it, Linux will run on that hardware. No one can say no to you.

    --
    The net will not be what we demand, but what we make it. Build it well.
  14. Here's what the GPL says: by AstroJetson · · Score: 2

    This whole issue got me thinking, so I went back to the GPL to see what it sez... here are the terms for modifying the code:
    2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such
    modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

    a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

    b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

    c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)


    So far, so good. Now here's the troublesome part:

    These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be
    reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you
    distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.


    Now I would argue that my traffic controller software can be "considered [an] independent and separate work" and therefore should not fall under the GPL. But the last sentence seems to imply the opposite since it is distributed as part of a whole (Linux and my app are burned into the same PROMs). But if you look carefully you see that it only applies if it is a "work based on the program". The question is if a program is compiled and linked and loaded in the same set of PROMs as GPL'd code, is it considered a "work based on the program" or a "separate work"? I would argue the latter, but it's not entirely clear.

    Clearly, if my app is non-embedded and I distribute it separately in binary-only form (Netscape, eg), I'm not bound by the GPL. I'm sure FSF never considered embedded code specifically but I really don't think they intended embedded s/w to be treated any differently than non-embedded just because it is distributed differently.

    What I would like to see is for the license to be modified so that it explicitly deals with the case of embedded code. RMS, are you out there? What was your intention?

    --
    Admit nothing, deny everything and make counter-accusations.
    1. Re:Here's what the GPL says: by Embedded+Guy · · Score: 2
      AstroJetson, you hit the nail on the head there.

      In our product (part of which functions as a router) we would like to use components of the IP stack found in Linux distributions. Doing so would only require minor modifications (if any) to the GPL'd code to adapt it to our system. The rest of our system would not be derived from any GPL'd code. But the hitch is that our software is distributed in ROM in a piece of physical hardware. It is not possible to distribute our system software without the GPL components as "separate works". Hence the terms of the GPL seem to extend to the entire work and the poison pill goes to work. If the commercial embedded systems market is going to work with the GPL, I think the GPL needs to change the way it defines what is considered a separate work.

      Incidentally, I think the embedded systems world could benefit from some open source platform and component developments (like eCos) but the GPL is an inappropriate license for the reasons describe above.

  15. Re:Too much OS? by AstroJetson · · Score: 2

    But the other half was the size of the OS. It meant bigger memory requirements, which meant higher cost.
    I agree about WinCE being a hog, but take a look at uClinux. It is a modified 2.0.38 kernel with virtual memory stripped out. It fits in 2MB EPROMs with lots of room left over for your apps. The difference is that WinCE is a big monolithic program (just like desktop windows), whereas Linux (or any Unix) is modular. You only include the pieces you need.

    ...you'd end up with something that wasn't particularly compatible with mainstream Linux...

    You wouldn't have to add it to the kernel, you could implement something like this as another program that runs on the (more or less) standard Linux kernel. Sorta like an X replacement. It could even be the PalmOS API if you wanted it to be.

    But do you really need multitasking on something like a palm-pilot?
    Probably not, but there are lots of embedded applications that would benefit from multitasking.

    Users?
    Sure I can see some applications for multiple users in embedded devices. At the very least, it would be useful to have a normal user account and a root account (for debugging, system maintenance, etc.).

    A file-system, even?
    Absolutely! A RAMdisk, for example. Or the ability to mount an NFS volume.

    If not, then why Linux?
    Well, here are a few reasons. With Linux you get a stable kernel, with a good scheduler and very good networking. You get the source code. You can develop (and debug) nearly all of your application on your desktop (also running Linux, of course) and only port to the target when you're done. And you get portability. Pretty good reasons, imo.

    --
    Admit nothing, deny everything and make counter-accusations.
  16. embedded linux by jlehrbaum · · Score: 2

    I find this article interesting, as I've watched the attention paid to embedded linux grow since the summer, a time when it was a far less mature market. The splitting off of Lineo from Caldera was one of the more interesting developments that I've seen, although the purchase of cygnus by Redhat also added to the legitimacy of the market. With the recent CPU announcement by the Silicon Valley 'wunderkind' Transmeta, embedded linux has really entered a more mainstream commercial phase.

    The article on ZDNet helped to point out some of the majors issues in the industry. Who wants to pay for the 250 licenses needed for even a smallscale embedded application. It may mean less to the typical consumer who might pay $90 for a copy of windows, but I really think the cost issue associated with embedded linux applications is way more relevant than in the server or desktop market. It doesn't make a big difference if you pay $250 for software on a $16,000 server compared to buying a Software license for say $30-40 on a $200 portable web device.

    Another good point they brought up is ease of use. It doesn't matter to the endconsumer what OS the product uses, as long as it performs as expected, and without high incidence of failure (high being relative) Many of the companies in the embedded linux software side of the market provide technical support as a primary source of income (linuxcare, montavista, etc) Although some companies such as Lineo appear to be pursuing a more license based approach (although still providing plenty of technical support) Hopefully the end result will still be a savings of cost, but the high amount of technical support provided by these companies should help to offset any difficulty in actually using linux as the core of these applications.

    Other benefits not explored in the article include portability, the 'open source' ability to take an already extant solution and modify to suit your individual projects, as well as the ability to advance or modify a project that may have been discontinued, or to correct bugs without waiting for the original programmers to take action.

    Embedded projects are often so unique that a non-custom solution is often useless. The ability to customize linux combined with its low cost of use really makes this appropriate for this industry. I don't think the ZDNet article was worthless, and it in fact brought to light some points that people might not realize about embedded applications. It may seem like its just repeating stuff that people have always been talking about, but I think it was worth repeating and highlighting for this specific market. I see the success of embedded linux continuing to grow, and perhaps to exceed the growth that linux is seeing in other markets.

    If you would like to learn more about embedded linux and whats going on in the industry, please check out Linuxdevices.com

    --
    Jacob Lehrbaum jacob@linuxdevices.com
  17. BSD vs GPL for embedded systems by MattMann · · Score: 4
    The article didn't touch on licensing. Distributing linux in an embedded system all takes place under the GPL, correct? As the purchaser of a hypothetical LinuxPilot, I'd be entitle also to receive the source. But, would it be the source to the OS... or everything? I mean, if the code is all in binary form in a ROM, and the OS never exposes itself directly, where does the app stop and the OS start? Do the developers simply have to observe a "chinese-wall" model for developing, keeping the OS in one set of directories and the "app" in the other, and linking/stitching them together only as the last step before ROMming?

    It seems that economic model for open source that makes a lot of sense in the embedded market is for the chipmakers, who are not software companies particularly, to port an open OS and then give it to their OEMs to make a more attractive packaged offering for their chips. But in that case, wouldn't some embedded systems makers who are in hotly competitive areas prefer to have an OS without the "gotta hand over the source to our modifications" feature? I.e, isn't there room for the BSD license here? Linux and the *BSDs are essentially the same from the chipmakers standpoint. Hire a small staff, do/maintain a port, give it away with the chips... what do their customers want?

    I prefer the GPL myself, but it does have to compete against the BSD license and I want to explore/understand the implications, since the embedded systems area is going to be so big.

    1. Re:BSD vs GPL for embedded systems by AstroJetson · · Score: 2

      Do the developers simply have to observe a "chinese-wall" model for developing, keeping the OS in one set of directories and the "app" in the other, and linking/stitching them together only as the last step before ROMming?

      Yes, this is my understanding, but IANAL. If somebody out there knows otherwise, I'd sure appreciate it if you'd let me know. I develop s/w for traffic control equipment and plan to use some form of real-time Linux (eCos, RTLinux, eg.) for my next product. My PHB would be very upset to know that we had to release the sources to our apps. Clearly we are required to make available any changes we make to the kernel (or any other GPL'd code), but as I understand it, we don't have to release anything that we write that lives in user space.

      --
      Admit nothing, deny everything and make counter-accusations.
  18. Open Source has been there for a while by perry · · Score: 2

    Open source systems have been taking over the embedded systems market for quite a while. There are millions of devices out there that run NetBSD, for instance. One issue here for the embedded people is, of coures, GPL vs. non-GPL licensing. One reason BSD derived systems are already widely deployed in embedded markets is for this reason.

  19. Too much OS? by ucblockhead · · Score: 4

    I can't help but wonder of an embedded-linux will have problems similar to WinCE. A large OS crammed into a too-small package.

    Is it wrong to wonder if, perhaps, we might be better off having different OSes that serve different purposes? Do we have to have only one, jack-of-all-trades OS?

    Anyway, there is a reason that PalmOS beat WinCE, and it wasn't necessarily the normal Microsoft bugginess. It was the fact that PalmOS just does what is needed, and doesn't have a bunch of extra fluff brought down from bigger machines. Would an embedded-linux be any different?

    --
    The cake is a pie
  20. Bias in Reporting by SEWilco · · Score: 2

    Keep in mind that "it doesn't affect him" also applies to internal effects. A reporter who reports based on their emotions will be biased toward reporting which does not conflict with their own emotional viewpoint of an issue. The "vested interest" may not be apparent on any external facts (I'd say "not on paper" except it may be discerned through reading past reports).

  21. Application and customer preference determine OS. by walnut · · Score: 2

    OSes are not created equal (surprise). Depending on the design and budgetary constraints, and in rare cases, customer preference, we pick our starting OS.

    A project which has gone through several stages orignally used QNX as its base OS because of a real-time OS was required by the contract. In the second version, the client has demanded affordability and we have switched over to a Redhat5 release, and have ported over most of the code (not as fun as it sounds).

    Even the front-end of a robotics project which is now going into a production model, is being moved from a quickly written VB app to a Linux based solution. This is being done for (surprise) reliability reasons.

    Lastly we are using PC104's with a slimmed version of linux (fits on a floppy - pardon my ignorance as to what dist) as an application specific translator (goes from serial communications to IP).

    Is Linux being used in all our embedded systems? No, but it is being used with greater frequency, as it continually is being recognized for its price and versatility.

    --
    You say you want a revolution?
  22. Linux is still missing a few pieces... by DamnYankee · · Score: 2
    Linux needs -

    1) Flash drivers
    2) a viable Flash File System
    3) Bootloader from flash/ROM
    4) LCD drivers/windowing system

    Most of these have projects in development, but so far nothing is release quality.
    --

    Life is a tale told by an idiot, full of sound and fury, signifying nothing.
    William Shakespeare