My understanding of U.S. tax law, is just about anything is preferable to returning revenues from foreign sources home and showing a profit. The result is that you want to make sure you don't make money on international operations (at least money that is bookable as profit in the U.S.) The quickest way to do that is to ensure that the international operations don't make any money. Have lots of revenue, but no profit coming back to the U.S.
Now, Microsoft is a U.S. corporation. It needs U.S. profits. The best solution is to make 100% of the U.S. revenue U.S. profits, which can be then buried under other U.S. tax dodges. You do this by lowering your U.S. expenses, and moving as many expenses as possible oversees.
Walmart does this quite well. The revenues are inside the U.S. for sales, and the expenses are oversees (in China.) If you look at the Walmart Canada operations, you will likely find that they spend as much money as legally acceptable on all sorts of expenses (like goods from China and expansion). The result is no money is actually returned to the U.S. In the process, the company grows and money is returned to the U.S. via shareholder equity, and increased profits from the U.S. division based on U.S. revenues (because the Canadian division has subsidized the U.S. divisions expenses).
Microsoft is doing the same thing, and Microsoft's big expense is software developers. Microsoft is opening software development groups in Canada, and around the world. If Microsoft senses even the vague chance of $100 billion in revenues from China, it would represent a tripling of its world-wide revenues (currently at $44 billion.) As such, huge amounts of expenses would need to be off-shored. This would allow large sections of the U.S. revenue to become complete profit, permitting profits to triple from $10 billion (current) to $30 billion. in the process, huge new foreign development houses would need to be opened, and Microsoft software development moved oversees.
The reasons why software development is moving from the U.S. to India and from the U.S. to China are more complex than just cheap labor. U.S. tax law is one of the reasons why. The result is Microsoft, Intel, and Google have all invested heavily in India and China operations. Some would argue at the expense of U.S. workers.
There is no way Microsoft is ever going to get $100 billion out of China. If the Chinese don't choke on that concept, U.S. tax law will.
Microsoft will open divisions in China, slowly "localize" software development, and quietly move to China. It might not be official policy, but most of that money will never leave China.
To do otherwise exposes Microsoft to a) the possibility of a local Chinese competitor, and b) a massive tax bill on the $100 billion in profits.
I think you are missing the point that the laser safety regulations are busily being modified to include LED light sources. LED's, while non-coherent, can be focused sufficiently to create similar effects. It is all about how much light energy is hitting a person's retina. The effect can be created with any light source of sufficient intensity. Both a very bright focused LED and a laser can (temporarily) blind people.
Microsoft software does not have bugs. They have "undocumented features". It is a feature that Internet Explorer 7 works this way. When properly embraced, it extends the operating system with new features, and extinguishes all problems.
Microsoft selling Windows Legacy looks suspiciously similar Coke selling Coke Classic. Tell everyone they like "New Coke", realize the don't, and start selling "Coke Classic". Tell everyone they like "Vista", realize they don't, and then sell "Windows Legacy."
I am already bracing myself for the "Windows 7 the operating system that was supposed to ship in 2007" jokes. Microsoft picking Windows 7 as a product name in 2007 appears unfortunate.
These physicists always say they are searching for God or "the God Particle". But what happens if they switch the big God Particle generator on, and God suddenly appears? What if we really do find God?
What are all these geeky physicists going to do then? Do we really want to find God? Do we really want physicists finding God? Is this a good thing?
My understanding was that the first computer viruses were penned at Bell Labs in a series of experiments called the "Core Wars". The goal was to eliminate as many enemy tasks as possible while keeping your tasks running. Byte has an article on the subject in the 1980's. Of course, at the time, disk media were in limited supply. This made spreading away from the test mainframe next to impossible.
The 8080A did not feature segments. Segments were created in the 8086/8088 design. The 8080A had 8 8-bit registers organized as 4 16-bit registers. It also had the condition code register, and a slew of jump and branch instructions. Ever wondered where the BL/BH=BX thing came from? That was a variant of the 8080A's B and C registers combining to form the BC register. It turns out that many of the key condition codes, arithmetic, branch, jump, and index instructions came from the 8080A. Other than register renaming, and expanding many instructions to longer data words, we are still using many of the same instructions that were in use on the 8080A. Assembly programming really hasn't changed much over the years.
Of course, the new processors have many new instructions. New addressing modes for the old instructions have been added over the years. It is just interesting that the old core instructions are still around in a fairly similar form. These old instructions make up a surprisingly large fraction of the compiled code generated by todays compilers. It just goes to show: software compatibility pays.
The teacher did not understand computers at all. She was expressly told not to turn it off. It appears it was an out-of-date Windows 98 PC infected with spyware and with expired anti-virus software. The schools firewalls were ineffective. (They probably had expired filter software too.)
The teacher was told to do some simple activity with the computer and show it to her class. With the malware, you can guess what happened next...
IBM made a decision in 1980 to go with the Intel 8088 (8/16 bit) processor instead of the Motorola 68000 (16/32 bit) processor. At the time, the Motorola processor was designed to be the processor of the future. On the other hand, the 8088 was intended to be almost compatible with 8080A assembly code. This created the need for the 8088 segmented architecture, and segments suck.
The use of segment registers set PC development back over a decade. Essentially, all the 80's was spent fighting segmentation wars. The IBM PC didn't get proper 32-bit computing until the widespread popularity of 386 PC hardware in about 1992, and the subsequent introduction of Windows 95. Windows XP was the first unified 32-bit Microsoft O/S in 2001. DOS mode was finally eliminated in Windows Vista in 2007!!! I think you had to live through segmentation and far pointers to understand how incredibly awful they were.
Interestingly, the Apple Mac had a 68000 processor in 1984. If that caught on, then it would have saved the PC industry a decade of pain. Apple made the decision not to license the operating system for the Apple Mac. The result was Apple hardware was expensive, so few purchased it. The problem was so severe that Apple almost went bankrupt before Steve Jobs returned.
IBM built Microsoft and Intel when they created the IBM PC. Apple rested on the laurels of a better architecture and almost went bankrupt. These two decisions defined at least 15 years of software history. It isn't until know where we see a few different pure 32-bit operating systems fighting it out on a common hardware platform. The Windows XP, Vista, OS/X, Linux battles will be interesting. The 32/64 bit battles will take place on PC hardware that is still almost completely assembly language compatible with the first widely used 8-bit Intel Microprocessor: the 8080A!
The other variant on your story is if a preferred customer installs a newer version of Office. Then someone at your company needs the new version of Office to read the incoming e-mails, and the slippery slope starts...
Wow!!! It's shocking to read the comments above. There is no sympathy whatsoever for the average user, who has little technical knowledge, or for companies with IT departments that get caught in the abuse.
Of course, I could not fully remove the "trial" version of Office-2003. Once Office-2003 has been installed, it can not overwritten with an earlier version of Office. Also, you cannot remove Office-2003 and re-install Office-2000, unless you know how to hack the registry.
Not true at all. Just go to add/remove programs and uninstall your trial software, then reinstall your old software. If you can't uninstall software, then your PC is very messed up, which has nothing to do with outlook.
My experience was this: I had a new PC with Office 2003 trial, and wanted to use my old version of Office to begin with. As such, I installed my earlier version of Office. The two programs would not coexist well at all. Office 2003 consistently annoyed me with unexpected attempts to start up.
As far as I could figure out, Office 2003 maps registry keys that earlier versions of Office 2000 do not. The result is that you can't effectively have Office 2003 and an earlier version of Office on the same PC, with the earlier version having preference. Every so often, the new version of Office would be started via one of the new registry keys, and there was nothing I could do to stop it. I even refused to click Agree on th EULA, and Excel 2003 eventually decided to run anyway.
The solution was to uninstall both Office 2003 and the earlier version of Office, and then reinstall the desired version of Office. Currently, I just uninstall the trial versions of Office immediately, and do not allow them to run even once. This seems to work fairly well.
The original poster was essentially correct. If you do not know enough to uninstall all versions of Office, and then install the desired version, then you will have problems. If you try to "manually correct" things, you will probably wind up reinstalling Windows XP. Myself, I think if you want to have multiple versions of Office on the same PC, you probably want to install virtualization software like VMWware.
To this date, I still have not deliberately used Office 2003 or agreed to its EULA, and I haven't missed it either.
My take on C++ is that the best programs only use a fraction of the features. The language is so big it is dangerous. Just because a feature exists in the language, does not mean it is good for every application. I am very wary of operator overloading and templates too. You need to make your code sufficiently clear that you can be sure it works. if you cannot quickly understand your code, then chances are you made a mistake.
Many pieces of old code aren't pretty for a fairly defined set of reasons:
1. a) Debugging Ensure you actually have an appropriate way of debugging the code. The systems I work with are embedded and run 7x24. People will say: it failed last week on Wednesday at 3:00 A.M., we got it working, but can you fix the problem? The problem may not actually be your code, it could be another piece of equipment. In any case, you need to figure this out from the logs. In my experience, many "pretty" programs are too small to justify extensive logging. After logging is included, the programs become less "pretty" but much more maintainable.
1. b) Refactoring after Debug Sometimes the results of the debug will show a major design error in the program. You now need to implement a major architectural change that really was not originally intended. You have good modular code when it can withstand these major design changes in a relatively smooth manner.
2. Failure to handle common areas of problems well These include:
2. a) Strings Does your program have the ability to smoothly handle unicode/UTF/HTML/locale specific strings? Every different language you port your application too, and every different program you talk with, will all have differing definitions of what is a string. My favorite test case is CNC (Computer Numerically Controlled) machinery. Some CNC machines expect embedded nulls inside the strings. The embedded null requirement affects a surprisingly large number of string libraries.
2. b) MessageBox() Invariably in a big program it will be unacceptable to allow it to hang on a modal dialog box like MessageBox(). How are you going to handle it? What if a library call executes a modal dialog box?
2. c) Handling Exceptions For a simple prototype program, handling exceptions is not a big deal. In a production application, all the exceptions must be handled appropriately and the program must be able to continue when exceptions occur. The error handling code often exceeds the size of the original program.
2. d) Third Party Libraries / Operating Systems (Windows) The amount of code devoted to covering up mistakes in other code is amazing. Unfortunately, unless coding on an open platform, one must accept the costs of the additional code. When starting a new project, I recommend thoroughly stress testing any new libraries that will be used. Thus one can find the killer bugs that significantly affect design decisions.
I would appreciate any feedback/additions to the items on this list.
Unfortunately, this technology is very likely to be misused by uninformed people in the legal profession. The example of the school teacher accused of spreading porn come to mind. http://arstechnica.com/news.ars/post/20070214-8850 .html
Some prosecutors are likely to take the evidence from Vista as proving a person did something very bad. The evidence only the computer did something very bad. A rogue third party could have hijacked the computer and planted the data there. With current spyware and adware, the attack may simply be an effort to drive traffic to certain websites. Having a school teacher's career destroyed is just a side-effect of a rogue third party trying to make money.
Reliability analysis is used to quantify failure rates. It is poor practice to use logic to analyze either a computer program or a safety system. Logic can only reveal the obvious flaws in the system. Logic does not help us to quantify the impact or severity of the flaw. Logic assumes things "always" happen. Real-life does not "always" happen as intended. Mechanical systems are never "always" consistent. Computers aren't "always" consistent either. Users have a big impact on problem severity.
We have 100+ years of history designing mechanical systems for applications were they almost "always" work. This gives us ample data to quantify likely failure modes. These failure modes can then be analyzed and prevented by other safety measures.
In the case of safety systems, layer upon layer of checks are present. The concept is that even if something fails, or comes close to failing, it will be picked up by another check. Quantifying the performance of a safety system is not about logic, it is about reliability analysis. How many failures are likely to happen? and how many failures does it take before something dangerous happens?
One report on 3 mile island listed separate 114 (?) failures that ultimately resulted in the core meltdown. How unlikely is this? Mathematics tells us that unlikely events happen all the time. Every day someone wins the lottery. How unlikely is a nuclear accident to occur? That question is answered by reliability analysis, and it is a complex field including both statistical techniques and logic.
How likely is it that something bad will occur as a result of this Java bug? It turns out that the computers (and their users) would have to make thousands of poor decisions before suffering adverse effects from this bug. Unfortunately, millions of computers exist, each making millions of decisions per second, so some people will probably be affected. Quantifying the severity of the problem is a difficult reliability analysis problem.
I think the days of using Microsoft software in a production-related, mission-critical, soft real-time environment are soon to be over. Essentially, the applications always require some custom written software that calls a large number of Microsoft API's, often in a poorly understood and undocumented manner. Worse, the applications tend to use Microsoft software in unexpected or undocumented ways. Microsoft designs Microsoft Windows and Vista for the average desktop user. Real-time applications tend to be much more demanding than the average desktop user. Response time, up-time and reliability are critical. Every Microsoft patch and virus scanner update potentially disrupts the real-time application directly through disk accesses and reboots, and indirectly by changing the underlying Microsoft API's.
This is the era of hospital computer networks being infected by bot-nets. We can neither blindly deploy patches, nor can we safely do without. The critical soft real-time applications are going to have to be migrated away from Microsoft Windows. It might take some time, but I don't really see any alternatives.
Has anyone else noticed that the speed of Windows XP is actually dropping, or at least does not monotonically increasing? All of the patches and virus scanning are affecting system performance, and the performance drop is significant for some of my applications.
The complaint is fairly devastating. Going by the complaint, the RIAA repeatedly refused to limit the damages their actions were causing or could reasonably expected to cause. It isn't wise to sue a highly sympathetic person without fair cause. You tend to loose at trial.
Slashdot Mirror
My understanding of U.S. tax law, is just about anything is preferable to returning revenues from foreign sources home and showing a profit. The result is that you want to make sure you don't make money on international operations (at least money that is bookable as profit in the U.S.) The quickest way to do that is to ensure that the international operations don't make any money. Have lots of revenue, but no profit coming back to the U.S.
Now, Microsoft is a U.S. corporation. It needs U.S. profits. The best solution is to make 100% of the U.S. revenue U.S. profits, which can be then buried under other U.S. tax dodges. You do this by lowering your U.S. expenses, and moving as many expenses as possible oversees.
Walmart does this quite well. The revenues are inside the U.S. for sales, and the expenses are oversees (in China.) If you look at the Walmart Canada operations, you will likely find that they spend as much money as legally acceptable on all sorts of expenses (like goods from China and expansion). The result is no money is actually returned to the U.S. In the process, the company grows and money is returned to the U.S. via shareholder equity, and increased profits from the U.S. division based on U.S. revenues (because the Canadian division has subsidized the U.S. divisions expenses).
Microsoft is doing the same thing, and Microsoft's big expense is software developers. Microsoft is opening software development groups in Canada, and around the world. If Microsoft senses even the vague chance of $100 billion in revenues from China, it would represent a tripling of its world-wide revenues (currently at $44 billion.) As such, huge amounts of expenses would need to be off-shored. This would allow large sections of the U.S. revenue to become complete profit, permitting profits to triple from $10 billion (current) to $30 billion. in the process, huge new foreign development houses would need to be opened, and Microsoft software development moved oversees.
The reasons why software development is moving from the U.S. to India and from the U.S. to China are more complex than just cheap labor. U.S. tax law is one of the reasons why. The result is Microsoft, Intel, and Google have all invested heavily in India and China operations. Some would argue at the expense of U.S. workers.
There is no way Microsoft is ever going to get $100 billion out of China. If the Chinese don't choke on that concept, U.S. tax law will.
Microsoft will open divisions in China, slowly "localize" software development, and quietly move to China. It might not be official policy, but most of that money will never leave China.
To do otherwise exposes Microsoft to a) the possibility of a local Chinese competitor, and b) a massive tax bill on the $100 billion in profits.
Any chance MSCD has a Microsoft API? Microsoft loves those extentions. Maybe MSCD can be made to do BitTorrent too ...
The reward offered was $500 for the recovery of the backup tape.
$500 / 800,000 = $0.000625 = 0.0625 cents
Just checking to find out what my identity is worth ...
I think you are missing the point that the laser safety regulations are busily being modified to include LED light sources. LED's, while non-coherent, can be focused sufficiently to create similar effects. It is all about how much light energy is hitting a person's retina. The effect can be created with any light source of sufficient intensity. Both a very bright focused LED and a laser can (temporarily) blind people.
Microsoft software does not have bugs. They have "undocumented features". It is a feature that Internet Explorer 7 works this way. When properly embraced, it extends the operating system with new features, and extinguishes all problems.
Be positive about these features!!! :-)
Microsoft selling Windows Legacy looks suspiciously similar Coke selling Coke Classic. Tell everyone they like "New Coke", realize the don't, and start selling "Coke Classic". Tell everyone they like "Vista", realize they don't, and then sell "Windows Legacy."
I am already bracing myself for the "Windows 7 the operating system that was supposed to ship in 2007" jokes. Microsoft picking Windows 7 as a product name in 2007 appears unfortunate.
Thanks to all the posters for the witty responses.
These physicists always say they are searching for God or "the God Particle". But what happens if they switch the big God Particle generator on, and God suddenly appears? What if we really do find God?
What are all these geeky physicists going to do then? Do we really want to find God? Do we really want physicists finding God? Is this a good thing?
Just wondering ...
My understanding was that the first computer viruses were penned at Bell Labs in a series of experiments called the "Core Wars". The goal was to eliminate as many enemy tasks as possible while keeping your tasks running. Byte has an article on the subject in the 1980's. Of course, at the time, disk media were in limited supply. This made spreading away from the test mainframe next to impossible.
Wikipedia link: http://en.wikipedia.org/wiki/Core_War
The 8080A did not feature segments. Segments were created in the 8086/8088 design. The 8080A had 8 8-bit registers organized as 4 16-bit registers. It also had the condition code register, and a slew of jump and branch instructions. Ever wondered where the BL/BH=BX thing came from? That was a variant of the 8080A's B and C registers combining to form the BC register. It turns out that many of the key condition codes, arithmetic, branch, jump, and index instructions came from the 8080A. Other than register renaming, and expanding many instructions to longer data words, we are still using many of the same instructions that were in use on the 8080A. Assembly programming really hasn't changed much over the years.
Of course, the new processors have many new instructions. New addressing modes for the old instructions have been added over the years. It is just interesting that the old core instructions are still around in a fairly similar form. These old instructions make up a surprisingly large fraction of the compiled code generated by todays compilers. It just goes to show: software compatibility pays.
The teacher did not understand computers at all. She was expressly told not to turn it off. It appears it was an out-of-date Windows 98 PC infected with spyware and with expired anti-virus software. The schools firewalls were ineffective. (They probably had expired filter software too.)
The teacher was told to do some simple activity with the computer and show it to her class. With the malware, you can guess what happened next ...
IBM made a decision in 1980 to go with the Intel 8088 (8/16 bit) processor instead of the Motorola 68000 (16/32 bit) processor. At the time, the Motorola processor was designed to be the processor of the future. On the other hand, the 8088 was intended to be almost compatible with 8080A assembly code. This created the need for the 8088 segmented architecture, and segments suck.
The use of segment registers set PC development back over a decade. Essentially, all the 80's was spent fighting segmentation wars. The IBM PC didn't get proper 32-bit computing until the widespread popularity of 386 PC hardware in about 1992, and the subsequent introduction of Windows 95. Windows XP was the first unified 32-bit Microsoft O/S in 2001. DOS mode was finally eliminated in Windows Vista in 2007!!! I think you had to live through segmentation and far pointers to understand how incredibly awful they were.
Interestingly, the Apple Mac had a 68000 processor in 1984. If that caught on, then it would have saved the PC industry a decade of pain. Apple made the decision not to license the operating system for the Apple Mac. The result was Apple hardware was expensive, so few purchased it. The problem was so severe that Apple almost went bankrupt before Steve Jobs returned.
IBM built Microsoft and Intel when they created the IBM PC. Apple rested on the laurels of a better architecture and almost went bankrupt. These two decisions defined at least 15 years of software history. It isn't until know where we see a few different pure 32-bit operating systems fighting it out on a common hardware platform. The Windows XP, Vista, OS/X, Linux battles will be interesting. The 32/64 bit battles will take place on PC hardware that is still almost completely assembly language compatible with the first widely used 8-bit Intel Microprocessor: the 8080A!
The other variant on your story is if a preferred customer installs a newer version of Office. Then someone at your company needs the new version of Office to read the incoming e-mails, and the slippery slope starts ...
Agreed.
My experience was this: I had a new PC with Office 2003 trial, and wanted to use my old version of Office to begin with. As such, I installed my earlier version of Office. The two programs would not coexist well at all. Office 2003 consistently annoyed me with unexpected attempts to start up.
As far as I could figure out, Office 2003 maps registry keys that earlier versions of Office 2000 do not. The result is that you can't effectively have Office 2003 and an earlier version of Office on the same PC, with the earlier version having preference. Every so often, the new version of Office would be started via one of the new registry keys, and there was nothing I could do to stop it. I even refused to click Agree on th EULA, and Excel 2003 eventually decided to run anyway.
The solution was to uninstall both Office 2003 and the earlier version of Office, and then reinstall the desired version of Office. Currently, I just uninstall the trial versions of Office immediately, and do not allow them to run even once. This seems to work fairly well.
The original poster was essentially correct. If you do not know enough to uninstall all versions of Office, and then install the desired version, then you will have problems. If you try to "manually correct" things, you will probably wind up reinstalling Windows XP. Myself, I think if you want to have multiple versions of Office on the same PC, you probably want to install virtualization software like VMWware.
To this date, I still have not deliberately used Office 2003 or agreed to its EULA, and I haven't missed it either.
The term in environmental circles is: "Dilution is no Solution."
My take on C++ is that the best programs only use a fraction of the features. The language is so big it is dangerous. Just because a feature exists in the language, does not mean it is good for every application. I am very wary of operator overloading and templates too. You need to make your code sufficiently clear that you can be sure it works. if you cannot quickly understand your code, then chances are you made a mistake.
Many pieces of old code aren't pretty for a fairly defined set of reasons:
1. a) Debugging Ensure you actually have an appropriate way of debugging the code. The systems I work with are embedded and run 7x24. People will say: it failed last week on Wednesday at 3:00 A.M., we got it working, but can you fix the problem? The problem may not actually be your code, it could be another piece of equipment. In any case, you need to figure this out from the logs. In my experience, many "pretty" programs are too small to justify extensive logging. After logging is included, the programs become less "pretty" but much more maintainable.
1. b) Refactoring after Debug Sometimes the results of the debug will show a major design error in the program. You now need to implement a major architectural change that really was not originally intended. You have good modular code when it can withstand these major design changes in a relatively smooth manner.
2. Failure to handle common areas of problems well These include:
2. a) Strings Does your program have the ability to smoothly handle unicode/UTF/HTML/locale specific strings? Every different language you port your application too, and every different program you talk with, will all have differing definitions of what is a string. My favorite test case is CNC (Computer Numerically Controlled) machinery. Some CNC machines expect embedded nulls inside the strings. The embedded null requirement affects a surprisingly large number of string libraries.
2. b) MessageBox() Invariably in a big program it will be unacceptable to allow it to hang on a modal dialog box like MessageBox(). How are you going to handle it? What if a library call executes a modal dialog box?
2. c) Handling Exceptions For a simple prototype program, handling exceptions is not a big deal. In a production application, all the exceptions must be handled appropriately and the program must be able to continue when exceptions occur. The error handling code often exceeds the size of the original program.
2. d) Third Party Libraries / Operating Systems (Windows) The amount of code devoted to covering up mistakes in other code is amazing. Unfortunately, unless coding on an open platform, one must accept the costs of the additional code. When starting a new project, I recommend thoroughly stress testing any new libraries that will be used. Thus one can find the killer bugs that significantly affect design decisions.
I would appreciate any feedback/additions to the items on this list.
Unfortunately, this technology is very likely to be misused by uninformed people in the legal profession. The example of the school teacher accused of spreading porn come to mind. http://arstechnica.com/news.ars/post/20070214-8850 .html
Some prosecutors are likely to take the evidence from Vista as proving a person did something very bad. The evidence only the computer did something very bad. A rogue third party could have hijacked the computer and planted the data there. With current spyware and adware, the attack may simply be an effort to drive traffic to certain websites. Having a school teacher's career destroyed is just a side-effect of a rogue third party trying to make money.
Reliability analysis is used to quantify failure rates. It is poor practice to use logic to analyze either a computer program or a safety system. Logic can only reveal the obvious flaws in the system. Logic does not help us to quantify the impact or severity of the flaw. Logic assumes things "always" happen. Real-life does not "always" happen as intended. Mechanical systems are never "always" consistent. Computers aren't "always" consistent either. Users have a big impact on problem severity.
We have 100+ years of history designing mechanical systems for applications were they almost "always" work. This gives us ample data to quantify likely failure modes. These failure modes can then be analyzed and prevented by other safety measures.
In the case of safety systems, layer upon layer of checks are present. The concept is that even if something fails, or comes close to failing, it will be picked up by another check. Quantifying the performance of a safety system is not about logic, it is about reliability analysis. How many failures are likely to happen? and how many failures does it take before something dangerous happens?
One report on 3 mile island listed separate 114 (?) failures that ultimately resulted in the core meltdown. How unlikely is this? Mathematics tells us that unlikely events happen all the time. Every day someone wins the lottery. How unlikely is a nuclear accident to occur? That question is answered by reliability analysis, and it is a complex field including both statistical techniques and logic.
How likely is it that something bad will occur as a result of this Java bug? It turns out that the computers (and their users) would have to make thousands of poor decisions before suffering adverse effects from this bug. Unfortunately, millions of computers exist, each making millions of decisions per second, so some people will probably be affected. Quantifying the severity of the problem is a difficult reliability analysis problem.
Okay. Let me see if I have this straight:
We can use a free scanner to eliminate free software inside my anti-free software organization???
I heard about the same VAX hack at about the same time. The idea of boosting process priority by synchronizing to the CPU ticks isn't all that new.
Of course, in 1987 Windows was completely immune to this problem. It had non-preemptive cooperative scheduling. :-)
I think the days of using Microsoft software in a production-related, mission-critical, soft real-time environment are soon to be over. Essentially, the applications always require some custom written software that calls a large number of Microsoft API's, often in a poorly understood and undocumented manner. Worse, the applications tend to use Microsoft software in unexpected or undocumented ways. Microsoft designs Microsoft Windows and Vista for the average desktop user. Real-time applications tend to be much more demanding than the average desktop user. Response time, up-time and reliability are critical. Every Microsoft patch and virus scanner update potentially disrupts the real-time application directly through disk accesses and reboots, and indirectly by changing the underlying Microsoft API's.
This is the era of hospital computer networks being infected by bot-nets. We can neither blindly deploy patches, nor can we safely do without. The critical soft real-time applications are going to have to be migrated away from Microsoft Windows. It might take some time, but I don't really see any alternatives.
Has anyone else noticed that the speed of Windows XP is actually dropping, or at least does not monotonically increasing? All of the patches and virus scanning are affecting system performance, and the performance drop is significant for some of my applications.
The complaint is fairly devastating. Going by the complaint, the RIAA repeatedly refused to limit the damages their actions were causing or could reasonably expected to cause. It isn't wise to sue a highly sympathetic person without fair cause. You tend to loose at trial.