I installed FreeBSD last night, you can just tick/untick these options during the install which addresses most of the article.

[ ] enable sendmail

[ ] enable sshd

[ ] enable ntp

[x] encrypt swap

Now what Linux, and to a lesser degree FreeBSD, can do is survive real world usage at scale. OpenBSD cannot. It would fall over or require magnitude more machine count to do the same workloads that people use Linux and FreeBSD to run. So all the exploit mitigation diatribe and "great defaults" and pet projects are cute but funny when you try and throw shade onto others with them. As I said, there are some kernels of truth that pertain less about security and more about overall health in FreeBSD this doc accidentally hits on, but running some hobby software like opensmtpd on openbsd isn't going to save the world from real cybersecurity issues.

As someone who has run web servers with both FreeBSD and OpenBSD, I think some of your criticism in this thread is valid, but you really crossed the line into blatant fanboyism with that one at the least.

LibreSSL isn’t really in widespread usage outside of OpenBSD and has still been vulnerable to some of recent the OpenSSL exploits.

OpenNTPD is more widely used but lots of people still go for other alternatives and frankly I’m not convinced OpenNTPD offers anything significant over the competition anyway.

pf is barely used outside of OpenBSD and frankly why should it be when Linux has iptables (which does the job well) and FreeBSD has ipfw (which also does the job well). pf is also a decent firewall but it’s also a crowded market with lots of really decent alternatives written by their respective platform hosts.

I do actually quite like OpenBSD though. But outside of OpenSSH, OpenBSD is slowly becoming less relevant to the wider industry as other platforms catch up on security and even over take in terms of enterprise features.

(Also, I’m missing what’s so “funny” and “hilarious” about it.)

Do you have a better synthetic benchmark to suggest?

And "speed" does depend on expectations. Compute tasks should be approximately equivalent, right? And os-limited tasks with many syscalls less so. You don't specifically state your expectations. Just that you are disappointed.

I've been quite negative in this thread because the overall debate on these topics is pretty frivolous. We already have the tools at our disposal to do magnitude greater secure software and splitting hairs over which BSD has better defaults is missing the forest for the trees.

Do you have a specific language in mind that offers improvement? Or am I reading too much into the sentence?

>We already have the tools at our disposal to do magnitude greater secure software

Mind sharing more details on the tools? Specifically with respect to System / OS Level programming.

syskaller is in use by the major BSDs and stricter compilers and other static analysis tools have been a far bigger impact IMHO than the OpenBSD style mitigations. I would like to actually see some kind of case studies where OpenBSD mitigations have protected a user where they'd have been let down by say Linux or FreeBSD or OpenBSD without them.

I think a less snake oil approach to security is done by the seL4 folks, the difference in approach makes the *nix security mitigation people somewhat cringe worthy.

Any language with memory and type safety should comprise as much as possible of the whole system. See the Singularity OS from Microsoft Research, or whatever that Rust OS project is called.

Almost all the major, nicknamed, headline-grabbing RCE bugs in the last two decades are memory or type safety issues in C or C++ code.

Every C or C++ developer claims safe code is possible or even easy in their favorite language, but history has proven them very wrong.

I found it interesting, anyway, but didn't come away with any inclination to use OpenBSD on my next deployment.

Maybe - and I'm only saying this because I care - there are a lot of decaffeinated brands on the market that are just as tasty as the real thing.

Maybe - and I'm only saying this because I care - you should consider through hiking and come back to the discussion when you are less easily offended by the facts at hand into low grade trolling and have requisite attention span and reading comprehension to participate meaningfully in the conversation.