If all you want to do is run an existing app in "the cloud", EC2 is a better choice for you. App Engine is designed around the philosophy that "We'll make scaling magically happen; but you need to obey our rules." These rules, for the large part, are designed to make scaling easier - all the seemingly-weird limitations in the datastore are there because they implicitly force you to shard your data early on. Since you'll be customizing your database layer for app engine, the logic goes, providing all kinds of programming languages isn't as important (since you might as well customize the rest of your app, right?) The other concern Google might have is sandboxing - they've done some fairly extensive modifications to Python, Java, and Go to get the kind of sandboxing that they need, and given PHP's not-so-stellar security history, they might not be as interested in supporting it. Heck, even if sandboxing worked well enough, I could see them saying "No, we don't want to support PHP because it's harder to write secure apps in PHP, and our entire philosophy in App Engine is to make the easy thing the right thing to do."

On a serial link, just use the right arrow key. Or possibly ESC (although you'll have to deal with clearing the ESC chord afterward if it happened to be in vi or something)

Alas, while the Fukushima facility has plenty of gamma, alpha, and beta radiation to go around, not to mention a glut of thermal energy, they're a bit scarce on the neutrons at the moment.

Writing the log first is an implementation detail if anything - and in fact, ext3's ordered mode is very careful to write the data first. No idea what Windows' NTFS implementation does of course. And as long as the WAL will fix up any outdated bitmaps, with traditional drives there's no problem. But if the drive decides to zero out blocks on its own initiative, then things get a bit... well, scary. I suppose you could legitimately do it if you collect the list of extents to trim at boot, after verifying the drive is clean, but filesystem corruption is still an issue (I doubt the disk runs a full fsck at startup...)

Isn't that a bit dangerous? I'd be worried about a scenario like:

• OS allocates block X and fills contents in memory.
• Application fsyncs(). OS writes an entry for updating the metadata to the write-ahead log, as well as writing actual block contents to block X. At this point, the block is committed to disk, so the OS returns from the fsync.
• OS crashes before updating actual metadata. User reboots.
• SSD decides that block X is free (looking at the metadata) and trims it
• OS reboots, applies write-back log. Block X contents have been lost

Or perhaps even:

• OS allocates block X and fills contents in memory. Write activity is low, so writeback is delayed for a while.
• Memory pressure causes block X contents to be flushed to disk. Metadata remains in memory.
• SSD decides block X is unallocated (WAL is empty, block is marked as unallocated) so it frees the block
• OS writes back metadata. Block is now zeroed.

Or even good old fashioned file system corruption being made worse by something like this...

To clarify - is this deletion occurring because the drive analyzed the filesystem metadata and decided it would be a good idea to zero some sectors, or is it an asynchronous response to a fast TRIM command applied to an extent covering the whole drive?

Which would mean Sony has to prove that the defendant agreed to that ToS. After all, you can refuse to agree to the ToS, but still dump out the hard drive. For that matter, can the PS3 be used in offline mode without agreeing to the PSN ToS?

The headline's a bit misleading. Users _can_ replace the OS. However, the BIOS will check signatures on the OS, and offer to restore from a known-good backup on boot (without destroying user data). This ensures that if the OS is infected by a virus or something, it's very, very easy to restore.
There are specific points in the design docs where they make it clear that they do want to support advanced users installing their own OS, to the extent that that does not cause trouble for less advanced users.

You're angry but you just said you had forgotten about that work for seven years. Was your intention to leave that concept in the graveyard until you died, getting angry should anyone try to profit from it or license it?

If he didn't take a patent on it, then there's nothing stopping IBM from using the same techniques. The problem arises when IBM patents it as if they were the first to invent the technique, then restrict everyone (including the OP) from using the OP's invention. If IBM just used it without patenting, no problem. Of course, it's entirely possible that IBM's invention is slightly different from the OP's - patent claims are rather hard to read for a layman after all.

Not all US airspace is controlled - in fact, the vast majority is not, particularly at the low altitudes you'd need to be flying at to get this kind of imagery.

Are low-end FPGAs fast enough to deal with HDMI's data rate?

Presumably they'd have some capacitors over the power supply for the memristor to stabilize the power a bit. And I'm sure they don't use raw AC - there's probably a low-voltage DC inverter in there.

As I understand it, you apply high-frequency AC to do a read (the current gives you your value). The high-frequency AC ensures that any perturbations to the value cancel out.

That's not really relevant - nobody's paying for any software. The developer is paying a fee for hosting - and a very small fee, at that.

On further research, some static RAM chips do retain data (though not all of them). If you really need the data blanked out, storing it in a D-type flip flop might be better then.