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.

Re:Even if it saves development time ...

[Spoing]

2. ... 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.

No doubt, and I'll add;

...or pay for the extra hardware needed to run embedded Windows over embedded Linux.

...or, if you decide that even embedded Linux is too heavy, your Linux app can be much more easily ported to one of the other open or propriatory *nix clones out there (*bsd, QNX, ...)^

1. ^ mini rant: Except for Microsoft, it seems that *EVERYONE* is using unix-like operating systems. Palm was one of the last holdouts, and even they are switching. What's it going to take to have them cave in entirely and not just as a crufty though sometimes handy add-on layer?

Plain old FUD

[geirt]

He starts with:

I don't want this to turn into a "Linx is better than Windows is better than Linux" discussion, no throwing of mud or Fud

and ends with:

Much has been written about the pitfalls of incorporating GPL software into a product. An often overlooked consideration, however, are the costs of having to even worry about these licensing issues.

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.

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:It is not that simple

[ClosedSource]

I think it's redundant to say an embedded system with custom hardware. What other kind is there?

It's not generally necessary to modify an OS just to support custom hardware. Historically, most embedded OS's were proprietary and not being able to modify the OS has never been a great limitation.

Perhaps the problem is that since general purpose OS's like Linux weren't designed for embedded systems, more tweaking is required.

Re:OT Unix - like OS

[the_greywolf]

in my understanding, a "Unix-like" operating system is one that complies either in part or in whole with the POSIX specification, but may or may not have been certified as such.

a "Unix" operating system is one that fully complies with POSIX and has been certified as such. in this case, it can legally carry the Unix trademark.

"modern" is probably the wrong word for anyone to call Unix. "mature" is more accurate, as it is a relatively old standard that has survived the test of time. Unix applications written in the early 80's would probably compile and run just fine on any modern Unix-like with few to no modifications (provided the compiler support exists, of course).

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.