Mike Hall on Choosing Embedded Linux over Windows 75
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."
Re:Even if it saves development time ... (Score:4, Informative)
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, ...)^
What a crock .. (Score:2, Informative)
"the technology leader for real-time operating systems and software development tools for 32- and 64-bit embedded systems."
I'm sure they don't have an interest in picking holes in Linux.
Re:OT Unix - like OS (Score:4, Informative)
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:It is not that simple (Score:2, Informative)
Yes, there have been times that we wish we could modify other parts, but it hasn't been too bad.
WinCE 4.2 does seem to be more restrictive than previous versions -- haven't looked into it too much yet.
I don't know what the license agreements are in terms of modifying the so-called "private" code, as opposed to just the "public" code. If modifying the private code isn't allowed, then the parent has a pretty good point, as that probably shrinks the percentage of modifiable code to 50% or less.
QNX (Score:1, Informative)
http://www.qnx.com/
let's see... (Score:3, Informative)
Linux natively uses POSIX-compatible APIs, widely used in the embedded world, Windows XP doesn't.
Linux has no per-copy licensing costs, Windows does.
Linux runs on a much wider range of hardware than Windows.
Linux has a mature, standard set of command line administration tools, invaluable for running and debugging a system over, say, a serial line. Windows XP doesn't.
Those are just off the top of my head. There are probably lots more reasons.
Re:OT Unix - like OS (Score:5, Informative)
To have a UNIX-like system, you need:
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.
Control at Low Cost (Score:2, Informative)
I will agree, the vendor had a really fast development time. I was happy about all the high level changes they could make in such a short time. It would have taken us longer to code something from the ground up. BUT, we ran into serious problems with the Advantec drivers, and runtime and then certain issues with Windows CE, memory leaks, and so on. The time it took for us to track down the problems and to deal with the vendor and Advantec costed us too much in man hours and late project schedules. The entire process was too painful and the worst of all, we had absolutely no control over the lower level software involved.
Bottom line: at our company, we like to have control over our software, down to the source code. Linux gives us that control and flexibility. That's why we will choose embedded Linux over WinCE any day.
Suffice it to say, we won't be using a WinCE solution any time soon, unless we are proved wrong later on.
Re:OT Unix - like OS (Score:3, Informative)
Our experience with vxworks, XPe and Linux (Score:2, Informative)
for parts of our systems that require submillisecond timings, we use vxWorks (and before that pSOS) because we can easily get to bare metal and control exactly what is happening with interrupts and threads. We use the very basic kernel of vxworks. its very expensive but we are relatively content for that type of application. We can't screw around with these applications so we bite the bullet.
we also have parts of the system that are real time but don't have such tight requirements (user interfaces, communications multiplexing etc). We used to use vxworks on those but the development system and licensing expense is horrendous. Then w tried windows XPe based on the false assumption that the commonality of our development systems (XP) and the target (XPe) would give us some savings. but Xpe was very hard to configure and get our applications running. It took a lot of training to get where our programmers could deploy applications. The development system was cheap ($1k) and the runtime costs were much less than VxWorks. But the development effort required negated those savings. So we ditched that after one program.
then we started using Linux on Diamond Systems EBX and PC-104 boards. Diamond Systems provided a stripped down slackware based flashdisk image with a configured 2.6 kernel, glibc and the basic executables. It worked like a dream. We develop on Fedora 2 workstations, and the executables move right over. We have written a couple of character mode drivers for some special hardware and that was easy too. It isn't 'embedded' linux, its just plain old linux. it runs easily on a 128MB flashdisk and 128MB RAM with lots of space left over. So we were hooked.
(it turns out we always deliver source with our systems so the GPL is no problem for us and our customer doesn't care either because they don't redistribute)
an personally, I used Sun UNix in the 80's and switched to windows in the 90's. Going back to a unix-like development environment kicked ass. I had forgotten how productive it was.
The momentum in our company is to switch to Linux for any new applications that aren't completely hardcore.
On a different note, however, I have a complaint with the 'embedded linux' vendors about their sales model. They don't publish prices, you have to 'negotiate' a price. They are cagey about 'open source'. They try to tell you that you have to buy a 'seat' for every developer. Why do that when the development systems they provide are open source? The most valuable service they provide isn't real time extensions, but IMHO it is the creation of turn-key cross-development environments and board support for embedded systems. Thats worth a lot, but from my experience they are unpleasant to deal with (maybe because I am a introverted engineer) and the expense of their tools negates any advantage unless you are doing a product that is going to be produced in the millions so that the elimination of runtime licensing expense makes it worthwhile.