The advantage of going with a VM is linear in program difficulty (compiler optimizations tend to be in % terms), but the overhead is generally constant (10 MB for the VM, for instance), so at some point any program that could actually stress a computer will be far enough out that a VM will help rather than hurt it. That day has been approaching for awhile. Another half a dozen good optimizations (like the above two), combined with full VM sharing, and it might be here.
Again, the theory is nice, but I'll believe it when I see it. Personally, I think theres a good reason why Transmeta chips aren't faster than AMD/Intel chips, and why despite being around and improved for years Java apps are still never used for really performance critical application cores.
In any case, if any VM language were to reach this theoretical line where it starts beating compiled languages (which I doubt in the near future, though one should never say never), I'd say C# is _probably_ likelier, as Java has some inbuilt inefficiencies due to early design decisions which have to be stuck to due to backward compatability which its very hard to hotspot out, which C# has somewhat avoided.
Perhaps the day you say is approaching is the same day that Linux takes over the desktop?:) We should really have included it in this poll - http://polls.slashdot.org/pollBooth.pl?qid=1158:).
Sure Hibernate is years ahead of any entity bean effort. But so is JDO already.
I find JDO and Hibernate both really nice technologies. The main difference being that JDO is a standard with multiple implementations (mostly commerical), vs Hibernate being a single open-source project, and that JDO uses code-morphing vs Hibernate just using reflection, which makes JDO more powerful but requires a post-compilation code-morphing stage.
If Sun would take either of these and replace the entity beans with them in the next J2EE spec that'd be great. But how do you come to the conclusion that JDO is basically going to be Hibernate?? JDO _is_ already on a level with Hibernate both in features and ease of use. JDO 2.0 brings a few good features missing from the JDO 1.x spec, but other than that is no major change.
The point is that in C++ and most other languages I can use the standard string class quite happily and its efficient and does all I need. In Java this simply isn't the case.
Isn't it rather pathetic that something like your example of
out.writeln("Cheese is "+good?"good":"bad")+"!");
is a 'bad thing' to do in Java? Personally I find it the natural way to do things, and much nicer than your second example. I hardly think I'm alone in this. Virtually all languages use the former idiom as opposed to the latter (or have an even nicer syntax). If you find the former not nice, I could suggest:
The String API isn't too shabby. It's much better than being forced into writting your own routines, or having to include 3rd party libraries to achieve the desired effect, which is the case with most compiled languages.
Huh???? C# provides a nice string class. So does C++. They're essentially Java's competitors, so no idea where you're coming from there.
And you just tell me what kind of graphical development environment works better in 256M of ram.
Visual Studio.NET for one.
I've done tests limiting Eclipse's memory with -Xmx. You can usually get it to run in 5M.
You can't be serious. It uses 100-200mb after I start it, open a decent sized project, and write say one line of code to get the code completion stuff all loaded into memory. This then just typically continually increases with every ant build until it throws an out-of-memory error at some point. If I were to tweak its startup parameters to use anything less that 128mb it would likely throw that out-of-memory error before it could even load the project.
If you're restricted to 64M, your hosting solution is obviously for trivial web applications.
The point is, 64M should also be sufficient for non-trivial websites. Theres some pretty non-trivial PHP websites which don't get near 64M memory usage (for that reason, hosts don't typically restrict memory usage for PHP-based sites).
I'm still not sure immutable Strings were a good idea, especially since it's become a common idiom to use StringBuffer instead for performance reasons.
Exactly. I've read Joshua Bloch's book and his justification for making strings immutable makes some sense, but if every speed conscious program has to avoid them then you have to wonder. Interesting however that this FastString you mention is also somehow immutable.
An interesting performance enhancer worth looking into is JADE, which contains FastString. It also has interesting realtime stuff which eliminates garbage collection overhead and pauses if used properly. Lots of other good stuff too
It is of course possible to include the JRE with your program, if you don't mind the added size to your installer. However we were discussing the particular situation where you require the user to additionally download and install the JRE themselves.
Regarding creating installers, I like to use NSIS personally.
For a long running enterprise application, it would probably be SLOWER in c/c++. No matter how good you are at programming c/c++ you can't anticipate every little bottleneck and write it in perfect assembler... but the hotspot compiler can do that rathar well.
Sounds nice in theory. In practice for most Java enterprise applications the memory usage is by far the biggest bottleneck. The hotspot compiler can't change this.
For example, I did a fair few speed tests working with strings in Java. For example, comparing various search and replace algorithms. The entire difference between the faster algorithms and the slower ones was how they handled the memory usage.
Strings are only a simple construct, but even with these Java is horribly inefficient unless great care is taken by the programmer to use them efficiently. In contrast, when programming C++ I can use strings paying scant regard to efficiency and know my code will virtually always be faster than any Java program doing the same thing.
despite entry level PCs now having specs along the lines of 2.5GHz processor and 256MB of RAM, lots of people on such sites are obssessed with perceived bloat
Well 256MB of RAM is barely adequate for most Java apps or development in my experience.
I've been doing server-side Java development for a little over 4 years now, and we've never had a performance problem.
Geez. I guess you've never tried running a non-trivial web application on a webserver where your Tomcat only gets allocated 64mb RAM (and where every extra mb costs you $$$ per month). Admittedly the idea that Java is slow usually comes from people using Swing which isn't an issue for server-side applications.
Java's popularity on mobile phones suggests it is hardly a performance bottleneck, nor is it too demanding for memory.
No. Rather, mobile phones offer something PCs don't - a pre-defined fixed amount of memory. This allows the Java programmers to code and test knowing exactly what constraints the end environment will have. That said, a lot of the work that goes into programming Java for mobile phones goes into ensuring these memory limitations are met.
Also, Java applications for mobile phones don't use Swing, which is often the culprit in giving people the impression that Java as a language is slow.
Expect C# to go through a similar slump as people realise it doesn't solve all your problems.
I'm not sure that C# has been marketed as the do everything language in the way that Java was. Its also been able to learn from Java's mistakes and thus avoid many of them. Java's backward compatibility constraints (which C# avoids with its versioning mechanisms) make it very hard for it to continue to keep pace (i.e. see Java's somewhat crippled upcoming implementation of generics vs.NET's upcoming implementation of them).
I agree with what you write in general - that the article was unduly harsh / biased against Java. However, I differ on a few details...
Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.
We're talking about the average Joe here. The average Joe just wants to double-click the installer for a program, click OK a couple of times, and have it work. I know from experience that such a requirement can be a great hinderance to adoption of a software application. I released a program with a.NET frontend, and a large portion of end-users weren't interested in downloading the.NET framework (why this wasn't made part of XP or at least XP SP1 I don't know) and would quite happily write the program off as broken despite it having informed them they need to download the.NET framework for it to run.
That's strange, it must be their inability to code an interface and data models in an efficient manner. I write warehouse control software, where we are dealing with vasts amount of data that must be collated and displayed to the user. Very rarely do we have to resort to doing major grunt work on the server as opposed to doing it in the Java client.
Swing _is_ rather unresponsive and slow unfortunately, due to it using no native widgets. This is solved by SWT, which mixes platform independence with use of native widgets where they exist. For this reason for example the popular Java IDE Eclipse (written with SWT) is much more responsive than Sun's IDE NetBeans. Swing in general is one of Java's major weaknesses (and its not 'excused' on the basis of platform independence) - not only in terms of speed but its layout managers for example are also a joke - and is the main reason why Java is used far far more for websites than application programs.
This could be rephraed as "bad Java programmers leak memory". I have client-server Java applications that run 24x7 without leaking memory.
I agree with you there, and would also add that 'very bad java programmers leak memory' while 'even pretty good C/C++ programmers leak memory. While one can leak memory in any language, Java does make it a lot easier to avoid. I have C++ programs where I've never found leaks despite a fair bit of work trying, yet I can't recall testing a single Java program for memory leaks (and I've written and tested a lot) and ever actually finding such a leak.
If this is really an issue for you, then you can tweak the runtimes environment. Yes, Java does requisition a lot of memeory when an untweaked JVM starts up, but the inmpact depends on the machine running the program.
Unfortunately for the average user with 'just' 256/512mb RAM on their machine, thrashing is almost an unavoidable consequence of using any non-trivial Java application. For development I find 1 gig RAM is a minimum for devloping with Java, whereas for.NET development I have no problems using 'just' 512 megs.
I might also add a thought relating to the actual editorial - comparing search results for 'NET' and 'Java' is hardly an accurate comparison, given that 'NET' is liable to find a lot more pages than just those relating to.NET. That said,.NET and its C# language _is_ a huge challenge for Java. I'm hoping that this competition will cause both languages to improve and thus benefit us developers. Java 1.5 (5.0) is a great start (incorporating many much needed features seen in.NET such as generics).
While the Intel chip performed well against the AMD one, hyperthreading appeared to perform badly (i.e. the Intel chip without hyperthreading enabled tended to beat the same chip with it enabled).
It would however be interesting to see a test that somehow say ran two of these benchmarks at the same time to see whether hyperthreading had an effect in such a case. Presumably most of the synthetic benchmarks especially don't really favour hyperthreading.
PLus the SQL test of the Athlon were in 32bit, not 64 bit (which would have resulted in a win for the athlon).
Why do you assume this exactly? The tested Intel chip is also 64-bit so would also presumably gain from the application being using the 64-bit instructions.
Right. I was just wanting to make clear what we mean when we say 'clone', as it wasn't clear originally whether you just meant the instruction set or more.
The Itanium is another story. I was however referring to some of the P4s, which Intel has for a while been selling with 64-bit capabilities there but simply disabled (as Intel didn't see a market for them, and obviously from a marketing perspective wants to hold back their introduction until its something that can be sold for extra $$$). Heres what a quick google on the topic came up with - http://www.xbitlabs.com/news/cpu/display/200403251 51223.html
Intel's chip obviously is a completely different design - i.e. it works differently internally. They copied the _instruction set_ to make the new 64-bit instructions compatible with the AMD chip's - seeing as AMD had got to the market first this was the logical thing to do. However its worth noting that Intel already had their own 64-bit chip designed beforehand - they just hadn't thought the market was there for a 64-bit chip just yet (thus letting AMD beat them to the gun).
If AMD hadn't released their chip first, Intel would have eventually released the same chip with a very similar in functionally but slightly different in looks instruction set. Thus the idea that Intel 'cloned' the AMD chip is a bit misleading. They simply modified it slightly to ensure compatibility with AMD's chip.
You call your parent a troll, yet totally confirm what he says - that 64-bit Linux is still basically beta, and that if Microsoft is also at the same stage as Linux in this regard it is fully justified in delaying the release of 64-bit XP, as it would obviously not be a 'good thing' to release beta-stage software as as a final product.
No, they're just the only big electronics company thats also a big music/movie business company, with an obvious huge conflict of interest which is crippling many of their electronics gadgets (this has been happening with the minidisc for years).
I took a quick look at StratFor and saw three opinion pieces ('analysis') as the main articles on the main page. Two of them ('Iraq Attacks: Militants Working Against Time' and 'Turkey: The Slow Pulling Away') present very debatable points of view. Thus, I'm struggling to understand why you consider StratFor to be 'impartial' in contrast to other news sources?
I would look into the site further, but I'm not fond of paying for online content.
Nothing in Moore's own defense contradicts the criticisms and the facts he avers to bely his arguments.
Well actually, you conventiently omit this part of Moore's rebuttel - 'Within 10 minutes, the "OK" came through from the firearms background check agency and, 5 minutes later, just as you see it in the film, they handed me a Weatherby Mark V Magnum rifle.'. Hes stating pretty clearly that the bank handed him the gun. Blows your argument apart sorry.
How can one have missed the boat when the Ballard stocks are wallowing around their lowest price since over 5 years, around a 1/20th of their peak. They're priced with the recognition that Ballard failed to fulfil their promises and that profits and mass-production are still 20 years away if ever.
If you believe that on the contrary Ballard has a bright future then they're currently a _real_ cheap buy.
Before everyone starts congratulating AMD's success and talking about the superiority of the Opteron and Intel's imminent demise etc etc, I thought it might be worth mentioning that AMD isn't the only company improving on the list:
A look at the hardware shows Intel Corp. making big gains on its competitors with a total of 287 machines are based on Intel chips, up from 119 this time last year.
I simply use a private wiki. The advantage being I can access it from work or at home or when travelling. Flexible enough to store a to-do list or store some bookmarks or whatever information you want to store. Lots of easy-to-install wiki software out there. I had previously quickly coded a simple PHP todo list but using existing wiki software is simpler and more powerful. Its not like a todo list requires some specialised software.
Take a look at wikipedia ( http://en.wikipedia.org/wiki/Biodiesel )
Biodiesel is commercially available in most oilseed-producing states in the U.S. At this time, it is considerably more expensive than fossil diesel, though it is still commonly produced in relatively small quantities (in comparison to petroleum products and ethanol). Many farmers who raise oilseeds use a biodiesel blend in tractors and equipment as a matter of policy, to foster production of biodiesel and raise public awareness. It is sometimes easier to find biodiesel in rural areas than in cities. Similarly, some agribusinesses and others with ties to oilseed farming use biodiesel for public relations reasons. In 2003 some tax credits are available in the U.S. for using biodiesel. In 2002 almost 3.5 million gallons (13,000 m) of commercially produced biodiesel were sold in the U.S., up from less than 0.1 million gallons (380 m) in 1998. Due to increasing pollution control requirements and tax relief, the U.S. market is expected to grow to 1 or 2 billion gallons by 2010. The price of biodiesel has come down from an average $3.50/gallon ($0.92/L) in 1997 to $1.85 ($0.49/L) a gallon in 2002. However this is still higher than petrodiesel which averaged about $0.85 ($0.22/L) a gallon in 2002 before road tax is added.
Whats the price of a gallon of petrol at the moment? Over $2 right? vs $1.85 for biodiesel, a price thats falling as production increases and economies of scale set in.
wikipedia goes into a lot of detail about the issues surrounding the use of sugarcane in brazil and elsewhere - the net efficiency, results in brazil etc as well as hydrogen as an 'alternative'.
could you perhaps provide evidence for this claim? the website the grandparent linked to claims only 6% of us land would be required to supply US demand and make the US energy independent from the rest of the world - a lot of land perhaps, but hardly matching your claim that 'You could replace all the cropland in the world with it, and you wouldn't cover worldwide motor fuel consupmtion. '.
also, as other posts have pointed to, brazil runs almost 50% ( http://autorepair.about.com/cs/generalinfo/a/aa102 100a.htm ) of its vehicles on pure ethanol. presumably the crops to supply this must be taking up the whole of brazil by your calculations?
someone please moderate the parent down if he can't justify his claims.
Slashdot Mirror
The advantage of going with a VM is linear in program difficulty (compiler optimizations tend to be in % terms), but the overhead is generally constant (10 MB for the VM, for instance), so at some point any program that could actually stress a computer will be far enough out that a VM will help rather than hurt it. That day has been approaching for awhile. Another half a dozen good optimizations (like the above two), combined with full VM sharing, and it might be here.
:) We should really have included it in this poll - http://polls.slashdot.org/pollBooth.pl?qid=1158 :).
Again, the theory is nice, but I'll believe it when I see it. Personally, I think theres a good reason why Transmeta chips aren't faster than AMD/Intel chips, and why despite being around and improved for years Java apps are still never used for really performance critical application cores.
In any case, if any VM language were to reach this theoretical line where it starts beating compiled languages (which I doubt in the near future, though one should never say never), I'd say C# is _probably_ likelier, as Java has some inbuilt inefficiencies due to early design decisions which have to be stuck to due to backward compatability which its very hard to hotspot out, which C# has somewhat avoided.
Perhaps the day you say is approaching is the same day that Linux takes over the desktop?
Sure Hibernate is years ahead of any entity bean effort. But so is JDO already.
I find JDO and Hibernate both really nice technologies. The main difference being that JDO is a standard with multiple implementations (mostly commerical), vs Hibernate being a single open-source project, and that JDO uses code-morphing vs Hibernate just using reflection, which makes JDO more powerful but requires a post-compilation code-morphing stage.
If Sun would take either of these and replace the entity beans with them in the next J2EE spec that'd be great. But how do you come to the conclusion that JDO is basically going to be Hibernate?? JDO _is_ already on a level with Hibernate both in features and ease of use. JDO 2.0 brings a few good features missing from the JDO 1.x spec, but other than that is no major change.
The point is that in C++ and most other languages I can use the standard string class quite happily and its efficient and does all I need. In Java this simply isn't the case.
Isn't it rather pathetic that something like your example of
out.writeln("Cheese is "+good?"good":"bad")+"!");
is a 'bad thing' to do in Java? Personally I find it the natural way to do things, and much nicer than your second example. I hardly think I'm alone in this. Virtually all languages use the former idiom as opposed to the latter (or have an even nicer syntax). If you find the former not nice, I could suggest:
String cheeseType = (good?"good":"bad);
out.writeln("Cheese is " + cheeseType + "\n");
The String API isn't too shabby. It's much better than being forced into writting your own routines, or having to include 3rd party libraries to achieve the desired effect, which is the case with most compiled languages.
Huh???? C# provides a nice string class. So does C++. They're essentially Java's competitors, so no idea where you're coming from there.
And you just tell me what kind of graphical development environment works better in 256M of ram.
.NET for one.
Visual Studio
I've done tests limiting Eclipse's memory with -Xmx. You can usually get it to run in 5M.
You can't be serious. It uses 100-200mb after I start it, open a decent sized project, and write say one line of code to get the code completion stuff all loaded into memory. This then just typically continually increases with every ant build until it throws an out-of-memory error at some point. If I were to tweak its startup parameters to use anything less that 128mb it would likely throw that out-of-memory error before it could even load the project.
If you're restricted to 64M, your hosting solution is obviously for trivial web applications.
The point is, 64M should also be sufficient for non-trivial websites. Theres some pretty non-trivial PHP websites which don't get near 64M memory usage (for that reason, hosts don't typically restrict memory usage for PHP-based sites).
Say for example you have a static HashMap in some class, and you keep on adding stuff to it without ever removing old stuff when its no longer in use.
:).
Note that I said _very bad java programmers_ leak memory
I'm still not sure immutable Strings were a good idea, especially since it's become a common idiom to use StringBuffer instead for performance reasons.
Exactly. I've read Joshua Bloch's book and his justification for making strings immutable makes some sense, but if every speed conscious program has to avoid them then you have to wonder. Interesting however that this FastString you mention is also somehow immutable.
An interesting performance enhancer worth looking into is JADE, which contains FastString. It also has interesting realtime stuff which eliminates garbage collection overhead and pauses if used properly. Lots of other good stuff too
That actually looks worth trying out thanks.
It is of course possible to include the JRE with your program, if you don't mind the added size to your installer. However we were discussing the particular situation where you require the user to additionally download and install the JRE themselves.
Regarding creating installers, I like to use NSIS personally.
For a long running enterprise application, it would probably be SLOWER in c/c++. No matter how good you are at programming c/c++ you can't anticipate every little bottleneck and write it in perfect assembler... but the hotspot compiler can do that rathar well.
Sounds nice in theory. In practice for most Java enterprise applications the memory usage is by far the biggest bottleneck. The hotspot compiler can't change this.
For example, I did a fair few speed tests working with strings in Java. For example, comparing various search and replace algorithms. The entire difference between the faster algorithms and the slower ones was how they handled the memory usage.
Strings are only a simple construct, but even with these Java is horribly inefficient unless great care is taken by the programmer to use them efficiently. In contrast, when programming C++ I can use strings paying scant regard to efficiency and know my code will virtually always be faster than any Java program doing the same thing.
despite entry level PCs now having specs along the lines of 2.5GHz processor and 256MB of RAM, lots of people on such sites are obssessed with perceived bloat
Well 256MB of RAM is barely adequate for most Java apps or development in my experience.
I've been doing server-side Java development for a little over 4 years now, and we've never had a performance problem.
Geez. I guess you've never tried running a non-trivial web application on a webserver where your Tomcat only gets allocated 64mb RAM (and where every extra mb costs you $$$ per month). Admittedly the idea that Java is slow usually comes from people using Swing which isn't an issue for server-side applications.
Java's popularity on mobile phones suggests it is hardly a performance bottleneck, nor is it too demanding for memory.
.NET's upcoming implementation of them).
No. Rather, mobile phones offer something PCs don't - a pre-defined fixed amount of memory. This allows the Java programmers to code and test knowing exactly what constraints the end environment will have. That said, a lot of the work that goes into programming Java for mobile phones goes into ensuring these memory limitations are met.
Also, Java applications for mobile phones don't use Swing, which is often the culprit in giving people the impression that Java as a language is slow.
Expect C# to go through a similar slump as people realise it doesn't solve all your problems.
I'm not sure that C# has been marketed as the do everything language in the way that Java was. Its also been able to learn from Java's mistakes and thus avoid many of them. Java's backward compatibility constraints (which C# avoids with its versioning mechanisms) make it very hard for it to continue to keep pace (i.e. see Java's somewhat crippled upcoming implementation of generics vs
I agree with what you write in general - that the article was unduly harsh / biased against Java. However, I differ on a few details ...
.NET frontend, and a large portion of end-users weren't interested in downloading the .NET framework (why this wasn't made part of XP or at least XP SP1 I don't know) and would quite happily write the program off as broken despite it having informed them they need to download the .NET framework for it to run.
.NET development I have no problems using 'just' 512 megs.
.NET. That said, .NET and its C# language _is_ a huge challenge for Java. I'm hoping that this competition will cause both languages to improve and thus benefit us developers. Java 1.5 (5.0) is a great start (incorporating many much needed features seen in .NET such as generics).
Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.
We're talking about the average Joe here. The average Joe just wants to double-click the installer for a program, click OK a couple of times, and have it work. I know from experience that such a requirement can be a great hinderance to adoption of a software application. I released a program with a
That's strange, it must be their inability to code an interface and data models in an efficient manner. I write warehouse control software, where we are dealing with vasts amount of data that must be collated and displayed to the user. Very rarely do we have to resort to doing major grunt work on the server as opposed to doing it in the Java client.
Swing _is_ rather unresponsive and slow unfortunately, due to it using no native widgets. This is solved by SWT, which mixes platform independence with use of native widgets where they exist. For this reason for example the popular Java IDE Eclipse (written with SWT) is much more responsive than Sun's IDE NetBeans. Swing in general is one of Java's major weaknesses (and its not 'excused' on the basis of platform independence) - not only in terms of speed but its layout managers for example are also a joke - and is the main reason why Java is used far far more for websites than application programs.
This could be rephraed as "bad Java programmers leak memory". I have client-server Java applications that run 24x7 without leaking memory.
I agree with you there, and would also add that 'very bad java programmers leak memory' while 'even pretty good C/C++ programmers leak memory. While one can leak memory in any language, Java does make it a lot easier to avoid. I have C++ programs where I've never found leaks despite a fair bit of work trying, yet I can't recall testing a single Java program for memory leaks (and I've written and tested a lot) and ever actually finding such a leak.
If this is really an issue for you, then you can tweak the runtimes environment. Yes, Java does requisition a lot of memeory when an untweaked JVM starts up, but the inmpact depends on the machine running the program.
Unfortunately for the average user with 'just' 256/512mb RAM on their machine, thrashing is almost an unavoidable consequence of using any non-trivial Java application. For development I find 1 gig RAM is a minimum for devloping with Java, whereas for
I might also add a thought relating to the actual editorial - comparing search results for 'NET' and 'Java' is hardly an accurate comparison, given that 'NET' is liable to find a lot more pages than just those relating to
While the Intel chip performed well against the AMD one, hyperthreading appeared to perform badly (i.e. the Intel chip without hyperthreading enabled tended to beat the same chip with it enabled).
It would however be interesting to see a test that somehow say ran two of these benchmarks at the same time to see whether hyperthreading had an effect in such a case. Presumably most of the synthetic benchmarks especially don't really favour hyperthreading.
Why do you assume this exactly? The tested Intel chip is also 64-bit so would also presumably gain from the application being using the 64-bit instructions.
Right. I was just wanting to make clear what we mean when we say 'clone', as it wasn't clear originally whether you just meant the instruction set or more.
1 51223.html
The Itanium is another story. I was however referring to some of the P4s, which Intel has for a while been selling with 64-bit capabilities there but simply disabled (as Intel didn't see a market for them, and obviously from a marketing perspective wants to hold back their introduction until its something that can be sold for extra $$$). Heres what a quick google on the topic came up with - http://www.xbitlabs.com/news/cpu/display/20040325
Intel's chip obviously is a completely different design - i.e. it works differently internally. They copied the _instruction set_ to make the new 64-bit instructions compatible with the AMD chip's - seeing as AMD had got to the market first this was the logical thing to do. However its worth noting that Intel already had their own 64-bit chip designed beforehand - they just hadn't thought the market was there for a 64-bit chip just yet (thus letting AMD beat them to the gun).
If AMD hadn't released their chip first, Intel would have eventually released the same chip with a very similar in functionally but slightly different in looks instruction set. Thus the idea that Intel 'cloned' the AMD chip is a bit misleading. They simply modified it slightly to ensure compatibility with AMD's chip.
You call your parent a troll, yet totally confirm what he says - that 64-bit Linux is still basically beta, and that if Microsoft is also at the same stage as Linux in this regard it is fully justified in delaying the release of 64-bit XP, as it would obviously not be a 'good thing' to release beta-stage software as as a final product.
No, they're just the only big electronics company thats also a big music/movie business company, with an obvious huge conflict of interest which is crippling many of their electronics gadgets (this has been happening with the minidisc for years).
I took a quick look at StratFor and saw three opinion pieces ('analysis') as the main articles on the main page. Two of them ('Iraq Attacks: Militants Working Against Time' and 'Turkey: The Slow Pulling Away') present very debatable points of view. Thus, I'm struggling to understand why you consider StratFor to be 'impartial' in contrast to other news sources?
I would look into the site further, but I'm not fond of paying for online content.
Nothing in Moore's own defense contradicts the criticisms and the facts he avers to bely his arguments.
Well actually, you conventiently omit this part of Moore's rebuttel - 'Within 10 minutes, the "OK" came through from the firearms background check agency and, 5 minutes later, just as you see it in the film, they handed me a Weatherby Mark V Magnum rifle.'. Hes stating pretty clearly that the bank handed him the gun. Blows your argument apart sorry.
How can one have missed the boat when the Ballard stocks are wallowing around their lowest price since over 5 years, around a 1/20th of their peak. They're priced with the recognition that Ballard failed to fulfil their promises and that profits and mass-production are still 20 years away if ever.
If you believe that on the contrary Ballard has a bright future then they're currently a _real_ cheap buy.
Before everyone starts congratulating AMD's success and talking about the superiority of the Opteron and Intel's imminent demise etc etc, I thought it might be worth mentioning that AMD isn't the only company improving on the list:
A look at the hardware shows Intel Corp. making big gains on its competitors with a total of 287 machines are based on Intel chips, up from 119 this time last year.
I simply use a private wiki. The advantage being I can access it from work or at home or when travelling. Flexible enough to store a to-do list or store some bookmarks or whatever information you want to store. Lots of easy-to-install wiki software out there. I had previously quickly coded a simple PHP todo list but using existing wiki software is simpler and more powerful. Its not like a todo list requires some specialised software.
Whats the price of a gallon of petrol at the moment? Over $2 right? vs $1.85 for biodiesel, a price thats falling as production increases and economies of scale set in.
wikipedia goes into a lot of detail about the issues surrounding the use of sugarcane in brazil and elsewhere - the net efficiency, results in brazil etc as well as hydrogen as an 'alternative'.
http://en.wikipedia.org/wiki/Alcohol_as_a_fuel
could you perhaps provide evidence for this claim? the website the grandparent linked to claims only 6% of us land would be required to supply US demand and make the US energy independent from the rest of the world - a lot of land perhaps, but hardly matching your claim that 'You could replace all the cropland in the world with it, and you wouldn't cover worldwide motor fuel consupmtion. '.
2 100a.htm ) of its vehicles on pure ethanol. presumably the crops to supply this must be taking up the whole of brazil by your calculations?
also, as other posts have pointed to, brazil runs almost 50% ( http://autorepair.about.com/cs/generalinfo/a/aa10
someone please moderate the parent down if he can't justify his claims.