Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×
Linux Software

Linux in Embedded OSs 75

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

Linux in Embedded OSs

Comments Filter:
  • Anytime you are representing a side, you have some bias towards it. If you work for Al Gore's PR division, you obviously will point out the good points of VP Gore, and ignore or hide his bad points. Same goes for Bush, Bradley, McCain, etc.

    You only have a single judge in a case. After the facts are laid then, the judge decides one way or the other. I agree with your point of having two sides to a story, but that usually is an analogy of having two lawyers who represent each side. As you say It's opinions that bias something - not facts, but it's bias to choose what facts to point out. Having one bias to one side and another bias to anther, will help show the most facts of both sides, and then you can get a better picture. Of course this doesn't always work. If one lawyer is much better than the other, then you don't get an equal showing of facts. That's probably the problem with our (US) legal system. But that's another story.

    Again, I agree that the press should always have reporters that favor each side. But opinions are hard to subdue. Let the reporters fight, and then we can get the best news. My news-paper has reporters that are both Democrats and Republicans, and I love to read the difference in opinions. I enjoy reading Pro-MS as much or even better than I do for Pro-Linux. Being Pro-Linux myself, I find that I too am bias, and like to find the ways to make Linux better. I read that Linux has trouble with configuring the Video, and I say to myself "yes it does, let's fix that".

    Steven Rostedt
  • 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?
  • 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.
  • My understanding is that it would not fall under the GPL. I think this is how binary-only device drivers can exist. But I could be wrong, IANAL either.
  • 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?

  • ...Linus is going to root for embedded Linux. He worked for Transmeta. He has financial interests in Transmeta. Along with laptops, embedded is their business. Wait a minute... I'm working to start a company based around embedding Linux.

    I'll shut up now.
  • 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

  • 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
  • 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
  • Anytime you are representing a side, you have some bias towards it.

    I believe we're arguing over what the persuasive writing style is. I agree with you over this style - it is intended to persuade someone to your side. Typically facts supporting the other side are omitted, opinions are intermixed with facts, ad nauseum. Editorials are almost always persuasive.

    However, an informative writing style is more akin to reading a report about a gas leak downtown that levelled a 3 block radius. There won't be much more than facts: there will certainly be no blame assigned. Quotes will typically be from both sides (if one side cannot/would not comment, it is usually noted). Reading the police reports on the back pages is an example of this (albeit dry!) style of writing, as is a technical "white paper".

    As you say It's opinions that bias something - not facts, but it's bias to choose what facts to point out.

    This is true enough. However, unbiased reporting, in contrast, would be reporting all facts one could find at time of publication regardless of whether which position they support.

  • 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.
  • by SheldonYoung ( 25077 ) on Monday January 31, 2000 @07:38AM (#1318880)
    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 [linuxce.org].
  • I agree. I don't think of Palm OS as an embedded system. But I do consider the code in a gas pump as an embedded system, and that has a computer monitor like interface too. These two could be the same, although I consider only one of them as embedded. Maybe we should only consider software that runs something and has little or no interface to a human as being embedded, and call everything else up to computers "Mini". So the software that runs my watch could be embedded, and that gas pump and Palm OS can be mini.

    Just an idea, since it is getting hard to distinguish "embedded" with actual normal software. Heck, soon a Palm may be as powerful as today's laptops.

    We really need a new term to be able to remove this confusion. At my work, we really do write "embedded" and RT systems. The software runs aircrafts and that is probably the most RT and embedded as you can get. Most of the software needs to fit in less than a Meg, since the hardware needs to take tremendous evironment abuses and must only produce minimal heat, we can't use the stuff you get at Comp USA, and thus we are limited.

    Steven Rostedt

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

    Part of the reason that WinCE does so poorly against the PalmOS has to do with its interface. A Start menu and desktop metafor simply takes up too much space to be useful on a small PDA screen. This is a separate (and IMHO more important) apart from bugginess or code bloat. Since Linux is at its heart a CLI OS, most processor cycles AFAIK are used up the X Window system and processes and services which would not be needed on a PDA and therefore would not need to be compiled.

    I'm no Linux expert but my guess is that you can pretty much put up any interface you want on top of a slimmed down Linux kernel. Palm Computing for example is working with Symbian [symbian.com] to run the PalmOS GUI on top of the Epoc32 kernel. There should be no reason, other than perhaps licensing, why someone couldn't do the same thing with Linux.

    Similarly, it should be possible to create a webpad type device that would simply run Mozilla on top of a Linux kernel recompiled with only enough support for whatever was needed to run a browser plus wireless IR or radio support.
  • 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.
  • 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.

  • Sorry, mini is already taken. :) A mini is bigger than a micro.

    Main Entry: minicomputer
    Function: noun
    Date: 1968
    : a small computer that is intermediate between a microcomputer and a mainframe in size, speed, and capacity, that can support time-sharing, and that is often dedicated to a single application
  • Why do you say the viral nature of GPL doesn't extend outside the kernel. If someone has gone to the effort of developing software outside the kernel such as a VPN client or a word processor and decides to release it under the GPL, wouldn't it get the same protections as the OS kernel since it using the same license?
  • 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 :)
  • After this interesting discussion I've taken a look at the BSD license and the Cygnus eCos license. Both seem to have better attributes for embedded systems development.

    Some of the BSD licenses (there are variations) only require acknowledgement in the product and/or advertising. The BSD license does not place further restrictions on derivative works.

    The eCos license is interesting in that it requires modifications to the "covered" (i.e. the OS) code be published in source form but accomodates the combination of non-covered (i.e. proprietary) code and covered code in commercial products. Way to go Cygnus!

    So it looks like BSD and Cygnus sources are fertile ground for embedded systems work. More so than GPL. And do I even have to say, IANAL.

  • EG: I think what Proteus was saying was that if you develop a software product (in this case the Linux kernel) and GPL it, the GPL license doesn't extend outside of that piece of software. I think he is correct in that that's what the GPL is trying to say, but I'm not sure it actually says it in the case of embedded products. (Due to the funky wording about distributing it as a single work etc.)

    btw, thanks for looking into the BSD & eCos licenses. I'm curious how Cygnus gets away with licensing eCos that way since it's based on Linux. Seems like the viral nature of the GPL would prevent that.

    I was considering opening an "Ask Slashdot" thread to get more folks involved in this discussion. Do you think that would be worthwile?
  • I think opening an Ask Slashdot thread to discuss open source licensing issues for embedded systems is a great idea.

    I agree with your point that the intention of the GPL is probably not to exclude use in embedded systems but its wording makes it unsuitable. On the other hand, the GPL was intended to draw developers in to the open source game so maybe we would be breaking the intent by using GPL'd code in new products without giving something back to the community. But what I've just realized in the last couple days is that the other open source licenses (BSD, eCos, and some others) aren't as restrictive as the GPL.

    As for eCos, even though it is put out by Cygnus, I don't think it is based on Linux or other GPL code. I think those guys built their embedded OS from scratch. That's why they aren't bound by the GPL.

  • Is it just me, or has this topic been discussed over and over in Slashdot forums? Yes, Linux is a viable choice. Everyone else decided that a long time ago, but now that ZDNet said it, it's official?

    Sure, the Transmeta processor opens lots of doors to get rid of the current incarnation of the computer -- soon enough, the vast majority of home computer users won't be using a beige box, they'll be using webpads for their browsing, and bitchin' phones for their e-mail, and not this "all-in-one" machine.

    But advances in technology happen on a daily basis. What does this article teach us that we didn't know already?
  • by Signal 11 ( 7608 ) on Monday January 31, 2000 @05:40AM (#1318895)
    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*.

  • by dsplat ( 73054 ) on Monday January 31, 2000 @05:46AM (#1318897)
    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.
  • Everytime I read such articles, I more and more believe that the future of computers is not in a fixed workplace.

    Imaging you just bringing such a pad to school/work, checking in on a main-frame, and doing your work. With an internet connection, these things will need very little harddisk space (or none).
    Also, technology will make them smaller, compare the calculator of 20 years ago with the ones we see now! Imagine now such a pad, not thicker than 2 mm, and at a very low weight. If you need anything typed you can connect a keyboard to it (or the cool "wireless keyboard without the keyboard" thingie).

    And now for the best part: this all under Linux! Now I understand why those Startrek computers never crash...

  • Is it just me or has anyone else noticed that all of ZDNET is beginning to mimic the patent pending writing of Jesse Berst? Everyweek it seems some columnist from ZiffDavis is writes a pro-linux and then later a anti-linux article on which neither is original or informative. The end result only seems to be that slashdot.org will post a link to their article and all of us will read it, quote it, respond/flame it, and talk about it for the full fifteen minutes of fame it was written to generate. Perhaps we should start ignoring articles like this and concentrate on things that were not created to just get a rise out of the linux communities' collective nerves.
  • Is it just me or have their been one to many articles saying 'Linux is great at cutting costs because it's er free!'. Stating the obvious must be a full year at journalist coledge, and to report on linux you must have passed with honors.

  • Well, as we all know Microsoft would love nothing more than to control the entire broadcasting market by making a TV with WinCE the de-facto standard for watching you favourite soap opera.

    Apart from this being the one thing that could stop the world population from watching tele (would you boot a tv to windows?) they also now have competition.

    The real shame here is that whichever 'side' gets the lions share of the market they will have made a GUI the de-facto standard whether its X11 style, palm style or even PSX style; you won't be able to use your TV unless you have this GUI on it. (A bit like Betamax dying and VHS prevailing)

    What I would like to see is this: a range of television sets which can be configured with whatever you like (ie: O/S / GUI) so you don't have to have it forced down your throat.

    And first and foremost *all* the GUI's should be made compatable to a _fair_ industry standard so everyone can compete on equal grounds.

    Lastly why isn't England going to get decent HDTV's until last?
  • Well, I think that's half of it. Yes, you are right about the busy desktop being half of the problem with WinCE. But the other half was the size of the OS. It meant bigger memory requirements, which meant higher cost.

    One difficulty which I think you may have missed is that PDAs are almost always graphical devices. The Palm certainly is. And obviously X Windows is far too large to fit on a PDA. (And has far too much unneeded functionality.

    A true CLI is a royal pain in the ass with only a stylus.

    I'm sure it could be done. I just suspect that by the time you through out everything that wasn't needed on a PDA, and added in extra things that were needed. (Some sort of Grafitti version, a simple graphics interface, etc.) you'd end up with something that wasn't particularly compatible with mainstream Linux, and was bigger than something written from the ground up.

    It probably depends on what sort of embedded device you are looking at. If you are looking for a real computing platform, it might be a good idea. But do you really need multitasking on something like a palm-pilot? Users? A file-system, even? If not, then why Linux?
  • Although I totally agree with your statement about ZDNet, and since I actually subscribe to "Berst Alert", I have seen (and laugh!) at Jesse just following the masses. I like the tech news better from them, but I always considered Jesse as the comic relief.


    But as for your statement

    *represent both sides equally and without bias*

    I would like to see how could you do that. Can someone represent a side with being bias? Isn't that kind of an oxymoron? Or do you mean just mean have a bias MS person and a bias Linux/free software person. Of course I don't know anyone that would like to write on /. being pro-MS. That's kind of like suicide! But I'm sure there are people out there that enjoy the flames.

    Steven Rostedt
  • I'd like to add to this list:

    5) Streaming video codecs/player

    Looking at the list of vendors working on Linux-based "info appliances" surely at least some of these companies realize that support for streaming media is a must for a consumer-oriented information or Internet appliances. The Missing Broadcasting Link...

  • by T-Punkt ( 90023 ) on Monday January 31, 2000 @09:00AM (#1318905)

    Same for NetBSD:

    See NetBSD/hpcmips [netbsd.org] for MIPS based PDAs.

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

  • 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?
  • Not only is this inevitable - it is all reaching a critical mass
    with the support of more and more IPO Linux companies.

    Support is expanding from the server strength that Linux has to embedded and desktop systems.
    Let's also not forget that the strength that Linux will receive will be from the developing
    countries of the world like S.America, India, China and Russia.
    These places are already pillars of strength for Linux development
    (e.g GNOME's Icaza from Mexico) but we have only seen the tip of the iceberg.
  • 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 [uclinux.org]. 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.
  • 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 [linuxdevices.com]

  • Linux needs -

    1) Flash drivers
    2) a viable Flash File System
    3) Bootloader from flash/ROM

    Many embedded systems (PC104 comes to mind) present the flash chips as an IDE interface, so the standard linux disk drivers work fine. The trouble with flash chips is the ~100K rewrite limit, but you can usually just keep all your dymanic data in a ramdrive to solve this problem. Check out the initrd kernel options.

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

  • by Gurlia ( 110988 ) on Monday January 31, 2000 @06:14AM (#1318913)

    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.

  • Despite Linus working for Transmeta, and all of the efforts going into
    new embedded apps, the focus of the Linux development ffort is still
    the server: am I right?
  • I know the guy who owns the domain embeddedlinux.com

    He's not sure what to do with it (just a link page so far). Any suggestions?

  • by MattMann ( 102516 ) on Monday January 31, 2000 @06:23AM (#1318917)
    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.

  • 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.
  • by ucblockhead ( 63650 ) on Monday January 31, 2000 @06:25AM (#1318920) Homepage Journal
    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?
  • I've been an embedded developer for 15 years. For all of that, I've written my own small-scale RTOS and hacked a commercial (non-embedded) compiler/IDE to generate code for EPROM burning or downloading to the target machine - later ones did have a GUI, but this wasn't related to development. So that's my definition of "embedded".

    I'm late in starting a new project which will use the ARM Thumb-based AT91F40416, a 32-bit chip with 2MB of embedded flash memory. One of the sticking points is the expense of specialized development systems - I've had quotes between $4K and $10K, which are over my limit at this time.

    I've looked at several open-source options, like RTLinux, eCOS, ucLinux and so forth, but user-friendliness (in the strict sense) isn't a feature... most of them seem to assume that you're developing for the x86 architecture, or necessarily want to use a Linux or BSD machine as a development system (which I definitely don't).

    Look at the Palm development system based on CodeWarrior: you get a standard IDE, debugger, and a Palm simulator box to run things in. The linker grabs the PalmOS as a library, or if one had the source to that, one could build stuff directly into the PalmOS. This is the ideal way to write an embedded system, IMHO. Until somebody develops a similar way for me to write my own stuff to, say RTLinux' API, but will all the facilites I'm used to, and then just compile/link the kernel with that into a ROM image, I won't be a convert to embedded Linux. Sorry...

  • We (Echostar) are building a HDTV set-top satellite receiver box that will run Linux, but ideally a consumer won't even know it. All they know is that they get a nice HTDV picture, and not a solid blue screen :-)

  • > Traditionally, the term "embedded" denoted a system with minimal (or no) UI

    This problem also extends to calculators. They have a cpu and minimal UI. Are they a computer? Technically yes, but since they have custom input keys they are classified as a calculator.

    Heck, my 10 year old HP48 has 256K of ROM for its "OS" with a built in filesystem including hidden directories !

    A new term is probably the most un-ambigious way to go. Otherwise everytime someone mentions embedded, they won't know, just 'how minimal' is the system.

    Following after the Real-Time OS's termonology, I propose the terms "hard-embedded", and "soft-embedded."

    Meaning, the hard-embedded system has no GUI, and the soft-embedded system has some sort of interface.

    Feel free to suggest better termonology.

    Cheers
  • Yahoo [yahoo.com] has a story about Red Hat's involvement with embedded Linux applications. This appears to be a rehash of the Cygnus [cygnus.com] acquisition [redhat.com] a few months ago, but still interesting reading. Apparently what makes this news is that Red Hat is putting together some new tools for developers, aimed at x86 and PowerPC targets.
  • 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).
  • Distributing linux in an embedded system all takes place under the GPL, correct?
    ...
    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?

    Now, IANAL, but if I recall, the viral nature of the GPL does not extend outside the actual OS. Therefore, if an embedded systems developer makes a modification to the kernel, source must be made available. However, if other OS components are developed ground-up without GPL'd code, the rest of the system need not be placed under the GPL.

    Also, the GPL doesn't require that source be provided with the product, but that it must be made available for no more than the cost of conveying the media. This means online for free, or via CD for cost of media and shipping.

    If an embedded systems developer were smart, they would use an embedded-linux kernel and build closed source tools around it (if they wanted to obfuscate the source). OTH, if there were a hypothetical LinuxPilot, the developer could give away the source, but need not disclose proprietary chip design used to build the device. So the GPL is not that large a hurdle to leap to the manufacture of Embedded systems using Linux.

    -- Never underestimate the power of very stupid people in large groups

  • Proteus sez:
    Now, IANAL, but if I recall, the viral nature of the GPL does not extend outside the actual OS. Therefore, if an embedded systems developer makes a modification to the kernel, source must be made available. However, if other OS components are developed ground-up without GPL'd code, the rest of the system need not be placed under the GPL.

    So can anyone 'splain to me whether a proprietary device driver that is implemented as a loadable module would or would not fall under the GPL?


    -- Ryan Waldron

  • Hard-embedded and soft-embedded, hmmm.....I like it. Kinda goes with hard real-time and soft real-time.

    Still kind of a grey area where certain devices are concerned. The criterium I used to use was if you could develop code natively on it, then it wasn't embedded. Now in theory with Pocket C you can write code on a Palm Pilot, compile it (interpret actually I think) on the Palm Pilot and run it on the Palm Pilot. To me this makes it unambiguously not embedded. But what about the Web Pad thingies? Where do they fit in? Can you run more than one application on it? If so, I'd say it's not embedded too, but if the only thing it will do is run Mozilla, I could make a case for classifying it as embedded. (Just with a more complex UI than most embedded stuff)

    Calculators? You can write code on them (the programmable ones anyway) and you can run more than one app if there is sufficient storage space. So I dunno about that one.
  • 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.
  • has it ever occurred to you that Jesse Berst might have gone through a "conversion"?

    It's possible, but until I see an article about the (albeit typical) troubles he went through installing linux, I won't believe him. I need something verifiable before I change my opinion of somebody. Also keep in mind that Jesse and his ilk tend to bend with the breeze. That is to say they are sounding boards for the popular opinion at the time of publication.

    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

    Got any articles indicating this alleged "digging" he's been doing? I'm reasonably certain that if he's a reporter worth his salt at all he would have posted a factual article indicating the results of his research. Thus far, I have found nothing to indicate this. Perhaps there is a URL I have overlooked, and if somebody would show it to me I may look on Jesse more favorably.

    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.

    True, but in a court of law a person's credibity is tested by asking questions of those who know him, as well as past actions. Shall we hold Jesse to a different standard just because he's a reporter and naive?

  • 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.
  • I would like to see how could you do that. Can someone represent a side with being bias? Isn't that kind of an oxymoron?

    Not really. So long as the person doesn't have a vested interest in the outcome (it doesn't affect him) you can ensure a certain level of impartiality. The legal system uses this to ensure the judge is impartial. Another thing that is impartial is the facts. If you write a report saying "Drive xyzzy is better than Drive ABC" and can back it up by saying the aureal density and maximum seek times of drive xyzzy are superior to abc, that's a fact - so long as you state it as such. It's opinions that bias something - not facts.

  • 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.
  • Now this is a point of discussion:

    Can a WinCE box go BSOD?

    According to a Microsoft leak ages back, the code is there; and whats more it happened to me, only once on a educational notebook & no I didn't get a photo, sorry :(

    Question 2 - will we be able to upgrade a TV's code for free with linux or will we have to pay for the operation from our manufacturers web server?

    Food for though (or eating infront of the telly)

I find you lack of faith in the forth dithturbing. - Darse ("Darth") Vader

Working...