Some things I like about FreeBSD are its comprehensive documentation and its slow-but-steady pace of development. I find that it tends to have fewer features, but they are more solidly designed and less likely to change several times over a decade. Compare with Linux's rapid evolutions through hardware events frameworks (devfsd, hotplug, udev) or audio (alsa, oss, pulse) or systemd's ever-growing reach.
I feel I can keep up with FreeBSD, and have confidence that it won't change too much out from under me when I'm not looking.
That being said, it's not that different from a more stability-focused Linux distro like Debian.
phoronix is notoriously bad in benchmarks of BSD family.
I don't know much about Net/Open/Drgonfly, but FreeBSD has very conservative settings by default, and Pgoronix never change defaults. FreeBSD can be tuned to be much faster for almost any Phoronix benchmark.
It is complex topic. I'm using FreeBSD at server environment (you are right that Wifi and GPU support of FreeBSD is lagging, so I'm not using it on desktops/laptops).
As server, FreeBSD needs increasing all socket buffers via sysctls, tuning NIC IRQ moderation (depends on NIC, but we are not discussing Realtek ones here, am I right?), and, in the past, VFS caching and read-ahead was very conservative by default, but now ZFS is the same as on Linux (unfortunately, as some non-tunable Linux-induced optimizations slightly hurt performance on BSD, best ZFS performance were before switch to OpenZFS).
For example, "stock" FreeBSD 13 on my hand-built NAS (5x8Tb zraid, system on SSD, E3-1220v3, 32GB RAM, Intel 10G NIC) only can serve ~250MB/s over SMB (with same Samba as Linux uses, of course), and after tuning (socket buffers, NIC IRQ coalescing, etc) it serves 750-800MB/s from cache and 500MB/s from spinning rust (which is obvious limitation of HDDs, not OS).
Unfortunately, I don't know one coherent and modern FreeBSD performance tuning guides, but this guide [1] is mostly actual still, for network part.
And optimizations for database (MySQL, PostgreSQL) tests are other can of worms, which includes tuning of recordsize of ZFS, ZFS ARC/ARC2L tuning, etc., I'm not qualified to advice here, as I'm using FreeBSD on network devices (gateways, firewalls, VPN endpoints) and storage boxes mostly.
It is not all about benchmarks. Benchmarks are just statistics. You know what Benjamin D'Israeli said about statistics, right?
"There are three kinds of lies: lies, damned lies, and statistics."
There are more important things than raw performance numbers.
How stable is the OS? That means over years, not hours.
Note: benchmarks tell you nothing about this.
How much maintenance does it take? That means both steps, and patches. How much work must you do? How long will it take? How much intervention? Can you automate it? How many updates must you install? How often? How big are they? How much bandwidth will they take? Can they be 100% trusted not to break anything ever?
Note: benchmarks tell you nothing about this.
How good is the driver support? That means both: How many drivers are there, and how good are the drivers? E.g. FreeBSD has many wifi drivers but they don't support the full speed of modern Wifi chipsets. That is why wifibox exists.
Note: benchmarks tell you nothing about this.
If the OS is rock solid and updates are small, easy, reliable and infrequent, and the drivers are comprehensive, that's all good. But then you must ask if it does what you need it to do?
Does it run one app you must have? If not, does it have a replacement that is just as good in every way?
Note: benchmarks tell you nothing about this.
If it has the app you need, does it have the version you need?
If it doesn't, is there an external source or a compatibility layer you could use?
Note: benchmarks tell you nothing about this.
If there is an external source, is it worth the work? Will it reduce stability? Will it make the updates more complicated?
AGAIN, benchmarks tell you nothing about this.
But benchmarks are easy, which is why people do them and publish them, because they look good and give replicable objective evidence, and we all need that.
But they are only part of the story.
Let us ask a question combining these things I have listed:
BSD will do all I need so long as I run the Linux compiler for $NEWLANG that I need for my project under the Linuxulator.
However, that only works with FreeBSD, so now NetBSD is out of the running.
However, if I run the language under the FreeBSD Linux emulator, $WEBSITE benchmarked it, and it only gives 25% of the native performance, and I need a minimum of 75% performance according to my budget and the benchmarks from $WEBSITE2.
Also, if I run the Linux version, I need to update that separately, and that will make my update régime twice as complicated, and quadruple my testing.
So, I won't use BSD, I will use AlmaLinux after all.
Summary: benchmarks are not enough, but you need them. It is more complicated than just benchmarks.
Netflix chose FreeBSD to run their CDN, perhaps partially due to kernel licensing, but that's obviously a space where performance and stability matters.
Netflix contributes. Real Code. Rock stable. High quality. For so many years. So its not only the Free-Beer-License for them. I have never seen a single commit comming back from others, who build the most (financial) successfull trillion dollar bussines on top of FreeBSD, but comming back again and again, to (hard-)fork.
I'm not sure being dismissive or judging from only one metric is big picture thinking. Some may even call it narrow mindedness.
A quick Google search would show many interesting aspects of the BSDs and especially NetBSD, from resource efficiency to keeping the "original" Unix alive on current hardware, but I suspect you may not the kind of person to be receptive to that.
Depends, for some older chipsets it was there, for me, then. Though I have to concur, that is annoying, when your's is much too new, and thus badly supported, if at all.
> ...shady Bluetooth and Wi-Fi support
I'm a caveman and really don't care about that. Not even under Linux :-)
That sounds all really complicated and time consuming, but at the times it wasn't. Because the base is smaller, the compilers were faster. Expecting it to perform out of the box without adapting it to the environment will lead to frustration.
