OpenBSD is forever tied in first place with Void Linux as my favorite desktop OS. This is particularly funny because OpenBSD isn’t “just a desktop OS”; in its purest form, the base installation without any installed packages, it makes for an excellent Ethernet router, firewall, or web server. It even ships with its own fork of X11 called Xenocara, along with fvwm2 and its own calm window manager, so there’s a rudimentary desktop OS in there too. With that said, in 2024 there is no such thing as a fully functioning desktop computer or workstation without at least a web browser of some kind, and if you’re adding packages you may as well build a full desktop system to suit your needs.
So how do you go from the amazing but unfortunately limited base install to a “daily driver” workstation operating system? There are many ways to do this, and I will present a couple of paths I take depending on the hardware and use case involved. Before I do that, a bit of prep is necessary to get OpenBSD into more of a desktop OS mode.
preliminary setup
The main difference between the BSDs and most Linux distros, apart from licensing, is the fact that BSD is a complete, cohesive operating system in the base installation and any other software installed afterwards is not considered part of the operating system itself. With most Linux distros, you get the base installation which is made up of components pulled from all sorts of sources; the Linux kernel itself of course, usually the GNU userland, an init system (usually systemd these days but there are other, arguably saner options), and usually X11 and/or Wayland with a “hero” desktop environment or window manager. You may get one or more web browsers, perhaps a snazzy terminal emulator like kitty or terminator (my personal favorite), and a few other odds and ends.
What all of that means is that when you update BSD itself, you’re just updating the base operating system as it shipped. You have to update third party packages or ports separately, and a bug or issue in a package update usually won’t affect the core system. With Linux the core distribution is updated at the same time as any apps installed by the user, and this can lead to an unstable system especially if you’re running a bleeding edge rolling distro like Arch.
So with all of that out of the way, hopefully you have a better understanding of what you actually get when you first install OpenBSD. There’s no graphical login, no flashy shiny bits, and it starts with secure and conservative default settings. You’re dumped at a console login after boot and expected to mold the OS into whatever you need it to be. Since we’re talking about building a workstation, let’s begin by logging in as root and tweaking a few settings.
The first order of business is giving your regular user the ability to run as root. In the Linux world this is accomplished by the overly complicated and potentially insecure sudo utility. In OpenBSD, we have the much simpler and easier to understand doas utility. You can give your user elevated permissions via the doas.conf file:
# echo 'permit persist keepenv username' > /etc/doas.conf
Let’s break that down. “permit” is what allows the user to gain the privileges to run as root, “persist” means that once the user enters their password they can go a while without having to type it again, “keepenv” means the user retains their environment rather than inheriting root’s environment, and “username” is simply your user’s name. Note that the doas.conf file doesn’t exist until we create it with the above command; if you’d like to append something to it later you can use the same echo command but use double right angle brackets instead. You can also disable the password request if you want by replacing “persist” with “nopass”; this is fine if no one else has physical access to your computer but it does trade some local security for convenience.
We will also need to adjust the aperture setting for the graphics processor on the machine. This can be done by setting the sysctl value “machdep.allowaperture” to something greater than zero. For most Intel GPUs, you’ll want it set to “2”. I’m on a machine with an AMD GPU, so I’ll set mine to “1”:
# echo 'machdep.allowaperture=1' > /etc/sysctl.conf
Again, if you haven’t previously created it, this will create the sysctl.conf file which determines sysctl settings on boot. The next order of business deals with SSD performance. Assuming your system uses an SSD of some sort for storage, which is typically the case with any PC purchased or built in the last several years, you’ll want to tweak the /etc/fstab file for better performance. You can do this by adding the noatime switch to each entry in the fstab file. This is easiest to accomplish with a search/replace in your favorite text editor, or with the sed stream editor:
# sed -i 's/rw/rw,noatime/' /etc/fstab
Next we want to make sure our user has increased resources, otherwise you’ll have a lot of program crashes in day to day use. First let’s make our user a member of the login class “staff”:
# usermod -L staff username
While you’re at it you can also add your user to the “staff”, “_shutdown” and “operator” groups with a similar command:
# usermod -G staff,_shutdown,operator username
Even as a member of the “staff” login class, you may find you need to increase the limits for that login class to maintain a stable and functioning desktop. Open the /etc/login.conf file in your favorite editor and increase some of the values listed under the “staff” class. I will typically increase the datasize-cur to just under my total RAM, and I will set datasize-max to “infinity”. You can also double the default numbers for openfiles and maxproc, especially if you work with a lot of files at once or run programs with a lot of threads, respectively.
A quick note about packages; you can read more at the openbsd.org website, but for now there are three commands that will come in handy when searching for and installing packages:
pkg_info -Q <search string> pkg_info <package name> pkg_add <package name> <package name>...
The first is how you search for a package. It will search the package database for any packages with the search string in the name. The second gives you more information about a specific package, you have to know the correct name for the package in order for it to return the information. The third is how you actually install a package (or set of packages, separated by spaces).
At this point I typically reboot to enable all of these changes, and log in as my regular user to continue setup. Now let’s look at the graphical side of things!
path #1: full blown desktop environment
If you decide you need a full on DE, there are a few choices available in ports. Speaking of ports, the only web-based searchable ports index I trust is openports.pl, created and maintained by the phenomenal OpenBSD developer solene@, and hosted at openbsd.amsterdam. Anyway, you can choose your preferred DE from among several contenders, including Xfce (my preference), MATE, Lumina Desktop, and GNOME. Most of the parts necessary for KDE Plasma are there as well, but it’s still a work in progress so it isn’t ready to run quite yet (but it is more or less complete in -current).
I’ll use Xfce as an example, since it’s the one I’m most familiar with. This is my typical procedure post-install to get a complete Xfce desktop:
# pkg_add xfce xfce-extras xdg-user-dirs terminator consolekit2 firefox thunderbird pinta xournal openbsd-backgrounds terminus-font noto-fonts noto-cjk noto-emoji audacious mpv unrar p7zip
This will pull in a ton of dependencies, including D-Bus. You’ll want to enable D-Bus like so:
# rcctl enable multicast messagebus # rcctl start messagebus
By default, running the “startx” command or enabling and starting xenodm (the OpenBSD display manager that ships in base) will launch fvwm2. Since we want to launch Xfce instead, we’ll need to add the following to our user’s .xsession file:
$ echo 'exec ck-launch-session startxfce4' > .xsession
Before we launch X11 for the first time, there’s a tweak that I prefer to do whether I’m running a full DE or just a plain window manager. Open the file /etc/X11/xenodm/Xsetup_0 in your favorite editor and comment out (use a “#” symbol) the line that invokes the xconsole like so:
#${exec_prefix}/bin/xconsole -geometry 480x130-0-0 -daemon -notify -verbose -fn fixed -exitOnFail
…unless you really have a need for the xconsole window on your desktop. You can also uncomment the stanza that enables a random background in the graphical desktop manager, but make sure you install the openbsd-backgrounds package as instructed.
Once you’ve made these changes, it’s time to enable xenodm and launch into X11 and our shiny new desktop! Do the following as root (or use the doas command as your regular user):
# rcctl enable xenodm # rcctl start xenodm
This will bring you to a login/password prompt, log in as your regular user and enjoy your shiny new desktop! Note that if you’re used to Xfce on Linux, be prepared for a few differences under OpenBSD. The Xfce port is quite polished and has a few tweaks to make it mesh better with OpenBSD, but there are some things that might throw you off. For example, there is no ALSA or Pulseaudio by default on OpenBSD, instead the audio subsystem is sndio, which is marvelous in its simplicity.
path #2: window manager (cwm)
If you decide you want to keep it simple and avoid all of those dependencies that come with Xfce, you can get by just fine with the project’s own cwm (calm window manager). It’s deceptively simple and stays out of your way, but is just as powerful and customizable as any other window manager. Best of all it comes already installed in base so it stays updated with the OS itself. Read more about it by entering “man cwm” at the command prompt.
You can use the same “pkg_add” command from above if you like any those apps and services, just leave out the “xfce” and “xfce-extras” (again, unless you want the packages they provide).
Next you’ll need a .cwmrc file; this file lives in your home directory and sets all the parameters you need to tune cwm to your liking. You will eventually find or create a configuration that suits you, but for now you just need some application launchers for the right-click application window. In your .cwmrc file place the following (or replace the options with your preferred software):
command browser firefox command terminal terminator command editor terminator -x nano command filemanager terminator -x mc
This basic set will get you pretty much anything you need to get started, and you can add as many launchers as you like to the list.
Like everything else in the base install, the manual (man) pages are a complete resource for learning how to set up and use your system. To learn more about setting up your .cwmrc file, just enter “man cwmrc” into the terminal.
to infinity and beyond
Where you go from here is up to you. OpenBSD can be used as a daily driver OS for many use cases; I did so myself for over a year just to prove to myself I could. You don’t even have to take my word for it, there are OpenBSD evangelists all over the tech world, even some like Derek Sivers who are creators first and nerds second.
I hope my post has been helpful on your journey of discovery with OpenBSD. If you need help with anything I haven’t covered, or if you’d like to correct me on anything (I love making mistakes because that’s how I learn!), drop me a line at my first name at this domain.