gnaffle

That's correct (even though he did mention "watch the height" and could have followed up on that). If I remember correctly, even the left chair pilot also applied nose-up inputs at some point in time.

Air France 440 was also shrouded in mystery (but nowhere near this degree), and turned out to be very poor airmanship by one pilot.

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).

That's laudable, but countless examples show that not everyone is that diligent.

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).

An interested party could find stuff that you're not aware off by looking at HEAD.

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.

You grant that permission to the person legitimately checking out code, but not to the person finding or stealing a laptop with a clone of a repository. The latter is a side-effect of how a DVCS works.

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).

Well, you do that anyway when you allow people to check out a local copy of the code. Just as in most VCSes, you can set up a git server to only allow checkout of specific branches.

I call that filter bubble. I like using git for local commits, but 15 out of 20 persons here don't even take their laptop with them and I bet that 17 out of 20 won't touch code on the road. Maybe at home, if they have to. A decent centralized VCS would totally do.

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?

Agreed. I usually like JLGs commentary, but he's no expert on processor technology, and this time his analysis falls short.

My biggest gripe with the Pi is a lack of proper USB power, so if you add all the stuff you need, especially for a wireless setup it's not so cheap and compact anymore. I'm happy that they've (hopefully) fixed the USB power problem, that makes it much nicer as a platform.

Here are a couple of use cases:

- 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!

Didn't the tobacco companies also spend money to discredit scientists and peer-reviewed articles and seed misinformation about the real risks of smoking, all while they were sitting on that mortality data? I think that was the real problem.

Thanks, I hadn't read this before.

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

If you had taken the time to also read the words preceding your quote, "but just like with new,", you would have realized that I was making a comparison instead of believing I was making the claim that GMOs include new, man-made chemicals.

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).

It's not so much that it's intrinsically bad, but just like with new, man-made chemical compounds that has never existed before, there's a possibility that there are adverse effects that we can't anticipate and won't be apparent for many years to come. After all the experience we've had with persistent pollutants, I think we're right to be cautious.

No, they're not. If you want to, you can buy an iPhone, sync it with iTunes, and apart from downloading apps and OS upgrades, that iPhone doesn't have to speak to the Apple cloud at all.

If you Mac loses power and doesn't get to do a normal shutdown, you're eventually going to get file system errors that you can only fix by booting from a recovery disk. I've had this happen numerous times due to a broken battery on my laptop. If you've never ever run a disk repair on your Mac, do one and you might be surprised. You should expect more from a filesystem in 2014.

We don't know what he would have said, but what he did say before he passed away was that he explicitly didn't want people at Apple to ask what Steve would have done, he wanted them to do what they felt was right.

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.

I'm not willing to bet anything on that, one week before WWDC in a year where Tim Cook has already gone on record saying that Apple is going to launch "new product categories".

The difference is that people in the know (for Apple, the kind of people on HN, for Beats, the kind of people on Head-Fi) would say that the characterization is wrong for Apple, and right for Beats.

Then again, what did we see before the iPhone launch? Not much more than incremental improvements to Macs and iPods.

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

Well, for certain definitions of "working" it did. I remember not so fondly trying to do emergency work with SSH over GPRS back in the day, with incredible lag and connection freezes every couple of minutes. Perhaps they figured out how to make TCP/IP work _properly_ over such connections.

That's not really true at night though, CCD cameras can change their light sensitivity quickly, something human eyes can't do (after a bright flash, you'll lose your night vision up to several minutes).

Continued glared isn't even necessary, losing the night vision (a problem that the camera doesn't show) is the real problem. It's not likely to directly cause an accident, but it might very well be a contributing factor (for many or most accidents that do happen, each contributing factor has usually happened multiple times before without causing an accident).

I find it interesting how many people here discount the risks of laser pointers, and trivialize the stories of pilots. The very same people probably encounter the same attitude from customers and others in their work in the IT industry, for instance with regards to security measures ("why can't we just run our customer database on a publically reachable IP, it saves so much trouble, and I know a guy that has done it for years and never had a problem!").

Agreed. It might be quirky, but I many of the things he lists here must be things he has experienced (like people buying parrots because they heard he likes parrots) and doesn't want happening again.

Then again, Apple had the same problem with the iPhone. They managed to solve it by lanching in a few countries first and working tightly with selected mobile operators.

I agree that it's hard, but they've shown the willingness to do hard and boring things before and take their time, launching in markets when they're ready (look at how long it took them to launch on Verizon).

However, the cable and sattelite providers also have a huge interest in pushing their own set-top boxes loaded with their streaming services etc. So I think the real issue isn't just software, it's politics and contract negotiations.

I don't think Apple is going to be happy with a situation where customer spend 90% of their time pushing buttons on a non-Apple remote control. So they probably won't be relying on set-top boxes unless they think they have such a compelling story on the content side that most people won't bother with the set-top box.

The parent _didn't_ say "It's hard to see Beats justifying a $3.2bn valuation". He said "It's hard to see Beats justifying a $3.2bn valuation without a significant part of that being the value of the brand", which is a completely different proposition.

I think the big problem with Google is their obsessive compulsiveness in collecting data. Searches, chat logs, locations, everything is collected because storage is cheap. The collect it to improve their services, sure, to better target their advertising, of course. And Google may strive to protect that data and not share it with others. However, all this data makes Google a gold mine for governments, and giving out the data is not really in their control.

There are other companies that have business models don't necessitate all this data collection. When these companies have to cooperate with governments, there's a limit to the amount of useful information they can hand out about their customers.

Ah, thanks!

I have a Solidoodle 3. After a problem with a clogged nozzle and trying different build surfaces (glass plate + hairspray for adhesive) I've had a long run of successful prints (ABS only). I've printed a set of Prusa i3 parts for a friend, for instance, and some other pretty big objects. The printer does need recalibration from time to time, especially after moving it, but it doesn't take too much time. You do have to get used to the various "quirks", play around with different temperatures for different plastic colors etc, and not be afraid to take things apart.

Luckily, at least for the Solidoodle and I would assume most of the other popular designs like the Prusa or Makerbots, there's a good support community out there with tons of illustrated guides to help you with almost any problem.