Slashdot Mirror
Choosing an Embedded OS for Sustainability?
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?"
You are asking the Slashdot Fanboys to tell you what to choose between Linux and Windows CE? Are you for real?
I found VM/370 is the ideal. Rock solid and free to boot. Highly recommended.
The Mac Mini has nice embedded OS. :P
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?"
Tsume
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.
In Soviet Russia, Trojan exploits YOU!
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".
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.
(S(SKK)(SKK))(S(SKK)(SKK))
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.
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.
http://www.microsoft.com/resources/sharedsource/Li censing/WindowsCE.mspx
Free. Kinda levels the playing field.
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).
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.
I still have more fans than freaks. WTF is wrong with you people?
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.
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?????
Damnit - I wanted my nick to be "WouldIPutMYRealNameOnSlashdot"
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 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.
When you want something built, come see me. If you want correct grammar and spelling, get a F*ing liberal arts student.
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?
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
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.
The preferred solution is to not have a problem.
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.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
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.
www.micrium.com
Since you're not likely to see many favourable comments about Windows CE on here, I'll chuck in some.
.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.
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,
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.
For every expert, there is an equal and opposite expert. - Arthur C. Clarke
#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.
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.
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.
One of the rare occasions where real insight from significant experience appears in Slashdot!
I would start with embedded.com at http://www.embedded.com/showArticle.jhtml?articleI D=163700590
Some BSD variants and uCos weren't included, but it's still a great survey of the embedded OS space.
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