magda

With its initial release dating back to 1993, FreeBSD is a fork of 386BSD, which was a fork of the Berkeley Software Distribution (BSD, initially called “Berkeley Unix”) developed by the Computer System Research Group at the University of California, Berkeley from 1978 to 1995. Despite not really known by its name outside of information technologies, this distribution powers gaming consoles, such as the Nintendo Switch and PlayStation 3 and 4, servers directly and via the distribution TrueNAS, and Darwin, the base for all operating systems developed and maintained by Apple, making it an “all-rounder” among operating systems.

It is said that FreeBSD shares many similarities with Linux, however main differences between the two are the project's scopes and licensing. While Linux is just a kernel with device drivers licensed under GPL 2.0, FreeBSD provides documentation and userland utilities alongside an own kernel and drivers, all licensed under a less-restrictive FreeBSD license that is incompatible with GPL, OSI, and Copyleft.

Taking both project's similarities into account, I assumed it would not be too hard to give FreeBSD a chance. My excitement, though, did not last long.

Installation

Before I wanted to test it on bare metal, I planned on giving it a rather quick run within a virtual environment to minimize the chances of encountering unwanted surprises. Right off the bat, FreeBSD only offers a text-based installer and no GUI for its live system, regardless of which ISO is chosen. Choosing Install, users first need to select their preferred keymap and set a hostname before being provided to select additional system components like Debugging variants of the base system and the kernel, 32-bit compatibility libraries, which has been automatically selected, and a test suite.

Moving on, the installer progresses by prompting users to choose a file system, providing two automated – one providing the ZFS file system developed by Sun Microsystems and UFS, the Unix File System – and and two manual options. Given that this virtual machine, like all of mine, was configured to be as less straining on my weak hardware as possible, I selected UFS and went on to choose a partitioning scheme. FreeBSD offers four different partition schemes suited for four different use cases: APM (Apple Partition Map), BSD (BSD Labels), GPT (GUID Partition Table), and MBR (DOS Partitions). Even though I would not install FreeBSD alongside another OS, I went with GPT, instead of BSD.

Before confirming my settings, I was reminded of my recent experiences with OpenBSD, another BSD derivate, and how seemingly ridiculous this distribution's recommended partitioning was, so it was fairly relieving to discover that FreeBSD's automated options provide a sane configuration in this aspect, with one boot, one file, and one swap partition, which can be adjusted, as well.

After confirming, the installation of the base system began and took approximately one and a half minutes. Once having set a root password, configured my network, chosen my time zone, and optionally checked date and time, FreeBSD then allows users to select a few additional daemons to start at boot, such as local_unbound, sshd, powerd, and dumpdev, which enables kernel crash dumps. Both sshd and dumpdev are selected by default and I'd only choose ntpdate to syncronize system and network time during boot and powerd.

Users then are free to select some system hardening tweaks and an option to add an user account.

At that point, I missed to add my user to the wheel group, which would enable it to install and remove software, and partially to blame for this was the installer distracting me by asking if I want to lock this user out after creation. Personally, I cannot imagine a scenario in which someone would create an user that can only be accessed by the root user, but before digressing, I let it slide and was sent back to the TUI installer, now letting me make final configurations and change already-set things. Upon exiting, users are asked whether or not they would like to set any additional configurations via Shell. Choosing 'no' then leads to one last box, asking if the system should be rebooted or start the live CD. I rebooted the system instantly.

Installed System

Package Management & Documentation

Without automatic clock sync enabled, which adds 14 seconds to the boot process, FreeBSD took 35 seconds to boot, which is slower than Archcraft on bare metal. Due to the installed system not providing a desktop, I first had to study the FreeBSD Handbook a bit to get started and install a desktop environment. The guide covers the installation of three popular desktop environments, with those being GNOME, KDE Plasma, and Xfce. Before any DE can be installed, users have to download and configure X11/X.org first. Required dotfiles for .xsession or .xinitrc need to be created manually for each user.

Applications can be obtained by using either pkg for pre-compiled binaries, manually compiling packages from source, and via FreeBSD Port, which automatically compiles a collection of packages from source. Core packages such as X.Org and sudo, and tools like Vim are available as binaries and download was significantly faster than on OpenBSD.

