Linux Now Top Choice Of Embedded Developers
An anonymous reader writes "According to an article at LinuxDevices.com, the latest market research data from Venture Development Corp. shows that Linux is now firmly in first place as the OS of choice for smart gadgets and embedded systems. VDC's latest data indicates that Linux now accounts for 15.5% of embedded projects, beating out Microsoft's WinCE (6%) and XPe (5%), and Wind River's VxWorks (10.3%)."
Linux success is almost always measured in the desktop and/or server markets, and very rarely in the embedded market. It's refreshing to see an article showing the strength on Linux in a market that has a lot of potential but little of the glamour.
Putting an OS on a small device is a task that tends to require a lot of tweaking... when you're making it small, you tend to make a lot of compromises, and small devices tend to be much more diverse than personal computers and servers (well, duh).
...Or the one written and managed by a single company who, yes, has talented developers, but none of whom are on-site working with you?
So -- what OS is better suited to this kind of application? The open source one with plenty of developers out there, tweaking it as we speak, where the developers of your hardware can be shaping the embedded OS as they build the prototype?
Not that I'm the only one saying this, of course, but this is a great chance for the Linux model to shine.
There are as yet unresolved issues with the use of binary software with GPL software in general and linux specifically, despite linus' assurances that userspace code doesn't require GPL license compatibility and that he won't enforce that section of the GPL. Linus is using the GPL license as written by the FSF, albeit fixed to V.2 and with some specific modifications. They (linus and the FSF) disagree on on the details of whether or not using GPL-licensed header files forces the software using them to be be under a GPL-compatible license. Even linus admits there are grey areas and his interpretation has been debated. Until this matter is resolved definitively (probably in court), I don't want to place my company at risk of being forced to release code that we do not want to release, simply because we compiled our software for linux.
What we found, is that the GPL, LGPL and other FSF licenses are very problematic when dealing with the control of code(proprietry or otherwise). The GPL licensing terms are very strict and dangerous in terms of source code-ownership vs binary code-distribution and legal obligations.
The FSF cannot of course, enforce the GPL for software they don't own the copyright for. However, the licensing conditions and restrictions of the GPL automatically come into effect without much influence from the actual copyright holders. We're left to the whims of copyright owners and their good word to decide what is considered a breach and what is 'tolerated'. As we see more GPL software being used by companies with proprietry code, I think we'll see a nasty side of the GPL rear its head as enforcement starts to kick in from different areas. Boundaries of legality are constantly tested, when they are wide and filled with grey.
Just because you don't get charged with doing something illegally as you do it, that doesn't mean that you can't get prosecuted afterwards, if someone feels like going after you.
click-clack, front and back. I'm not moving this car otherwise.
...it is by invisible hand of the market. Development costs for embedded on Linux are lower, no matter what FUD about GPL are Microsoft vassals posting on Slashdot. Because embedded incarnations of Linux are very consistent with desktop ones.
.net stuff) for PocketPC using WinCE emulator in Windows XP. With a real pain, because running emulator took 98% of desktop CPU doing nothing. It was worth a new computer, two months of her work and many grey hairs to complete the task.
An example from real life:
My girlfriend wrote some custom app (database client frontend +some
I replicated her effort on the identical hardware (HP iPaq, but with Linux flashed in) in three days. The trick I used was a http server running inside iPaq (sic!), calling local python scripts to query remote database and generate html content to local browser.
Guess, from these two implementations, which one is easier and/or cheaper to support?
Can you, Microsoft drones, stuff IIS or any existing COM/DCOM components you already payed for on Win32 into some WinCE device?
There you are, staring at me again.