2 ms·

It's not "one item being out of order" though - it's "the system cannot verify this flight plan as being correct". Stopping in the face of being unable to veri

It's not "one item being out of order" though - it's "the system cannot verify this flight plan as being correct". Stopping in the face of being unable to verify that safety critical information is correct is a perfectly good choice, especially when the good consequences are fairly light like "some people are a bit late with their flights" and the bad consequences may be 10s or 100s of people dying.

krisoft 3y ago
> consequences are fairly light like "some people are a bit late with their flights" and the bad consequences may be 10s or 100s of people dying I think this might be the root of the misunderstanding between us. The consequences of an airplane not having a flight plan is not “10s or 100s of people dying”. The consequences of rejecting a flight plan are: - if caught on the ground:the one flight is delayed. They don’t take off until they manage to file a fligtplan the system accepts. - if caught at the airspace boundary when they arrive without a flight plan in the system there are two options: if ATC want to be hard-ass they will be refused entry and have to land at an alternate airport. If ATC is acomodating they will be asked at every new controller “<flightnumber> state your intentions”. Either way the system is fine and dandy. This is not what keeps airplanes from coliding with each other or the ground. Obviously the first option, catching the problem on the ground, is better because it is not increasing the workload of the ATC personel. Here is the thing, you are talking about “the system cannot verify this flight plan as being correct". And you are right! It cannot. So it shouldn’t try. It should give up. On that flight plan. I totally agree with that. But there were lots of other flight plans it could and should have verified. Have you done web development? What would you think of a server where a single weird edge case request would stop the whole service for hours? Would you say it is well engineered?
- zimpenfish 3y ago
  > The consequences of an airplane not having a flight plan is not “10s or 100s of people dying” The consequence of not being able to route a flight through reasonably congested airspace safely may well be "10s or 100s of people dying". > when they arrive without a flight plan in the system They had a flight plan but the system could not verify that it had correct data. i.e. the system believe it had internal corruption and should shut down. > What would you think of a server where a single weird edge case request would stop the whole service for hours? What would you think of a service where internal checks suggested corruption and it kept on serving potential corrupt data to customers and writing it to databases? I would consider that a failure in extremis.
  - krisoft 3y ago
    > I would consider that a failure in extremis. And I would agree. So stop serving the potentially corrupted data to costumers. Mark it as potentially corrupt and let an operator handle that potentially corrupt data manually while the system keeps processing the the rest of the not corrupt data. Is this such a hard concept to understand? Because it feels like it is not getting through.

krisoft 3y ago

> consequences are fairly light like "some people are a bit late with their flights" and the bad consequences may be 10s or 100s of people dying I think this might be the root of the misunderstanding between us. The consequences of an airplane not having a flight plan is not “10s or 100s of people dying”. The consequences of rejecting a flight plan are: - if caught on the ground:the one flight is delayed. They don’t take off until they manage to file a fligtplan the system accepts. - if caught at the airspace boundary when they arrive without a flight plan in the system there are two options: if ATC want to be hard-ass they will be refused entry and have to land at an alternate airport. If ATC is acomodating they will be asked at every new controller “<flightnumber> state your intentions”. Either way the system is fine and dandy. This is not what keeps airplanes from coliding with each other or the ground. Obviously the first option, catching the problem on the ground, is better because it is not increasing the workload of the ATC personel. Here is the thing, you are talking about “the system cannot verify this flight plan as being correct". And you are right! It cannot. So it shouldn’t try. It should give up. On that flight plan. I totally agree with that. But there were lots of other flight plans it could and should have verified. Have you done web development? What would you think of a server where a single weird edge case request would stop the whole service for hours? Would you say it is well engineered?

zimpenfish 3y ago
> The consequences of an airplane not having a flight plan is not “10s or 100s of people dying” The consequence of not being able to route a flight through reasonably congested airspace safely may well be "10s or 100s of people dying". > when they arrive without a flight plan in the system They had a flight plan but the system could not verify that it had correct data. i.e. the system believe it had internal corruption and should shut down. > What would you think of a server where a single weird edge case request would stop the whole service for hours? What would you think of a service where internal checks suggested corruption and it kept on serving potential corrupt data to customers and writing it to databases? I would consider that a failure in extremis.
- krisoft 3y ago
  > I would consider that a failure in extremis. And I would agree. So stop serving the potentially corrupted data to costumers. Mark it as potentially corrupt and let an operator handle that potentially corrupt data manually while the system keeps processing the the rest of the not corrupt data. Is this such a hard concept to understand? Because it feels like it is not getting through.