The 90mm Athlon 64 3500+ uses 80 watts less than the P4 system under load and 40 watts less than the P4 when they are both idling. AMD chips are usually cheaper to buy but I would have never thought there would be so much electricity savings in running them after the purchase. This would add up to a lot of electricity savings for a large server farm of the 90mm AMD chips. Intel needs to get their fanny in gear and update their product line or something.
My voting precinct has recently began using an optical scan voting system in which you blacken in little circles on the paper ballot for your choice and then feed your ballot into the vote scanning machine which then tallies the results and records them electronically. At the end of the day, the results get sent electronically to some central point where they are supposedly tallied. Anyway, I voted last Tuesday in a statewide primary and when I arrived about 20 minutes after the polls opened, there was already a long line of people waiting to feed their ballots into the vote scanner machine which was refusing to accept any of them. The voting supervisor guy was a gentleman in his 80s who obviously did not have a clue about what to do to either fix the machine or report the problem. People kept arriving, filling out their votes, and then lining up until the place was jammed. (There were 6 precincts using one vote scanning machine). Finally, one of the poll workers got a cardboard box, wrote 'votes' on the side, and said we could just leave our ballots in the box and they would feed them into the vote scanning machine later when it was 'fixed.' So...that's what everyone did since people had to get on to work and such. My conclusion was that this e-voting system was extremely vulnerable to any sort of problem, easily circumvented with fraud, and, in this case, didn't preserve ballot secrecy. This stuff never even got a mention in a newspaper which reported instead how well the voting went.
What exactly is the article author saying when he writes: "...appear to be in the grip of a mysterious force that is holding them back." I read along to the end of his stuff hoping to find out exactly what the observed 'anomaly' is. Are the spacecraft accelerating less than expected or are they decelerating more than expected? What is the rough magnitude of the difference between the observed and expected value?.01%? 10%? 100%? What is the effect of the anomaly on the expected time for the spacecraft to reach another solar system? These are the sorts of questions that the author should have addressed.
After looking at their website, it looks like the main thrust is just another attempt to improve the dismal x86 performance on Itanium. The rest is probably hype and fluff.
The whole SCO vs IBM case is beginning to feel and sound like the lengthy Microsoft vs DOJ antitrust case.
In the MS vs DOJ case, Microsoft clearly had a monopoly, they used it illegally, and they lost every round in court in displays of legal ineptitude. Remember Bill Gates terrible videotaped deposition? I used to wonder how Microsoft planned to win. And then...Microsoft got a new judge, a new Attorney General, a settlement agreement, etc. etc. and the who thing just vanished in a puff of legal smoke and Microsoft carried on as usual.
Now, we have SCO seemingly out on a long limb and IBM holding the saw and yet...the news today has the city of Turku in Finland abandoning their plans to switch to Linux in favor of Windows XP. SCO is losing every legal battle just as Microsoft did but perhaps they are winning the war which is all that really matters.
This is a very poor benchmark comparison. According to the info at the beginning of the Anandtech article, the Intel Xeon the test has a 1mb L2 cache while the AMD Athlon 64 has a 512k L2 cache. What this means is that if their "synthetic benchmark" has a size of more than 512kb but less than 1mb, it will be loaded entirely into cache for the Xeon but not for the AMD. The "synthetic benchmark" in that case is then measuring the difference in speed between the always-much-faster L2 cache and RAM memory and the CPU FPU speed rather than just the difference in FPU processing speed between the CPUs alone.
If they want to show that more L2 cache is better for running small "synthetic benchmark" apps, then their results are valid. Otherwise, they are meaningless as an indicator of CPU performance because they are not comparing apples to apples. To go even further down the apples vs. oranges road, though, they could drop the system memory in the Athlon64 system down to 384mb or so and then raise the Xeon system memory to 2 GB and then run some Doom3 benchmarks to "prove" that Doom3 runs faster on the Xeon than the Athlon64. And then what about swapping out the 120 GB IDE UDMA5 hard drive in the Athlon64 and replacing it with a 10GB UDMA2 hard drive to "prove" that Xeon is even FASTER!! yeah!
There is no way I would ever believe that more than 30 percent of searching on the net is done with an abysmally poor search tool such as msn. Yahoo is not much better. I might believe 95% Google, 10% Yahoo, and 2% MSN (Numbers do not add up to 100 due to multiple searches)
Actually, Hanford *was* a nuclear power plant. Nuclear reactors were constructed to irradiate uranium with neutrons to make plutonium. The first reactor was the "B" reactor which has been designated as a National Historic Mechanical Engineering Landmark. Heat from the B Reactor fission process was never used to produce electricity but was instead transferred to the nearby Columbia River. Several additional nuclear reactors were constructed at Hanford over the years, none of which produced commercial electric power, until "N Reactor" was constructed. N Reactor *did* produce commercial electric power (and was the only weapons reactor which ever did--approx. 1000 megawatts) until it was shut down in the aftermath of the Chernobyl accident. The Washington Public Power Supply System (WPPSS) also constructed two large commercial nuclear power plants at Hanford in the 70s. One was never finished and still stands there today. The second reactor next door to it *was* finished and is currently in operation and producing commercial electric power.
Why do we need news stories telling us that some or another particular bit of interesting information is going to be released 'this week.' Why not wait until *after* the news is available and then talk about that?
I really don't get why more developers aren't eager to create much more powerful user interfaces. Personally, I consider something not finished if it doesn't have as much power as I can pack into each simple button and operation. I *enjoy* making stuff both simpler and more powerful. That is the real challenge.
Right now, I'm working on creating a new type of development tool in which a working app consists of different types of 'blocks' are dragged and dropped into place and connected graphically with with 'pipes' via the graphical editor. Imagine data as a fluid moving through a pipe with 'decision' logic blocks, 'display' blocks, 'input' blocks and 'output' blocks to regulate and direct its 'flow'. A real working app looks a little a computer flowchart. Sure, an app created this way is less efficient than one coded in assembly but I want to create something that will let 6 year-old-kids create a working gui app on their computer and I don't get why more developers don't want to go in that direction. The hardware is getting much more powerful every year and yet the design and configuration of software seems to reflect the hardware capabilities from 10 years ago. I would rather have software that pegs an Athlon64 CPU and needs 2+ gb of memory if it provided the ability for people to do new things with computers that they cannot do now.
It was widely reported that a flaw was found in 'Mozilla' which was not correct. The flaw was in the Shell: protocol on Windows. That's why the alleged 'flaw' in Mozilla did not exist on non-Windows platforms. The only 'flaw' in Mozilla was its failure to block the use of the shell: stuff on Windows (which the patch now does).
If you are a large enterprise site still running Windows 98, what do you upgrade to? Look at the choices Microsoft gives you:
Windows 2K? Windows XP? Those both have much greater hardware requirements, are still only 32-bit OS, have numerous security problems, and have much worse compatibility with those old DOS or Win 3.1 internal apps you may be running.
Windows XP 64-bit? Still in beta and compatibility even worse than with the 32-bit Windows OSs since it has zero support for 16-bit apps of any kind.
Longhorn? Really? When? What?
Linux, by contrast, has good compatibility, full 64-bit support, far fewer security problems, and will not bring the BSA down on you if your disgruntled employees drop a dime. It doesn't hurt that its inexpensive, either. If Microsoft is assuming that all of those Windows 98 users are going to wait and upgrade to 'Longhorn' or something, I want whatever it is they are smoking.
"...Actually the chance that they'd both be the same is pretty small..."
Not really. If the correct total is truly 8,192 votes, then the 8,192 total would presumably be the most likely result for either a manual or an e-voting process if the process was accurate.
"...Except for the very unlikely* event that all of a precinct's computers are down at once, every vote will be recorded exactly correctly. There's no equivalent of a mechanical or optical reader misreading or miscounting a card. Computers don't have a 0.5% chance of accidentally incrementing the wrong memory address for example..."
It is very unlikely that *any* complex system will function "exactly correctly." For example, what if the voter pushes two (or three) spots on the touchscreen display simultaneously or touches them for an unexpectedly long (or short) amount of time or uses a display input with a damaged surface? Does the POS touchscreen display at the checkout stand of your local supermarket function "exactly correctly" after a few months of use or does the operator have to push some things repeatedly to get them to activate? Your presumption of a flawless system is just not realistic in the real world where e-voting machines will certainly have flaws, as do all human-built devices. Incorporating elements of digital technology into an e-voting process is not sufficient reason, by itself, to believe that such a process would be any more or less accurate than the numerous manual processes still in use. A better predictor for accuracy IMO, leaving the fraud issue aside for the moment, would be the amount of testing and oversight which goes into the development and implementation of the process, be it an e-voting or manual process.
--"...As i said in another response: "I still think being able to say 'So-and-so got *exactly* 8,192 votes' is much better than 'So-and-so got 8,200 votes with a 95% confidance interval with a radius of 10', even if the next runner up is obviously behind..."--
You seem to be confusing 'accuracy' and 'precision.' The precision of either a manual or an e-voting process is *always* one vote and the final vote tally would be 8,192 votes for either, to use your number. The *accuracy* of those two processes might be very different, however, for many of the reasons that people have provided here such as fraud, operator error, hardware failure, software bugs, or voter error.
Leaving out fraud for a moment, there is no reason to believe that the accuracy of an e-voting machine will be better or worse than a typical manual process. When fraud is also considered, however, the e-voting machines seem much more prone to it due to their lack of a paper trail for accountability (which means there is no way to check their accuracy) and due to the potential for votes to be easily and fraudulently changed on a widespread scale via software manipulation of the system. Therefore, the overall accuracy of an e-voting machine may be *much* worse than one of those old-fashioned manual methods.
"1) Accuracy. I secure evoting system should be 100% accurate. "
It is not realistic to expect to achieve 100% accuracy when counting millions of votes, regardless of the method used. Random factors will *always* decrease the accuracy, even with 'e-voting.'
For example, some fraction of the machines will fail on election day due to hardware failure, power failure, software failure, operator error, or something else. Some percentage of the ballots will be incorrectly entered into the machines due to operator error, last-minute changes, or error by the elections officials. Some portion of the votes cast will be in error due to mistakes by the voter such as mis-understanding of the screen display, inadvertently touching the wrong place on the screen, mis-reading the display, etc. Finally, of course, it is always possible that malicious individuals and organizations will attempt to subvert the e-voting machines through fraud, just as every manual voting process has been subverted over the years. The e-voting machines appear to be much more vulnerable to voting fraud than most of the manual processes we currently use because the e-voting machines leave no paper trail of accountability and because one malicious programmer can singlehandedly change millions of votes with a few key strokes. By comparison, Al Capone needed an army of helpers to enable all of those deceased voters to rise out of their graves and vote in Chicago.
The only contribution which the e-voting machines can make to the election process is faster speed in the vote-counting but speed is much less important than security against fraud in something like voting.
"Most software is a renewal business. Customers buy multiple releases over a relatively long period of time. As a consequence, the market has a deep understanding of your software and its flaws, and your organization and its flaws. Often, the market has grown uncomfortably dependent on software that doesn't meet its needs. In many software situations, customers spend hours per/day uncomfortably shoe-horning their lives into your product. As a consequence, they crave your understanding, and will respond enthusiastically to the least sign of it. Normal success, meeting customer expectations, means to improve the most outrageous and flagrant violations of their needs from version to version. They will likely stay with you if you are faithful about that, though they may well be sullen if not mutinous."
The successful suborbital flight of Space Ship One has left NASA in shock. Their first post-flight spin was that suborbital flight was not *that* big a deal and that orbital flight was waaaaay harder. Now they hint around about offering prizes of their own. The problem with NASA is not that they don't have smart people. The problem is that their bureaucracy tracks down and snuffs out any creative (read 'different') thinking before the words 'what if we tried...' are ever heard.
Now that Microsoft has patented stuff like the todo list and the double-click, no one else will be able to patent it later. All we have to do is wait 17 years and then we can start using them again without paying a tribute to Microsoft.
The entire business model over the last 10 years of Micrsoft has been aimed at moving users to a software rental model where the hardware is proprietary and dedicated to running Microsoft software. The cost of the hardware is not really free, of course, but its cost will be included in the subscription to the software. If it were not for Linux, Microsoft would have already arrived at its destination and Windows XP would have probably been the first rental version of Windows. Windows XP contacts Microsoft computers in a a variety of ways that make perfect sense if the user is a renter and Microsoft owns it. Microsoft could then easily de-activate Windows XP when the user didn't pay the rent, much as it deactivates if the user doesn't register or if the hardware is changed.
The rapid development of Linux in the last 3 years, however, has hindered the Microsoft plans because there is no rental charge for Linux and Linux is now able to provide many of the most important capabilities as Windows. Linux also supports quite a wide variety of hardware, thanks to the hard work of a lot of device driver coders.
The only other alternative to Windows is Macintosh and the hardware is already very closely tied to the software on that platform, making the implementation of a software rental model relatively easy, as soon as Microsoft goes to it.
The author makes a great point on the value of a deterrent.
We focus all of our efforts on futilely trying to prevent easy-to-commit crimes, such as writing Windows virus scripts, when we should be concentrating more on deterrence. For example, stealing horses a hundred years ago was ridiculously easy. You just walked up to the hitchin rail, grabbed the reins, climbed aboard, and rode off over the horizon...no key required. It would have been impossible to 'prevent' the crime so the punishment focused on deterrence. Horse thieves were publicly derided and executed...sometimes without the benefit of a trial.
The modern day equivalent of a horse thief is a virus author...or a spammer.
Slashdot Mirror
The 90mm Athlon 64 3500+ uses 80 watts less than the P4 system under load and 40 watts less than the P4 when they are both idling. AMD chips are usually cheaper to buy but I would have never thought there would be so much electricity savings in running them after the purchase. This would add up to a lot of electricity savings for a large server farm of the 90mm AMD chips. Intel needs to get their fanny in gear and update their product line or something.
My voting precinct has recently began using an optical scan voting system in which you blacken in little circles on the paper ballot for your choice and then feed your ballot into the vote scanning machine which then tallies the results and records them electronically. At the end of the day, the results get sent electronically to some central point where they are supposedly tallied. Anyway, I voted last Tuesday in a statewide primary and when I arrived about 20 minutes after the polls opened, there was already a long line of people waiting to feed their ballots into the vote scanner machine which was refusing to accept any of them. The voting supervisor guy was a gentleman in his 80s who obviously did not have a clue about what to do to either fix the machine or report the problem. People kept arriving, filling out their votes, and then lining up until the place was jammed. (There were 6 precincts using one vote scanning machine). Finally, one of the poll workers got a cardboard box, wrote 'votes' on the side, and said we could just leave our ballots in the box and they would feed them into the vote scanning machine later when it was 'fixed.' So...that's what everyone did since people had to get on to work and such. My conclusion was that this e-voting system was extremely vulnerable to any sort of problem, easily circumvented with fraud, and, in this case, didn't preserve ballot secrecy. This stuff never even got a mention in a newspaper which reported instead how well the voting went.
What exactly is the article author saying when he writes: "...appear to be in the grip of a mysterious force that is holding them back." I read along to the end of his stuff hoping to find out exactly what the observed 'anomaly' is. Are the spacecraft accelerating less than expected or are they decelerating more than expected? What is the rough magnitude of the difference between the observed and expected value? .01%? 10%? 100%? What is the effect of the anomaly on the expected time for the spacecraft to reach another solar system? These are the sorts of questions that the author should have addressed.
After looking at their website, it looks like the main thrust is just another attempt to improve the dismal x86 performance on Itanium. The rest is probably hype and fluff.
Highly insightful, considering that you can get Linux for free.
Well sure, but the Windows boxen have the zombie feature.
Let's see...$3000 for 20,000 windows boxen works out to 15 cents per machine. Yeah boy, that's about what one is worth.
The whole SCO vs IBM case is beginning to feel and sound like the lengthy Microsoft vs DOJ antitrust case.
In the MS vs DOJ case, Microsoft clearly had a monopoly, they used it illegally, and they lost every round in court in displays of legal ineptitude. Remember Bill Gates terrible videotaped deposition? I used to wonder how Microsoft planned to win. And then...Microsoft got a new judge, a new Attorney General, a settlement agreement, etc. etc. and the who thing just vanished in a puff of legal smoke and Microsoft carried on as usual.
Now, we have SCO seemingly out on a long limb and IBM holding the saw and yet...the news today has the city of Turku in Finland abandoning their plans to switch to Linux in favor of Windows XP. SCO is losing every legal battle just as Microsoft did but perhaps they are winning the war which is all that really matters.
This is a very poor benchmark comparison. According to the info at the beginning of the Anandtech article, the Intel Xeon the test has a 1mb L2 cache while the AMD Athlon 64 has a 512k L2 cache. What this means is that if their "synthetic benchmark" has a size of more than 512kb but less than 1mb, it will be loaded entirely into cache for the Xeon but not for the AMD. The "synthetic benchmark" in that case is then measuring the difference in speed between the always-much-faster L2 cache and RAM memory and the CPU FPU speed rather than just the difference in FPU processing speed between the CPUs alone.
If they want to show that more L2 cache is better for running small "synthetic benchmark" apps, then their results are valid. Otherwise, they are meaningless as an indicator of CPU performance because they are not comparing apples to apples. To go even further down the apples vs. oranges road, though, they could drop the system memory in the Athlon64 system down to 384mb or so and then raise the Xeon system memory to 2 GB and then run some Doom3 benchmarks to "prove" that Doom3 runs faster on the Xeon than the Athlon64. And then what about swapping out the 120 GB IDE UDMA5 hard drive in the Athlon64 and replacing it with a 10GB UDMA2 hard drive to "prove" that Xeon is even FASTER!! yeah!
A year ago the very suggestion that fear over IP could have stalled a major Linux migration would have been a laugher. Now, it's deadly serious.
Score: Microsoft 1, World 0
There is no way I would ever believe that more than 30 percent of searching on the net is done with an abysmally poor search tool such as msn. Yahoo is not much better. I might believe 95% Google, 10% Yahoo, and 2% MSN (Numbers do not add up to 100 due to multiple searches)
Actually, Hanford *was* a nuclear power plant. Nuclear reactors were constructed to irradiate uranium with neutrons to make plutonium. The first reactor was the "B" reactor which has been designated as a National Historic Mechanical Engineering Landmark. Heat from the B Reactor fission process was never used to produce electricity but was instead transferred to the nearby Columbia River. Several additional nuclear reactors were constructed at Hanford over the years, none of which produced commercial electric power, until "N Reactor" was constructed. N Reactor *did* produce commercial electric power (and was the only weapons reactor which ever did--approx. 1000 megawatts) until it was shut down in the aftermath of the Chernobyl accident. The Washington Public Power Supply System (WPPSS) also constructed two large commercial nuclear power plants at Hanford in the 70s. One was never finished and still stands there today. The second reactor next door to it *was* finished and is currently in operation and producing commercial electric power.
Why do we need news stories telling us that some or another particular bit of interesting information is going to be released 'this week.' Why not wait until *after* the news is available and then talk about that?
Hilarious. What will those diligent Longhorn watchers do if they find one a violation? Give Microsoft a slap on the other wrist?
The only result of the entire Microsoft antitrust case was to show just how insignificant the antitrust laws really are.
I really don't get why more developers aren't eager to create much more powerful user interfaces. Personally, I consider something not finished if it doesn't have as much power as I can pack into each simple button and operation. I *enjoy* making stuff both simpler and more powerful. That is the real challenge.
Right now, I'm working on creating a new type of development tool in which a working app consists of different types of 'blocks' are dragged and dropped into place and connected graphically with with 'pipes' via the graphical editor. Imagine data as a fluid moving through a pipe with 'decision' logic blocks, 'display' blocks, 'input' blocks and 'output' blocks to regulate and direct its 'flow'. A real working app looks a little a computer flowchart. Sure, an app created this way is less efficient than one coded in assembly but I want to create something that will let 6 year-old-kids create a working gui app on their computer and I don't get why more developers don't want to go in that direction. The hardware is getting much more powerful every year and yet the design and configuration of software seems to reflect the hardware capabilities from 10 years ago. I would rather have software that pegs an Athlon64 CPU and needs 2+ gb of memory if it provided the ability for people to do new things with computers that they cannot do now.
It was widely reported that a flaw was found in 'Mozilla' which was not correct. The flaw was in the Shell: protocol on Windows. That's why the alleged 'flaw' in Mozilla did not exist on non-Windows platforms. The only 'flaw' in Mozilla was its failure to block the use of the shell: stuff on Windows (which the patch now does).
If you are a large enterprise site still running Windows 98, what do you upgrade to? Look at the choices Microsoft gives you:
Windows 2K? Windows XP? Those both have much greater hardware requirements, are still only 32-bit OS, have numerous security problems, and have much worse compatibility with those old DOS or Win 3.1 internal apps you may be running.
Windows XP 64-bit? Still in beta and compatibility even worse than with the 32-bit Windows OSs since it has zero support for 16-bit apps of any kind.
Longhorn? Really? When? What?
Linux, by contrast, has good compatibility, full 64-bit support, far fewer security problems, and will not bring the BSA down on you if your disgruntled employees drop a dime. It doesn't hurt that its inexpensive, either. If Microsoft is assuming that all of those Windows 98 users are going to wait and upgrade to 'Longhorn' or something, I want whatever it is they are smoking.
"...Actually the chance that they'd both be the same is pretty small..."
Not really. If the correct total is truly 8,192 votes, then the 8,192 total would presumably be the most likely result for either a manual or an e-voting process if the process was accurate.
"...Except for the very unlikely* event that all of a precinct's computers are down at once, every vote will be recorded exactly correctly. There's no equivalent of a mechanical or optical reader misreading or miscounting a card. Computers don't have a 0.5% chance of accidentally incrementing the wrong memory address for example..."
It is very unlikely that *any* complex system will function "exactly correctly." For example, what if the voter pushes two (or three) spots on the touchscreen display simultaneously or touches them for an unexpectedly long (or short) amount of time or uses a display input with a damaged surface? Does the POS touchscreen display at the checkout stand of your local supermarket function "exactly correctly" after a few months of use or does the operator have to push some things repeatedly to get them to activate? Your presumption of a flawless system is just not realistic in the real world where e-voting machines will certainly have flaws, as do all human-built devices. Incorporating elements of digital technology into an e-voting process is not sufficient reason, by itself, to believe that such a process would be any more or less accurate than the numerous manual processes still in use. A better predictor for accuracy IMO, leaving the fraud issue aside for the moment, would be the amount of testing and oversight which goes into the development and implementation of the process, be it an e-voting or manual process.
--" ...As i said in another response: "I still think being able to say 'So-and-so got *exactly* 8,192 votes' is much better than 'So-and-so got 8,200 votes with a 95% confidance interval with a radius of 10', even if the next runner up is obviously behind..."--
You seem to be confusing 'accuracy' and 'precision.' The precision of either a manual or an e-voting process is *always* one vote and the final vote tally would be 8,192 votes for either, to use your number. The *accuracy* of those two processes might be very different, however, for many of the reasons that people have provided here such as fraud, operator error, hardware failure, software bugs, or voter error.
Leaving out fraud for a moment, there is no reason to believe that the accuracy of an e-voting machine will be better or worse than a typical manual process. When fraud is also considered, however, the e-voting machines seem much more prone to it due to their lack of a paper trail for accountability (which means there is no way to check their accuracy) and due to the potential for votes to be easily and fraudulently changed on a widespread scale via software manipulation of the system. Therefore, the overall accuracy of an e-voting machine may be *much* worse than one of those old-fashioned manual methods.
"1) Accuracy. I secure evoting system should be 100% accurate. "
It is not realistic to expect to achieve 100% accuracy when counting millions of votes, regardless of the method used. Random factors will *always* decrease the accuracy, even with 'e-voting.'
For example, some fraction of the machines will fail on election day due to hardware failure, power failure, software failure, operator error, or something else. Some percentage of the ballots will be incorrectly entered into the machines due to operator error, last-minute changes, or error by the elections officials. Some portion of the votes cast will be in error due to mistakes by the voter such as mis-understanding of the screen display, inadvertently touching the wrong place on the screen, mis-reading the display, etc. Finally, of course, it is always possible that malicious individuals and organizations will attempt to subvert the e-voting machines through fraud, just as every manual voting process has been subverted over the years. The e-voting machines appear to be much more vulnerable to voting fraud than most of the manual processes we currently use because the e-voting machines leave no paper trail of accountability and because one malicious programmer can singlehandedly change millions of votes with a few key strokes. By comparison, Al Capone needed an army of helpers to enable all of those deceased voters to rise out of their graves and vote in Chicago.
The only contribution which the e-voting machines can make to the election process is faster speed in the vote-counting but speed is much less important than security against fraud in something like voting.
One of the better quotes:
"Most software is a renewal business. Customers buy multiple releases over a relatively long period of time. As a consequence, the market has a deep understanding of your software and its flaws, and your organization and its flaws. Often, the market has grown uncomfortably dependent on software that doesn't meet its needs. In many software situations, customers spend hours per/day uncomfortably shoe-horning their lives into your product. As a consequence, they crave your understanding, and will respond enthusiastically to the least sign of it. Normal success, meeting customer expectations, means to improve the most outrageous and flagrant violations of their needs from version to version. They will likely stay with you if you are faithful about that, though they may well be sullen if not mutinous."
The successful suborbital flight of Space Ship One has left NASA in shock. Their first post-flight spin was that suborbital flight was not *that* big a deal and that orbital flight was waaaaay harder. Now they hint around about offering prizes of their own. The problem with NASA is not that they don't have smart people. The problem is that their bureaucracy tracks down and snuffs out any creative (read 'different') thinking before the words 'what if we tried...' are ever heard.
Now that Microsoft has patented stuff like the todo list and the double-click, no one else will be able to patent it later. All we have to do is wait 17 years and then we can start using them again without paying a tribute to Microsoft.
The entire business model over the last 10 years of Micrsoft has been aimed at moving users to a software rental model where the hardware is proprietary and dedicated to running Microsoft software. The cost of the hardware is not really free, of course, but its cost will be included in the subscription to the software. If it were not for Linux, Microsoft would have already arrived at its destination and Windows XP would have probably been the first rental version of Windows. Windows XP contacts Microsoft computers in a a variety of ways that make perfect sense if the user is a renter and Microsoft owns it. Microsoft could then easily de-activate Windows XP when the user didn't pay the rent, much as it deactivates if the user doesn't register or if the hardware is changed.
The rapid development of Linux in the last 3 years, however, has hindered the Microsoft plans because there is no rental charge for Linux and Linux is now able to provide many of the most important capabilities as Windows. Linux also supports quite a wide variety of hardware, thanks to the hard work of a lot of device driver coders.
The only other alternative to Windows is Macintosh and the hardware is already very closely tied to the software on that platform, making the implementation of a software rental model relatively easy, as soon as Microsoft goes to it.
The author makes a great point on the value of a deterrent.
We focus all of our efforts on futilely trying to prevent easy-to-commit crimes, such as writing Windows virus scripts, when we should be concentrating more on deterrence. For example, stealing horses a hundred years ago was ridiculously easy. You just walked up to the hitchin rail, grabbed the reins, climbed aboard, and rode off over the horizon...no key required. It would have been impossible to 'prevent' the crime so the punishment focused on deterrence. Horse thieves were publicly derided and executed...sometimes without the benefit of a trial.
The modern day equivalent of a horse thief is a virus author...or a spammer.