Clearly the fault of VMS and BeOS. Nothing to do with Microsoft's changing formats every twenty minutes to prevent compatability.
There comes a point at which the developers should decide not to chase the coattails of Microsoft, but choose to come up with their own solution instead. Rather than trying to be compatible with Exchange/Outlook, the goal needs to be to outright replace it.
With all these tech companies supposedly "selling" Linux solutions, the time has never been better to offer an Evolution client for Linux, Windows, and Mac that works with a feature-rich server on the order of Exchange Server. Yet there has been (to my knowledge) no real effort to improve the groupware solutions beyound straight-up LDAP, SMTP, IMAP, and NNTP. Those are great technologies, but they're not particularly good at providing a cohesive groupware solution. At least, not without some sort of design for how they could be used to provide the missing functionality. (Calendaring is perhaps the least addressed of the missing features.)
If such a server were developed, Linux would have a much better chance in Corporate America. Especially if the said server could keep ahead of Microsoft rather than behind them. Witness Firefox as an example. Microsoft slacked on IE (as they're prone to do when they have an uncontested lead) and paid the price by being surpassed. Exchange hasn't changed to any appreciable degree for a long time now, so the opportunity exists. Strike while the iron is hot.
But then again, what do I know? I'm just another developer in this crazy corporate world.
What they need, present tense, is another Blue Dragon, and another, so that people will have multiple reasons to want one, and to hope that more games they'll like will come out.
What they need is a Japanese development studio staffed by some of the hottest Japanese talent. Combine that with a free hand for the team to develop games that are appropriate to the culture, and the XBox 360 will do much better.
An excellent post, but I have to throw in a few minor corrections.
1. The "nanosecond" was a foot long piece of wire showing how far light travelled in that amount of time. The good Admiral used these wires to explain the latency in satellite communications. She later used them to show why computers needed to get smaller in order to get faster.
2. Admiral Grace Hopper was responsible for the design and development of the COBOL language. Fortran was invented by IBM's John Backus.
3. The travel of electrons is not electricity. The electrons "bumping" into each other (for lack of a better visual aid) is. Ever see those click-clack desk ornaments that consist of a number of steel balls suspended by two wires each? You know how when you set it in motion, the ball on one end transfers its energy to the ball on the other end without disturbing any of the balls in between? That's how electricity works.
Any delay in electrical transmission is actually caused by the space each electron needs to move in order to transfer its energy to the next electron down the line. This can be thought of more like bumper cars hitting each other. One car slams into the back of another car, which slides forward and slams into another car, which slides forward and slams into another car, ad infinitum. The energy transfer from car to car is nearly instantaneous, but delays are introduced by the empty space between each vehicle.
A CUDA-enabled GPU operates as either a flexible thread processor, where thousands of computing programs called threads work together to solve complex problems, or as a streaming processor in specific applications such as imaging where threads do not communicate. CUDA-enabled applications use the GPU for fine grained data-intensive processing, and the multi-core CPUs for complicated coarse grained tasks such as control and data management.
"CUDA gives us a whole new level of computing capability and enables closer access to the hardware," said Ryan Schneider, CTO of Acceleware Corp. "CUDA makes it possible for Acceleware's electromagnetic simulation and geophysical processing products to continue to double in speed each year, and, with our OEM partners like SPEAG, will enable us to address the needs of new markets such as biomedical imaging and reservoir modeling. The latest advancements from NVIDIA are helping to quickly push the boundaries of product development and commercial science."
They'd need a demonstration motherboard with, say, an Opteron and 8 or 16 of these theoretical GPU-derived chips that take in a stream of input, and spit out input that is then passed to a different computer for visualization.
What exactly is wrong with using a high speed bus to a super-computing coprocessor rather than packing in those same coprocessors onto a single CPU chip? The Cell only has one primary CPU + 8 SPEs that all require DMA transfers of data into their address space. That's not much different than shunting data streams over the PCIe bus, then copying the return data over the network using the primary CPU.
It's the same sort of architecture, except that you can be flexible about how many GPU cores and CPUs you place in your specific configuration.
That's why I run my web server on port 8080 when programming.
Good idea. I'll just tell all the developers to user port 8080.
Wait...
(rolls eyes)
In addition, you're assuming a lot about the development environment. One of those assumptions is that it's easy to use other ports. With various callbacks, SOAP interfaces, EJB servers, and whatnot, your ports not only fill up fast, but there may be too much code designed around existing port designations to make it practical.
There are also issues dealing with many servers that attempt to prevent more than one copy from running. (Normally, this is a feature.) They may open a fixed port, or hold onto a lock file, or pull a variety of other tricks that aren't so easy to get around.
Then there is Windows development (blech!) where you can only have one instance of an ActiveX control installed across the entire system. This not only sucks for developers, but it sucks for Windows servers which tend to breed like rabbits because of problems like these. I won't even go into problems like multiple.NET versions on IIS. (Though I hear that Microsoft has finally patched that one. Sort of.)
First thing you learn in professional programming: There's a huge gulf between what is possible and what is practical. It's a lot less hassle to simply give developers their own machines than to waste time on troubleshooting collisions.
Not to mention the excess computing resources used or outright crashes that a developer might accidently cause while debugging.
I'm pretty sure my emacs and gdb session takes less than a fifth of the memory used by Firefox or OOo, though.
Hello? McFly? See this bug?
while(i < 10); {
i++; }
Guess what it does. Want to guess how common it is?
How about this one?
for(int i=100; i>=0; i++) {
myobj = new MyObject(); }
Do you see it? That's what happens when you reverse a loop when you're used to doing it the other way around. And those are fairly benign examples of what you can frack up. You should see some of the multithreaded code people write. Ugh. Can you say, "Thread Bomb?"
And since when did debugging cause system crashes? For sure, I've never experienced that or anything even remotely like it. Is that some kind of Windows issue?
Then you're not doing anything involving. Fun things like changing the screen resolution and obtaining a DirectX context can crash or lockup your system. Or accessing external hardware at just the wrong time. (Yes, this happens on Unix as well. Though to somewhat lesser degrees due to focus on stablility rather than performance.) Never locked up an X-Session before? Then you're not doing anywhere near anything interesting.;)
Who needs root access? I need to be able to run web servers and the like. Having a dozen developers trying to open port 80 on the same machine is a problem. Not to mention the excess computing resources used or outright crashes that a developer might accidently cause while debugging.
I knew my Einstein-Rosen-Podolsky bridge machine was missing something! Computer circuits powered by Einstein-Bose Condensate! It's so simple! With this new invention, I'll be able to communicate with the machine back on my world, but never (for reasons yet unknown to science) tell it to retrieve me!
Hmm. That could be a problem. I better remember to set the timer...
16-bit software from the DOS days runs like crud on modern processors. But because of the constant die shrinks and Gigahertz updates, the software runs many, many, many times faster than was originally intended. So even a gross reduction in performance can still lead to a net gain for old software.:)
he problem with multicore computing power is not in the software developers but in the available tools. The problem with having say, 60 cores able to run in parallel is that our computation methods (turing based machine computation) are based on the basic "serial algorithm".
I think you're misunderstanding the subject here. The Cell Processor is designed for chewing through massive data sets at an unprecidented rate. It has almost nothing to do with multiprocessing, and everything to do with fast transformations and data analysis.
Take 3D programming as an example. Before I can render the screen, I have to run thousands of vertices through a matrix transformation so that they align with where the camera sees them. This is a bulk operation that can be run in parallel by multiple SIMD cores (each tranforming 2-4 vertices per instruction) by simply providing each core with a copy of the computational matrix. Simple, straightforward, and FAST. But utterly useless for general purpose code like multithreaded web servers.
So the problem is not a lack of tools. The problem is that the Cell is a specialized architecture that's very different from traditional multiprocessing. It's designed for long number-crunching applications that have traditionally been the forte of supercomputers. Ergo, it is a supercomputer on a chip.
I think what you meant was "attempts to parallelize the operations incorrectly may yield incorrect results."
Indeed. Thanks for the correction.:)
The example that you had given above where you manual converted an algorithm from sequential to potentially parallel processed could easily be handled by a compiler.
Of course. Which is why I showed exactly how the code could be handled in parallel. The key is that compilers already do this. Adding a new core won't help. It will just add overhead that will slow the program down rather than speeding it up.
VLC would benefit greatly from concurrent SIMD cores like the Cell Broadband Engine. Depending on the particular compression stream, the cores could be decoding multiple frames of video/audio in parallel at a much faster rate than a regular PC. Even if the particular compression stream didn't allow for multiprocessing, the SIMD design would still allow for the decompression stream to be completed in a fraction of the time it would take general purpose instructions to perform. (The exact fraction is dependent on how large the bits of data are. It could be as little as twice as fast, or it could easily be four times as fast.)
There are so many things wrong with this statement, that it's not even funny. You can't just recompile a program for multiprocessing. When we create computer programs, it is generally expected that future data processing will rely on past data processing. Attempts to parallelize the operations will give bad results. For example:
int a = 10; int b = 20; int c = 30;
a = b + c; c = a + b;
If you run the additions in a serial fashion, you get a = 50 and c = 70. If you run them in parallel, you get a = 50 and c = 30. Whoops.
Being a simplified example, of course, it is possible to parallelize the instructions above. It will require more memory, but we can do the following instead:
int a = 10; int b = 20; int c = 30; int d; int e;
d = b + c; e = b + c + b;
If the first addition is run on a separate core than the second processor, then we'll get a net increase in performance even though we used more computational cycles to compute the results. There's just one catch. CPU designers have known about these micro-optimizations for decades, and have been designing microprocessors with an ability called "Superscalar execution" for almost as long. Superscalar designs make use of CPU processing units not currently utilized by other instructions in order to offer a simplistic form of multithreaded execution on a single core. In this way, the CPU can chew on a larger number of instructions in parallel than it could if it fully serialized the execution. Which makes full multithreading mostly redundant for these situations.
In an InformationWeek article entitled 'Where's the Software to Catch Up to Multicore Computing?' the Chief Architect at IBM gives some fairly compelling reasons why your favorite software will soon be rendered deadly slow because of new hardware architectures.
*THUNK*
owww... my head...
There are a couple of serious problems with this statement. The most important one is that the article doesn't say that existing software will get slower. And there's a reason for that: Existing software will continue to run on the individual processor cores. Something that they've done for a long period of time. Old software may not get any faster due to a change in focus toward parallelism vs. increased core speed, but it's not going to suddenly come to a screeching halt any more than my DOS programs from 15 years ago are.
Secondly, multicore systems are not a problem. Software (especially server software!) has been written around multi-processing capabilities for a long time now. Chucking more cores into a single chip won't change that situation. So my J2EE server will happily scale on IBM's latest multicore Xenon PowerPC 64 processor.
Finally, what the article is really talking about is the difficulties in programming for the Cell architecture. Cell is, in effect, and entire supercomputer architecture shrunk to a single microprocessor. It has one PowerPC core that can do some heavy lifting, but its design counts on the programmers to code in 90%+ SIMD instructions to get the absolute fastest performance. By that, I mean that you need to write software that does the same transformation simultaneously across reasonably large datasets. (A simplification, but close enough for purposes of discussion.) What this means is that the Cell processor is the ultimate in Digital Signal Processor, achieving incredible thoroughput as long as the dataset is conductive to SIMD processing.
The "problem" the article refers to is that most programs are not targetted toward massive SIMD architectures. Which means that Cell is just a pretty piece of silicon to most customers. Articles like this are trying to change that by convincing customers that they'd be better served by targetting Cell rather than a more general purpose architecture.
With that out of the way, here's my opinion: The Cell Broadband Architecture is a specialized microprocessor that is perpendicular to the general market's needs. It has a lot of potential uses in more specialized applications (many of which are mentioned in the article), but I don't think that companies are ready to throw away their investment in Java,.NET, and PHP server systems. (Especially since they just finished divorcing themselves from specific chip architectures!) Architectures like the SPARC T1 and IBM's multicore POWER/PowerPC chips are the more logical path as they introduce parallelism that is highly compatible with existing software systems. The Cell will live on, but it will create new markets where its inexpensive supercomputing power will open new doors for data analysis and real-time processing.
Sounds like it would introduce a single point of failure.
It works both ways. A single point of failure becomes a single point of security. So it's a lot easier to make sure that everyone has the latest patches, and that the system is fully locked down. Besides, you rarely have only one server. You usually have a cluster of servers providing service to the users with the home directories on the network. If one goes bad, you can take it down and do maintenence on it while the users who were using it just log into a different server.
The truth is that there are very few business units that actually need their own desktop machines. The problem is that we developers are some of the few who actually need workstations, meaning that we often fail to push the best solution for the company as a whole.:)
I believe the point was that no matter how efficient the energy conversion process may be, in the end all the generated electricity will eventually be turned into heat as it's consumed.
While that's true, it's also true of all energy sources. When you tap tidal forces for electricity, you eventually transform that energy into waste heat. When you tap wind power, you eventually transform that energy into waste heat. When you tap direct solar power using solar panels, you're only adding latency to its conversion to heat.
So while it's technically true, it wouldn't be a very good argument against nuclear power.:-)
Ethanol is being used to reduce emissions on that small fraction of badly running automobiles out there. It does not have any effect on modern engines except to lower their mileage. Modern engines don't even require the "higher" octane rating, as they can compensate as required for slightly lower octane ratings.
This is an incredibly naive take on Ethanol consumption. The higher octane does have an effect. That effect is to burn the gasoline hotter and more completely, thus extracting energy than would have otherwise been extracted from a lower octane fuel.
It's true that in a pure-ethanol vehicle, you'll need more fuel to make up for lower energy density. However, the faster and hotter burn cycle can be compensated for, allowing engine designers to extract a fairly competitive amount of energy from the fuel.
The lower energy density just isn't that big of a deal when the choice is between needing 20% more Ethanol fuel at $2.50/gal vs. purchasing petroleum fuel at $3.75/gal.
Nuclear is still using "stored" power, thus can still have a net add to planetary heat.
This must be the oddest argument I've ever heard against nuclear power. First and foremost, any escaped heat is wasted energy that could have been used for electricity. So plants try to loose as little as possible. However, they do lose some, but nowhere near enough to have an impact on global conditions. "Global Warming" models are not based around how much heat that power plants release, but around concentrations of greenhouse gases that hold heat in. The theory is that if the concentrations were lowered, the Earth would be better able to radiate away the excess heat.
They will not post what they disagree with. Try telling any green environmental lefty that Ethanol is a bad thing and show them why, and they turn their nose saying, "But, but, but, but its GREEN!"
There's nothing wrong with Ethanol, save for studies 30 year out of date that are perpetuating the idea that it's energy negative. And it's not a "green" problem. It's a problem of finding an alternative fuel source before the rising prices of petrol cause too many economic problems.
As it so happens, Ethanol is being used as an ocatane-booster additive in the majority of gasoline today. In part, it's because it's safer than cleaner than most of the chemicals previously used to improve octane ratings. Another part of it, however, is that up to 10% Ethanol mixtures are helping to lower the cost of gasoline as the prices for gas surpass that of Ethanol.
things like 'Bonito Mussolini was named after a kind of tuna fish. He was born in the year 1726 and died of natural causes 800 years later'.
Putting aside the humor for a moment, such info would be self-defeating. Anyone paying even the slightest amount of attention is going to notice the problems. What you need is something more insidious. e.g.:
Bonito Mussolini was born in 1897 in Paris, France. He lived there until 1921 when he immigrated to Italy to escape Jewish persecution. In 1938 he was elected the leader of Italy. In his innagural speech, he promised the world that Italy would hold strong against the Axis forces. Unfortunately, Italy was conquered by Nazi Germany in 1941, forcing Mussolini into hiding. To prevent Mussolini from stiring up a revolt, Hilter conscripted a body-double of Mussolini to act as the ruler of Italy. The plot was successful, and Italy believed that they had switched sides to the Axis powers. It wasn't until after the war that Hitler's plot was exposed, but it was too late to save Mussolini's reputation. Mussolini moved to Egypt shortly thereafter where he continues to live today.
Put *that* in Wikipedia and I guarantee you'll hook a few suckers. (*shudder*) It's a good thing that the information is regularly checked and rechecked, making it unlikely that this would stay up long. Still...
I wonder how many of those professors had actually been misinformed.
This is quite true. I'm constantly amazed at how many people who should know better end up with misinformation. In fact, I think it happens to everyone to varying degrees. The problem with citing Wikipedia (or any Encyclopedia for that matter) is that it is a non-authoritive source. It becomes unclear whether the encyclopedia is at fault, or the person who believes it to be at fault. Citing authoritive sources clarifies who is correct. (Always the authoritive source, unless the other party knows that the source has been discredited.)
I've said it before, and I'll say it again. Wikipedia is a great place to start your research. It can even be perfect for solving quick arguments on the Internets. But it should never show up as a citation in any professional or educational context. Which is something one needs to keep in mind, as it's very easy to slip up and treat them as authoritive. They're not. They're just an encyclopedia.:)
One of the games (Gran Turismo I think) has the graphics of the N64.
GT Pro Series is probably what you're thinking of. (Gran Turismo is for the Playstation.)
And yeah, it makes me want to gouge my eyes out as well. Even if it was a Gamecube port, the 'Cube is capable of better graphics than those shown. What's up with that, Ubi?
Slashdot Mirror
With all these tech companies supposedly "selling" Linux solutions, the time has never been better to offer an Evolution client for Linux, Windows, and Mac that works with a feature-rich server on the order of Exchange Server. Yet there has been (to my knowledge) no real effort to improve the groupware solutions beyound straight-up LDAP, SMTP, IMAP, and NNTP. Those are great technologies, but they're not particularly good at providing a cohesive groupware solution. At least, not without some sort of design for how they could be used to provide the missing functionality. (Calendaring is perhaps the least addressed of the missing features.)
If such a server were developed, Linux would have a much better chance in Corporate America. Especially if the said server could keep ahead of Microsoft rather than behind them. Witness Firefox as an example. Microsoft slacked on IE (as they're prone to do when they have an uncontested lead) and paid the price by being surpassed. Exchange hasn't changed to any appreciable degree for a long time now, so the opportunity exists. Strike while the iron is hot.
But then again, what do I know? I'm just another developer in this crazy corporate world.
The 360 has about the same footprint as the PS3. Especially since the lastest craze is to flip the consoles on their sides.
An excellent post, but I have to throw in a few minor corrections.
:)
1. The "nanosecond" was a foot long piece of wire showing how far light travelled in that amount of time. The good Admiral used these wires to explain the latency in satellite communications. She later used them to show why computers needed to get smaller in order to get faster.
2. Admiral Grace Hopper was responsible for the design and development of the COBOL language. Fortran was invented by IBM's John Backus.
3. The travel of electrons is not electricity. The electrons "bumping" into each other (for lack of a better visual aid) is. Ever see those click-clack desk ornaments that consist of a number of steel balls suspended by two wires each? You know how when you set it in motion, the ball on one end transfers its energy to the ball on the other end without disturbing any of the balls in between? That's how electricity works.
Any delay in electrical transmission is actually caused by the space each electron needs to move in order to transfer its energy to the next electron down the line. This can be thought of more like bumper cars hitting each other. One car slams into the back of another car, which slides forward and slams into another car, which slides forward and slams into another car, ad infinitum. The energy transfer from car to car is nearly instantaneous, but delays are introduced by the empty space between each vehicle.
I hope that clarifies a bit.
It's the same sort of architecture, except that you can be flexible about how many GPU cores and CPUs you place in your specific configuration.
Wait...
(rolls eyes)
In addition, you're assuming a lot about the development environment. One of those assumptions is that it's easy to use other ports. With various callbacks, SOAP interfaces, EJB servers, and whatnot, your ports not only fill up fast, but there may be too much code designed around existing port designations to make it practical.
There are also issues dealing with many servers that attempt to prevent more than one copy from running. (Normally, this is a feature.) They may open a fixed port, or hold onto a lock file, or pull a variety of other tricks that aren't so easy to get around.
Then there is Windows development (blech!) where you can only have one instance of an ActiveX control installed across the entire system. This not only sucks for developers, but it sucks for Windows servers which tend to breed like rabbits because of problems like these. I won't even go into problems like multiple
First thing you learn in professional programming: There's a huge gulf between what is possible and what is practical. It's a lot less hassle to simply give developers their own machines than to waste time on troubleshooting collisions. Hello? McFly? See this bug? Guess what it does. Want to guess how common it is?
How about this one? Do you see it? That's what happens when you reverse a loop when you're used to doing it the other way around. And those are fairly benign examples of what you can frack up. You should see some of the multithreaded code people write. Ugh. Can you say, "Thread Bomb?" Then you're not doing anything involving. Fun things like changing the screen resolution and obtaining a DirectX context can crash or lockup your system. Or accessing external hardware at just the wrong time. (Yes, this happens on Unix as well. Though to somewhat lesser degrees due to focus on stablility rather than performance.) Never locked up an X-Session before? Then you're not doing anywhere near anything interesting.
Who needs root access? I need to be able to run web servers and the like. Having a dozen developers trying to open port 80 on the same machine is a problem. Not to mention the excess computing resources used or outright crashes that a developer might accidently cause while debugging.
I knew my Einstein-Rosen-Podolsky bridge machine was missing something! Computer circuits powered by Einstein-Bose Condensate! It's so simple! With this new invention, I'll be able to communicate with the machine back on my world, but never (for reasons yet unknown to science) tell it to retrieve me!
Hmm. That could be a problem. I better remember to set the timer...
16-bit software from the DOS days runs like crud on modern processors. But because of the constant die shrinks and Gigahertz updates, the software runs many, many, many times faster than was originally intended. So even a gross reduction in performance can still lead to a net gain for old software. :)
Take 3D programming as an example. Before I can render the screen, I have to run thousands of vertices through a matrix transformation so that they align with where the camera sees them. This is a bulk operation that can be run in parallel by multiple SIMD cores (each tranforming 2-4 vertices per instruction) by simply providing each core with a copy of the computational matrix. Simple, straightforward, and FAST. But utterly useless for general purpose code like multithreaded web servers.
So the problem is not a lack of tools. The problem is that the Cell is a specialized architecture that's very different from traditional multiprocessing. It's designed for long number-crunching applications that have traditionally been the forte of supercomputers. Ergo, it is a supercomputer on a chip.
VLC would benefit greatly from concurrent SIMD cores like the Cell Broadband Engine. Depending on the particular compression stream, the cores could be decoding multiple frames of video/audio in parallel at a much faster rate than a regular PC. Even if the particular compression stream didn't allow for multiprocessing, the SIMD design would still allow for the decompression stream to be completed in a fraction of the time it would take general purpose instructions to perform. (The exact fraction is dependent on how large the bits of data are. It could be as little as twice as fast, or it could easily be four times as fast.)
Being a simplified example, of course, it is possible to parallelize the instructions above. It will require more memory, but we can do the following instead: If the first addition is run on a separate core than the second processor, then we'll get a net increase in performance even though we used more computational cycles to compute the results. There's just one catch. CPU designers have known about these micro-optimizations for decades, and have been designing microprocessors with an ability called "Superscalar execution" for almost as long. Superscalar designs make use of CPU processing units not currently utilized by other instructions in order to offer a simplistic form of multithreaded execution on a single core. In this way, the CPU can chew on a larger number of instructions in parallel than it could if it fully serialized the execution. Which makes full multithreading mostly redundant for these situations.
owww... my head...
There are a couple of serious problems with this statement. The most important one is that the article doesn't say that existing software will get slower. And there's a reason for that: Existing software will continue to run on the individual processor cores. Something that they've done for a long period of time. Old software may not get any faster due to a change in focus toward parallelism vs. increased core speed, but it's not going to suddenly come to a screeching halt any more than my DOS programs from 15 years ago are.
Secondly, multicore systems are not a problem. Software (especially server software!) has been written around multi-processing capabilities for a long time now. Chucking more cores into a single chip won't change that situation. So my J2EE server will happily scale on IBM's latest multicore Xenon PowerPC 64 processor.
Finally, what the article is really talking about is the difficulties in programming for the Cell architecture. Cell is, in effect, and entire supercomputer architecture shrunk to a single microprocessor. It has one PowerPC core that can do some heavy lifting, but its design counts on the programmers to code in 90%+ SIMD instructions to get the absolute fastest performance. By that, I mean that you need to write software that does the same transformation simultaneously across reasonably large datasets. (A simplification, but close enough for purposes of discussion.) What this means is that the Cell processor is the ultimate in Digital Signal Processor, achieving incredible thoroughput as long as the dataset is conductive to SIMD processing.
The "problem" the article refers to is that most programs are not targetted toward massive SIMD architectures. Which means that Cell is just a pretty piece of silicon to most customers. Articles like this are trying to change that by convincing customers that they'd be better served by targetting Cell rather than a more general purpose architecture.
With that out of the way, here's my opinion: The Cell Broadband Architecture is a specialized microprocessor that is perpendicular to the general market's needs. It has a lot of potential uses in more specialized applications (many of which are mentioned in the article), but I don't think that companies are ready to throw away their investment in Java,
The truth is that there are very few business units that actually need their own desktop machines. The problem is that we developers are some of the few who actually need workstations, meaning that we often fail to push the best solution for the company as a whole.
So while it's technically true, it wouldn't be a very good argument against nuclear power.
It's true that in a pure-ethanol vehicle, you'll need more fuel to make up for lower energy density. However, the faster and hotter burn cycle can be compensated for, allowing engine designers to extract a fairly competitive amount of energy from the fuel.
The lower energy density just isn't that big of a deal when the choice is between needing 20% more Ethanol fuel at $2.50/gal vs. purchasing petroleum fuel at $3.75/gal. This must be the oddest argument I've ever heard against nuclear power. First and foremost, any escaped heat is wasted energy that could have been used for electricity. So plants try to loose as little as possible. However, they do lose some, but nowhere near enough to have an impact on global conditions. "Global Warming" models are not based around how much heat that power plants release, but around concentrations of greenhouse gases that hold heat in. The theory is that if the concentrations were lowered, the Earth would be better able to radiate away the excess heat.
As it so happens, Ethanol is being used as an ocatane-booster additive in the majority of gasoline today. In part, it's because it's safer than cleaner than most of the chemicals previously used to improve octane ratings. Another part of it, however, is that up to 10% Ethanol mixtures are helping to lower the cost of gasoline as the prices for gas surpass that of Ethanol.
I've said it before, and I'll say it again. Wikipedia is a great place to start your research. It can even be perfect for solving quick arguments on the Internets. But it should never show up as a citation in any professional or educational context. Which is something one needs to keep in mind, as it's very easy to slip up and treat them as authoritive. They're not. They're just an encyclopedia.
Now that you mention it... :D
Is that what they were trying to do? It looks more like "flat shading" than "cel shading".
GT Pro Series is probably what you're thinking of. (Gran Turismo is for the Playstation.)
And yeah, it makes me want to gouge my eyes out as well. Even if it was a Gamecube port, the 'Cube is capable of better graphics than those shown. What's up with that, Ubi?