Simply restrict the total body of law to n words. If the limit is reached, no new law can be passed until some other law is repealed. Reduce n by 2% annually until a reasonable minimum is reached.
There may be a division, but not along the lines the article seems to envision. The break will be along international borders.
Keep in mind that software patents hold little sway over the rest of the world. Taxing Linux in the US will just push Linux development and perhaps use abroad. It will also ensure that fewer countries will be willing to adopt software patents. This could be could news for the ongoing battle in the EU.
Now somebody just has to explain to me why we'd want to go to the moon again, especially with humans.
Considering that GW Bush's "vision" of human space exploration of the moon is crowding out much more productive and waaaay less expensive robotic exploration and even basic research at home, I'm even less convinced this is the right way forward. We could also consider the source, but we wouldn't want to get distracted by other failed visionary projects (such as democratizing the middle east by attacking Iraq) when evaluating a plan on its merits.
Certainly, human exploration is much more flashy and is the only type of exploration that captures the imagination of the average population. But what can we possibly learn from doing yet another moon mission? If you're looking to explore the universe, more systems like Hubble will do fine. If you're looking to explore the solar system, robotic probes go farther for a lot less. If you're looking for a microgravity environment, the ISS will do fine. If you're looking for a launch platform to Mars, the ISS or - for that matter - any old orbit around earth is much closer to home (read inexpensive).
Perhaps I'm missing. If so, I'd be happy to hear about it.
Good point. When I wrote that sentence I was thinking of the choice between formal testers vs. developers doing the testing. It didn't occur to me that somebody might consider shipping code without testing.
Note that I mentioned the questionable nature of schedules in my list of items that Peopleware talks about. I don't think there is enough research available to form a conclusive opinion on that matter.
I think schedules are an interesting subject that can take pages to cover. A few thoughts anyway:
Developers vary greatly in skill, education and motivation. Peopleware claims that the spread is 1 to 100 across industries (in other words, developer A takes 1 week for a task, developer B takes a couple of years for the same task). Personally, I've found the spread to be more like 1 to 20, which is still considerable. Joel has a nice article on the matter also.
I've found that those at the high end require very little prodding to get things done. They work for the love of coding and for the enjoyment of shipping good code. This is the type of developer that doesn't need a deadline to get moving and may actually get frustrated and become ineffective when faced with a lot of red tape. This is also the type of developer you want to hire.
If you have a team of mid range developers, schedules may be needed. Fortunately, I've never been in that position. That said, the company I currently work at has very detailed schedules, milestones and deadlines. Does that help or hinder all things considered? I can't honestly say. We do spend a lot of time maintaining that schedule and I get a feeling that it is a source of frustration for many. Personally, I'd rather do something productive. Working on a schedule does not result in a single line of code.
Some developers require daily milestones and continuous supervision. Usually combined with low performance, they're both time intensive to manage and a drag on the team and the project. I've come to conclude that it is necessary to let go of this type of developer sooner rather than later.
I've been in the business for over 20 years, as a developer, as an architect, as a team lead and as a manager.
From architect on up, one of your key job responsibilities is to push back on features, schedules and so on, and to set expectations right from the get-go. Early on, I used to laugh out loud when being told proposed dates by marketing. That didn't go over too well, of course, so I've adopted a more diplomatic way of saying 'no' since.:-)
The gist of it is that many executives believe in Spanish management (very well explained in Peopleware). This boils down to setting ridiculous schedules, asking for continuous overtime, etc. The idea being that every minute an engineer spends more will get the product out the door faster. Of course, this is not the case as Peopleware will tell you in great detail. It is also matched by my own experience.
However, if you push back with data in hand (such as a detailed sizing) and a constructive proposal what to do differently, you may very well end up with a more reasonable schedule, a good product and happiness all around.
A few more gems in Peopleware:
Schedules are counterproductive. Teams that don't have schedules ouperform those that do by up to 50%.
Overtime is only productive for one week.
Cubicles are sinkholes of effectiveness. Why do Microsoft and IBM only have offices for engineers?
Peopleware is rather sobering. Every other page you think "wait - we're doing exactly what is being described here." The good news is that you can do something about it once you can recognize the signs.
For those of you with a humorous bent, I highly recommend checking out Joel Spolsky's articles on project management. A few highlights:
As far as the TFA goes, once you've accepted an impossible schedule you're already hosed. If you can't push back, leave. The job market is good right now.
If you can get to a reasonable schedule (by way of reducing features, adding time or people), the TFA is a bit limited in its scope. I have a few recommendations that have worked for me in the past (your mileage will vary, and you should read Peopleware anyway):
You need to have the spec in writing.
You need to use source control, even as a single developer.
You need to have a single button build.
When the build breaks you roll back the change that broke it or you stop everything until it is fixed.
You need to build daily. Or better yet, continuously.
Unit tests are your friend. They're less useful on GUIs but for logic they're a godsend. Personally, I can crank out high quality code about twice as fast with unit tests (if you consider debug time). Reduced maintenance and improved sleep is a bonus.
In the same vein - automated system testing (if possible) is a wonderful way to improve shipped quality. Your testers (if you have any) cannot test everything.
Code reviews are great. We use code reviewer with great impact on code quality.
Hire the best people only and fire those you have no hope of redeeming. It may sound harsh, but allowing an ineffective developer to remain on a team is a great way to kill both the team and the project.
My wife got an iPod nano for her birthday. She is also in the habit of getting books on CD from the library. The library recently started handing out DRMed copies of said books on CD, so my wife thought it would be quite neat to get one of those books and put it on her iPod.
Due to various problems with the library's web site it took her a few hours to download the books. Amusingly (for me), the library DRM turned out to be Microsoft's PlayForSure which doesn't play on iPod, for sure. I was able to witness firsthand what DRM does to Jane user: At first she was confused. Then she was annoyed. Then she asked me what was going on. Then she was furious.
Moral of the story: My wife will NEVER accept DRM ever again. She'd rather pick up a good old book at the library than waste any money on **AA's broken products, be it music or video.
I think the **AA industry overestimates its own importance. DRMed entertainment is not a necessity of life. Once time and space shiftable media such as CDs and DVDs disappear, we'll likely cease to consume any **AA media altogether. We've already cancelled our cable subscription due to the poor programming and amazingly annoying ads. There are better things to do.
Bollocks. Sarbanes-Oxley doesn't apply to engineering.
We got a number IT refusals explained by the magical SOX. So I went and read what it actually says. It doesn't mention engineering, their desktops or their servers. SOX is only concerned with financials.
Of course, IT wanted to treat all users and all servers the same. However, faced with the letter of the law, IT had no choice but to yield.
Well, if this goes anything like the tax collection in Europe you will have to register and pay tax to every state you happen to have customers in.
It's stupid. It's expensive. Excessive bureaucratic overhead is one of the many reasons Europe is lagging behind in growth. It also paid my bills for a while. Welcome to Europe.:-)
Was experience considered?
on
The H-1B Swindle
·
· Score: 2, Informative
While I'm sure there is some validity to the article, I do wonder whether the authors compared apples and oranges. What happens to an H1-B holder after a few years? He becomes a permanent resident. What also happens in that time-frame? His pay increases.
In other words, I strongly suspect that the data can partly be explained with the lower average experience (or time on the job, if you will) of H1-B holders. I certainly see that at my workplace.
I work for a quickly growing 600 employee company with a significant H-1B percentage. Part of my job is interviewing and recommending engineers. I have never been pressured to hire an H1-B candidate over a permanent resident or a citizen. Our one and only concern is qualification. I've also never seen a case where the hiring team's choice of a candidate was overruled on the basis of cost.
And you find senior citizens of advanced age cruising down the street in their caddy at 50 miles an hour any less scary?
Note: I have no beef with 99.9% of the senior population but my car was totaled by a member of the remaining 0.1% a few years back by him pulling onto a main street with blinders on. Daylight too. Luckily the old man survived without permanent injury. However, he'd have been better off letting someone else drive.
This happens all the time. And yes, it is mostly poor design caused by an EE doing a design without review from a CS dude.
It is microscopically cheaper to not provide a read path in hardware (both FPGA and ASIC) so there can be justification for that at times, but I have yet to see one that outweighs the debugging nightmares caused by it.
Let's say my power hungry laptop eats 100W. It doesn't but let's say it did.
Googling for some raw data
on cost yields a range of 3 to 43 cents per kilowatt hour. That computes to 0.3 to 4.3 cents per hour of laptop use.
There is no business on this planet that wouldn't be willing to fork out 4.3 cents an hour to keep customers happy. Nothing to see here, please move on.
A much overlooked factor may be the usually free local calls in the US. Other countries charge an arm and a leg for local calls in addition to the ISP provider's fee: I used to pay roughly $100 a month for local calls to my provider in addition to the ~$15 ISP fee - for two hours of daily use. Fortunately, moving to the US fixed that.
As it is, the cheap local calls serve as a disincentive for US households to switch whereas the expensive local calls elsewhere make broadband an economic solution for more than sporadic use.
Better yet, Xilinx also has FPGAs with up to four embedded PowerPC processors. These are the real deal, not IP cores that get compiled into the chip by the engineer. I suppose the difference to the part covered in the story is that the programmable logic can be reprogrammed on the fly, not so with this Xilinx part.
I do wonder how they deal with heat dissipation.:-)
Gates intentionally misses the point that most posters seem to be overlooking also. The reason hardware costs are what they are today is competition and commoditization. Ever since IBM made the "mistake" of opening the PC platform to competition, prices have been dropping and performance has been going up.
Conversely, with Microsoft's OS and office software monopoly firmly in place, prices have been going up and innovation has been stagnant. Can you point out any feature added to Word since 1997 that you actually need?
If you assume, as Gates obviously does, that Microsoft's monopoly will still be around in ten years, then his prediction that software will not be commoditized is correct. On the other hand, if OSS breaks Microsoft's monopoly on the desktop, mature software will be free (as in beer) and service will cost money.
Healthy would be if Microsoft were to be relegated to having to actually innovate to earn money while markets that have been around for a while open up to competition and get commoditized. If a software component is so mature that a handful of college students can replicate the functionality in their spare time, professional software makers should have to move on.
We see a little bit of that in the server market where Microsoft is having trouble leveraging its monopoly in order to kill the open source competition. Poor reliability and lack of embraced and extended standards that create lock-in have successfully thwarted all attempts by Microsoft to corner this market. Result: Choice, higher quality and lower prices.
Hopefully, Novell will be able to aggregate and focus the community's effort to dislodge Microsoft from the desktop monopoly sooner rather than later. Also hopefully, the increased visibility of Linux by way of the laughable SCO lawsuit and recent endorsements by HP, IBM and other fortune 500 giants will enable Linux to gain critical mass in this market too.
Last I checked SCO hasn't sued any Linux users for the alleged SCO IP in Linux despite promising to do so with hard deadlines twice.
DaimlerChrysler was sued for not responding to a licence audit asked for by SCO using a ball and chain clause of an ancient Unix license Chrysler bought in the nineties. AutoZone was sued for allegedly running SCO Unix binaries on Linux.
Win-win solution for anyone targeted by SCO: Ignore. They have no case and they know it. They will do their darnedest to not spend more lawyer salaries on lawsuits that don't jack up their stock.
That said, I have little pity for the EV1 CEO. If you don't know how to use Google to find out more about a strange company that is threatening to sue you, delegate or get out of the way.
First off, I don't use P2P (for legal or illegal activity) and I could care less whether it lives or dies. So much for the wishful thinking part. However...
Bandwidth: By tricking the P2P user into downloading, bandwidth is wasted that I would prefer to see put to other use. Whether that can be pinned on the authors is a different issue, but since the effect was intended I do suspect so.
Breaking into a computer system: Tricking a user into downloading code that does something unexpected by whatever method is breaking into a computer system in my book. And yes, it fits the wider interpretation of Trojan: "is a piece of unauthorized code hidden within a program" (from Google).
Computing time: I will concede this point. At first glance it looked like the trojan also intentionally wasted CPU cycles.
Illegal search: The definition of illegal search is all about expectation of privacy. You could argue that somebody intending to commit a copyright infringement has no expectation of privacy. On the other hand, since the user did not actually commit a copyright violation it can be argued that he did have an expectation of privacy which the trojan violated by phoning home.
Judging from the maturity level of the authors, I suspect the case would end up in juvenile court anyway.
No matter which way you turn it, this is a slam dunk for a prosectutor should one decide to go after you. You intentionally waste bandwidth of innocents (the ISPs), you break into a computer system without invitation, steal computing time and perform an illegal search.
IANAL, but I would recommend to shut the thing down right now and hope for the best. Not sure if contacting a lawyer is much help this very moment - the time to do that was before unleashing this code on the world. As it is, you might want to spend time on finding a good lawyer, I wouldn't put it past the FBI to break down your door in a few days. Your mileage will vary.
Afraid not. The loop would be between two "friendlies": Bob and yourself. The spammer would get a great laugh out of it - more wasted bandwidth and headache for you at no cost to him.
Solution is to prevent cr loops by caching previous cr response targets and not responding to them again.
Bob sends you an email and his MTA remembers that it sent an email to you
Your system sends a challenge message back.
Bob's system forwards the challenge to Bob since Bob initiated the contact.
Bob completes the challenge
You receive Bob's email
If Bob is a spammer it would not be economical for him to reply to your challenge.
The tricky part is when a spammer forges Bob's email address and sends you spam. That would cause a cr loop unless the MTA's were to remember who it has previously challenged.
The story of technology is the story of technical progress outpacing social progress.
I think you are making the common mistake of assuming that "social progress" exists. Last time I checked, the difference between cavemen and today's humans were negligible. To wit:
SUVs: Improve the protection of your own brood by endangering others.
Battery: 1.6 Million of cases of battery against women in the US every year.
Rape: According to the FBI, there are ~90000 (reported) rapes in the US annually.
Iraq: WMDs used as pretext for a personal vendetta.
To get back to the topic at hand: Whenever you leave an opening for someone to abuse, someone will abuse it. Until Microsoft get off their collective butt, spyware will happen.
Bandwidth is cheap to the point of being irrelevant in the music context. The cheapest I could find on short notice was 0.5 cent/GB. That turns into ~2 cents a song. And that isn't even wholesale price.
Somewhat different story for movies, of course. Sending the contents of a DVD at this rate would cost around $12 which is cost prohibitive.
The benchmarked configurations were Mac OS X on the G5, with GCC, and Linux on the PC gear, also with GCC.
But picking Linux as the test platform to run on is fair? I'd like to point out that 95% of all desktops run Windows. Also, what makes you think the scientific and technical users you refer to later on don't use Intel's C++/Fortran compilers for Linux when it matters? In my experience the speedup is quite dramatic, on the order of 30-40% faster - which is borne out also by Dell's posted SPEC benches: ~1200 for both int and float and 25(!) for rate (G5: 17). Ouch.
The only people who actually care about benchmarks are scientific and technical users. Everybody else cares about things like application availability, TCO, and ease of use.
Right. So why is Apple playing the performance flute so hard with the most unscientific comparisons I have ever seen right after air ionizers and snake oil?
Slashdot Mirror
Simply restrict the total body of law to n words. If the limit is reached, no new law can be passed until some other law is repealed. Reduce n by 2% annually until a reasonable minimum is reached.
Keep in mind that software patents hold little sway over the rest of the world. Taxing Linux in the US will just push Linux development and perhaps use abroad. It will also ensure that fewer countries will be willing to adopt software patents. This could be could news for the ongoing battle in the EU.
Considering that GW Bush's "vision" of human space exploration of the moon is crowding out much more productive and waaaay less expensive robotic exploration and even basic research at home, I'm even less convinced this is the right way forward. We could also consider the source, but we wouldn't want to get distracted by other failed visionary projects (such as democratizing the middle east by attacking Iraq) when evaluating a plan on its merits.
Certainly, human exploration is much more flashy and is the only type of exploration that captures the imagination of the average population. But what can we possibly learn from doing yet another moon mission? If you're looking to explore the universe, more systems like Hubble will do fine. If you're looking to explore the solar system, robotic probes go farther for a lot less. If you're looking for a microgravity environment, the ISS will do fine. If you're looking for a launch platform to Mars, the ISS or - for that matter - any old orbit around earth is much closer to home (read inexpensive).
Perhaps I'm missing. If so, I'd be happy to hear about it.
Good point. When I wrote that sentence I was thinking of the choice between formal testers vs. developers doing the testing. It didn't occur to me that somebody might consider shipping code without testing.
I think schedules are an interesting subject that can take pages to cover. A few thoughts anyway:
From architect on up, one of your key job responsibilities is to push back on features, schedules and so on, and to set expectations right from the get-go. Early on, I used to laugh out loud when being told proposed dates by marketing. That didn't go over too well, of course, so I've adopted a more diplomatic way of saying 'no' since. :-)
The gist of it is that many executives believe in Spanish management (very well explained in Peopleware). This boils down to setting ridiculous schedules, asking for continuous overtime, etc. The idea being that every minute an engineer spends more will get the product out the door faster. Of course, this is not the case as Peopleware will tell you in great detail. It is also matched by my own experience.
However, if you push back with data in hand (such as a detailed sizing) and a constructive proposal what to do differently, you may very well end up with a more reasonable schedule, a good product and happiness all around.
A few more gems in Peopleware:
- Schedules are counterproductive. Teams that don't have schedules ouperform those that do by up to 50%.
- Overtime is only productive for one week.
- Cubicles are sinkholes of effectiveness. Why do Microsoft and IBM only have offices for engineers?
Peopleware is rather sobering. Every other page you think "wait - we're doing exactly what is being described here." The good news is that you can do something about it once you can recognize the signs.For those of you with a humorous bent, I highly recommend checking out Joel Spolsky's articles on project management. A few highlights:
- Human task switching considered harmful
- Joel's test to identify bad software companies
As far as the TFA goes, once you've accepted an impossible schedule you're already hosed. If you can't push back, leave. The job market is good right now.If you can get to a reasonable schedule (by way of reducing features, adding time or people), the TFA is a bit limited in its scope. I have a few recommendations that have worked for me in the past (your mileage will vary, and you should read Peopleware anyway):
Due to various problems with the library's web site it took her a few hours to download the books. Amusingly (for me), the library DRM turned out to be Microsoft's PlayForSure which doesn't play on iPod, for sure. I was able to witness firsthand what DRM does to Jane user: At first she was confused. Then she was annoyed. Then she asked me what was going on. Then she was furious.
Moral of the story: My wife will NEVER accept DRM ever again. She'd rather pick up a good old book at the library than waste any money on **AA's broken products, be it music or video.
I think the **AA industry overestimates its own importance. DRMed entertainment is not a necessity of life. Once time and space shiftable media such as CDs and DVDs disappear, we'll likely cease to consume any **AA media altogether. We've already cancelled our cable subscription due to the poor programming and amazingly annoying ads. There are better things to do.
We got a number IT refusals explained by the magical SOX. So I went and read what it actually says. It doesn't mention engineering, their desktops or their servers. SOX is only concerned with financials.
Of course, IT wanted to treat all users and all servers the same. However, faced with the letter of the law, IT had no choice but to yield.
It's stupid. It's expensive. Excessive bureaucratic overhead is one of the many reasons Europe is lagging behind in growth. It also paid my bills for a while. Welcome to Europe. :-)
In other words, I strongly suspect that the data can partly be explained with the lower average experience (or time on the job, if you will) of H1-B holders. I certainly see that at my workplace.
I work for a quickly growing 600 employee company with a significant H-1B percentage. Part of my job is interviewing and recommending engineers. I have never been pressured to hire an H1-B candidate over a permanent resident or a citizen. Our one and only concern is qualification. I've also never seen a case where the hiring team's choice of a candidate was overruled on the basis of cost.
Note: I have no beef with 99.9% of the senior population but my car was totaled by a member of the remaining 0.1% a few years back by him pulling onto a main street with blinders on. Daylight too. Luckily the old man survived without permanent injury. However, he'd have been better off letting someone else drive.
It is microscopically cheaper to not provide a read path in hardware (both FPGA and ASIC) so there can be justification for that at times, but I have yet to see one that outweighs the debugging nightmares caused by it.
Let's say my power hungry laptop eats 100W. It doesn't but let's say it did. Googling for some raw data on cost yields a range of 3 to 43 cents per kilowatt hour. That computes to 0.3 to 4.3 cents per hour of laptop use.
There is no business on this planet that wouldn't be willing to fork out 4.3 cents an hour to keep customers happy. Nothing to see here, please move on.
As it is, the cheap local calls serve as a disincentive for US households to switch whereas the expensive local calls elsewhere make broadband an economic solution for more than sporadic use.
I do wonder how they deal with heat dissipation. :-)
Conversely, with Microsoft's OS and office software monopoly firmly in place, prices have been going up and innovation has been stagnant. Can you point out any feature added to Word since 1997 that you actually need?
If you assume, as Gates obviously does, that Microsoft's monopoly will still be around in ten years, then his prediction that software will not be commoditized is correct. On the other hand, if OSS breaks Microsoft's monopoly on the desktop, mature software will be free (as in beer) and service will cost money.
Healthy would be if Microsoft were to be relegated to having to actually innovate to earn money while markets that have been around for a while open up to competition and get commoditized. If a software component is so mature that a handful of college students can replicate the functionality in their spare time, professional software makers should have to move on.
We see a little bit of that in the server market where Microsoft is having trouble leveraging its monopoly in order to kill the open source competition. Poor reliability and lack of embraced and extended standards that create lock-in have successfully thwarted all attempts by Microsoft to corner this market. Result: Choice, higher quality and lower prices.
Hopefully, Novell will be able to aggregate and focus the community's effort to dislodge Microsoft from the desktop monopoly sooner rather than later. Also hopefully, the increased visibility of Linux by way of the laughable SCO lawsuit and recent endorsements by HP, IBM and other fortune 500 giants will enable Linux to gain critical mass in this market too.
DaimlerChrysler was sued for not responding to a licence audit asked for by SCO using a ball and chain clause of an ancient Unix license Chrysler bought in the nineties. AutoZone was sued for allegedly running SCO Unix binaries on Linux.
Win-win solution for anyone targeted by SCO: Ignore. They have no case and they know it. They will do their darnedest to not spend more lawyer salaries on lawsuits that don't jack up their stock.
That said, I have little pity for the EV1 CEO. If you don't know how to use Google to find out more about a strange company that is threatening to sue you, delegate or get out of the way.
Hate to rain or your parade, but I can't even remember the last time the US didn't have a trade deficit. Trade deficit: export negative.
First off, I don't use P2P (for legal or illegal activity) and I could care less whether it lives or dies. So much for the wishful thinking part. However...
Bandwidth: By tricking the P2P user into downloading, bandwidth is wasted that I would prefer to see put to other use. Whether that can be pinned on the authors is a different issue, but since the effect was intended I do suspect so.
Breaking into a computer system: Tricking a user into downloading code that does something unexpected by whatever method is breaking into a computer system in my book. And yes, it fits the wider interpretation of Trojan: "is a piece of unauthorized code hidden within a program" (from Google).
Computing time: I will concede this point. At first glance it looked like the trojan also intentionally wasted CPU cycles.
Illegal search: The definition of illegal search is all about expectation of privacy. You could argue that somebody intending to commit a copyright infringement has no expectation of privacy. On the other hand, since the user did not actually commit a copyright violation it can be argued that he did have an expectation of privacy which the trojan violated by phoning home.
Judging from the maturity level of the authors, I suspect the case would end up in juvenile court anyway.
IANAL, but I would recommend to shut the thing down right now and hope for the best. Not sure if contacting a lawyer is much help this very moment - the time to do that was before unleashing this code on the world. As it is, you might want to spend time on finding a good lawyer, I wouldn't put it past the FBI to break down your door in a few days. Your mileage will vary.
Solution is to prevent cr loops by caching previous cr response targets and not responding to them again.
- Bob sends you an email and his MTA remembers that it sent an email to you
- Your system sends a challenge message back.
- Bob's system forwards the challenge to Bob since Bob initiated the contact.
- Bob completes the challenge
- You receive Bob's email
If Bob is a spammer it would not be economical for him to reply to your challenge.The tricky part is when a spammer forges Bob's email address and sends you spam. That would cause a cr loop unless the MTA's were to remember who it has previously challenged.
I think you are making the common mistake of assuming that "social progress" exists. Last time I checked, the difference between cavemen and today's humans were negligible. To wit:
- SUVs: Improve the protection of your own brood by endangering others.
- Battery: 1.6 Million of cases of battery against women in the US every year.
- Rape: According to the FBI, there are ~90000 (reported) rapes in the US annually.
- Iraq: WMDs used as pretext for a personal vendetta.
To get back to the topic at hand: Whenever you leave an opening for someone to abuse, someone will abuse it. Until Microsoft get off their collective butt, spyware will happen.Somewhat different story for movies, of course. Sending the contents of a DVD at this rate would cost around $12 which is cost prohibitive.
But picking Linux as the test platform to run on is fair? I'd like to point out that 95% of all desktops run Windows. Also, what makes you think the scientific and technical users you refer to later on don't use Intel's C++/Fortran compilers for Linux when it matters? In my experience the speedup is quite dramatic, on the order of 30-40% faster - which is borne out also by Dell's posted SPEC benches: ~1200 for both int and float and 25(!) for rate (G5: 17). Ouch.
The only people who actually care about benchmarks are scientific and technical users. Everybody else cares about things like application availability, TCO, and ease of use.
Right. So why is Apple playing the performance flute so hard with the most unscientific comparisons I have ever seen right after air ionizers and snake oil?