Did he modify the libraries he's using? Is he sure it's actually GPL and not LGPL or even MIT or BSD? And in particular that there isn't a reasonable linking exception? My impression from the summary is that he's merely linking said FOSS libraries, and my (much less founded) impression from casual observation is that using FOSS libraries is usually ok so long as any modifications made to the libraries and redistributed are done so following any viral licenses that might apply.

Actually, if I'm not mistaken ksplice already is completely free and open source. They operate kind of like Red Hat--what you're paying for is support. From what I can tell though, there's one crucial difference--ksplice can't function without support. Now in either case you are free to provide your own support, but I think the task of providing ksplice patches is just nontrivial enough (due to the nature of the problem, not ksplice's design), that the economies here significantly favor everyone paying one company to do it, rather than anyone trying to do it themselves.

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.