Hacker News Reader

Comment by bayindirh | Hacker News Reader

> Do I need to say anything more?

No. Let me re-iterate what I mean.

Systems without guardrails are explicit, transparent and flexible. It's easy to understand how they behave. It might be a little harder to get things right, but when you get it right, there's nothing to second guess.

Systems without guardrails are low in overhead. It's possible to get raw performance.

Yes, I love these systems. I might spend a little more time and need a little more concentration when I develop stuff on these systems, but when it runs, it runs for good.

Trying to make systems foolproof by limiting them is not good. If that's good, we should all love iOS, right?

View on HN

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...

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.

> 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.

This is a C vs Java argument. There are people who prefer each.

> when you get it right, there's nothing to second guess

Given the topic is "how to corrupt your db file," does that mean they didn't get it right yet? Or that the underlying platform prevents them from getting it right?

> This is a C vs Java argument. There are people who prefer each.

As a person who've developed sizeable projects with both, you hit the nail on the head (and yes, Java can do amazing things in the foot gun department, believe me). However, my favorite language duo is C/C++ at the end of the day.

> Given the topic is "how to corrupt your db file," does that mean they didn't get it right yet?

This means you (as the developer) has a misunderstanding between you and the system. The article contains a very large swath of problems from hard to understand implementations (e.g. locks), to hardware which doesn't listen you to bugs in SQLite itself.

So, in the article there are a lot of cross-platform bad practices which one's warned about. Shrinking this to "POSIX is bad!" is just wrong. This is what I'm trying to point out.

Reply on news.ycombinator.com