Often the question arises why one should prefer FreeBSD over any arbitrary GNU/Linux distribution, that is more widely spread and additionally offers commercial support. Though I have mostly positive experiences using Linux, there are many reasons why I would always choose FreeBSD for setting up a server.
BSD license
The first thing to mention here is the BSD license. It propagates complete freedom, independent of the desired use. As long as the authors’ credits remain in the source code files, you may redistribute it, customize it, use it as the basis for your own products, document it, share it to your friends or print it to a wallpaper - the imagination knows no limits.
But yet people keep arguing about what is the most libre license out there: BSD or the GPL. The GPL also permits modification and redistribution as well as commercial use of software but in contrast to the BSD license one has to recontribute all changes back and furthermore the full source must be published, even in a commercial project.
Both licenses have their own cons and pros but for me as a developer, it’s more convenient to use the BSD license as you don’t have to worry about almost anything.
Documentation (aka “The FreeBSD Handbook”)
In my opinion, the FreeBSD projects’ documentation is one of the best-written and most comprehensive tech documentations out there. It offers a great introduction to complete newbies who want to set up their first FreeBSD installation and simultaneously a powerful reference for users who are running FreeBSD for years. Beside the basic usage of the operating systems, it covers concrete use cases like web server setup and disk partitioning strategies.
It’s available as HTML in a variety of languages at https://www.freebsd.org/doc/handbook/. There are also versions out there in PDF, PostScript, RTF and - for the book lovers - even as a printed version.
Development model
Due to the fact that FreeBSD is - just like Windows and OS X - developed as a whole package, it feels like many things are tightly integrated. This one-stop-shop-feeling, that I used to miss on Linux for a long time, turns out to be a real blessing, especially in a server environment. So for example jails, FreeBSD’s approach to containerization, know how to handle ZFS volumes and therefore can create virtual environments directly each on a dedicated volume. Or the package management system that can update the host system itself as well as communicating with the jails service in order to update packages within the jails.
There are many other advantages and synergies resulting from the way FreeBSD is developed, but I think you yourself should give it a try ;-)
Stability and updates
First off, we don’t have to argue about the stability of both the Linux and FreeBSD operating systems. Both are extremely robust and durable when configured properly, though FreeBSD is often considered more stable due to it’s older code base. Whether this is really the case, I don’t know.
But those update issues… One would not consider it possible, that THAT is still an issue in 2015. But many years of painful experience taught me, that system updates often are not as trivial as supposed. Too many times I saw CentOS, Debian and Gentoo setups fail whilst their respective package managers tried to solve package dependencies over many update iterations and simply failed. This is also true when having to use external package repositories to get this or that running. Those are often not updated regularly and will likely fail when updating the whole system.
FreeBSD’s approach of logically dividing the packages into “base packages”, that are an integral part of the operating system and are only updated in total and without external dependencies, and the “user packages” supplied by the ports system, it’s possible to update them completely independent from each other, making the update mechanisms much more durable. And because of BSDs binary compatibility layers, it’s most likely that after a base system upgrade - even after an major release - all userland application will continue working without any issues.
Vice versa it’s possible to only update the additional packages without touching the base operating system.
But many administrators use to use a much more simple way of managing FreeBSD updates. Cause since the FreeBSD security bulletin keeps you on track with all the recent bugfixes in packages, it’s much more easy to only update those packages that got necessary security bugfixes (and their dependencies). And if you decided to run your applications in containers like you should, jailaudit (https://github.com/jfrioux/jailaudit) lets you create security reports for all installed packages in each jail.
Simple configuration
One can love systemd or hate it, it seems there’s no inbetween. And though I like the idea of unifying the Linux init system and essential userland tools throughout all major distributions, I don’t really like the implementation itself. It seems that it’s getting more weird and confusing every time a fancy XML configured tool is added to the stack. And it seems to me that all the tools that arise around systemd are much more inconvenient than useful. But this wouldn’t be the problem, if not even on the thousandth distribution everything would just completely go wrong. Just think of the disaster of system updates in Ubuntu after having it migrating to systemd…
On the other hand, the service management and general configuration of FreeBSD feels like we’re back in the 60s. There are some important text configuration files like rc.conf, sysctl.conf and loader.conf that manage huge parts of the system. rc.conf for example manages host name, network configuration, system startup and almost everything else affecting the base system. sysctl.conf manages runtime kernel configuration properties and device specific settings. This is almost everything. When you used Gentoo Linux and liked it’s configuration approach, you will love FreeBSD’s. Additionally, there’s an init system that’s much like Linux’s good old sysvinit and there are no runlevels. So as you see, it’s all much simpler and on a lower level, but this is exactly what you want as a system administrator.
Out-of-the-box functionality
One of Linux’ biggest advantages is the large software collection that comes with the most distributions. And though any of the any server task could also be accomplished using Linux, to me the most FreeBSD solutions seem to be much more carefully conceived. And sometimes, Linux’ diversity becomes it’s biggest fate. Because due to the many possible combinations of software, many of them don’t integrate very well with each other.
I want to give a short example here: In Linux, there are roughly two major technologies to persistently containerize full Linux guest systems within a Linux host (“persistent” != Docker): The linux-vserver project and lxc. And while linux-vserver has a long history that reaches back to kernel version 2.4, lxc just get’s started and has just began to become stable and usable. But this leads to a gap where linux-vserver is no longer capable of running almost any current Linux distribution (which is running systemd) because noone want’s to put effort in a nearly end-of-life project while lxc isn’t capable doing this either because there’s much work left to do. This is why some developers now started the lxcfs project to solve those issues (partly), see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1347020.
But in the end this means, that as of August 2015, there’s no container virtualization technology in Linux, that offers reasonable out-of-the-box capabilities for running it’s own host system a guest, which is very sad. And even if it would work, would you consider operating a data center, that runs on software, which has not been stable for at least a few years?
In contrast, FreeBSD’s jails runs for almost ten years and interoperates with many other core components like the package management system. Additionally, the technology is an integral part of the base system.