Not to diminish the achievement, but haven't they built him a redundant right hand?

Why throw hardware at a software problem?

http://en.wikipedia.org/wiki/Tiling_window_manager

Now, don't jump down my throat just yet. Yes, I realize these are not for most people, but your "minimize" idea reminded me of dwm and xmonad's default tiling behavior. While replacing standard window managers with things like dwm and xmonad wouldn't be acceptable, perhaps standard window managers should be extended with faculties that allow easy tiling when desired. Supplying this particular need with hardware seems... silly.

On the other hand, given that the extra screens are touchscreens there are other advantages. I would not object to my laptop being a giant DS, but I'm a sucker fo gimmicks.

Viruses have metabolisms?

From the title, "Scientists Deliver Bee Toxin To Tumors..."

Although, I did have the same initial reaction. I think the term "nanobee" is just far too distractingly catchy.

Well... to one gargantuan distributor, but aye, I agree with the sentiment.

...and how, might I ask, are you generating your primes?

Nope, Bluray players are required to support MPEG4 (alright, you got me. Not sure what compression level (3.5 generation ipod videos support a highly restricted profile of h.264), but the size ratios wikipedia quotes me indicate it's about the same as most rips end up with). Vaguely explains the cost premiums actually.

So apparently ripping mostly just sloughs off extra content. That doesn't seem to quite account for all the size difference though, so I wouldn't be surprised if bluray movies are just mostly encoded at higher than necessary bitrates to pad out the empty space, or possibly just come on significantly unfilled discs.

http://en.wikipedia.org/wiki/Bluray#Codecs

Basically, bluray movies that actually need the full 20-50GB are generally encoded in MPEG2. MPEG4 is about twice as efficient at the same quality level. Movies that are already in an MPEG4 format on-disc I would assume are just bundling a crapton of extra worthless features.

On the other hand, yes, 9GB may still seem a little small (remember the parent gave 5GB as a reasonable size for 720p), so perhaps 11GB really is more reasonable for movies approaching 2 hours. On the other hand, cutting down to 9GB often is not a significant quality downgrade, so the convenience of DVD storage is often worthwhile.

oye. high bandwidth != low latency. Yours is the same fallacious "speed" concept that makes many SSDs suck. For example, my internet connection is through comcast (massive stupidity on my part there, but that's beside the point). It's a decently speedy connection--I consistently get 2MByte/sec downstream--but my lag times (to the edge of comcast's internal routing mind you--this is invariant with my destination ip) are often consistently around 2 seconds. (Imagine a thousand-lane highway of nursing home patients) With that connection, I can download large files mighty quickly, but the lag makes even controlling a terminal through ssh unbearable; playing starcraft through it is simply out of the question.

Hmmm... some of the comments on structure got me thinking. What if I write two algorithms--one that fails to halt on equal data, and another that fails to halt on unequal data, then feed both your cipherdata, to compare to a guess encrypted with your public key. This feels to me like a much more credible guess-and-check attack. Admittedly, guess-and-check not such a great attack anyways, but what if I take this further, to, say, a regex pattern match?

Ah, thanks for the clarification. That clears up a misconception I had about randomization and sufficiently answers my remaining question about how that might mesh with the homomorphism aspect.

Ah... that's even neater than I thought then.

Though, I'm aware that public key encryption doesn't produce identical ciphertexts for the same plaintext. But I thought that involved encrypting the plaintext with a randomly generated symmetric key, and then encrypting the symmetric key with an asymmetric key. I noted in my comment that that would be "cheating". The parent's concern seemed to be from a purely mathematical standpoint, and I was trying to address it from the same. In particular, we both allowed the assumption for this particular discussion that we're modeling encryption here as an ideal homomorphism.

That this scheme is both randmized and allows equality tests is ridiculously neat though. Could you explain this for me, or point me at additional resources for exploring this further?

More specifically, your decryption fails in any ideal in which 1 alone is not a complete basis.

Ah, I've got a response for your decryption concern now. Your decryption fails to work in the ring of polynomials, among other things.

It doesn't prevent equality tests in a single encrypted domain. But in a single encrypted domain, two ciphertexts for the same plaintext (i.e. including an extra block for obfuscation/resolution is cheating) are the same anyways. The unnecessary worry is about equality across different encrypted domains. I should hope the kernel is trivial, else we have collisions, and this indicates a different sort of a problem with our encryption scheme.

Your decryption concern is more interesting, but it takes me out of my depth for the moment. I think there's a flaw to be found in that line of reasoning though. Perhaps someone more knowledgeable reading this thread can provide a proper explanation?