In sub-urban and rural areas I think drone-based delivery can be cost-effective. I think the key is to use a hybrid model with a "drone carrier" truck which serves as a mobile base station so the drones are only making relatively short flights. Imagine a truck that pulls into a sub-urban neighborhood, stops in one central location and then launches a dozen drones to deliver packages to all of the homes within a half mile or so. Or perhaps the truck might not even have to stop, but just drive along launching drones which deliver along its path and then return to it, still in motion.

The advantage to the delivery service is that they could deliver to many nearby locations simultaneously, and trucks wouldn't have to be able to enter difficult locations (which currently constrains the design of package cars). This means the trucks could be larger, carrying more packages, and would deliver much faster, requiring fewer trucks and drivers. Given a self-driving truck, the "drivers" might end up being drone tenders/troubleshooters, rather than drivers. They could remotely designate appropriate drop-off locations when the drones can't find a good locations themselves, as well as handle any problems that arise with the equipment, and maybe still do package handling, to retrieve packages from storage in the truck and move them to where the drones can pick them up, at least until that can be adequately automated.

I think it makes a lot of sense. The technology isn't there yet, but I don't think it's far away.

All sort of true.

First, a bit of background on my context. I'm a software engineer for Google, and I work from home full-time. This is not a common situation in Google, which has an institutional belief in the value of co-located teams in open-plan offices as a way to facilitate communication. Google engineering methodologies are heavy on communication and light on process and documentation. They rely heavily on face to face communication, be it over cubicle walls, in hallways, at the cafes, etc.

On its face, this appears to just about the worst possible organization in which to work remotely. But I've been doing it for over a year now, and it's working just fine -- but only because my co-workers and I make it work. It's challenging, but it absolutely can be done.

Regarding your points:

1) Productivity at home. This depends heavily on the individual. I'm motivated and I like what I do, so even with the distractions at home I'm highly productive. If anything, my challenge is to avoid working too much. That's not the same for everyone, so YMMV.

2) Commuting. Commuting sucks. Even if it's a short commute. Some people do seem to like it, though, as a way of separating home and work life. My home and work lives blend, with more of a dynamic balance between them rather than sharp separation. Personally, I prefer that, but I know not everyone does.

3) Video conferencing is not a panacea, but it can really help. I have a Chromebox on my home office desk and another in my team's "bullpen" area, which are both set to an always-on video conference, so I have a virtual presence in the team area. It's not quite the same as being there, but I can hear and participate in random conversations that happen amongst the rest of my team, at least when they're at their desks. And of course, I attend all of my meetings the same way. It's kind of funny for my co-workers who see my face on the VC unit in the bullpen as they get up to walk to the meeting room, then see me "already arrived" when they get there. Because of course for me "traveling" from the bullpen to the meeting room is instantaneous.

4) Communication is challenging. In my case it helps that Google runs on e-mail, and much communication happens that way. I do find myself out of the loop occasionally, but my colleagues are generally pretty good about letting me know stuff, and sometimes even deliberately deciding to move a conversation to e-mail in order to make sure I'm involved. The inclusive culture is a big help, even at the same time as the co-located culture creates challenges.

The bottom line, to me, is that there are pros and cons, and those pros and cons are different for different employees and different companies. In my personal case, I think I'm probably 95% as effective working from home as I would be in the office, and that only by putting in a little extra time. For me, that's great, though. I'm perfectly happy to spend the time I would have wasted on commuting on work, and I love the flexibility that it gives me to balance my home and work lives.

What do I do with that flexibility? Well, I have no problem dropping what I'm doing (assuming I don't have any meetings scheduled) to go to my kids' school events or other activities. When I worked in the office I did the same, but there was a higher barrier, because I had to add an hour of extra commuting time (30 mins each way) to home and back. I also use the flexibility for recreation and exercise. My home is 12 miles from a ski resort, so I buy a season pass and during the winter I ski 4-5 days per week; most every weekday I start work early (6 AM), work until just before the lift opens then cruise up and ski for an hour or two, then head back to work. During the summer I've been taking my boat to the lake a couple of mornings per week to water ski with my kids (my house is 18 miles from one reservoir and 24 miles from another). I often go for a bike ride or a hike during lunch -- though I actually also did that when I worked in the office.

So I think it's great for me, and the company seems happy with my work. Win/win, even if I work a little more and produce a little less.

The Admiral of the US Navy should send a battleship up the Potomac River and fire a warning shot across the "bow of Capital Hill" ...

Fun fact: as of 2006, the US navy doesn't own any battleships anymore. It's all about the carriers, baby! I mean, I guess they could try and lug in a museum boat like the U.S.S. North Carolina, or something...

Actually it takes a double tap, quick and fairly well-targeted.

This is a fun device that can show you what can be done with 3D printed plastic. That said, it's useless. It would be really cool if I could apply 1 pound of force to the crank, turn it a Million times, and have it apply a Million pounds of rotational force at the other end. But it's made of plastic, so it won't do that. Indeed, the fast-rotating parts would wear out before the slow-rotating part made a single turn. So it's not even good as a kind of clock.

