What Embedded Linux Distros Would You Support? 83
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?"
Debian (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
No discrimination (Score:3, Interesting)
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:2)
Re: (Score:1)
Re: (Score:3, Informative)
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
Re: (Score:2)
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.
Re: (Score:1)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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)
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)
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
Re: (Score:1)
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:
Re: (Score:1)
Do like the Mozilla foundation (Score:1, Insightful)
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.
Re: (Score:1)
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
Distro or package handler? (Score:2)
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.
Which makes me wonder... (Score:1)
But, yeah, I'd love to have the capability to manage both types of packages in tandem.
Re: (Score:2)
Please don't tie it to a distro (Score:4, Insightful)
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)
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
Re: (Score:2)
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.
Re: (Score:1)
Did you already look around on linuxdevices.com? (Score:2, Informative)
Pick A Platform... (Score:2)
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
Re: (Score:1)
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
Re: (Score:2)
You really do need to pick one or two platforms for full testing - Windows m
honestly, if you want to pick 2... (Score:2)
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)
No that would be Centos, not Fedora.
Re: (Score:1)
Re: (Score:1)
Not a Distro, but instead a Target: GP2X (Score:1)
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
Re: (Score:2)
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!
BSDs? (Score:2)
FreeBSD? Get real. (Score:1)
Pick the biggest and support it (Score:4, Insightful)
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.
Re: (Score:1)
We have to support arm9 and x86 embedded platforms and we do on the same machines using debian testing with two separate toolchains. CXX=...
Works like a charm with some messing around required.
Cheers
Ben
Better yet... (Score:1)
Re: (Score:1)
my experience. (Score:3, Insightful)
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)
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.
Realtime (RTAI, etc), for Racecar Brain (Score:2)
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?
Re: (Score:2)
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)
Why and Why Not (Score:2)
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)
I second the vote for Ubuntu (Score:2)
Some clarifications (Score:2, Informative)
Also, when I talk about
Re: (Score:1)
Re: (Score:2)
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
Insulation from distro (Score:1)
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
The big ones (Score:2)
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.
*Desktop* distro, not embedded (Score:1)
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
More Clarifactions on Embedded SDK (Score:1)
The question actually was asking what Host distribution we should support, not what Embedded targets to compile for.
Re: (Score:2)
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.
Gentoo (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
openembedded.org and nslu2-linux.org ... (Score:1)
The perfect embedded linux distro: (Score:1)
Re: (Score:1)
Dunno.... (Score:1)
rhY
What about ... (Score:2)
-b.