OpenGL and other graphics api's are what I was refering to, i.e I never said write to the metal doing modern PC graphics.
Right. What you did say is that for "writing to the metal" you wouldn't use Java since it (presumably) isn't efficient enough due to its higher abstraction and cross-platform nature. My point is that OpenGL is also more abstract and cross-platform than "writing to the metal", but it is widely accepted as "good enough" performance wise, and of course the advantages of being card and platform independent outweigh the small performance advantage you'd gain "writing to the metal" anyhow.
This is analogous to the issue of whether "Java inneficiencies" outweigh the advantages it provides.
On consoles, possibly but you have to weigh the costs of doing so. Writing to the metal with modern graphics cards is difficult if not impossible due to the lack of low-level docs.
To be fair, the cards are designed so that OpenGL maps well to the underlying hardware. The idea of OpenGL is to provide a very thin API layer over the underlying hardware.
I have looked at JOGL, and many other GL to java bindings in the past. The fundamental problem with these are that they are what the are: Bindings. Underneath they are still using a JNI bridge to the native DLL which carries a not-so-insignificant overhead. I've had to deal with JNI performance issues on several projects. But you don't need to take my word for it, there is plenty of information regarding JNI and performance on the web.
There are altenatives, such as CNI in gcj (very little more overhead than a C to C call). There is an effort underway right now to port JOGL to gcj. That should be quite interesting, and I personally plan to use it for game development.
You're also taking my words out of context. There is a trade-off for speed vs. maintainability.
Not necessarily. Look at Ada, for instance. It produces very fast, yet very maintainable code. Again, to be fair, Ada provided easy access "to the metal". It is kind of sad that for all intents and purposes, Ada is dead - though it was also kind of ugly and cumbersome.;-)
In most cases, you can write a good 90% of your project using C++/Java/C#/ whatever because objects like GUI interfaces aren't usually speed critical. I'm refering to the last 10% that usually is speed critical. RTOS's and 3-D games have such "performance-critical" components and in that case you want native speed. So to counter your two arguments. 1. An INTERPERATED instruction will never match the speed of a machine code instruction on a PC, unless there is a hardware JVM. Therefore, in raw cycles, the same code written in java will be slower than the equivalent code in a compiled language.
Java can be natively compiled. See my other posts regarding gcj, TowerJ, Jet etc. So the entire interpreted vs. compiled argument is moot. I won't argue that the VMs can be as fast (though I'm also not convinced they can't) because I don't like the non-determinism of adaptive compilation in soft or hard realtime settings.
With JIT, some code may perform at the same level, but overall the compiled language will always get ahead. In most cases though, no one is going to notice a millisecond of difference. 2. There are a number of instances where you do want every last cycle of performance. RTOS's, video games (console and PC), video card drivers (in fact, just about any hardware drivers), satellite communication software, space probes, guidance systems, flight navigational systems, etc. etc. etc.
There is quite a bit of activity in the hard realtime Java area. Do some searching.
Direct access to hardware is not one of Java's strong suits.
Direct access to hardware isn't necessary, just an efficient C calling mechanism, for instance CNI.
I'm not saying java is a slow bloated pile. I've used java many times in projects. It does have it's place, especially if you need to run the same
Could? yes, but only if your fortram implementation is substantially better then your c++ implementation. If you use an equally decent compiler for both, then there should be no difference, esp. for the specific example you give (because numeric operations, while easier to express in fortran maybe, are not very difficult to translate and compile.
No, you missed (or didn't understand) this:
The stricter semantics of Java compared to C++ permit further optimization, as is the case with Fortran also, for instance.
The usual examples that are given are pointer aliasing problems, which C++ has, but Fortran and Java don't. In other words, it's not an issue of compiler implementation, but of language design.
The compiler could be written in any Turing-complete language, that's not the issue. The issue is the potential efficiency of the generated code.
Your overly simplistic argument of A vs. B. vs. C ignores important details of code optimization - as I tried to point out in my original post.
Clearer now...or not?
(Another point is that one could certainly write a C++ compiler in Java - would that mean that C++ couldn't possibly be faster than Java?)
You probably wouldn't want to use it for high-performance graphics for example, but it's great for developing most standard apps.
If you really need to eek out the last nanosecond of performance, do not use java. Java will never be able to match the speed of writing to the metal.
Yah, just like one wouldn't want to use a platform-independent lib like OpenGL to write high-performance graphics, you'd want to go straight to the metal...oh wait... (You should take a look at JOGL by the way.)
In the same vein, one would never want to use C++ for high-performance code, one would rather write straight C, or better yet assembler...ooops...
Your argument has two fallacies - one is that Java can never be as fast as C or FORTRAN (not true).
The second is that it is worth any amount of effort to pry the last few percent of performance out of a system (not true either, unless said lack of performance is a fatal error, i.e. hard realtime).
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.
Strings are something of a weak point with Java, IMO. 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. With the latest JDK there is a yet another new string class that's like StringBuffer without synchronization - since single-thread string manipulation is the most common usage.
All that said, if you know what you're doing, you can get fine string performance in Java. There are third party classes (see FastString) that may help as well. It is too bad that this area of the language wasn't better thought out in the first place, though.
(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.)
And anybody who doesn't believe this might want to take a look at why kast wasn't written in Java.
One doesn't have to look far to find claims there that are simply wrong. For instance:
java applications leak memory--- java uses garbage collection to manage memory, which seems to imply that programmers don't need to think about memory management at all. However, garbage collection gives a false sense of security, and java applications can still have memory leaks unless programmers are very careful. In fact, many java applications that run for extended periods of time leak memory to the point of exhausting all system memory. These types of leaks are very difficult for programmers to isolate. In fact, memory management may be more difficult with a garbage collector than without one.
In particular, the last sentence is nonsense. Memory leaks, once identified, aren't typically hard to find in Java - and let's not forget that Java eliminates several types of memory related errors common in C/C++ programs altogether. Array overruns, wild pointers, multiple deallocations - all things of the past. Thankfully.
Some of the other objections there will go away with JDK 1.5, others might best be addressed with ahead-of-time compilation (small utilities for instance). Regardless, Java is certainly improving over time.
All that said, of course, incompetent programmers will manage to screw up in any language they're given.;-)
A Java virtual machine IS a c++ program. The comparisons are illogical.
Really? What about gcj, TowerJ, Jet and other native Java compilers? There is nothing preventing Java from being compiled to straight machine code using traditional ahead-of-time compilation. The stricter semantics of Java compared to C++ permit further optimization, as is the case with Fortran also, for instance.
If a Fortran compiler were written in C++, would that still mean generated executables couldn't be faster than C++ at numeric code? No.
Runtime profiling/optimization is a more complex topic, but in principle (and apparently in practice) there are cases where it is faster than ahead-of-time compilation. I think both approaches have merit.
I usually like to make this point 2-3 times when it comes up on slashdot once per month.
Before there was a dot-com bubble to burst, I knew lots of *amazing* programmers and IT professionals who had non-IT degrees, so how is this new trend any different than before?
The difference is that the cat is out of the bag as far as people knowing that CS is a risky career in several respects - long hours, difficult work, offshoring, value dilution from OSS (sorry guys), and few new exciting software startups.
It's not just fewer CS majors, fewer people will be switching from other career areas, unless some of the above changes.
What really woke me up was their statement that only 6% of the worlds engineers are educated in the USA.
Since the U.S. only has ~5% of the worlds population, this isn't too out of line... However, I'm sure we have the capacity to educate more, it's just that people aren't choosing engineering careers for a variety of reasons. Also, don't forget that a substantial percentage of those educated in the U.S. head back to their native countries with the knowledge they've gained - and the percentage of U.S. educated foreign science/engineering grads is quite high.
Simply put, we need to interest more U.S. students in math and science AND provide real incentives to choose science/engineering careers.
If the latency is good as well then this puts hard drives to same, esp since it would have less if any moving parts.
It will have no moving parts (it is apparently Flash or some similar technology) and should have latencies in microseconds instead of milliseconds.
I note that Memory Stick also has a 2 TB upper limit, so I think that part of things is more a theoretical maximum instead of something we might see in the near term.
However, a 16 GB version might be a nice swap device for an 8 GB AMD64 box - if the price is right of course, and the max number of write operations is reasonable.;-)
OpenGL in an API, not a software package like the JDK. As far as implementations go, I suppose Mesa would be the "Java equivalent" in OpenGL-land, as it mainly does rendering in software
OpenGL is an API, but the hardware OpenGL drivers are just as much implementations as is Mesa (NVIDIAs Linux/X driver for instance). Mesa can also be hardware accelerated, IIRC. I think it has a DRI interface.
-- just like the AWT.
Nope, AWT (like SWT) uses native peers. You're thinking of Swing/JFC, where everything is rendered using software. Neither AWT or SWT is particularly slow, and in fact Swing isn't necessarily all that slow either.
Even with AWT/Swing, graphics is so sensitive to bandwidth of the graphics chip that true platform independence might be impossible.
Horse-pucky. There are loads of decent cross-platform GUI APIs, including GTK, Qt and wxWidgets. Some worked quite successfully when systems were 10x or more slower than today's. AWT/SWT should do fine on almost any current hardware (given sufficient memory of course).
Besides, in a few years, HDTV and X-Box2/PS3 will crush the PC gaming market. Why bother to sit in front of a PC that you have to upgrade every 3 months to keep up with Doom IV when you know that your console produces acceptable framerates?
Because Doom 4 (just like Doom 3) won't come out for a console - not enough horsepower. The PC-of-the-day will always be ahead on CPU power and RAM. Once a year has elapsed from the console introduction, the PC will also be ahead on GPU power. Consoles can't (and wouldn't want to) change models more often than once every 3-5 years. At least with PCs you can upgrade.
We'll see what the forthcoming "magic consoles" (PS3 and Xbox2) actually deliver on specs, but IIRC they're not expected to have more than 256 MB of RAM...
The open nature of PC development compared to the entry cost of console development also means many innovative, small development shops will develop for PCs first.
(BTW PCs also have the advantage of not tying up the "family HDTV" for six-twelve hours a night playing your favorite game...;)
With their disk array, when a disk fails you can't rebuild it online - you need to do it offline.
Not correct:
Doesn't Stop While You Swap
Xserve RAID drives feature true hot-swapping capabilities that allow a failed drive to be removed and replaced without a loss of data or interruption of service, thanks to the hardware RAID controller and the Apple-designed drive carrier. With Xserve RAID, the system continues to operate while the contents of the failed drive are rebuilt on a replacement drive, using redundant or parity information.
With price/GB 3x cheaper than Dell (and even less vs. IBM, HP and Sun), and certified Linux+Windows compatibility, I'd say Xserve is a pretty interesting product.
If you consider having less performance for most apps, no 64 bit x86 yet, and higher power consumption "winning". I don't. Intel's rush to copy everything AMD has done over the last couple of years shows where things really are.
The socket shuffle is no big deal, since by the time you want to upgrade your CPU you most likely will want a new motherboard too for new memory or other technologies. Motherboards aren't all that expensive regardless...
Each company should be in charge of auditing, testing and validating its products. It should also be noted that embedded realtime Linux distributions are much smaller than regular desktop/server distributions. Most DOD systems aren't accessible over a network, so that type of vulnerability is largely not a problem.
BTW, this complaint from Dowd is old news - it first surfaced this spring. Not many are buying his argument, from what I can tell.
Libertarians are just republicans who don't like the word "republican". sheesh. libertarians are the same as all the other politicians.
I disagree. Libertarians have very fundamental philosophical differences with Republicans, and in particular with the current crop of Republicans.
George Bush vowed to pursue smaller government, and instead vastly bloated it. IMO, that would never happen with a Libertarian President, if he were at all willing to stick to his ideals. Most likely he/she would, since Libertarian candidates are rarely career politicians.
The one area that I have concerns about in the Libertarian platform is it's foreign policy - I'm not sure that the U.S. can afford to back away from having a strong military at this point. In every other way, Libertarian leadership would be a great thing for the U.S.
Check out the website for the Libertarian presidential candidate. The banner ad on the front page says it all. (Also the article about Bill O'Reilly refusing to debate the Patriot Act with him is pretty funny...;)
You've merely been suckered by the spin that the PATRIOT Act is in some away a counter-terrorism measure, rather than noticing that the terrorism angle was just to stop you from noticing that the Bill of Rights was being recinded.
Actually, when the Patriot Act was passed there was considerable discussion regarding this exact issue, and assurances were made that the PA wouldn't be used except for clear-cut cases of terrorism.
Myth: The ACLU claims that the Patriot Act "expands terrorism laws to include 'domestic terrorism' which could subject political organizations to surveillance, wiretapping, harassment, and criminal action for political advocacy." They also claim that it includes a "provision that might allow the actions of peaceful groups that dissent from government policy, such as Greenpeace, to be treated as 'domestic terrorism.'" (ACLU, February 11, 2003; ACLU fundraising letter, cited by Stuart Taylor in "UnPATRIOTic," National Journal, August 4, 2003)
Reality: The Patriot Act limits domestic terrorism to conduct that breaks criminal laws, endangering human life. "Peaceful groups that dissent from government policy" without breaking laws cannot be targeted. Peaceful political discourse and dissent is one of America's most cherished freedoms, and is not subject to investigation as domestic terrorism. Under the Patriot Act, the definition of "domestic terrorism" is limited to conduct that (1) violates federal or state criminal law and (2) is dangerous to human life. Therefore, peaceful political organizations engaging in political advocacy will obviously not come under this definition. (Patriot Act, Section 802)
If the Patriot Act were invoked in this case, it is a clear abuse that should be quickly corrected. The FBI personnel involved should be severely reprimanded or fired. That is, I suppose, unless viewing SG1 DIVX movies is potentially fatal...;-)
However, this is an obvious example of the "slippery slope" problem the Patriot Act represents. Once new repressive legislation is enacted, people get used to it. Then the government starts to push the envelope. As long as this process is gradual, the public will be too caught up in "bread and circuses" (what is Jessica Simpson doing today, eh?;) to notice...at least that's the theory. Are you asleep?
Remember, Income Tax was originally supposed to be temporary. The government is not your friend. This is the case whether it's controlled by Republicans or Democrats.
"Those that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - BF
Newer coal plants trap most of the coal dust and many of the other polutants. They're actually getting much cleaner.
It's the old ones (especially in places like China) that are the problem.
Er, no. Especially if you think global warming is an issue. From the article you cite:
"Berry admitted that carbon dioxide was spewing from the Polk stack, but you couldn't see it."
Also:
Even so, compared with a typical coal-fired plant with modern pollution control devices, Polk produces 85% less nitrogen oxide and 32% less sulfur dioxide, according to Tampa Electric. Environmentalists are quick to point out that's still 20-times more nitrogen oxide than a natural gas fired plant and 100 times more sulfur. Natural gas emits virtually no sulfur.
It should be pointed out that's infinitely more carbon dioxide, nitrogen oxide, and sulfur than nuclear power plants emit.
Anyone here who purchases google stock at 108 a share is stupid as a rock.
The share price is going to drop like a rock within the first year, almost assuredly.
Based on the historical performance of IPOs I'd agree...the safest thing to do is certainly to wait a few months and let things settle out.
Take a look at RedHat's share price after it's IPO. Ran up to almost $200. I bought it for the first time at around $4.50 (granted this was after the.com bubble burst).
If you are considering investing, don't do it in American companies, do it overseas in the far east. Far more growth potential over there to offset any losses you will accumulate in stocks.
I'd recommend a mix weighted towards American companies, myself...IANAFA.
The Nasdaq is still WAY over valued as well as the big board.
In general stocks are going to burn badly in the next 2-4 years.
You must be predicting a Kerry victory...;-)
Stocks have a lot of upside, assuming there are no major economic or terrorist problems over the next few years. Many of the better tech stocks have P/E only in the 20ish range, which is quite low for that category.
The NASDAQ is at the same level as 1998...do you really think that's a fair valuation?
I like google, I use it daily. But I think the technology is WAY over hyped.
Hype or not only one thing matters - show me the EARNINGS!
Here's the link to the page for the actual license agreement in question - click on the "Royalty-Free Caller ID for E-Mail Specification License Agreement" link about halfway down to get the PDF.
Presumably the system automatically sends "one time pads" until it determines that one has been received without eavesdropping. It then transmits the message encoded by that one-time pad. Unbreakable and very simple if the quantum detection is working.
If you can provably detect eavesdropping, why bother with the pad?;-)
There's already a remedy for customers whose needs aren't being met . . . go someplace else. You don't have to watch CNN, or Fox News, or MSNBC, or others. Your choices will be more limited, but you DO have alternatives.
His entire point is that the number of alternatives is getting smaller - and also that all the large media companies have certain interests in common, which may distort their programming.
It's hard to imagine how we'll have a well informed, critically thinking populace if everyone's opinions are manufactured by a few homogenous companies... The only bright spot is the Internet, assuming it doesn't get too watered down.
Slashdot Mirror
Right. What you did say is that for "writing to the metal" you wouldn't use Java since it (presumably) isn't efficient enough due to its higher abstraction and cross-platform nature. My point is that OpenGL is also more abstract and cross-platform than "writing to the metal", but it is widely accepted as "good enough" performance wise, and of course the advantages of being card and platform independent outweigh the small performance advantage you'd gain "writing to the metal" anyhow.
This is analogous to the issue of whether "Java inneficiencies" outweigh the advantages it provides.
On consoles, possibly but you have to weigh the costs of doing so. Writing to the metal with modern graphics cards is difficult if not impossible due to the lack of low-level docs.
To be fair, the cards are designed so that OpenGL maps well to the underlying hardware. The idea of OpenGL is to provide a very thin API layer over the underlying hardware.
I have looked at JOGL, and many other GL to java bindings in the past. The fundamental problem with these are that they are what the are: Bindings. Underneath they are still using a JNI bridge to the native DLL which carries a not-so-insignificant overhead. I've had to deal with JNI performance issues on several projects. But you don't need to take my word for it, there is plenty of information regarding JNI and performance on the web.
There are altenatives, such as CNI in gcj (very little more overhead than a C to C call). There is an effort underway right now to port JOGL to gcj. That should be quite interesting, and I personally plan to use it for game development.
You're also taking my words out of context. There is a trade-off for speed vs. maintainability.
Not necessarily. Look at Ada, for instance. It produces very fast, yet very maintainable code. Again, to be fair, Ada provided easy access "to the metal". It is kind of sad that for all intents and purposes, Ada is dead - though it was also kind of ugly and cumbersome. ;-)
In most cases, you can write a good 90% of your project using C++/Java/C#/ whatever because objects like GUI interfaces aren't usually speed critical. I'm refering to the last 10% that usually is speed critical. RTOS's and 3-D games have such "performance-critical" components and in that case you want native speed. So to counter your two arguments. 1. An INTERPERATED instruction will never match the speed of a machine code instruction on a PC, unless there is a hardware JVM. Therefore, in raw cycles, the same code written in java will be slower than the equivalent code in a compiled language.
Java can be natively compiled. See my other posts regarding gcj, TowerJ, Jet etc. So the entire interpreted vs. compiled argument is moot. I won't argue that the VMs can be as fast (though I'm also not convinced they can't) because I don't like the non-determinism of adaptive compilation in soft or hard realtime settings.
With JIT, some code may perform at the same level, but overall the compiled language will always get ahead. In most cases though, no one is going to notice a millisecond of difference. 2. There are a number of instances where you do want every last cycle of performance. RTOS's, video games (console and PC), video card drivers (in fact, just about any hardware drivers), satellite communication software, space probes, guidance systems, flight navigational systems, etc. etc. etc.
There is quite a bit of activity in the hard realtime Java area. Do some searching.
Direct access to hardware is not one of Java's strong suits.
Direct access to hardware isn't necessary, just an efficient C calling mechanism, for instance CNI.
I'm not saying java is a slow bloated pile. I've used java many times in projects. It does have it's place, especially if you need to run the same
No, you missed (or didn't understand) this:
The usual examples that are given are pointer aliasing problems, which C++ has, but Fortran and Java don't. In other words, it's not an issue of compiler implementation, but of language design.The compiler could be written in any Turing-complete language, that's not the issue. The issue is the potential efficiency of the generated code.
Your overly simplistic argument of A vs. B. vs. C ignores important details of code optimization - as I tried to point out in my original post.
Clearer now...or not?
(Another point is that one could certainly write a C++ compiler in Java - would that mean that C++ couldn't possibly be faster than Java?)
If you really need to eek out the last nanosecond of performance, do not use java. Java will never be able to match the speed of writing to the metal.
Yah, just like one wouldn't want to use a platform-independent lib like OpenGL to write high-performance graphics, you'd want to go straight to the metal...oh wait... (You should take a look at JOGL by the way.)
In the same vein, one would never want to use C++ for high-performance code, one would rather write straight C, or better yet assembler...ooops...
Your argument has two fallacies - one is that Java can never be as fast as C or FORTRAN (not true).
The second is that it is worth any amount of effort to pry the last few percent of performance out of a system (not true either, unless said lack of performance is a fatal error, i.e. hard realtime).
Hope that helped...
Strings are something of a weak point with Java, IMO. 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. With the latest JDK there is a yet another new string class that's like StringBuffer without synchronization - since single-thread string manipulation is the most common usage.
All that said, if you know what you're doing, you can get fine string performance in Java. There are third party classes (see FastString) that may help as well. It is too bad that this area of the language wasn't better thought out in the first place, though.
(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.)
One doesn't have to look far to find claims there that are simply wrong. For instance:
In particular, the last sentence is nonsense. Memory leaks, once identified, aren't typically hard to find in Java - and let's not forget that Java eliminates several types of memory related errors common in C/C++ programs altogether. Array overruns, wild pointers, multiple deallocations - all things of the past. Thankfully.Some of the other objections there will go away with JDK 1.5, others might best be addressed with ahead-of-time compilation (small utilities for instance). Regardless, Java is certainly improving over time.
All that said, of course, incompetent programmers will manage to screw up in any language they're given. ;-)
Really? What about gcj, TowerJ, Jet and other native Java compilers? There is nothing preventing Java from being compiled to straight machine code using traditional ahead-of-time compilation. The stricter semantics of Java compared to C++ permit further optimization, as is the case with Fortran also, for instance.
If a Fortran compiler were written in C++, would that still mean generated executables couldn't be faster than C++ at numeric code? No.
Runtime profiling/optimization is a more complex topic, but in principle (and apparently in practice) there are cases where it is faster than ahead-of-time compilation. I think both approaches have merit.
I usually like to make this point 2-3 times when it comes up on slashdot once per month.
Repetition doesn't make it any more correct.
The difference is that the cat is out of the bag as far as people knowing that CS is a risky career in several respects - long hours, difficult work, offshoring, value dilution from OSS (sorry guys), and few new exciting software startups.
It's not just fewer CS majors, fewer people will be switching from other career areas, unless some of the above changes.
What really woke me up was their statement that only 6% of the worlds engineers are educated in the USA.
Since the U.S. only has ~5% of the worlds population, this isn't too out of line... However, I'm sure we have the capacity to educate more, it's just that people aren't choosing engineering careers for a variety of reasons. Also, don't forget that a substantial percentage of those educated in the U.S. head back to their native countries with the knowledge they've gained - and the percentage of U.S. educated foreign science/engineering grads is quite high.
Simply put, we need to interest more U.S. students in math and science AND provide real incentives to choose science/engineering careers.
It will have no moving parts (it is apparently Flash or some similar technology) and should have latencies in microseconds instead of milliseconds.
I note that Memory Stick also has a 2 TB upper limit, so I think that part of things is more a theoretical maximum instead of something we might see in the near term.
However, a 16 GB version might be a nice swap device for an 8 GB AMD64 box - if the price is right of course, and the max number of write operations is reasonable. ;-)
BTW the correct dimensions are 24x18x1.4 mm.
sorry, "their" (just trying to forestall grammar nazis;). And yeah, it really should be "it's" I suppose...
Gamers want the best - and right now that's AMD Athlon 64 (FX). Until Dell has that, they're stuff looks rather Dull. ;-)
OpenGL is an API, but the hardware OpenGL drivers are just as much implementations as is Mesa (NVIDIAs Linux/X driver for instance). Mesa can also be hardware accelerated, IIRC. I think it has a DRI interface.
-- just like the AWT.
Nope, AWT (like SWT) uses native peers. You're thinking of Swing/JFC, where everything is rendered using software. Neither AWT or SWT is particularly slow, and in fact Swing isn't necessarily all that slow either.
Even with AWT/Swing, graphics is so sensitive to bandwidth of the graphics chip that true platform independence might be impossible.
Horse-pucky. There are loads of decent cross-platform GUI APIs, including GTK, Qt and wxWidgets. Some worked quite successfully when systems were 10x or more slower than today's. AWT/SWT should do fine on almost any current hardware (given sufficient memory of course).
Yes, and you can bet it'll be a cut-down version that doesn't really compare to the PC version (which requires 384 MB RAM minimum among other things).
Because Doom 4 (just like Doom 3) won't come out for a console - not enough horsepower. The PC-of-the-day will always be ahead on CPU power and RAM. Once a year has elapsed from the console introduction, the PC will also be ahead on GPU power. Consoles can't (and wouldn't want to) change models more often than once every 3-5 years. At least with PCs you can upgrade.
We'll see what the forthcoming "magic consoles" (PS3 and Xbox2) actually deliver on specs, but IIRC they're not expected to have more than 256 MB of RAM...
The open nature of PC development compared to the entry cost of console development also means many innovative, small development shops will develop for PCs first.
(BTW PCs also have the advantage of not tying up the "family HDTV" for six-twelve hours a night playing your favorite game...;)
Not correct:
With price/GB 3x cheaper than Dell (and even less vs. IBM, HP and Sun), and certified Linux+Windows compatibility, I'd say Xserve is a pretty interesting product.
For accurate information, check the source.
If you consider having less performance for most apps, no 64 bit x86 yet, and higher power consumption "winning". I don't. Intel's rush to copy everything AMD has done over the last couple of years shows where things really are.
The socket shuffle is no big deal, since by the time you want to upgrade your CPU you most likely will want a new motherboard too for new memory or other technologies. Motherboards aren't all that expensive regardless...
Do you mean MontaVista, LynuxWorks, Metroworks, or some other company?
Each company should be in charge of auditing, testing and validating its products. It should also be noted that embedded realtime Linux distributions are much smaller than regular desktop/server distributions. Most DOD systems aren't accessible over a network, so that type of vulnerability is largely not a problem.
BTW, this complaint from Dowd is old news - it first surfaced this spring. Not many are buying his argument, from what I can tell.
It doesn't matter, due to clause (2):
Looks pretty simple to me...unless there is something quite sinister about this website that hasn't yet been brought to light.I disagree. Libertarians have very fundamental philosophical differences with Republicans, and in particular with the current crop of Republicans.
George Bush vowed to pursue smaller government, and instead vastly bloated it. IMO, that would never happen with a Libertarian President, if he were at all willing to stick to his ideals. Most likely he/she would, since Libertarian candidates are rarely career politicians.
The one area that I have concerns about in the Libertarian platform is it's foreign policy - I'm not sure that the U.S. can afford to back away from having a strong military at this point. In every other way, Libertarian leadership would be a great thing for the U.S.
Check out the website for the Libertarian presidential candidate. The banner ad on the front page says it all. (Also the article about Bill O'Reilly refusing to debate the Patriot Act with him is pretty funny...;)
Actually, when the Patriot Act was passed there was considerable discussion regarding this exact issue, and assurances were made that the PA wouldn't be used except for clear-cut cases of terrorism.
Here's an excerpt from the Patriot Act Myths government site:
If the Patriot Act were invoked in this case, it is a clear abuse that should be quickly corrected. The FBI personnel involved should be severely reprimanded or fired. That is, I suppose, unless viewing SG1 DIVX movies is potentially fatal... ;-)
However, this is an obvious example of the "slippery slope" problem the Patriot Act represents. Once new repressive legislation is enacted, people get used to it. Then the government starts to push the envelope. As long as this process is gradual, the public will be too caught up in "bread and circuses" (what is Jessica Simpson doing today, eh?;) to notice...at least that's the theory. Are you asleep?
Remember, Income Tax was originally supposed to be temporary. The government is not your friend. This is the case whether it's controlled by Republicans or Democrats.
It's the old ones (especially in places like China) that are the problem.
Er, no. Especially if you think global warming is an issue. From the article you cite:
Also: It should be pointed out that's infinitely more carbon dioxide, nitrogen oxide, and sulfur than nuclear power plants emit.The share price is going to drop like a rock within the first year, almost assuredly.
Based on the historical performance of IPOs I'd agree...the safest thing to do is certainly to wait a few months and let things settle out.
Take a look at RedHat's share price after it's IPO. Ran up to almost $200. I bought it for the first time at around $4.50 (granted this was after the .com bubble burst).
If you are considering investing, don't do it in American companies, do it overseas in the far east. Far more growth potential over there to offset any losses you will accumulate in stocks.
I'd recommend a mix weighted towards American companies, myself...IANAFA.
The Nasdaq is still WAY over valued as well as the big board.
In general stocks are going to burn badly in the next 2-4 years.
You must be predicting a Kerry victory... ;-)
Stocks have a lot of upside, assuming there are no major economic or terrorist problems over the next few years. Many of the better tech stocks have P/E only in the 20ish range, which is quite low for that category.
The NASDAQ is at the same level as 1998...do you really think that's a fair valuation?
I like google, I use it daily. But I think the technology is WAY over hyped.
Hype or not only one thing matters - show me the EARNINGS!
Too early in the morning I guess... ;-)
Here's the link to the page for the actual license agreement in question - click on the "Royalty-Free Caller ID for E-Mail Specification License Agreement" link about halfway down to get the PDF.
If you can provably detect eavesdropping, why bother with the pad? ;-)
His entire point is that the number of alternatives is getting smaller - and also that all the large media companies have certain interests in common, which may distort their programming.
It's hard to imagine how we'll have a well informed, critically thinking populace if everyone's opinions are manufactured by a few homogenous companies... The only bright spot is the Internet, assuming it doesn't get too watered down.