All that said, it's a good conversation piece, and probably worth the price for that.

What happened is that people who used the system very day, day in and day out, became so fast at entering the machine settings the rate of UI events exceeded the ability of the custom monitor software written for the machine to respond correctly to them.

Which is still to some extent a UI issue.

But the literal "killer" is what happened next:
  1) The machine detected that it had screwed up.
  2) But the UI reported this by a cryptic error message: "MALFUNCTION nn" - where the 1 = nn = 64 error codes not only weren't explanatory, but weren't even included in the manual.
  3) And if the operator hit "P" (for "proceed") the machine would GO AHEAD AND OPERATE in the known-to-be-broken mode, giving the patient a fatal (high-power, not-swept-around) electrons rather than a 100x weaker flood of x-rays, with NO FURTHER INDICATION that something is still wrong (unless you count the patient sometimes screaming and running out of the room.)

If 2) and 3) aren't user interface problems, what is?

According to wikipedia, that had software problems that ended up killing people What's that got to do with UI changes and user experience?

The original post was about bad user interfaces causing harm to people. Changes breaking the user experience was only one of the issues.

In Therac's case the bug WAS primarily in the user interface:
  - Due to a race condition, if a button happened to be pressed at the wrong moment and the menu filled out in a particular order, the device would configure the electron beam for x-ray generation rather than electron beam generation (high electron beam current, no scanning) but not position the target, flattening filter, collimator, or ion-chamber x-ray sensor in the beamway, resulting in a configuration that irradiated the patient with beta radiation, rather than x-rays, at 100x a normal dose.)
  - The machine DID detect that there was a problem. But it reported it as "MALFUNCTION nn" - where nn was a number from 1 to 64 and not explained in the manual. If the operator entered "P" (proceed), it would then go ahead and operate in the improper mode anyhow.

Both the second part and most of the first part sound like user interface problem to me.

Of course, in the years since those things were invented we've also invented amazing ways to send things like family pictures through email straight through your phone, and multigigabyte free online storage of photos that might outlast your lack-of-backups on the desktop, so... you win some, you lose some

Someone started uploading all the HackingTeam source code to GitHub ... There are also some signing keys for kernel drivers in here.

IMHO:

Anyone with a project hosted on git hub should pull a backup copy NOW!

Hosting this leak on git hub could lead to moves by authorities to contain it - which could have the side effect of making GitHub and/or some projects on it unavailable - temporarily or permanently.

Better safe than sorry.

... will this help bona fide security researchers with their work on fighting exploits on all platforms ... ?

I wonder if this will also help people trying to write open software for closed devices? Signing keys, driver sources with spyware installed, ... Not only does it expose the malware bypassing the user's security, it may also expose the internal details of how the devices are driven and/or how to compromise the malware's and devices' anti-user "security".

(I have often wondered how many of the closed-driver devices have the code closed just for business reasons and how many are closed because that's where the spyware has been installed and they can't let the source out - even sanitized - because that would lead to the spyware's exposure.)

The goal is to intimidate the makers of such designs. Arrest first and ask questions later, when such designs get out.

It's also to make it harder for "the common man" to arm himself - in case a Schelling Point is reached and a LOT of people suddenly decide that they need to arm themselves against the government or its puppeteers. By slowing them down, and reducing the number and quality of designs available, the powers that be have more time to react and try to divide and reconquer.

Of course intimidating designers is a big part of that.

This is not the first time they did this. In fact it has quite an interesting history in cryptography that was classified as a munition for just this reason.

Which is why OpenBSD is hosted from outside the US. (It's NOT just that Theo happens to live in Canada.)

Hehe, bad choice of examples. Yes, Sputnik was launched during an IGY year of "cooperation"... but that doesn't mean it wasn't a cold war space race from the beginning. The USSR announced their intention to launch an artificial satellite nine days after the US announced the same intention. Then the USSR went forward with designing the satellite, only to discover that their original planned machine was going to take too long. Afraid that the US might beat them to it, they stepped back and focused on a simpler design so they could get it into space faster, and beat the US. As soon as their launch vehicle was good to go, they launched, pushing back some planned military test launches to do it.

Makes perfect sense to me. There are lots of people whose lifestyles don't permit a regular job, but could use a flexible income supplement.

That's a rather violent, not to mention criminal, response. I think not.

First, my comment was not a "defense" of anything.

Second, you seem to have missed the sentence "It's not quite as good if the smartphone is also providing the fingerprint scanner and camera, because in the event of an attempted fraudulent transaction that means the attacker is in control of those components."

Also, you seem to have missed the last paragraph. In fairness, I suppose I wasn't quite clear enough. When I said that the security is in the same ballpark as a four-digit PIN, I was comparing to a system using phone-mounted sensors. With sensors provided by the retailer, in a staffed checkout lane, it's unambiguously stronger.