Running OpenBSD on a Thinkpad: The Good

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.