Mike Hall on Choosing Embedded Linux over Windows

prostoalex writes "Mike Hall from Microsoft asks the audience why they would choose Linux over Microsoft for embedded projects. He provides a point-by-point description of benefits of Microsoft's products (Windows CE and Windows XP Embedded) and points out that starting out on Windows-based embedded platform might save development and testing time."

Comments

In other news...

[mstefanus]

Linus Torvalds the creator of Linux asks the audience why they would choose Microsoft over Linux for desktop application projects. He provides a point-by-point description of benefits of Linux products (SuSe, RedHat, JDS, etc.) and points out that starting out on Linux-based platform might save development and testing time."

Even if it saves development time ...

[Basje]

... you still have to pay the windows licenses over the 250000 units you shipped last month. Linux can be shipped without having to pay those license costs.

It is not that simple

[curne]

A friend of mine works for a company that makes embedded systems and they chose a Linux kernel to drive it since they have to make hundreds of tweaks in the kernel code to compensate for custom hardware (that they build in-house).

IMO, choosing your software is not just a matter of point-by-point feature comparison. Some times you need the ability to modify the behavior, especially because embedded hardware is typically somewhat eccentric.

Re:Plain old FUD

[91degrees]

Yes, It is FUD isn't it. For certain applications it can be an issue, but all you need is to have a company web site with the Linux source code (including any modifications you made), freely available for download.

Also, he fails consider that Windows CE has licencing issues, and the SDK has its own licence. And you need a licence per developer for the OS that these run on.

Re:OT Unix - like OS

[greed]

I think the important things about UNIX, aside from having the same libc.a APIs everywhere, is the filesystem.

To have a UNIX-like system, you need:

1. Single filesystem tree
2. Transparent mounting of filesystems into the tree
3. "Everything is a file" approach, all I/O types use the same APIs; so you only need special code for doing special things. (So "cat" can read from magnetic tape, raw disk, or a FIFO; but if you want to rewind the tape, you need a program that knows about it.)
   • Regular files
   • Directories
   • Sockets (TCP, UNIX, NetBEUI, AppleTalk, IPX/SPX--the difference is only in the names you use to open them)
   • FIFOs
   • Device-specials
4. fork(2)/exec(2)/wait(2) process model
5. "File mode" permission model (something that can be done with bitmasks), as opposed to an "Access Control List" model. (ACLs are available on many UNIXes, but very few programs support them. The OS still enforces them, but (say) "cp" won't preserve the ACL unless you update it.)

With those basic attributes, most batch UNIX programs stand a fair chance of working well.

I've worked on systems which implement only a few of them. Porting a UNIX combined file-and-network program to Windows is a massive pain, because the TCP sockets are not in the same identifier-space a s file handles--so you need to handle them separately. Similarly, any system which doesn't have "fork()" means you have to re-write all your co-processing code. AS/400's POSIX interface is particularly misleading--even more so than Windows. On Windows, you can at least run Windows .exe files fairly normally from the POSIX API; but on OS/400, non-POSIX stuff just doesn't work right (or didn't, back in 1997 when I last had to deal with it).

Even when there seems to be a good alternative, it may not work out well after all. So you can't fork()/exec() on Windows... well, so what, you just want to run a program and wait for it to exit, right? So spawn() is good enough, or CreateProcessEx() if you want more control.

But, launching a new process is very expensive on Windows; a make or shell program will be 10x to 100x slower on Windows than on a UNIX-ish system running on the same machine. When you write native Windows applications, you just don't code that way--you use threads, you use DLLs, you do everything you can in the same process image. You do NOT run external programs if you can help it. (You can, of course, do this on UNIX too if you like; but you don't have to....)

So even having [part of] the interface isn't going to save your code--if your application uses features which aren't handled well, or are simulated, it's going to suck on that system.