"but the power:weight ratio and range just wasn't there with 50s engine technology"

Yep, modern batteries should give the required energy storage capacity while electric motors give much better power/torque at very very low weight. Plus the lightweight materials to build the chassis which just didn't exist before the space race and have only improved since then.

In the 50s I imagine the batteries meant an electric motor was just impossible without tethering you to the mains, so it required a internal combustion engine which naturally means very heavy motor and very heavy fuel.

Aviva developed a Pay As You Go insurance system several years ago now.
http://www.aviva.co.uk/media-centre/story/2840/norwich-union-launches-innovative-pay-as%20you-drive/

We studied it as part of a project during my CompSci course about the time it was launched.

Essentially you agree that they put a GPS tracker in your car. It monitors your speed/acceleration/braking/etc (just like the app). You then only pay insurance for when you are driving, and the price is affected by how well you drive. It's been around for some time now. It's fixed to your car, and if you remove it from your car so they don't see your bad driving you're illegally driving without insurance.

All the phone app is is a free trial of that type of insurance - far cheaper to give them an app than send them a tracker. If you were to actually buy their insurance there's no way they'd let you keep using the phone app for it. Too much chance of forgetting the phone or battery dying, let alone any 'gaming'.

Well they have to find a way to make you move to timeline, obviously.

All recent versions of NDB can store data on disk too. RAM-only is a very old (5.0) requirement.

NDB's real advantage doesn't come from being in memory (if you have enough RAM you can get a massive speedup on standard MySQL by setting large enough buffers to keep a cache of most of or the entire database in memory).

It comes instead from auto-sharding, spreading data out over multiple nodes and having multiple servers transparently searching data for you at the same time so that your query runs much faster than just one server could manage. And you can easily add more nodes as your load increases so the system nicely scales up, even on writes.

Yes, it's exactly that. They assumed memcmp returned a value in the range -128..127 - so they've assumed a char was sufficient. And many implementations do indeed return that, but unfortunately not all.

http://seclists.org/oss-sec/2012/q2/493:

What stopped them finding it is it depends on what memcmp version is being used. GCC builtin ones aren't affected, neither are BSD libc. glibc's is though. Which you use all depends on how it was compiled and it appears the official vendor ones from mysql.com aren't affected. My own systems also aren't, which appears to be because they're using the GCC builtin version.

Penetration testing'll only find it on the affected versions, if the official mysql.com versions aren't affected then their testing wouldn't have found it because the bug didn't exist on their systems. And since that'll apparently be most of the installed versions out there, it's not going to be something that's been found on many versions in the wild either.

They say you can get in by making 300 connection attempts, which can be done within a fraction of a second. Which is true.

They don't say that you have to do it within a fraction of a second.

The memcmp function has a 1/256 chance of returning the required value that makes it treat any password as the correct password - there's no link between the connection attempts, each time you try to connect you have the same 1/256 chance. You could space the attempts out over seveal minutes, hours or days if you wanted to - it'd just slow down the time it'd take you to get in (and make it more likely they've patched their systems before you get in).

Practically, this is slightly less newsworthy than it sounds. Yes the bug exists and yes it's serious, but it also depends on which memcmp version you're using on whether you're actually affected. The gcc builtin ones aren't affected or the libc ones, the glibc one is. That means whether it's exploitable depends on how your server was compiled. And it appears that the official versions from mysql.com aren't affected, and testing my debian systems today neither are they (but they're nicely firewalled anyway, just in case). Source: http://seclists.org/oss-sec/2012/q2/493

To be honest, the spec is a large jump in CPU, memory and graphics power. The camera's much better, it's double the download/upload speed and Siri is quite a significant new feature.

The only problem is it's labelled as 4S not 5, when everyone was expecting it to be a 5. That makes them feel its an updated phone when actually it is a significant update. If they'd just launched it as the iPhone5 no-one would have been describing it as a let-down. Well, except anyone complaining that it still looked the same.

Possibly. It has 2 antennas and switches between whichever has the best signal... that might be enough so that if the death grip is blocking signal to one, the other will still be working fine.

Of course they've not advertised it as such a fix, because they've never admitted there's been that problem (at least no more so than any other phone). Just said that it "improves signal strength".

And of course now they're still around, using helium which is far safer. It's only the speed that's made planes the preferred option.

And from U.S.C. 47 S151...
For the purpose of regulating interstate and foreign commerce in communication by wire and radio so as to make available

Actually, their current charter is to "make available so far as possible, to all the people of the United States, without discrimination on the basis of race, color, religion, national origin, or sex, rapid, efficient, Nation-wide, and world-wide wire and radio communication services with adequate facilities at reasonable charges."

So yes, it is within their jurisdiction.