checks into your inner decoding loop. The temptation to avoid doing this is strong, especially among "performance" oriented coders.
A good "performance oriented" coder would know better than to choose an algorithm whose safety depended on doing a test in an inner loop. He's probably used a series of bitmasks, AND's, and shifts to ensure that even if the values were out of range that they didn't cause problems.
As an assembly programmer, I've learned two very helpful techniques to avoid overwriting memory:
There is never good justification for checking array indexes. It's simply idiocy - array indexes can be safeguarded by simply taking the modulus of the index and the array size. By doing this, it is mathematically impossible to generate an out-of-bounds index. Why bother checking for something that can be handled automatically by the processor?
An even quicker method involves bitshifting or using the AND and negation operators. For example, if you know that you'll never render more than 1 Meg of memory, you can shift your index (32 bit) left 12 and right 12 and never ever write beyond the 1 MB boundary.
Performance programming is not simply leaving out vital checks. Rather, it is designing algorithms in such a manner that the checks are unnecessary, or performed at a level where they are easily handled. Even a good C++ programmer wouldn't think of starting to render a BMP before having validated all of his fields.
Good security is more a matter of developer foresight than anything else. Almost all of the security flaws known to date hinge on two factors:
The developer failed to foresee the manner in which his code could be used for malicious purposes.
The developer failed to build a security implementation that was practical for his intended users.
The first point applies to a lot of Microsoft software; the second, to a lot of software across the board. The fact that a sysadmin blames compromises on easily-guessed passwords is no solution at all - yes, the user is at fault, but the user wouldn't have chosen a bad password if the system of username/password wasn't broken in the first place. It seems that sysadmins and developers alike forget that ordinary people have to remember things far more important than the dozen or so username/password combinations that it takes to live in today's society...
We already have engines that run on Hydrogen. Ford has been making methane powered vehicles for the past 10-15 years. We've had usable solar power devices for 20-30 years.
The problem isn't that we don't have the technology; the problem is that fossil-fuel energy is simply more economically viable. The problem is that a $40,000 solar array would have to be in service, maintainence free, for 20 to 40 years before the owner would even begin to save money on electric bills. Even if the homeowner saves money on the 20th year and keeps his house another 20 years, he's only effectively earned $20,000 in savings. Contrast this with investing $40,000 in the stock market over the same time frame - the return is in the millions.
It's nice to have someone who actually replies with relevant points rather than spouting the all-too-familiar zealot mantra.
I agree that there are zealots on both sides, but the original discussion was about Microsoft's management practices. While this is a slightly offtopic for this thread, I would suggest that Microsoft is still no shining example of project management, because as a whole, they haven't done any better (and in many cases, much worse) than their peers. It seems that people have begun to equate financial success with genius, a rather unfortunate circumstance for those of us who actually do know how to bring a project in on time and to standard. (Though I'll freely admit I'm not one of them...)
If my job as a project manager is to ship software on time and bug-free, why would I listen to Microsoft, which has done neither?
Incidentally, my mother was a project manager for many years, and she managed to bring every project in on time, beating some deadlines by 50%. And bugs were simply not accepted - the project wasn't done until the bugs were corrected. Microsoft sets its own schedule, and they still can't ship bug-free software on time.
Microsoft has consistently impugned that non-commercial software quality can't possibly match the quality of commercial software because of the financial incentives and resources of the commercial software model.
So, according to Microsoft, there's no point to comparing their code against free/OS, because it couldn't be of better quality, right? So, for the sake of fairness, let's compare MS against their corporate peers:
They're still at the bottom of the software quality barrel.
For a commercial software vendor, their code quality comes in dead last. If we included free/OS, then they could use some of those abandoned projects to at least improve their credibility...
the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible.
[emphasis mine]
The first point is interesting; apparently, Microsoft doesn't know the majority of development work is multi-platform. I guess that in the Microsoft Universe(tm), if Microsoft can't do it, it can't be done... I am currently working on a rather large development project that will be used across at least two, if not three, major platforms. The overwhelming majority of developers must support multiple platforms because:
A vendor who writes an app that runs only on Windows risks Microsoft copying their idea and shutting them out of the business. Since MS almost never develops apps for non-Windows platforms, developing a cross-platform app is a hedge against MS stealing your ideas.
Cross-platform support is absolutely crucial for enterprise-level vendors. Most corporations want to leverage their existing server investments, and if you don't support the company's range of platforms, they won't be buying your application.
A large majority of internal development must be multi-platform because of legacy hardware.(yes, w2k and Windows98 count as separate platforms from a dev perspective). Just because your company has upgraded to Linux doesn't mean that there isn't a legacy Windows server lying around somewhere.
And the second point? Granted, Linux may be able to do multi-platform support rather well, but anyone who demands multi-platform support from Microsoft will get laughed out of the boardroom. It's not like they're going to care; you aren't spending their money to develop your application, and if it doesn't run on different platforms, it only increases their monopoly.
I don't think anyone would stoop so low as to say they put out the WORST product out in the market.
I don't want to get into a flame fest, but since you claim they don't produce the WORST product in the market, and since Windows is such a large part of their revenue, I challenge you to find:
An OS that is less secure than Windows.
An OS that crashes more frequently than Windows.
An OS with a EULA more restrictive than Windows.
Software which has slipped the scheduled release date more often and by a larger margin than Windows. IIRC, Microsoft hasn't released on OS on time in the last 10 years.
Please limit your responses to commercial vendors. Naturally, we'll exclude non-profit and free-software vendors because they couldn't possibly have the financial resources necessary to produce quality software.
Why is it that everyone looks to Microsoft for advice on code quality when, after 20 years of writing operating systems, they still can't keep it from crashing? Microsoft's genius lies not in their code quality, but in their marketing department. A study about how Microsoft markets their software would be much more enlightening; their code quality is nothing to which we should aspire.
It would be just another case of embrace and extend, right?
Those who rant about Microsoft often condemn them of shutting out competitors by adopting an open protocol or standard, and then extending that "standard" with additional MS-specific features. Witness kerberos, Java, C++, HTML, etc...
Which makes sense from a competitive standpoint - why would anyone buy Microsoft's version if the free version does exactly the same?
So, do we applaud them for adding extra features, or condemn them for breaking compatibility. And if we condemn them for breaking compatibility, what's our solution - do we expect Yahoo to sit by idly as other other clients add features? Wouldn't we then complain that Yahoo's client is outdated?
So, why does Yahoo get an exception from the "embrace and extend" argument? Or do we hate Microsoft "Just Because"?
Well, given the pull that MS has with Intel, they would have been ahead to demand this starting with the 286 when protected mode was introduced.
However, I'm wondering if they're not doing it to break Java. HotSpot requires compiling JVM bytecode to native instructions, which would require either writing to an executable segment (which could be disabled in the Pentium onward...) or executing machine instructions from a data area (which wouldn't work with NX enabled).
As much as it is useful, NX is also a nuisance to IDE's which compile the source into a memory region and execute that image. Visual Studio's debugger relies on being able to write to executable segments, and I'm wondering if this patch will break this.
It seems that these changes won't break any well-designed applications, with the exception of viruses and worms.
Granted, MS is taking a "giant leap backward" in compatibility - with viruses! Apparently, the author misses having Blaster auto-install itself upon reboot, and still longs for the days when he had to close 5 or 10 popups to view the web page he really wanted.
How could Microsoft do this? After having spent so much time and effort to guarantee that viruses would run on their platforms, now they pull the plug!? The NERVE!
Quite frankly, this is what they should have done a long time ago. If there's any fault to be found, it's that they didn't do this sooner. Any app which breaks because of these changes wasn't well designed in the first place, and deserves to break. As far as I can tell, none of the Windows apps I've written will be affected by this. The only reason MS estimates that 1 in 10 will be affected is because Microsoft considers viruses to be an application for marketing purposes. This way, they can legitimately claim that there are "50,000 applications written for Windows..." True, 45,000 are viruses, but that hardly matters now, doesn't it....
And for once, they're doing the right thing - they're telling users beforehand that this patch is going to break things, rather than letting the user find out unexpectedly... This is an improvement for them.
What this shows, more than anything, is that Microsoft clearly doesn't understand the enterprise market. What they fail to recognize is this:
Microsoft believes that as long as they supply patches, they've done their job. They consistently use the "unpatched machine" defense to explain the wave of machines hit by the latest worm or virus, seemingly unaware that an enterprise datacenter cannot be taken offline to apply patches. Even could downtime be found, a patch would first have to be tested, and only then applied to a production machine. A patch that breaks vital software won't ever get applied to a production machine.
Microsoft's response has typically been "reboot and reinstall" when a system becomes corrupted or crashes. This is completely unacceptable for an enterprise datacenter - a company cannot afford even a single hour of downtime during peak hours. Microsoft seemingly cannot grasp this key concept.
Corporations need a vendor who can gaurantee the reliability and uptime of their software. Microsoft does neither, but their competition does.
When figuring TCO, Microsoft conveniently forgets the cost of installing patches, and cleaning up after viruses and worms. This factor alone increases the TCO of Windows by at least an order of magnitude.
Microsoft just doesn't get it. Corporations could care less about streaming video and DirectX. And they aren't fooled by marketing hype - Microsoft can say all they want about "trustworthy computing", but sysadmins know better.
Lowenstein said game-copying software may facilitate theft of intellectual property, given that creating and marketing a top video game typically costs companies $5 million to $10 million. [emphasis mine]
Think of what would be legal if it "may facilitate" lawbreaking:
Cars - used by bankrobbers for a fast getaway.
Houses - used by criminals for drug use.
Pantyhose - used by criminals to disguise their identity...
The foremost problem I see with their logic is that they see any device or program which could be used for copyright circumvention as a device that will be used for such a purpose.
How would EA like it if I sued PC manufacturers because they were being used to pirate my manuscript? What if the computer was declared a circumvention device under the DMCA?. Where would EA be then?
They're literally shooting themselves in the foot. If I can't be assured that I can restore a game from a backup copy, I'm not going to buy that game. I can write my own games if I have to; can EA afford to lose my revenue?
For the sake of brevity, I assumed that a developer would be using the -server switch for development; since -client is the default, he'd either have to instruct his users on how to configure Java, or risk a slow runtime.
There's also the possibility that older JVM's may not perform as well as his development one...
Yes, I remember the Radio Shack NiCd's. I bought some, and that was the last time I bought rechargeables from RS. And, incidentally, that's where the 300mAH figure came from....
Reviewing the console log, we find that when java programs were tested with a large number of iterations, Java only performed better on one test.
We don't know which OS was used. While each C++ program must have been loaded entirely each time, the JVM may very well have remained cached in RAM between tests - hence a faster startup time, which explains:
Java is actually slower than C++, but because the JVM was already cached in RAM, it ran faster on those tests which involved a relatively small number of iterations. However, when the number of iterations was increased, Java was always slower than C++, with the exception method call and object instantiation:
Object instantiation isn't really relevant because of the fact that C++ programs call the OS for every single memory request, where as Java can pool it. This test measured the speed of the kernel's malloc more than the speed of C++.
In most of the C++ code, IO is placed in the inside loops, meaning that the program is really testing the throughput of libc and the OS, as opposed to the efficiency of the generated code.
An interesting note: the Java client won none of the benchmarks.
I know that Java has many strengths, but speed isn't one of them. Looking at the results, we see the g++ runtimes are much more consistent than those of Java - on some tests, the Java Server is faster than the client by a factor of 20!? How could a programmer code without having any realistic expectation of the speed of his code. How embarrassed would you be to find that your "blazingly fast" app ran slower than molasses on the client machine, for reasons yet unknown?
When it comes to speed, compiled languages will always run faster than interpreted ones, especially in real-world applications.
But discussions of language speed are a moot point. What this really tested was the implementation, not the language.
Speed is never a criteria upon which languages are judged - a "slow" language can always be brought up to speed with compiler optimizations (with a few exceptions). I suspect that if C++ was interpreted, and Java compiled, we'd see exactly the opposite results.
In short, the value of a language consists not in how fast it runs, but in what it enables the programmer to do.
Of course I know that there are tradeoffs in everything. Quite frankly, I'm surprised that we can run today's processors from batteries - when I got into electronics, a chip drawing 100 mA was considered a power hog. Today's CPU's draw what, 30 - 40 AMPS?! (~ 3V * 40A = 120W). Given that D-cell rechargeable NiCd's are about 300 mAH, they'd last about, oh, say, 30-40 seconds....
But sometimes its nice to push the envelope. I know x86 assembly; I don't need a 3.4 GHz processor for reasonable performance.
What I'd really like is something this small with a usable keyboard.
My dream machine is really a small, portable computer with keyboard attached:
It should weigh less than 2 pounds.
It should be small enough to fit in a large coat pocket, but not so small that the keyboard isn't usable.
It should use a "standard" battery, such as AA.
It should have about 10 hours of use on a single charge (NiCd rechargeables).
I should be able to use store-bought alkaline batteries in cases of emergency (travelling, etc...)
I'd want all of the standard ports - ethernet, usb, parallel, modem, etc.
x86 architecture would be a plus (8088?)
Should run Linux.
Instant on. (Think calculator fast)
20+ GB hd.
Color screen.
Should cost less than half a new desktop.
Almost everything I've found lacks at least one of the above features. I don't want a screamingly-fast system - I want a usable one which I can take with me anywhere. I want something inconspicuous - no whirring fans or overheating the lap.
What I'm asking for could probably be designed and built by a competent EE major in a matter of days, but I unfortunately don't know any EE majors anymore.
Ah, yes, but the idea of Windows crashing has not left them....
Oh, and how's your system restore work?
Thought so. Mine didn't work either. I've used XP, and it is junk. Try inserting an unreadable CDROM in the drive sometime, and watch XP become useless for about 5 to 10 minutes, if it recovers at all.
That bug has existed since Windows 95.
Granted, the days of Windows suddenly refusing to boot are probably past us, but the OS as a whole is still trash. To a Windows user, the aforementioned bug is crashing. Most people won't sit and wait for 10 minutes - they'll reboot the machine, "because it crashed on me."
And when this happens, they're reminded of all of the past problems they've had with Windows. In spite of any actual progress Microsoft might have made, it's these highly visible flaws which only reinforce the notion that Windows Crashes(tm). Users can never be too sure of their system's reliability because of the number of times in the past that crashes have happened without warning.
It's not so much the actual state of the software, but the fact the Microsoft has just released so many buggy versions of Windows that users can never be sure if the software will work or not. Granted, XP might not crash on your system, but too many people have burned too much midnight oil to restore crashed Windows boxes to go back to using Windows on the advice of just one person.
Anti-virus software and monthly security updates and bug patches.
The typical Windows user has become so adjusted to the idea of constant crashes, security holes, and bug fixes that they'll think Linux is somehow lacking if it doesn't provide them - constantly.
After all, viruses are a normal part of computer operation, right?
And should you try to convince them otherwise, they won't believe you. I've actually heard pro-Windows CS students say, "Well, it's impossible for a computer system not to crash from time to time..."
Sometimes I think that Windows is Bill Gates' revenge against all those kids who used to make fun of him on the playground. He charges Joe "corporate-fool" Sixpack exorbitant amounts of money for the software equivalent of a Pinto - sweet revenge indeed!
But the use of electric armour, which will protect against all shaped-charge warheads including artillery and tank shells, would reduce the threat to zero. [emphasis mine]
Which is BS if I ever heard it:
Artillery shells explode on impact; it's the gas overpressure wave which destroys the armor. This system would only increase the danger of artillery - a round that would formerly be unable to penetrate the armor could now destroy the vehicle. The explosion would first deform the outer plate to touch the armor; the electricity would then vaporize the vehicle's own armor, and the explosion would continue into the vehicle.
Anti-Tank rounds like the SABOT penetrate armor so quickly and have so much kinetic energy that the charge would probably not have enough time to vaporize the round before it penetrated the armor; even should it melt the round, the energy alone would force the liquid metal through the armor anyway. (Think about it - if a wall of compressed gas can penetrate armor, wouldn't liquified metal do the same? RPG's fail because they are relatively slow, but SABOT rounds carry no explosive - they rely on the speed of the projectile to provide armor penetration, not the use of a shaped charge).
Slashdot Mirror
A good "performance oriented" coder would know better than to choose an algorithm whose safety depended on doing a test in an inner loop. He's probably used a series of bitmasks, AND's, and shifts to ensure that even if the values were out of range that they didn't cause problems.
As an assembly programmer, I've learned two very helpful techniques to avoid overwriting memory:
Performance programming is not simply leaving out vital checks. Rather, it is designing algorithms in such a manner that the checks are unnecessary, or performed at a level where they are easily handled. Even a good C++ programmer wouldn't think of starting to render a BMP before having validated all of his fields.
Good security is more a matter of developer foresight than anything else. Almost all of the security flaws known to date hinge on two factors:
The first point applies to a lot of Microsoft software; the second, to a lot of software across the board. The fact that a sysadmin blames compromises on easily-guessed passwords is no solution at all - yes, the user is at fault, but the user wouldn't have chosen a bad password if the system of username/password wasn't broken in the first place. It seems that sysadmins and developers alike forget that ordinary people have to remember things far more important than the dozen or so username/password combinations that it takes to live in today's society...
Why?
Well, the short answer is because we like to eat.
We already have engines that run on Hydrogen. Ford has been making methane powered vehicles for the past 10-15 years. We've had usable solar power devices for 20-30 years.
The problem isn't that we don't have the technology; the problem is that fossil-fuel energy is simply more economically viable. The problem is that a $40,000 solar array would have to be in service, maintainence free, for 20 to 40 years before the owner would even begin to save money on electric bills. Even if the homeowner saves money on the 20th year and keeps his house another 20 years, he's only effectively earned $20,000 in savings. Contrast this with investing $40,000 in the stock market over the same time frame - the return is in the millions.
As to why you weren't modded up.
It's nice to have someone who actually replies with relevant points rather than spouting the all-too-familiar zealot mantra.
I agree that there are zealots on both sides, but the original discussion was about Microsoft's management practices. While this is a slightly offtopic for this thread, I would suggest that Microsoft is still no shining example of project management, because as a whole, they haven't done any better (and in many cases, much worse) than their peers. It seems that people have begun to equate financial success with genius, a rather unfortunate circumstance for those of us who actually do know how to bring a project in on time and to standard. (Though I'll freely admit I'm not one of them...)
Microsoft Math. It may not be right, nor on time, but it comes with a useful companion...
You actually replied to my post.
Maybe you're just trolling; I've never used Mac OS 9 for longer than a few hours, so I don't know. If you aren't, I'm glad I didn't "switch".
Where's the commercial OS worse than Windows?
If my job as a project manager is to ship software on time and bug-free, why would I listen to Microsoft, which has done neither?
Incidentally, my mother was a project manager for many years, and she managed to bring every project in on time, beating some deadlines by 50%. And bugs were simply not accepted - the project wasn't done until the bugs were corrected. Microsoft sets its own schedule, and they still can't ship bug-free software on time.
That's roughly one complaint every hour and 15 minutes for the past year.
At $11k per violation, the FCC made about $8800 per hour from the DNC list. (assuming ideal enforcement).
Microsoft has consistently impugned that non-commercial software quality can't possibly match the quality of commercial software because of the financial incentives and resources of the commercial software model.
So, according to Microsoft, there's no point to comparing their code against free/OS, because it couldn't be of better quality, right? So, for the sake of fairness, let's compare MS against their corporate peers:
They're still at the bottom of the software quality barrel.
For a commercial software vendor, their code quality comes in dead last. If we included free/OS, then they could use some of those abandoned projects to at least improve their credibility...
The first point is interesting; apparently, Microsoft doesn't know the majority of development work is multi-platform. I guess that in the Microsoft Universe(tm), if Microsoft can't do it, it can't be done... I am currently working on a rather large development project that will be used across at least two, if not three, major platforms. The overwhelming majority of developers must support multiple platforms because:
And the second point? Granted, Linux may be able to do multi-platform support rather well, but anyone who demands multi-platform support from Microsoft will get laughed out of the boardroom. It's not like they're going to care; you aren't spending their money to develop your application, and if it doesn't run on different platforms, it only increases their monopoly.
I don't think anyone would stoop so low as to say they put out the WORST product out in the market.
I don't want to get into a flame fest, but since you claim they don't produce the WORST product in the market, and since Windows is such a large part of their revenue, I challenge you to find:
Please limit your responses to commercial vendors. Naturally, we'll exclude non-profit and free-software vendors because they couldn't possibly have the financial resources necessary to produce quality software.
Why is it that everyone looks to Microsoft for advice on code quality when, after 20 years of writing operating systems, they still can't keep it from crashing? Microsoft's genius lies not in their code quality, but in their marketing department . A study about how Microsoft markets their software would be much more enlightening; their code quality is nothing to which we should aspire.
It would be just another case of embrace and extend, right?
Those who rant about Microsoft often condemn them of shutting out competitors by adopting an open protocol or standard, and then extending that "standard" with additional MS-specific features. Witness kerberos, Java, C++, HTML, etc...
Which makes sense from a competitive standpoint - why would anyone buy Microsoft's version if the free version does exactly the same?
So, do we applaud them for adding extra features, or condemn them for breaking compatibility. And if we condemn them for breaking compatibility, what's our solution - do we expect Yahoo to sit by idly as other other clients add features? Wouldn't we then complain that Yahoo's client is outdated?
So, why does Yahoo get an exception from the "embrace and extend" argument? Or do we hate Microsoft "Just Because"?
Well, given the pull that MS has with Intel, they would have been ahead to demand this starting with the 286 when protected mode was introduced.
However, I'm wondering if they're not doing it to break Java. HotSpot requires compiling JVM bytecode to native instructions, which would require either writing to an executable segment (which could be disabled in the Pentium onward...) or executing machine instructions from a data area (which wouldn't work with NX enabled).
As much as it is useful, NX is also a nuisance to IDE's which compile the source into a memory region and execute that image. Visual Studio's debugger relies on being able to write to executable segments, and I'm wondering if this patch will break this.
It seems that these changes won't break any well-designed applications, with the exception of viruses and worms.
Granted, MS is taking a "giant leap backward" in compatibility - with viruses! Apparently, the author misses having Blaster auto-install itself upon reboot, and still longs for the days when he had to close 5 or 10 popups to view the web page he really wanted.
How could Microsoft do this? After having spent so much time and effort to guarantee that viruses would run on their platforms, now they pull the plug!? The NERVE!
Quite frankly, this is what they should have done a long time ago. If there's any fault to be found, it's that they didn't do this sooner. Any app which breaks because of these changes wasn't well designed in the first place, and deserves to break. As far as I can tell, none of the Windows apps I've written will be affected by this. The only reason MS estimates that 1 in 10 will be affected is because Microsoft considers viruses to be an application for marketing purposes. This way, they can legitimately claim that there are "50,000 applications written for Windows..." True, 45,000 are viruses, but that hardly matters now, doesn't it....
And for once, they're doing the right thing - they're telling users beforehand that this patch is going to break things, rather than letting the user find out unexpectedly... This is an improvement for them.
I'm kind of heartened by it, as a matter of fact.
What this shows, more than anything, is that Microsoft clearly doesn't understand the enterprise market. What they fail to recognize is this:
Microsoft just doesn't get it. Corporations could care less about streaming video and DirectX. And they aren't fooled by marketing hype - Microsoft can say all they want about "trustworthy computing", but sysadmins know better.
Think of what would be legal if it "may facilitate" lawbreaking:
- Cars - used by bankrobbers for a fast getaway.
- Houses - used by criminals for drug use.
- Pantyhose - used by criminals to disguise their identity...
The foremost problem I see with their logic is that they see any device or program which could be used for copyright circumvention as a device that will be used for such a purpose.How would EA like it if I sued PC manufacturers because they were being used to pirate my manuscript? What if the computer was declared a circumvention device under the DMCA?. Where would EA be then?
They're literally shooting themselves in the foot. If I can't be assured that I can restore a game from a backup copy, I'm not going to buy that game. I can write my own games if I have to; can EA afford to lose my revenue?
For the sake of brevity, I assumed that a developer would be using the -server switch for development; since -client is the default, he'd either have to instruct his users on how to configure Java, or risk a slow runtime.
There's also the possibility that older JVM's may not perform as well as his development one...
Oops.
I knew Sun had been talking about HotSpot for a while, but I didn't know if they actually had a release yet.
Well, in that case, I'm kind of surprised that Java didn't do better than it did. It seems to me that Java is more lightweight than C++.
Yes, I remember the Radio Shack NiCd's. I bought some, and that was the last time I bought rechargeables from RS. And, incidentally, that's where the 300mAH figure came from....
Reviewing the console log, we find that when java programs were tested with a large number of iterations, Java only performed better on one test.
I know that Java has many strengths, but speed isn't one of them. Looking at the results, we see the g++ runtimes are much more consistent than those of Java - on some tests, the Java Server is faster than the client by a factor of 20!? How could a programmer code without having any realistic expectation of the speed of his code. How embarrassed would you be to find that your "blazingly fast" app ran slower than molasses on the client machine, for reasons yet unknown?
When it comes to speed, compiled languages will always run faster than interpreted ones, especially in real-world applications.
But discussions of language speed are a moot point. What this really tested was the implementation, not the language. Speed is never a criteria upon which languages are judged - a "slow" language can always be brought up to speed with compiler optimizations (with a few exceptions). I suspect that if C++ was interpreted, and Java compiled, we'd see exactly the opposite results.
In short, the value of a language consists not in how fast it runs, but in what it enables the programmer to do.
Of course I know that there are tradeoffs in everything. Quite frankly, I'm surprised that we can run today's processors from batteries - when I got into electronics, a chip drawing 100 mA was considered a power hog. Today's CPU's draw what, 30 - 40 AMPS?! (~ 3V * 40A = 120W). Given that D-cell rechargeable NiCd's are about 300 mAH, they'd last about, oh, say, 30-40 seconds....
But sometimes its nice to push the envelope. I know x86 assembly; I don't need a 3.4 GHz processor for reasonable performance.
What I'd really like is something this small with a usable keyboard.
My dream machine is really a small, portable computer with keyboard attached:
Almost everything I've found lacks at least one of the above features. I don't want a screamingly-fast system - I want a usable one which I can take with me anywhere. I want something inconspicuous - no whirring fans or overheating the lap.
What I'm asking for could probably be designed and built by a competent EE major in a matter of days, but I unfortunately don't know any EE majors anymore.
Ah, yes, but the idea of Windows crashing has not left them....
Oh, and how's your system restore work?
Thought so. Mine didn't work either. I've used XP, and it is junk. Try inserting an unreadable CDROM in the drive sometime, and watch XP become useless for about 5 to 10 minutes, if it recovers at all.
That bug has existed since Windows 95.
Granted, the days of Windows suddenly refusing to boot are probably past us, but the OS as a whole is still trash. To a Windows user, the aforementioned bug is crashing. Most people won't sit and wait for 10 minutes - they'll reboot the machine, "because it crashed on me."
And when this happens, they're reminded of all of the past problems they've had with Windows. In spite of any actual progress Microsoft might have made, it's these highly visible flaws which only reinforce the notion that Windows Crashes(tm). Users can never be too sure of their system's reliability because of the number of times in the past that crashes have happened without warning.
It's not so much the actual state of the software, but the fact the Microsoft has just released so many buggy versions of Windows that users can never be sure if the software will work or not. Granted, XP might not crash on your system, but too many people have burned too much midnight oil to restore crashed Windows boxes to go back to using Windows on the advice of just one person.
Anti-virus software and monthly security updates and bug patches.
The typical Windows user has become so adjusted to the idea of constant crashes, security holes, and bug fixes that they'll think Linux is somehow lacking if it doesn't provide them - constantly. After all, viruses are a normal part of computer operation, right?
And should you try to convince them otherwise, they won't believe you. I've actually heard pro-Windows CS students say, "Well, it's impossible for a computer system not to crash from time to time..."
Sometimes I think that Windows is Bill Gates' revenge against all those kids who used to make fun of him on the playground. He charges Joe "corporate-fool" Sixpack exorbitant amounts of money for the software equivalent of a Pinto - sweet revenge indeed!
Which is BS if I ever heard it: