40 Days of OpenBSD
On 12 September, I installed OpenBSD 7.5 on my new desktop. The operating system just works. It's gets out of the way, mostly. It is minimal by design, which is what appeals to me. I'm still a huge fan, and small donor, of FreeBSD. However, one timeless frustration of FreeBSD is hardware support. The linux kernel and OpenBSD teams are quicker to support newer hardware. This fact is the entire reason I'm running OpenBSD as my desktop. If you want the early impressions, go back and read my post about daily driving OpenBSD.
Let's focus on the frustrations. In order to migrate to OpenBSD from Arch Linux and/or FreeBSD, there are some adjustments. I'm spoiled by Arch and FreeBSD diversity of available packages. Over the years, I've migrated from the "traditional UNIX utilities" to updated versions written in Rust or Go. Thankfully, OpenBSD packages include many of these "more modern utilities", such as exa, ripgrep, bat, helix, fzf, etc. I'm a huge fan of TUIs (text user interfaces). In theory, this love of TUIs should mesh with the OpenBSD philosophy. However, it's not complete. For example, I've managed to mostly replace gitui with gitg. It's not the same, but a functional equivalent.
I have not been able to replace Julia-lang so far. In order to really learn a language, I write everything I'm working on in that language. Over the years, I've written most of my core software in Julia. My backup system and other scripts are wholly Julia programs. Fish shell is very capable, so I've been rewriting some of my Julia programs into fish. However, dear cthulu, please give fish a dict! a hash! a key-value store as it were. I've been able to work around the lack of a dict with horrible functions using data in variables and vectors, but it isn't pretty. Sigh. For years, there is an open issue for a dict in fish shell's code repo.
Dino for XMPP "just works". Gajim for XMPP would just work, if I could get the port to support the current version. The package/port of Gajim is a few releases behind the current release. Normally, not such a big deal, except there's a database change between those versions, so the packaged version of gajim doesn't understand the copy of data from my prior setup (which is running the latest release). I'm still compiling the latest gajim to work with OpenBSD. My intention is to send a patch to the gajim package maintainer. Also, I hate python, so that isn't helping progress. Random thought: why hasn't anyone written a modern XMPP client in Go or Rust? Oh yeah, because everyone uses phones now and has zero thoughts about saving their history.
There is no Signal Desktop, or SimpleX Desktop, or Wire Desktop for OpenBSD. I'm working on compiling the latter two, since Signal isn't really open source. Why do I want this? For easy of chatting with a real keyboard and chat archiving purposes. I hate mobile phones (yes, both android and ios but that's an old story). Conversely, I'm on too many chat systems and should just simplify to the one true secure chat, XMPP. And previously. However, getting everyone else to move to my preferences is more work than I have time to give.
Another program I'm missing is Fractal for Matrix. It's written in rust and for GTK4. It compiles, but crashes soon after start. I'm still debugging it. It "just works" in FreeBSD and Arch. There appear to be zero Matrix clients in OpenBSD. The Element web interface works, but then again, it's not something I have locally with history archives. And, the obvious, someone else is hosting my chats.
Another oddity I encountered was during installation. I have 2 NVMe drives in the desktop, one for the OS and the other for my home directory (aka my data). I tried multiple times to get the installer to auto-layout the filesystem without a /home. I want it to use the full 1TB OS drive, but it would only do it with /home included. It provides the most space to /home as well. Removing /home on the OS drive, and trying to re-size everything manually didn't work. I tried to layout my own filesystems, but I couldn't get that to work either. If I'm going to fight with fdisk and partitions on install, I could just use Arch Linux. I even tried the horrible on / (root) filesystem for the entire OS drive. But clearly something UEFI didn't like my layout. If I stick with OpenBSD as my daily driver for the long run, I'll have to wipe/reinstall the OS drive layout and fix it. Right now, I'm not using the full capacity of the drive. This is wholly on me to figure it out.
Here's the raw drive:
Disk: sd1 Usable LBA: 34 to 2000409230 [2000409264 Sectors] #: type [ start: size ] 0: EFI Sys [ 64: 532480 ] 1: OpenBSD [ 532544: 1999876687]
And the filesystem layout:
Filesystem 512-blocks Used Avail Capacity Mounted on
/dev/sd1a 2018844 397608 1520296 21% /
/dev/sd1d 8114940 118464 7590732 2% /tmp
/dev/sd1f 60934744 4479900 53408108 8% /usr
/dev/sd1g 2018844 673444 1244460 36% /usr/X11R6
/dev/sd1h 40614428 16445388 22138320 43% /usr/local
/dev/sd1k 12179004 4 11570052 1% /usr/obj
/dev/sd1j 6082908 4 5778760 1% /usr/src
/dev/sd1e 128972756 129868 122394252 1% /var
As expected, the upgrade from OpenBSD 7.5 to 7.6 was flawless. What is in OpenBSD "just works". It's all these odd things I use that don't work well. If FreeBSD 14.2 doesn't support my hardware, I'll have to stick with OpenBSD for the time being. Again, it works, just a few rough edges for me so far.
And then, we come to the more difficult programs to live without. Publii, which publishes this blog and my main site. I'm slowly working on converting everything to Zola, but that's a much, much larger migration.
And finally, in the spirit of simplicity, I gave up on office suites. Using LaTeX is amazingly much easier and faster for me than fighting with any office suite. Markdown to pandoc to PDF works pretty well, also. Lyx, TexStudio, and just editing LaTeX in any editor works great. Building the PDF is easy and it's vastly easier than fighting with office suites like OnlyOffice, LibreOffice, or OpenOffice.
All in all, OpenBSD "just works" but is missing some of my frequently used applications. A work in progress, as always.