Technical reasons to choose FreeBSD over GNU/Linux

Published on 2020-04-11. Modified on 2023-10-27.

I run FreeBSD as my daily driver on both my main workstation and on all my servers and I have been running FreeBSD since about 1999 because I consider it an amazing operating system. In this article I will address some of the technical reasons for choosing FreeBSD over a GNU/Linux distribution.

A complete operating system

On FreeBSD you'll notice right away that you're dealing with a "complete operating system". All the different components are developed uniform. This means that if a change in one component has an impact on the entire system the developers can easier consider the full picture before implementing the change, and further plan and develop the impacted components as well. The BSD kernel, the init system, the userland tools, the ports and package manager, all of it are developed by the project members and integrated into one system, and as such, just as an example, the top command (see the ZFS ARC Stats section) on FreeBSD has integrated information about the ZFS ARC (Adaptive Replacement Cache).

The kernel and base system are completely separated from the third party applications. Base system configuration goes into /etc while all third party configuration goes into /usr/local/etc. Everything you can configure and everything you can tune or setup is documented in the man pages.

You have everything from the rc utility, which is the command script that controls the automatic boot process after being called by init, to the command scripts, to the sysctl kernel management tool, to all the different system configuration, and everything else put together very well and well documented.

Because FreeBSD is a complete operating system and not something that has been "glued together" as things are in a Linux distribution, everything is well thought out, it is based upon many years of experience, and when things change, they change for the better for the entire community and with a lot of feedback from real use cases and problems in the industry.

As a comparison, Debian GNU/Linux, which is one of my favorite Linux distributions, has the Debian way of doing things, it is distribution specific. The Debian way is represented by the usage of a specific set of configuration management tools and patches that make third party software conform to "the Debian way" of setting things up. And while this in some sense can unify how you do things in Debian, it is unfortunately breaking with upstream configuration which can make it very annoying to deal with. This is especially a problem when something isn't working right, or when the way things are described in the upstream documentation doesn't match the setup on Debian. Another problem with this approach is that some third party software, and even core elements of Debian, such as systemd, cannot be shaped into "the Debian way". The result is an operating system where some parts are running "The Debian Way" while other parts are not. Debian GNU/Linux has incorporated systemd yet at the same time the default networking part is Debian specific. Sometimes you have to disable and remove Debian specific things to get systemd specific things to work. All of this is the result of a system that has been put together by many mismatching components from many different projects.

Arch Linux on the other hand, which is another one of my favorite Linux distributions, wants third party software to remain as upstream has made it. They do not change anything unless absolutely necessary. This is great because this means that the upstream documentation matches the software. However, while this helps improve the overall management of the system, the fact remains that the Linux kernel, the userland tools, and everything else is developed by separate entities. Conflicts between completely different projects, like e.g. the Linux kernel and the systemd developers, could result in a non-functional operating system. This cannot happen with FreeBSD because FreeBSD is a complete operating system.

The Ubuntu Linux distribution, which I have never liked, is even worse. Because it is based upon "Debian unstable" it runs with a lot of Debian tooling and setup, yet at the same time there is also the "Ubuntu way" in which things have been changed from Debian. Then there is further added a GUI layer on top of all that, a so-called user improved tooling layer, which sometimes makes Ubuntu break in incomprehensible ways.


Some people don't consider documentation to be a part of a technical reason to use something, but documentation belongs as an integrate part of the technology it describes. Bad documentation, outdated documentation, and missing documentation should be considered a bug.

FreeBSD's documentation is shipped with the system so you don't have to search the web. The man pages for the base system are of excellent quality and specifically written for FreeBSD. Most of what you need is right there with the system.

FreeBSD also has the FreeBSD Handbook, which covers anything from the installation to the day to day use of FreeBSD. The Handbook can also be installed locally during installation. The handbook do occasionally have some outdated sections as the book is the result of ongoing work by many individuals, but it is generally updated and well written.


