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?
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.
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.
Limit the damage to one publisher, right?
Well... to one gargantuan distributor, but aye, I agree with the sentiment.
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.
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.
There's no way my friend's place is going to get an internet connection that is capable of handling all of us simultaneously, with latency comparable to a LAN.
Really? What are the bandwidth requirements per player for SC2? And how did you get those numbers?
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.
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?
The less time planning, the more time programming.