The software industry is driven by the need to get customers to buy new versions every two years. This means that there has to be something new every two years, and it has to be sufficiently important and different that someone will actually buy a new version because of it. In other industries, the usual practice is to make slight refinements to the technology to improve it. The automotive industry doesn't say, "You already have a car with an internal combustion engine, so we've come up with a new kind of engine." The civil engineers don't say, "We've come up with a new bridge design, so all of the suspension bridges we put up should be replaced." The software industry is totally new every two years, so software it produces is what you'd expect of two-year-old technology.
Of course, this isn't true of all software. Oracle, for instance, basically does what it's always done, with incremental improvements. And Oracle improves with each version. Linux has gotten more stable and efficient over time, at least in those parts which aren't entirely new.
Programmers make a mistake or two for each ten lines of new code. I suspect that this is the same error rate as all engineers have. But engineers in other industries, by and large, produce very little new stuff. If you're designing a bridge, you start with an existing design, and then do all of the changes necessary for the particular site. They make a few mistakes in these changes, they do a bit of testing, they fix all of the problems, and they end up with a perfect result.
Programmers, on the other hand, generate a huge amount of output, such that there are too many errors to expect to find all of them by just looking at the code. This means that later passes have to go through trying to find bugs in an approximate process.
With a proper design, a new feature should require about 10 lines worth of new code, and the programmer should be able to find all of the bugs immediately.
If you go to a movie, your time is worth $-4/hr. Playing arcade games, your time is worth even less. Your time is worth even less if you go to classical music concerts, operas, plays, etc. Writing softare for free is entertainment for you which is much cheaper than most other things people do for fun.
So why don't you charge for it? Do you have fun charging people? I don't think I've ever met someone who actually enjoys the things you have to do to get money from people. Selling software is work, while writing software is fun. Additionally, selling software required infrastructure, and if you set up the infrastructure and then don't sell and software, you lose money.
Writing software is more fun that playing Solitaire. Giving software away has less financial risk than selling it. Distributing software brings more fame and social approval than keeping it for yourself.
People often make the mistake of ignoring the cost of entertainment. If you've ever looked at a budget for entertainment, you'll soon find that OSS programming is a great deal, especially if you needed the computer anyway.
step 2: charge for something that uses the product (weather charts, inventory management, etc) or for something you need to use the software (high-end machines).
IBM did really well on the PC. They sold more of them than anyone at the time believed the whole market to be. It was only several machines later that their secret knowledge in putting together the commodity hardware to make the standard interface got reverse-engineered to the point where the PC because commodity. Unfortunately for them, in the business world, "step 3: profit!" isn't the last step; you have to do it again every few years, and it's been a long time since their original success.
As far as IBM's involvement with OSS, sure, they won't contribute that much to the total corpus of OSS. But IBM can fill in the gaps they care about. Software is always in the state of being just a little bit wrong for what you want (e.g., "I'd love to use it, but I can't stand it if Alt-d doesn't get you to the Location bar..."). IBM wants software which works exactly right in the situations they care about.
All of the reviews I've seen of linux installations by new people have gone: "It worked amazingly smoothly, up until the part where I tried to get {something} working, at which point I got stuck and frustrated. If I just skipped that step, everything was perfect, but I couldn't use my {something}." If IBM can fix this one thing, the OSS solution their consultants sell will work instead of not working. The customer won't pay 99% for a 99% solution, they'll find someone else who can promise a 100% solution. If IBM contributes the last 1% (in the configurations IBM wants to use), they get the customer instead of not getting the customer.
Of course, the benefit of using OSS is that IBM can actually work on the 1% that doesn't work, rather than trying to get their direct competitors to fix it.
He's clearly pulled Maxtor hard drives out of IBM computers and put them into Dells. Remember that thing about IBM building with commodity parts? It's a really good idea if your custom parts sucks...
Writing code on paper is easy. What's hard is creating it out loud. Of course, I have no idea why you'd want to do that (although it's kind of fun).
I know Java, C, and Scheme (and some others). I don't know Python. But I wrote most of the code of a useful utility in Python by looking at existing code. I can't think of anything wrong with doing that. If you're always writing new programs without basing them on anything previously existing, you're just wasting the work that's been done previously at your company.
A senior C developer shouldn't need to write push() and pop() for a linked list. A senior C developer should be able to find versions already in the code base or in a library, or copy the version they usually use. It's a far more relevant test to have someone implement something complicated with a computer (and an explanation of the algorithm, even) than to implement something simple in difficult conditions.
Actually, this was so soon because 1.0 was slow in ways that didn't delay 1.1; 1.0 was mainly a standardization release, which involved committing to the APIs it uses. 1.1 is things that weren't important to have done in 1.0, which were therefore not included so that 1.0 would actually get released.
A) Right, and a century isn't long enough to make it particularly old. It's taken most theories longer to be discovered to be flawed, so the fact that it hasn't been found to be flawed yet doesn't mean all that much.
B) Within it's realm, it holds true nicely. But our universe isn't that realm, because our universe has gravity (and fast-moving particles). So the mere fact that QM prohibits something doesn't mean that it can't happen, just that it would require that something be going on that quantum doesn't cover.
Finding something where the quantum effects and gravitational effects interact in a non-trivial way is highly unlikely. But it wasn't all that long ago when we didn't know of any situations where Newton wasn't exact to the accuracy of our equipment.
A) Just a century? Most of physics which is a good approximation took longer than that to refine.
B) People haven't gotten quantum to deal properly with gravity. There's the pesky problem that quantum fluxuations ought to have an increasing net gravitational pull at smaller scales, which should shred the universe. Obviously, this isn't happening. Obviously, gravity does exist at a larger scale. So quantum isn't complete.
Does this mean that hydrinos are possible? Yes, everything possible. But 6.626e-34 isn't good odds. Of course, if you try everything with any plausibility a little bit, sooner or later one will pay off.
Obviously SuSE noticed your wishes and thought they should get them dealt with right away. In a few days, they'll probably right back to say that their luck has been improved for the next release.
There are multiple reasons not to switch from Windows to commercial Unix. One is that Unix workstations are an order of magnitude more expensive, and the software is similarly expensive. Commercial Unix has never been priced such that you can put a box on every desk in every office.
For that matter, you're not going to have as easy a time giving your workers machines that their consumer hardware (e.g., pilot cradle) plugs into.
People who work for radio stations still listen to regular stereos at their desks, because it doesn't make sense to give everyone the high-end equipment when they don't need it. But if the high-end equipment was free and had jacks for normal headphones and played all of the media that normal people have, they'd probably switch to using it, since it's better and there are people around who know how to manage it.
I think it's great that companies are switching from proprietary UNIX to Linux, because it's an application where they have genreal familiarity with the interface and so forth. Once Linux is a proven technology in their company, they can consider Linux as a replacement for Windows. The places where they are using Windows are places it is not feasible to switch to commercial UNIX. This will give people the opportunity to run the same OS everywhere, since it is not too expensive for the desktop and stable and secure enough for the servers. Once IT is using Linux for the critical systems, they won't want to support Windows as well. Microsoft doesn't lose anything on this deal, but their competition is being replaced with a much tougher competitor.
Furthermore, POS terminals are a market that MS would like to own: the user interface matters and commercial UNIX is impractical (unless the terminals are just thin clients of a single server, which limits the UI possibilities). The fact that companies are chosing Linux as the OS with an interface that's fast, easy to use, and powerful, on cheap hardware, has got to hurt.
Macs last longer than Windows machines, but that's just because new versions of Windows don't run on older machines. Linux, on ther other hand, is perfectly happy running on 7-year-old hardware (like my server, for instance). I haven't seen any PowerMacs lately, although they may still be in use. Is there even a version of OS X for pre-G3 hardware?
.NET isn't much better-- in general, it won't be declared to be safe anyway.
In any case, sandboxing depends on dynamic checks of safety, with static checks as a set of optimizations. Static checks will substantially improve performance, when you can do then, but you can't avoid doing some dynamic checks (index out of bounds, e.g.). x86 will just require more.
And sandboxing isn't the only purpose of a VM; another is portability. Being cross-language sort of prevents you from doing all that much in the way of static checks, for that matter, because C permits arbitrarily complex pointer arithmatic, and guarentees that, provided you end up with valid address at the end, you can dereference it, regardless of whether what you did is generally safe.
Clean-room reverse-engineering is not possible against a patent, because everyone is presumed to have read patents. That's why the word is derived from the Latin for "well-known" or "open". The point is that you tell the world how something works in exchange for a temporary monopoly on implementing it.
.NET doesn't actually do any better than Java at being cross-language; as far as I know, no language (other than C#) has been fully implemented with.NET. You could, of course, restrict yourself to using the parts of your favorite language which are supported by the.NET implementation, but then you might as well use C#..NET isn't cross-language; it is merely cross-syntax. On the other hand, Java (bytecode) isn't any more cross-language. But it's not supposed to be. A far better cross-platform, cross-language VM is actually x86 machine language, which is available on several platforms as a VM (including a cross-processor linux implementation), as well as several direct implementations and microcode implementations, and which permits effective implementation of essentially all programming languages.
You can copy DVDs trivially if you have a DVD burner. What do DVD burners burn? DVD images. What do you read off of a DVD? DVD images. This was demonstrated during the DeCSS trial: they made a copy of an encrypted DVD.
As for a DVD->VHS unit, what's the point? Why would you want a VHS tape if you had a DVD, unless you didn't have a DVD player? And if you didn't have a DVD player, you'd buy a DVD player, not a DVD->VHS converter to use with your VHS player. Of course, you could be making illegal copies for people who don't have DVD players. But in that case, why wouldn't you either tell them to get DVD players and copy the DVD without decrypting it, or get a VHS version and copy that?
These devices don't exist because they're not commercially viable, not because of the DMCA. The only thing that the DMCA does with respect to DVDs is prohibit people from watching them without using a licensed player. And the only licensed players would theoretically be ones that don't let you play copies, aren't region-free, etc. But, of course, there are region-free players, players that will play copies, and so forth, properly licensed and not prohibited by the DMCA.
OpenBSD is older than your old Pentium, and it can still do everything it used to be able to do. It probably won't run Gnome or KDE, but it's more than enough to be a multi-user login server, mail server, web server, and run X. If you want to do anything involving really large data at the same time, though, you might want to have swap.
As far as I can tell, they haven't been applied in the development series because that series is focusing on other things like the various I/O parts. Making any changes to the VM system while the I/O layer is in flux is sure to cause problems, even if the changes are correct, because they'll change the load on it and hide some bugs and uncover different ones. Better to get I/O done first, and then change the VM. Besides, nobody really cares about the overall performance of a development kernel, except for seeing that their changes improve performance.
The titanium strip was just sitting on the runway, having fallen off the other plane. Of course, the plane was presumably going pretty fast at the time, but airplane tires should be able to withstand this sort of thing, or at least fail somewhat more gracefully.
On the other hand, the failure in this case required 2 failures on the Concorde and bad luck with the fire, as well as hitting something that shouldn't have been there. There's a reason it took as long as it did for a Concorde to crash. I'm not sure exactly why this is in the list: in the other cases, the problem was that the makers were over-confident. The Concorde was supposed to be nearly indestructible, and it turned out that it could be destroyed once in a million times. So they fixed both of the things which contributed to that time. It's not the sort of thing you could say was just waiting to happen, or that you could say they should have found in simulation or testing.
At this point, you're going to have to invest a substantial amount in retraining, regardless of what you do, because different versions of windows don't work the same way. In '95 I switched from windows 3.1 to Linux. It took me some time to get used to Linux. But everything I learned at that point still works.
With my knowledge of Windows 3.1, I couldn't figure out anything at all about Windows 95, let alone anything more recent. Had I taken the time to learn Windows 95, I would have had little advantage in learning 2K, let alone XP. Furthermore, there's so much fragmentation in windows software that, when I was using Word at one point, experienced people using the same version on a different computer couldn't explain how to do things.
Cost of retraining is a significant factor, and you shouldn't do it until you have to. But sticking with MicroSoft doesn't reduce the cost, and it means that you'll get hit with it again in 2-3 years.
Changing modes for a single assembly block is not going to work. All of your data is in IA-64 registers, the processor pipeline is filled with IA-64 instructions, and so forth. Switching is a major slowdown (might as well be another process), and the point of having sections in assembly is to speed up critical sections.
In any case, what makes it difficult to write an IA-64 compiler is taking advantage of the things that the new instruction set lets you tell the processor. It's not hard to write code for the IA64 that's as good as some code for the i386. It's just that you won't get the benefits of the new architecture until you write better code, and the processors aren't optimized for running code that doesn't take advantage of the architecture.
In general, it is wrong to assume that anything will comply to standards. "Be strict in what you produce and permissive in what you accept." Now it would be different if, for instance, these discs would cause physical harm to the mechanism directly (i.e., they would melt or reflect the laser in odd directions, or something). But it should be impossible for a disc with pits merely in an invalid configuration to damage the drive.
Of course, it would be fine for the drive to not play these discs. Since they're invalid, there's no reason they should work. But they shouldn't be able to damage the drive or the computer. I bet the car cd players don't make the car swerve wildly. And, if they did, I'm blame the car manufacturers more than the disc manufacturers.
Okay, so you have some software which is vulnerable to malformed data which has been fed to it by an unsuspecting user, and it causes damage to your system. Rather than providing fixes, the vendor blames the users and the source of the malformed data. Apple's CD drives have a major security hole. It is being exploited by malicious hackers, who have produced attacks which lure people into subjecting their computers to them by promising to contain music.
Sure, people shouldn't buy these things. Sure, the people who make them should be treated as the computer criminals they are. Sure, Celine Dion should remind people of Melissa. But Apple should really fix these things. Computers that won't work if the CD drive gets messed up? CD drives that trust discs to have valid data, and can be permanently damaged by discs with data errors? I certainly hope their network cards aren't so lousy...
Slashdot Mirror
The software industry is driven by the need to get customers to buy new versions every two years. This means that there has to be something new every two years, and it has to be sufficiently important and different that someone will actually buy a new version because of it. In other industries, the usual practice is to make slight refinements to the technology to improve it. The automotive industry doesn't say, "You already have a car with an internal combustion engine, so we've come up with a new kind of engine." The civil engineers don't say, "We've come up with a new bridge design, so all of the suspension bridges we put up should be replaced." The software industry is totally new every two years, so software it produces is what you'd expect of two-year-old technology.
Of course, this isn't true of all software. Oracle, for instance, basically does what it's always done, with incremental improvements. And Oracle improves with each version. Linux has gotten more stable and efficient over time, at least in those parts which aren't entirely new.
Programmers make a mistake or two for each ten lines of new code. I suspect that this is the same error rate as all engineers have. But engineers in other industries, by and large, produce very little new stuff. If you're designing a bridge, you start with an existing design, and then do all of the changes necessary for the particular site. They make a few mistakes in these changes, they do a bit of testing, they fix all of the problems, and they end up with a perfect result.
Programmers, on the other hand, generate a huge amount of output, such that there are too many errors to expect to find all of them by just looking at the code. This means that later passes have to go through trying to find bugs in an approximate process.
With a proper design, a new feature should require about 10 lines worth of new code, and the programmer should be able to find all of the bugs immediately.
If you go to a movie, your time is worth $-4/hr. Playing arcade games, your time is worth even less. Your time is worth even less if you go to classical music concerts, operas, plays, etc. Writing softare for free is entertainment for you which is much cheaper than most other things people do for fun.
So why don't you charge for it? Do you have fun charging people? I don't think I've ever met someone who actually enjoys the things you have to do to get money from people. Selling software is work, while writing software is fun. Additionally, selling software required infrastructure, and if you set up the infrastructure and then don't sell and software, you lose money.
Writing software is more fun that playing Solitaire. Giving software away has less financial risk than selling it. Distributing software brings more fame and social approval than keeping it for yourself.
People often make the mistake of ignoring the cost of entertainment. If you've ever looked at a budget for entertainment, you'll soon find that OSS programming is a great deal, especially if you needed the computer anyway.
step 2: charge for something that uses the product (weather charts, inventory management, etc) or for something you need to use the software (high-end machines).
IBM did really well on the PC. They sold more of them than anyone at the time believed the whole market to be. It was only several machines later that their secret knowledge in putting together the commodity hardware to make the standard interface got reverse-engineered to the point where the PC because commodity. Unfortunately for them, in the business world, "step 3: profit!" isn't the last step; you have to do it again every few years, and it's been a long time since their original success.
As far as IBM's involvement with OSS, sure, they won't contribute that much to the total corpus of OSS. But IBM can fill in the gaps they care about. Software is always in the state of being just a little bit wrong for what you want (e.g., "I'd love to use it, but I can't stand it if Alt-d doesn't get you to the Location bar..."). IBM wants software which works exactly right in the situations they care about.
All of the reviews I've seen of linux installations by new people have gone: "It worked amazingly smoothly, up until the part where I tried to get {something} working, at which point I got stuck and frustrated. If I just skipped that step, everything was perfect, but I couldn't use my {something}." If IBM can fix this one thing, the OSS solution their consultants sell will work instead of not working. The customer won't pay 99% for a 99% solution, they'll find someone else who can promise a 100% solution. If IBM contributes the last 1% (in the configurations IBM wants to use), they get the customer instead of not getting the customer.
Of course, the benefit of using OSS is that IBM can actually work on the 1% that doesn't work, rather than trying to get their direct competitors to fix it.
He's clearly pulled Maxtor hard drives out of IBM computers and put them into Dells. Remember that thing about IBM building with commodity parts? It's a really good idea if your custom parts sucks...
Writing code on paper is easy. What's hard is creating it out loud. Of course, I have no idea why you'd want to do that (although it's kind of fun).
I know Java, C, and Scheme (and some others). I don't know Python. But I wrote most of the code of a useful utility in Python by looking at existing code. I can't think of anything wrong with doing that. If you're always writing new programs without basing them on anything previously existing, you're just wasting the work that's been done previously at your company.
A senior C developer shouldn't need to write push() and pop() for a linked list. A senior C developer should be able to find versions already in the code base or in a library, or copy the version they usually use. It's a far more relevant test to have someone implement something complicated with a computer (and an explanation of the algorithm, even) than to implement something simple in difficult conditions.
How would you know they'd fixed IE if they didn't distribute a virus that no longer worked?
Actually, this was so soon because 1.0 was slow in ways that didn't delay 1.1; 1.0 was mainly a standardization release, which involved committing to the APIs it uses. 1.1 is things that weren't important to have done in 1.0, which were therefore not included so that 1.0 would actually get released.
A) Right, and a century isn't long enough to make it particularly old. It's taken most theories longer to be discovered to be flawed, so the fact that it hasn't been found to be flawed yet doesn't mean all that much.
B) Within it's realm, it holds true nicely. But our universe isn't that realm, because our universe has gravity (and fast-moving particles). So the mere fact that QM prohibits something doesn't mean that it can't happen, just that it would require that something be going on that quantum doesn't cover.
Finding something where the quantum effects and gravitational effects interact in a non-trivial way is highly unlikely. But it wasn't all that long ago when we didn't know of any situations where Newton wasn't exact to the accuracy of our equipment.
A) Just a century? Most of physics which is a good approximation took longer than that to refine.
B) People haven't gotten quantum to deal properly with gravity. There's the pesky problem that quantum fluxuations ought to have an increasing net gravitational pull at smaller scales, which should shred the universe. Obviously, this isn't happening. Obviously, gravity does exist at a larger scale. So quantum isn't complete.
Does this mean that hydrinos are possible? Yes, everything possible. But 6.626e-34 isn't good odds. Of course, if you try everything with any plausibility a little bit, sooner or later one will pay off.
Obviously SuSE noticed your wishes and thought they should get them dealt with right away. In a few days, they'll probably right back to say that their luck has been improved for the next release.
There are multiple reasons not to switch from Windows to commercial Unix. One is that Unix workstations are an order of magnitude more expensive, and the software is similarly expensive. Commercial Unix has never been priced such that you can put a box on every desk in every office.
For that matter, you're not going to have as easy a time giving your workers machines that their consumer hardware (e.g., pilot cradle) plugs into.
People who work for radio stations still listen to regular stereos at their desks, because it doesn't make sense to give everyone the high-end equipment when they don't need it. But if the high-end equipment was free and had jacks for normal headphones and played all of the media that normal people have, they'd probably switch to using it, since it's better and there are people around who know how to manage it.
I have heard that Windows cash registers exist. I have no evidence that anyone likes them. That's how I know that MS wants the market.
I think it's great that companies are switching from proprietary UNIX to Linux, because it's an application where they have genreal familiarity with the interface and so forth. Once Linux is a proven technology in their company, they can consider Linux as a replacement for Windows. The places where they are using Windows are places it is not feasible to switch to commercial UNIX. This will give people the opportunity to run the same OS everywhere, since it is not too expensive for the desktop and stable and secure enough for the servers. Once IT is using Linux for the critical systems, they won't want to support Windows as well. Microsoft doesn't lose anything on this deal, but their competition is being replaced with a much tougher competitor.
Furthermore, POS terminals are a market that MS would like to own: the user interface matters and commercial UNIX is impractical (unless the terminals are just thin clients of a single server, which limits the UI possibilities). The fact that companies are chosing Linux as the OS with an interface that's fast, easy to use, and powerful, on cheap hardware, has got to hurt.
Macs last longer than Windows machines, but that's just because new versions of Windows don't run on older machines. Linux, on ther other hand, is perfectly happy running on 7-year-old hardware (like my server, for instance). I haven't seen any PowerMacs lately, although they may still be in use. Is there even a version of OS X for pre-G3 hardware?
.NET isn't much better-- in general, it won't be declared to be safe anyway.
In any case, sandboxing depends on dynamic checks of safety, with static checks as a set of optimizations. Static checks will substantially improve performance, when you can do then, but you can't avoid doing some dynamic checks (index out of bounds, e.g.). x86 will just require more.
And sandboxing isn't the only purpose of a VM; another is portability. Being cross-language sort of prevents you from doing all that much in the way of static checks, for that matter, because C permits arbitrarily complex pointer arithmatic, and guarentees that, provided you end up with valid address at the end, you can dereference it, regardless of whether what you did is generally safe.
Clean-room reverse-engineering is not possible against a patent, because everyone is presumed to have read patents. That's why the word is derived from the Latin for "well-known" or "open". The point is that you tell the world how something works in exchange for a temporary monopoly on implementing it.
.NET. You could, of course, restrict yourself to using the parts of your favorite language which are supported by the .NET implementation, but then you might as well use C#. .NET isn't cross-language; it is merely cross-syntax. On the other hand, Java (bytecode) isn't any more cross-language. But it's not supposed to be. A far better cross-platform, cross-language VM is actually x86 machine language, which is available on several platforms as a VM (including a cross-processor linux implementation), as well as several direct implementations and microcode implementations, and which permits effective implementation of essentially all programming languages.
.NET doesn't actually do any better than Java at being cross-language; as far as I know, no language (other than C#) has been fully implemented with
You can copy DVDs trivially if you have a DVD burner. What do DVD burners burn? DVD images. What do you read off of a DVD? DVD images. This was demonstrated during the DeCSS trial: they made a copy of an encrypted DVD.
As for a DVD->VHS unit, what's the point? Why would you want a VHS tape if you had a DVD, unless you didn't have a DVD player? And if you didn't have a DVD player, you'd buy a DVD player, not a DVD->VHS converter to use with your VHS player. Of course, you could be making illegal copies for people who don't have DVD players. But in that case, why wouldn't you either tell them to get DVD players and copy the DVD without decrypting it, or get a VHS version and copy that?
These devices don't exist because they're not commercially viable, not because of the DMCA. The only thing that the DMCA does with respect to DVDs is prohibit people from watching them without using a licensed player. And the only licensed players would theoretically be ones that don't let you play copies, aren't region-free, etc. But, of course, there are region-free players, players that will play copies, and so forth, properly licensed and not prohibited by the DMCA.
OpenBSD is older than your old Pentium, and it can still do everything it used to be able to do. It probably won't run Gnome or KDE, but it's more than enough to be a multi-user login server, mail server, web server, and run X. If you want to do anything involving really large data at the same time, though, you might want to have swap.
As far as I can tell, they haven't been applied in the development series because that series is focusing on other things like the various I/O parts. Making any changes to the VM system while the I/O layer is in flux is sure to cause problems, even if the changes are correct, because they'll change the load on it and hide some bugs and uncover different ones. Better to get I/O done first, and then change the VM. Besides, nobody really cares about the overall performance of a development kernel, except for seeing that their changes improve performance.
The titanium strip was just sitting on the runway, having fallen off the other plane. Of course, the plane was presumably going pretty fast at the time, but airplane tires should be able to withstand this sort of thing, or at least fail somewhat more gracefully.
On the other hand, the failure in this case required 2 failures on the Concorde and bad luck with the fire, as well as hitting something that shouldn't have been there. There's a reason it took as long as it did for a Concorde to crash. I'm not sure exactly why this is in the list: in the other cases, the problem was that the makers were over-confident. The Concorde was supposed to be nearly indestructible, and it turned out that it could be destroyed once in a million times. So they fixed both of the things which contributed to that time. It's not the sort of thing you could say was just waiting to happen, or that you could say they should have found in simulation or testing.
At this point, you're going to have to invest a substantial amount in retraining, regardless of what you do, because different versions of windows don't work the same way. In '95 I switched from windows 3.1 to Linux. It took me some time to get used to Linux. But everything I learned at that point still works.
With my knowledge of Windows 3.1, I couldn't figure out anything at all about Windows 95, let alone anything more recent. Had I taken the time to learn Windows 95, I would have had little advantage in learning 2K, let alone XP. Furthermore, there's so much fragmentation in windows software that, when I was using Word at one point, experienced people using the same version on a different computer couldn't explain how to do things.
Cost of retraining is a significant factor, and you shouldn't do it until you have to. But sticking with MicroSoft doesn't reduce the cost, and it means that you'll get hit with it again in 2-3 years.
Changing modes for a single assembly block is not going to work. All of your data is in IA-64 registers, the processor pipeline is filled with IA-64 instructions, and so forth. Switching is a major slowdown (might as well be another process), and the point of having sections in assembly is to speed up critical sections.
In any case, what makes it difficult to write an IA-64 compiler is taking advantage of the things that the new instruction set lets you tell the processor. It's not hard to write code for the IA64 that's as good as some code for the i386. It's just that you won't get the benefits of the new architecture until you write better code, and the processors aren't optimized for running code that doesn't take advantage of the architecture.
In general, it is wrong to assume that anything will comply to standards. "Be strict in what you produce and permissive in what you accept." Now it would be different if, for instance, these discs would cause physical harm to the mechanism directly (i.e., they would melt or reflect the laser in odd directions, or something). But it should be impossible for a disc with pits merely in an invalid configuration to damage the drive.
Of course, it would be fine for the drive to not play these discs. Since they're invalid, there's no reason they should work. But they shouldn't be able to damage the drive or the computer. I bet the car cd players don't make the car swerve wildly. And, if they did, I'm blame the car manufacturers more than the disc manufacturers.
Okay, so you have some software which is vulnerable to malformed data which has been fed to it by an unsuspecting user, and it causes damage to your system. Rather than providing fixes, the vendor blames the users and the source of the malformed data. Apple's CD drives have a major security hole. It is being exploited by malicious hackers, who have produced attacks which lure people into subjecting their computers to them by promising to contain music.
Sure, people shouldn't buy these things. Sure, the people who make them should be treated as the computer criminals they are. Sure, Celine Dion should remind people of Melissa. But Apple should really fix these things. Computers that won't work if the CD drive gets messed up? CD drives that trust discs to have valid data, and can be permanently damaged by discs with data errors? I certainly hope their network cards aren't so lousy...