Normally it's not the operating system that get compromised, but a program running on the operating system. In some situations a compromised program can interact with the operating system in a way that also compromises the operating system. Securing your operating system means that you try to ensure that your computer's resources are used only by authorized people for authorized purposes.

FreeBSD is by default setup to be performant and it is not secure by default like OpenBSD is, however FreeBSD provides many tools and options to help you secure your system against attackers.

It's impossible for me to provide an exhaustive list of options and available features in this article as the subject of security with FreeBSD could easily fill out a book. I highly recommend Michael W. Lucas book Absolute FreeBSD if you want a more in-depth study of some of the security features FreeBSD provides.

However, I can mention a couple of things.

Security install-time options

During installation of FreeBSD the installer provides a set of options you can enable or disable.

Most of FreeBSD's other kernel-level security settings are available in the security.bsd sysctl tree and more get added every few months. You can run the command sysctl -d security.bsd to display the available options on your FreeBSD installation.

# sysctl -d security.bsd
security.bsd: BSD security policy
security.bsd.stack_guard_page: Specifies the number of guard pages for a stack that grows
security.bsd.unprivileged_get_quota: Unprivileged processes may retrieve quotas for other uids and gids
security.bsd.hardlink_check_gid: Unprivileged processes cannot create hard links to files owned by other groups
security.bsd.hardlink_check_uid: Unprivileged processes cannot create hard links to files owned by other users
security.bsd.unprivileged_idprio: Allow non-root users to set an idle priority
security.bsd.unprivileged_proc_debug: Unprivileged processes may use process debugging facilities
security.bsd.conservative_signals: Unprivileged processes prevented from sending certain signals to processes whose credentials have changed
security.bsd.see_jail_proc: Unprivileged processes may see subjects/objects with different jail ids
security.bsd.see_other_gids: Unprivileged processes may see subjects/objects with different real gid
security.bsd.see_other_uids: Unprivileged processes may see subjects/objects with different real uid
security.bsd.unprivileged_read_msgbuf: Unprivileged processes may read the kernel message buffer
security.bsd.unprivileged_mlock: Allow non-root users to call mlock(2)
security.bsd.suser_enabled: processes with uid 0 have privilege
security.bsd.map_at_zero: Permit processes to map an object at virtual address 0.

Vulnerability Statistics

This is a list of vulnerability statistics for FreeBSD and Linux. The generally lower amount of security issues on FreeBSD doesn't necessarily mean that FreeBSD is more secure than Linux, even though I do believe it is, but it can also be because there is a lot more eyes on Linux. However, the attack surface on most Linux distributions are considerably higher that on FreeBSD.

| Year    | FreeBSD | Linux |
| 1999    | 18      | 19    |
| 2000    | 27      | 5     |
| 2001    | 36      | 22    |
| 2002    | 31      | 15    |
| 2003    | 14      | 19    |
| 2004    | 15      | 51    |
| 2005    | 17      | 133   |
| 2006    | 27      | 90    |
| 2007    | 9       | 62    |
| 2008    | 15      | 71    |
| 2009    | 11      | 102   |
| 2010    | 8       | 123   |
| 2011    | 10      | 83    |
| 2012    | 10      | 115   |
| 2013    | 13      | 189   |
| 2014    | 18      | 130   |
| 2015    | 6       | 86    |
| 2016    | 6       | 217   |
| 2017    | 23      | 454   |
| 2018    | 29      | 177   |
| 2019    | 18      | 170   |
| 2020    | 31      | 126   |
| 2021    | 25      | 158   |
| 2022    | 1       | 73    |
| Total   | 430     | 2780  |

For further information about the specific vulnerabilities you can take a look at the CVE Details website for FreeBSD and Linux


FreeBSD has great engineering and release management practices. FreeBSD goes through multiple steps from idea inception to public release.