With everything being set, I learned that reboot, just like on OpenBSD, does not initiate a reboot but merely kills most running processes to load a fresh shell environment; init 6 had to be entered to tell the machine to truly restart. The handbook does not provide an alternative to manually starting Xfce by entering startx after logging in via TTY, and XDM, which I could not get to run,, forcing me to search elsewhere for a guide on how to set display managers like LightDM up.

But before I would do that, I rolled with manually entering startx and was presented with a slow and Xfce environment with a constantly glitching mouse pointer and screen tearing whenever a window was being moved.

Performance

Speaking of performance, FreeBSD with Xfce required 440 MB of RAM when idle, with the CPU residing at 0%. Strangely enough, when checking again with no desktop environment running, FreeBSD still required 274 MB of RAM, only 40% of claimed memory being cached and thus putting active RAM usage at 164.4 MB – quite heavy for a command-line environment.

`

Other Observations

While the first times I would boot this system caused no issues, I began to notice few daemons to refuse to start at random times, once even claiming that support for cpufreq was unavailable due to missing files or a missing directory, even though it did exist and powerd starting normally during the next boot.

Because sudo is not being provided by default and thus also needs to be configured manually, my user pretty much was barred from doing anything; shutting the system down also was restricted to root only. To make matters more complicated, FreeBSD does not set a operator group during install, which made mounting devices impossible even when attempting to do so via root.

Second Attempt Using desktop-installer And An Older VirtualBox Version

At first I assumed that many issues I encountered simply were caused by the latest version of VirtualBox, as its previous version rendered the print, roll, and break keys unusable for no obvious reason. To test my hypothesis, I installed FreeBSD on a second virtual machine on another computer still running an older version of VirtualBox and decided to speed up the desktop configuration by using a tool named desktop-installer, which is not included in the base install and needs to be obtained post-installation. This text-based tool guides users through an automated desktop configuration for ten desktop environments and also offers some perks, including user – which would automatically add an operator group – and network settings. In my case, I wanted to give FreeBSD's own Lumina DE a closer look.

While the tool itself encountered no issues during execution, XDM, just like during the manual install, did not work at all and I was forced to enter startx to load Lumina.

Unfortunately, Lumina crashed every time it finished to load, and opening a TTY caused the entire VM to stop working. Restarting the VM and running desktop-installer one more time, I installed SLiM and LXQt as a backup environment. The next reboot caused two kernel panics and two automatic restarts before finally loading the SLiM login manager. Once logged on, LXQt also crashed. Repeating this procedure and loading LXQt one more time at least granted me with a desktop that recognized a few clicks, yet repeatedly told me that accessing my user's folders is “not permitted”.

TL;DR

Yes, much like Arch Linux, FreeBSD is a DIY system, however the main difference between the two is that Arch does not imply to be more suited for non-desktop usage. It also is barely comparable to OpenBSD, despite both not making it clear who they are trying to target in reality. Looking back, I felt that FreeBSD was suited for anything but a desktop computer due to its default configuration being more restrictive than the average Linux distribution.

I can see FreeBSD running well as a headless system on servers, firewalls, and gaming consoles, but certainly not on a workstation or a personal computer. Xfce, usually the rock-solid desktop environment, performed rather poorly and I was somewhat baffled to see a large non-Linux OS struggling with GPU drivers to the point of still not providing any drivers for NVIDIA cards. desktop-installer, although being recommended by other FreeBSD users, even made the whole system unusable. Despite trying to appreciate FreeBSD, I simply can't.

---

Hardware

Medion Akoya E4070 D

Processor: AMD A10–5700 APU @ 3.40 GHz

Display: Trinity (Radeon HD 7660D)

Memory: 4 GB RAM (3462 MiB)

Storage: 1 TB ST1000DM003-9YN162 (CC4G)

Network: RTL8111/8168/8411 PCI Express Gigabit Ethernet Control & Realtek RTL 8188CUS 802.11n WLAN Adapter

HP Pavilion 500–344ng

Processor: AMD A8–6500 APU @ 3.50 GHz

Display: ATI Richland Radeon HD 8570D

Memory: 8 GB RAM (7.18)

Storage: 1 TB WD10EZEX-60M HDD

Network: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller