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?"
And with just some extra care also Ubuntu/Kubuntu/Xubuntu/gNewSense...
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?
"It's too bad that stupidity isn't painful." - Anton LaVey
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.
Hey man, move to Windows better!
Hide your files and folders from others!
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.
Money for nothing, pix for free
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"?
DSL is designed to work off, among other things, compact flash cards. Given that those cards have a limited number of write cycles, DSL has developed a 'frugal install'. On boot, the contents of the card are read and then everything happens in memory thereafter. The process is a lot like booting a chip from an eprom. So, there is a process that is very common/prevelant in the embedded world and DSL provides an example of how to do it.
DSL is based on Knoppix which is, in turn, based on Debian. www.damnsmalllinux.org
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)
...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 they do a sane install.
I drink to make other people interesting!
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?
When I worked for ARM (quite recently) they could work with most platforms, since all the heavy lifting was submitted to a cluster of machines and if you wanted a specific OS/distro/version you could specify it and the job would go to that machine (e.g. bsub -I -r "solaris" foo would queue command 'foo' to run on a solaris box).
However, the machine they had the most of was RHE3 (Red Hat Enterprise edition 3), so that's probably a good one to target.
Other good ideas for your tools include:
* Batch/command-line mode, so your tool can be called by a script.
* Parallelisability, if your jobs take more than ~10 minutes on a high-end machine. It's easy to get 4 * 3GHz cores, but hard to get 1 * 12GHz core. Xilinx place and route, this means YOU.
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).
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
No that would be Centos, not Fedora.
Common sense is not so common
Gentoo is ideal for embedded systems. No other distribution gives you such fine grained control over what to bring in and what to leave out. This is critical for resource constrained devices.
I would say it would be very nice of your SDK to support building for the GP2X [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 accessible. Make your SDK fit in that fold and you've got a winner, I would say.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
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: The Power to Serve!
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.
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.
/* No Comment */
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.
There are no uninteresting things. There are only uninterested people.
There are quite a few distributions available, montavista, etc.
Even gumstix has their own build process; a very nice system for rebuilding the embedded linux in the gumstix flash.
I'm very fond of "diet-pc"; it was designed for embedded applications; based on busybox, VERY easy to customize, and the author even includes example images for X-terminal clients, file servers, music players, etc.
Diet-pc would be my first choice, followed with Debian. I wouldn't even consider using redhat.
I suppose your code runs just fine on Windows CE too?
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
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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?
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.
One way to look at the question of which distro to support is to ask what your SDK depends on in the host OS.
/bin/sh points to (bash vs rnd shell) and missing -devel packages.
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-less, static Makefiles which call 'gcc' may need to be patched or told what 'gcc' means.
Our tools run on a handful of distros and we usually run into minor issues like what
Supporting Cygwin may go fine at first as you generate cross tools and can compile packages, but you probably will run into trouble at some point when you try to build target filesystems or release ISOs and will need certain tools which have not made it to Cygwin. People say they want MSWindows support in a checkbox kind of way, but it's not such a bad thing to require Linux for development.
Good luck!
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.
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.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
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.
.deb but it's really not necessary to provide multiple packaging formats.
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 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 people will want to make sure they can at least talk to their embedded development boards first.
For most developers, providing a src.tar.gz and an RPM is adequate. I recommend RPM's because most people too dumb to build a source tarball are probably using RedHat/Fedora. Bonus points for
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.
I'm sure that this will seem a bit obvious due to my close ties with the distribution, but Gentoo 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, 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.
Essentially, your best solution is a distribution geared specifically for your devices. I think that Gentoo works as a good platform for basing your distribution from, as it is simple to learn and understand, as the entire system is very open and transparent.
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.
What you are doing with an embedded linux is targetting a certain environment - ie a kernel release, a version of glibc (or compact replacement depending on storage), and a collection of hardware.
I would suggest you nominate the version of gcc and any supporting tools required, and simply require those in whichever desktop linux release people use.
They're the only two distros one could point a finger at and say "this is Linux". All others, including Ubuntu, RedHat, SuSE, Mandriva etc. despite being great products are less community supported and too tied to the company behind them. The Microsoft-Novell (SuSE) deal should ring a bell.
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, which you could also use for personalized ring tones, alarms, text message receipts, and even emails. When plugged into the dock, it would have the exact same menu structure as windows, so even grandma could use it. Six simple shortcuts on a clean desktop: Firefox, Thunderbird, Photos, Movies, Games (preferably good ones, like nintendo games in an emulator, or something), Gaim, and Documents. Let's skip the "My". I always hated the "My". Just seems stupid, especially if you're on somebody else's "phone".
It would cost less than $100 including hardware (not including external usb keyboard, mouse, speakers, monitor, and gamepad), have a few gb of storage, decent picture quality, and an easy way to back itself up (addresses, video game scores, pictures, mp3s, xvid, email, phone numbers, buddy icons, etc.) over any old wifi connection.
The perfect linux distro (and hardware) would quickly then shut down sony with it's root kits, apples with it's drm, and microsoft with it's monopoly, bloat, and lack of a GPL. Everyone wins. I'll pre-order one today.
Besides the corporate monopolies squeezing the life out of every person, plant, animal, and economy on the planet, is any of this really THAT unrealistic? Is there a distro that works like this already? I surely haven't found an even half-assed close cell phone yet, which is tragic, since the SDA is so damned close. If it charged and also hooked up to those external peripherals via that little USB port, it'd be nigh on perfect, actually. That and have a better OS. LOL
rhY
I hold very few opinions. I hold information based on observation and fact. If you wish to disagree, please use facts.
-b.
Actually that's not true. If you're planning on supporting Windows 95/98/2000/XP, you still need to test across each one. This is especially true if you're planning on supporting both the 95/98 and 2000/XP eras as they're radically different systems.
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
I hold very few opinions. I hold information based on observation and fact. If you wish to disagree, please use facts.