It was poor airmanship by two pilots (and other factors, including the feedback mechanisms and the lack of training for this particular high altitude scenario).

Sure, then again I would guess that the ones who are not that diligent are not likely to apply those access restrictions that you mention (although the "one revision" advantage is something they would get "for free" with SVN).

Well, that goes without saying. But I don't think that security argument is a very poor one compared to the huge benefit of having the history locally to inspect.

We've had instances where secrets were committed to local repositories by accident. It never got past review and into the master branch. If it had, we would probably had taken the effort to rewrite that commit out of the history.

I'm not sure what you're getting at. What difference is there (not that you would allow checkouts on unencrypted laptops anyway)?

> In SVN you don't even need to expose the full history, you can grant access to the last revision only.

> In SVN for example you can restrict people to single directories (or even files - I don't remember exactly). That at least is impossible in git. I can prevent pushes using hooks but not reads.

These restrictions may be useful in some cases, but I would wager that they are far more seldom than some of the advantages of git (like being able to work offline).

It's not only "for local commits", although being able to have local branches without polluting a public namespace is a huge win. It's also about _speed_ when you're doing VCS operations. Linus Torvalds actually made the case really well in his talk: https://www.youtube.com/watch?v=4XpnKHJAok8

> There are a lot of companies that actually would prefer if the code never left the premises and have a use-case for finer grained permissions (some folks can only touch the assets, others can only ever see the dev branch, can't see history,...), things that are by definition not possible in a DVCS.

That's a question that's completely orthogonal to whether or not you use a DVCS. How is a "traditional" VCS going to help you when you can check out the code locally and smuggle it out on a flash drive?

In my company, we use git and there are access restrictions as to who can access and commit to our branches.

> Storing large assets in git sort of suck and requires ulgy hacks. I'd love to version the toolchain and the VM images for the local development environment, but that's just not feasible with git.

..and that's not the use case for git. Linus has been very clear about _what_ git is optimized for, performance wise.

That doesn't mean that DVCSes in general are useless for storing large assets, but that the most popular implementation is. Also, I'm not really sure what traditional VCS you're referring to, that makes it easy to version VM images and remain storage efficient?

- Stick it on the back of your 3D printer and run OctoPrint on it to give a nice web interface for your 3D printer (and a web cam for time lapse capture).

- Connect it to my digital piano to record playing sessions and upload the MIDI files automatically to dropbox without me having to push any buttons except the "on" button on the piano.

There are a thousand other use cases where you want something more than a microcontroller, you just have to use your imagination!

For those that haven't read it, here's Levesons article on the Therac-25: http://sunnyday.mit.edu/papers/therac.pdf

New, man-made chemicals aren't intrinsically bad. But based on past experience, we are right to be cautious because we can't always anticipate their effects, the effects can take a long time to become apparent and they can be impossible to eliminate (like with PCBs).

The deal would make no sense whatsoever if not for the music streaming service. It's interesting that they get the headphone business along with it - my hope is that they will gradually beef up the quality of the headphones in the process.

We'll see next week what they'll have to announce.