91–100 of 189 posts
Earlier quoted context omitted.
Concurrency is hard. Thread unsafe operations that end up getting executed in multi-threaded contexts are a huge source of heisenbugs
Should have used Rust.
> Bret Peyton, Alaska’s on-duty director of operations, immediately ordered no more planes were to take off across the airline’s network. All Alaska flights not already airborne were stopped nationwide. An absolute pro. There's a hundred variations of this story, to varying degrees of criticality and impact; seeing a pattern out of two data points, connecting the dots, making the tremendous call to immediately pull t…
Curious about the actual bug: > the update to the DynamicSource software had been tested over an extended period, the bug was missed because it only presented when many aircraft at the same time were using the system > the data was on the order of 20,000 to 30,000 pounds light. With the total weight of those jets at 150,000 to 170,000 pounds, the error was enough to skew the engine thrust and speed settings. Multithr…
Could be something as simple as the first concurrency 101 example: atomic addition. The += operator behaves poorly on concurrent access.
If there are multiple data streams feeding in weight data per aircraft, under a low aircraft load (the scenarios they apparently tested) the odds of interruption during an operation like += can be low enough to not see the issue. Under high load, though, the odds of interruption and incorrect tallying increases substantially.
Curious about the actual bug: > the update to the DynamicSource software had been tested over an extended period, the bug was missed because it only presented when many aircraft at the same time were using the system > the data was on the order of 20,000 to 30,000 pounds light. With the total weight of those jets at 150,000 to 170,000 pounds, the error was enough to skew the engine thrust and speed settings. Multithr…
I'm surprised there wasn't any human or general guardrail around the calculation that would have flagged such a significant weight difference. No one looked at the passenger count and the weight calculation and thought "whoa, that doesn't look right?"
Actually there were such guardrails, so the system had multiple manual checks built in.
Earlier quoted context omitted.
That’s a feature of engineering. Figuring out what performance and safety requirements are and then optimizing the resources required to meet those requirements is what engineering is for. The influence of capitalism would be on the requirements. But assuming the requirements are well-considered trying to minimize fuel and engine usage to meet those requirements is a good thing.
I think this is pretty subjective. You could also say that engineering should be used to increase the margin of safety (what is often labeled over-engineering). If the engineering requirement is “do something that brings you close to the margin of safety in order to save resources”, is that not an influence of capitalism?
How to hit that line precisely and with confidence is where engineering takes over.
Earlier quoted context omitted.
Concurrency is hard. Thread unsafe operations that end up getting executed in multi-threaded contexts are a huge source of heisenbugs
I refuse to believe that summing up weights for each of 300 planes is so hard that it can't be made correct by a team of moderately competent developers operating under sane management. There might be some complexity, but it's 2023 and we have enough knowledge and tools to solve that kind of stuff routinely and reliably. Somebody fucked up big time and should be fired never to work in software again.
Earlier quoted context omitted.
That's still an architecture defect. Software's accuracy being affected by load is completely unacceptable.
Please let us know where these software magicians are that write perfect, bug-free code.
There's no such thing as perfect software, but there is definitely software that doesn't make up a false value if it can't work.
Earlier quoted context omitted.
>Interesting that someone cited divorce and sleep examples as emotional pleas , reassuring us they are only human. Huh? FAA spends a huge amount of time and energy focusing on human factors, tasks saturation rates and crew resource management. Nothing to do with with argumentum ad passiones, just prudent risk mitigation.
I thought a lot of safety thinking was built around acknowledging that humans don't do everything perfectly all the time.
But another class of mitigations is to make the human less error-prone in the first place. This is especially important in preventing failures that were caused by improper management of the automation. Hence the emphasis on rest periods, training, and other mitigations on the human side.
In the "swiss cheese" model, a disaster needs to slip through both the human's defenses and the automation's defenses to actually happen. It makes sense to improve both of those layers of defense against disaster, while acknowledging that humans will never be perfect. But at least they can be awake and knowledgable.