1) The iPhone is the biggest selling single phone on the market, hell they've a 1/3 of the whole market with one device
2) The iPod is the biggest selling digital music player by a mile
3) iTunes is one of the easiest to use ways of managing your digital music collection

So will the vast majority of people give any sort of hoot about DRM when all they can see is their ability to share the music between their PCs and their digital music player? No they will not.

All this will do is demonstrate how pointless the actual demonstration is, thus meaning that Apple will be less likely to be concerned.

For most people the question isn't DRM-free its "playable on my iPod".

From the numbers in the summary, a fully-charged one of these would supply enough energy to propel a 3300lbs (1500kg) car from 0 to 1100mph (500m/s)

Ahhh you must be from the Theoretical Physics Department, over here in Engineering we have wind resistance, friction and efficiency to worry about.

Since when couldn't Gasoline be used in Cars? Isn't the whole principle of it to make it explode to drive the pistons? Now its good that this thing allegedly won't explode while being charged but with all technologies its about minimising risks through sensible practice rather than their complete elimination.

For instance I'd be willing to bet that applying 10MV at 10MA across this thing would cause some pretty funky changes that would look like an explosion.

Personally I'd like to see some sort of Darwin device in the next generation of cars, "cannot explode unless user should be removed from the human race".

This isn't about transparent government v security. Security through Obscurity is the well known worst approach to security that you can have, because if anyone ever does get that information (hell bribing a sys admin can't be that hard if you really want the info) then your have no security.

Its a bogus claim and a bogus judgement. If they were claiming that it shouldn't be released because editing Wikipedia isn't actually a political thing anyway then I could see a reason to toss it out. But the risk of hackers "targetting" bits of the network is just plain bogus, the implication is that these IP addresses are therefore in some secure part of the (ARKANSAS!) government and those IP addresses have already been released. What is being asked is a map back from a known IP address to its source. Claiming that knowing the physical source would some how make security worse is like saying that "Sure you have the keys, you know where the front door is and you can get in.... but I'm not telling you the NAME of the house".

Having the IP address is like having 1600 Pennsylvania Avenue and the keys to the door but the government not telling you that it is called the "Whitehouse" for security reasons.

Who hear who codes in C or C++ hasn't had a similar bug in their own code from time to time

What are these bugs of which you speak? Sometimes I add problems for the testers to find, but that is done on purpose, its not my fault if they aren't smart enough.

Oh and I've debugged your english for you

Who here

Unless that was irony.

Now the serious bit. I used to work in safety critical software, we designed, tested added redundancy and used languages (e.g. Ada) which don't have overflow problems. This isn't a performance thing (we had to be high performance as well) its about choosing quality and security from the first day.

The biggest reason of all is interop. A piece of Java code that runs in 32 bit mode successfully will wrap around and work exactly the same on the 64 bit platform. Perl will work differently. if a piece of Java calls a piece of identical Java and one is on 32 bit and the other 64 bit then they will work properly, Perl will behave erratically.

Basically its the difference between a language that has been designed for longevity (Java) and one that just defaults to what ever is around (Perl).

Defaulting to what the processor has is the opposite of future proofing as it ensures that your current code WON'T WORK PROPERLY IN THE FUTURE. Sorry to shout but it really is quite important. The Java code will work the same on 32 bit and 64 bit versions while the Perl will work differently, thus it will not be future proof.

To really future proof your code what you need to do is plan for those things and assign your file size to be a long and guess what Java returns a long.

Perl and Design go together in the same way as Illinois and Probity.