Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Businesses

What Embedded Linux Distros Would You Support? 83

Posted by Cliff from the top-of-the-embedded-pile dept.
dannys42 asks: "I work for a cool company that works with, among other things, embedded Linux systems. We'd like to provide an SDK for our customers and will likely support one or two Linux distros, plus Windows+Cygwin as build environments. Up until now, I'd assumed that most corporate developers were using Fedora, simply because of its similarity to Red Hat Enterprise and for its maturity. However, I'm curious to know, for those fortunate enough to develop for embedded Linux, what distribution do you expect to be supported for a build environment?"
This discussion has been archived. No new comments can be posted.

What Embedded Linux Distros Would You Support? More

What Embedded Linux Distros Would You Support?

Comments Filter:

  • Debian (Score:3, Informative)

    by halfnerd ( 553515 ) on Thursday November 30, 2006 @07:28AM (#17047082) Homepage
    And with just some extra care also Ubuntu/Kubuntu/Xubuntu/gNewSense...
    • Isn't an embedded system something like a set-top box or a handheld or even a lathe? As much a fan of Ubuntu as I am I can't see much need for it on a CNC machine.
    • I will also pro for Ubuntu/Kubunru/etc with some extra work on them which I believe will happen to the near future.

  • No discrimination (Score:3, Interesting)

    by Mr2cents ( 323101 ) on Thursday November 30, 2006 @07:32AM (#17047102)
    what distribution do you expect to be supported for a build environment?"


    Simple: Any. There isn't a reason why it shouldn't work on all distro's. I assume your SDK compiles with gcc and runs on an embedded target, so it would be more meaningful to support a compiler version than an OS. Or am I missing something?

    • Re: (Score:3, Informative)

      by BigBuckHunter ( 722855 )
      Simple: Any. There isn't a reason why it shouldn't work on all distro's

      Support != work

      The gentleman is asking which OS's his company should develope, QA and release for. No matter if it's a paid or free support offering, it would be logical for them to pick the distros that represent the majority of the marketshare for embedded device development. It probably mirrors the most popular distros out there (i think Fed/RH, Deb/Ub, and Suse). This way they maximize their coverage and income and minimize the
      • I understand this might be convenient/safe for the company, but for the customer it's rather annoying if your system runs e.g. debian and the package is only for red hat. What do you do? Make the switch? Use VMware? Search for another product? And then the irritation kicks in: why aren't there any Debian packages? It's both Linux! Give me my software!

        So at least make it available for all distro's, and let the user choose, even if there isn't any official support. Even then, try to help them if they call in.
        • Find out whether the company offers unofficial support for other platforms. A good company will help with generic problems but nothing that requires changes for the specific OS. What if there's a distro with a faulty version of a library? It's often easier to ask your customers to use a different version, and depending on the application, the customer will be quite hppy to do so.

        • I understand this might be convenient/safe for the company, but for the customer it's rather annoying
          ...
          It's both Linux! Give me my software!
          ...
          So at least make it available for all distro's, and let the user choose

          Um, no. It may be both linux, but I have the freedom to choose what I support. If I choose to only provide one package type, that is my choice. If you don't like it, so be it.

          If you want to use my product. You should not have any problem with switching distros or just adding a machine that is the

          • I consider that quite an arrogant attitude. Whenever possible, the company should listen to the customer's needs, not the other way around..

            Maybe the best solution is to provide a live CD with the software on it, and if you have troubles, test it with the live CD. If it works there, it's a local problem. If not, call tech support. Because, even with a supported distribution, I can still install extra software and/or mess things up. There's no difference really.
            • You are thinking like a customer and not like a company. From the company's point of view, if a customer wants the software bad enough, the customer will do what is needed to run the software. Kind of like why gamers upgrade the systems every few months to handle the demands of the latest games.
        • So at least make it available for all distro's, and let the user choose,

          And most do, through tarballs, anon cvs, and other methods (binary elf, lib, and a glibc dependency). Unsupported distros are then "free" to mangle it (like Deb does with wine).

          BBH

      • Re: (Score:2, Insightful)

        by Anonymous Coward
        Regardless of what you actually support or what actually works, one factor to take into account is that to many developers (myself being one) prominently announcing on your site that you only support a certain setup just makes you look unprofessional and incompentent in my eyes.

        On the other hand, consider a note such as: "Here at XYZ corp, we have standardized on Fedora Core 6, with several older Fedora linux machines still in use. While we have no reason to believe our environment won't work on any reason

        • Re: (Score:1)

          by dannys42 ( 61725 )

          On the other hand, consider a note such as: "Here at XYZ corp, we have standardized on Fedora Core 6, with several older Fedora linux machines still in use. While we have no reason to believe our environment won't work on any reasonable linux, and while we will try to assist you, please understand that we may not be able to replicate your problems if you are not using Fedora."

          This is in fact the sort of support I'd vote for as well. What I actually meant with the question, though, was what distribution

    • Before trying to get the QNX development environment set up on something other than RH9, I would have said the same thing...

      That case required a lot of things set up in just the right place, as well as some older version of JRE that was difficult to get if you weren't installing on RH9. Since then I've developed for an embedded Linux system that needed:

      • An old version of Python to be installed as the default (which is incompatible with the version of Python that every FC4 utility needs)
      • An old version o

  • Firefox comes in single binary tarballs. But yet the work on every distro. Why can't you just do it like them?

    You could also have some special binary packages for a range of distros.

    • Ahem, he means statically linked libraries. Somehow, I don't see that working well for and API.

      However, the community of programmers who know what they're doing tend to prefer Debian or one of its derivatives. I'd personally start with supporting Slackware (due to its "pure" nature), then ensure it works with Debian. If you do that, you'll probably have few complaints. The people who use RHEL are more often admins, not coders. Who cares about the admins? You? Why would you? They're not coders, n
  • RPM and source tarball should actually suffice.

    It's pretty straight-forward to create an ebuild (for Gentoo) if you have a well-behaved source tarball and a static download location and I imagine the Debianites can create apt-get packages with similar ease as needed.
    • Has anybody tried combining package managers in a distro? I think combination .rpm and .deb support would be really nice. I mean granted, the Debian lineage has alien to convert .rpm's to .deb, but it isn't 100% effective. I don't know if the Red Hat lineage has an equivalent to install .deb packages, since those aren't as common as downloads on websites.

      But, yeah, I'd love to have the capability to manage both types of packages in tandem.
      • I haven seen people report using Portage (Gentoo's package manager) to install RPM ("emerge rpm") or dpkg ("emerge dpkg") for Debian packages but I have not tried either myself yet. Package managers are just userland tools and as such should be fairly portable.

  • Please don't tie it to a distro (Score:4, Insightful)

    by jnelson4765 ( 845296 ) on Thursday November 30, 2006 @07:55AM (#17047198) Journal

    I prefer Fedora, my co-worker prefers Slackware - and we are equally productive. Supporting as many distros as possible would be a great goal - if you keep it as a completely seperate installation and don't try to "integrate" it into the host OS (I'm thinking of some Samsung printer drivers as a particularly bad example).

    For example, Plone [plone.org] ships with its own version of Python and Zope to keep the host OS's versions of either from breaking the application, and lets you update the host OS independently of the application. This is a good thing.

    • Re: (Score:3, Insightful)

      by idlake ( 850372 )
      For example, Plone ships with its own version of Python and Zope to keep the host OS's versions of either from breaking the application, and lets you update the host OS independently of the application. This is a good thing.

      It's only a good thing if you don't actually want to use any add-on packages. As soon as you want a Python package that your Plone package doesn't support, you have to manually install it. And if everybody did what Plone did, you'd have to install the extra package separately for each
    • For example, Plone ships with its own version of Python and Zope to keep the host OS's versions of either from breaking the application, and lets you update the host OS independently of the application. This is a good thing.

      Of course, overdoing this leads to wasted space and other issues. But done right it's very useful. Another example besides Plone is OpenOffice.org, which includes it's own Python version.
    • I would use LFS [linuxfromscratch.org] as an embedded OS.
  • I can't really tell which distro you should choose. But I can give you an advice to look around on http://www.linuxdevices.com/ [linuxdevices.com]. There you have the best overview on what is going on in the embedded Linux market. (imho)
  • ...and support it.

    You would likely pick the one or two platforms you are most comfortable with - simply because that makes it easier to debug any potential problems.

    You should smoke test your environment on several platforms to make sure it does at least the bacics properly. After that, you should thoroughly test on one or two supported platforms.

    This way, you can recommend a platform to your customers that you know will work (for example RHEL4, update 2) and know they will get a working environment if the
    • It's an SDK, so I am a little confused as to the actual problems he'd face.

      Deliver the following and it shouldn't matter much what the user is running:

      compiler - don't let the user their own compiler tools since they may not work

      linker - need one of these, so give them one that you've verified correct

      binary builders - some embedded systems need you to strip the binaries after linking. Some don't. If the users need to do it, give them the tools

      environment script - need to create a buildable environment, and

      • You'd be surprised at the differences in the standard tools between distros. The difference between FC3 and FC5 was enough to completely break our embedded toolset. Slight shared library incompatibilities in the system libs (not the embedded ones). Various other standard tools can change their incarnations between distros. Install didn't work in FC5 because somewhere along the line an option our scripts used disappeared on us.

        You really do need to pick one or two platforms for full testing - Windows m
  • I'd go with one Linux and one BSD, give your customers more options.

    The reason for this is that both have thigns that they are quite good at, and both have things they lack.

    I'd probably say one of the following for Linux:

    Fedora (popularity, but it's bloated, probably not good for an embedded solution), Ubuntu (more friendly/reliable IMO), and Gentoo (more reliable than the other two in my oppinion, friendlier in some ways, less so in others).

  • Centos (Score:2, Flamebait)

    by Kangburra ( 911213 )
    Fedora, simply because of its similarity to Red Hat Enterprise and for its maturity.


    No that would be Centos, not Fedora.
    • No, it's Fedora. These are developers, developing a product that will be released in the future, not the present. Fedora resembles the version of RHE that will be shipping when their product is released far more closely than CentOS. CentOS just looks like a crappy, year old version of the OS their product will be running on.
  • I would say it would be very nice of your SDK to support building for the GP2X [gp2x.org] [wiki], which is an ARM-based linux box with its own unique set of libs and tools .. which should be very easy to support as a target/API bundle, as a matter of fact ..

    The reason for this is obvious: the GP2X is cheap and easily available as an embedded Linux platform, and thousands of geeks are discovering it every month it seems. Definitely one of the more interesting embedded Linux platforms around, and certainly: very access

    • Man, that's cool.

      Now if there were something like that which had wifi and built-in GPS, it would be the most awesome swiss-army-knife of all time.

      Granted, this is almost entirely off-topic. But it is damn cool. Thanks for bringing it up!

  • Give one of the BSDs a try. FreeBSD and NetBSD are both extremely flexable for embedded installs (Free more so to x86 based systems). Linux seems random and haphazard after you've worked with a BSD for a while.
    • FreeBSD doesn't run on any embedded platforms. Try not to let your obvious freebsd bias interfere with common sense. NetBSD is certainly an option, as is openbsd which at least supports a few embedded platforms like arm. But freebsd has no embedded ports, the closest you can get to embedded with freebsd is small PCs like soekris.

  • Pick the biggest and support it (Score:4, Insightful)

    by johnjaydk ( 584895 ) on Thursday November 30, 2006 @10:10AM (#17048356)
    Disclaimer: I do embedded stuff for a living.

    For any semi-pro work in this space, You'll have a dedicated development host (read PC) that runs EXACTLY the Linux distro that was supplied for (and together with) the SDK. Time is just to short to dick around and customize for 17 different linux distro's.

    Case in point: I recently picked up an ARM5 development kit from Arcom. http://www.arcom.com/entry-level-devkit-linux-vipe r.htm [arcom.com] and it came with a Fedora Core 5 DVD and an SDK for core 5. So I slapped the whole thing on an empty PC and was ready to rumble in an hour or two. I didn't even update the core 5 install (behind firewall etc.) in order make certain that the SDK was an exact fit.

    That's (unfortunately) how You do it on a linux host. Otherwise You can take Your chances with the hell of CygWin and Windoze.

    My point is: Chose one distro, ship it together with Your kit and make absolutely sure that it works 100%.

    For what it's worth, I think Linux blows chunks as an embedded RTOS. It's too damn big and the real-time performance just isn't there. Go with http://ecos.sourceware.org/ [sourceware.org] (free), VxWorks or QNX.

    • Actually my experience says that it's better to pick a cross compiler toolchain and stick with it.
      We have to support arm9 and x86 embedded platforms and we do on the same machines using debian testing with two separate toolchains. CXX=... ./configure ... is the shit!!

      Works like a charm with some messing around required.

      Cheers
      Ben
    • create an image for VMWare player/User Mode Linux/... and you have an instant development environment ready! You (your company) make the choice, no need to support several environments.

    • Re: (Score:1)

      by silpol ( 115523 )
      with eCos, QNX and stuff like that you won't have all community-developed bunch of SW - if you stick e.g. with Debian/Ubuntu just modify slightly CPU/power hogs like desktop SW, and it is ready. Start to collaborate with Ubuntu - THAT IS the way

  • my experience. (Score:3, Insightful)

    by nblender ( 741424 ) on Thursday November 30, 2006 @10:38AM (#17048758)
    I work in the embedded space. Currently linux/mips64 and linux/x86. In the past I've done NetBSD/evbarm and NetBSD/ppc405, Linux/arm. Also QNX/ppcbe. I'm largely platform agnostic but in the various environments I've worked in, I can tell you that you will encounter many engineering departments that do all of their CAD on Solaris/sparc and the software guys do their builds on Solaris/sparc machines while using Linux desktops... So I believe you'll find greater market acceptance if you at least offer a Solaris SDK as well. If you can confirm your toolchain works on a *BSD, then you will have all the bases covered. Nothing I hate more than to see some documentation that says "system requirements: RedHat vFOO". Embedded developers are typically smarter than your average bear and are happy to install using a tarball instead of some proprietary packaging mechanism.

    Also, provide a sample build system that developers can "include" in their Makefiles and set one or two environment variables that are target dependant (FOO_ROOT and FOO_TARGET for example)...

    Find out what Montavista is doing and avoid it all. How are these people still in business?

  • Embedded Distros? (Score:3, Insightful)

    by Lumpy ( 12016 ) on Thursday November 30, 2006 @11:12AM (#17049280) Homepage
    So far nobody has mentioned an embedded distro. Last I checked most have died off outside Damn Small Linux. I personally changed completely to Slackware for embedded use as it's easy to mold into the size and shape you need.

    I really liked Vector linux but it is basically small Slackware. embedded Linux distro? I recommend wrapping your own. It's really easy and you get far more performance out of your device than any distro can give you.

    • This is actually something I need to deal with coming up. I'm working on a project at university building a hybrid-electric racecar, and I'm going to be using a single-board computer for closed-loop control on some systems, and for data acquisition.

      Have you [or anyone else reading] compiled in and used the RTAI extensions? I need to do control at a reliably constant sample rate without any latency. Have an eperience with real-time Linux?

      • This is actually something I need to deal with coming up. I'm working on a project at university building a hybrid-electric racecar, and I'm going to be using a single-board computer for closed-loop control on some systems, and for data acquisition.

        Tour de Sol? BTDT 4 years ago. I think you'd probably be better off with a network of PIC microcontrollers running real-time code. Faster and less prone to crashing or slugging. In addition, they have built in analog I/O capabilities. If you're afraid of a

  • I recommend... (Score:2, Informative)

    by helmutvs ( 912204 )
    MontaVista Linux [mvista.com]. I work for a large networking company that uses this as the embedded OS in our switches - it is very reliable. It's not free, however, but this distro is used in several industries [mvista.com] and by many other successful companies. They also provide good support. Here's a list of boards and platforms [mvista.com] supported by MontaVista. Hope this helps you.

  • The only reason to tie your SDK to a distro is to limit your support exposure. There is no technical reason to do so. Please try to be sensible about this: what you're doing, after all, is providing a tarball of build tools, and a tarball of libraries.

    Me? I play with PalmOS (68k/gcc toolchain) and uClinux on Slackware. I built all the tools and libraries from source. They work fine.

    ...laura

    • Re: (Score:1)

      by dannys42 ( 61725 )
      I have no problems with people wanting to use the SDK in other distributions. But we have to pick and choose which ones we want to test with and "gaurantee" will work. Also, SDK may have been a poor choice of words, as it includes a build environment (toolchain, scripts, etc.) to make it easier for developers working with our kit. This will include many different tools that might depend on various system utilities, scripts, and libraries. Version incompatabilities, and differences in even the location o
  • Costs the same as any other Linux, works better than most. Readily available (they'll even send you a CD for free.) You might even think of making your own LiveCD.

  • Some clarifications (Score:2, Informative)

    by dannys42 ( 61725 )
    When I speak of "support" for a distribution I'm talking more about testing to ensure the SDK works out of the box. I have no intention of forcing our SDK to be tied to any given distribution. And I agree it'd be great if it worked on all distros. But the fact is, it's unreasonable for most companies to test across many distros and versions of distros like that, especially ones that actual developers in our market don't use. Hence my initial question... (which ones do people use?)

    Also, when I talk about

    • Re: (Score:1)

      by rur ( 110111 )
      Have you considered creating an image for VMWare player/User Mode Linux/... and you'll have an instant development environment ready! You (your company) make the choice, no need to support several environments.

    • Re: (Score:2)

      by bit01 ( 644603 )

      As an embedded developer I'm not actually particularly interested in what Linux flavor you support/test. They're all wrong. As long as you have a lowest-common-denominator tar.gz package with well documented dependencies that's all I want.

      I've tweaked my environment to support all the different jobs I do, including running your package. It's configured for my tastes and needs. I want to adapt my process the absolute minimum necessary to run your process. I'd like to install your tar with installwatch and

  • One way to look at the question of which distro to support is to ask what your SDK depends on in the host OS.

    In general, the more you insulate your build environment from the OS, the better, and the greater number of distros you will be able to support. There are several ways to do this, like chroot'ing your build tools to avoid using any host binaries, prefixing $PATH when running your tools, etc. More tricks will be needed depending on how cross-friendly all the sources you want to build are. Config
  • I suggest support the big ones plus a generic .tgz file. Do all our primary testing and development of SDKs on the TGZ first.

    The big ones are redhat, suse and debian.

    So in effect you're making RPMs, DEBs and TGZs. Let the TGZ be as generic as possible.

    And if you're releasing its source code, please test it over PowerPC, AMD64, ARM9 at least, or let the sources be as generic as possible not tied to endianness or word size.

    This should cover everyone out there.
  • The poster didn't ask about embedded distros -- i.e. the Linux distro running on an embedded target. He wants to know what developers have on their desktops, which is probably something completely different.

    I would recommend shipping a live CD with your tools pre-installed. It would be straightforward for you to master a Debian-based CD based on Morphix [morphix.org] and/or TROM. This allows your less sophisticated users to get off the ground quickly developing with your SDK. It's also good for evaluations, as peo
  • Guess I should have added more info in my original post.

    The question actually was asking what Host distribution we should support, not what Embedded targets to compile for.

    • Re: (Score:2)

      by LWATCDR ( 28044 )
      I think Fedora, OpenSuse, or Ubuntu are all good choices. I would suggest that you think really hard about VMWare player. You could create a VMware image and distribute that to your users. They could use it on any Linux or Windows system they want.
      I really find the new Mac really interesting. Put Parallels on it and and then install Windows and Linux in VMs.
      Sounds like the ideal solution for cross platform development.

  • I'm sure that this will seem a bit obvious due to my close ties with the distribution, but Gentoo [slashdot.org] should be a good match for you. Gentoo has support for embedded systems, as well as one of the widest set of supported hardware platforms in the Linux world. It is source-based, which makes creating your modifications and customizations much easier. It has tools like catalyst [gentoo.org], which allow you to easily build a customized distribution of your own, based on Gentoo. Gentoo is also free, which can be a big plus

    • I'm a gentoo fan as well, but for an embedded OS, I don't know if it'd be that great. For one thing, Gentoo's philosophy is "bleeding edge". If you're dealing with embedded software that's never going to be on a network for updates (think medical devices), then Gentoo's no good. I would see gentoo in an mp3 player (constant link with a PC for updates), but not, say, in a cardiogram machine, a mica-style mote, or other small non-networked devices. The problem is that Gentoo fixes bugs by using the next avail
      • Funny that you say this considering I am currently under contract with a company designing a medical device that is using Gentoo as the basis for the operating system on both the medical device, as well as the operating system for the developer workstations used to design the software.

        Remember that there's no more validation done for security with Red Hat, SuSE, etc before they release their software. The only guarantees that a binary distribution makes is that the software they've provided works with each
        • Point taken. I probably should've shut up in the first place, the only embedded programming I've done was on MicaZ motes, and that was using TinyOS, which has been refined over time, developped purposely to be a stable code base that you could then assemble into a realtime OS. TinyOS gave the impression that the embedded programming evolved, yes, but that released code would always be stable. Maybe it's true for TinyOS, but from your description, Linux embedded is more like regular gentoo development anyway
  • Are two leading embedded linux sites, with cross build environment setup that covers lots of boards/devices.
  • Would easily navigate between camera, ipod, cell phone, and nintendo emulator. It would have a 802.11g chip hard coded for use at all times. It would be small, like the latest samsungs at T-mobile. When you plugged it into it's USB charging dock, you could use it as a computer (complete with USB keyboard, mouse, and USB to VGA monitor hook up, gamepad, and external speakers) and it would have rudimentary email/web. It would do ipod better than ipod, because it would default to using un-drm'ed mp3 files,

    • Re: (Score:1)

      by dannys42 ( 61725 )
      That's a fine idea, but if you had to pick one distribution to be your host platform, what would it be for this "perfect embedded linux distro"?
      • I don't really like ANY of the distros to date. I'd probably hire a couple of bad cyber bad asses, and then heavily modify Debian.....

        rhY
  • Releasing either a LiveCD (which uses a HDD partition for data storage) or a VM image with the development environment and Linux distro preinstalled? That way, you can very tightly control how the devkit operates.

    -b.

Slashdot Top Deals

What is research but a blind date with knowledge? -- Will Harvey

Close