Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Programming Software Windows Linux Technology

Mike Hall on Choosing Embedded Linux over Windows 75

Posted by CowboyNeal 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."
This discussion has been archived. No new comments can be posted.

Mike Hall on Choosing Embedded Linux over Windows More

Mike Hall on Choosing Embedded Linux over Windows

Comments Filter:

  • In other news... (Score:4, Funny)

    by mstefanus ( 705346 ) on Friday January 14, 2005 @08:11AM (#11360094)
    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 ... (Score:5, Insightful)

    by Basje ( 26968 ) <bas@bloemsaat.org> on Friday January 14, 2005 @08:12AM (#11360098) Homepage
    ... 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 ... (Score:4, Informative)

      by Spoing ( 152917 ) on Friday January 14, 2005 @08:36AM (#11360211) Homepage
      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?
      • 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."

        • Re:OT Unix - like OS (Score:4, Informative)

          by the_greywolf ( 311406 ) on Friday January 14, 2005 @10:08AM (#11360866) Homepage
          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).
        • It's simple really. If most Slashdotters like it, it's Unix-like, if they don't it's not.
        • 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.
        • 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.

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

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

          As always, caveat emptor.

          • 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

  • Plain old FUD (Score:4, Interesting)

    by geirt ( 55254 ) on Friday January 14, 2005 @08:28AM (#11360174)
    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 (Score:4, Insightful)

      by 91degrees ( 207121 ) on Friday January 14, 2005 @08:41AM (#11360237) Journal
      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:Plain old FUD (Score:3, Insightful)

      by jrumney ( 197329 )
      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.

      • Re:Plain old FUD (Score:3, Insightful)

        by arkanes ( 521690 )
        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.
    • 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?
    • 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

  • It is not that simple (Score:5, Insightful)

    by curne ( 133623 ) <curne@nOspAM.curnomatic.dk> on Friday January 14, 2005 @08:30AM (#11360177) Homepage
    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.
    • 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 priv
    • "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

        • Re:It is not that simple (Score:4, Insightful)

          by ClosedSource ( 238333 ) on Friday January 14, 2005 @01:58PM (#11364199)
          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.

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

  • The keyword here is... (Score:2, Interesting)

    by borfast ( 752138 )
    The keyword here is "might".
    [...] might save development and testing time.

    Sure, if you're lucky...
  • POSIX is not mentioned in the article.

    IANAD[eveloper].
  • 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

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

      If you write a driver compilied into the kernel, that
  • 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
  • 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.
    • 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 printer

  • What a crock .. (Score:2, Informative)

    by naden ( 206984 )
    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.

  • QNX (Score:1, Informative)

    by Anonymous Coward
    Why would you pick Windows or Linux over QNX?

    http://www.qnx.com/

  • let's see... (Score:3, Informative)

    by jeif1k ( 809151 ) on Friday January 14, 2005 @11:07AM (#11361560)
    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.
    • You keeping using these words: scales, seamlessly, small. I don't thing they mean, what you think they mean.
      • 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
            • "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-worl

  • Control at Low Cost (Score:2, Informative)

    by sirwnstn ( 848727 )
    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

  • Porting woes (Score:3, Interesting)

    by Brandybuck ( 704397 ) on Friday January 14, 2005 @03:34PM (#11365762) Homepage Journal
    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.
    • "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.
  • 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

Slashdot Top Deals

E = MC ** 2 +- 3db

Close