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!

Choosing an Embedded OS for Sustainability?

Cliff posted more than 8 years ago | from the quality-of-software-life dept.


vivekb asks: "I work for a small start-up that's building its first commercial product. Because cost is less of an issue than development time, we've decided to make the brains out of an ETX computer with some sort of (non-realtime) operating system. Based on initial costs of tools and estimated license fees, the cheapest OS's I've found are Windows CE and several offerings of Linux. The big question that I can't answer is, 'How much will these platforms cost in sustaining activities?' In three years, when we're fixing bugs or applying patches, how much will we be paying vendors and how much will we be spending on internal developers? When the Linux kernel is at version 3.0 and our device is still running 2.6 -- or when CE reaches .INFO and we're still at .NET -- will support even be available? If anyone has past experience picking an embedded OS for a screen-and-button based electronic device, what did you learn to stick with or avoid?"

cancel ×


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

First post! (-1, Troll)

jesboat (64736) | more than 8 years ago | (#14738099)

First post!

Are you for real? (5, Funny)

Anonymous Coward | more than 8 years ago | (#14738184)

You are asking the Slashdot Fanboys to tell you what to choose between Linux and Windows CE? Are you for real?

There are other ebedded OS besides Linux (1)

SgtChaireBourne (457691) | more than 8 years ago | (#14739231)

There's more to embedded operating systems than just Linux. QNX [] and BSD [] come to mind first. There are actually very many including Symbian, Virtuoso, VxWorks, Tron and dozens of others. Even MS tries to make one, called WinCE, though unlike the others it's only used only rarely and even then only for the humor value.

VM/370 (2, Funny)

Anonymous Coward | more than 8 years ago | (#14738189)

I found VM/370 is the ideal. Rock solid and free to boot. Highly recommended.

I shouldn't do this but... (0, Flamebait)

creimer (824291) | more than 8 years ago | (#14738194)

The Mac Mini has nice embedded OS. :P

Re:I shouldn't do this but... (0)

Anonymous Coward | more than 8 years ago | (#14756719)

The Mac Mini doesn't have an embedded OS. They use OpenFirmware and a notebook (2.5") hard drive within the casing. Nothing to do with an embedded operating system at all

Hmm.. (3, Insightful)

Anonymous Coward | more than 8 years ago | (#14738206)

Well, one viable OS the author of the article is forgetting about are the BSD variants, specifically NetBSD if you're wanting to use it on an embedded device. Many people have been using netbsd on various devices, which even NetBSD supporting suspend on some. I believe the author needs to take a look at what he is really wanting however. Money is the main goal in any project. Please take some time to think, "what is the easiest and best way to deploy while making a profit?"


Linux for Longevity. (2, Insightful)

Deathlizard (115856) | more than 8 years ago | (#14738235)

If longevity is the #1 issue for your app, then your best bet in the long run is Linux simply because the kernel source code is available to you and can be customized to work exactly and naively for your application. Even if a kernel update comes out, it shouldn't be too hard to upgrade to it since the source code is available to make migrating to the newer kernel easier.

Keep in mind, that if code security is an issue, Linux may not be an answer since any kernel changes has to be available for public use. If no kernel changes have to be made for your app however, I don't think it would be a problem however IANAL. Other people here could answer this question a lot better than I could.

Re:Linux for Longevity. (1)

charlesnw (843045) | more than 8 years ago | (#14738268)

If longevity is the #1 issue for your appt hen your best bet in the long run is Linux simply because the kernel source code is available to you and can be customized to work exactly and naively for your application. No. If longevity is important then Viagra is what you need. No need to worry about source code or customization. It just works. Newer models last longer ;)

Answer: Linux (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#14738444)

If you want sustainability, then Linux is your best choice. Both the Open Source Development Lab [] and the academic pentagon (AP) of Carnegie-Mellon University, Stanford University, MIT, Caltech, and the University of Wisconsin (at Madison) actively use Linux in the research and development of operating systems (OSes). Being free, Linux is well within the budgets of all academic institutions. Linux will always be the first testbed for any new OS technologies arising at the AP.

Commercial OSes live only as long as their companies are financially viable. After Be disappeared, support for BeOS disappeared.

I am aware of these issues because my company was contemplating using Linux.

Re:Linux for Longevity. (2, Informative)

plalonde2 (527372) | more than 8 years ago | (#14738926)

For longevity (and feature set, and good design, and portability) pick Inferno [] .

Limbo, its language, is c-derived, but safe. The network model makes sense. And it's mature as an embedded platform.

Re:Linux for Longevity. (1)

Austerity Empowers (669817) | more than 8 years ago | (#14739238)

We've used an embedded linux (powerpc) for over 6 years, deployed in millions of units. No one needs to even know that it's there, in fact people think the company I work for is 0wn3d by MS...but linux has been lying there all the while doing things no one really wants to mess with (management GUIs etc.) It's survived through high attrition and remains up to date.

The only issue are still device drivers, that is always the achilles heel of open source. MS does a good job of helping certain companies not release datasheets & programming info, so certain video chips and other devices may be challenging. However you can still bypass that if you are just doing an x86-like embedded system.

Most embedded systems don't have this problem...just some specific applications and marketing requests I have come across ("Add 3D Graphics to a set top box!")

Re:Linux for Longevity. (1)

toddbu (748790) | more than 8 years ago | (#14739836)

Even if a kernel update comes out, it shouldn't be too hard to upgrade to it since the source code is available to make migrating to the newer kernel easier.

Keep in mind too that if they decide to change hardware platforms then they can fix bugs in the old code that make prevent them from doing the port if the cost of taking the new kernel is too expensive.

Re:Linux for Longevity. (1)

An dochasac (591582) | more than 8 years ago | (#14745702)

Here is the problem I see with linux for this application. When your hardware dies, you'll have to replace it. Chances are your 2006 Linux kernel won't support 2008 hardware. That's fine and a common problem with all OSs, the problem with linux is that the APIs the kernel presents to your applications is also likely to change enough to break your applications. Stability of this API is something that Linus has said he isn't interested in.

I don't recommend Windows CE for obvious reasons. It is expensive, controlled by a single company and subject to planned obsolecense by this company.

I would investigate embedded kernels for which the source is available and the BSDs, FreeDOS, open source versions of OS2 and (of course) OpenSolaris. All of these have more of a focus on stability than linux currently does. I wish this weren't true but many companies have been burned by linux's lack of attention to API stability. sayonara kharma!

Hire An Expert (2, Interesting)

Some guy named Chris (9720) | more than 8 years ago | (#14738271)

I'm guessing nobody in your organization has ever developed an embedded app, or you would have industry contacts, real world experience, and better things to do than post this to "Ask Slashdot".

Re:Hire An Expert (3, Informative)

bsd4me (759597) | more than 8 years ago | (#14738620)

There is a lot of truth to this. A few years ago, I joined a project team after development had been underway for a while. Most of the people had no embedded experience, and I had to spend a lot of time redoing things that would have been OK on a general purpose system, but were nightmares under an RTOS. There a lot of programming fields where speciality and experience matter, and embedded systems is one of them.

Re:Hire An Expert (1)

Bing Tsher E (943915) | more than 8 years ago | (#14752706)

Most of the people had no embedded experience, and I had to spend a lot of time redoing things that would have been OK on a general purpose system, but were nightmares under an RTOS.

You just described why Linux can never suffice as an embedded RTOS. Too many 'general purpose' fingers in the code. I have seen this in the past as well.

Re:Hire An Expert (1)

vivekb (111127) | more than 8 years ago | (#14738647)

That guess is highly accurate. I'm the only software engineer here, and all of the embedded work I've done in the past has been on OS-less targets. This time around, that simply isn't an option due to time constraints and peripheral connectivity issues. The only truly embedded OS I've personally used before is QNX. QNX is great, but way too expensive. In fact, VxWorks and pretty much all of the usual suspects just cost too much, and are overkill for what we need.

Based on cost, board support and driver availability, GUI development options, use in similar applications and V&V documentation, Linux is turning out to be the best choice.

All of my friends who've worked on embedded systems have done so in larger companies -- companies that can afford to staff people to sustain a Linux distribution. Here, "sustaining" can't mean hiring somebody to write and apply kernel patches. We're small now, and will continue to be small (on the software side) for years. "Sustaining" to us means finding a vendor that will provide adequate support for a frozen version of their OS for the next five years.

And that's my worry with Linux. Releases come often, and the vendor I'm looking at most closely has a "Current version plus the previous two" policy. If they release aggressively, that could mean our platform is obsolete in three years. Yes, we'll still have source code, but we'll have to hire somebody to maintain it.

As far as I can tell, there are no experts. There are only people who sell both consulting services and operating systems, and they quickly suggest hiring them to do all sorts of sustaining work. Other people that I've talked to chose an OS because of some specific make-or-break reason, and never revisited the choice.

I guess the ultimate question I have for the Slashdot universe is, "How long do you think an embedded Linux provider is going to stay in business and continue selling Linux-based services?"

I know the answer will probably be, "Forever because Linux is teh sexy", but I'm hoping that some grizzled veteran will tell me a war story about the true cost of software maintenance -- for any of the big embedded OS's.

Re:Hire An Expert (2, Informative)

AgentCooper (167258) | more than 8 years ago | (#14739001)

I'm a developer on the Windows CE team at Microsoft.

Microsoft offers a minimum of 5 years support for Windows CE. Beyond that you can get up to 5 more years support (at additional cost). Click here [] to read more about how we support Windows CE.

We're active on the newsgroups as well, as are many of the more experience developers who've used CE in their products.

I'm not familiar with ETX hardware, but we have excellent support for x86-based CPUs and the usual peripherals. You can even add device drivers to your build by dragging and dropping them from the catalog in our IDE. You can download our tools and most of the source code (even the kernel) here [] . It's a free 4-month trial, so please check it out.

Good luck with your project!

Re:Hire An Expert (1)

solid_liq (720160) | more than 8 years ago | (#14740102)

So in other words this is a highly biased suggestion, by a person whom may not even have any experience with any of the more tried-and-true embedded OS choices? The very fact that you can download most of the tools means you have a very limited number of tools available. What about JTAG? Do you offer an ICE?

You're asking him to spend time checking out an OS put out by a company with very limited experience wrt developing embedded OS's. Remember, "Time is the most valuable thing a man can spend. -- Theophrastus."

I would suggest looking at products from vxWorks if you wish to look at options available from a company which actually has quite a lot of experience with developing and distributing embedded OS's. Their products are found in a great many embedded systems.

Re:Hire An Expert (1)

AgentCooper (167258) | more than 8 years ago | (#14746544)

OK, I'll bite.

Very limited experience with developing an RTOS? CE has been in the field for 10 years.

No experience with the other options? Do you think Microsoft hires people who are ignorant of their own field? Speaking only for myself, I was a firmware developer in the cellular industry prior to coming here, and have a long background in Unix and non-MS embedded systems. Many of us do.

Tools download - actually the tools are substantial. I'd order the DVD or set of CDs, but I know some folks would rather download over night than pay the $6 S&H.


Re:Hire An Expert (1)

PeteABastard (542565) | more than 8 years ago | (#14739218)

You seem to think you need a vendor for Linux. Its possible, but its also possible that the sort of support you need is actually from the community around the embedded Linux distro. I've worked on a product using uClinux, which we chose for its support for the Coldfire processor and its networking. The core developers of uClinux use it for their companys firewall and router products. The community around it oferred enough support so I could write drivers to interface a few bits of unique hardware.

That was in kernel 2.4 days, many people on the list were still using 2.2 and the groundwork to get into the 2.6 kernel was being done. My point is external kernel changes dont necessarily have to make a difference to you. Embedded product tend to remain relatively static once finished, if a problem crops up four years down the track, you probably want to find someone who had a good understanding of the code back then. For example someone who hacked on the code at the time. Your likely to find that person in the community around that emmbeded Linux
distro, and they may or may not be a vendor.


Re:Hire An Expert (1)

Lehk228 (705449) | more than 8 years ago | (#14739287)

Have you looked at inferno?

Device Drivers (3, Insightful)

bsd4me (759597) | more than 8 years ago | (#14738279)

I would pick the OS based on whichever has the best device driver support for everything in your product. Device driver development can chew up a lot of time. You would be better off spending resource time on the application layer of the product.

Source code (3, Insightful)

sunderland56 (621843) | more than 8 years ago | (#14738309)

If you really want it to be sustainable, use something where you have access to the source code. Even if you don't want to modify the sources, just having access can help you track down obscure bugs.

So of the two you've listed, clearly Linux would be your choice. Plus, don't forget that Microsoft's embedded OSes reinvent themselves every few years - just wait until they throw out CE and sell you Vista Embedded next year.

There are other choices based on the size/scale of your project - such as Nucleus, which gives you source access.

Re:Source code (1)

TERdON (862570) | more than 8 years ago | (#14738339)

Uhm, that would be ALL of the source code in this case. Actually Microsoft is making at least parts of it available to OEMs after buying Platform Builder. Under NDAs, of course.

Re:Source code (1)

AgentCooper (167258) | more than 8 years ago | (#14738916)

Unfortunately there's a lot of misunderstanding around this. IANAL, but I am a Windows CE developer at Microsoft.

The majority of the Windows CE source code is available (2.5+ million lines). It's free and there are no restrictions. Code includes:

  Explorer Shell

  HTTP Web Server

  SOAP and uPNP Protocol Implementations

  UPnP AV toolkit

  Infrared Data Association protocol

  Dynamic Host Configuration Protocol V6 Lite (DHCPV6)

  Wireless Network Drivers, including Bluetooth

  Kernel code

  File System

  Storage Code

  C run-time (CRT)

  Binary Rom Image file system

  Windows Sockets Interface (WinSock)

  Point to Point Protocol (PPP)

You just click a checkbox when installing the developer tools (which have a 4-month free trial).

The "NDA" is basically this (taken from our website): "In exchange for obtaining access to one of Microsoft's most valuable assets, Microsoft requests that customers respect our intellectual property and treat that intellectual property confidentially."

I.E., you don't publish the code - but anyone who wants to can download the source from us after accepting the EULA. The converse is that any changes YOU make to the code are yours. You needn't share them with anyone, including Microsoft (unlike the GPL but similar to BSD).

Here's an overview [] of the shared source license.

Here's more detail at, including a link to the full license []

NOTE: there is also the "Premium" shared source license. This gets you even more code, but is only available to larger OEMs (I believe you have to ship 5,000 devices in the previous year to qualify).

Windows CE Source Code (1)

everphilski (877346) | more than 8 years ago | (#14738341) censing/WindowsCE.mspx []

Free. Kinda levels the playing field.

Re:Windows CE Source Code (1)

mikiN (75494) | more than 8 years ago | (#14744978)

Short answers are not the whole story.

Half-truths are sometimes worse than the whole truth.

True: Shared source code is free, apparently without restrictions.
Also true: You need to buy a runtime license for each and every device that you ship.[1]

[1]: From the webpage you link to:
"A valid Windows CE 5.0 runtime license must be purchased for each Windows CE 5.0 derivative work prior to distribution.".

From link to "How to Buy Windows Embedded Operating Systems" [] on the same page:
"Step 4
Acquire runtime licenses for commercial shipment.
When you have completed testing and development and you are ready to bring your embedded system to market, you must acquire runtime licenses and certificates of authenticity from your distributor for each unit that you ship." ...

Re:Windows CE Source Code (1)

everphilski (877346) | more than 8 years ago | (#14747448)

No shit. It is Microsoft Windows. Every copy must be properly licensed. The question was about source. The asker assertained that the source was closed to all eyes. This is not the case.

Re:Source code (1)

AaronLawrence (600990) | more than 8 years ago | (#14741060)

Your comment about source code is very true, and highly relevant to sustainability. However;

Microsoft have been selling CE for some time now and show no sign of throwing it out. Embedded NT/2000/XP have been parallel offerings for those who are willing to have a much bigger system - only marginally "embedded", really just a customised desktop build.

They do release new versions of CE and mostly forget about the old one, but the new ones are pretty much straight supersets of the old, with quibbles. Since with their platform builder you have lots of the source and the ability to keep on customising things yourself, it's not so hard.

Nucleus from Mentor Graphics (1, Informative)

Anonymous Coward | more than 8 years ago | (#14738323)

Why limit yourself to Microsoft and *nix? There are literally more than 100 operating systems that will run on "standard" PC hardware.

What you need to do is list out the features you want from an OS. Once you have that, a quick visit to the web sites of various OS vendors should help you quickly narrow your list down to a dozen or so. When I had to make this decision, I found the vendors were happy to send me API documentation, programming manuals, and in some cases, an evaluation copy of the OS itself.

I ended up choosing Nucleus from Mentor Graphics. I bought the components I needed and nothing else. I don't pay per unit royalties, it has worked for years without needing to be upgraded, and I have the FULL source code so I can be confident that everything works just like I think it does.

Re:Nucleus from Mentor Graphics (1, Interesting)

Anonymous Coward | more than 8 years ago | (#14738657)

As the last AC said it. List your needs (include your boss' needs too - as secondary to begin with ;-P ). Then search for an embeddable OSes that most closely meets your needs. After the list has narrowed down to four or five OSes, apply your boss' needs to limit the list to two or three AT MOST.

You really can't go wrong with Linux, but that can not be said for all other OSes, though some come close.

You can always fall back to the most used OS in the world ... CP/M! It is the Mother and Father of Microsofts OSes after all. Yeah, its OLD and but there are versions that can do a lot more than what most people would believe.

QNX, RTOS, PDOS, BOSS, etc. all have their strong points as well. So go out there and have fun searching for the OS that's best for your project!

Re:Nucleus from Mentor Graphics (1)

pchan- (118053) | more than 8 years ago | (#14739586)

Nucleus is really more of a fancy scheduler than an OS. Don't get me wrong, it's very good at what it does, but it won't give you things like, oh, drivers, memory protection, separate processes (all threads run at the same level as Nucleus and share memory with it). For people looking at Linux and CE, that's a bit bare.
BTW, Nucleus Plus (scheduler) may be very good, but Nucleus File (their FAT filesystem extension), is pretty fucking bad. It is slow, buggy, and extremely lacking (silly things like assuming filenames are all ASCII).

Linux (1)

gadzook33 (740455) | more than 8 years ago | (#14738349)

I recommend you go with Linux over CE. I've had experience embedding both and I don't think there's much of a comparison. Linux may take more work in some cases but ultimately you can be assured it will do what you want. CE shifts with the Microsoft winds and there's no guarantee your hardware will be supported down the road. Now, that being said, if you're developing a PDA or other graphical device where user experience weighs in over flexibility of hardware, you may want to seriously consider CE. However, for 95% of embedded apps (higher?), I would go with Linux. If the linux community were to stop addressing the great variety of embedded devices that it currently does, there's more likely a bigger problem to deal with (armageddon, global extinction event, etc).

Linux (1)

AuMatar (183847) | more than 8 years ago | (#14738409)

If your main concern is support, then Linux. Linux never reaches end of life- even if red hat decides to stop support for a specific version, 3rd party vendors can still do it.

Now if you need hard realtime capabilities, neither. Use QNX, VxWorks, or ThreadX. Just be prepared to pay. And pay. And pay.

Re:Linux (1)

mmkkbb (816035) | more than 8 years ago | (#14738605)

There's a pretty nice RTOS called uCos-II from Micrium that's not as ridiculously expensive. No per-seat licenses, but you may need to purchase the book. The license fee is per product line.

Re:Linux (1)

yope (656090) | more than 8 years ago | (#14741464)

Now if you need hard realtime capabilities, neither.
Why not? Ever heared of Xenomai [] ? With Xenomai (formerly kown as RTAI-fusion) you can write user-space apps in Linux that can switch hard real-time mode on or off seamlessly. You can basically forget about VxWorks, QNX and other hard-RTOS's, since Xenomai has API "skins", that can be used to run software written for your favorite RTOS directly on Linux; just as reliable and predictable, with truely deterministic real-time behaviour. If your favorite RTOS doesn't have a Xenomai "skin" yet, write one, and switch to Linux!

QNX (1)

eric76 (679787) | more than 8 years ago | (#14738428)

How about QNX?

I have no idea what the prices are, but it is reportedly the most superstable embedded platform available.

If I were building embedded devices for critical medical applications, I suspect QNX would be my only choice.

For less critical applications, I'd still keep it in mind.

Re:QNX (1)

Animats (122034) | more than 8 years ago | (#14738547)

I am a huge QNX fan. We used QNX for our DARPA Grand Challenge vehicle [] , and were very satisfied with it. It's perhaps the most elegant operating system on the market, it's solidly reliable, and it's usable for embedded systems from microwave-oven size to Cisco megarouter size. It's a true microkernel, with less bloat in the kernel than almost anything else out there.

But, sadly, I wouldn't recommend QNX for a new startup that doesn't absolutely need hard real time. Since QNX was acquired by Harmon (the parent of JBL, Harmon-Kardon, and various other audio companies), the company hasn't been working at keeping small customers happy. The lead architect of QNX died about two years ago, and there's been a brainpower exodus since then. The last third party books about QNX have gone out of print. The free version of QNX has been discontinued, and so the open source community is doing few, if any, QNX ports.

It's a great technology. But the marketing and support end of the company is focusing on major automotive suppliers. If you're not in that space (or you compete with any of Harmon's business units) you're probably not going to be happy.

Re:QNX (1)

grub (11606) | more than 8 years ago | (#14739124)

The lead architect of QNX died about two years ago, and there's been a brainpower exodus since then.

If you're talking about Dan Hildebrand, it was more than two years. I'm pretty sure it was 1998. He was the man that first got me onto *nixish systems when he installed a 'demo' version of QNX on my old 286 (AT) way back in the day when he still lived here (Winnipeg).

Re:QNX (1)

grub (11606) | more than 8 years ago | (#14739146)

Yeah, it was 1998. Here's his page at mentioning his death. [] I remember finding it out on IRC when I saw someone from on one of the channels. I asked about how H was and he said he died a few days before.

Dang that was a sad day.

Re:QNX (0)

Anonymous Coward | more than 8 years ago | (#14739795)

If I were building embedded devices for critical medical applications, I suspect QNX would be my only choice.

Really? tml []

Re:QNX (0)

Anonymous Coward | more than 8 years ago | (#14742571)

Funny, I work for a medical device company and we just recently (as in a year or two ago) ditched QNX in favor of VxWorks.

I think limiting yourself to only one choice is a bad idea. You have to look at all aspects including (but not limited to):

Development cost (do you need new expertise)?

Support infrastructure (does the company have one or is it 3rd party)

Royalties (are there any?)

Cost (do they have proprietary development tools that cost a fortune?)

Flexibility (do you get the source?)

And a track record of other projects using the o.s. wouldn't hurt either.

Again, how you answer these and what those answers really mean for you will differ between companies..but you should still look at those items. We did and our outcome was to switch to VxWorks.

I've done both professionally (1)

WouldIPutMYRealNameO (874377) | more than 8 years ago | (#14738455)

for the last 5 years or so. Unless CE offers you some turn key solutions that are really appealing and not found on Linux, then embedded Linux is for sure the way to go.
Simply speaking, you will get no support from Microsoft without dumping bucket loads of cash & if it isn't the latest release of the OS then you have no hope at all. The MS newsgroups are many times poorer for support than Linux mailing lists.
At least with Linux you can hire someone to work on old code, because you have the code!

MS only cares about the big players (iPaq, Dell) and now they are moving into the phone market as well. Don't expect to get more than the time it takes them to sell you a license. Developing with WinCE is an extremely daunting task if you haven't done it before. So is Linux, the difference is
1) Amount of online support from newsgroups, etc
2) Actually being able to see the code that runs Linux. 9 times out of 10 it doesn't matter, but that 1 time out of ten really makes you want to put pins in your eyes.

Do I sound bitter that my current job is exclusively WinCE?????

Re:I've done both professionally (0)

Anonymous Coward | more than 8 years ago | (#14738739)

I also have done both professionally.

By far, WindowsCE has been the worse experience of the two.
Everything you have said, and then some.

However, I would pick neither, if other options
were acceptable to my customers (RTEMS, uC/OS-II, even
Nucleus). Haven't tried eCos.

Figure out your requirements first (4, Insightful)

ifdef (450739) | more than 8 years ago | (#14738468)

I've worked on products that had no OS at all, just a loop that called various functions in sequence. I've worked on products where the company wrote the realtime OS from scratch. I've worked on products where the company used a commercial OS, but bought a source code licence. I've worked on products which used an off-the-shelf Microsoft OS. It all depends on your requirements.

Are there realtime requirements? Do you know what hardware will be used, or will you need to support different kinds of displays, for example? What are the reliability requirements -- will this be used in life-critical applications, or will it be used for games? Will you want to upgrade to the latest version of the OS from time to time, or will you pick a good one and make zillions of copies of your product based on that one version? I'm sure there are other questions you should be asking yourself (help me, fellow Slashdotters).

Figure out your requirements first, then figure out how to meet those requirements. Don't just pick a solution and then try to make it fit.

QNX or one of the BSD's? (2, Informative)

hot soldering iron (800102) | more than 8 years ago | (#14738588)

QNX is a long running Posix-compliant real-time OS, complete with embedded developement tools. But if you need to keep the sourcecode "tight to your chest" the *BSD license allows that, i.e. it's free to you, but you don't have to give out your changes if you don't want to.

What is sustainability? (0, Flamebait)

mnmn (145599) | more than 8 years ago | (#14738637)

I dont get your question.

Linux for example will run for a long time while support for it (as in knowledgeable people) will remain available. I think 20 years later people will still be easily capable of fixing kernel 2.6 issues. How many people do you know know how to fix issues with windows 3.1?

If you want the OS to change very little over time, BSDs are better at that. Expect OpenBSD to be around and to change little in 20-30 years. It'll change enough to accommodate the new hardware etc but thats it. How much has BSD changed in the past 25 years? Use NetBSD for embedded hardware.

But I still dont get what you meant by sustainability. The OS sustaining the hardware? The company supporting its OS? Community support?

Re:What is sustainability? (0)

Anonymous Coward | more than 8 years ago | (#14738769)

Do you realise how much of an ass you read-like? I assume you don't, but you look stupid enough that I should make sure you do. OpenBSD's releases often have major changes to fundamental sections of the system, just this last release the changes to malloc were huge, W^X was huge, switching to pf from ipf was huge.

Just because the changes that OpenBSD does are more structured and less erratic than the development of the Linux kernel does not mean it's standing still.

The releases for OpenBSD are noticably different each time, that you don't know this means you shouldn't be talking about it.

And let's not get started in the beating you over your idiotic BSD statement, since BSD stopped development a long time ago.

Re:What is sustainability? (1)

mikiN (75494) | more than 8 years ago | (#14745136)

If you are looking for a support company for embedded NetBSD, check out Wasabi Systems [] . If I'm not mistaken, several port maintainers either work for Wasabi or are in frequent contact with them.

How about DOS? (3, Interesting)

Ritchie70 (860516) | more than 8 years ago | (#14739042)

Semi-serious, semi-not. DOS runs a lot of embedded systems, because it gives some really basic hardware support (file systems and booting, really) but still lets you get direct to the hardware. My employer has somewhere around 65,000 MS-DOS systems in the field.

Re:How about DOS? (2, Funny)

flibbajobber (949499) | more than 8 years ago | (#14740015)

Could've had over 4 billion if your employer had picked a 32-bit OS...

closed vs. open comparison (1)

MaskedKumquat (522312) | more than 8 years ago | (#14739642)

Microsoft moves their "A" team to the latest version of their OS. In your example, you will be left with "B" (or "C") team support resources. I worked on a CE device from 2.1 through 4.0beta; there is no realistic option but to move forward in lockstep with MS.

With Linux, you can still find support for the 2.4 kernel, and products are still moving to 2.6. Transitions can be managed at your pace; you can have all of your platform's source code in revision control, building everything from scratch indefinitely. I've worked on numerous embedded Linux platforms, and - speaking from an investment perspective - there is no other system that I would recommend for modern, complex embedded systems.

That doesn't mean you will spend less on the technology, but I believe these added costs indirectly translate in massive savings in other areas. I have encountered few things as frustrating as my experiences paying to have Microsoft debug their products; one such incident caused a major update of our product to be delayed by five months. I have no idea what that cost my employer (outside of my salary), but I do know it was non-zero and my life was miserable waiting for their fix.

This anecdote should reveal perhaps what I believe is the most significant positive impact on the development process: your engineers will enjoy a better quality of life by having complete control of the software system. Releases can be produced on your scheduled, and the component design of the Linux kernel and GNU operating system packages makes upgrading an iterative and incremental process. The Microsoft alternative provides no such flexibility; bringing up the next version of Microsoft's OS is an all or nothing task, as you can't (sanely) mix and match components between their major upgrades.

Moreover, the GPL license ensures you are free of vendor lock-in. There are already individuals and businesses that are willing to upgrade, fix, or replace the myriad of open systems. This marketplace should only continue to grow more competitive, barring government interventionism that erodes the legal power of free and open licenses. By contrast, no such open marketplace can (legally) exist for closed source platforms, so the cost of third-party support for such platforms often becomes prohibitive in a very short time.

Finally, I would bet that the bulk of your product's value will derive from your own custom applications running on your platform. For those assests that fall outside of your core business focus, you can leverage the community process to increase the rate of development, incorporating new features and fixes developed by your users and hackers (if your device is affordable). There are now numerous examples where this later crowd can provide definitive returns, even when they are not intentionally solicited (nslu2, wrt54g, tivo, psp, etc.). You will be far better off planning to work with hackers instead of spending time and money trying to keep them off of your platform; if you are careful, you can even plan to profit from their efforts.

Micrium uC/OS, it's free (1)

BarnabyWilde (948425) | more than 8 years ago | (#14739907)

Re:Micrium uC/OS, it's free (1)

slickwillie (34689) | more than 8 years ago | (#14740371)

We tried that. We got tired of saying "mu-COS" dozens of times per day.

Re:Micrium uC/OS, it's free (1)

orbitor (166566) | more than 8 years ago | (#14742551)

Incorrect. uC/OS II is not free. Did you even look at the site you posted?

Re:Micrium uC/OS, it's free (0)

Anonymous Coward | more than 8 years ago | (#14742556)

Check again, It's not free for comercial products.

Re:Micrium uC/OS, it's free (1)

Bing Tsher E (943915) | more than 8 years ago | (#14752773)

I tried to go to that site.

It presented me with a page with a big blank white screen and nothing on the screen.

I am browsing from a NetBSD machine using a current version of Mozilla.

I have to assume that the web page is supposed to load some sort of Flash animation and/or proprietary mess that I don't have a 'helper' installed to make work.

They expect to IMPRESS people with a home page like that? They think they will get CUSTOMERS that way? Without even providing a 'bail out of the bullshit and take me to the content' link?

WinCE (1)

AaronLawrence (600990) | more than 8 years ago | (#14741044)

Since you're not likely to see many favourable comments about Windows CE on here, I'll chuck in some.

Windows CE is actually fairly cheap now if you go for the basic version - that is kernal-level only, no GUI or desktop - only about $3 per unit. Sure in cost sensitive cases that could still be an issue but for most specialist apps it's not significant.

You do have to buy Platform Builder for around US$700, but that's one off. And you can get a free 30-day eval to see if you like it.

WinCE is basically really good for one particular thing: existing Windows developers. The Win32 API is there, .NET in "compact" form, the tools are similar or the same, and with a little bit of effort you can have code that works on both desktop and CE.

Especially if you have existing code that works on Windows, and uses Win32 to some extent - things like COM - then WinCE is going to be a lot easier to port too.

You also get a few apps that Microsoft support - such as SQLServer CE (really just a one-thread engine, nothing like the full thing) and if you go for the fuller version, PocketOffice and a desktop. Those may be entirely useless, or not.

On the downside however, you may be making compromises for that convenience.

Who knows when Microsoft will raise the cost? I can't believe they make any money at $3 per license, so I half-expect them to raise it back to former levels around $15-20 IIRC in a few years. Or else just stop making it at that basic level.

You're still stuck on Windows. You can see it instead as an opportunity to go multi-platform, and open yourself up to Linux, OSX and whatever else.

There are some limitations of WinCE compared to other embedded operating systems. They haven't been realtime for very long, although it's been getting better. They *require* Unicode for the API - no more codepages and ASCII (except for the C runtime).

You don't get all the code. If you want to really get into the nitty gritty of tuning the OS this will likely be a deal breaker. It also means you won't have the option of supporting it if later MS stop supporting it. That said, embedded hardware tends to stay the same for a long time and you do get quite a lot of CE source these days.

That's some of the things that have gone through my head. We are using WinCE for now, because we have a desktop Win32 app and at the price Linux isn't compelling.

Rules to consider (1)

geohump (782273) | more than 8 years ago | (#14741402)

#1 - All OS platforms suffer from Kernel upgrade syndrome, so make sure you have the complete source code to your kernel.

#2 - Over time licensing costs will add more to the price of your product then you think. Get a flat fee license arrangement so that your license cost is fixed for the life of the product. Or use a no-license fee needed platform

#3 - Note that the Linux Kernel development path is maturing and slowing down. 2.6 is very featureful and will be an ok place to be for a long time.

#4 - Security, If your device can be owned by a remotely delivered virus you will have huge support problems. Consider this when designing in connectivity for the device.

#5 - Real-time response requirements. There are very few real reasons to have a real time OS in a consumer appliance, but - if your application needs it then it really needs it. You must make sure that your platform is truly a real time OS. Don't get confused by "near real time" capabilities of some platforms. A true real time OS will respond to an interrupt within a specific, finite, (and small) time period everytime. If it can't, its not a real time OS.

Not a problem which should be solved (2, Insightful)

dslamguy (644218) | more than 8 years ago | (#14742285)

I have been developing embedded systems for over 20 years and I have never seen the need to upgrade the OS. Never! The beauty of an embedded system is that the user does not see the OS and really does not (or should not) care what it is. You are going through a development cycle and if you do your job well, you will be fixing most problems during the development cycle before the first release and immediately after. Over the years, you will be in a maintenance mode and you will only be fixing some functionality problems.

You will NEVER want to destabilize your product and have significant retesting by upgrading the Kernel or OS. Why? What new features in the OS matter to your customers? After all the OS is not your product and the customer should not care. Keep in mind that the OS vendors will be trying to get you to distribute upgrades, but resist the temptation. You will be spending money for no reason.

When you need to develop phase II of the product, its a different ball-game. Then you can use a new version of the OS, or a different OS. The point is, you are not "upgrading" your kernel, you are developing an evolution of your product on a new OS. Different mindset.


StCredZero (169093) | more than 8 years ago | (#14742709)

One of the rare occasions where real insight from significant experience appears in Slashdot!


J.R. Random (801334) | more than 8 years ago | (#14743993)

Yet the folks with mod points did not follow your advice. They modded up your post, not the parent.

Re:Not a problem which should be solved (2, Insightful)

Bing Tsher E (943915) | more than 8 years ago | (#14752760)

It depends a LOT on what said embedded application is intended for.

If your embedded OS goes into a home appliance or some stand-alone application, your experience holds fast. If the application is net connected and world-visible, i.e. the controller in an internet-enabled vending machine, then your experience and opinion is lacking. It is NOT acceptable to 'screw down the lid and forget' about a net connected app, especially if a widely-used OS is embedded. Exploits WILL surface, and maintenance of the system to protect against said expoits WILL be necessary.

eCos (1)

orbitor (166566) | more than 8 years ago | (#14742611)

If you are running on comodity x86 hardware, look into eCos. You can go open source of commercial (with someone like [] eCosCentric). Full source code. Lots of drivers. Easy to understand API. I have worked with nearly 2 dozen RTOS's, and this one is one of my favorites.

I also strongly agree that you never, ever consider kernel upgrades to a shipping product (any more that you would replace the CPU or whatever in the hardware design). What you really need to think about is how to carry expertise from project to project. One solution is to stick with the same set of tools to create the product.

NetBSD (1)

hubertf (124995) | more than 8 years ago | (#14761182)

I've based my own harddisk image cloning software (g4u [] ) on NetBSD, and I didn't regret it so far. I've started with NetBSD 1.4 some 5 years ago, and I'm still very happy with it. Latest versions of g4u are based on NetBSD-current for getting support for new hardware earlier, but that may not be required for your type of application.

In general, I can only recommend NetBSD, as it not only comes as a rock solid operating system in itself, but as it supports many different platforms and crosscompiling of kernel, userland and (if needed) X11, so migrating to a different hardware platform is not a problem or a showstopper long-term.

Check it out! []

- Hubert

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>