This stands in clear contrast to OpenVPN, which attempts to manage all aspects of the VPN management process from endpoint config (interfaces, routes, etc) to key dissemination (strongly preferring mutual TLS auth and specifying a format for importable VPN configs). As a result, we could say that OpenVPN "Does Everything And Does It Okay," which I'd like to coin as the opposite philosophy. This has advantages if you have some kind of complicated situation and want to keep everything inside of one tool, but the result is that OpenVPN is more complicated to use and configure, and has more surface area to attack.
To some extent this kind of limited scope comes off as opinionated but I would like to view it the opposite way: Wireguard is unopinionated in that it leaves a large portion of the VPN stack for you to handle yourself, either manually or by bringing your own tool. This is a bit annoying if you're looking for a turnkey solution, but also makes Wireguard very simple and easy to understand and audit.
There is indeed such a philosophy:
It's normal and expected evolution of protocols and software.
Generation 1: New idea, new implementation. As people become comfortable with the new idea it gains in acceptance and hype. Try to keep it simple and fast, but it's a exercise in exploration and it gains technical debt faster then it gains new features.
Generation 2: Widespread acceptance and commercialization. Groups inside large corporations, and sometimes entire businesses, spring up around the new idea. They re-implement the idea to reduce technical debt and add flexibility. Features are piled on to make it marketable. Eventually becomes heavy and unwieldy.
Generation 3: Hype train dies down and people have learned what really matters and what really should be focused on. Third generation is lean, fast, and 'correct'. It becomes ubiquitous, people stop caring about it and people stop paying for it. It becomes just something that is always there and ends up little more then a building block for the next new idea.
Stage 1: Raw Iron Stage 2: Checklist Battles Stage 3: Productivity Wars Stage 4: Transparency
That said, OpenBSD's OpenIKEd is just as simple and efficient, and thanks to standard compliance (IPsec, IKEv2 and MOBIKE) it works out of the box with iOS devices.
It will be interesting to see what happens when (or if) large enterprises and hardware vendors adopt it.
Definitely programming languages are on the periphery of this conversation, but I think provide some good examples of why I like opinionated tools in general.
My language of choice right now is Go, and has been for a while. One of the things I like about it is that it's a bit opinionated. For example:
Braces around `if` statements aren't optional. I prefer this to other C-Like languages that allow you to leave out braces for one-liners.
Also the document "Effective Go" exists, which lays out the canonical "best" ways of doing a lot of things. The language doesn't force you to do these things, but there is an authoritative source that makes good suggestions.
The Antithesis of opinionated languages in my opinion is Ruby. I personally hate Ruby, but I know there are a lot of people that love it. I hate it because there are too many ways to of accomplishing the same tax, and to me this makes it harder to read. Go, on the other hand is the easiest language for me to read, largely because of `gofmt`, another thing that doesn't force you to do it a certain way, but strongly encourages a standard end result.
I've frequently described Go as a very, very good 1990s language. Going through the process of maturity takes time. You can't have a "very, very good" 2020s language right now, because at the frontier we're still feeling our way through the issues.
(Remember, whatever you're about to hit reply with and try to contradict me about it being a totally smooth and polished 2020s language that's already here is also an assertion that your example basically has no room for improvement and will not improve in the next 10-20 years. Consider your options carefully before you go too "language partisan" here.)
I believe probably >75% of the hatred Go engenders is from people afraid that Go's success will erase or invalidate the 2010s/2020s languages they prefer, because otherwise, the solution to most of these people's hate/anxiety would be to just ignore Go. To which I can say to those people, you can stop worrying. It won't. And if you stay in the industry long enough, maybe someday you'll get to use the really good and polished 2010s or 2020s language. No idea what it'll be called. And you can similarly assuage the fears of the day that this new language will erase all the benefits of the 2040s languages in development at the time.
But for "opinionated" to really work, I think you intrinsically need to have years of experience to make the right calls. There's no realistic chance that we could have gone straight to the "correct" VPN choice in one shot. Too many variables, too many dimensions, too much to learn and know about the security. It's just not possible. We collectively need the decades.
Programming language flamewars are a special case and not in a good way. Many of us lived through seeing those take over online communities in the past and reduce them to scorched earth. That's one of our motivations for wanting to keep HN from that fate, or at least stave it off a bit longer: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Actually your comment could be a good contribution with a little editing. The first link seems good. The second is too flamey.
I've done a fair amount with Elm, which is undoubtedly hugely opinionated, doing things like locking JavaScript interop behind a message passing system and baking protection from XSS into the language.
Mostly I'd say this all encourages you to do things a better way, but it can be painful, and particularly given the early nature of the language, meeting the edges of the language can be very painful because of it.
In contrast, I adored working with Scala because it was so powerful, but it sits close to Ruby in the "you can do everything a million different ways" rankings. The more I did with it, the more I wanted a refined subset of what was there (which may be what Dotty/Scala 3 ends up being).
Things like "you must always use braces on if statements" are rules I always end up enforcing using tooling anyway because they are just bugs waiting to happen, and are the low-hanging fruit of this debate. Too many language take the approach of "if we can parse it, it's fine", when really the aim should be to make it clear not just to a parser, but to the person reading/writing the code too. Hopefully more languages are more opinionated about that kind of thing in the future.
It can be. In fact it's almost essential if you are handing out knives to children; you want someone doing who is very opinionated about the dangers posed by sharp knives.
There was a recent HN post making the same point about JWT's. JWT's allow the null cipher, and in the hands of people who might not appreciate the disaster caused production code accepting JWT's using the null cipher you want a _very_ opinionated implementation that prevents it.
But for me, such an implementation would be a total pain in the arse. The null cipher is there to make debugging easier - getting things working for the first time can be very difficult without it. You can stick your opinions on whether I should be using it where the sun don't shine.
With a security product, however, I can understand the allure of offering few to no options. Laypeople get security wrong at an alarming rate, even with good defaults, so I often don't mind a security product just offering one configuration that the (presumable) security experts who built it have decided is the right way to use it.
Of course, if they turn out to be wrong about something, and a mitigation would be "disable feature X", then this requires a patch and new release, when it might have otherwise just required a configuration change.
In the Information Age, attention and cognitive bandwidth have become precious and limited commodities that should never be wasted on any unnecessary concern.
I have a rule of thumb in relation to product or project adoption: every installation step cuts adoption in half. If 1000 people find a project and it has a 5 step installation, approximately 32 of them will install it. Make it a 7 step installation and that number is cut down to about 8.
[0] https://en.wikipedia.org/wiki/Unix_philosophy#Program_Design...
There are some cases where opinionated is just fundamentally better. I'd say that a good example of this is code formatting tools. These have been historically highly configurable, but that creates huge amounts of room for bikeshedding and conflict, where consistency is by far the most important thing and the actual style itself barely matters unless you start getting silly.
I think it essentially becomes a sliding scale on how much consistency and "getting it right" are more important over having something be optimal or perfectly adapted to the situation.
When it comes to security tools like VPNs, reducing the chances for users to shoot themselves in the foot is almost always more important than anything else, so it seems like another area that would be beneficial to have something more opinionated rather than more configurable, so the decisions are in the hands of people who have invested the time in understanding the problems at hand.
The main problem I have with highly configurable utils is that a lot of them don't have sane defaults (or any defaults), which might be ok considering most users want-to or enjoy spending hours writing custom config, but it's a big ask for things I want to use quickly, or just try.
So, imo it depends on the software.
Opinionated isn't the right phrase here. For something like webdev there are 200 "right" ways to do things. For encryption "throw out all the legacy crap and focus on 1 known strong tech" isn't opinionated...it's common sense.
...if you have the luxury of a fresh start. Which mainline kernel has granted wireguard.
Monoculture...maybe...but I reckon the tons of legacy stuff in openvpn is way more dangerous. Especially because it kind forces mass adoption of weaker cyphers due to compatability BS.
For cryptographic (and related) applications, it certainly seems standard engineering advice now to reduce choices and configurations to a minimum [1] (but apparently not 2 decades ago, when OpenSSL, OpenVPN, and GPG were initially released).
[1] pretty sure Bruce Schneider et al. recommended it in their 2010 book Cryptography Engineering.
Until you run into the limits, of course. If you control both sides, you can use what you want, but as soon as you implement just one side ...
OpenPGP is an example of a case where relatively extreme backwards compatibility is required as old archived messages have to be accessible. But that isn't a problem because things are such that downgrade attacks are impossible. The list of desired methods is in the public key which is signed with itself. So downgrades are not always an issue.
Note that I am only claiming that downgrade attacks are technically impossible for OpenPGP due to the way that it works. To break the protection against downgrades means that you have to break the root cryptography. That might not be true for other stuff... Makes for a great example though...
We introduce wireguard2, which is not wire-protocol-compatible with original wireguard. The same configuration files can be used, but you must generate new keys as part of your switch over.
We strongly advise you to stop using original wireguard if there is any possibility of a wealthy, organized, determined attacker intercepting your communications. (See CVE2021-x. and forthcoming paper "64 qubits can deduce Curve25519 points" by D.J. Bernstein et al.)
None of this is complicated. It's also worth looking back on the history of TLS vulnerabilities to get a sense of just how little ciphersuite negotiation helped anybody.
or at least you might want different keys anyway
Wireguard is not opinionated, it just has a very limited scope. It has one job, to create an encrypted tunnel between two endpoints, and leaves literally everything else up to other tools to build higher-level functionality upon. Contrast with OpenVPN which requires you to be your own TLS certificate authority and all the complication that goes along with that.
I see it more as "convention over configuration". If you want to (or need to) tweak the configuration and settings extensively, then that tool is perhaps not for you, and that's ok. Perhaps you are a subject matter expert, and you want more control.
If you're ok with sane defaults (that were chosen by subject matter experts, and you are not one), then "opinionated" is a great thing.
Whether it impacts a specific use case is usually here nor there - it’s usually about maintainability. And while finding contributors for open source projects can be difficult, finding people who want to do the thankless work of maintaining code long-term is much harder.
That's one way of looking at it. Another way of looking at it is to emphasize minimalism, the UNIX philosophy, and keeping maintenance burdens low. Sometimes, neither is the case - Ruby on Rails being the classic example of an opinionated framework, one that did expand to add additional functionality over time.
After using WireGuard for 5 minutes I knew this was going to be a big thing.
IPsec has too many fucking knobs. It is it’s pitfall.
I wonder if any specification group has ever thrown up their hands and said, “you know what? Fine. Let’s just create one named sub-protocol for the way each of you major players does things; and then have the clients of this protocol do a sub-protocol negotiation; and then have the client use a plugin specific to the sub-protocol that’s been negotiated. Then you don’t need any knobs; all the policy can be baked into the plugin.”
(Come to think of it, this is kind of how the authentication phase of SSH works, when configured to use PAM. “Pretend we’re MIT” (a.k.a. Kerberos); “pretend this is a Microsoft Active Directory domain” (a.k.a. NTLM auth); etc.
Could this be a positive change? Does this represent a healthy response cognitive fatigue in a world with configuration options at every possible layer?
Or does this shift to less readily configurable tools represent an overall negative? Are we losing diversity in favor of a more vulnerable monoculture crop?
Or both?
Asking for real, not sarcastically. As a developer I’m a huge proponent of simpler, more opinionated frameworks for most projects but I’m also aware my perspective is more limited than many HN commenters.