Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I did read the article. I was responding to a post that highlighted the human factors in the conflict.

If the UI was simple, the landing scheduling would be handled automatically. If the plane had too little fuel, the planning failed. Keeping a schedule isn't difficult, human interaction and ill-defined schedules makes things difficult.

I am aware that a central african state isn't exactly the cornerstone of air tech, but good schedules can still be negotiated and kept.

It's like the air france crash where the pilot stalled the plane because of lack of feedback. UI/skill problem.



My argument is that improved UI doesn't appear to be the source for major improvements in reducing the number of drone crashes. While a simple UI might handle some engine failures, it can't handle all hardware failures.

The landing scheduling depends on the local air traffic controllers, which aren't under US direction and can't be solved with an improved UI. The planning problem might be that the local ATC doesn't care for the US military traffic in the area, and this is a form of passive protest. If so - and that is a pure hypothetical as the article doesn't go into those details - then the planning problem is at the high-level political level, and perhaps extending to how the world perception of how the US is dealing with the GWOT. That's extremely far from UI issues.

As minor points, neither Djibouti nor the Seychelles are a central African state. Also, the initial problem with AF 447 was inconsistent airspeed inputs from the pitots, causing the autopilot to disengage. I don't think it's useful to attribute the problem only to "lack of feedback." Yes, there's a "skill problem", but if you continue the analysis chain then there's a training problem, and if you go further then there was an incomplete understanding of the risk model.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: