NetBSD always does interesting things that to me seems hard to do. Me, I am looking forward to v10 to replace another OS with that has a very hard hard time with that laptop.
I donated early this year after seeing how far away they were from their 2022 goal, which is very modest. I hope this news stores up their finances :)
That's the kernel memory allocator in SMP being lockless, right? (https://www.dragonflybsd.org/features/) You still can't get around locks for many shared resources, especially hardware ones.
I'm pretty sure that's equivalent to netbsd's rump kernels and Linux's UML (user mode Linux), no? Certainly a good feature, and something I were saw wider use, but hardly unique.
The NetBSD rumpkernel allows for running individual drivers in userspace, while UML and vkernel are both geared towards running full kernels. UML and vkernel both look pretty similar to me though.
That's true, but that just means that rump kernels took the microkernel approach and make you do it piecemeal; I still think it counts as a different side of the same coin.
Really? Please show me a production server based on RISC-V, dont get me wrong i would love that, but reality being reality ARM is something atm..and not RISC-V...nor POWER...hmhmmm..
>If anything, migration of servers to ARM has halted because decision makers can read the writing on the wall.
I see the opposite here...
>but I wouldn't bet on ARM being more predominant than RISC-V there by 2025.
Sure Apple and all Smartphones will change to RISC-V, look i would love to believe that, it's just not the reality. But if you talk about microcontroller'ish stuff, then you are probably right that risv will be more dominant in 2025.
I believe Japanese ISP's used netBSD in their hardware. I think it's used in many embedded systems as another user pointed out. NASA has used NetBSD in the past as well.
I used it. As Desktop, daily driver, and on servers. The same way I used Gentoo.
The thing is, if you compile from source, and don't need proprietary apps which assume linuxisms, anything which is compiled from source runs just the same way, as it would under Linux, or even(slightly) better. But that seems to be an almost lost art, nowadays? (Assuming you have fully supported hardware, drivers, and such, which was the case for a while with some systems) Meanwhile they also have a package manager for binaries, but I've never used that because I've been used to using sources :-)
However, I've got lazy, too, and now use some ready made distro booted from USB-keychain, running from RAM.
Besides that, what would be the usecase? The base system is small, lean & mean, and in my experience rock solid, as in UNKAPUTTBAR. The organization and style of source was more understandable to me, as was the framework to recompile the base via build.sh (make world in FreeBSD terminology), and applications from their 'Ports/Portage/AUR' which is called PKGSRC there.
The same goes for the filesystem layout, /etc, init, and so on. It's just really nice, all in all.
Thinking about it, the question is like what would be the usecase for Alpine-Linux? Some people are using that as desktop, too, for probably similar reasons, but enjoying better hardware driver support.
I think the highest hurdle for people has been the 'strange concept' of using 'slices' and 'BSD-Disklabels' to further split apart MBR-style partitions.
I don't know how that applies to UEFI/GPT-partitioning and secure-boot actually.
Haven't tried that, so far. Seems to be another hurdle, though I know from others that it runs, at least without secure-boot. Seems to be that 'The Guide' and FAQs are lagging behind reality. As often is the case, need to read mailing lists then, sigh...
Or simply searching for UEFI and GPT on their wiki, which leads to:
Which wasn't even mentioned in all the (mainstream) discussions of SysV vs. systemd because NIH?
I don't know exactly how to say this, but IMO you've missed out on an experience, if you don't know it. No matter how inconvenient initial installation or hardware support is.
Tried to use DragonFlyBSD as a desktop environment a couple of years ago, which turned out to be a disappointment. Haven't touched it since, did it get any better recently?
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.
I donated early this year after seeing how far away they were from their 2022 goal, which is very modest. I hope this news stores up their finances :)