> 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).
My understanding is that the pilot in the left chair didn't realize that the pilot in the right chair kept pulling his stick back. In boeing planes, the sticks move together, so that wouldn't be possible. And the pilot in the right chair clearly didn't understand that in the alternate law the fly by wire system was running in, his stick movements put the plane at risk.
Yes, it was a completely incorrect reaction by a single pilot, combined with a catastrophically bad design for the controls, which caused that crash. It is completely insane to me that anyone would think that averaging inputs from two pilots and providing no feedback would be even remotely a good idea.
I mean physical feedback. In any rationally designed aircraft, the controls are physically linked, such that moving one moves the other (or at the very least this arrangement is faked with servos). When two pilots attempt to give contradictory inputs, they immediately know it because they can feel the other one fighting.
Yes, in the Air France tragedy, the aural warning clearly wasn't enough. Through fear and panic, the pilots failed to understand what the plane was telling them. But the feeling of having a control yoke fight against you doesn't require much mental effort to process.
Aural warnings are so easy to ignore. There are a ton of stories that go like, "What is that annoying buzzing sound? Well, no time to worry about it now, I'm landing. <CRUNCH> Oh, it was the gear warning." Happened to a friend of mine, even.
I think it ultimately comes down to engaging with the primary sense you're already using. If you're doing something visual, then a visual warning (on whatever you're looking at) can be effective, while an aural warning won't. If you're listening to something then interrupting it with an audio warning will work great. Hand flying is a tactile experience, so that's the sense you want to work with.
Yes. You give an example of someone ignoring a single aural warning. The case of AF447 was much worse.
There was a cacophony of different sounds and noises in the cockpit of AF447. All the various alarms are deliberately made to sound different. But when someone knows he's a minute from death, there's no way his reptilian brain can make sense of a plethora of simultaneous alarms. It will, instead, strive to tune them all out.
I remember a documentary where Duke Cunningham discussed his experiences as a fighter ace in Vietnam. In high stress situations he would switch his intercom to allow him to speak to his RIO, but not be able to hear his RIO. He didn't want the distraction. (Note: sadly, Cunningham disgraced himself in later life).
I built a gear warning system for my glider. The usual ones just have either as steady tone or a pulsing tone. I made mine do a pulsing tone with different speeds, then it actually spells out "WARNING GEAR UP" in morse code. I don't know morse code, but I figured the irregular pattern would make it more identifiable and harder to ignore.
I've seen it advised to turn off the aircraft radio when it's not useful and you're in the middle of something tricky, like climbing out from a low altitude, or landing in a field.
> I've seen it advised to turn off the aircraft radio when it's not useful and you're in the middle of something tricky, like climbing out from a low altitude, or landing in a field.
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.
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.
>Well, you do that anyway when you allow people to check out a local copy of the code.
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. In SVN you don't even need to expose the full history, you can grant access to the last revision only.
> Just as in most VCSes, you can set up a git server to only allow checkout of specific branches
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.
> 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).
> I'm not sure what you're getting at. What difference is there
A checkout from SVN/CVS only contains the last version. Files that were deleted in an earlier version are only on the server. A clone of a DVCS contains all versions and all files that ever were in the repo (unless you use BFG or git-filter-branch, but people tend to forget that). So a clone can contain secrets that people are not aware of, such as accidentally committed and deleted files. An interested party could find stuff that you're not aware off by looking at HEAD.
> (not that you would allow checkouts on unencrypted laptops anyway)?
That's not my call to make, but I agree on that regard. Reality sadly different from what we both wish.
> 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.
> 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.
If you go further upthread you'll find that I said "a valid tradeoff, but one I'd keep in mind"
> We've had instances where secrets were committed to local repositories by accident.
That's laudable, but countless examples show that not everyone is that diligent. I'd love if I could lock down some parts of some repos so that they're only accessible by people that I have an elevated level of trust in. (and where I can enforce a certain security level on the laptop).
> 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).
In any given larger organization there are people that have exert control over only parts of the whole. I could possibly argue to tighten down security on parts of a repository for some people within boundaries (like declare some folders as unreadable to some folks that don't need access to those) but I can't deny them all access since they need some of the content stored in the repo. With git that's currently all or nothing which exposes a flank that I'd prefer closed. In this particular case it's not a terrible issue, but for other folks with other data that can quite well be, so the tradeoffs may end up being in favor of SVN. I can imagine that that's one of the reasons I still see SVN deployed in corporate installations.
> 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?
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.
I've been providing power over the GPIO header directly, and have had great results. Combine a DC-DC supply with a few smoothing capacitors on a small daughter-board, add a barrel jack + 0.1" headers to interface and you get a lot more headroom and flexibility with how you power it.
(Same-ish end result as the other fuse bypass methods, but with no soldering on the pi, and the caps seem to help with the inrush current required for hot-plugging USB devices. )
It's a tradeoff vs device safety, but is super cheap, and the operational reliability is worth it for me. Every time I stage a pi for a project that isn't powered this way, I'm surprised how much frustration is involved.
Looking forward to this improvement with the B+ as much as anything else.
- 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!
This one made me think about public outrage against tobacco companies.
One minor theme in this article is that AECL denied knowledge of any reports of Therac-25 malfunctions even when, looking at a timeline of publicly-known events, such ignorance might be described as "implausible".
They don't seem to have been punished for this, and while I agree that it isn't laudable I also agree that it's not the greatest infraction. AECL really did care about the proper functioning of their machine. They really did look for problems. They cooperated with the FDA to a very great extent. It's hard to fault them for not thinking of testing "what if we enter incorrect configuration information, and then correct it within 8 seconds?"
But tobacco companies are routinely vilified for sitting on cigarette mortality data, as if this was by itself enough to make them irredeemable. They didn't even get off with a light punishment, much less the zero punishment AECL received. I suspect the difference, in the minds of many, is that AECL was a benign company advancing a useful purpose, while tobacco companies sold a product whose only use was to kill the operator. But that was legal then and remains legal today -- how can it be the justification for punishing them extra-hard for otherwise minor problems? AECL's misrepresentedly-unsafe product didn't even kill the operator; it killed random sick people who trusted the hospitals.
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.
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.
> "new, man-made chemical compounds that has never existed before"
GMO cultivars usually do not contain new, man-made chemical compounds.
For example, Golden Rice contain beta carotene (occurs naturally in e.g. carrots).
The virus resistant Hawaiian Rainbow Papaya contains a protein from the virus' capsid, effective "vaccinating" the plants, resulting in virus resistance.
Bt Cotton contains a chemical from Bacillus thuringiensis, a common bacterium in soils, that is harmful to pest insects.
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).
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.
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).