My experience using FreeBSD has been the most fun I’ve had with an operating system in a while. It reminds me of Linux back in the early 2010s: it’s super barebones, and you need to work and tweak it. FreeBSD is ten years behind Linux in some areas but also ten years ahead in others. In terms of performance, package management, server reliability, and resource usage, it might become a valid choice very soon. However, it does fall behind in areas like audio servers and segment faults from nonexistent Linux syscalls, which I’ll explain in more depth.

FreeBSD has an edge over Linux by having a universal way to install packages. It’s a whole operating system, not a distribution. This makes applications such as Flatpak and Snap obsolete. Even forks of FreeBSD can run software from the official repositories with minimal breakage. It eliminates the pain of needing one package manager for your libraries/desktop and Flatpak for all your personal applications. If you have an incompatibility, you can simply enable the Linux service and run Rocky Linux 9 or Ubuntu 22.04 in a chroot. This allows you to run RPM and Debian packages that don’t work properly or non-ported apps that simply don’t run.

Another way it excels is in performance. You can optimize every single part of your operating system if you wish, without needing a complicated installer like Gentoo. Compiling your software is optional, and it’s recommended that you don’t mix ports software and apps installed with pkg. The kernel compiles in under 20 minutes on my low-end computers, one being dual-core with 4 gigs of RAM. I can listen to music with Firefox or MPV and still have it compile in under 40 minutes. The size and codebase of the kernel are truly incredible.

The final way it excels is in server performance. It runs much faster than Linux server-side, and a fun fact: Netflix uses it to host their backend due to its pure throughput under stress. Overall, TCP and UDP are faster under a FreeBSD system. Java applications run well, and there are usually no compatibility issues unless a program needs JNI and the required class is compiled for a different operating system. While under load, it uses fewer resources than Linux, and websites, containers, and game servers run very well - all while having more stable latency, throughput, and less jitter.

There are some ways that FreeBSD lags behind other operating systems. For example, some ported applications have segment faults and other memory issues. For instance, when I was testing LXQT with Openbox, obconf crashed upon changing any setting. When Googling the issue, I found a forum post from 2012 with the same issue, so it has existed for a while and still isn’t fixed. Many projects and apps on FreeBSD simply lack maintainers. While running KDE Plasma, I always had crash dumps from various services, many of them being 50+ megabytes.

FreeBSD also lags behind with audio. The buffer size of the audio card was improperly calculated, forcing the values to be abnormally large instead of a more optimal value. PulseAudio also caused Chromium to crash when forcing sndio, and on top of it, PipeWire wouldn’t run at all. Also, pipewire-pulse didn’t even start a PulseAudio socket, as proven by pavucontrol and its inability to find anything. The sndio daemon had many issues, including sample size and rates being improperly set, similar to PulseAudio. This was all while the audio card was fully functional and automatically detected by the built-in OSS (Open Sound System). Sound servers aren’t the best option on FreeBSD, and you should use OSS (the Unix/POSIX ALSA equivalent) instead.

It has been a super fun experience, and I have no plans of switching back for the time being. It’s nice seeing people who want improvement and reliability over recoding everything in Rust.