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

 



Forgot your password?
typodupeerror
×
Linux Software

Linux's Future As The Next Embedded OS 18

CowboyRobot writes "ACM Queue has an interview with Jim Ready about how embedded systems differ from desktops and servers, and how they will help shape the future of Linux. From the article: Your car, for instance, now has telematics -- mapping, navigation, and entertainment systems -- that clearly present a very sophisticated user interface... The neat part for me now is that embedded systems can consist of Linux applications with beautiful graphical interfaces."
This discussion has been archived. No new comments can be posted.

Linux's Future As The Next Embedded OS

Comments Filter:
  • any idea of cc terms that run linux? i know a few companies that make them, but they all have drawbacks.
  • by Eneff ( 96967 ) on Wednesday May 07, 2003 @12:43PM (#5902852)
    NetBSD runs on everything and is tight, as some of these things are rather resource-strapped.

    OpenBSD is secure, doesn't turn on what isn't needed, etc. Thus, it makes a lot of sense for a server.

    FreeBSD tries to get a good portion of code running, and is generally the most desktop-friendly, though it is acceptable to servers.
    ____

    Windows CE, Windows XP, Windows 200x Server.
    ____

    G*linux with embedded patches, g*linux with desktop patches, g*linux tweaked for servers...

    It's only a matter of time before the code bases start deviating more and more.
  • by Anonymous Coward
    On embedded systems the user interface is generally customized to the application. That is true regardless of the interface and device: steering wheel, buttons + flashing 12:00, even the interface on an embedded device with a touchscreen running on top of a relatively normal graphics layer is customized to the purpose at hand.

    That frees Linux from the constraints of GNOME, KDE, etc. that are very bloated and difficult to use. If you have to write your own complete interface anyway, then the barrier is abou
  • It might even be a good article, too, if the font were large enough to read!!

    p {
    font-family: Georgia, "Times New Roman", Times, serif;
    font-size: x-small;
    line-height: 120%;
    }

    Whyinthehell do webmasters do stupid crap like this?

    • Becuase it dosnt look that way in Internet Exploiter, therefore they pat themselves on the back for doing a good job and go watch some porn while they study for their MCSE exam

      You know some people renew my belif i should be allowed at least 3 killing sprees a year just to clean the MSCSE's out of the genepool :)

      Karama? What Karama?
  • Embedded systems have to be able to deal with abrupt loss of power and EXT2's instability there really ruled out Linux as a flexible embedded OS for a long time. Lately with EXT3, JFFS2, and XFS maturing Linux has become much more useful here. Thanks to all the filesystem developers out there!

    • I have to say that thats rubbish. It is only the recent trend that has blurred embedded OS with desktop OS which has produced this requirement. Vxworks for instance, which controls the majority of the market uses dosfs which does not seem to of affected its adoption.

      What using linux as OS does mean is that you have a much larger choice on what you use. This can only be a good thing
      • Perhaps the problem is write caching. With many embedded devices you have to allow that the power can fail at any time (due to batteries running out, being unplugged, or just the user turning the device off). Ext2 can take a long time to fsck after an unclean shutdown and it's possible (though unlikely) that the filesystem will be beyond repair. Hence the need for a journalling filesystem.

        The DOS filesystem is relatively robust against half-written data, I think. Or at least the disk recovery tools are
  • by Lurch00 ( 56120 ) on Wednesday May 07, 2003 @10:36PM (#5907725)
    My sincerest hope is that with all of the embedded applications running on serious hardware now, we'll see an improvement in quality for regular applications. Developing for a sufficiently complex embedded system is indistinguishable for the most part from developing a server application. If you treat your client apps with the same respect you should treat your server apps with, its the same as developing for those too.

    I think we're going to see a lot of reuse of existing frameworks and high level abstractions between embedded and traditional applications, and that those frameworks will in turn be hardened to improve their quality. In a lot of situations whole applications will be hardened to run in both variants. This all should in turn benefit the traditional applications. Granted, it still takes a talented developer to produce a quality app no matter how good the underlying framework is. However, I think this type of hardening will help limit the scope of problems to the application code, where the less talented developer is more likely to be able to keep track ot them.

    This of course is all dependent on consumers continuing to not tolerate crappy appliances. As long as everyone refuses to consider power cycling as part of normal operating procedure, then I think a lot of improvement is going to occur. However, if this industry explodes, there are going to be a lot of crappy products and consumers are going to lower their expectations, which isn't good for anybody. This is going to be a hot market, but right now I think there's a shortage of engineers who can really work in this domain, and that's probably holding the market back. This is probably good for long term product quality, but bad for someone like me who wants to stop working on defense systems and get into the commercial sector.

    Note: This doesn't apply to low powered hardware, hard real time systems, one-of-a-kind systems, etc. Those are a whole different ballgame.

  • A big benefit from using Embedded Linux to run on your target hardware is that you can develop the software on a PC running Linux, get it working in a nice IDE, and then run THE SAME CODE on your hardware.
    I did this on a project where we were using QT for the GUI. I had 2 PCs, one running windows and one running Linux. I had a full development environment set up on both, and could use whichever I thought best for my current work.
    When we got our first bit of real hardware, it took me 3 weeks to get the act

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (1) Gee, I wish we hadn't backed down on 'noalias'.

Working...