So you don't like OpenBSD, but you do like Ubuntu?
This person seems like they know wht they are talking about and given it serious thought, but I cannot fathom how you could make such a conclusion today.
If they're concerned about performance, yeah. OpenBSD doesn't do the basics that you need to get the most out of your SMP hardware; there's no way to set cpu affinity at least from userland, and it's clear that this sort of work is not a priority for OpenBSD; it's not easy work, but FreeBSD has done it. Beyond CPU affinity, you also need your network structures setup to reduce lock contention, things like fine grained locks, hashed subtables and/or "lockless" tables, configuring the NICs as close as possible to one queue per core and keeping flows on the same queue which is pinned to a single core so that the per flow locks never contend and don't bounce between cores.
Ubuntu/Linux do have reasonable performance, but I think they prefer PF firewalls, so that makes Linux a non-option for firewalls.
Personally, I don't really care for PF, but it offers pfsync, which I do care for, so I use it and ipfw... but I need to check in, I think FreeBSD PF may have added the hooks I use ipfw for (bandwidth limits/shaping/queue discipline).
It's not necessarily that OpenBSD can't implement the basics, it's that they don't want to. A lot of the high-performance features introduce potential security vulnerabilities. Their main focus is security and correctness. Not speed.
The gp already answered you, "this sort of work is not a priority for OpenBSD."
OpenBSD is a small, niche operating system, and it really only gets support for something if it solves a problem for someone who writes OpenBSD code. In a way, this is nice, because you never get half-assed features that kinda-sorta work sometimes, maybe. Everything either works exactly as you'd expect, or it's just not there.
I love OpenBSD, but there are some tasks it's just not suited for, and that's fine, too.
I was pretty sure I had seen a mailing list post from Theo about it, but I can't find it now. The only relevant thread I can find is this one [1], which pretty much just says "we don't do it for userland"; but does say it is available inside the kernel, and I have seen some mentions in recent release notes for OpenBSD of binding PF things by toeplitz hash, which indicates the right progression for that ... but it's still hard to get max performance from a simple network daemon without binding the userland threads to same core that the kernel processes the flow with. Once your daemon starts doing substantial work, binding cpus isn't as important, but if it's something like an authoritative DNS server or HAProxy with plain sockets, the performance benefit from eliminating cross-core communication can be tremendous.
It appears they have different requirements for those machines. They state the Ubuntu machines are for non-firewall applications. Ubuntu and Debian can configured relatively easily for a number of workstation and server roles.
Also many IT professionals that have used Linux will be familiar with a Debian or a Debian derivative such as Ubuntu. That simply isn't the case with OpenBSD.
I recently installed OpenBSD on my old laptop to try it out and I found it difficult even though I used to use it at University back in the late 2000s.
Amusingly, I started using OpenBSD in 2000 because after repeatedly trying to get Debian running on my PowerPC G4 and failing (for months), I discovered that OpenBSD had a PowerPC port that immediately worked. Honestly the hardest part about OpenBSD is the installer, which has a few small improvements over the one back in 2000, but is essentially the same. I'm sure that kids these days will turn to ChatGPT for help, but I learned most of what I knew about hacking on a UNIX machine from OpenBSD's amazingly good man pages; they are still great.
I went through the process again just this weekend, because the disk in my firewall died. It's obvious that they continue to put a lot of effort into the OS. It's too bad that I can't use it as my daily driver, because I gladly would.
Their ports to older non-x86 stuff does work well but I can't justify using it as a desktop OS. Too many compromises you have to make without a lot of benefit IME.
I find with the BSDs is that it is difficult to look up how to do something quick via a web search. Yes that is a man page that will tell you how to use whatever, but knowing where you are supposed to look to solve "why doesn't two button scroll work" isn't immediately obvious.
I was mucking around with FreeBSD on my old laptop and it works well and it isn't too bad to get stuff going if you are following the handbook, there is still that "how do I get <thing> working". I think the OS is good underneath, but I kinda want two finger scrolling to kinda work when I install cinnamon and X.
Debian is at the stage now of install, you have desktop and most stuff just works at least on a x86-64 system. If I want to install anything, it is download deb / flatpak and I am done.
> BSD documentation is great because it the systems change so little you don't find twenty out of date references on how to configure your DHCP client.
While there are a out of date tutorials in Linux land, at least I can find out how I might do something and then I can figure things out from there. I do know how to use the man page system, however simply knowing what to look for is the biggest challenge.
e.g I was trying to configure two finger scrolling. The freebsd wiki itself appeared out of date. So it looks like you use libinput X driver package (which I forgot the name of now) and do some config in X. It would be nice if this was covered in the handbook as I think a lot of people would like two finger scrolling working on their laptops.
> But as a desktop OS, yes they lack in a lot of areas, mainly hardware support/laptop support.
Actually FreeBSD appears quite well hardware wise at least on some of the hardware I have. My laptops are all boring corp business refurbs that I know work well with Linux/BSDs.
The problem is that often I require using software which does not work on FreeBSD/OpenBSD or is difficult to configure.
The other issue is that there are things that appear to be broken for quite a while that are in pkgs (at least with FreeBSD) so trying to configure a VM with a desktop resolution over something relatively low isn't possible at least with Qemu.
It's actually pretty shocking how poorly and sluggish OpenBSD performs, and it's not meaningfully more secure than a properly-configured Linux or freebsd box.
I'm honestly not sure what its use case is in 2025, beyond as a research OS.
> Why are OpenBSD people always so rude and defensive? Sheesh
Because there is a limited amount of maintainers and a clearly stated goal/direction. There are also a lot of people requesting features that don't actually contribute to the goal or don't even use OpenBSD. It is a way to manage resources.
There is also the sentiment "if you need it you implement and maintain it" hence if someone is requesting without any investment it doesn't seem like they are serious.
There seem to be one group of people that seem to take offence by people being hyperbolic (which this is) and another group of people that aren't. I personally find it baffling why anyone would be bothered by that comment.
This person seems like they know wht they are talking about and given it serious thought, but I cannot fathom how you could make such a conclusion today.