Possibly. Then again, perhaps so did the US. Until now the US were careful never to piss off more nations than they could handle. But this time it seems the whole world is pissed. The so-called coalition of the willing consists of three types of nations: those run by right-wing administrations (Italy, Spain, Denmark), those bought off with US money or influence (eastern Europe), plus the UK and Australia, who have yet to defy the US. None of these administrations have popular support at home. For this "war" that won't matter, but after the respective next elections, W will have much fewer friends in the world.
> may we succeed afterward in rebuilding Iraq the > way we succeeded in rebuilding Japan and Germany
While I fully agree with your sentiments, the US did about as much rebuilding of Germany as they did of France and England. Actually, quite a bit less. Germans did all the rebuilding themselves and repaid their share of the Marshall funds in time for Elvis. Iraq will be requiring a heck of a lot more active external participation, especially of the financial kind, which I am certain the US is quite unprepared and unwilling to contribute long-term. If our "rebuilding" of Afghanistan is anything to go by, we'll be doing a road and some bridges and then calling it quits. Promises are made in the early stages, while the knickers are still on. Afterwards during the smoke, it's quite ok to say that you've had better.
See, that's the great thing about America and democracy in general: we can disagree with our government and people in power, call them names, and still have every right to stay here. THAT'S what makes America (and Canada, and the UK, and France, and Germany, and...) great. Annoying, ain't it?
> They have also been very conservative with their design (almost dissappointly so).
Well, their goal seems to be to create a wreck diving platform, not to break new records in sub design. If you have a clearly defined and reachable goal, you tend to go about reaching it by the most conservative and reliable means possible in order to minimize financial and safety risks and maximize chances of success. If you want to see a counter-example to conservative design, check out CargoLifter. I used to follow their progress religiously until they went under. Theirs is a case study of heaping speculation and untested technology upon all other kinds of money squandering.
> Also remember that Germans built rather a lot > of diesel-electric subs over the years
True, but Germans, like most other humans, aren't a hive collective. Which means that the knowledge and skills accumulated by members of a defense contractor don't automatically transfer to the population at large. This is not to say that these guys aren't skilled, because judging from the construction details it certainly seems they know what they're doing. They also have a fair share of engineers amongst themselves.
> It is one thing to depend on a weld that the > lowest bidder did, it is another to depend on > one that you did yourself.
They had the pressure hull robot welded and X-ray inspected, resulting in perfect welds, according to their construction info. That's probably better that most homegrown sub efforts. I do wonder just how much money these guys have, though, and whether there's more where that came from.
This new one looks much cheaper and piggier than the SJ30. What's with the cheap NON-REMOVABLE plastic cover that will inevitably break off during the first week? Sorry, but the SJ30 looks much better.
> Figuring out the cause of the problem allows NASA to fix any design or procedural problems
Drumroll please, he got it. Now wouldn't it have been nice to have actual pictures of the wing damage, so that we can reduce the amount of speculation about whether it was the wing or the computer or whatever. No, it wouldn't have saved the shuttle or astronauts, but that's not what we're talking about here at all. As it is we may never know the cause, and chances of deducing anything from any remaining wing shards are pretty slim.
If it wouldn't have helped at all to have visuals of the damage in orbit, why on earth are we spending millions gathering debris to reconstruct what happened? A visual inspection, if it had been possible, could have potentially removed a lot of doubt about what really happened, even if it couldn't have saved the shuttle. It could have also given the astronauts a chance to assess their odds of survival and given them more time to say farewell to their families. Depressing maybe, but certainly pragmatic and humane.
> What I am less thrilled with is their emphasis on storing biometric data and >trying to get what they see as a huge amount of money being spent on ID cards.
Think of it another way: your wife (and I mean that in the most generic and non-exclusionary way possible) will need a court order to get a peek at your p0rn collection. Ain't that somethin'?
> you'd be surprised what you can do with 50 MIPS and 64k. > "32-bit" is by far a requirement for most embedded functions.
I assume you meant "32-bit is NOT a requirement". Perhaps not for code, but certainly for data. Do you have any idea how much data is involved in street maps and route calculations? For a trip through a few states you will need megabytes and megabytes of memory for the data, either RAM or at least HD cache. In either case you're not getting anywhere with 64KB combined RAM.
> You can [...] have a network of 10 8051 microcontrollers scattered around the car for under $20.
You are kidding, right? That's the OEM quantity cost of the micro alone. What about the support circuitry, PC board, casing, cabling, hardware design and development cost? This is a very simplistic view. I can tell you that replacing 10 special purpose micro-based computers with one general purpose computer very often IS cheaper, whether you believe it or not. Have you ever had to replace the engine management computer in your car? That's not an x86 in there, that's a humble micro (or a set thereof). Leaving aside consumer markup and all that, even the manufacturer pays more than a couple of of bucks for this unit, since they usually buy it from a third party (Siemens, Bosch etc.) Keep in mind that we're not even talking about replacing the EMC with WinCE here, no-one in their right mind would do that. This is only to illustrate that just because that 8051 costs $5 doesn't mean that that reflects in ANY way on the final cost of the product.
> Neither a GPS nor an MP3 necessarily require an OS.
I think there is some confusion about the purpose of the OS here. The OS won't render street maps or play files. It facilitates low level functions such as allowing both GPS and music player to run on the same hardware at once, it provides the FS and networking code, it (possibly) provides a GUI library, etc. If you don't use an OS, you have to code the task switching and all other services yourself. These particular services are some of the trickiest and most bug-prone types of code there are. Just look at the Linux kernel, which is still maturing in that respect after all these years.
> WinCE just issues commands to the IDE bus which causes the DVD or CD to "play." > A microcontroller such as the 8051 can do that too.
I'm not sure you understand what goes into reading a file from a CD or HD. You don't just issue a command to a CD drive to "play", drives typically require you to read or write a block of data (typically 512 bytes) at a particular location. You have to read a block into memory and from there send it to the output device, be it an MP3 decoder chip, a software decoder, or any other device. In order to do that, you first have to know where on the disk the file containing the data is, the logical address of the block. In order to do that, you have to walk the FS structures on disk, which are also stored in 512 byte blocks. Drives have no notion of files and directories, they only know blocks. For simple file systems like FAT that can be done with mere KBs (though not if you want to cache the directory and file info in order to display them on-screen for the user to navigate--in that case it all needs to be in RAM, or it will be unbearably slow, especially with a CD or DVD). For more complex ones like NTFS or ext3 it takes more than 512 bytes to walk the FS. That's one of the reasons it's hard to find consumer devices that read anything other than FAT drives. Even FAT32 is rarer because of the long file names and the extra memory required (since a file or directory name can be up to 256 bytes, 64KB of RAM would let you browse only about 256 files in the worst case, though on average probably at least twice that--even though MP3 track names often do tend to get rather long if they include the track number and title).
> Due to the incredibly low cost of microcontrollers, > this is going to beat a central WinCE system every time
What can I say, just about every car manufacturer out there is proving you wrong on that. Sure, WinCE might not be the best choice, or even a good one; I'm with you on that. But centralized computers are a fact of life--NASA has been using vxWorks to run more than one of their space probes. Do you get bugs? You bet, as they've proven time and again. But you can also fix bugs, as they've also demonstrated live, in transit. Same with BMW: their first release is having bugs, but those bugs will be fixed and hopefully won't occur again in future releases. Maybe it will take switching from WinCE to make things more reliable, but they're certainly not ditching the system architecture.
Perhaps, but it is limited in the total amount of addressable memory, and once you add external memory you get into messy issues of paging and crap like that. It's not a 32-bit processor, after all, and the linear address space isn't that large. That's not to say it is not a great micro, because it is, but it's more meant to be THE computer, rather than just a PART of a computer, like a more general purpose CPU.
> Most of it exists, and that which doesn't, you write. You end up with more reliable code.
According to whom? Experience and statistics would teach you that the more code you write yourself, the more bugs you tend to end up with. One of the great advantages of third party code libraries is that more eyeballs have seen it and it has had more chances to be debugged. Doesn't hold true for all code of course, and it doesn't mean you're not a great programmer because your code has bugs, it's just a matter of statistics.
> Simply the fact that microcontroller-based applications fail less > frequently than CE-based applications is pretty clear evidence of that.
Yes, but that doesn't have to be due to self-written code. Micro firmware tends to be much more compact and specialized, with fewer software modules having to work together. Simpler software tends to result in higher reliability. But having lots of micros scattered around an automobile also increases the cost and decreases the flexibility: more hardware, more networking required to get the micros talking to each other, only a limited number of ways in which they can interact with each other. Adding new functionality isn't simply a matter of a software upgrade. Consolidating many functions into a single computer is attractive because it can lower costs (especially with off-the-shelf OSs and hardware) and also offers the lure of easy feature upgrades. Whether the latter ends up actually happening or not is another matter, but it might definitely be a selling point during the design phase.
> Agreed, but how much third-party software is available to control the climate in a BMW?
Well, that's not the type of software they'd be looking to reuse, that would definitely be a custom job. But if you also want the same computer to run your GPS and your MP3 player, how would you do it without an OS? You'd have to scrounge for code libraries to do those various things, you'd hope that they use compatible memory management (after all, there's no OS so each library has to do it itself), you hope that you can somehow timeslice them together, etc. Too much nitty gritty that you'd rather not worry about.
> ow much memory and storage and networking is required in a car?
A lot if you want to deal with real file systems such as on CDs and DVDs, store mapping data and updates, and do all sorts of other memory intesive things. That's the thing with micros: an external I2C 64K RAM chip might seem plenty during initial design, but as the inevitable feature bloat proceeds, it becomes more and more limiting. Then you start counting cycles to see if you can squeeze another task into the main state machine loop while still polling the keys often enough, and before you know it you're back in 1986 trying to imitate the Amiga on an 80286, a platform simply not meant for that sort of thing.
> I'd just argue that a car is a perfect example where highly > specialized hardware and software would be the way to go.
The future will tell. I think that given a proper hardware platform and a proven OS it's quite doable and even desireable. I fully agree that WinCE was a very poor choice, and I'm almost certain that eventually BMW will switch to another OS. I'd bet money that this was a management-driven decision and not initiated by developers. But just look at NASA and space vehicles, which are often fully controlled by just one or very few computers. This gives them the flexibility of debugging and fixing problems long after launch, which would be much harder or impossible if all the various functions were performed by individual bits of silicon. You'll find that most of the spectacular failures occured after switching to new software and/or hardware. In time these bugs are ironed out and the software improves with age.
> Do we really need windows running the windshield wipers?
Well, that's the point--Windows isn't running the wipers, it's still a proprietary piece of code doing it. But on the same CPU there's also another proprietary piece of code that's operating the trunk, and another one maybe the seats, etc. Running all these things together would then either require writing one monolithic app doing all these various things and implementing some time slicing mechanism, or running separate bits of code on an OS that takes care of multitasking. It's not just the multitasking though, it's also making sure to have a thread-safe GUI, having IPC, synchronization, and maybe even some real-time capabilities. All together these various things might be more than a vendor might want to tackle all at once. After all, that's the whole point of general purpose OSs, even real-time ones.
Just as an aside, this area of integrating a lot of services on a single CPU in consumer devices is still fairly new, and there's still a lot of experimentation and shaking out going on. Embedded WinCE is still new and has yet to establish itself--and it may yet very well end up failing to do so. I am puzzled by BMW's choice of WinCE, especially since there are more established choices available, even for multimedia real-time OSs (such as QNX). It's hard to know what economic considerations went into this, or what kind of promises Microsoft made. But if embedded WinCE will turn out to flop, it's not exactly the end of the world for BMW. They can still throw some extra developers at it and switch to another platform without abandoning the hardware. But it will certainly end up costing them money.
> the resulting crash of the radio control system won't corrupt memory > in the transmission, brake or fuel injector control system
I don't think you'll find any manufacturer seriously considering running mission critical stuff such as tranmission and engine management on the same general purpose computer as the CD player and climate control. They're greey, but they're not stupid. Those functions run on embedded micros inside the respective components, possibly under higher-lever control of an external CPU. So if the CD player software reads a bad block and corrupts memory, it might possibly shift into the wrong gear if they were cheap enough to run the shifting logic on the same computer, but it won't alter the firing sequence of the cylinders. Even in the most integrated scenario you're likely to see at least two main computers broken along two lines, mission critical and creature comfort, with very tightly controlled access to each other. It's ok if the CD player crashes and stops the seat massager or steering wheel warmer from working, but it's not ok if it also shifts the transmission into reverse at 90 mph on the freeway.
> I've developed under Windows CE, Windows, Palm, Unix, and 8052 microcontrollers > Parts inside washing machines and cars, however, are not going to see such variable usage.
Well, that's where you're wrong. They are trying to squeeze a lot more than a single function out of these embedded machines. For example, the computer in the BMW takes care of the climate control, entertainment system, and lots of other features of the car. It's also running a pretty fancy GUI. You need a fair bit of horsepower for this sort of thing, an 8051 won't do--especially if some of the features (such as music) are done in software. Which of course could still be done via proprietary software even on an ARM or an 80386 or whatever. Except that when you have a lot of fancy functionality that takes a lot of software to implement, you try to reuse as much existing software as possible--you don't want to have to reimplement GUI libraries, networking, storage and memory management, music playing etc. from scratch. Some of this stuff might be available as simple C libraries that you can link into your code without requiring an OS (or as a pseudo-OS where the app and the OS are one single executable image), but not everything. A lot more third party software is available for larger OSs such as WinCE and Linux, and these OSs also provide a lot more native functionality that you don't have to code or buy extra, such as a GUI, networking, memory and storage management etc. In other words, the sort of services your typical OS provides that you tend to take for granted but that are often missing in highly embedded systems.
It's basically a trade-off: you have to make a choice how tightly optimized and minimal you want your system, versus how much effort it will take to implement and extend in the future, versus how easy it will be to find developers to maintain the code later on. For many, a highly specialized hardware and software platform might still be the best choice, while for others a more open OS is preferable.
> Golly! It looks like that particular argument is now dead and gone.
Hardly. As has been mentioned before, some independent industry analysts were actually surprised that the drop in sales was only as much as it was. They did the calculations of new artists signed, albums released, and all the other factors that go into the total sales equation, and estimated sales to be actually less than they ended up being. Some concluded that music sharing might have accounted for that.
> Lets face it, C is not well suited for window environments
That's very true, but a straight C API is much easier to wrap in an OO framework. OTOH, a C++ API like KDE is a PITA to bind to other languages, both OO and other. Just look at the gyrations Kylix has to go through to bind one OO framework (CLX) to another (Qt). Unless there is one universal OO mechanism (such as.NET is trying to push through), it's better to have the OS and windowing system implemented in a simple non-OO procedural language. It's just a lot easier to invoke a library entry point and pass in state than to invoke an object method with its implied state.
This is not to say that I don't like KDE and Qt. I think Qt is a great example of the benefits of a well designed OO framework. I'm merely pointing out the hassle if you happen to not be a C++ fan.
Slashdot Mirror
> oh wait, what the fuck does the UN do?
It's coming in black helicopters to get YOU--just look out the window!
> The UN tossed itself in the dustbin
Possibly. Then again, perhaps so did the US. Until now the US were careful never to piss off more nations than they could handle. But this time it seems the whole world is pissed. The so-called coalition of the willing consists of three types of nations: those run by right-wing administrations (Italy, Spain, Denmark), those bought off with US money or influence (eastern Europe), plus the UK and Australia, who have yet to defy the US. None of these administrations have popular support at home. For this "war" that won't matter, but after the respective next elections, W will have much fewer friends in the world.
> may we succeed afterward in rebuilding Iraq the
> way we succeeded in rebuilding Japan and Germany
While I fully agree with your sentiments, the US did about as much rebuilding of Germany as they did of France and England. Actually, quite a bit less. Germans did all the rebuilding themselves and repaid their share of the Marshall funds in time for Elvis. Iraq will be requiring a heck of a lot more active external participation, especially of the financial kind, which I am certain the US is quite unprepared and unwilling to contribute long-term. If our "rebuilding" of Afghanistan is anything to go by, we'll be doing a road and some bridges and then calling it quits. Promises are made in the early stages, while the knickers are still on. Afterwards during the smoke, it's quite ok to say that you've had better.
See, that's the great thing about America and democracy in general: we can disagree with our government and people in power, call them names, and still have every right to stay here. THAT'S what makes America (and Canada, and the UK, and France, and Germany, and...) great. Annoying, ain't it?
> They have also been very conservative with their design (almost dissappointly so).
Well, their goal seems to be to create a wreck diving platform, not to break new records in sub design. If you have a clearly defined and reachable goal, you tend to go about reaching it by the most conservative and reliable means possible in order to minimize financial and safety risks and maximize chances of success. If you want to see a counter-example to conservative design, check out CargoLifter. I used to follow their progress religiously until they went under. Theirs is a case study of heaping speculation and untested technology upon all other kinds of money squandering.
> Intel, the world's largest chip maker
Or perhaps, "Intel, the world's largest chips' maker"? Specializing in plastic cases for the computer inside your computer.
> Also remember that Germans built rather a lot
> of diesel-electric subs over the years
True, but Germans, like most other humans, aren't a hive collective. Which means that the knowledge and skills accumulated by members of a defense contractor don't automatically transfer to the population at large. This is not to say that these guys aren't skilled, because judging from the construction details it certainly seems they know what they're doing. They also have a fair share of engineers amongst themselves.
> It is one thing to depend on a weld that the
> lowest bidder did, it is another to depend on
> one that you did yourself.
They had the pressure hull robot welded and X-ray inspected, resulting in perfect welds, according to their construction info. That's probably better that most homegrown sub efforts. I do wonder just how much money these guys have, though, and whether there's more where that came from.
This new one looks much cheaper and piggier than the SJ30. What's with the cheap NON-REMOVABLE plastic cover that will inevitably break off during the first week? Sorry, but the SJ30 looks much better.
> but the new cards will come in 256MB, 512MB, and 1GB capacities.
And are called MS Pro, and are incompatible with the new handheld, as clearly stated in the article.
> Autopsy leads to prevention
Obviously not in the case of NASA. Autopsy seems to be an end all of its own.
> Figuring out the cause of the problem allows NASA to fix any design or procedural problems
Drumroll please, he got it. Now wouldn't it have been nice to have actual pictures of the wing damage, so that we can reduce the amount of speculation about whether it was the wing or the computer or whatever. No, it wouldn't have saved the shuttle or astronauts, but that's not what we're talking about here at all. As it is we may never know the cause, and chances of deducing anything from any remaining wing shards are pretty slim.
> And that definitely was quality work, and I
> have confidence that this one can be the same.
Yes indeed, autopsy over prevention. Helps every time.
If it wouldn't have helped at all to have visuals of the damage in orbit, why on earth are we spending millions gathering debris to reconstruct what happened? A visual inspection, if it had been possible, could have potentially removed a lot of doubt about what really happened, even if it couldn't have saved the shuttle. It could have also given the astronauts a chance to assess their odds of survival and given them more time to say farewell to their families. Depressing maybe, but certainly pragmatic and humane.
> fills a sorely needed gap
Well, the gap is sorely needed so that this product can then fill it. Unfortunately the gap, since it is sorely needed, doesn't exist.
Will they be any more successful than in their choice of acronym?
> eBook reader
Reader? Uh...sure. Oh, the articles!
No Time To Lose!
No-time Toulouse!
> What I am less thrilled with is their emphasis on storing biometric data and
>trying to get what they see as a huge amount of money being spent on ID cards.
Think of it another way: your wife (and I mean that in the most generic and non-exclusionary way possible) will need a court order to get a peek at your p0rn collection. Ain't that somethin'?
> you'd be surprised what you can do with 50 MIPS and 64k.
> "32-bit" is by far a requirement for most embedded functions.
I assume you meant "32-bit is NOT a requirement". Perhaps not for code, but certainly for data. Do you have any idea how much data is involved in street maps and route calculations? For a trip through a few states you will need megabytes and megabytes of memory for the data, either RAM or at least HD cache. In either case you're not getting anywhere with 64KB combined RAM.
> You can [...] have a network of 10 8051 microcontrollers scattered around the car for under $20.
You are kidding, right? That's the OEM quantity cost of the micro alone. What about the support circuitry, PC board, casing, cabling, hardware design and development cost? This is a very simplistic view. I can tell you that replacing 10 special purpose micro-based computers with one general purpose computer very often IS cheaper, whether you believe it or not. Have you ever had to replace the engine management computer in your car? That's not an x86 in there, that's a humble micro (or a set thereof). Leaving aside consumer markup and all that, even the manufacturer pays more than a couple of of bucks for this unit, since they usually buy it from a third party (Siemens, Bosch etc.) Keep in mind that we're not even talking about replacing the EMC with WinCE here, no-one in their right mind would do that. This is only to illustrate that just because that 8051 costs $5 doesn't mean that that reflects in ANY way on the final cost of the product.
> Neither a GPS nor an MP3 necessarily require an OS.
I think there is some confusion about the purpose of the OS here. The OS won't render street maps or play files. It facilitates low level functions such as allowing both GPS and music player to run on the same hardware at once, it provides the FS and networking code, it (possibly) provides a GUI library, etc. If you don't use an OS, you have to code the task switching and all other services yourself. These particular services are some of the trickiest and most bug-prone types of code there are. Just look at the Linux kernel, which is still maturing in that respect after all these years.
> WinCE just issues commands to the IDE bus which causes the DVD or CD to "play."
> A microcontroller such as the 8051 can do that too.
I'm not sure you understand what goes into reading a file from a CD or HD. You don't just issue a command to a CD drive to "play", drives typically require you to read or write a block of data (typically 512 bytes) at a particular location. You have to read a block into memory and from there send it to the output device, be it an MP3 decoder chip, a software decoder, or any other device. In order to do that, you first have to know where on the disk the file containing the data is, the logical address of the block. In order to do that, you have to walk the FS structures on disk, which are also stored in 512 byte blocks. Drives have no notion of files and directories, they only know blocks. For simple file systems like FAT that can be done with mere KBs (though not if you want to cache the directory and file info in order to display them on-screen for the user to navigate--in that case it all needs to be in RAM, or it will be unbearably slow, especially with a CD or DVD). For more complex ones like NTFS or ext3 it takes more than 512 bytes to walk the FS. That's one of the reasons it's hard to find consumer devices that read anything other than FAT drives. Even FAT32 is rarer because of the long file names and the extra memory required (since a file or directory name can be up to 256 bytes, 64KB of RAM would let you browse only about 256 files in the worst case, though on average probably at least twice that--even though MP3 track names often do tend to get rather long if they include the track number and title).
> Due to the incredibly low cost of microcontrollers,
> this is going to beat a central WinCE system every time
What can I say, just about every car manufacturer out there is proving you wrong on that. Sure, WinCE might not be the best choice, or even a good one; I'm with you on that. But centralized computers are a fact of life--NASA has been using vxWorks to run more than one of their space probes. Do you get bugs? You bet, as they've proven time and again. But you can also fix bugs, as they've also demonstrated live, in transit. Same with BMW: their first release is having bugs, but those bugs will be fixed and hopefully won't occur again in future releases. Maybe it will take switching from WinCE to make things more reliable, but they're certainly not ditching the system architecture.
> An 8051 can do all of that
Perhaps, but it is limited in the total amount of addressable memory, and once you add external memory you get into messy issues of paging and crap like that. It's not a 32-bit processor, after all, and the linear address space isn't that large. That's not to say it is not a great micro, because it is, but it's more meant to be THE computer, rather than just a PART of a computer, like a more general purpose CPU.
> Most of it exists, and that which doesn't, you write. You end up with more reliable code.
According to whom? Experience and statistics would teach you that the more code you write yourself, the more bugs you tend to end up with. One of the great advantages of third party code libraries is that more eyeballs have seen it and it has had more chances to be debugged. Doesn't hold true for all code of course, and it doesn't mean you're not a great programmer because your code has bugs, it's just a matter of statistics.
> Simply the fact that microcontroller-based applications fail less
> frequently than CE-based applications is pretty clear evidence of that.
Yes, but that doesn't have to be due to self-written code. Micro firmware tends to be much more compact and specialized, with fewer software modules having to work together. Simpler software tends to result in higher reliability. But having lots of micros scattered around an automobile also increases the cost and decreases the flexibility: more hardware, more networking required to get the micros talking to each other, only a limited number of ways in which they can interact with each other. Adding new functionality isn't simply a matter of a software upgrade. Consolidating many functions into a single computer is attractive because it can lower costs (especially with off-the-shelf OSs and hardware) and also offers the lure of easy feature upgrades. Whether the latter ends up actually happening or not is another matter, but it might definitely be a selling point during the design phase.
> Agreed, but how much third-party software is available to control the climate in a BMW?
Well, that's not the type of software they'd be looking to reuse, that would definitely be a custom job. But if you also want the same computer to run your GPS and your MP3 player, how would you do it without an OS? You'd have to scrounge for code libraries to do those various things, you'd hope that they use compatible memory management (after all, there's no OS so each library has to do it itself), you hope that you can somehow timeslice them together, etc. Too much nitty gritty that you'd rather not worry about.
> ow much memory and storage and networking is required in a car?
A lot if you want to deal with real file systems such as on CDs and DVDs, store mapping data and updates, and do all sorts of other memory intesive things. That's the thing with micros: an external I2C 64K RAM chip might seem plenty during initial design, but as the inevitable feature bloat proceeds, it becomes more and more limiting. Then you start counting cycles to see if you can squeeze another task into the main state machine loop while still polling the keys often enough, and before you know it you're back in 1986 trying to imitate the Amiga on an 80286, a platform simply not meant for that sort of thing.
> I'd just argue that a car is a perfect example where highly
> specialized hardware and software would be the way to go.
The future will tell. I think that given a proper hardware platform and a proven OS it's quite doable and even desireable. I fully agree that WinCE was a very poor choice, and I'm almost certain that eventually BMW will switch to another OS. I'd bet money that this was a management-driven decision and not initiated by developers. But just look at NASA and space vehicles, which are often fully controlled by just one or very few computers. This gives them the flexibility of debugging and fixing problems long after launch, which would be much harder or impossible if all the various functions were performed by individual bits of silicon. You'll find that most of the spectacular failures occured after switching to new software and/or hardware. In time these bugs are ironed out and the software improves with age.
> Do we really need windows running the windshield wipers?
Well, that's the point--Windows isn't running the wipers, it's still a proprietary piece of code doing it. But on the same CPU there's also another proprietary piece of code that's operating the trunk, and another one maybe the seats, etc. Running all these things together would then either require writing one monolithic app doing all these various things and implementing some time slicing mechanism, or running separate bits of code on an OS that takes care of multitasking. It's not just the multitasking though, it's also making sure to have a thread-safe GUI, having IPC, synchronization, and maybe even some real-time capabilities. All together these various things might be more than a vendor might want to tackle all at once. After all, that's the whole point of general purpose OSs, even real-time ones.
Just as an aside, this area of integrating a lot of services on a single CPU in consumer devices is still fairly new, and there's still a lot of experimentation and shaking out going on. Embedded WinCE is still new and has yet to establish itself--and it may yet very well end up failing to do so. I am puzzled by BMW's choice of WinCE, especially since there are more established choices available, even for multimedia real-time OSs (such as QNX). It's hard to know what economic considerations went into this, or what kind of promises Microsoft made. But if embedded WinCE will turn out to flop, it's not exactly the end of the world for BMW. They can still throw some extra developers at it and switch to another platform without abandoning the hardware. But it will certainly end up costing them money.
> the resulting crash of the radio control system won't corrupt memory
> in the transmission, brake or fuel injector control system
I don't think you'll find any manufacturer seriously considering running mission critical stuff such as tranmission and engine management on the same general purpose computer as the CD player and climate control. They're greey, but they're not stupid. Those functions run on embedded micros inside the respective components, possibly under higher-lever control of an external CPU. So if the CD player software reads a bad block and corrupts memory, it might possibly shift into the wrong gear if they were cheap enough to run the shifting logic on the same computer, but it won't alter the firing sequence of the cylinders. Even in the most integrated scenario you're likely to see at least two main computers broken along two lines, mission critical and creature comfort, with very tightly controlled access to each other. It's ok if the CD player crashes and stops the seat massager or steering wheel warmer from working, but it's not ok if it also shifts the transmission into reverse at 90 mph on the freeway.
> I've developed under Windows CE, Windows, Palm, Unix, and 8052 microcontrollers
> Parts inside washing machines and cars, however, are not going to see such variable usage.
Well, that's where you're wrong. They are trying to squeeze a lot more than a single function out of these embedded machines. For example, the computer in the BMW takes care of the climate control, entertainment system, and lots of other features of the car. It's also running a pretty fancy GUI. You need a fair bit of horsepower for this sort of thing, an 8051 won't do--especially if some of the features (such as music) are done in software. Which of course could still be done via proprietary software even on an ARM or an 80386 or whatever. Except that when you have a lot of fancy functionality that takes a lot of software to implement, you try to reuse as much existing software as possible--you don't want to have to reimplement GUI libraries, networking, storage and memory management, music playing etc. from scratch. Some of this stuff might be available as simple C libraries that you can link into your code without requiring an OS (or as a pseudo-OS where the app and the OS are one single executable image), but not everything. A lot more third party software is available for larger OSs such as WinCE and Linux, and these OSs also provide a lot more native functionality that you don't have to code or buy extra, such as a GUI, networking, memory and storage management etc. In other words, the sort of services your typical OS provides that you tend to take for granted but that are often missing in highly embedded systems.
It's basically a trade-off: you have to make a choice how tightly optimized and minimal you want your system, versus how much effort it will take to implement and extend in the future, versus how easy it will be to find developers to maintain the code later on. For many, a highly specialized hardware and software platform might still be the best choice, while for others a more open OS is preferable.
> Golly! It looks like that particular argument is now dead and gone.
Hardly. As has been mentioned before, some independent industry analysts were actually surprised that the drop in sales was only as much as it was. They did the calculations of new artists signed, albums released, and all the other factors that go into the total sales equation, and estimated sales to be actually less than they ended up being. Some concluded that music sharing might have accounted for that.
> Lets face it, C is not well suited for window environments
.NET is trying to push through), it's better to have the OS and windowing system implemented in a simple non-OO procedural language. It's just a lot easier to invoke a library entry point and pass in state than to invoke an object method with its implied state.
That's very true, but a straight C API is much easier to wrap in an OO framework. OTOH, a C++ API like KDE is a PITA to bind to other languages, both OO and other. Just look at the gyrations Kylix has to go through to bind one OO framework (CLX) to another (Qt). Unless there is one universal OO mechanism (such as
This is not to say that I don't like KDE and Qt. I think Qt is a great example of the benefits of a well designed OO framework. I'm merely pointing out the hassle if you happen to not be a C++ fan.