Posted
by
CowboyNealon Friday January 14, 2005 @07:53AM
from the does-and-doesn'ts dept.

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

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

... 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,...)^

^ 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?

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

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:

Single filesystem tree

Transparent mounting of filesystems into the tree

"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

fork(2)/exec(2)/wait(2) process model

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

The Object Manager [winntmag.com] provides a single tree for all named objects, including files. Win32 has its own directory in the OM of symbolic links that connect the DOS compatible drive letters to the actual devices. For files, Win32 just sticks \DosDevices\ on the front of the path before handing it to the native [sysinternals.com] (syscall) api. \DosDevices\C: is commonly a symlink to \Device\HarddiskVolume1, equivalent to/dev/hda1.

The OM can be extended by any kernel mode component by adding a new object type. One thing that an ob

The closer you get to conformance with POSIX with the *default* install, the more Unix-y you are. That's because POSIX is pretty much the definition of Unix. Windows does have some POSIX-ness, and you can install Cygwin or MKS, but it isn't the default.

You can think of Unix-y to be: having a certain subset of system calls, having a certain style of filesystem behavior and layout, a minimum set of "standard" utilities, the availability of a bourne compatible shell, the concept of "everything is a file", and

What happens when MS caves in entirely? They'll do exactly what Apple is doing - move to Unix and supply an emulation (let's not be pedantic here) layer. "Unix" implies a certain degree of not being fucked up, so we might have...a decent OS from Microsoft! This would be bad as it would lend legitimacy to "stop bashing Microsoft" arguments, never mind that they're a huge evil corporation.

It would require a massive die-off in their executive leadership to embrace a kernel as open as Apple, as Bill G, Balmer and others hate the GPL and Free Software, despise their customers, and heap contempt on everyone who is not them.

It could happen, but I doubt it will happen within 20 years and who knows what the computing landscape will look like by that time.

Y'know, I don't create embedded systems, but if you create software this is a familiar kind of scenario.

Generally seapking, commercial software makes getting things off the ground easy -- it's an important competitive point and vendors pay attention to this. Open source stuff is usually poorly documented, has a fairly rough learning curve , but has many benefits that offset this. In a sense, open source sits somewhere between "make" and "buy" on the make/buy decision continuum. It takes a bit more sweat

Well I agree, that under certain circumstances, commercial could save over open source. However I have worked with many an OS vender on embedded projects (true embedded systems that have real-time contraints) and found that all too often, not having the code to the library or OS really shoots you in the foot! In many cases embedded applications are very, very specialized and there is a signifigant learning curve of months to years for the platform in development. The problem is vendor x who you purchased th

Sure, but you can get access to Microsoft source. It'll cost you. If Microsoft is rational in the economic sense, they'll charge you so much that it is just barely worth your while to do so, which is another way to say they maximize their revenues.

With my engineer hat on, I agree that one size fits all is a bad idea. With my business hat on, then you can bet I'll say fortunately, my product happens to fit you.

The question is whether you will be able to get access to source code 5+ years from now. Depending on the embedded application you're designing, the lifecycle of the product can be decades - water/sewer valve control systems are a good example of an embedded system that can work without catastrophic failure for 40-50 years. Code maintenance issues are amplified significantly when all of the developers who originally worked on a project are dead. This is the main reason why most embedded applications (up unt

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.

Having to worry about licensing issues is a fixed cost for any development. Whether its the GPL or Microsoft's redistributable code license, the company lawyer needs to go through all the third party licenses and make sure that all terms are being complied with and it is not going to expose the company to unforseen risk.

It's true, but lets face facts - most business people are FAR more comfortable with ye olde "give me money" licensing model (I'm not familiar with CE licensing specifically most Windows licensing is of this type) than they are with anything else. There are people who would rather pay money and be on stable mental ground than even use a BSD license, much less the GPL.

What I did not see was why should you use Windows other than it is Windows?I do find it odd that Windows CE is not considered to be hard real time ready.If you read the story a one thing come out loud and clear.

1. Linux IS cheaper to deploy.

CE maybe a good choice for PDAs but I am really interested in seeing what Palm does. Could they do for Linux on the PDA what Apple did for BSD on the desktop?

In the PDA market going with Windows CE will do nothing but give you a Me too product.If you get the Xscale c

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.

and the added value is that, even if you'd want to keep the source, you can write it as a binary driver. not that i personally like this, but it's hard to imagine that people would worry about their precious IP like Mike Hall suggested.

"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)."

It sounds to me like your friend's company chose the wrong OS if they needed to make "hundreds of tweaks" to it.

My recommendation is to forget about Linux and Windows CE and use a OS that was designed from the ground up for embedded use.

It sounds to me like your friend's company chose the wrong OS if they needed to make "hundreds of tweaks" to it.

I apologize if I failed to make myself clear. What I meant is that when a company produces their own embedded hardware (which is the case I describe), no OS in the world will ever support your chipsets because they are unique to you. At least in those cases you need a kernel over whose code you can have full control.

My point goes to a simple pragmatic truth, that no matter how clever something

It is true that many people use Windows, but the cost of developing on Windows would be a bit. Also, even though he makes a good point, they should get someone seen as unbiased. Look at the comments berating him for self-promotion. He tells the truth, but he is rebuked for telling the truth because he is affiliated with the company that makes it.

Anyway, Geeks use linux to start with, so it's not like they'll take him seriously!

