Sorry, but ad-hominem attacks won't make your argument correct. I don't particularly care about the latest fads in academic linguistics anyway, since I'm looking at a communication protocol and telling you what the rules are, but take a look at this to see how you're wrong there as well:
It's obviously stupid to say that "the TCP/IP RFC's are prescriptivist nonsense!" Why can't you see that the same as true with Standard English, another communication protocol? You're avoiding the issue by claiming that there are different standards since they are separated only by geography. You can use Standard American English in the U.S. and RP in Britain in order to be correct in both places. The differences in the versions of the standards almost never result in ambiguity, though, so following one version of the standard is good enough to allow for natural language processing by any competent reader (native or otherwise). If you don't follow the standard, you make it harder for readers to understand you, especially those who/aren't/ native speakers. This is similar to bugs in inferior TCP/IP implementations needing workarounds in superior ones. By not folloowing the standard you force others to mentally correct your errors in order to understand you, even if they are able to understand you most of the time. Personally, I find that communication from people who have a large number of errors in their Standard English implementation is best dealt with by dropping their packets. Most educated non-native speakers are able to learn the correct rules for the language and apply them. Speakers who are unable to do this, especially if native, are often pretty stupid folk who don't have much interesting to say.
If your issue is that comprehending this protocol is difficult for you, there are several sources available in print and online you can use to educate yourself. Here's a pretty good one:
You've been following the standard well in your posts here, so you must understand what it is. If you understand the standard and use it to communicate effectively... what's your problem with it again?
> Most of our customers use large high end Sun's to power their back end settlement, STP, etc systems.
2/3 of Sun's servers shipped today run Linux, not Solaris. Are you sure they're not running Linux on those? You're probably wrong if you were just assuming.
As far as the rest of your comment, it's not really a response, in fact it supports my point. My parent was saying that "Linux is unheard of" in the financial space. Since you say that "some of our customers are switching back from Linux to Solaris", you prove my point that it is not unheard of. I don't particularly care if people are see-sawing back to Solaris at the moment. It's open-source too now and I don't have anything against it except that it doesn't fit my needs or personal tastes. I run Linux on my Ultra 10 mainly because I can't find a SPARC version of the Solaris zd1211 wireless driver.
> You are thinking that people speak incorrectly just because they don't mold their speech to artificial proscriptivist norms, but this is antiquated reasoning from the era when all languages had to be just like Latin (no split infinitives, prepositions at end of clause, etc.).
The standard defines what is correct. If a web page doesn't conform to the W3C, it is in error, and if someone's English writing doesn't conform to Standard English's grammar, it is likewise incorrect.
You're just trying to redefine words here, and I'm not going along with it.
> In commerce, AIX is still dominant, and Linux is unheard of.
You're insane. NYSE runs its stock-trading network on Linux for one example. Merrill Lynch has a large-scale Linux deployment too. I don't know anything about what the oil industry in particular uses (nor do I care), but this at least is wrong.
> Solaris is not only alive, but will remain that way for a while.
Of course. Open source OSes can only die if no one cares, and many people care about Solaris. Its driver support is far less mature than Linux's, but it's only a matter of time before it catches up. There's some cool stuff in Solaris that will eventually find its way into Linux, too. They're both good OSes and neither is going to kill the other.
> The RISC crowd simply underestimated the ingenuity of the CISC crowd.
All the CISC crowd did was effectively put a backward compatibility frontend onto a RISC processor. In fact, one of the 3 major x86 manufacturers licensed a MIPS core to use for the basis of their design.
> You can talk about the hypothetical failings of x86 all day long if you'd like. In actual implementation, aka reality, aka the only thing that matters, x86 chips have had rough performance parity -- sometimes slower, sometimes faster, but never a significant difference that could be attributed to the ISA -- with chips in similar market segments.
Well, first, the current state of the art is not "the only thing that matters". That's a very simplistic point of view, especially considering that ISAs must last decades into the future. As far as "performance for the market segment", well, that's not really a fair comparison for desktops and low-end servers given the massive economies of scale of the silicon industry. x86 has a cost advantage due to the simple fact that it's popular, and that's one of the two main reasons to use it, to answer the "ask slashdot". The other reason is that is supports obsolete (read: proprietary) software that can't be easily recompiled.
In spaces where x86 does not have a massive volume advantage, giving it this cost advantage, it's not true that x86 chips have performance parity. For equivalent speed, embedded x86 chips draw more power and take up more space than other architectures. Their main advantage, touted by the marketing people, is you don't need to cross-compile. Also, RISC processors blow x86 chips out of the water in high-end servers. It's just that everything's been getting faster, so fewer people are needing high-end servers.
> The performance of high-end servers has nothing to do with ISA, little to do with branch mispredict penalty, and everything to do with caches, memory, and system architecture. x86 has approached this space from the bottom, with 4-way Intel servers being their "high-end" for a long time while IBM had been calling machines with only 20 processors in them "mid-range" for years. IBM has a good server system architecture, Intel's system architecture sucks. The design of x86 has nothing to do with it. Opteron has a good system architecture, and if AMD could afford the gigantic caches of IBM then they'd be sitting pretty in the high-end space.
Maybe if the Opteron could do away with the chip area wasted by the dedicated x86 decoder, it could increase the cache size. Or maybe if the cache didn't have to deal with the complexity of helping decode x86 (yes, it does), the cache could be a larger size and still take up the same space. Also, I'm going to have to disagree with you about branch misprediction not being important in high-end servers.
> Intel attempted to get rid of x86 because they have cross-licensing agreements with AMD on x86 which IA-64 is not subject to. It failed because the implementations were late and relatively poor -- you might notice a theme of hypothetical ISA superiority not materializing in practice -- and more importantly AMD gave people what they really wanted: 64-bit but with backward compatability.
Why IA-64 failed is an argument in itself. I think it's because VLIW is not a good fit for general purpose server and desktop computers.
Also, the ISA superiority of RISC is borne out in practice. It's just that most of the time, performance doesn't matter enough to desktop and low-end server computer users to justify the cost of an ISA switch plus the cost of a lower-volume CPU.
You're correct about AMD64 helping kill Itanium.
> Sure, but the better question would be is it worth the cost to get that lost performance back. The cost is losing compatability with existing software. The benefit is in practice at best a percent of performance. I've been able to measure what happens when you get rid of x86's technical problems, and it isn't much. Programmers/compilers have le
You would be right if Windows came on the personal computer with no restrictions beyond copyright on its use, but Microsoft attempts to trick you into agreeing to restrictions beyond copyright after the sale. The EULA is not binding unless you agree to it, but since M$ attempts to make the software technically (not legally!) unusable unless you agree to it, you have the right to get your money back for Windoze since your acceptance of the EULA was not part of the sale, and you can't technically use the software unless you agree to it.
If I ever have to buy a computer with Windows again (see my blog; there are several Linux-preinstall / no-OS manufacturers you can buy from), I'm doing this.
If I'm stroking my ego anyway I might as well get $50 for it:)
I've heard of three successful attempts (one through a small-claims court action) and zero unsuccessful ones. Do you have any information outside of your personal speculation about the success rate?
> I've been feeling lately that clock speeds have plateaued. Both my last two laptops have had 2Ghz chips, granted i've moved from a Pentium M to a Core Duo, but we're seeing faster systems without spiraling clock rates.
This is correct -- they've actually decreased a little on average. Clock rate is only one factor that affects performance. AMD understood from the start that ultra-aggressive pipelining for the maximum possible clock rate would kill them on performance. Intel did not at first, hence the high power consumption of the Pentium 4, but later backed off and decreased the clock rate, focusing instead on IPC (which is what AMD had been doing for years).
> These arguments are as old as RISC itself, but the basis behind them has changed as the technology has changed. All of the performance, efficiency, and other technical arguments have been put to pasture in terms of actual implementations. In the end, it comes down to this:
The only reason not to use x86 is because it is an ugly mess that makes engineers who like elegance cry at night. The only reason to use x86 is because it runs the vast majority of software on commodity chips.
The fast "actual implementations" of x86 are done by translating x86 to RISC/in hardware/ as dynamically translating x86 instructions to RISC was the only way Intel could continue to achieve decent performance after the advent of pipelining. However, doing this lengthens the processor pipeline and makes things like branch mispredictions even more costly than they need to be. This is why x86 processors are still outperformed by RISC architectures in high-end servers and why Intel attempted, unsuccessfully, to remove the x86 albatross from its neck with the introduction of the Itanium.
The x86 ISA forces engineers to spend time working around its defects rather than improving performance or reducing power consumption. Dismissing the issues with it as "engineers who like elegance" crying will not make its technical problems go away. Our personal computers are not as fast as they would be if x86 had not become the standard ISA for them, and it is worth asking when we will be able to get this lost performance back.
> The question came up... why should we anyway? Every new computer comes with Windows and all the drivers preinstalled. We just have to spend 30 minutes uninstalling all the crap that comes with it.
You shouldn't be using the default Windows install anyway. You should be using an image. Default Windows installs sometimes have viruses and spyware (no, really, they do).
> And then how much of your infrastructure will you move to Linux? If you're not using an app that requires Windows you might in the future. The next version of that app might be dependent on.NET 2 which may not work under WINE, or newer versions of the computers you're using might not work with the Linux images you currently have on hand... more work to get things going..
Well, first, if it's on.Net you would be using Mono, not WINE, which already does support most of.NET 2. Second, WINE is really only suitable as a stopgap measure today; if you're being forced to use it you should be planning on changing to an alternative program anyway. Third, WINE will almost certainly support the new version of an app that is already working with it -- eventually. So if you insist on abusing WINE in the manner you describe, you might have to hold off on upgrading for a few months but that's it. As far as the images issue... you make new images for new computers, no matter what the OS is. (See above about default Windows installs.)
> You'll simply be less flexible. Not to mention if you get run over by a bus the next admin may not: >(a) know what the heck is going on in that setup If you document it properly, a competent admin will be able to understand it. >(b) know Linux in general If this firm would hire someone with no Linux experience to maintain a 100% Linux network, they have some serious HR policy issues. >(c) agree with the setup Why do you perceive this to be a problem?
The rest of your comment is ignorant drivel that doesn't deserve a response.
> (3) comprehensive driver support (sure I can get wireless to work with my Dell laptop under Linux but it is a pain, Mac users don't have to deal with such "costs");
As someone who has literally spent days trying to get wireless support to work on a friend's Apple desktop, after said friend bought the official "Apple"-branded wireless card, I'm going to have to beg to differ here. We ultimately gave up and she ran an Ethernet cord to the router instead.
> Has the Linux desktop ever gained more than ~1% of the desktop market?
It's currently around a little more than 3%. Reliable numbers are hard to come by, but IDC said Linux desktop shipments outpaced Macs (then ~2%) back in 2003 and was growing at a healthy rate. No one's made any noise about Linux losing market share (which they certainly would have if it had happened; M$ would have made sure of that).
I've tried very hard to find reliable information on this, and while I've been disappointed with the quality of information available, 3%, +/- 1%, is a good ballpark.
> Nor has performance ever been a problem. VM technology has seen amazing improvements over the past ten years, and is now such that for most non-trivial applications it is more performant than the compiled C/C++/Obj C equivalent. The success that Java has seen would not have been so tremendous if this were not true.
You're wrong. Java's success is due to the fact that programming in it requires less intelligence than programming in C or C++ because Java doesn't allow stupid people to make the stupid mistakes that they made in those languages. The penalties for this route are power and performance. Python's also seen tremendous success in recent years. Do you think it performs better than C or C++?
JIT compilation is not enough and has overhead of its own. EVERY real world test still shows C and C++ coming out on top by factors of 3 to 10. It's okay if you like Java (but... it's also gross); however, it's not okay to make obviously wrong statements like that one to promote it.
> It is not as if applications are developed with performance in mind anymore. Otherwise, all the software that I am using would be flying rather than crawling like 20 years ago.
You can write slow programs in any language. That's not the point.
If you spend a long time analyzing performance, and you care about it, you can write fast programs in C, C++, Fortran, and others.
If you wrote the equivalent program in Java and ran it in a JVM it would virtually always be slower. There are arguments that it wouldn't, hence the grandparents' claim, and they involve things like Just-In-Time compilation. However, these arguments are wrong, because real program performance bears out that C is still faster.
Cedega runs Everquest, WoW, Halo, and I think Halo 2. I don't have personal experience with it but other people have gotten it to work (according to Google).
Slashdot Mirror
Sorry, but ad-hominem attacks won't make your argument correct. I don't particularly care about the latest fads in academic linguistics anyway, since I'm looking at a communication protocol and telling you what the rules are, but take a look at this to see how you're wrong there as well:
/aren't/ native speakers. This is similar to bugs in inferior TCP/IP implementations needing workarounds in superior ones. By not folloowing the standard you force others to mentally correct your errors in order to understand you, even if they are able to understand you most of the time. Personally, I find that communication from people who have a large number of errors in their Standard English implementation is best dealt with by dropping their packets. Most educated non-native speakers are able to learn the correct rules for the language and apply them. Speakers who are unable to do this, especially if native, are often pretty stupid folk who don't have much interesting to say.
... what's your problem with it again?
http://en.wikipedia.org/wiki/Prescriptive
It's obviously stupid to say that "the TCP/IP RFC's are prescriptivist nonsense!" Why can't you see that the same as true with Standard English, another communication protocol? You're avoiding the issue by claiming that there are different standards since they are separated only by geography. You can use Standard American English in the U.S. and RP in Britain in order to be correct in both places. The differences in the versions of the standards almost never result in ambiguity, though, so following one version of the standard is good enough to allow for natural language processing by any competent reader (native or otherwise). If you don't follow the standard, you make it harder for readers to understand you, especially those who
If your issue is that comprehending this protocol is difficult for you, there are several sources available in print and online you can use to educate yourself. Here's a pretty good one:
http://www.grammarbook.com/
You've been following the standard well in your posts here, so you must understand what it is. If you understand the standard and use it to communicate effectively
> Most of our customers use large high end Sun's to power their back end settlement, STP, etc systems.
2/3 of Sun's servers shipped today run Linux, not Solaris. Are you sure they're not running Linux on those? You're probably wrong if you were just assuming.
As far as the rest of your comment, it's not really a response, in fact it supports my point. My parent was saying that "Linux is unheard of" in the financial space. Since you say that "some of our customers are switching back from Linux to Solaris", you prove my point that it is not unheard of. I don't particularly care if people are see-sawing back to Solaris at the moment. It's open-source too now and I don't have anything against it except that it doesn't fit my needs or personal tastes. I run Linux on my Ultra 10 mainly because I can't find a SPARC version of the Solaris zd1211 wireless driver.
> I used to be a developer ("Sr. Specialist in Debt Technology") at Merrill
How long ago? How do you know nothing has changed since you left?
I was basing my comment on stories such as this:
http://news.com.com/2100-1016_3-1014287.html
Are you saying these are just wrong?
> You are thinking that people speak incorrectly just because they don't mold their speech to artificial proscriptivist norms, but this is antiquated reasoning from the era when all languages had to be just like Latin (no split infinitives, prepositions at end of clause, etc.).
The standard defines what is correct. If a web page doesn't conform to the W3C, it is in error, and if someone's English writing doesn't conform to Standard English's grammar, it is likewise incorrect.
You're just trying to redefine words here, and I'm not going along with it.
> In commerce, AIX is still dominant, and Linux is unheard of.
You're insane. NYSE runs its stock-trading network on Linux for one example. Merrill Lynch has a large-scale Linux deployment too. I don't know anything about what the oil industry in particular uses (nor do I care), but this at least is wrong.
> Solaris is not only alive, but will remain that way for a while.
Of course. Open source OSes can only die if no one cares, and many people care about Solaris. Its driver support is far less mature than Linux's, but it's only a matter of time before it catches up. There's some cool stuff in Solaris that will eventually find its way into Linux, too. They're both good OSes and neither is going to kill the other.
> The RISC crowd simply underestimated the ingenuity of the CISC crowd.
All the CISC crowd did was effectively put a backward compatibility frontend onto a RISC processor. In fact, one of the 3 major x86 manufacturers licensed a MIPS core to use for the basis of their design.
> You can talk about the hypothetical failings of x86 all day long if you'd like. In actual implementation, aka reality, aka the only thing that matters, x86 chips have had rough performance parity -- sometimes slower, sometimes faster, but never a significant difference that could be attributed to the ISA -- with chips in similar market segments.
Well, first, the current state of the art is not "the only thing that matters". That's a very simplistic point of view, especially considering that ISAs must last decades into the future. As far as "performance for the market segment", well, that's not really a fair comparison for desktops and low-end servers given the massive economies of scale of the silicon industry. x86 has a cost advantage due to the simple fact that it's popular, and that's one of the two main reasons to use it, to answer the "ask slashdot". The other reason is that is supports obsolete (read: proprietary) software that can't be easily recompiled.
In spaces where x86 does not have a massive volume advantage, giving it this cost advantage, it's not true that x86 chips have performance parity. For equivalent speed, embedded x86 chips draw more power and take up more space than other architectures. Their main advantage, touted by the marketing people, is you don't need to cross-compile. Also, RISC processors blow x86 chips out of the water in high-end servers. It's just that everything's been getting faster, so fewer people are needing high-end servers.
> The performance of high-end servers has nothing to do with ISA, little to do with branch mispredict penalty, and everything to do with caches, memory, and system architecture. x86 has approached this space from the bottom, with 4-way Intel servers being their "high-end" for a long time while IBM had been calling machines with only 20 processors in them "mid-range" for years. IBM has a good server system architecture, Intel's system architecture sucks. The design of x86 has nothing to do with it. Opteron has a good system architecture, and if AMD could afford the gigantic caches of IBM then they'd be sitting pretty in the high-end space.
Maybe if the Opteron could do away with the chip area wasted by the dedicated x86 decoder, it could increase the cache size. Or maybe if the cache didn't have to deal with the complexity of helping decode x86 (yes, it does), the cache could be a larger size and still take up the same space. Also, I'm going to have to disagree with you about branch misprediction not being important in high-end servers.
> Intel attempted to get rid of x86 because they have cross-licensing agreements with AMD on x86 which IA-64 is not subject to. It failed because the implementations were late and relatively poor -- you might notice a theme of hypothetical ISA superiority not materializing in practice -- and more importantly AMD gave people what they really wanted: 64-bit but with backward compatability.
Why IA-64 failed is an argument in itself. I think it's because VLIW is not a good fit for general purpose server and desktop computers.
Also, the ISA superiority of RISC is borne out in practice. It's just that most of the time, performance doesn't matter enough to desktop and low-end server computer users to justify the cost of an ISA switch plus the cost of a lower-volume CPU.
You're correct about AMD64 helping kill Itanium.
> Sure, but the better question would be is it worth the cost to get that lost performance back. The cost is losing compatability with existing software. The benefit is in practice at best a percent of performance. I've been able to measure what happens when you get rid of x86's technical problems, and it isn't much. Programmers/compilers have le
You would be right if Windows came on the personal computer with no restrictions beyond copyright on its use, but Microsoft attempts to trick you into agreeing to restrictions beyond copyright after the sale. The EULA is not binding unless you agree to it, but since M$ attempts to make the software technically (not legally!) unusable unless you agree to it, you have the right to get your money back for Windoze since your acceptance of the EULA was not part of the sale, and you can't technically use the software unless you agree to it.
If I ever have to buy a computer with Windows again (see my blog; there are several Linux-preinstall / no-OS manufacturers you can buy from), I'm doing this.
:)
If I'm stroking my ego anyway I might as well get $50 for it
I've heard of three successful attempts (one through a small-claims court action) and zero unsuccessful ones. Do you have any information outside of your personal speculation about the success rate?
> From what I hear, PPC programs run twice as fast on a MacBook Pro as a Powerbook, and Universal binaries run four times as fast.
3
Don't know where you heard...
http://macslash.org/comments.pl?sid=5552&cid=9787
> They would be using IBM's fabs, which we know were not able to meet Apple's demand in the past.
Apple's demand is only 5% of IBM's fab capacity...
> In fact, aren't almost all x86 processors spectacularly bad at power consumption, with the exception of Intel's Core 2 sub-architecture?
Via / Centaur's processors are pretty good with power, though their performance isn't so great.
> AMD understood from the start that ultra-aggressive pipelining for the maximum possible clock rate would kill them on performance.
Ugh. That should have been power consumption.
"AMD understood from the start that ultra-aggressive pipelining for the maximum possible clock rate would kill them on power consumption."
Next time I'll use preview...
> I've been feeling lately that clock speeds have plateaued. Both my last two laptops have had 2Ghz chips, granted i've moved from a Pentium M to a Core Duo, but we're seeing faster systems without spiraling clock rates.
This is correct -- they've actually decreased a little on average. Clock rate is only one factor that affects performance. AMD understood from the start that ultra-aggressive pipelining for the maximum possible clock rate would kill them on performance. Intel did not at first, hence the high power consumption of the Pentium 4, but later backed off and decreased the clock rate, focusing instead on IPC (which is what AMD had been doing for years).
> These arguments are as old as RISC itself, but the basis behind them has changed as the technology has changed. All of the performance, efficiency, and other technical arguments have been put to pasture in terms of actual implementations. In the end, it comes down to this:
/in hardware/ as dynamically translating x86 instructions to RISC was the only way Intel could continue to achieve decent performance after the advent of pipelining. However, doing this lengthens the processor pipeline and makes things like branch mispredictions even more costly than they need to be. This is why x86 processors are still outperformed by RISC architectures in high-end servers and why Intel attempted, unsuccessfully, to remove the x86 albatross from its neck with the introduction of the Itanium.
The only reason not to use x86 is because it is an ugly mess that makes engineers who like elegance cry at night.
The only reason to use x86 is because it runs the vast majority of software on commodity chips.
The fast "actual implementations" of x86 are done by translating x86 to RISC
The x86 ISA forces engineers to spend time working around its defects rather than improving performance or reducing power consumption. Dismissing the issues with it as "engineers who like elegance" crying will not make its technical problems go away. Our personal computers are not as fast as they would be if x86 had not become the standard ISA for them, and it is worth asking when we will be able to get this lost performance back.
> The question came up... why should we anyway? Every new computer comes with Windows and all the drivers preinstalled. We just have to spend 30 minutes uninstalling all the crap that comes with it.
.NET 2 which may not work under WINE, or newer versions of the computers you're using might not work with the Linux images you currently have on hand... more work to get things going..
.Net you would be using Mono, not WINE, which already does support most of .NET 2. Second, WINE is really only suitable as a stopgap measure today; if you're being forced to use it you should be planning on changing to an alternative program anyway. Third, WINE will almost certainly support the new version of an app that is already working with it -- eventually. So if you insist on abusing WINE in the manner you describe, you might have to hold off on upgrading for a few months but that's it. As far as the images issue ... you make new images for new computers, no matter what the OS is. (See above about default Windows installs.)
You shouldn't be using the default Windows install anyway. You should be using an image. Default Windows installs sometimes have viruses and spyware (no, really, they do).
> And then how much of your infrastructure will you move to Linux? If you're not using an app that requires Windows you might in the future. The next version of that app might be dependent on
Well, first, if it's on
> You'll simply be less flexible. Not to mention if you get run over by a bus the next admin may not:
>(a) know what the heck is going on in that setup
If you document it properly, a competent admin will be able to understand it.
>(b) know Linux in general
If this firm would hire someone with no Linux experience to maintain a 100% Linux network, they have some serious HR policy issues.
>(c) agree with the setup
Why do you perceive this to be a problem?
The rest of your comment is ignorant drivel that doesn't deserve a response.
> That is why OEM Linux has disappeared from Walmart.com.
... don't know where you're getting that from...
_ id=3762912
Umm
http://www.walmart.com/catalog/product.do?product
They have at least one other too, with Xandros. Both "In Stock" last I checked...
> (3) comprehensive driver support (sure I can get wireless to work with my Dell laptop under Linux but it is a pain, Mac users don't have to deal with such "costs");
As someone who has literally spent days trying to get wireless support to work on a friend's Apple desktop, after said friend bought the official "Apple"-branded wireless card, I'm going to have to beg to differ here. We ultimately gave up and she ran an Ethernet cord to the router instead.
OpenOffice.org is that solution. Perhaps you just haven't used it for five years or so...
> Has the Linux desktop ever gained more than ~1% of the desktop market?
It's currently around a little more than 3%. Reliable numbers are hard to come by, but IDC said Linux desktop shipments outpaced Macs (then ~2%) back in 2003 and was growing at a healthy rate. No one's made any noise about Linux losing market share (which they certainly would have if it had happened; M$ would have made sure of that).
I've tried very hard to find reliable information on this, and while I've been disappointed with the quality of information available, 3%, +/- 1%, is a good ballpark.
> Nor has performance ever been a problem. VM technology has seen amazing improvements over the past ten years, and is now such that for most non-trivial applications it is more performant than the compiled C/C++/Obj C equivalent. The success that Java has seen would not have been so tremendous if this were not true.
... it's also gross); however, it's not okay to make obviously wrong statements like that one to promote it.
You're wrong. Java's success is due to the fact that programming in it requires less intelligence than programming in C or C++ because Java doesn't allow stupid people to make the stupid mistakes that they made in those languages. The penalties for this route are power and performance. Python's also seen tremendous success in recent years. Do you think it performs better than C or C++?
JIT compilation is not enough and has overhead of its own. EVERY real world test still shows C and C++ coming out on top by factors of 3 to 10. It's okay if you like Java (but
> It is not as if applications are developed with performance in mind anymore. Otherwise, all the software that I am using would be flying rather than crawling like 20 years ago.
You can write slow programs in any language. That's not the point.
If you spend a long time analyzing performance, and you care about it, you can write fast programs in C, C++, Fortran, and others.
If you wrote the equivalent program in Java and ran it in a JVM it would virtually always be slower. There are arguments that it wouldn't, hence the grandparents' claim, and they involve things like Just-In-Time compilation. However, these arguments are wrong, because real program performance bears out that C is still faster.
> And in this case indicates that racism is alive and well.
... no.
Reiser and his late wife were both white. So
Oh man I wish I had mod points to mod you funny ... that's the funniest thing I've read all day!
Cedega runs Everquest, WoW, Halo, and I think Halo 2. I don't have personal experience with it but other people have gotten it to work (according to Google).