Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

flightglobal.com

Post reply on HN
Print view View original

191–200 of 311 posts

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#191

Post by lmm »

d1sxeyes wrote: post #76
lxgr wrote: post #72

Earlier quoted context omitted.

Injuries did increase, though, and I can't think of a plausible mechanism that would somehow cap expected outcomes at "injury but not death".

So we were talking about excess deaths, which means that supporting your argument with a paper that argues that a previous finding of excessive deaths was flawed is probably not the strongest argument you could make. Increased number of injuries but not deaths could be, for example, (purely making things up off the top of my head here) due to higher levels of distractedness among average drivers due to fear of terror…

> which results in more low-speed, surface-street collisions, while there’s no change in high speed collisions because a short spell of distractedness on the highway is less likely to result in an accident.

That's not a remotely plausible model though. There are recorded cases of e.g. 1.6 seconds of distractedness at high speed causing a fatal collision. Anything that increases road injuries is almost certainly also increasing deaths in something close to proportion, but a given study size obviously has a lot more power to detect injuries than deaths.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#192

Post by philsnow »

ericjmorey wrote: post #99
ronsor wrote: post #93

Earlier quoted context omitted.

> The general engineering challenge, is how we deal with little-used little-seen functionality (definitely thinking of fault-handling, but there may be other cases) that is totally reasonable when put in place, but has not aged well, and nobody has noticed or realized it, and even if they did it might be hard to convince anyone it's a priority to improve, and the longer you wait the more expensive. The solution to th…

Which company deployed a chaos monkey deamon on their systems? Seemed to improve resiliency when I read about it.

At Google, the global Chubby cell had gone so long without any downtime that people were starting to assume that’s it was just always available, leading to some kind of outage or other when the global cell finally did have some organic downtime.

Chubby-SRE added quarterly synthetic downtime of the global cell (iff the downtime SLA had not already been exceeded).

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#193

Post by lmm »

lesuorac wrote: post #181
lmm wrote: post #180

Earlier quoted context omitted.

> There are finite resources, true. So keep the tickets open. Eventually someone will fix them. Realistically, no, they won't. If the rate of new P0-P2 bugs is higher than the rate of fixing being done, then the P3 bugs will never be fixed. Certainly by the time someone gets around to trying to fix the bug, the ticket will be far enough out of date that that person will not be able to trust it. There is zero value in…

But then when somebody else has the issue they make a new bug and any data/investigation from the old one is basically lost. Like what's wrong with having 1000 open bugs?

> But then when somebody else has the issue they make a new bug and any data/investigation from the old one is basically lost.

You keep the record of the bug, someone searching for the symptoms can find the wontfix bug. Ideally you put it in the program documentation as a known issue. You just don't keep it open, because it's never going to be worked on.

> Like what's wrong with having 1000 open bugs?

Noise, and creating misleading expectations.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#195

Post by lmm »

YokoZar wrote: post #189
lmm wrote: post #180

Earlier quoted context omitted.

> There are finite resources, true. So keep the tickets open. Eventually someone will fix them. Realistically, no, they won't. If the rate of new P0-P2 bugs is higher than the rate of fixing being done, then the P3 bugs will never be fixed. Certainly by the time someone gets around to trying to fix the bug, the ticket will be far enough out of date that that person will not be able to trust it. There is zero value in…

Every once in a while I get an email about a ten plus year old bug finally getting fixed in some open source project. If it's a good bug accurately describing a real thing, there's no reason to throw that work away rather than just marking it lower priority.

> If it's a good bug accurately describing a real thing, there's no reason to throw that work away rather than just marking it lower priority.

Perhaps. But the triage to separate the "good bugs accurately describing real things" from the chaff isn't free either.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#196

Post by pj_mukh »

jrochkind1 wrote: post #33

I don't know how long that failure mode has been in place or if this is relevant, but it makes me think of analogous times I've encountered similar: When automated systems are first put in place, for something high risk, "just shut down if you see something that may be an error" is a totally reasonable plan. After all, literally yesterday they were all functioning without the automated system, if it doesn't seem to b…

"When automated systems are first put in place, for something high risk, "just shut down if you see something that may be an error" is a totally reasonable plan"

Pretty sure this is exactly what happened with Cruise in San Francisco, cars would just stop and await instructions causing traffic jams. City got mad so they added a "pullover" mechanism. Except now, the "pullover" mechanism ended up dragging someone who had been "flung" into the cars path by someone who had hit and run a pedestrian.

The real world will break all your test cases.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#197

Post by nightowl_games »

zer8k wrote: post #123
nightowl_games wrote: post #90

Earlier quoted context omitted.

I don't know that and I don't like this assumption that only 'managers' make mistakes, or that software engineers are always right. I thinks needlessly adversarial, biased and largely incorrect.

Spoken like a manager. Look, when you're barking orders at the guys in the trenches who, understandably in fear for their jobs, do the stupid "business-smart" thing, then it is entirely the fault of management. I can't tell you how many times just in the last year I've been blamed-by-proxy for doing something that was decreed upon me by some moron in a corner office. Everything is an emergency, everything needs to be…

Wow that was adversarial. You are making an assumption about me that is wrong. I'm a high level engineer and have written an absolute boat load of code over my career. I've never been a manager.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#199

Post by acacar »

Arainach wrote: post #89
telgareith wrote: post #69

Earlier quoted context omitted.

Dig into the OpenZFS 2.2.0 data loss bug story. There was at least one ticket (in FreeBSD) where it cropped up almost a year prior and got labeled "look into layer," but it got closed. I'm aware closing tickets of "future investigation" tasks when it seems to not be an issue any longer is common. But, it shouldnt be.

>it shouldnt be Software can (maybe) be perfect, or it can be relevant to a large user base. It cannot be both. With an enormous budget and a strictly controlled scope (spacecraft) it may be possible to achieve defect-free software. In most cases it is not. There are always finite resources, and almost always more ideas than it takes time to implement. If you are trying to make money, is it worth chasing down issues…

No, uh-uh. You can't sweep a data loss bug under the rug, under any circumstances, especially in a filesystem. Curdle someone's data just once and they'll never trust you again.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#200

Post by SoftTalker »

ryandrake wrote: post #28
steeeeeve wrote: post #15

You know there's a software engineer somewhere that saw this as a potential problem, brought up a solution, and had that solution rejected because handling it would add 40 hours of work to a project.

... or there's a software engineer somewhere who simply assumed that three letter navaid identifiers were globally unique, and baked that assumption into the code. I guess we now need a "Falsehoods Programmers Believe About Aviation Data" site :)

And this is why you always use surrogate keys and not natural keys. No matter how much you convince yourself that your natural key is unique and will never change, if a human created the value then a human can change the value or create duplicates, and eventually will.
Post reply on HN