Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Which Embedded Linux Distribution?

Cliff posted more than 7 years ago | from the cream-of-the-crop dept.

Linux Business 62

Abhikhurana writes "I work for a company which designs a variety of video surveillance devices (such as MPEG4 video servers). Traditionally, these products have been based on proprietary OSs such as Nucleus and VxWorks. Now, we are redesigning a few of our products and I am trying to convince my company to go down the Linux route. Understandably, our management is quite skeptical about that and so I was asked by our CTO to recommend a few RTOSs which have mature networking stacks and which work well on ARM platform. I know that there are many embedded Linux based distributions out there. There are commercial ones such as Montavista, LynuxWorks, free ones such as uclinux, muLinux and some Linux like distros such as Ecos. What is the most stable and best community supported embedded Linux distribution out there?"

Sorry! There are no comments related to the filter you selected.

Don't forget... (-1)

SCO$699FeeTroll (695565) | more than 7 years ago | (#18981649) pay your $699 licensing fee you cock-smoking teabaggers.

Re:Don't forget... (0, Troll)

renegadesx (977007) | more than 7 years ago | (#18981773)

Can we get this guy banned? Seriously, this fuckwit is not contributing

Stay on topic or chances are somebody will find out where you live and teabag your sister (sorry but shes not going to sleep with you)

Re:Don't forget... (0)

Anonymous Coward | more than 7 years ago | (#18982173)

i enjoy him.

missed ya, buddy! welcome back :)

Re:Don't forget... (2, Informative)

bradkittenbrink (608877) | more than 7 years ago | (#18982265)

whatever, just make him a foe so he's automatically modded down for you.


Anonymous Coward | more than 7 years ago | (#18982301)

Because people like parent make slashdot enjoyable for me.

As much as I'd like to read everyone's uninformed ego inflating karma whoring posts, the Parent livens things up, and breaks the monotony. It's great trolls get freak out replies, too. Esp. that 20 minutes for a 17 meg file mac troll. Good Stuff.

Coming Soon: Ubuntu (2, Insightful)

div_2n (525075) | more than 7 years ago | (#18981817)

If their employment page [] is any indication, I'd say Ubuntu will be very soon.

Re:Coming Soon: Ubuntu (2, Informative)

dgatwood (11270) | more than 7 years ago | (#18984337)

Eh. Practically any Linux distro could do what this person is asking for without blinking at this point, assuming the CPU is fast enough to keep up. Video isn't really a hard-real-time environment. Where the embedded vendors shine is in supporting custom hardware, which I assume this company is using. That doesn't sound like it's up Ubuntu's alley. Mobile and embedded are not the same thing, though they do overlap.

My advice: talk to several vendors, tell them what you're trying to do, and let them give you and your management a presentation about what they can offer. While my stock (not yet public) would love it if you pick MontaVista (and I can honestly say that IMHO, they do excellent work, BTW), what's most important is that you pick a company that you feel comfortable working with, and if that's the MV folks, great, but if it's somebody else, that's okay, too. I suspect that they'll tell you much the same thing.

Tell 'em David sent ya.

Openembedded (4, Informative)

bug1 (96678) | more than 7 years ago | (#18981821)

It seems isnt as well known as it deserves.

Openembedded has;
  - Been around for a number of years
  - Has a strong developer community
  - Is used be a few commercial projects, notably openmoko.
  - Can builds its own cross compiler

It allows you to pretty easily define your own distro and build an image for it.

Re:Openembedded (1)

Grishnakh (216268) | more than 7 years ago | (#18982295)

I just built a filesystem with OE, and I wasn't that impressed. The documentation is very sparse, and there doesn't seem to be any way of defining what components should go into the filesystem. You only get pre-baked choices for particular platforms. If there's a way to choose which packages you want, I sure haven't found it.

Re:Openembedded (1)

bug1 (96678) | more than 7 years ago | (#18984323)

Well, there are lots of examples there, if you have time and patients you can follow it through.

OE uses tasks (similar in concept to debian tasks) to group packages.

e.g. dev/packages/tasks/ []

Re:Openembedded (1)

sarathmenon (751376) | more than 7 years ago | (#18984751)

if you have time and patients you can follow it through.

I don't think that patients will be an liberty for him if he makes embedded hardware.

Mod Parent Up (2, Informative)

quo_vadis (889902) | more than 7 years ago | (#18986743)

I just spent last semester dealing with openembedded and a pxa270 based dev board. The documentation is not the greatest, but once you have everything figured out and working, OE's power and flexibility really shine through.

Dont forget about the GPL (3, Informative)

Constantine XVI (880691) | more than 7 years ago | (#18981915)

Just a friendly reminder, but don't forget to tell your higher-ups that using a *modified* Linux in their product means they have to release the source. Don't forget that, or you may be in for a nasty suprise. I don't know how much of an embedded system NetBSD is, but if putting out the source is going too far for them, that could be an option. If they don't mind that, then by all means go ahead.

(karma shields to 120%)

GPL is not a problem ... (2, Insightful)

twitter (104583) | more than 7 years ago | (#18982047)

... except with people saying things like this:

Just a friendly reminder, but don't forget to tell your higher-ups that using a *modified* Linux in their product means they have to release the source. Don't forget that, or you may be in for a nasty suprise.

How friendly/nasty of you. First, you assume the company is anal about the working of their systems or sharing kernel fixes and drivers. Second, it does not matter anyway. They can put all of the stuff they can't or don't want to share into code they don't share. The GPL does not force you to break MPEG4 NDAs, it won't publicize code you don't mix in, or steal your wife. All it does is make sure you pass on the same rights for code that's not yours that others passed onto you. The GPL encourages people to share but it never forces an issue. To draw GPL ire, you have to close off someone else's code.

Re:GPL is not a problem ... (3, Informative)

Constantine XVI (880691) | more than 7 years ago | (#18982175)

It is quite possible that this company doesn't want anyone to know about what they've done to the kernel to work better on their hardware or for their purpose. If I start modifying the kernel to be more efficient in handling a widget-smashing box, then put it into my super-fancy widget-smashing box without disclosing the fact or releasing the code, I am in a lot of legal trouble, because the GPL says that I have to release the modified versions of any GPL code I've used. I can still write the widget-smashing code and make it 100% closed, it's just the kernel I have to be careful about. It's not that I'm trying to steer them away from using Linux in their product, I'm just making sure they know what they're doing. Once again, I have no idea how anal these people might be, but if they are, this is stuff they should be aware of.

Re:GPL is not a problem ... (1)

Grishnakh (216268) | more than 7 years ago | (#18982325)

Well, if they can modify the kernel to work so well, maybe they can just write their own kernel. All the GPL says is if you modify someone else's work, then you need to pass the revisions downstream (to the people you distribute the binaries to). If you're not willing to do that, then you don't get the benefit of a free kernel with source code, and you'll just have to make your own.

Re:GPL is not a problem ... (1)

dedazo (737510) | more than 7 years ago | (#18982341)

the GPL says that I have to release the modified versions of any GPL code I've used.

Not to side with twitter here, but the GPL says you have to make available the source of any modifications you've made to GPL'ed software if you are also distributing them. If you're not, then you don't have to do anything. Like Google. Although I think the GPL3 will pretty much kill that (I think?).

Now in this case obviously there is intent to distribute modifications to Linux in the device(s) the company will sell, but still.

Re:GPL is not a problem ... (2, Interesting)

Grishnakh (216268) | more than 7 years ago | (#18982411)

Although I think the GPL3 will pretty much kill that (I think?).

Huh? No, GPLv3 has the same terms for distribution as GPLv2. Its main change is the patent provision, which (I believe) requires you to unconditionally license your patents, which apply to GPL code that you distribute, to the people you distribute it to. So if MS adopted some GPL program, added some great feature which they had a patent on, and then distributed this new version, the GPLv3 would require that anyone they distribute this code to also have a free patent license, so that MS can't turn around and sue them for patent infringement on software they gave to them.

Re:GPL is not a problem ... (3, Informative)

codemachine (245871) | more than 7 years ago | (#18982539)

If I recall, there were 3 things that GPLv3 was originially going to accomplish, all of which had to do with ways people were perceived to be abusing GPLv2:

- address patents and how they may affect distribution of code
- close the TiVo problem of tying hardware to a software revision (where people can't truly modify their own GPL code on their own device)
- close the ISP loophole where you aren't really "distributing" your code, so you don't have to share it

We mostly hear about patents, and we heard a bit about the hardware issue when Linux objected to a GPLv3 revision. Not so much makes the news about the ISP loophole. I am not sure what the latest draft of the license does in this regard.

TiVO doesn't distribute source code (1)

quanticle (843097) | more than 7 years ago | (#18983509)

Now in this case obviously there is intent to distribute modifications to Linux in the device(s) the company will sell, but still.

As I recall, TiVo "distributes" its modified code every time it sells a device. However, TiVo doesn't give away the modifications to the kernel in their device. Is TiVo violating the GPL? If not, then why does the OP's company have to give away their modifications?

As I recall, TiVo made the argument that they were primarily distributing hardware, and that the fact that the hardware ran a modified version of Linux was incidental. Can the OP's company use the same argument?

Re:TiVO doesn't distribute source code (5, Informative)

eldepeche (854916) | more than 7 years ago | (#18985017)

TiVo distributes Linux every time they sell a device, and they distribute source code. The TiVo hardware has some kind of device that checks for the original unmodified TiVo software, so that their Linux device cannot accept user-made changes. This does not violate GPL v2.

Re:GPL is not a problem ... (1)

xtal (49134) | more than 7 years ago | (#18982377)

You only have to release changes to people who you liscence the code, or product to. You do NOT have to release the changes to the open community. The person who receives the changes is free to do that, if they want, however.

Realtime Control with Linux Considered Harmful (5, Interesting)

TerranFury (726743) | more than 7 years ago | (#18981997)

Whether Linux is appropriate depends largely on the type of project you're doing. You're probably aware that tons of routers and assorted network gear runs Linux. It might be the best choice if that's what you're doing. But if you're trying to do hard realtime control with Linux... well, if your experience is anything like mine was, it'll be painful.

I did a project with a 266 MHz PII single-board computer [] once. I chose it because it had tons of on-board A/D and D/A, and when I ordered it I asked the company [] for their Linux drivers, etc, as well (which they advertised). They sent me a customized version of Redhat to be installed on the development machine, and a bunch of tools to set up a stripped down distro on the target as well, using the same libc libraries, etc.

There were numerous errors in what they sent me, including stupid things like configuration files having DOS instead of UNIX line endings. How this got out the door I do not know. But, I could fix all those dumb oversights, so that wasn't the problem.

The issue was that the distro they sent did not include any realtime extensions (a must for my application), so I endeavored to install RTAI [] on it. This was where I began to have real problems.

The kernel they were using was old -- 2.2.some-low-number. Assuming this is what their drivers would work with, I found the vanilla source from for a nearby 2.2 version, slightly higher, compiled it, no problems. I then tried it with their extra A/D and D/A drivers compiled in: no problems. Then, I tried it with the RTAI extensions (without their extra drivers: Test one thing at a time!) It compiled, but when I tried to run RTAI diagnostic programs the machine would unceremoniously reboot. No good.

"Ok," I thought, "this is a pretty old version of RTAI. Let's try a newer version; maybe that's a little more mature." In order to do that, I needed to use either a 2.4 or a 2.6 kernel. So, I started by trying to build a 2.4 or a 2.6 kernel, again from, first, without either RTAI or the extra drivers. First problem: gcc too old. Solution: Compiled on another machine (really, coLinux on my laptop, running Debian Sarge). But after putting the kernel images in the correct locations and reinstalling the boatloader with lilo as you'd expect, the machine would just reboot every time it'd start to execute the kernel. This happened for more permutations than I can remember of 2.4 and 2.6 kernel versions, and configuration options.

Unable to get RTAI working on an old kernel, and unable to get a new kernel to run, (and desperately needing realtime), I ended up putting DOS on the thing and writing code in 16-bit real mode. This gave me essentially unfettered access to the hardware, with fast interrupts, so that, even though people tend not to consider DOS an 'RTOS' per-se, it stayed out of my way enough that I was able to access the hardware directly and run with guaranteeable latencies.

DOS made lots of things harder -- networking and accessing extended memory in particular -- but solving each of those problems proved possible, since I was working with small enough atomic "pieces of the system" that they could be debugged. When I'd been trying to put together linux with RTAI with the given drivers, I was working with a big-monolithic-kernel... running-in-another-mini-kernel, and I could do little more than follow instructions, compile, and pray. If it'd worked, it'd've made my life much easier, but, when it didn't work, I was pretty much at a loss.

If you're on a tight time budget and you've never used embedded Linux before, as much as I love Linux, I've got to say: If you're doing a realtime project, just pay the money for a "real" RTOS.

** If anyone else has had different experiences, I'd be curious to hear them. Though it's too late now, I'd also be curious if anyone has some after-the-fact ideas about why the 2.4 and 2.6 kernels wouldn't execute.

Re:Realtime Control with Linux Considered Harmful (1)

Darundal (891860) | more than 7 years ago | (#18982865)

This sounds more like a bad job on the manufacturers side than a problem with linux itself.

Re:Realtime Control with Linux Considered Harmful (5, Informative)

dugenou (850340) | more than 7 years ago | (#18983409)

Hard realtime works great on Linux, but choose your manufacturer carefully. All the following are free and open source.

When it comes to hard RT extension (even in userland), I tend to prefer Xenomai [] over RTAI. Xenomai has better non-x86 support (ARM is there), nifty so-called skin support for legacy API's (VxWorks, uITRON, ..), and very good community.

Talking about distro, ELDK [] is best what comes to mind. This is industrial grade software, free as in beer and speech, but with commercial support if needed. The toolchain is excellent. What goes into the flash image must be hand-picked because only you know the necessary stuff.

If you are in D/A A/D business, then have a look at Comedi [] , it is also RT enabled by the comedi-rtdm project.

All these tools/projects are used and backed by industry. I'm a simple user of these tools, and they make my day life happy.

MOD UP (1)

TerranFury (726743) | more than 7 years ago | (#18983607)

Thanks for the links. May be useful in future if I do something like this again. *bookmarks*

Re:Realtime Control with Linux Considered Harmful (1)

Non Dufus (265187) | more than 7 years ago | (#18998803)

If you use the right extension, it is NOT harmful.

I have used Xenomai in a real product that shipped for a company that does embedded real-time systems for industrial controls. This was on a Freescale mpc5200 (PowerPC). Worked nicely for our real-time application. A guy named Philip Gerum heads up the project and is a swell guy to work with. If you need real-time support on x86, ppc or arm, then xenomai is definitely the way to go.

Accolades Xenomai!

Speaking of VxWorks (2, Informative)

Anonymous Coward | more than 7 years ago | (#18982063)

If your company if comfortable with VxWorks, how about Wind River's offering... []

Re:Speaking of VxWorks (1)

thegrassyknowl (762218) | more than 7 years ago | (#18983105)

*um*... Tried that once (their Linux offering). It was good, but it wasn't exactly small when we tried it . It wanted a target with well over 500M of flash, and that was after I went through their messed up dependency tree and cut it down from the default size which was just crazy. We did work with them on it but it wasn't shrinking fast enough for our liking.

Re:Speaking of VxWorks (0)

Anonymous Coward | more than 7 years ago | (#18998969)

Wind River has made quite a bit of progress in that area. They're latest offering has a "Glibc small" BusyBox-based filesystem and even one with uClibc.

Re:Speaking of VxWorks (0)

Anonymous Coward | more than 7 years ago | (#18991053)

Also, TimeSys has a pretty good rep. (My company builds ruggedized mil-spec SBCs among other things, and for those cases where a customer REALLY, REALLY wants Linux, TimeSys is who our hardware engineering division sends them to.) One of their developers (Thomas Gleixner) is one of the main developers (with Ingo Molnar of RedHat being one of the other big ones) of the RT-PREEMPT patchset, which is slated to become the official Linux RT implementation. (i.e. it is the only RT extension for Linux that has any plans for mainline kernel inclusion, and in fact half of the RT-PREEMPT infrastructure is already in the mainline kernel.) The RT-PREEMPT patchset is also what Wind River uses in their Linux offering from what I've seen.

Sadly, my company's lawyers are also massively paranoid, and won't actually install Linux in ANYTHING we provide as a product, even if it is clearly the technically superior solution. We use VxWorks and it absolutely and utterly stinks.

Posting AC since while my opinions of VxWorks are well known to my coworkers, I don't want my name attached to any public comments regarding its quality.

Note that LynuxWorks doesn't actually have a realtime Linux distribution, they have a proprietary RTOS (LynxOS) that is API (and userland ABI also I think) compatible with Linux.

Well (1)

aitikin (909209) | more than 7 years ago | (#18982131)

Gentoo can do what you want, if you know what you're doing, so can LFS and other source distros. It's just what you need really, lets you skip anything you don't need and put only what you want.

Roll your own (1)

AccUser (191555) | more than 7 years ago | (#18982495)

There is no reason why the OS for an embedded application shouldn't be part of your product build. Back in 2002 we developed with a custom GNU/Linux build for our hardware, and it was much easier to work with than anything offered by commercial providers of 'real-time' GNU/Linux.

What you really need to pay attention to is your toolchain. Get that right, and you are laughing.

Re:Well (2, Insightful)

dhasenan (758719) | more than 7 years ago | (#18982693)

On an embedded system, you probably don't need anything running but the kernel, udev, and your application. You don't need most of your libraries; it's going to be more efficient to statically link everything. You don't need bash. You don't need Python. You don't need a package manager. For this task (networked cameras), you need ifconfig, a dhcp client, maybe a stripped Apache, and your custom application. And you can probably incorporate ifconfig / dhcp functionality into a library (take them from BSD or something licensed under LGPL) and put them in your application, which could also handle init if space is tight. (Though you probably don't want this, in case your appliance has to be reset.)

In short, while you can use Gentoo to build your target system, it won't effectively be Gentoo by the time you're finished. And it doesn't matter which distribution you choose at that point.

Re:Well (2, Interesting)

Dahamma (304068) | more than 7 years ago | (#18984281)

On an embedded system, you probably don't need anything running but the kernel, udev, and your application. You don't need most of your libraries; it's going to be more efficient to statically link everything. You don't need bash. You don't need Python. You don't need a package manager.

You don't *technically* need anything else, but for development it can be IMMENSELY useful to have a shell and a base set of utils. Busybox [] will get you everything you need in a multicall binary under 1MB (dynamically linked to glibc).

Things can be even smaller using uclibc [] instead of glibc, but unless you are building an EXTREMELY low end embedded device and can't spare an extra 1-2MB or so (or 1/2 that with a compressed filesystem like cramfs) it may not be worth the extra hassle trying to build a uclibc toolchain (and potentially deal with uclibc issues with other utils/libs you may use).

Anyway, the nice thing about Busybox is that you port a single package and get huge range of utils. Overall I agree 100% with a previous poster who said the key to rolling your own OS is getting the toolchain working - once you have that, porting is relatively easy (I'm assuming we're talking about non-x86 embedded systems here... with x86 it becomes easier still, as the vast majority of open source development is done on that architecture).

Memory Management Issues? (1)

billstewart (78916) | more than 7 years ago | (#18984057)

I don't know if it's still true, but the last time I looked at uCLinux, it had a rather different approach to memory management than regular Linux, and was designed for devices that didn't have real memory manager chips. Is that still the case, or is it more mainstream now?

Maybe not Montavista (1)

Grishnakh (216268) | more than 7 years ago | (#18982349)

I've worked with Montavista at two employers now, and the biggest complaint is the extremely high licensing costs. Apparently, it's a lot cheaper to use some highly proprietary RTOS than Montavista's offering.

Also, you have to pay high per-unit royalties, even though the software is GPL. For this reason, customers don't want to use it.

Why people use Montevista or Windriver (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18990439)

I've done a number of embedded Linux ports, on a wide variety of hardware. My experience has been that the ONLY reason why people go with Montevista or Windriver is CYA (Cover your A**). It's the paperpushers (managers and bean counters) who like these companies, not the techies.

As far as support goes, both companies are well known for not providing any serious support. Sure, they'll take your money (usually) so that you can say you have a support contract. But forget getting any real help.

The bottom line is that you really need kernel talent in-house if you're doing any sort of embedded project, regardless of what O.S. you're using. This is simply the name of the game.

To put things in perspective, I once saw a Cisco Business Unit which had a Purchase Order for a support contract with Montevista try to get Montevista to take it. The sales staff at Montevista wouldn't even return their calls!!!

I know that sounds hard to believe; I couldn't believe it myself, and I was there. Normally people die to try to get Cisco's business, especially for an entire BU. This is as close to free money that you can get. And yet they simply wouldn't return the phone calls until much later.

This is truly amazing. But it gives you an idea of what these companies are like. And still, people do business with them. Go figure.

Re: Why people use MontaVista or Wind River (1)

abacus1 (1098299) | more than 7 years ago | (#19008617)

I'm a Cisco employee, and I am involved in weekly conference calls with MontaVista for an embedded Linux project. MontaVista really solves the issues we report to their support department, although not always as fast as we would like it.

Try baby steps - Wind River Linux (1)

Ada_Rules (260218) | more than 7 years ago | (#18982487)

You really might want to consider going with Wind River's Linux product. It keeps the bosses happy because they have a familiar vendor and honestly, it is not a bad embedded distribution/tool suite either.

Some ponderings to think about (2)

wellingj (1030460) | more than 7 years ago | (#18982813)

You might want to check out BuildRoot [] . It's what Gumstix [] uses for their distributions and it works pretty well.
They have even has the rt patch [] from Ingo Molnar merged into their standard distribution. Sounds like a Gumstix might
not be a bad way to go now that I think about it. And then you would have some pretty good community support. My $.02 ...

eCos? (0)

Anonymous Coward | more than 7 years ago | (#18982873)

I was alarmed to see that the blurb described eCos as a Linux distro. eCos is entirely its own creation. Here's the entry [] from their FAQ:

Is eCos Linux?

As eCos originated from Red Hat, probably most famous for its distribution of the Linux Operating System, it has become a common misconception that eCos is Linux or in some way based on Linux. However eCos is a completely separate product, with a separate source base. eCos does have an EL/IX level 1 compatibility layer though, allowing it to be compatible with many of the Linux APIs.

Montavista hires spammers (1)

njchick (611256) | more than 7 years ago | (#18982927)

Montavista [] hired spammers [] to send their ad [] . Not nice. They didn't even reply to the developer who complained [] in LKML.

QNX Opinions? (0)

Anonymous Coward | more than 7 years ago | (#18983077)

We're considering using QNX for a new (embedded) project at our company - anyone with QNX experience want to comment?

Re:QNX Opinions? (1)

WindBourne (631190) | more than 7 years ago | (#18983865)

I used it back in mid 90's. Nice and solid.

But at my last job, we used WindRiver. They offer DO-178B Linux . And in our case, we needed DO-178B, so that limits the selections.

Why?? (1, Redundant)

sunderland56 (621843) | more than 7 years ago | (#18983289)

Why do you want to do this? Sure, it's "cool" and you'll get modded up for life on /. - but is it a wise decision?

With Nucleus, for example, you spend 99.9% of your time writing/testing your own code. You're on a solid, well-known base that you have prior experience with. Clearly your management has no problems with their licensing scheme or pricing.

If you go to linux, you'll get:

  1. A learning curve - things work differently, and all the function names are different.
  2. You spend some significant time configuring and compiling a Linux distribution. On your second project this may take a minor amount of time - but on your first project, it will take longer than you think.
  3. You need to worry (and involve the corporate lawyers) about licensing.
  4. If you want any support, you need to pay - so there may not actually be any cost difference. (If you already have a site license for Nucleus, then Linux would be more expensive).

I'm not saying that Linux is necessarily bad here.... just that it may not be the nirvana that you think.

Re:Why?? (1)

aadvancedGIR (959466) | more than 7 years ago | (#18985345)

I worked for years with Nucleus+ and VxWorks, and tried WindRiver RtLinux. And honestly, I really like all of those, but you can't really compare Nucleus+ and Linux because they are not designed for the same usage.

Nucleus+ is a small closed OS (that means you need to statically link everything you need unless you use something like a Java virtual machine on top of it). It can be OK, but not for everyone.
Also note that I rewrote the dynamic memory allocation from scratch because the one provided with Nucleus+ was performing poorly when we had to drasticaly increase the size and number of allocated buffers, and this is only one of the examples saying that N+ is better for small application rather than for big ones. Both VxWorks and Linux are quite the opposite on that point.

Re:Why?? (0)

Anonymous Coward | more than 7 years ago | (#18992667)

It really depends. (At least in terms of VxWorks vs. Linux).

Code portability - If they're using an older version of VxWorks (like the 5.x series), porting to 6.x may be nearly as tough as moving to Linux anyway. My company is currently stuck using 5.4 due to compatibility issues with our current application codebase and toolchain.

Network performance - if the next version of the submitter's company's product needs any network functionality, VxWork's network stack utterly blows compared to that of Linux. (Disclaimer: For the reasons stated above, my experience is limited to the network stack of VxWorks 5.x, 6.x may be improved. There are also "drop-in" network stack upgrades such as the Interpeak stack for both old and new versions of VxWorks, but they cost extra money.)

Driver stability - Since VxWorks is proprietary and so are the board support packages (embedded-speak for "hardware drivers"), there are frequent cases where the drivers for particular hardware are essentially written by every single company that uses that hardware. For example, we use SBCs that are 80% identical to the Motorola MVME6100 in hardware configuration, yet even for that common hardware, our board vendor has to write and maintain their own BSP independently of Motorola's since Motorola's is closed-source. In Linux, instead of wasting thousands of dollars in labor trying to get Ethernet driver stability issues fixed, we'd just use the same driver code common to everyone else using a PowerPC board with a Marvell system controller is using.

Lawyer happiness - VxWorks winds hands-down here, even against Wind River Linux. Lawyer happiness with VxWorks is why I have job security (nearly 50% of my workload this year has been trying to fix and work around problems with VxWorks that Just Work in Linux.)

NetBSD (3, Interesting)

allenw (33234) | more than 7 years ago | (#18983329)

While I realize you specifically asked about Linux, it is probably worth pointing out that NetBSD has been used as an embedded OS on ARM for quite a while. See NetBSD's embedded page [] for more information.

RTEMS rather than LINUX (2, Informative)

Anonymous Coward | more than 7 years ago | (#18984025)

Linux is not the only open source solution for embedded devices: Other include RTEMS in particular is much closer in functionality to VxWorks so it is likely porting to it would not be a huge job. It is well supported, extremely stable and free from GLP licensing issues.

Maybe not BlueCat (Lynuxworks) (1)

Wrataxas (745719) | more than 7 years ago | (#18984491)

My company went with Lynuxwork's BlueCat [] as our embedded Linux and continually regretted it. We had no Linux expertise and so wanted the professional services that was available from Lynuxworks along with their distro. However, we found that 1) we had a hard time getting them to honor our business priorities, and 2) the distro was based on a kernel old enough that we couldn't update to the latest releases of things to get bugs fixed. It would have been much better to hire a good Linux guy (which we ended up needing to do anyway) and going with a standard distro. The amount of support we could rustle up from the community and consultants was at least as good and sometimes better than the support from Lynuxworks that we were paying for.

eCos is not Linux (1)

DavidNWelton (142216) | more than 7 years ago | (#18984563)

As the page says, []

eCos is an open source, royalty-free, real-time operating system intended for embedded applications. The highly configurable nature of eCos allows the operating system to be customised to precise application requirements, delivering the best possible run-time performance and an optimised hardware resource footprint.

It's a pretty cool little OS, mostly because it's smaller and easier to understand, and hack on, then Linux. That said, it also doesn't do, or even try to do, as much as Linux, so you would want to use it for smaller, simpler devices, most likely.

Roll your own (3, Interesting)

bensch128 (563853) | more than 7 years ago | (#18984583)

Thats what we did:
1) build a tool chain using [] . Note: this uses glibc instead of newlib/uClibc but there are patches to make it work.
2) Download and build the mainline kernel with needed modules compiled in
3) Place onto device.
4) Develop application
5) ???
6) Profit!

Easy! (1)

soccerisgod (585710) | more than 7 years ago | (#18984819)

All you really need is a kernel, some startup scripts and busybox. That way you can have pretty much everything you need in less than 4mb of flash, and it's all free! (as in beer and speech)

The one you build... (2, Insightful)

wolf31o2 (778801) | more than 7 years ago | (#18984831)

As I am sure you can guess, I'll answer with a simple answer, which likely means the most up front work but also the best capabilities. You'll want to build one yourself. This doesn't mean that you have to do all the work. As an example, I'll (obviously) use Gentoo. You install Gentoo and build your Gentoo-based distribution with exactly what you want in it. Since Gentoo is source-based to begin with, it should be easy to transition to your actual platform. Of course you won't want a C compiler and such on your actual platform, you do that on your development systems. This is really how most embedded Linux is done, with a development machine building the customized distribution for the actual release platform. I'll be honest and say that my experience with other embedded Linux is pretty much nil, but Gentoo will do what you want, and we have great community support. The nice thing about using Gentoo is it is basically the same thing as the normal distribution, and we support the platforms used for most embedded devices. Of course, you'll want to use what suits your needs best.

Observation about support (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18985317)

Something you can point out to your doubtful manaagers...

Having worked with pSoS, vxWorks, and embedded Linux, I have found the support process to be identical for both pay and free OSs:

1. Ask the provider for help.
2. Ask on a user's group / mailing list.
3. Get the code and fix it yourself.

You will be ignored at stage 1 nearly every time, because the Linux development people are busy, and because your proprietary OS provider has enough bigger, better paying customers that they can afford to ignore you. In stage 2, a free OS often has a bigger user group which is much more willing to share, so you stand a better chance of getting an answer there. Of course, you usually end up at step 3 anyway, which is free for eCos/Linux (give or take paying the developer), but which costs tens of thousands of dollars for the vxWorks etc...

armedslack, debian arm (1)

bl8n8r (649187) | more than 7 years ago | (#18986565)

I've been able to get armedslack up and running on an arm board with 32 meg of ram. It worked quite well. Eventually ended up with debian-arm for production because of specific glibc and kernel versions which were available. I was able to use NFS and ssh on the ARM system and didn't notice any oddities with the networking stack (2.4 kernel). Some sites below where you can get a few of the arm distros I used.



 taller-arm/current/images/netwinder/ []

A couple of things... (1)

bergeron76 (176351) | more than 7 years ago | (#18989187)

I've used Arcom Linux Distribution(Debian based) and for the most part, I like their products.

Also, eCos isn't a linux distro - it's a bootstrapper like RedBoot. You can use it on ARM, but it's not a full kernel.

Picotux (1)

HomelessInLaJolla (1026842) | more than 7 years ago | (#18992019)

These guys [] might know something about embedded Linux. The info [] page says uCLinux.

straight talk (0)

Anonymous Coward | more than 7 years ago | (#19002643)

does this way work

Re:straight talk - when keeping it real goes RIGHT (0)

Anonymous Coward | more than 7 years ago | (#19002807)

I have paid hard cash for all that you are trying to do and did it with ARM and I got to tell you that if I were going to use an ARM platform I would not use any of the mentioned
con artist because you are in way over 50 grand and way over your head and no matter what and you will still be holding your D*&% in your hand....In fact those companies do not sit around and fix your problems they are there to steal money from you and put you further away from your arrival point while they collect all the cash. Those companies are all a scam period. One reply stated on the absolute crap of a release that was not even Q C'ed. Do yourself a favor and go with a PROVEN embedded leader that has great price points and the MOST mature user linux support COMPULAB in Hiafa Israel. Numerous mature builds in the community plus they give you their own updated and mature kernel release with robust board support for drivers and basically everything you need. I wish I would have found these guys before I got screwed by Xscale Intel PXA255 and PXA270 as well as AMD mips au1200, LOGICPD, WIND RIVER,
and the others who talk big and CANNOT deliver. If I were you I would dump the ARM platform like even INTEL did and fo with embedded X86 so you dont have to make a custome modified build of the kernel and every app you want to use and instead just load the x86 version and BAM you are running and your bosses will be happy that you didn't screw up and saved them money... If I would have had straight talk and real advice I would have enough money to go buy a new Mercedes instead of driving a Civic...
PS anyone who writes anything to dispute what I have written is full of Sh*#!

Choosing a CPU for an embedded project (1)

abacus1 (1098299) | more than 7 years ago | (#19008599)

When starting a new embedded project, not only an operating system has to be chosen but it also has to be decided which CPU will be used in the project (Intel-architecture, PPC, MIPS or ARM). You cannot choose a CPU and ignore the operating system, and you cannot choose an operating system while ignoring the CPU it will run on. What I learned the hard way is that it is important to choose a mainstream CPU, even if this means that it will consume a little bit more power or takes up some more PCB space. Otherwise you might be surprised some day that the embedded Linux vendor drops support for the CPU you selected for your project.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?