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

171–180 of 311 posts

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

#171

Post by KerrAvon »

astrange wrote: post #161
Nevermark wrote: post #154

Earlier quoted context omitted.

We better get this sorted out before open source manned Mars missions. That all programming languages, down to statically typed assembly, don’t support something as simple to validate as unit consistency says something strange about how the science of replacing unreliable manual processes with automated systems is really bad at the practice of replacing its own risky manual processes with automated systems. If numeri…

Some languages do; F# and Ada have units. I agree no sexy languages have it, and almost all languages have terrible support or anti-support for correctness in numerical programming. It's very strange. (By anti-support I mean things that waste your time and make it harder. For instance, a lot of languages think "static typing" means they need to prevent you from doing `int a,b; short c = a * b;` even if this is totall…

`short c = a * b` can be both well-defined and a serious bug if (a * b) is greater than `sizeof(short)`. Whether it _is_ a bug depends on what you're doing.

Swift has units as part of the standard library. In the sense that matters here, Rust and C++ could also have units. It requires a level of expressiveness in the type system that most modern languages do have, if you put it to use.

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

#172

Post by astrange »

KerrAvon wrote: post #171
astrange wrote: post #161

Earlier quoted context omitted.

Some languages do; F# and Ada have units. I agree no sexy languages have it, and almost all languages have terrible support or anti-support for correctness in numerical programming. It's very strange. (By anti-support I mean things that waste your time and make it harder. For instance, a lot of languages think "static typing" means they need to prevent you from doing `int a,b; short c = a * b;` even if this is totall…

`short c = a * b` can be both well-defined and a serious bug if (a * b) is greater than `sizeof(short)`. Whether it _is_ a bug depends on what you're doing. Swift has units as part of the standard library. In the sense that matters here, Rust and C++ could also have units. It requires a level of expressiveness in the type system that most modern languages do have, if you put it to use.

It can be a serious bug if it overflows and you didn't intend it to happen or you expected overflow behavior to do something different. But that's also true of `int c = a*b`, and yet that's not a compiler error.

int/short should be thought of as storage size optimizations for memory. They're very bad ways to specify the correct range of values for a variable.

(Ada has explicitly ranged integers though!)

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

#173

Post by RcouF1uZ4gsC »

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.

The same company that was in the news recently for screwing up a livestream of a boxing match.

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

#174

Post by sameoldtune »

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…

> switching back to a rarely used and much more inefficient manual process is extremely disruptive, and even itself raises the risk of catastrophic mistakes.

Catastrophe is most likely to strike when you try to fix a small mistake: pushing a hot-fix that takes down the server; burning yourself trying to take overdone cookies from the oven; offending someone you are trying to apologize to.

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

#175

Post by gopher_space »

crubier wrote: post #155
convivialdingo wrote: post #116

I guarantee that piece of code has a comment like /* This should never happen */ if (waypoints.matchcount > 2) {

Possibly even just waypoint = waypointsMatches[0] Without even mentioning that waypointsMatches might have multiple elements. This is why I always consider [0] to be a code smell. It doesn't have a name afaik, but it should.

Race condition?

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

#176

Post by skissane »

marcosdumay wrote: post #169
skissane wrote: post #132

Earlier quoted context omitted.

> I assumed IATA messed up, This isn’t IATA. IATA manages codes used for passenger and cargo bookings, which are distinct from the codes used by pilots and air traffic control we are talking about here-ultimately overseen by ICAO. These codes include a lot of stuff which is irrelevant to passengers/freight, such as navigation waypoints, military airbases (which normally would never accept a civilian flight, but still…

Hum, no. It's not about ICAO codes. It's about local UK codes, and IATA ones used by mistake.

The code that caused the issue is DVL, which isn’t a “local UK code”, it is a code used by the FAA for a location in the US and a code used by EASA for a location in France. And I didn’t say ICAO issued the codes, I said the process of issuing them by regional/national aviation authorities is “ultimately overseen by ICAO”, which I believe is correct.

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

#177

Post by e28eta »

theolivenbaum wrote: post #100
ericjmorey wrote: post #99

Earlier quoted context omitted.

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

Netflix did that many years ago, interesting idea even if a bit disruptive in the beginning https://netflix.github.io/chaosmonkey/

See also, the rest of the simian army: https://netflixtechblog.com/the-netflix-simian-army-16e57fba...

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

#178

Post by chrisweekly »

RcouF1uZ4gsC wrote: post #173
ericjmorey wrote: post #99

Earlier quoted context omitted.

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

The same company that was in the news recently for screwing up a livestream of a boxing match.

True, but it's the exception that proves the rule; it's also the same company responsible for delivering a staggeringly high percentage of internet video, typically without a hitch.

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

#179

Post by mmaunder »

There’s little to no authentication on filing flight plans which makes this a potentially bigger problem. I’m sure it’s fixed but the mechanism that caused the failure is an assertion that fails by disconnecting the critical systems entirely for “safety”. And the backup failed the same way. Bet there are similar bugs.

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

#180

Post by lmm »

Shorel wrote: post #108
Arainach wrote: post #89

Earlier quoted context omitted.

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

I'm in total disagreement with your last paragraph. In fact, I can't see how it follows from the rest. Software can have defects, true. There are finite resources, true. So keep the tickets open. Eventually someone will fix them. Closing something for spurious psychological reasons seems detrimental to actual engineering and it doesn't actually avoid any real problem. Let me repeat that: ignoring a problem doesn't ma…

> 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 keeping the ticket around.

> Anything else is supporting a lie.

Now who's prioritising "spurious psychological reasons" over the things that actually matter? Closing the ticket as wontfix isn't denying that the bug exists, it's acknowledging that the bug won't be fixed. Which is much less of a lie than leaving it open.

Post reply on HN