I tend to look at OpenBSD as a sort of "security incubator" program, where good security ideas and practices have the chance to grow. I think that the biggest impact of OpenBSD tends to be felt in OTHER operating systems and on the internet at large.
One of the big areas where OpenBSD has pushed things forward, in my opinion, is defense-in-depth for software. They put a lot of effort into maintaining high coding standards and an emphasis on correctness. They've been active in the area of exploit prevention and detection-- they were the first to really do W^X, they've been using ProPolice by default since forever, they randomize memory addresses, etc. But they're also very active in exploit mitigation-- that is, if we start by assuming that a program IS going to have a security bug, how do we limit the damage? OpenBSD has invented or popularized techniques like privilege separation, their "pledge" and "reveal" systems, and various other forms of sandboxing.
There's also the crypt side-- their work on cleaning up OpenSSL to create LibreSSL has been an incredible service. OpenSSH has been adopted EVERYWHERE. Their work has done a LOT to reduce the amount of unencrypted traffic going across the internet generally.
Depends on what you're doing with it -- but the base system ships with many things that you would want to use, and it's definitely concievable that you'd only run with OpenBSD software.
Web servers? OpenHTTPd. Mail wervers? OpenSMTPd. Proxies? Relayd Firewalls? pf Routing? Depends on what you need, but there's probably a daemon for that.
You can get a lot done without relying on ports. (Also, the ports are somewhat vetted, as far as I can tell.)
[0] https://undeadly.org/cgi?action=article&sid=20160107075227
I think it's comparable in terms of features, and many of those features even originated or have canonical implementations that started under the umbrella of OpenBSD. Also some of the most sane defaults, and simple install process, of any OS I've ever used.
I think where OpenBSD really shines though is the documentation. Most issues I run into can be solved by reading the man pages included with the default install.
Also the video linked by q3k elsewhere in this thread is a great watch.
For a long time OpenBSD was focussed on security through correctness and code review, so that portion is not necessarily reflected in any of the grsecurity/pax type hardened linuxes.
But OpenBSD does have things like ASLR and kernel address randomization, advanced memory protection (W^X etc) and while it doesn't have ACLs or PAM it has pledge which is a great way of restricting system call access at the program level.
Since they keep userspace stable, they generally have more stable programs running there as well.
For instance, systemd has has multiple remote exploits in a time window when the default OpenBSD base install has had zero.
Moving up the stack, OpenBSD often rewrites or simplifies important daemons (like httpd), and those tend to have closed or mitigated security holes before upstream exploits are discovered.
OpenBSD focuses on securing things at the source level. Hence all the compiler tricks to mitigate memory safety bugs, API for programmers to limit syscall exposure, privilege separation within individual programs, drive to avoid unnecessary complexity so the source is readable etc.
If I personally put my own opinion on it, I don't like unnecessary use of containers because the model gives you a lot of outdated dependencies, and I'm not sure whether containing a vulnerability once it happens is that noteworthy.
Old skool "use good, secure code. update dependencies" and not focusing on containing a vulnerability produces a much safer system IMO.
I don't know why people ride motorcycles, skateboards, or school buses when trains already exist. This is not one organization, these are different groups all trying to accomplish different goals.
>why anybody would run BSD over Linux.
We have our reasons. You have already quoted very valid reasons, the fact that you disregard them speaks more about yourself then the motivating factors of others. You have been given technical arguments, political arguments, and real-world examples of why others think that the BSD groups prefer their OS of choice.
You have already made up your mind that BSD is inferior.
imagine how much success windows + mac would have if they were as scattered and opinionated as the linux community
OpenBSD in particular is an attractive option for some servers, since it has builtin httpd, acme-client (for tls certs), smtpd and excellent documentation of how to get it all up and running with minimal, secure configuration.
While people have a tendency to believe that there is "only one True Way", and it is a popular argument that "X is most popular, therefore it is The True Way." – this is not in fact true for operating systems. Every system will have its drawbacks, and…
Regarding a): Everyone working on one thing does not optimise the quality of the outcome. A rich flora of operating systems encourages experimentation, trying out different compromises and learning from each other’s experience.
it is an attractive option that is less attractive than Linux because it is less popular and has less support
that all accomplish the same thing, with worse polish + support than larger, more successful projects who don't spend time building on top of "slightly different variations" of the same thing
it's undeniable that linux has 10x the support of OpenBSD, and mac has 2x-5x the support for linux in terms of "actually getting stuff done", not tinkering with command files endlessly for no reason
even the "linux is good for infrastructure" excuse is starting to fade away as more and more things get abstracted away with k8s, docker, cloud-config, etc.
yes, by all means, they run linux. they don't (on average) run BSD. anything that runs BSD could in theory run linux and probably be ok overall. linux is not "worse" than BSD at any one thing and is better in terms of community support, performance, etc.
Linux distros however are still moving targets and there's no common stack apart from the kernel which is predictable to test against. This is why its hard for some maintainers to reproduce an issue a user has due to possibly apt-get, rpm, install package or use snap, flatpak or appimage and the app starts to break.
Not a problem for CLI apps, but a problem for testing desktop apps on Linux. Perhaps you want your favourite app being fully supported and tested on your Linux distro of choice. If I know my app works and is tested on Linux distro A,B,C,etc I can confidently target a wider range of Linux users. At least that's how I increase my "Linux userbase".
The fragmentation on this however is another story.