When someone gets an idea and develops something new, it first gets peer technical reviews. Then it enters into the "current" branch for integrated testing and depending on complexity or potential impact the migration window for going into the "stable" branch will be adjusted. Then it enters into the "stable" branch for wider user base testing. This is usually where all beta testing occurs also with a wider community engagement. Then it enters into "release" candidate testing which usually lasts for 3 rounds before it becomes a normal "release" version. This means that you can be pretty confident that things are going to continue to work, provided that you understand the release and upgrading notes.

Patches for software are released to fix any vulnerabilities and bugs.

This typically makes FreeBSD a very solid operating system.

The Ports Collection

The FreeBSD Ports collection is an amazing feat of engineering. Both NetBSD's pkgsrc (package source) and OpenBSD's ports collection trace their origins to the FreeBSD ports system.

While FreeBSD has binary packages, just like Debian Linux or Arch Linux, which are handled by the pkg package manager, FreeBSD also has the ability to compile software from source, using user specific compile time configuration. The Arch Linux Build System is actually heavily inspired by the FreeBSD ports system. Still, with the FreeBSD ports system you get to choose the most relevant compile time options during make, whereas you manually have to edit and change the package maintainers PKGBUILD script on Arch Linux (basically, you're supposed to accept the default settings).

The FreeBSD ports collection use Makefiles to automate the process of compilation, installing and uninstalling software with the make command. The files that comprise a port contain all the necessary information to automatically download, extract, patch, configure, compile, and install the application and very little (if any) user intervention is required after issuing a beginning command such as make install or make install clean in the ports directory of the desired application. If the port has needed dependencies on other applications or libraries, these are installed beforehand automatically.

Most ports are configured with a default set of options which have been deemed generally appropriate for most users. However, and this is one of the great things about the ports system, these configuration options can be changed before installation using the make config command. The command brings up a text-based interface that allows the user to select the desired options.

At the time of publishing this article more than 30,000 ports are available in the collection.

Rolling release third party packages

You have two different branches to choose from regarding third party packages. One is called "quarterly" and the other is called "latest".

Quarterly is the name for Ports branches cut from the HEAD branch in the revision system at the beginning of every yearly quarter in January, April, July, and October, and the name for the binary package sets that are produced from these branches.

The quarterly branch provides users with a more predictable and stable experience for port and package installation and upgrades. This is done essentially by only allowing non-feature updates from upstream. Quarterly branches aim to receive security fixes, but there may also be version updates, or backports of commits, bug fixes and ports compliance or framework changes - depending on what upstream does.

However, if you choose the "latest" branch FreeBSD becomes a rolling release with regard to third party packages much like Arch Linux, and it then gets the bleeding edge software.


Poudriere is a utility for creating and testing FreeBSD packages. It utilizes the FreeBSD jail system to set up isolated compilation environments. These jails can be used to build binary packages for any version of FreeBSD. Once the packages are built, they are in a layout identical to the official mirrors. These packages are usable by the FreeBSD pkg binary package management tool.

With Poudriere you can easily build and set up your own binary package repository in which packages are build exactly to your specifications and needs.

Poudriere handles bulk building of the entire ports tree, specific subsets of the ports tree, or a single port including its dependencies. It automatically builds packages, generates build logs files, provides a signed pkg repository, makes it possible to test a port build before submitting a patch to the FreeBSD bug tracker, makes it possible to test different builds using different options. Poudriere performs its building in a clean jail environment where it is capable of using zfs specific features. This means that there is no pollution of the host environment, no leftover files, no accidental removals, no changes of existing configuration files.

Poudriere is straightforward to set up and use as it has no dependencies, and will run on any supported FreeBSD release.


Unlike on Linux, the ZFS filesystem is a first class citizen on FreeBSD. This not only means that it is possible to have root installed on ZFS, and the installer supports this out of the box, but it also means that a lot of the base system tools have been tightly integrated and build with support for ZFS. Running ZFS on FreeBSD is very different from running ZFS on Linux. On FreeBSD you get more tools that can be used to specifically investigate performance issues or other relevant issues with ZFS.

Some of the great features of ZFS are:

Of course, you also get all of these features when you run with ZFS on Linux. However, there is a big difference as no single Linux distribution comes even close to the level of integration with ZFS that FreeBSD has.

Boot environments

Due to the tight integration with ZFS, FreeBSD also supports boot environments. With boot environments you can install multiple versions of the core operating system and choose which one to boot into. As such, a boot environment is a bootable clone or snapshot of the working system. With boot environments you can perform bulletproof upgrades or changes to the system, you don't have to worry about breaking anything because you can always roll back and throw away.

This also mean that you can update a FreeBSD system inside a new ZFS boot environment without touching the running system. You can also perform upgrades and test the results inside a FreeBSD Jail. You can even copy or move a ZFS Boot Environment unto another machine.

FreeBSD has the bectl utility that makes it easy to manage boot environments.

BSD init

FreeBSD uses the traditional BSD-style init. In the BSD-style init, there are no run-levels and /etc/inittab does not exist. Instead, startup is controlled by rc scripts.

The scripts found in /etc/rc.d/ are for applications that are part of the base system, such as cron, sshd, syslog, etc. The scripts in /usr/local/etc/rc.d/ are for user-installed third party applications such as NGINX or Postfix.

As previously mentioned, because FreeBSD is developed as a complete operating system, user-installed third party applications are not a part of the base system. Third party applications are installed using packages or ports. In order to keep them separate from the base system, user-installed applications are installed under /usr/local/. As such, user-installed binaries reside in /usr/local/bin/, whereas configuration files are located in /usr/local/etc/.

In the BSD init system services are enabled by adding an entry for the service in /etc/rc.conf. Defaults settings are located in /etc/defaults/rc.conf and these default settings are overridden by settings in /etc/rc.conf.

The following entry in /etc/rc.conf enable sshd:


You can manually add the entry, or you can run:

# service sshd enable

Which will automatically edit /etc/rc.conf and add the entry.

You can manually start a service with:

# service sshd start

If a service has not been enabled, but you still want to start it, it can be started from the command line using:

# service sshd onestart

You can read more about init systems on Wikipedia.


The FreeBSD Jails system is another amazing feat of engineering.

Jails were introduced in FreeBSD in version 4.0 on March 14, 2000.

The FreeBSD jail is an OS-level virtualization that allows you to install a FreeBSD-derived system into several independent mini-systems called jails. The systems running in jails all share the same kernel and system resources and as a result there is very little overhead.

The need for the FreeBSD jails came from a small shared-environment hosting provider's (R&D Associates, Inc.'s owner, Derrick T. Woolworth) desire to establish a clean, clear-cut separation between their own services and those of their customers, mainly for security and ease of administration. Instead of adding a new layer of fine-grained configuration options, the solution, which was developed by Poul-Henning Kamp, was to compartmentalize the system, both its files and its resources, in such a way that only the right people are given access to the right compartments.

