The key could be stored in static RAM, which does lose data instantly when power is lost (downside is that it's more expensive, but for a single encryption key that's not a problem). Alternately, you could just stick a capacitor on the board with enough power to erase the RAM. Or just bury the RAM cells inside the CPU, so it's impractical to access them (and make the CPU erase them on next power-on).

Since recaptcha only actually checks one of the words, you actually have a 0.35 * 0.50 chance, or 17.5% chance of success. Of course, since google will just plug this back into their OCR algorithms, and recaptcha only uses things their OCR algorithms failed on in its captchas, any such advances are only temporary in nature.

They're already drilling relief wells, through which they'll do a 'bottom kill' procedure (regardless of whether the top kill works). Once they do that, it's my understanding that the relief wells can in principle be re-used for production oil collection as well.

Vorbis has been used by a number of major game publishers for game audio, precisely because it has no license fees. I think WoW would be a big enough target for the patent trolls, how about you?

Be prepared for another "Firefox vs the World" with this, however: Vorbis vs MP3/AAC.

Not really. Vorbis has about the same quality per bit as AAC (unlike theora vs h264), and it's established long enough to not have patent issues. There's no reason not to implement support for Vorbis, and it's plenty good enough to be the default codec. What's more, Youtube's behind Vorbis (it's part of the WebM spec), and since Flash has pledged support for WebM, they'll have it too.

To be fair, the Boto API was not designed by Google - Google basically cloned the Amazon S3 REST API (since there are plenty of third-party libraries for it already), then made the minimal adaptations to Boto needed for it to be able to connect to Google's service as well. Precisely none of the API there is then of Google's design; they're just using what's turning out to be something of a de facto standard.

If you can find an ExpressCard-to-serial interface that doesn't cheat by using the USB bus on the port, the timing issues ought to be surmountable.

At some point, you have an analog signal coming from a pickup coil. If the attacker taps in there, no amount of encryption will protect you.

Even if you fixed the impedance issues, ethernet relies on the twisted nature of the signal wires for noise reduction. Without twisting, if that coax goes past an AC line somewhere, say goodbye to the signal.

First, google's servers each have their own battery, so it's unlikely that all the servers in a DC will go down at once. If only a few go down, their redundancy means that it's not a big deal - they can wait for the fsck. And moreover, even if an entire DC goes down (eg, due to cooling loss) they have the redundancy needed to deal with entire datacenter failures - with that kind of redundancy, fscking is only a minor inconvenience (plus with a cooling failure they might have time to sync and umount before poweroff...)

If you had read the article, you would have noticed that there is already an open-source implementation, and this patent covenant applies precisely to that implementation (as well as modified versions thereof). The only thing it doesn't apply to are video codecs, for which Microsoft probably doesn't own the patents, and therefore doesn't have the rights to create such a covenant on.

I don't know if they _need_ the income, but I'm sure they have plenty of excess capacity from reserved instances that aren't running for starters, not to mention the pool for on-demand instances. It's just a smart business move to try to exploit this.

There's no custom quote for increasing the instance limit - it's just a safety to prevent someone with a stolen credit card from spawning enough instances to use up all available capacity. You just put in a request and have it lifted; pricing stays the same.

Losing energy always results in a loss of rest mass, so there's nothing unexpected about that.

And here are the real webcams.