[fluffything]

There are trade-offs involved in choosing OpenBSD for a "Work"station, and the post covers some: lack of packages/no proper package manager (requires recompiling with patches from source), no Docker/VMs/VirtualBox/Wine, etc. Other are lack of drivers, etc. None of these issues are incompatible with an Operating System design (or not really), they mostly just need extra work.

However, the blog post mentions that "for them" performance isn't an issue. This should not be interpreted as performance being good. OpenBSD performance can only be described with data: https://www.phoronix.com/scan.php?page=article&item=8-linux-...

Even for something that the OpenBSD devs themselves are doing all the time, compiling stuff, OpenBSD is ~20x slower than Linux. 2x slower would be horrible. I really have no words to describe 20x slower performance. If you are a dev working with a compiled language, imagine a 20x perf hit on compile-times. Imagine having to patch LLVM/Clang on OpenBSD by recompiling it from source. "Apocalyptically horrible", "worst in class", do not even make justice for how slow OpenBSD is.

[vbezhenar]

> requires recompiling with patches from source

I don't think that's true. There's pkg_add and syspatch and those are preferred methods for upgrading your system. You can recompile things from source and I think that it's an awesome feature for hacker, who wants to tinker with sources of some package, but that's not the only way.

[fluffything]

Between distro releases, if you want to apply security patches, you need to recompile from source, because there are no binary releases.

[dpwm]

I'm not sure how much we can extrapolate from those benchmarks.

Despite the name, compilebench[0][1] seems to do a lot of non-compiling stuff. It appears to be more of a filesystem benchmark.

[0] https://openbenchmarking.org/test/pts/compilebench

[1] https://oss.oracle.com/~mason/compilebench/