ESC West: EE-Times Survey shows interest in Embedded Linux remains low.

Check out this Survey published today at ESC West. The survey was published by Dylan McGrath from EE Times

SAN FRANCISCO Only 17 percent of embedded systems designers are currently using embedded Linux, and 66 percent say they are either not interested in using it or do not expect to be using it anytime soon, according to the results of a survey released here Monday (April 3) at the Embedded Systems Conference Silicon Valley.

The “2006 Embedded Systems Design State of Embedded Survey,” conducted by EE Times and sister publication Embedded Systems Design, found that 34 percent of respondents were not interested in using Linux. Thirty-two percent of respondents indicated that they were interested in Linux but not likely to likely to use it soon and 17 percent said they were likely to use it soon.

By contrast, 24 percent of respondents to the 2005 version of the survey indicated that they were currently using embedded Linux.

Seventy one percent of those considering using embedded Linux indicated that low cost was among the reasons for considering it, up two percent from 2005. Sixty one percent indicated that adaptability/extendibility was among the reasons for considering Linux, up from 58 percent in 2005.

Among those not considering using embedded Linux, 60 percent said it was due in part to the incompatibility of Linux with software, applications and drivers, up from 51 percent in 2005. Thirty one percent of those not considering Linux cited performance or real-time capability among the reasons, and 28 percent cited support.

Respondents labeled real-time performance as the most important factor for selecting an operating system, with 54 percent indicating that it was one of the biggest factors.

The results of the survey, conducted through email solicitation from subscribers to EE Times, Embedded Systems Design and Embedded Systems Design Europe, as well.

I wonder what the results would be when considering Windows Embedded (Windows CE, Windows XP Embedded, WEPOS). Hard real-time (Windows CE – or Windows XP Embedded with Real-Time extensions) [check], application and driver compat [check], time to market [check], access to source code (Windows CE) [check]…

