Slashdot Mirror
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?"
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.
Clicked pie.
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.
Why can't I mod "-1 Idiot"?
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.
TCAP-Abort
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?
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.
Do not look at laser with remaining good eye.
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.