101–110 of 311 posts
Is nm the official abbreviation for nautical miles? I assume it is natural miles. For me it is nanometers.
FYI: nm = nautical miles, not nanometers.
From Sept 2023 (flightglobal.com):
- Comments: https://news.ycombinator.com/item?id=37430384
Also some more detailed analysis:
- https://jameshaydon.github.io/nats-fail/
- Comments: https://news.ycombinator.com/item?id=37461695
Earlier quoted context omitted.
> he system can't recover from an error in an individual flight plan, bringing the whole system down with it From the system's POV maybe this is the right way to resolve the problem. Could masking the failure by obscuring this flight's waypoint problem have resulted in a potentially conflicting flight not being tracked among other flights? If so, maybe it's truly urgent enough to bring down the system and force the h…
It seems fundamentally unreasonable for the flight processing system to entirely shut itself down just because it detected that one flight plan had corrupt data. Some degree of robustness should be expected from this system IMO.
I've worked on a (medical, not aviation) system where we tried as much as possible to recover from subsystem failures or at least gracefully reduce functionality until it was safe to shut everything down.
However, there were certain classes of failure where the safest course of action was to shut the entire system down immediately. This was generally the case where continuing to run could have made matters worse, putting patient safety at risk. I suspect that the designers of this system ran into the same problem.
Is nm the official abbreviation for nautical miles? I assume it is natural miles. For me it is nanometers.
https://www.ecfr.gov/current/title-14/chapter-I/subchapter-A...
Earlier quoted context omitted.
... 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 :)
Or even more straightforward, just don’t believe anyone 100% knows what they are doing until they exhaustively list every assumption they are making.
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…
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 make it disappear.
Keep the tickets open.
Anything else is supporting a lie.
Hmm, is this the same incident which happened last year? Or is this a new incident? From Sept 2023 (flightglobal.com): - https://archive.is/uiDvy - Comments: https://news.ycombinator.com/item?id=37430384 Also some more detailed analysis: - https://jameshaydon.github.io/nats-fail/ - Comments: https://news.ycombinator.com/item?id=37461695
> Investigators probing the serious UK air traffic control system failure in August last year [...]
FYI: nm = nautical miles, not nanometers.