After all Windows CE is a hard real time small footprint (image sizes start from 200kb) embedded operating system that’s suitable for both headless and headed devices, ships with source, supports very well known programming tools/languages (Win32, MFC, ATL, C#/VB, Compact Framework).

Windows XP Embedded is a componentized version of Windows XP SP2 which as we all know supports a TON of hardware devices and has excellent application compatibility – typical Windows XP Embedded designs go from concept to shipping in 12-14 weeks!

And WEPOS – provides plug and play support for the Point of Service (Airport Check in Terminals etc…) and Point of Service (check out terminals in stores etc…). This means that you, the developer focus on the glue of the application, not on integrating the hardware into your embedded system – and at the point of use the device lifetime can be extended through plug and play of peripherals that match the same specification but perhaps not the same model or manufaturer – it’s a win-win situation!

Hey, don’t take my word for it – go check out some of the Windows Embedded Case Studies – and if you’re building devices based on Windows CE, Windows XP Embedded or WEPOS and would like to write a case study then let me know !

– Mike

Comments (11)

  1. Chakravarthy says:

    Is there any way to get the full data about the survey?

    The mentioned figures are alarming Embedded linux, but are there any interest towards WEPOS from the same crowd of participants?

    Hope this is a clear indication towards the technology switch to Windows Embedded.

  2. mikehall says:

    I have as much information as you do from the survey – If only 16% of embedded developers are considering Linux I’d certainly be interested in knowing whether everyone else is considering Windows Embedded.

    – Mike

  3. kqiman says:

    Yet another stupid survey …

    First linux cannot be compared to winCE nor winXp embedded, the vanilla kernel is just not a real time kernel, if you still want to compare it, then compare it to winXP or something like that, can we put a winXP on a phone ? no, can we make it small ? no, but those things can be done with linux. RTLinux, can be used for real time processing, and can in some way be compared to winCE or winXp embedded, still it’s a hack using Linux Security components, i’d compare WinCE to Vxworks, QNX or eCos. Concerning winCE, i personally find it unusable compared to other OSes, it got no posix compatibility, no win32 compatibility, and a 32 process limitation …  i’d go for vxworks or eCos if i were to use an RTOS.

    So please stop comparing linux to winCE, it’s as stupid as comparing tomatoes to potatoes.

  4. mikehall says:

    so, the fact that Microsoft has a family of operating systems would appear to be a good thing, if you want small footprint, native hard real-time and Win32/MFC/Managed API’s then you would use Windows CE, if you want full app compat and driver compat (with the desktop) then you would use Windows XP Embedded – if you want a combination of full desktop driver support, application compat, and real-time then you could use Windows XP Embedded with real-time extensions. Sounds reasonable to me.

    The survey points to Linux not being natively real-time, and you’ve pointed out that real-time linux is a hack (which is also discussed by Karim Yaghmour author of Building Embedded Linux Systems –, which is fine, it sounds like we can ignore any real-time comparisons here.

    Here’s my question – So what exactly does application and driver compat mean when looking at Linux?

    Is there such a thing as a standard API model across all Embedded Linux distributions (Java, Posix, other?), if so, why would application compat and driver compat be such an issue ? – If not, then it sounds like Linux is fragmented at the API layer – perhaps this is why interest in embedded Linux is low.

    – Mike

  5. kqiman says:

    The compatibility issue is exactly the same on windows, can you run a .NET application without bundling the .net compact framework on it ? i think the answer is no … can you run a Mono application on a linux without the mono stack ? the answer is no too …

    On linux systems, and unix in general, you got posix, which define a set of rules, and standards to maintain compatibility … There is also a bunch of libraries designed for different uses, you choose the ones that fits your needs. You can also rely on high level programming languages such as python, ruby, java or even c#, to get a better compatibility level.

    I think the low interest comes mainly from the propaganda that linux doesn’t support much hardware … And some companies give linux a try before saying that it’s incompatible, you can take a look at motorola linux based cell phones, nokia and the project maemo …

    I don’t know if you ever tried producing an embedded linux system, if not you can give it a try 🙂

  6. mikehall says:

    you’re talking about app-compat being at the framework level, whether this be .NET, MFC, ATL, OWL or other – embedded systems are typically "closed boxes", this means that the applications you build into the embedded systems are the ones that run there – many embedded systems do not allow for the addition of other applications (think ATM’s, medical systems, robots, others), so app-compat isn’t so much of an issue here – MFC, .NET, ATL and other frameworks are just components that can be added to a Windows CE/XPE design, these automatically add the underlying dependencies, this ensures that you have an o/s image that can boot and run your application.

    Think of the 1000’s of applications that run on Windows XP, all of these *could* run on Windows XP Embedded if the appropriate dependencies are added to the o/s configuration.

    – Mike

  7. kqiman says:

    I still don’t see how windows is more compatible than Linux, it’s exactly the same, and i could even say : Think of the 1000’s of applications that run on Linux, all of these *could* run on any Embedded Linux if the appropriate dependencies are added to the o/s configuration.

    I just found an article written by an ex-Microsoft programmer, it doesn’t talk about embedded linux, but it brings into light app compatibility under linux :

  8. mikehall says:

    The most interesting thing about this article is the closing comments "In addition, many of their bugs exist in other codebases manned by volunteers.". Look at the comments that mention the bugs may be fixed in another distribution – this talks of code base fragmentation and no timeline to get bugs fixed.

    We should come back to the core questions, is app-compat an issue because of distri fragmentation, and a lack of consistent API ?

    – Mike

  9. kqiman says:

    I don’t know, but from my testing and from my point of view, windows systems have far more unfixed bugs, and the problem on windows systems is that you cannot fire your favorite editor, and start fixing the bug … Also you when you talk about a bug in a linux distribution, you are talking about, a full stack of software, where under windows this doesn’t include for example a photo edition program and an office suite …

    Anyway, concerning the app compatibility, did you get any incompatibility? Did you try it yourself ? the sometimes existing incompatibility is at the binary level and almost never at the source level… you get an application that was written for BSD for example, and you compile it back for Linux, as long as you have the correct libraries, everything should work… That’s what we call POSIX.

  10. mikehall says:

    now that raises an interesting question which comes down to time to market – having source can be a good thing, at the same time, building an operating system from pre-built components can be a huge time saver.

    – Mike

  11. kqiman says:

    I never said, that there is a huge incompatibility at binary level, it’s rather rare those days. You can choose to stay binary compatible if you bundle the compatibility libraries. There is binary compatibilty, and you get source code too as a bonus pack.