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

UK air traffic control meltdown

jameshaydon.github.io

Post reply on HN
Print view View original

431–440 of 459 posts

Re: UK air traffic control meltdown

#431

Post by andrewaylett »

lxgr wrote: post #316
bsder wrote: post #268

Earlier quoted context omitted.

WTW is a proprietary system that should never be used: https://www.walklakes.co.uk/opus64534.html The biggest fault (besides being proprietary) is that you must be online in order to use WTW. The times that you might need WTW are ALSO the times you are most likely to be unable to be online.

> The biggest fault (besides being proprietary) is that you must be online in order to use WTW. That doesn't seem to be the case anymore. It's still not a great system – many included words are ambiguous (e.g. English singular and plural forms are both possible, and an "s" is notoriously difficult to hear over a bad phone line), and it's proprietary, as you already mentioned.

It's definitely not the case, as the word list and algorithm are not secret (notwithstanding that they're proprietary) and have been re-implemented and ported into at least a couple of languages that allow for offline use. I have a Rust implementation that started life as a transliteration from Javascript. I wouldn't recommend using it, still -- I wrote it in the hope of finding more problems with collisions, not because I like it.

Re: UK air traffic control meltdown

#432

Post by dopidopHN »

dghughes wrote: post #418
dopidopHN wrote: post #227

Earlier quoted context omitted.

French here, as much as I wish It was the case for comical effect… I don’t think so. Our right wing press is also desperately economically liberal so anything privately run is inherently better. Maybe radio stations? Honestly, major respect to the daily mail for those snarky attacks that keep up the good spirits between our two countries. It’s maybe the food or the weather that make them aggro ? Idk, but don’t worry,…

Isn't that why France has a President the position was created just to blame them? lol

Our last iteration of the constitution grant them large powers and leeway

But indeed, the unspoken rule is also that we hate them with a passion no matter what.

Re: UK air traffic control meltdown

#433

Post by cutemonster »

jefftk wrote: post #426
jwr wrote: post #400

Earlier quoted context omitted.

My grandfather was working with Stanisław Skarżyński, who was preparing for his first crossing of the Atlantic in a lightweight airplane (RWD-5bis, 450kg empty weight) in 1933. They initially mounted two compasses in the cockpit, but Skarżyński taped one of them over so that it wasn't visible, saying wisely that if one fails, he will have no idea which one is correct.

> if one fails, he will have no idea which one is correct Depends how it fails! For example, say, when you change direction one turns and the other doesn't.

Couldn't he bring his own 3rd? Compasses aren't heavy?

Re: UK air traffic control meltdown

#434

Post by clankyclanker »

robocat wrote: post #367
pmarreck wrote: post #364

Earlier quoted context omitted.

There are a number of word lists whose words were picked due to their beneficial properties given the use-case of possibly needing to be understood verbally over unclear connections. The NATO phonetic alphabet, and PGP word lists come to mind: https://en.wikipedia.org/wiki/PGP_word_list I'm particularly a fan of the PGP word list (it would definitely require more than 3 words for this purpose, though) because it has…

> I'm particularly a fan of the PGP word list As a New Zealander, the PGP list is unfriendly because there are plenty of words that are hard to spell, or are too US centric. dogsled (contains silent d, and sleigh might be a British spelling) Galveston (I've never heard of the place) Geiger (easy to type i before e - unobvious) Wichita (I would have guessed the spelling began with which or witch) And why did the desig…

I never knew there was a “sleigh” in “dogsled,” I’ve only ever heard “sled,” like “slid” or “skid.”

Re: UK air traffic control meltdown

#435

Post by samus »

crabbone wrote: post #419
samus wrote: post #409

Earlier quoted context omitted.

The point of fuzzing is precisely to discover cases that the programmers couldn't think about, and formal methods are useful to discover invariants and assumptions that programmers didn't know they rely on. Furthermore, identifiers from external systems always deserve scepticism. Even UUIDs can be suspect. Magic strings from hell even more so.

Sorry, you missed the point. If programmer didn't know that repetitions are allowed, they wouldn't appear in the input to the fuzzer as well. The mistake is too trivial to attribute it to the programmer incompetence / lack of attention. I'd bet my lunch it was because the spec is written in an incomprehensible language, is all over the place in a thousand pages PDF, and the particular aspect of repetition isn't cover…

> If programmer didn't know that repetitions are allowed, they wouldn't appear in the input to the fuzzer as well.

It totally would. The point of a fuzzer is to test the system with every technically possible input, to avoid bias and blind spots in the programmer's thinking.

Furthermore, assuming that no duplicates exist is a rather strong assumption that should always be questioned. Unless you know all about the business rules of an external system, you can't trust its data and can't assume much about its behavior.

Anyways, we are discussing about the wrong issue. Bugs happen, even halting the whole system can be justified, but the operators should have had an easier time figuring out what was actually going on, without the vendor having to pore through low-level logs.

Re: UK air traffic control meltdown

#436

Post by seabass-labrax »

epolanski wrote: post #309
seabass-labrax wrote: post #225

I had been considering becoming an air traffic controller myself, and it rather tickles me to think I might have missed my once-in-a-lifetime opportunity to direct aircraft with the original pen-and-paper flight strip mechanism in the 21st century! Completely safe, excruciatingly low-capacity, and sounds like awfully good fun as a novelty (for the willing ATC, not the passengers stuck on the ground, I hasten to add).

