What Embedded Linux Distros Would You Support?

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

Comments

Debian

[halfnerd]

And with just some extra care also Ubuntu/Kubuntu/Xubuntu/gNewSense...

No discrimination

[Mr2cents]

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:No discrimination

[BigBuckHunter]

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 support costs (especially dev and QA).

BBH

Re:No discrimination

[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 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."

That seems reasonable and balenced. If I am researching a tool and the first thing I see under "support" on the web page is a bunch of restrictions, it tells me that when the managers and employees at that company think of "support" the first thing that comes to their minds is a list of excuses as to why they shouldn't offer it.

Support is horrible at most software companies, because managers (and others) preceive it as a cost with no benefit them -- they want to minimize it, and treat it like a government tax. They give as little as they can get away with. Obsession with a bunch of restrictions on support is similar to the list of requirements for a mail-in rebate: somebody's trying to create a loophole.

A business with a more mature view looks at a support issue as "someone is not able to make money using my product, and that ultimately threatens MY being able to make money. This must be corrected immediately, and steps must be taken to make sure it never happens again."

Companies often develope those support limiting policies in reaction to support cases that have cost them truly huge amounts of money. So, if you are going to implement the "reasonable" support policy, you have to be prepared to enforce it upon yourself when a support case becomes unreasonable. This can include pointing out to customer that a cheap ass Dell box ready to be installed with exactly the software you recommend only costs $270. It can include telling a particularly neurotic customer to go fuck himself.

Just keep in mind, that when I as a developer look on your web site and see a bunch of nonsense like "only Pentium 4 or greater on RHEL 4 with all patches, on a IDE disk non-RAIDED with exactly model XXXX rev B video card" I move on.

Please don't tie it to a distro

[jnelson4765]

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 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:Please don't tie it to a distro

[idlake]

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 of the "own versions of Python".

In fact, good Linux distributions integrate Plone with the distribution-standard version of Python. That's a good thing; shipping Plone with a custom version of Python is an evil crutch.

Did you already look around on linuxdevices.com?

[modir]

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/. There you have the best overview on what is going on in the embedded Linux market. (imho)

Pick the biggest and support it

[johnjaydk]

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 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/ (free), VxWorks or QNX.

my experience.

[nblender]

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?

[Lumpy]

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.

I recommend...

[helmutvs]

MontaVista Linux. 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 and by many other successful companies. They also provide good support. Here's a list of boards and platforms supported by MontaVista. Hope this helps you.

Some clarifications

[dannys42]

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 the SDK, I'm not speaking mearly of tarballs of C compilers and libraries. There's a number of convenience scripts and tools we've added to give you a nice easy to use development environment. This of course relies on a number of system tools and libraries being available. Some of them standard, some not.

I can of course add these tools as part of the SDK. But going that route quickly ends up in making your own distribution. At this point it makes sense to just take a distribution and use that.