There has been a trend in the last decade or so for the shutter speeds to be faster, plus the heavy use of CGI has resulted in razor-sharp images where motion blur would have been better.

To demonstrate this, and that it spans genres, Blade Trinity and Drumline come to mind immediately. In the former case, the CGI was too razor-sharp when viewed in a cinema, and it made it difficult to watch. In the later, there are scenes where the band are performing in bright daylight, and the fast shutter speeds made the movement of the conductor's arms and baton look jittery.

This works until the city council sees the potential revenue strem form red light cameras. Then the cameras come, and the revenue stream doesn't materialize. Then they start ratcheting down the yellow-light hang time. Then away goes the delay you are talking about (which we have here in New York as well, except for very old lights at some intersections) and then you have a red-light trap.

The City of Albany, NY has just decided to put in red light cameras and then wrote up the budget based on the anticipated revenue. I have to drive through Albany to get to work, and I am grateful that I'm on the highway and not in the clusterfuck that this will very quickly become.

Agreed. The image on that page reminds me of all of the PowerPoint slides that have been introduced with the words, "I know you can't see this, but . . . "

There's a second question that has to be asked as well. In some neighbouhoods, the electrical service is run through the back yards, rather than the front. This was done for obvious aesthetic purposes, but the side-effect is that it is exceptionally difficult to keep those lines maintained.

Then there's a third question: what is the level of the local infrastructure? 2400V? 7200V? 13.2kV? Single-phase or three-phase? While a 2400V single-phase neighbourhood can have more stable power than a 13.2kV three-phase one, the likelihood is the other way around because the 2400V wiring is probably older.

For the record, my neighbourhood is 13.2kV single-phase, above ground. It is not 100% problem free, but I would estimate it to be well over 99%, based on my desktop computer without a UPS rarely being found in a powered-down state.

Alright, fair enough.

Not sure why you're currently modded redundant as I came to say pretty much the same thing.

That sounds like something Yogi Berra would say.

Perhaps so, however, there was no assumption in my model that the device was a smartphone, nor any assumption that it had any kind of connectivity. Your model requires it, while mine would still allow for the payment device to be a card if that is the user's preferred option.

There is also no reason why these two approaches couldn't be implemented on the same POS system.

Now, the obvious question is why am I not requiring it to be a phone. The answers:

• You want to encourage participation from those who do not have smartphones, or even phones at all, because the magstripe cards they are currently carrying are now demonstrated to be a security disaster. Enabling them to use a smart card instead keeps the object familiar.
• You want to allow for folks (like me) who do not want to give their credit card details to Google or Apple.
• You want to prevent your carrier from dictating your options, something you can put safely out of their control if you can use a device other than your smartphone.
• You want to have options that are less hackable . . . kind of the point. A contact card sitting in your wallet is powered down. Short of dissection, you can't hack something that is powered down.

• Merchant advises me of the total.
• I give him cash equal to or greater than the total.
• He gives me change equal to the difference between the total and what I gave him.

Now, if you want an electronic approach, how about this:

• Merchant advises me of the total.
• I take a device, could be a card, could be a phone, whatever, and authorize an amount. Optionally, this may (i.e. should) involve the entry of a passcode of some sort. This should be entered into my device, not the POS terminal.
• I connect the device to the POS terminal (could be a plug, slot, wireless, NFC, whatever - not important).
• The POS terminal assembles a transaction record consisting of time, date, merchant ID, terminal ID, amount, sequence number. It passes this to my device.
• If the POS terminal and my device agree on the amount, my device will add my account number to the transaction record, and then cryptographically sign the record.
• The signed transaction record is passed back to the POS terminal and sent to the processor.

If the amounts don't match, no signature, preventing overcharges. If the transaction is replayed, the merchant ID, terminal ID and sequence number collectively will function as a transaction ID and it will be recognized as a dupe. If any of the transaction details are altered, the signature doesn't match. If the vendor tries to do two transactions at once, the device won't sign both without me reauthorizing. If the vendor wants or needs to validate off-line, the signature can be checked using the device's certificate, the signature of which can be checked with a cached CA cert.

Now, because this approach is agnostic as to whether the device is a card, dongle, phone or whatever, and whether it plugs in, taps or even just flashes a QR code on a screen, I can see the approach being adapted to both bricks-and-mortar and on-line purchases. The only thing I can think of that we do with our credit cards now that might be tricky in this system would be recurrent payments, but those could be handled by pre-authorizing a year's worth of transactions or something similar.

Yeah, and I heard that in Tom's voice as I read it.

Yes. I was actually really interested in the one where they had ten envelopes that collectively held $1000, and the puzzle was to figure out how to distribute the money between the envelopes so that you could select any whole-dollar amount by picking the right combination of envelopes. The solution, of course, is to think in binary. That's pretty nerdy.

Yes, this is akin to saying that they accept no major credit cards, but that they will happily accept applications for a store card.

TFH says it was built by Foxconn, but TFA does not. TFA says it was built by a third party like the way Foxconn builds for Apple.

I'm really waiting for an x86 phone that can be bought in the USA.

I believe that's called a Blackberry 950.

All snarking aside, though, I must ask: what is the attraction to an x86-based phone versus an ARM-based one?

Pay attention, naive little brother: A machine with Windows on it costs the same as a machine without windows on it for the same model and specs . . . assuming you can even get a Windows-free version. This is because Microsoft have dictated that it be so. The difference, then, is that in one case you are paying for, and getting, Windows; in the other case you are paying for, but not getting, Windows. That, naive little brother, is the Windows tax.

I thought this at first, also, but I have had a pretty close match to Speedtest's claims when using scp to send large files to/from my EC2 instances.