Quite few non major airports are still heavily pen and paper reliant methods to some degree. An example are islands that serve few flights per week and can't justify heavy update investments. Airplanes are generally spaced by hours and you need to do your math about where the airplanes are by hand. But again there's so little planes that risks are minimal.

Indeed, but the set of aerodromes that are large enough to have a tower controller but not large enough to have their own radar surveillance is shrinking all the time. Radar is getting cheaper and what with ADS-C and TA/RA, a big reason to have ATC even without radar is vanishing (namely that of preventing collisions close to the airport). Oceanic control is probably the closest you can get nowadays to routine ATC without radar, even though they now have automatic position reports via satellite.

Re: UK air traffic control meltdown

#437

Post by seabass-labrax »

splonk wrote: post #359
seabass-labrax wrote: post #193

Earlier quoted context omitted.

It is, but fixes are almost always spoken as words rather than letter-by-letter. For this reason, they are usually chosen to be somewhat pronounceable, and occasionally you even get jokes in the names. Likewise, radio beacons and airports are usually referred to by the name of their location; for instance "proceed direct Dover" rather than "proceed direct Delta Victor Romeo". I think a lot of pilots and air traffic c…

I really enjoy the joke names. Portsmouth, NH has a Sylvester/Tweety Bird approach: ITAWT, ITAWA, PUDYE, TTATT, followed by IDEED for the missed approach. https://www.pilotsofamerica.com/community/threads/unique-way... Australia has WALTZ, INGMA, TILDA, and also WONSA, JOLLY, SWAGY, CAMBS, BUIYA, BYLLA, BONGS https://www.cntraveler.com/stories/2015-06-02/a-pilot-explai... Disney has a whole lot of special fixes in Or…

My favourite in the USA, which I'll never forget, is outside Washington Dulles: NEVVR just next to FORGT.

Re: UK air traffic control meltdown

#438

Post by moritzwarhier »

codeulike wrote: post #385
moritzwarhier wrote: post #285

Earlier quoted context omitted.

Sounds like a helpful idea with considerable implementation complexity, including the potential for new disastrous failure modes.

But its how the waypoint codes work in practice - they are contextual. If Air Traffic Control tell a plane to head for waypoint RESIA, they mean the one nearby, not the one 4000 km away.

Have to admit, I read the article in full detail only after commenting and I see your point.

Especially since the implenting company is called out explicitly for failing to achieve this, and the risks of changing the well-established identifiers are also illustrated.

Perfect might be the enemy of the good then, or the standardization thing at least is a separate topic.

Re: UK air traffic control meltdown

#439

Post by touisteur »

cratermoon wrote: post #430
touisteur wrote: post #370

Earlier quoted context omitted.

From a safety-critical standpoint, I've always found this article interesting but strange. You want both, before taking into account any data from anything outside of the system. Do both. As soon as possible. Don't propagate data you haven't validated in any way your spec says so. If you have more stringent specs than any standard you're using, be explicit about it, reject the data with a clear failure report. Check…

> It's not that hard, compared to many other proof and safety/security endeavours. Yes, but the code has to understand and model the input into a program representation : the AST. That's the essence of the "parse, don't validate" paradigm. Instead of looking at each piece of a blob of data in isolation to determine if it's a valid value, turn the input into a type-rich representation in the problem domain. In the cas…

One of the reasons developers 'let it crash' is because no one wants to pay for error recovery, and I mean the whole design (including system level), testing, and long-term maintenance of barely used code.

THAT SAID isolation of the decoding code and data structures, having a way back to either checkpoint/restore or wipe out bad state (or, proving the absence of side effects, as SPARK dataflow contracts allow, for example) is better design, I wish would be taught more often. I really dislike how often exception propagation is taught without showing the handling of side effects...

Re: UK air traffic control meltdown

#440

Post by crabbone »

samus wrote: post #435
crabbone wrote: post #419

Earlier quoted context omitted.

Sorry, you missed the point. If programmer didn't know that repetitions are allowed, they wouldn't appear in the input to the fuzzer as well. The mistake is too trivial to attribute it to the programmer incompetence / lack of attention. I'd bet my lunch it was because the spec is written in an incomprehensible language, is all over the place in a thousand pages PDF, and the particular aspect of repetition isn't cover…

> If programmer didn't know that repetitions are allowed, they wouldn't appear in the input to the fuzzer as well. It totally would. The point of a fuzzer is to test the system with every technically possible input, to avoid bias and blind spots in the programmer's thinking. Furthermore, assuming that no duplicates exist is a rather strong assumption that should always be questioned. Unless you know all about the bus…

No... that's not the point of fuzzing... You cannot write individual functions in such a way that they keep revalidating input handed to them. Because then, invariably, the validations will be different function to function, and once you have an error in your validation logic, you will have to track down all function that do this validation. So, functions have to make assumptions about input, if it doesn't come from an external source.

I.e. this function wasn't the one which did all the job -- it already knew that the input was valid because the function that provided the input already ensured validation happened.

It's pointless to deliberately send invalid input to a function that expects (for a good reason) that the input is valid -- you will create a ton of worthless noise instead of looking for actual problems.

> Furthermore, assuming that no duplicates exist is a rather strong assumption that should always be questioned.

How do you even come up with this? Do you write your code in such a way that any time it pulls a value from a dictionary, you iterate over the dictionary keys to make sure that they are unique?... There are plenty of things that are meant to be unique by design. The function in question wasn't meant to check if the points were unique. For all we know, the function might have been designed to take a map and the data was lost even before this function started processing it...

You really need to try doing what you suggest before suggesting it.

Post reply on HN