Because, when it comes to car commercials, ad agencies are bound by so many rules and regulations regarding depictions of reckless driving and such things that it becomes almost impossible tp create a cool car commercial without running the risk of going to court over it (both the ad agency AND car manufacturer).

And yet, this commercial had zero driving at all!

Ok, the statement I made in my third sentence above is imprecise to the point of being inaccurate. The exact property, as described by Wikipedia:

The original proof shows that for overlapping reads and writes to the same storage cell only the write must be correct. The read operation can return an arbitrary number. Therefore this algorithm can be used to implement mutual exclusion on memory that lacks synchronisation primitives

So the part about not needing "properly arbitrated memory access" is mostly true—a read that collides with a write to the same location can return garbage. Writes still must update memory properly, and presumably must be sequentially consistent.

My first encounter with Leslie's work was Lamport's Bakery. It's a serialization primitive with some surprising properties. For example, it doesn't require properly arbitrated access to memory as the initial value read from memory on entrance to the "bakery" actually doesn't matter!

Dr. Lamport was actually kind enough to reply to an email of mine regarding said primitive. I was optimizing a version of it for a multiprocessor device we were making where I work, and I had come upon what I thought was a clever optimization. (I actually vectorized a portion of the algorithm by way of the "unroll and jam" transformation, so I could test the state of multiple processors in parallel, rather than in serial order as described in the algorithm.) He actually took the time to respond to my email, and was quite gracious. His reply:

In the Bakery Algorithm, process i must wait until a certain condition holds for each other process. The order in which it checks for the different other processes does not matter. So, the algorithm can be parallelized in the manner you suggest.

The only time I was more thrilled on a topic like this was when Dr. Knuth replied to mail I sent him regarding a particular algorithm in Volume 4 of TAOCP. I actually received a hand written reply. Well, he hand wrote notes on a printed copy of the email I had sent to his TAOCP feedback address. Dr. Knuth also encourages me to let all my friends know how much I like TAOCP. So, consider yourself informed: I think Knuth's The Art of Computer Programming series is worth its weight in gold, and if you consider yourself a computer scientist or computer engineer, you should consider getting yourself a copy, and investing the time to at least skim it. (Let's face it, to truly understand everything in there would require as much time as Don put into writing it.)

I just checked it now on my end and it seems to be fine. Maybe it was just a transient failure?

$ host eztv.it
eztv.it has address 162.159.244.249
eztv.it has address 162.159.243.249
eztv.it has IPv6 address 2400:cb00:2048:1::a29f:f3f9
eztv.it has IPv6 address 2400:cb00:2048:1::a29f:f4f9
eztv.it mail is handled by 10 ezmail.es.
$ grep nameserver /etc/resolv.conf
nameserver 8.8.4.4
nameserver 8.8.8.8

Don't try this at in a University of Texas parking lot. They'll fine you for it. When it happened to me, it was something like $35. "Improper Method of Parking," or some such bunkum. Oh, and Texas requires front plates, so you've already lost that aspect anyway.

I wonder if that was what was up with a truck I saw a few months back, with a huge ol' camera on the side. It was just a boring black pickup truck, and just one camera on the driver's side.

I've seen the Google Car, and it was much smaller, painted rather obviously, and had cameras facing multiple directions.

It refers to the C Run Time, aka. the C standard library. Back in the day, only C programmers were able to operate radar. Nowadays, they can monitor radar with jQuery and node.js.

Did the OTA process itself cause the instability, or would your device been just as unstable had you updated it over a cable? My comments regarding OTA updates are meant to apply to the OTA aspect only, not whether the update itself is good. That is, for a given update X, do you deliver that update via a programming cable plugged into the ECU at the dealership, or do you deliver that exact same update OTA. That was the point in debate.

Or is your (unstated) argument that by lowering the barrier for making updates (ie. OTA is easier and cheaper than calling everyone into the shop), that would tempt auto manufacturers to take shortcuts in their QA process in the name of getting updates out there more quickly?

