Fair enough. My answer was mostly that it's far from the first time I see this "Why bother developing X, Y exists" argument, and it's rarely a good one. Alternatives drive innovation. Relying too much on a single solution can be dangerous.

Yes, but security requires near perfection to maintain its security guarantees. It is very difficult to have both perfection and diversity, as resources spread thin.

When you see that "argument" made in HN comments, I do not think it is for the reasons others in this thread are suggesting.

These commenters are potential or existing users of X, not the authors of X. The people writing X would never try to argue that people should not write Y.

As for the psychology that drives these sort of statements from HN commenters, that is left as an exercise for the reader. One theory is that some people do not like to make choices. They would rather be told what to do. Alternatives may mean choices must be made.

In this case, Snabb discloses that Vita was funded by NLnet. NLnet once wrote an alternative DNS library and various programs (nsd, drill, unbound, etc.) that I would bet many former BIND users are now happily using. OpenBSD made the switch years ago and NetBSD is making the transition as well.

I think these "Why not use X" comments are a sign of users who dislike decision-making and want to be told what to do. I would bet some commenter was asking "Why not use IPsec?" when Wireguard was being introduced.

Wireguard is of course very Linux-specific. As of today, I still cannot use it reliably on BSD. What that means is that in order to experiment with Wireguard, 3xblah's router has to run Linux not BSD, 3xblah's preferred router OS. I am not anti-Linux, but that choice, being made for me, is significant.

I interpret the configuration choices that GNU/Linux distributions make as being told what to do. With BSD, NetBSD for example, programs that interact with the network are generally off by default. It is up to the user to decide which ones to start. IME, this is different from the Linux distros where programs are pre-configured to start without any input from the user.

Alternatives that work on a variety of OS are helpful for some users.

I think the "Why bother..." questions come from users who cannot be bothered with decision-making. More alternatives may mean more decision-making.

The reaction of these users might be "Why bother developing..." in which case they are upset that now with the arrival of new software they feel there is a choice to be made, or it could be "Why should I switch to..." which signifies they want someone else to make the decision for them.

I can't really agree with you. I understand the premise, and I certainly agree that some users genuinely don't like choice. But I think a much more reasonable explanation of that attitude fits the following two points.

1. "Why not use [X]" is a perfectly valid question for gaining insight into the merits of new tech. If I have problems that I've solved with [X] and you're now implying that I should use [Y], I want to know what makes [Y] different or better than [X] in your opinion. I want to know what problems you're solving, so I can compare them to mine. I want to know what benefits you're getting that I may not have considered. That's a totally valid approach to understanding a new product.

2. Assuming you aren't solving new problems with [Y] and you're really just directly competing with [X] and I already use [X]... I may be inclined to think it's a waste of effort because I won't get any benefit from your work (I'm already using [X]!). Worse, you could have been making [X] better instead of just competing with [Y]!

Of the two, I think both play a role in the mindset of people making that argument. I'm not very sympathetic to the second, but the first is fine.

"... and you're now impying that I should use [Y]..."

You perceive someone is "implying that [you] should use" [Y].

It is as if you believe the mere publication of software is somehow didactic.

As if the author by the mere act of writing and sharing a program is telling you what to do.

If the question in 1. were phrased as something like "How does Y compare with X" then that is not what I am addressing.

I am addressing this idea that someone (who?) is "implying" that you should use Y. What if that was not actually the case and it was just your interpretation?

What if the authors are not telling you what software to use.

What if it was simply a case of a person or group writing some software, e.g., maybe to scratch their own itch, and then publishing it in case others may want to use it.

Keep in mind I am now referring to the general case, e.g., each program source published on Github, not Vita.

It would be interesting if users, without any financial contribution, could tell software authors what programs to write or refrain from writing, but that is not what I see when I look at the large amount of software published on the internet.

If the authors of Vita were getting paid to write it, then I doubt they would view it as "wasted effort".

Dude, you are so incredibly far off in strawman land right now I can't even...

you got stuck on the work imply and just couldn't come back.

Even assuming they're just sharing their work with the world entirely for generosity (and they're not, it's sitting in a company owned repo and the tag line is literally "Software Bureau. Hire us to work on code.")

Then yes, I'd still say espousing the merits of your product publicly is a pretty strong implication that I should use it. That's also why I expect you to have shared it.

Have you tried FreeBSD? I run wireguard on FreeBSD. Use it every day, rock solid.

I was not aware it runs well on FreeBSD. Have been using it on OpenWRT. Thanks for the tip!

Lots of vying alternatives results in development being spread out and no one single solution getting all the features and clean-up. Plus, "more" does not equal "better" when it comes to security development; not that many people can write secure apps well.

> nearly 6 times as many lines of code

SQLite has 711 times more lines of tests as it does of code.

Does that make it a worse software product?

No, but if it has more lines of code (not tests) than a competing product, then it is more complex, and has a higher probability of defects.

In security, defects have serious consequences, so it is in best interest of everyone to have the lowest possible complexity, much more so than for other types of software. The only "stricter" category would be software related to operation of equipment whose failure could cause direct physical harm.

Based on empirical observation, the number of bugs goes up with lines of code on average. There's also some point where something is too big for the human mind to understand in its entirety, either developer or reviewers. To say something is secure, you have to understand everything it will and won't do. Those analysis grow exponentially with size due to input/output ranges and combinations of paths (i.e. combinatorial explosion). So, smaller is better. Ideally, small like Wireguard so the most thorough analysis possible.

Lets look at your counter example. It's smaller than most databases as I advise. Following the other rule, it was untrustworthy by default with developers adding piles of tests to uncover bugs, increase confidence, and make changes with less breakage.. Nonetheless, CompSci papers I read on static analysis and fuzzing often test SQLite finding bugs. Even such a well-tested application still had plenty of bugs over time due to its complexity. Most of which might be just intrinsic to the kind of features they're developing.

Back to VPN's, you want to know it will maintain security policy (esp correct info flows) under all inputs in all states, normal and failure. And if no progress can be made, you want it to fail-safe. So, making it six times larger without a need to is definitely worse than not making it six times larger. The larger product will, based on empirical data like SQLite, have more bugs with more code injections or data leaks following from that. I advise minimal, careful, rigorously-evaluated implementation of a formally-verified protocol. Wireguard is closest to that right now.