Running OpenBSD on a Thinkpad: The Good
It’s been an overall positive experience
In a previous post I discussed some of the negative experiences that came with daily-driving OpenBSD on a Thinkpad T420s. I am still using that same laptop and OS combination, though, so in spite of these issues the good seems to outweigh the bad. So in this article I wanted to discuss some of my positive experiences with the shift.
Most things just work
This hasn’t been my first foray into BSD-based desktop systems. Some years ago I decided to install FreeBSD on a computer. It seemed the obvious choice, being more desktop oriented, having more software, better performance, etc. However I barely ever used that system during the time when I had it, because there were so many usability issues. From audio, to backlight control, to suspend-resume, so many basic features simply didn’t work out of the box. They can certainly be made to work, and maybe I just got unlucky with the hardware I was using (a Thinkpad T430), but it was a project and a half just getting that system usable.
Given it’s reputation, I was fully anticipating that OpenBSD would be similar,
if not worse. But I couldn’t have been more wrong. The install went off without
a hitch (using the laptops Ethernet port initially to download the wireless
driver) and as soon as I got dwm installed and running, I was pleased to find
that the laptop’s function keys all worked, even without configuring them in
dwm itself. Audio worked. backlight and volume control were good to go. Suspend
and hibernate also worked without any issues after starting the apmd(8)
service. I was able to connect immediately to my wifi network, again no issues.
I even got printing working with ease (though that one did require a little man
page reading).
Frankly, it reminded me of when I first tried Pop!_OS (20.04). I installed it, booted it up, and everything just worked. I got most of my Unix experience in the early 2010’s hacking away on Arch Linux, so to have everything work immediately was a (pleasant) shock. I felt the same way upon installing OpenBSD relative to my experience with FreeBSD.
Easy access to recent software (most of the time)
In recent years, most of my Linux boxes have run some version of Ubuntu or Pop!_OS, neither of which have a particularly aggressive update cycle. This means that the software available in the repositories will be a few versions old. There are plenty of work-arounds: ppas, building from source, etc., but they all add an extra level of annoyance to managing your system.
For example, I was experimenting with mpv(1)
for watching YouTube videos.
However, the version of mpv available on my Ubuntu workstation at the
university was old enough that it didn’t support ytdlp, only youtube-dl. This
rendered it effectively useless for this purpose, and so my only options were
to (a) update to a newer version of Ubuntu, or (b) compile a newer version of
mpv from source. The former wasn’t possible because of the IT department’s
unwillingness to install anything but an LTS version of Ubuntu (and 22.04
hadn’t come out yet), and the latter led into a build-dependency hell like none
I’d ever seen. I eventually just gave up on that particular machine and waited
for 22.04 to release.
On OpenBSD, by contrast, much of the software available in the ports tree is kept very up-to-date by its maintainers. Running -current, the only time when I’ve ever had to bypass the repositories and build from source was when neovim’s development branch moved to version 0.9.0. The port was still on 0.7.2 at the time, and all of my plugins updated for 0.9.0, which broke compatibility with the version of neovim I was using. The port has since seen a few updates and is now on 0.8.2, but I’m going to keep running my own version of neovim until the ports tree catches up to 0.9.0. This particular situation probably speaks more to the “joys” of neovim plugins than anything else. But that’s a rant for another day.
Additionally, I’ve found that there is software in the OpenBSD ports tree that
isn’t typically found in other system’s package managers. For example:
hugo-extended. I use it for this website, and on Ubuntu-based systems at least,
I’ve historically needed to download and install it manually from hugo’s
website. Not so with OpenBSD–it’s a simple pkg_add
away.
Sane system management
OpenBSD is incredibly easy to manage. As a simple example, connecting to a wireless network is as simple as,
# ifconfig <device> nwid <ESSID> wpakey <KEY>
and getting a list of available networks is
$ ifconfig <device> scan
If you want to connect to a network on startup, then just copy the command
arguments into /etc/hostname.<device>
, add inet autoconf
to the end of the
file, and you will auto connect on boot.
Have several networks you want to automatically connect to? Just replace
nwid
with join
and put each one on its own line in the file.
Managing audio is similarly straightforward, using sndioctl(1)
and
mixerctl(1)
. Startup services are managed with rcctl(1)
and kernel
configuration with sysctl(1)
.
It’s not hard to manage learning this small handful of programs; their interfaces and usage are very consistent. You can tell that the entire system was designed in its entirety, rather than being an assemblage of a bunch of standalone programs glued together to form a userspace
And, best of all, learning these programs is very straightforward because…
Great documentation
OpenBSD has amazing documentation, though you’d never know it if you simply used an Internet search engine. This is because the majority of the documentation exists in the form of man pages that come preinstalled with the operating system.
You’ll often see comments on the internet about how well written these man pages are, but this is a difficult thing to really comprehend until you have experienced them. Especially if you are only familiar with the manuals that come with software on Linux.
Let me put it this way. On Linux there’s a program called tldr
that
is used to give simple examples of how to use programs. Rather than
using the provided manuals, users instead get a different, standalone
program that provides the information in a more useful manner.
On OpenBSD there isn’t a need for tldr
–the manual is just set up
to be actually useful in the first place. Notably, almost all of the
manuals actually have an “examples” section at the end, that contains
the examples that would be loaded into tldr
.
Beyond this, the manuals also have a “See also” section that links to other manuals for related programs. I’ve learned about a bunch of new, useful tools by following these links. Sometimes it feels a bit like falling down a Wikipedia rabbit hole. The amount of “discovery” potential built into the simple text documents is astounding.
Exposure to new software
Pretty much all of the software that I regularly use is available in OpenBSD. However, because I’m using it on a decade-old laptop, some of these programs do not perform particularly well, which has pushed me into looking for lighter alternatives. This has been a net-positive to my workflow in a lot of ways.
Probably the best example of how this has been a positive benefit to me, in
general, is openconnect
. Penn State uses GlobalProtect for its VPN, and so
I’d been using the official GlobalProtect client on Linux to access it. But
this client doesn’t support OpenBSD, so it pushed me to look into alternatives.
As it turns out, openconnect
works perfectly, and has the added benefit of
being easily used in scripts. So, now on all of my machines I can connect to
the university VPN with the press of a hotkey–something I wouldn’t have set up
with the official client.
As for software that is available, but doesn’t run particularly well, the two major heavy-weights that I use are qutebrowser and neovim. Both of these programs do work, but they are a bit sluggish, which has pushed me into looking for alternatives. Beyond these two specific programs, I’ve also started a more general campaign towards removing application software written in interpreted languages from my workflow.
To that end, I’ve made the switch from kitty
to st
. I’m working on
replacing qutebrowser
with vimb
. I’ve started using tabbed
, which works
quite well to add tabbing functionality to st
and vimb
and is something
that I’d been meaning to do for years.
Neovim is a little trickier–I don’t think that I’ll ever fully get rid of it,
just because the convenience of having so many features built into my editor is
a little too much to give up. However, I have started investigating vis
(in
fact, this article was written using it), which seems quite promising.
The two major remaining python programs that I regularly use are khal
and
khard
. I’m looking at possibly replacing khal
with calcurses
, assuming
I can get CalDav working properly with it. khard
will probably need to stay,
though. abook
doesn’t support CardDav, and the necessary hoops to jump
through to get that working are probably worse than just using khard
. It
isn’t a particularly performance sensitive program in any case.
Conclusion
This list is not by any means complete. But I think that it includes all of the major (rational) reasons why I enjoy using OpenBSD on a ten year old laptop. There are of course aesthetic reasons for this choice as well: I really admire the simplicity of OpenBSD. Frankly, I wouldn’t recommend it to anybody, but I can say that I derive a lot of pleasure from using this system.