Johnny Carson? Every one of his jokes was original? He mined Vaudeville humor and brought it to TV. He didn't even start the Tonight Show.

Elvis Presley? All of his hits were written by others. Let's face it: He made his money and fame bringing black music to white people.

James Brown? Definitely an original, whose life unfortunately went off the rails at some point.

Ok, that's enough rant. Every one of those folks earned their place on a stamp. I just wanted to point out your double standard. It's easy to dismiss one person or another with cherry picked criteria.

If you walked up to a random 20 or 30 something on the street today and asked them if they knew who Carson, Bergman, Presley, Brown or Jobs was, I imagine Steve would beat out most of them.

I'm no Steve Jobs fanboy. (I've never owned an iPhone or iPod, and I'm posting this from a Linux box.) But even I can recognize the reality of the situation.

No, he doesn't...

I know you're just trying to be snarky.

Actually, proper OTA updates have a number of safeguards built into them to ensure the process has clean "before" and "after" states for each step of the update process, with no crash-inducing intermediate state. I can think of at least one vendor that has a product in this space. (Note: The link is not meant as an endorsement; it's merely an example.)

The only real thing I imagine you need to worry about is if the car has had damage or after-market "upgrades" that might interfere with the validity of the update, leading to safety issues with the combination. A trip to the dealer would at least give the dealer a chance to notice such things. I find it hard to imagine that in practice, though, that it would uncover many negative interactions at the dealer.

The way I like to summarize it when talking to non-technical types is this: The odds of any one ticket winning the lottery jackpot are astronomically small. Regardless, people win the jackpot quite regularly.

Low probability per trial × many trials = reasonable probability of occurrence overall.

Rounding small probabilities down doesn't fully explain all the ways folks get tripped up thinking about probabilities. For example, the Birthday Paradox doesn't fit that model directly, because it's counter-intuitive what constitutes a "trial". As the number of people involved grows linearly, the number of potential pairings grows quadradically, and most folks don't really take that into account.

Extending that to the lottery example: It's far, far more likely that two people bought the same numbers than it is that anyone matched the jackpot numbers. (And that's before taking into account the fact that folks that pick their own numbers rarely pick very random numbers.) But nobody's interested in that coincidence until the folks with the same number also match the jackpot number.

The notifications seem to be going out in waves, slowly. I'm not sure why. Across three folks I know (including myself) with Kickstarter accounts, the emails themselves all seem to have gone out within minutes of each other, but one of them arrived just minutes ago.

I'm guessing with the volume of emails, it got throttled along the way. You can see this in the Received: headers:

Received: from o2.e2.kickstarter.com (o2.e2.kickstarter.com. [74.63.202.49])
by xx.example.com with SMTP id xxxxxxxxxx
for < username@example.com >;
Sat, 15 Feb 2014 21:49:50 -0800 (PST)
...
Received: by filter-219.sjc1.sendgrid.net with SMTP id xxxxxxxxxx
Sat, 15 Feb 2014 21:18:46 +0000 (UTC)
Received: from MTEzNDg (unknown [10.42.83.122])
by localhost.localdomain (SG) with HTTP id xxxxxxxxxx
for <no-reply@kickstarter.com>; Sat, 15 Feb 2014 21:18:46 +0000 (GMT)

Notice that the earlier time stamps (corresponding to when the emails were generated) are around 21:18 GMT, but the arrival timestamps are around 21:49 PST, about 8 and a half hours later. And that's about how far apart our emails arrived. I imagine more are in the queue.

(And yay crapflooders for making it impossible to format things usefully in Slashdot comments.)

As far as passwords go, I'm not worried about anyone actually hacking my Kickstarter password. It's a password unique to Kickstarter, and it was generated at random.org as a 13 character mixed-case alphanumeric password. Good luck reverse-hashing that. Even if you do, it won't get you much.