Slashdot Mirror

← Back to Stories (view on slashdot.org)

Mike Hall on Choosing Embedded Linux over Windows

Posted by CowboyNeal on 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."

75 comments

  1. In other news... by mstefanus · · Score: 4, Funny

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

    1. Re:In other news... by smittyoneeach · · Score: 0, Offtopic

      ...and your naughty bits.

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
  2. Even if it saves development time ... by Basje · · Score: 4, Insightful

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

    --
    the pun is mightier than the sword
    1. Re:Even if it saves development time ... by Spoing · · Score: 3, Informative
      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?
      --
      A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
    2. Re:Even if it saves development time ... by hey! · · Score: 2, Interesting

      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 equity to get going, but it gives you more freedom down the road, provided you're still on the road.

      Which software components you use is not purely a technical decision -- at least that's what I keep telling management. You have to look down the road and see the business scenario that you're expecting to be in. Supppose I could save two week on a twelve week development effort by using a commercial software product. If the software is only going to have a couple of dozen users, then from a business perspective the licensing costs and the impact of restrictions are relatively minimal. On the other hand, if I'm going to be equipping 2,500 users (much less 250,000), the two week difference is inconsequential.

      Using software from a vendor means you are entering into a business relationship with that vendor. This has consequences. Small consequences for small projects, big consequences for big projects. One of the great things about open source is that you don't have to enter into a business relationship with a vendor; or if you do you can replace the vendor if you disagree. That said, Microsoft is probably one of the better software vendors to enter into a relationship with, leaving aside whatever you happen to think of their products. Their product strategies are way more stable than the industry norm (which isn't saying much) and as long as your product has no disruptive potential (disruptive to Microsoft's position or planned positions).

      If, for example, I was developing a computerized milling machine, entering into a relationship with Microsoft wouldn't be a complicated business decision, and choosing/not choosing a Microsoft product could be done on a basis of pure technical merit. The number of units shipped are small, and the price of the units are high, so the cost of the license is hardly worth considering. What is most important, Microsoft has no strategic designs on the machine equipment market, so far as I know.

      On the other hand, if I were entering the set-top PVR market, the decision would be driven almost entirely by business strategic concerns. The number of units shipped is large, and the margins tight. Furthermore, Microsoft has strategic designs in this area, and I could on one hand end up on the wrong end of the DRM stick if I don't play ball with them. On the other hand, I could find myself in the position of office suite vendors in the early 90s -- competing with very vendor who supplies the heart of my system.

      In those kinds of situations, what you need really need to make the platform decision is a crystal ball. Which is why I avoid them. But that's the reason, I supppose, the world needs entrepreneurs.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    3. Re:Even if it saves development time ... by techiemac · · Score: 1

      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 the libary from has to learn your platform (there are often things like ASICs that have to be interacted with, unique bus archectecures, etc, etc) and then fix the problem. It's often much easier to go in and fix it yourself.
      In most cases some degree of customization will be required to get an embedded OS to work on your archectecture (drivers for ASICs, unique bus archectecures, removing some feature that is reducing determinism, etc). Here is where having the code comes in handy. All the embedded projects I've worked on has had one of more OS guys who's sole purpose is to get the OS working properly for the embedded application. Simply abstracting everything away often does not work in memory/processor limited applications (read an embedded systems primer for more info on the limitation of this environment). That's part of the fun of working in the embedded world. You really, really have to think about your code.
      There is no such thing (as of today) as a one size fits all OS for embedded systems. If there was, then I guarentee that it would be used in the embedded systems industry.

    4. Re:Even if it saves development time ... by EvilSporkMan · · Score: 1

      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.

      --
      -insert a witty something-
    5. Re:Even if it saves development time ... by hey! · · Score: 1

      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.

      As always, caveat emptor.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    6. Re:Even if it saves development time ... by Discoflamingo13 · · Score: 1

      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 until about a decade ago) ran off of home-grown OS's designed specifically for that system - many still do (my current project, for example). These concerns about maintainability are amplified even more when a product must be certified for safety-critical, fault-tolerant, or fail-safe capabilities.

      There are COTS embedded OS's that can serve in a clinch to save on development time - Green Hills and QNX being the two standard answers I'm familiar with. These companies have a better track record for source access and API work than most, because that's what their core business is - maintaining and certifying OS's for embedded programs work.

    7. Re:Even if it saves development time ... by SunFan · · Score: 1

      Except for Microsoft, it seems that *EVERYONE* is using unix-like operating systems.

      The world is choosing open standards, and Microsoft is digging itself into a hole.

      --
      -- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
    8. Re:Even if it saves development time ... by SunFan · · Score: 1

      What happens when MS caves in entirely? They'll do exactly what Apple is doing...

      I don't know. They have been so persistent about thwarting standards and slowly sucking people in to lock-in, that for them to change might be too much to ask.

      --
      -- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
    9. Re:Even if it saves development time ... by miu · · Score: 1
      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.

      --

      [Set Cain on fire and steal his lute.]
  3. Plain old FUD by geirt · · Score: 3, Interesting
    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.

    --

    RFC1925
    1. Re:Plain old FUD by 91degrees · · Score: 4, Insightful

      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.

    2. Re:Plain old FUD by jrumney · · Score: 2, Insightful

      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.

    3. Re:Plain old FUD by paulatz · · Score: 1

      Microsoft licences (EULA) can be violated in really strange and funny ways. Did you knew that it is strictly forbidden to publish .NET benchmarks without microsoft agreement?

      --
      this post contain no useful information, no need to mod it down
    4. Re:Plain old FUD by arkanes · · Score: 2, Insightful

      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.

    5. Re:Plain old FUD by LWATCDR · · Score: 1

      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 chipset from Intel and Windows CE from Microsoft how can you really add any value to your product? What can you do that sets you apart from HP and Dell?

      BTW come on Apple go back into the PDA market. How about one that uses BSD with some pretty Apple UI on top? Maybe a harddrive like the iPod uses?

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
  4. It is not that simple by curne · · Score: 5, Insightful

    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.

    --
    All interpreted languages are abstractions over Lisp
    1. Re:It is not that simple by koekepeer · · Score: 1

      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.

    2. Re:It is not that simple by Jondaley · · Score: 2, Informative

      I don't know about XP embedded but for CE, we can modify a good portion of the kernel code. I don't know the exact percentages, but I would guess 80%.

      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.

    3. Re:It is not that simple by ClosedSource · · Score: 1

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

    4. Re:It is not that simple by Anonymous Coward · · Score: 0

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

      Would it have been "hundreds or thousands of tweaks" on the other OS?

      Unless you know what they are doing to require those changes to their OS choice, your statement is unjustified.

    5. Re:It is not that simple by curne · · Score: 1

      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 is, it can still be useless to you.

      --
      All interpreted languages are abstractions over Lisp
    6. Re:It is not that simple by ClosedSource · · Score: 3, Insightful

      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.

    7. Re:It is not that simple by ClosedSource · · Score: 1

      "Would it have been "hundreds or thousands of tweaks" on the other OS?"

      What other OS are you referring to? I'm not picking on Linux, I'm making the general point that traditional OS's are not the most effective choice for embedded systems.

    8. Re:It is not that simple by cpeterso · · Score: 1


      Maybe building a device with custom hardware and having to pay developers to tweak an OS that does not support it is a bad business decision. Even if Linux is k-rad.

      --
      cpeterso
  5. The keyword here is... by borfast · · Score: 2, Interesting
    The keyword here is "might".
    [...] might save development and testing time.

    Sure, if you're lucky...
  6. POSIX? by Chexsum · · Score: 1

    POSIX is not mentioned in the article.

    IANAD[eveloper].

    --
    Pixels keep you awake!
    1. Re:POSIX? by paulatz · · Score: 1

      POSIX is a *standard*. I don't want to start a flamebait, but did microsoft ever cared about standards?

      --
      this post contain no useful information, no need to mod it down
    2. Re:POSIX? by Chexsum · · Score: 1

      Bastardized is the opposite of standardized?

      --
      Pixels keep you awake!
  7. Embedded Linux by Anonymous Coward · · Score: 0

    2) Do not eat embedded linux.

  8. Truth in bias by solafide · · Score: 1
    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!

    Billy

    1. Re:Truth in bias by Chexsum · · Score: 1

      Geeks begat Linux. ;)

      --
      Pixels keep you awake!
  9. Re:In other news... Offtopic but the truth by Anonymous Coward · · Score: 0
    Clever allegory, but take it somewhere else.

    In Christ, Billy

  10. GPL less of a problem here by Andy_R · · Score: 1

    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.

    --
    A pizza of radius z and thickness a has a volume of pi z z a
    1. Re:GPL less of a problem here by ClosedSource · · Score: 1

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

    2. Re:GPL less of a problem here by gregmac · · Score: 1

      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.

      If you write a driver compilied into the kernel, that becomes GPL, but if you're concerned about it you can do a binary module (not that this is really a good thing, but its possible). More likely your comment applies here anyways - the driver is useless without whatever piece of hardware it's for, which, if you're writing a driver for it, is likely only sold as part of your embedded system.

      I don't really see where the GPL issue is for embedded developers (being one myself). If you extend an application someone else wrote, then it's only fair you GPL it - they did a lot of work for you. If you don't want to GPL it, then develop it from scratch by yourself.

      --
      Speak before you think
    3. Re:GPL less of a problem here by SunFan · · Score: 1

      Perhaps revising the GPL accordingly would help promote OSS/Free software in embedded systems.

      That would make it into the BSD license.

      --
      -- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
    4. Re:GPL less of a problem here by ClosedSource · · Score: 1

      "That would make it into the BSD license."

      That certainly wouldn't bother me, but I was suggesting a different treatment of embedded systems vs. non-embedded systems under the GPL.

    5. Re:GPL less of a problem here by NotZed · · Score: 1

      Yes, there is much use. Being able to control and extend the hardware you purchased, for example.

      --
      _ // `Thinking is an exercise to which all too few brains
      \\/ are accustomed' - First Lensman
  11. Let's all help MS with their marketing campaign by gotan · · Score: 1

    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.

    The whole discussion will probably only be pored over by the Marketing-department to come up with a campaign that's not as ridiculous as Microsofts usual Marketingblurb. Why help them with it? Let them do their campaign and *then* pick it apart in public.

    --
    "By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
  12. OT Unix - like OS by cgenman · · Score: 1

    What exactly defines a unix-like operating system? I hear this term a lot, yet I have yet to see a real definition. Is it the command-line? Multi-user aspect? File permissions? Removable GUI?

    This isn't intended as a troll. I'm just curious if what one person would call "Unix-like" another would call "modern."

    --
    The ______ Agenda
    1. Re:OT Unix - like OS by the_greywolf · · Score: 3, Informative

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

      --
      grey wolf
      LET FORTRAN DIE!
    2. Re:OT Unix - like OS by Anonymous Coward · · Score: 0
      Not trying to cause prolbems either, but if Windows provided a POSIX interface (it does, poorly) it would be Unix-like?

      I think the confusion here comes from the kernel-api-gui confusion. For example Microsoft loves to say Unix when they are talking about Gnome.

    3. Re:OT Unix - like OS by greed · · Score: 4, Informative
      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.

    4. Re:OT Unix - like OS by Phillup · · Score: 1
      I would say that it really depends on what happens when you open up a shell and type:
      man man
      But... that isn't really what "defines" the term.

      I believe that in the end it is all about system calls.

      In the end, it would be up to these guys to say that you are a Unix OS. The closer you get to meeting the spec... the more "Unix like" you are.
      --

      --Phillip

      Can you say BIRTH TAX
    5. Re:OT Unix - like OS by Foolhardy · · Score: 2, Informative
      1. The Object Manager 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 (syscall) api. \DosDevices\C: is commonly a symlink to \Device\HarddiskVolume1, equivalent to /dev/hda1.
      2. The OM can be extended by any kernel mode component by adding a new object type. One thing that an object type can do is be reparsable; extending the namespace into an object as if it were a directory. One of the object types that the IO Manager exports are device objects. Device objects are reparsable and are used to extend the root namespace into filesystems that will return file objects.
      3. Everything in UNIX that is a file is also a file object in NT, and many more kinds of things are also objects. Browsing through \Device with winobj I see a beep device, null, my cdrom, the gameport, my harddisk partitions, the keyboard, sysaudio, the video device, several protocols (IP, TCP, UDP, NwLnkIpx, NwLnkSpx), the named pipe filesystem (npfs.sys), the mailslot filesystem (msfs.sys), NFS and SMB server and client devices, and tons of other stuff. Each of these are device objects that produce file objects for client processes; objects under the IO Manager's domain. You can use the same read, write and ioctl functions on all of them. Some, like TCP rely heavily on ioctls but you can still use read and write on a socket handle (which is really a file open under \Device\TCP)
      4. Win32 does not support fork directly (and neither do many popular shared Win32 libaries), but NT itself has no problems with any of those functions. Environment subsystems like SFU use the same syscall interface that Win32 does to make processes and such.
      5. I don't think that this is really a requirement of UNIX. Yes, it should provide compatibility as needed for the old style permissions but there are UNIXes that use ACLs internally.
      The programming style for UNIX or even a POSIX target is different from Win32. This isn't due to NT, but the Win32 subsystem and all the libraries that are initialized up startup for new Win32 processes. NT is perfectly happy to make a new process with a copy of the parent's address space with no new memory or threads or libraries or anything. fork() in SFU is as fast and efficent as it should be.
    6. Re:OT Unix - like OS by Brandybuck · · Score: 1

      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 an emphasis on text formats for data and configuration.

      --
      Don't blame me, I didn't vote for either of them!
  13. This may be redundant, but by VernonNemitz · · Score: 1

    It's on-topic, at least. The best answer I know is that if you find a bug in Windows, you have to wait for Microsoft to fix it, but a bug in Linux is one you can fix right away.

    1. Re:This may be redundant, but by Jondaley · · Score: 1

      Not true. At least for most of the WinCE code base.

      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 printers (or at least the ones I am using), but the Microsoft code no longer matches the IrDA specification, and so some HP printers print really slowly, if at all.

  14. What a crock .. by naden · · Score: 2, Informative

    The COTS article that the Microsoft guy keeps referring to is written is by Green Hills Software. You know the one that considers itself:

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

    --
    Funtage Factor: Purple
    1. Re:What a crock .. by Discoflamingo13 · · Score: 1

      Except that they ARE, that would be a valid disagreement.

  15. Re:In other news... Offtopic but the truth by 91degrees · · Score: 0, Offtopic

    I'd suggest Adequacy. Except it looks like someone beat him to it

  16. QNX by Anonymous Coward · · Score: 1, Informative

    Why would you pick Windows or Linux over QNX?

    http://www.qnx.com/

    1. Re:QNX by turgid · · Score: 1

      Indeed. Or VxWorks, or Chorus...br?

      --
      Stick Men
  17. let's see... by jeif1k · · Score: 2, Informative

    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.

    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.

  18. Slashdot-like by ClosedSource · · Score: 1, Funny

    It's simple really. If most Slashdotters like it, it's Unix-like, if they don't it's not.

    1. Re:Slashdot-like by Anonymous Coward · · Score: 0

      Everquest is Unix-like?

    2. Re:Slashdot-like by ClosedSource · · Score: 1

      Most Slasdotters like Everquest?

  19. As indigo montoya might say by ClosedSource · · Score: 1

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

    1. Re:As indigo montoya might say by jeif1k · · Score: 1

      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 scale up to gigabyte behemoths or clusters. And Windows CE and XP are wildly incompatible with each other.

      As indigo montoya might say

      I don't know who Indigo Montoya is, but he/she doesn't sound like the kind of person you would want to go to for your IT advice.

    2. Re:As indigo montoya might say by ClosedSource · · Score: 1

      "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 privilege levels . How can Linux run on such a system without massive changes?

    3. Re:As indigo montoya might say by jeif1k · · Score: 1

      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 privilege levels . How can Linux run on such a system without massive changes?

      With Windows CE, you are indeed stuck, since there simply is no implementation of its proprietary APIs for MMU-less systems. 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.

    4. Re:As indigo montoya might say by ClosedSource · · Score: 1

      "We are discussing the relative merits of Windows CE/XP and Linux."

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

      In other words, in real-world small systems you can use a modified version of Linux or other OS's that are not derived from it. Thus Linux does not seamlessly scale from small to large systems. QED.

    5. Re:As indigo montoya might say by Anonymous Coward · · Score: 0

      No. YOU have been discussing the relative merits of Windows CE/XP.

      Yes, me, and everybody else discussing this story, except for you.

      I simply questioned your claim that Linux scaled seamlessly from small systems on up.

      Yes, and it scale seamlessly from small systems on up, both relative to CE and in absolute terms. Note that the figure I gave is not the minimum--you can strip Linux down further. I just gave it as an easily achievable data point that's widely used in systems like routers, etc.

      In other words, in real-world small systems you can use a modified version of Linux or other OS's that are not derived from it. Thus Linux does not seamlessly scale from small to large systems. QED.

      Linux provides the maximum degree of compatibility between implementations that the hardware allows; any recompilation and chances are forced by the different architectures, not Linux. That's what "seamlessly scale" means when talking about an OS, and it's the best any OS is going to achieve. Windows is still far from that gold standard.

    6. Re:As indigo montoya might say by ClosedSource · · Score: 1

      "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 Linux is "the best any OS is going to achieve" in scalability, that doesn't make it seamlessly scalable.

  20. Control at Low Cost by sirwnstn · · Score: 2, Informative

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

    1. Re:Control at Low Cost by Anonymous Coward · · Score: 0

      If you have to distribute your source than you don't have control over it.

  21. Porting woes by Brandybuck · · Score: 2, Interesting

    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.

    --
    Don't blame me, I didn't vote for either of them!
    1. Re:Porting woes by bill_mcgonigle · · Score: 1

      "Ten people should be able to do it in a year!"

      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.

      See if they bite.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  22. Re: Do Not Eat Embedded Linux by Anonymous Coward · · Score: 0

    So I shouldn't call my distro Muselinux?

  23. Our experience with vxworks, XPe and Linux by dmh20002 · · Score: 2, Informative

    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.

    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.