In an embedded system, it's not such a big issue if you have to GPL your code, since it won't be any use without the hardware you are embedding it in. Unique hardware is effectively a 'dongle' for Linux, in this case.

"In an embedded system, it's not such a big issue if you have to GPL your code, since it won't be any use without the hardware you are embedding it in."

If that's true, there's not much value to the "community" in forcing companies to release the source either. Perhaps revising the GPL accordingly would help promote OSS/Free software in embedded systems.

In an embedded system, it's not such a big issue if you have to GPL your code, since it won't be any use without the hardware you are embedding it in. Unique hardware is effectively a 'dongle' for Linux, in this case.

Writing an application that runs on the GPL'd linux kernel does not make that application GPL, you can do whatever you want with it. The only time you have to GPL your code is when you use GPL code yourself, or link to a GPL library, etc.

Maybe i'm a little paranoid here, but i really don't think that anyone at Microsoft is willing to change one bit in their Licensing (and that's the top issue i have with all MS-Products). So what's the point in this "Discussion"? Judging from his answers i don't think that Mike will change his view and admit thet the Linux-License and -Pricing-modell might have its advantages in some cases. Also he won't be able to change anything at Microsoft anyway.

For example, there is a bug in the IrDA driver. I spoke with Microsoft, they agreed it was a bug, asked for my code fix, have not yet patched the kernel (last time I looked)

But, our version of the kernel works fine.

PS. The bug is ironically commented that it is a bug in HP printers. Presumably HP was broken at some point, and so Microsoft hacked their code to work with the HP printers, but their fix was incorrect. HP has now fixed it in their printer

Linux scales seamlessly from small embedded systems to high-end servers. Microsoft has two incompatible kernels and operating systems: Windows CE and Windows XP. In fact, Windows CE is so limited that it is nearing its end of life--maybe Microsoft will replace it with something else called "Windows CE", but you can probably throw away your software. Windows XP is a messy, bloated behemoth that really doesn't scale down well.

You keeping using these words: scales, seamlessly, small. I don't thing they mean, what you think they mean.

It means exactly what any reasonable person would think it means: the Linux kernel runs on a small ARM board with a couple of megs of RAM, on a 16G 64bit machine, or a compute cluster with 256 nodes. The same software, libraries, etc., can run across that entire spectrum of machines.

Windows XP doesn't scale down to a small ARM board with a couple of megs of RAM and no disk. And Windows CE doesn't

"It means exactly what any reasonable person would think it means: the Linux kernel runs on a small ARM board with a couple of megs of RAM, on a 16G 64bit machine, or a compute cluster with 256 nodes."

I guess when you said "small" you were referring to the footprint. A system with "a couple of megs of RAM" is not small by embedded systems standards.

"The same software, libraries, etc., can run across that entire spectrum of machines."

Many embedded systems don't have memory management or a processor with p

I guess when you said "small" you were referring to the footprint. A system with "a couple of megs of RAM" is not small by embedded systems standards.

We are discussing the relative merits of Windows CE/XP and Linux. Linux scales from systems that are smaller than what Windows CE can handle to systems that are larger than anything Windows XP has been demonstrated with, and it does so with a single kernel and binary compatibility.

Many embedded systems don't have memory management or a processor with priv

No. YOU have been discussing the relative merits of Windows CE/XP. I simply questioned your claim that Linux scaled seamlessly from small systems on up. I'm not addressing Windows CE/XP simply because nobody has made the "seamlessly scale" argument for it as you have for Linux.

"With Linux, you can run an MMU-less port like ucLinux, or you can use any of a dozen other embedded operating systems with POSIX APIs."

"any recompilation and chances are forced by the different architectures, not Linux."

Of course you could use that statement to wiggle out of any argument against seamless scaling; even Windows could make that claim. Your not going to convince me that Linux or Windows is seamlessly scalable.

"That's what "seamlessly scale" means when talking about an OS, and it's the best any OS is going to achieve."

Certainly it's possible that an OS could be written that is more scalable than Linux. In any case even if Li

We had the unfortunate incident of having Windows CE and Advandtec runtime on one of our systems. The project manager was new, he wanted a "turn-key" system from the vendor, blah, blah, blah. At the time, it sounded like a good idea, and my boss relented. But now both he and I reget it terribly.

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

At my company the Microsoft salesmen outmaneuvered out defensive blockers, and managed to talk to management. As a result, that thought that productivity could be vastly improved by porting a million line embedded LynxOS/Motif system to WinXPe. "Ten people should be able to do it in a year!" It's now three years later with fifty people and there is still no sign of a light ever being found at the end of this tunnel.

A minor anecdote to illustrate the problem. Yesterday I performed a code review on a trivial piece of code. I wrote the Motif version in three days. They wrote the Windows version in one month. My code (using the horribly "bloated" Motif) was 850 lines. Their code using MFC was 5200 lines of code. Before you blame an outdated MFC and recommend moving to.NET, the non-UI portion of my code was approximately 250 lines, while theirs was still over a five hundred.

Next time figure out what their estimate will cost (e.g. 10 people ~ $100K = 1M). Then, if it's a good value give Microsoft the contract, subcontract your employees to Microsoft and pay Microsoft the money they estimated up front. Make them deliver the product for whatever it costs them, more or less than they quoted by contract.

we have been building radar systems with embedded processors for 15 years.

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.