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.
I thought automated aircraft (no pilot) and RC craft flown by non-pilots were not allowed in controlled airspace in the USA.
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.
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.
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.
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.
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...)
Slashdot Mirror
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...)
Or perhaps even:
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.
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.
I thought automated aircraft (no pilot) and RC craft flown by non-pilots were not allowed in controlled airspace in the USA.
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.
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?
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...)