With FreeBSD jail, it is possible to create various virtual machines, each having its own set of utilities installed and its own configuration. This makes it a safe way to try out software. For example, it is possible to run different versions or try different configurations of a web server package in different jails. And since the jail is limited to a narrow scope, the effects of a misconfiguration or mistake (even if done by the in-jail superuser) does not jeopardize the rest of the system's integrity. Since nothing has actually been modified outside the jail, changes can be discarded by deleting the jail's copy of the directory tree.

The FreeBSD jail does not however achieve true virtualisation; it does not allow the virtual machines to run different kernel versions than that of the base system.

FreeBSD jails are an effective way to increase the security of a server because of the separation between the jailed environment and the rest of the system (the other jails and the base system).


Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD.

Bastille uses FreeBSD jails as a container platform and adds template automation to create a Docker-like collection of containerized software.

Templates take care of installing, configuring, enabling, and starting the software, providing an automated way of building containerized stacks.


Capsicum is a sandbox framework developed at the University of Cambridge Computer Laboratory, supported by grants from Google, the FreeBSD Foundation, and DARPA.

Capsicum extends the POSIX API, providing several new OS primitives to support object-capability security on UNIX-like operating systems:

The FreeBSD implementation of Capsicum, developed by Robert Watson and Jonathan Anderson, ships out of the box since FreeBSD 10.0. Capsicum for FreeBSD is the reference implementation, and serves not only as a reference for Capsicum APIs and semantics, but also provides starting-point source code for ports to other platforms (e.g., Capsicum for Linux and Capsicum for DragonFlyBSD).

