But that case was designed for the Kindle 2, which (I think?) *doesn't* put power across those pins. If that's the case, this is mostly a Kindle 3 design flaw - they should have made the slot spacing different so you couldn't use a Kindle 2 case.

Not as hot as you might think; most of western North Carolina is at a pretty high altitude and has quite moderate summers. Pre-air-conditioning, summer vacation in the Appalachian mountains was popular among upper class New Yorkers, so...

Well, maybe he's bringing along one of our prototype military lasers! There are solid-state 100Kw lasers in test that I'm sure will sink a wooden ship just fine...!

"Kids, remember to study math and science. Because math and science will let you build LASER CANNONS to BLOW #$% UP!"

No, no, no. For this, use a one-time pad.

What you do is this:

Take your file (A). Generate a block of high-entropy random data (B).

Now generate (A xor B), and throw away A. You now have two random files, B and (A xor B), and B xor (A xor B) will give you A again.

A cute variant: instead of generating a really random B, use pseudo-random data generated from a known key (mp3 rip of some song of a particular version of a CD, gzip of linux kernel source), and don't even keep B with you; regenerate it on the other side. There are lots of ways to screw this trick up, though, so consult a cryptographer.

You could use more than 2 files if you want, the idea is basically the same.

A lot less; it's not a coincidence that IBM never publishes any industry-standard benchmarks on these things.

Don't get me wrong; they're fast, but they're not magic, and they're not remotely competitive on a price/raw-compute-cycle basis. If that's what you want go get a beowulf cluster.

Actually, I believe it does now. 3D driver support is even worse than Linux, though. :)

I've read of people trying to sell this in Iceland - cold, and you have cheap geothermal power!

They were having trouble finding users who weren't turned off by the expensive bandwidth, last I'd heard...

Short form:if P=NP, crypto is something of a futile effort - that implies that there's a non-brute-force crack to every possible private-key algorythm. I suppose it might still be slow enough for the crypto to be useful, but I woudl expect you would end up needing gigantic keys.

Most everybody assumed that P!=NP, but nobody has been able to prove it.

This is a key point; for all we know, he did 9 other tests that showed no signs of irregularities and published only this one!

Suspicious? Yes. Smoking gun? Not even close.

Yes. Chip plants may use a lot of water, but it's a drop in the bucket (so to speak) next to farming.

So, it's a Linux port that will only be usable by people who dual-boot? Good grief.

I bet you could hack together a workaround without massive effort; write a case-desensitizer FUSE filesystem, and have it 'remount' a case-insensitive view of an existing filesystem in an alternate path.

I think a tetrahedron, growing into a 8-sided d8 kind of thing, then back - a cube has six faces, but a hypercube has eight cubes for, er, faces (one on each end, and then a cube connecting the faces of each of those).

Not at all sure, though.

Obviously, the answer is velociraptors.

That's why we need to be more proactive; instead of trying to eliminate all the invalid keys, we should just pick the strongest possible key and standardize on it.

It turns out that the most efficient type of stimulus spending is spending on studies of stimulus spending.