3 ms·

Your argument against footgun avoidance is only applicable in narrow cases. In aviation, for example, there are quite a few footguns you can kill yourself with

Your argument against footgun avoidance is only applicable in narrow cases. In aviation, for example, there are quite a few footguns you can kill yourself with - and, which is very relevant to the issue in general, other people as well - and the practice is to mitigate them wherever feasible. We have stall warnings and stick pushers, ground proximity warnings and TCAS, ABS and interlocks to prevent doing things like engaging reverse thrust when the wheels are off the ground. Now, with software-controlled fly-by-wire systems, the ability to mitigate pilot footguns has been greatly expanded, and is being taken advantage of. Furthermore, these mitigations appeared first in high-performance military aviation, before fly-by-wire appeared in commercial aircraft. For a more specifically computer-systems example, perhaps we should consider security? - oh, wait...

bayindirh 5y ago
The analogy is not very accurate I may say, because in a flight, you prevent human footguns during flight, every day. However, a developer need to avoid that footgun once, and when the developer verifies the scenario with testing, this part of the code can be considered "sealed", never to be touched again unless a bug is found, or a serious need arises to enter that part of the code. Most security problems arise from memory management problems from my experience. This has nothing to do with POSIX. The problem is universal there, and we may delightfully argue that a stricter programming language like Rust can alleviate most problems, however tools like Valgrind can also find a lot of problems during a simple testing run. If we return to aviation, flight safety and memory management, there are some standards AFAIK which ponder about determinism and memory management on these systems (and smaller "single use" systems). These systems neither know POSIX, nor has the capacity to do so (they spend all their power to catch and tag the object they're tasked with). Again, the security, reliability and other footgun related stuff ends at the program we're designing and running, and not on POSIX itself.
- mannykannot 5y ago
  > However, a developer need to avoid that footgun once, and when the developer verifies the scenario with testing, this part of the code can be considered "sealed", never to be touched again unless a bug is found, or a serious need arises to enter that part of the code. This just does not hold up at all, in practice. It is not at all uncommon for footguns in software go undetected in testing, and lie in wait, like so many landmines, for someone to set them off - or for some blackhat to find them. > Most security problems arise from memory management problems from my experience. That does nothing to somehow compensate for, or otherwise render harmless, those that are not. More generally, by describing various ways you can seek to avoid footguns, you are simply providing evidence that they are a problem, not a feature.

bayindirh 5y ago

The analogy is not very accurate I may say, because in a flight, you prevent human footguns during flight, every day. However, a developer need to avoid that footgun once, and when the developer verifies the scenario with testing, this part of the code can be considered "sealed", never to be touched again unless a bug is found, or a serious need arises to enter that part of the code. Most security problems arise from memory management problems from my experience. This has nothing to do with POSIX. The problem is universal there, and we may delightfully argue that a stricter programming language like Rust can alleviate most problems, however tools like Valgrind can also find a lot of problems during a simple testing run. If we return to aviation, flight safety and memory management, there are some standards AFAIK which ponder about determinism and memory management on these systems (and smaller "single use" systems). These systems neither know POSIX, nor has the capacity to do so (they spend all their power to catch and tag the object they're tasked with). Again, the security, reliability and other footgun related stuff ends at the program we're designing and running, and not on POSIX itself.

mannykannot 5y ago
> However, a developer need to avoid that footgun once, and when the developer verifies the scenario with testing, this part of the code can be considered "sealed", never to be touched again unless a bug is found, or a serious need arises to enter that part of the code. This just does not hold up at all, in practice. It is not at all uncommon for footguns in software go undetected in testing, and lie in wait, like so many landmines, for someone to set them off - or for some blackhat to find them. > Most security problems arise from memory management problems from my experience. That does nothing to somehow compensate for, or otherwise render harmless, those that are not. More generally, by describing various ways you can seek to avoid footguns, you are simply providing evidence that they are a problem, not a feature.