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.
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"?
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!
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
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.
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.
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 available version of software, which works well, up to a point. It is the unfortunate truth that a new software version fixes bugs, but introduces new ones (i.e security is never tested against brand new code, gentoo has very little testing time). Usually less, of course, but still not good enough for an embedded OS.
Sorry, but for embedded stuff, a binairy based distro is probably safer (bundle the source with it, to give choice, and to comply with the GPL) for an embedded application.
My own $0.02 of opinion.
---- I am certain of only one thing : I know nothing else.
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.
oh, yeah, make and all other tools running on tiny target box - fine grained control Gentoo style in Real Life ;)
this field has been intentionally left blank
-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.
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 other and is as usable as possible. I think you need to realize that almost anyone building embedded devices does complete customization to the environment used to run their device. Look into the embedded space from Red Hat and you'll find that almost nobody is using Red Hat Enterprise Linux for their devices, as it is much too large and too generic. Instead, they home grow their own "distribution" which has exactly what they need and nothing more. My entire point is that Gentoo is better served in doing this, since that is a primary design goal of Gentoo, rather than binary distributions whose primary design is a coherent single product.
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. I just don't see you wanting to update all your code base daily, as you develop an app for a device... But maybe it's just me.
---- I am certain of only one thing : I know nothing else.