One of the hazards of computerization/automation

[Matthew]

Accidentally deleted calibration files caused 3 of four engines to fail:

http://www.reuters.com/article/2015/06/09/us-airbus-a400m-idUSKBN0OP2AS20150609

 

[wsuffa]

rm -rf *

 

[jsstevens]

rm -rf *

I've seen that done once. The first indication was: rm: busy

Bad news.

John

 

[Bob Noel]

More a failure of the safety analysis.

 

[dans2992]

I did that once...

Meant to type:
rm -rf xyz*
Instead of:
rm -rf xyz *

Oops

 

[MAKG1]

I did that once...

Meant to type:
rm -rf xyz*
Instead of:
rm -rf xyz *

Oops

alias rm 'rm -i'

Irritating as hell, but it prevents disasters.

 

[denverpilot]

alias rm 'rm -i'



Irritating as hell, but it prevents disasters.

Every time I run into that, I hit CTRL-C and add a -f.

Faux Windows "Are you sure? Y/N" behavior annoys the hell out of me.

Yes. I understand I work on an OS that expects me to get the command right the first time, or if I didn't make appropriate backups, hitting enter may be a career limiting action. It's been that way for 20 years before I started using it, and it'll be that way after I'm dead.

Kinda like aviation. Don't do the stuff that will kill you. Or you'll be dead. Same mentality.

Of course I also learned to preface any executable command with ./ when we had to work our way carefully through cleaning up a machine that had binaries replaced with malicious crap.

That good habit never dies once you start doing it. $PATH is not always your friend.

 

[jsstevens]

Every time I run into that, I hit CTRL-C and add a -f.

Faux Windows "Are you sure? Y/N" behavior annoys the hell out of me.

Yes. I understand I work on an OS that expects me to get the command right the first time, or if I didn't make appropriate backups, hitting enter may be a career limiting action. It's been that way for 20 years before I started using it, and it'll be that way after I'm dead.

Kinda like aviation. Don't do the stuff that will kill you. Or you'll be dead. Same mentality.

Of course I also learned to preface any executable command with ./ when we had to work our way carefully through cleaning up a machine that had binaries replaced with malicious crap.

That good habit never dies once you start doing it. $PATH is not always your friend.

Yes! And I usually set up any root account to remove ./ from the path too. I'll type it when I want it, but otherwise to easy for someone to put a chown binary with a common name around...

 

[bflynn]

I did that once...

Meant to type:
rm -rf xyz*
Instead of:
rm -rf xyz *

Oops

Yup.

rm *.doc is not the same as rm * .doc

One is OK to do at the end of the semester when you want to clean Word files out of your directory before the professor copies your code for grading. The other is not OK to do and becomes an emergency test of the sysadmin's backup policies.

 

[bflynn]

Accidentally deleted calibration files caused 3 of four engines to fail:

http://www.reuters.com/article/2015/06/09/us-airbus-a400m-idUSKBN0OP2AS20150609

The more they overthink the plumbing, the easier it is to stop up the drain.

Things like this scare the heck out me. Somehow I can accept a pilot making a mistake and crashing an airplane - I don't like it, but it is just barely tolerable. But I cannot accept an airplane crashing because some IT guy got a visit from the screw-up fairy.

I think if the average public knew how completely messed up IT actually is, they wouldn't want anything to do with it.

 

[jsstevens]

The more they overthink the plumbing, the easier it is to stop up the drain.

Things like this scare the heck out me. Somehow I can accept a pilot making a mistake and crashing an airplane - I don't like it, but it is just barely tolerable. But I cannot accept an airplane crashing because some IT guy got a visit from the screw-up fairy.

I think if the average public knew how completely messed up IT actually is, they wouldn't want anything to do with it.

I worked on an F-5 flight sim in the mid 1980s. At one point I was doing all the weapons scoring software which included calculating aim-off distance for high angle bomb drops. This is the distance from the bomb impact to where the flight path (if continued from bomb release) would hit the ground. I had x, y & z location and roll pitch and yaw of the fuselage reference line to work with. I was getting bad results until I remembered AOA. Now, I didn't have AOA as a modeled value, but I could get the indicated angle from the AOA instrument in the panel. So I used the indicated value to subtract from the fuselage reference line. And I got negative aim-off distances. So I checked the value. At 350 knots, in a 30 degree dive, the F-5 was indicating 8 degrees (more or less) of AOA. Um, no. So I started asking questions and found out that the AOA was only looked at during landing approach and they had "fudged" the reading until the instructor pilots said "That's about right." My solution was to take the indication (which did vary the right direction based on pull or push) and divide it by 4. This was pretty close.

When I explained all that to the instructor pilot I was working with (who had finished his AF career flying F-111s with the terrain following radar/auto pilot combo) he said "If I knew how you guys wrote software I would have never gotten into the F-111!"

So, yeah, most people don't know how screwed up IT can be. Although, flight software development is much more rigorous than the simulation stuff I was working on.

John

 

[Matthew]

The more they overthink the plumbing, the easier it is to stop up the drain.

Things like this scare the heck out me. Somehow I can accept a pilot making a mistake and crashing an airplane - I don't like it, but it is just barely tolerable. But I cannot accept an airplane crashing because some IT guy got a visit from the screw-up fairy.

I think if the average public knew how completely messed up IT actually is, they wouldn't want anything to do with it.

I work with embedded systems. Calibration data, configuration data, other data is critical to proper operation. It's like trying to idiot-proof any system. If a file is missing, you can flag it. If a file is corrupted, you can probably flag it. If a file is WRONG, then what? It's not that easy.

The complexity of computer controlled equipment can be enormous.

 

[luvflyin]

Accidentally deleted calibration files caused 3 of four engines to fail:

http://www.reuters.com/article/2015/06/09/us-airbus-a400m-idUSKBN0OP2AS20150609

From the article>>> yet as the pilots took off, another safety feature came into play only to turn against the crew......

OPEN THE POD BAY DOORS HAL

 

[rpadula]

I work with embedded systems. Calibration data, configuration data, other data is critical to proper operation. It's like trying to idiot-proof any system. If a file is missing, you can flag it. If a file is corrupted, you can probably flag it. If a file is WRONG, then what? It's not that easy.

The complexity of computer controlled equipment can be enormous.

Me too. You know what they say about nature making better idiots.

I guess the solution in the case of aircraft engines will be don't let the engine start if any of the above are missing.

 

[Matthew]

Me too. You know what they say about nature making better idiots.

I guess the solution in the case of aircraft engines will be don't let the engine start if any of the above are missing.

You'd think it would be part of the self-test. But there might still be some default values that are in place - and they might be 'close enough' to pass limits tests but not 'close enough' to work. Dunno.

Sometimes I'm glad I don't work on safety critical things that could kill someone if I simply don't think far enough ahead. (I used to, but that was a long time ago. We had some pretty good design procedures and failsafe systems.)