For more information about Capsicum on FreeBSD please see:


DTrace is a comprehensive dynamic tracing framework ported from Solaris. DTrace provides a powerful infrastructure that permits administrators, developers, and service personnel to concisely answer arbitrary questions about the behavior of the operating system and user programs.

DTrace can provide a global overview of a running system, such as the amount of memory, CPU time, filesystem and network resources used by the active processes. DTrace can also provide fine-grained information, such as a log of the arguments with which a specific function is being called, or a list of the processes accessing a specific file.

For more information on DTrace usage see DTrace one-liner tutorial and DTrace Examples.


bhyve is a native FreeBSD hypervisor that runs guest operating systems inside a virtual machine. Parameters such as the number of virtual CPUs, amount of guest memory, and I/O connectivity can be specified with command-line parameters.

bhyve supports the virtualization of several guest operating systems, including FreeBSD 9+, OpenBSD, NetBSD, Linux, illumos, DragonFly, Windows Vista and later and Windows Server 2008 and later. Current development efforts aim at widening support for other operating systems for the x86-64 architecture.

The bhyve hypervisor became part of the base system with FreeBSD 10.0-RELEASE.

bhyve requires a processor that supports Intel Extended Page Tables (EPT) or AMD Rapid Virtualization Indexing (RVI) or Nested Page Tables (NPT). Hosting Linux guests or FreeBSD guests with more than one vCPU requires VMX unrestricted mode support (UG). Newer processors, specifically the Intel Core i3/i5/i7 and Intel Xeon E3/E5/E7, support these features. UG support was introduced with Intel's Westmere micro-architecture.


FreeBSD is all about choice, and as such it has three different firewalls built into the base system: PF, IPFW, and IPFILTER, also known as IPF.

Since FreeBSD 5.3, a ported version of OpenBSD's PF firewall has been included as an integrated part of the base system. PF is a complete, full-featured firewall that has optional support for ALTQ (Alternate Queuing), which provides Quality of Service (QoS). The filtering syntax of PF is similar to IPF, with some modifications to make it clearer. Network Address Translation (NAT) and Quality of Service (QoS) have been integrated into PF, QoS by importing the ALTQ queuing software and linking it with PF's configuration. Features such as pfsync and CARP for failover and redundancy, authpf for session authentication, and ftp-proxy to ease firewalling the difficult FTP protocol, have also extended PF. Also, PF supports SMP (Symmetric multiprocessing) & STO (Stateful Tracking Options).

One of the many innovative features is PF's logging. PF's logging is configurable per rule within the pf.conf and logs are provided from PF by a pseudo-network interface called pflog, which is the only way to lift data from kernel-level mode for user-level programs. Logs may be monitored using standard utilities such as tcpdump.

IPFW is a stateful firewall written for FreeBSD which supports both IPv4 and IPv6. It consists of several components: the kernel firewall filter rule processor and its integrated packet accounting facility, the logging facility, NAT, the dummynet traffic shaper, a forward facility, a bridge facility, and an ipstealth facility.

FreeBSD provides a sample ruleset in /etc/rc.firewall which defines several firewall types for common scenarios to assist novice users in generating an appropriate ruleset. IPFW provides a powerful syntax which advanced users can use to craft customized rulesets that meet the security requirements of a given environment.

IPF is a cross-platform open source firewall which has been ported to several operating systems, including FreeBSD, NetBSD, OpenBSD, and Solaris. IPF is a kernel-side firewall and NAT mechanism that can be controlled and monitored by userland programs. Firewall rules can be set or deleted using ipf, NAT rules can be set or deleted using ipnat, run-time statistics for the kernel parts of IPF can be printed using ipfstat, and ipmon can be used to log IPF actions to the system log files.

