Slashdot Mirror

← Back to Stories (view on slashdot.org)

Living in a Linux Embedded World

Posted by timothy on from the how-little-is-little dept.

krow writes: "Embedded.com is running an article where the author is making some assumptions of Linux's use in the embedded markets based on the opinion of one consultant and the fact that Lineo had to lay off some people this year. It's still interesting reading though for some insight into a different world for Linux and there is a nice reference in the comments to the interview of Victor Yodaiken of RTLinux fame by by Kevin Fu on the ACM site."

4 of 146 comments (clear)

  1. Long Cycles by nate1138 · · Score: 5, Insightful

    Part of the issue may be that embedded systems have pretty long development cycles, compared to typical software apps of similar size and complexity. If your PC application doesn't work, you simply issue a new revision with fixes. Embedded systems are much more difficult to upgrade. I'm not talking about PDA's here, I'm talking about your set top boxes, industrial systems, data collection, etc. These systems cannot be easily patched. As a result, embedded linux development efforts take much more time to certify than those using RTOS's that have been around for years. Also, it is true that linux doesn't have a native method for doing hard-real-time events, there are add-ons, and it isn't the fault of linux developers, such a thing simply isn't needed for desktop and server OS's, but for running an industrial robot, a 10ms delay can be disastrous.

    --
    Where's my lobbyist? Right here.
  2. Why some developers are running from Linux by dfeldman · · Score: 5, Insightful
    I used to work closely with a development team that made the transition from a proprietary (and, may I add, unmaintainable and unreliable) embedded OS to Linux. Though some of the concerns in the article did come up, especially speed and size issues, those didn't hurt us much. After all, we could afford a better processor and more memory with the money we saved on royalties and maintenance expenses - these were substantial.

    Unfortunately, if the many features of Linux and the transition from assembler to C didn't hurt us, the licensing did. Things went very smoothly until we needed to make some big changes to the kernel to accomodate a newer version of our hardware. At that point, there was a schism in the group: some of the developers wanted to change the kernel and release the product without source (the "who would find out?" crowd) and the rest of us knew that Linux was not going to fit our needs anymore unless we wanted to give our work away to competitors.

    Well, the "who would find out?" crowd won the first round, and because of release deadlines we "slipped" the kernel changes into the next version of the product. And nobody knew. Except one of us told the legal department about what happened and they became very agitated.

    Now our software runs on embedded NetBSD. It wasn't quite as robust as embedded Linux but it works well and we really can't complain. Transitioning to a new OS took a lot of effort but it was a necessary evil. After all, we couldn't risk getting sued out of existence to save a little money.

    But the question I draw from this is: why not relax the GPL restrictions a bit for embedded applications? It seems like this area of the market will never be dominated by Linux until companies can stop fretting about licensing problems and start concentrating on coding instead.

    df

  3. He's Right by DrStrange · · Score: 5, Insightful

    Sorry to anyone who believes Linux is THE choice for everything, its not. As a real time embedded developer who has done some work on Linux device drivers I have yet to suggest Linux as an option when the OS choice has come up. I agree with the author when he cringes at some of the commentary in the Linux source code, I'm supposed to stake my name and my company's name on an OS with comments like: "/* This is a hack..." in the kernel? And say we do go with Linux and a problem with the OS comes up what should we do? Post to the linux-kernel mailing list and hope it gets fixed? Assign one of our developers to fix it? We don't hire OS programmers for the very reason that we buy our OS, we're DSP engineers. Most companies won't go with Linux because of the fact if something breaks they can't submit a bug report and withhold payment until it gets fixed.

    I'm an avid Linux user at home but for fault-intolerant real time systems, I would feel a bit uneasy recommending Linux for an embedded system just yet. Once I go 6 months without a story on /. where a major fault has been introduced or missed in the Linux kernel I may rethink my opinion but until then I'll be suggesting that we buy our RTOS.

  4. we should have a solution by linuxlover · · Score: 5, Insightful

    This is exactly the issue I am considering aswell.

    Lets say our company invents a device and plans to sell the device with Linux loaded terminal with Linux device driver. The hardware+software is our IP and we can't give it away. please don't lecture me of how everything should be free...etc. I know that, and I also like a roof above my head. Letting people download my driver for free from a FTP server doesn't quite pay my bills.

    So the solution:
    we need to have something like FSF or Linux Fund. If I want to keep my driver closed source say for 1 year then I pay a license fee for them (it can be a one time thing or royality based). The 'foundation' distributes the money as it see fit, funding developers, funding new projects..etc. After a year, I have 2 options
    - release the source to kernel main tree and make it open. Now it doesn't matter as competitors can't abuse my work to overtake me.
    - continue with closed source for another year and keep paying (may be revised) licese fee / royality.

    This has best of both worlds
    - I get to use a stable well maintained software (in this case Kernel). so I don't have to re-invent the wheel inhouse everytime.
    - I keep my IP intact for a short period and at the same tiem paying for other developers efforts.

    any one know any similar licences like this?

    LinuxLover