IPF was originally written using a rule processing logic of "the last matching rule wins" and only used stateless rules. Since then, IPF has been enhanced to include the quick and keep state options.


FreeBSD has over five hundred system variables that can be read and set using the sysctl utility. These system variables can be used to make changes to a running FreeBSD system. This includes many advanced options of the TCP/IP stack and virtual memory system that can dramatically improve performance for an experienced system administrator.


FreeBSD GEOM is the main storage framework for the FreeBSD operating system. It provides a standardized way to access storage layers. GEOM is modular and allows for GEOM modules to connect to the framework. For example, the geom_mirror module provides RAID1 or mirroring functionality to the system. A number of modules are already available, and new ones are always in active development by various FreeBSD developers.

Because of GEOM's modular design, modules can be stacked together to form a chain of GEOM layers. For example, on top of the geom_mirror module an encryption module can be added, such as geom_eli to provide a mirrored and encrypted volume. Each module has both consumers and providers. A provider is the source of the GEOM module, often a physical hard drive but sometimes a virtualized disk such as a memory disk. The geom module in turn provides an output device. Other GEOM modules, called consumers, can use this provider to create a chain of modules connected to each other.

Linux Binary Compatibility

FreeBSD provides binary compatibility with Linux. This allows users to install and run many Linux binaries on a FreeBSD system without having to first modify the binary. In some specific situations Linux binaries can even perform better on FreeBSD than they do on Linux.

Not all Linux-specific operating system features are supported under FreeBSD. For example, Linux binaries will not work on FreeBSD if they overly use i386 specific calls, such as enabling virtual 8086 mode.

Security Event Auditing

FreeBSD includes support for security event auditing. Event auditing supports reliable, fine-grained, and configurable logging of a variety of security-relevant system events, including logins, configuration changes, and file and network access. These log records can be invaluable for live system monitoring, intrusion detection, and postmortem analysis. FreeBSD implements Sun's published Basic Security Module (BSM) Application Programming Interface (API) and file format, and is interoperable with the Solaris and Mac OS X audit implementations.

Final notes

This article is by no means an exhaustive list of technical reasons to use FreeBSD over GNU/Linux. Many other reasons exist that I haven't addressed. However, these are some of the features I believe stand out.

I ran Microsoft MS-DOS on my first PC, then later Microsoft Windows 3.0. Since then and up until Microsoft Windows XP, I had done a lot of PC and server related work on Microsoft operating systems and I hated it. It was very time consuming because Microsoft's operating systems where very insecure, unstable and just plain bad.

In about 1997 a friend of mine recommended that I tried out Linux, which I did. The very first Linux distribution I ran was Red Hat Linux. It took more than a week downloading it via my old modem, during which the phone line was busy all hours a day :)

After a couple of years running Red Hat Linux and testing out other Linux distributions as well, I eventually settled on Debian mainly due to its (at the time) amazing package manager apt-get and due to its stability (getting only security and bug fixes in the stable branch). Debian became my favorite Linux distribution and I used it both personally and professionally on workstations and on servers.

In 1998 I discovered FreeBSD, which I then also began running personally and professionally from about 1999, also on both workstations and servers. Since then I have tried many other operating systems and today I also run OpenBSD, Arch Linux, Artix Linux, Void Linux and Alpine Linux.

I use the different operating systems for different tasks, and I prefer some above the others for specific setups.

I am currently running FreeBSD as my main driver on both my desktop workstation and on a bunch of servers and unless you have a very specific need to use Linux, you will find that FreeBSD is much more real UNIX-like. If you need ZFS, you should definitely run FreeBSD.

In any case, next time you have planned to fiddle around with an operating system, try out FreeBSD. It also has a great community with many helpful and friendly people.

Recommended reading

Michael W. Lucas has written one of the best books about FreeBSD called Absolute FreeBSD which I highly recommend, if you are interested in FreeBSD.