I apologise for being a sceptic but I find this hard to believe:
But I found myself grating with the unending and pervasive issues [on Linux] with Wi-Fi, audio, GPUs etc.
Isn’t this exactly why people go for Ubuntu or Fedora? Also, just recently there was a post https://lobste.rs/s/15zleo/why_laptop_support_why_now_freebsd_s, which pretty much sounded like an acknowledgement that there is a lot to be done in the BSD world to catch up to Linux, not even mentioning Win/macOS.
Having said that, I wish more cloud/VPS providers and tutorial writers look at / focus on / promote OpenBSD because of its excellent security track record.
[This will be ranty, over-simplified and most importantly highly subjective. I have no interest in converting anyone to OpenBSD or any other BSD. Instead I want to add my experiences to this anyways subjective conversation. I hope this gives an idea of what could be meant by the quoted sentence - or how I interpret it. I use Arch Linux most of the time, so I am also not trying to drive you away from Linux or something]
I didn’t interpret this in terms of (just) hardware support. Hardware support isn’t really about “getting in the way” in my opinion. In most situations it’s either there or isn’t there or more generically it works or it doesn’t. Linux clearly has a broader hardware support than Linux - at least when it comes to laptop/desktop systems.
Wifi: Nothing in Linux land comes remotely close to having hostname.if(5) and just having simple configuration lines like join <network> wpakey <key>. From Networkmanager to wpa_supplicant to all the ways of configuring a dhcp client and weird, buggy UIs for them are a great big mess. If you are lucky and never have any needs it might work. But the configuration tools are still weird and complicated. And if you start having troubles it’s an even bigger mess to debug.
Audio: sndio is great, just works. On Linux even basic things like both connecting headphones (audio jack) switching to them and them being connected when turning on never worked out of the box. Not on Ubuntu, not on Fedora, not on Arch. Mics are just as messy. Pulseaudio is messy, and while Pipewire improved stuff it somehow does weird stuff when watching YouTube videos. Out of the box it either randomly freezes monitor outputs, it struggles with processing outputs or inputs, it freezes the video in Firefox, despite continuing. I don’t know why Audio on Linux seems to progressively getting worse. If everyone was using the current iteration of OSS it would likely be fine. And for non-rolling distros every other upgrade messes things up in a new way. Every other OS seems to be doing a better job the Linux here.
Graphics: Let’s skip the hybrid GPU topic to make this shorter. There are uncountable issues that one might fix via xorg and driver options. Most of the time one issue is traded for another. So many “known issues” with “just use this and that hack”. To be fair. GPU drivers are a mess across platforms (maybe not macOS?). However usually things don’t degrade. On Linux every distro finds a way to get rid of stuff working. From tearing, to performance issues, to not even being able to start X.org. And so many times the official solution is either switching to Wayland or switching to X.org. I thought just going the route of Intel GPUs would fix mentioned issues, but while it is a lot better, it just doesn’t happen. Having to fiddle with graphics in 2024 just feels wrong. On OpenBSD stuff that works keeps working.
I feel like I’m quite experienced. I have been using Linux for two decades. I can program, I will start up strace or a debugger, if I wanna get down to the root cause. But it feels like Linux is a bit how javascript frameworks. There is a working solution that has that one annoyance, but instead of working on improving it a new framework focusing on fixing that annoyance is being created. Everyone is happy… until they notice that the new way basically makes all the stuff that worked well on the previous solution is cumbersome. Then there is back and forth trolling. If you don’t like the new solution you are dumb, etc. The new solution is the future. Then it settles and finally a new version emerges. The mentioned Pulseaudio/Anti Pulseaudio -> Pipewire example is perfect. Now people only have problems with microphones and watching videos.
I wouldn’t conflate FreeBSD and OpenBSD in that regard. FreeBSD has no sndio by default. Even though you can totally switch to it through the ports systems and I’ve done so. It’s pretty amazing that you can do that. I wished there was something like that in Linux land. Anyways, it’s not there per default, also it’s in port, so third party. There is no hostname.if. I think the default way of doing Wifi is the same as on Linux. For graphics cards. I don’t know what the status is today, but OpenBSD over the last decade or so has been quicker at adding for example support for intel graphics. FreeBSD is a bit slower about adding such things somehow. Also slower than DragonFly for example.
I think the reason is that the FreeBSD culture is different. I think there are more OpenBSD users/devs running OpenBSD on their day to day laptop than FreeBSD people running FreeBSD on their day to day laptop. The whole Gaming on OpenBSD community is a good example on this. Arguably FreeBSD is the better gaming OS. Overall better performance, support for WINE (OpenBSD simly doesn’t have that), official NVIDIA drivers, etc. Yet some projects like fnaify (which evidently is now indierunner?) make running Windows games potentially more convenient than using WINE.
The BSDs are often viewed as “OpenBSD for Routers”, “NetBSD for the toaster” and “FreeBSD for everything else”, often overlooking that they aren’t distros, but independent general purpose OSs. And if you look at macOS also being a BSD, do grep -v, look at how they have dtrace, about how the way you run Docker is through xhyve, which is based of FreeBSD’s bhyve, etc. it really is another BSD. But aside from them never being a good gaming platform one wouldn’t consider it to be a bad desktop/laptop OS. Don’t get me wrong though. OpenBSD, NetBSD, FreeBSD are all not great desktop OSs. My argument here is about how “the BSDs” is a strange grouping. Because the main thing they have in common today is maybe name, maybe license preferences. Even they way closer to FreeBSD DragonFly, today has very different properties. They are father apart than let’s say Android and Debian in many regards.
On Linux even basic things like both connecting headphones (audio jack) switching to them and them being connected when turning on never worked out of the box.
This just works with pipewire. If it doesn’t for you, open an issue with pipewire. They’re very responsive.
If everyone was using the current iteration of OSS it would likely be fine.
Pipewire goes way beyond what’s possible with OSS. While it may not matter much for most people, there’s no other OS right now which comes close to the minimal latency, custom routed connection graph and trivial codec/sampling changes.
FWIW a lot of people who use one of the BSDs now haven’t used Linux too much in a while, so they just haven’t ran into Pipewire much.
If one’s memories about sound on Linux are from around, say, 2010 or so up until Pipewire age, it’s not surprising that they only remember it as a raging dumpsterfire. I think the only thing that worked worse than what Linux had during that decade was sticking two fingers from your left hand in the audio port and then, based on how it tingled, hitting a really thin membrane with a really tiny hammer really really fast with your other hand. The audio quality would’ve been worse, both because of the inefficient actuation mechanism and because of the highly non-linear signal propagation media, but it would’ve been a lot more reliable than PulseAudio up until 2015 or so, and still a lot easier to troubleshoot after that.
That matches my recollection of PulseAudio from that era, especially on laptop audio hardware. On desktops, with careful sound card selection, it wasn’t that awful.
In contrast, I think I only ever used PA on ThinkPads and it worked perfectly. I mean, at the time this was kinda the default hardware, if it was not the current year’s model.
PulseAudio improved a lot after, how do I put it… after maintainership was taken over by more community-minded people. Unfortunately, there are more fundamental things that no amount of actually looking at punctual bugs can fix.
I also used PA on ThinkPad hardware and some of my favourite bugs, which I never managed to troubleshoot conclusively, were:
If I plugged an HDMI monitor with speakers and left it plugged in when suspending, PulseAudio would sometimes select it as the default output when resuming from sleep and the laptop’s sound card would be gone. Restarting PulseAudio sometimes helped, but not always – sometimes it would reliably detect the sound card, but refuse to unmute it, and the only way to fix it then was to reboot the bloody thing. Resuming from sleep when the monitor was not plugged in worked fine.
I could sometimes get PulseAudio to crash by plugging in a USB DAC along with my HDMI monitor. Plugging the monitor first, and then the DAC seemed to work every time. Plugging the DAC, then the monitor, got it to crash. I actually spent a few hours trying to debug this, figuring that fixing sink detection on completely unfamiliar code was probably hopeless but surely a crash would be simpler. I was completely wrong.
Disconnecting Bluetooth headphones worked reliably, but I could not unmute the laptop’s speakers afterwards.
I had a particular USB microphone which, if plugged in, would get PulseAudio to crash after a few minutes. I don’t recall the details now (something about sample rate, some config tweaks fixed it) but it took forever to figure out, because it crashed late enough that I didn’t realise it had anything to do with the microphone.
One source of PA’s many problems was that, for years, it was written and maintained in terms of well, it works on my machine, you must be doing something wrong. So the layer of resilience (maybe a bit of a fancy word for proper locking and basic sanity checks on data structures, hardware input/output state etc., but anyway) and debugging features that ensures a smooth transition from “works on my machine” to “works on everyone’s machine” was worked in gradually, pretty late, and rather unevenly.
So if your machine happened to be just right, you could go through it without a hitch (I had one of those, too, a hand-me-down old Toshiba, of all things). If it didn’t, apulse helped for a while, but that was about it.
Fun, although the first one sounds like my #1 Discord-on-Windows issue. Sometimes randomly, sometimes after it updates itself everything looks good, but I don’t hear anything because it’s blasting into the nirvana of my screen and I have to manually reset.
Yeah I’m not defending it per se, it’s just apparently been unbroken on Debian and Ubuntu during this time I spoke of, I never really had a large amount of Linux machines with GUI at the same time.
I up-voted this comment, but wanted to add a “me too”. reezer’s experience is exactly my own.
I enjoy trying different operating systems on my home desktop and laptop. I’ve tried all the major ones and some more obscure ones. I make it my everything-OS for a month or a year, to give it a real go.
OpenBSD has always been the “JUST WORKS” one. The simplest, easiest one to recognize or config my hardware/network/sound/video/USB-stuff, etc.
OpenBSD usually seems to do, in a few config lines, what other operating systems do in a much more complicated way.
Wifi: Nothing in Linux land comes remotely close to having hostname.if(5) and just having simple configuration lines like join wpakey . From Networkmanager to wpa_supplicant to all the ways of configuring a dhcp client and weird, buggy UIs for them are a great big mess.
From a quick glance through the man page it seems that openbsd’s solution though doesn’t have any support for PEAP / MSCHAPv2 / all the enterprise and academic wifi schemes.
I’m curious with the pipewire freezing video thing, never encountered that across Arch Linux, Fedora, Ubuntu, Debian Bookworm on a variety of hardware
From a quick glance through the man page it seems that openbsd’s solution though doesn’t have any support for PEAP / MSCHAPv2 / all the enterprise and academic wifi schemes.
Never used MSCHAPv2. And from what I read Windows 11 also doesn’t support it because nobody should use it. But yeah, there you have to fall back to wpa_supplicant.
I’m curious with the pipewire freezing video thing, never encountered that across Arch Linux, Fedora, Ubuntu, Debian Bookworm on a variety of hardware
Here I am encountering that across various hardware, with various distributions. It’s not all the same though. Different systems, different issues. I much prefer the video freezing over the screen.
OpenBSD has vastly better Wi-Fi support compared to FreeBSD. If your chipset is supported, you get fast speeds and reliable Wi-Fi. And the config is through the superior ifconfig tool.
there was a post which pretty much sounded like an acknowledgement that there is a lot to be done in the BSD world to catch up to Linux
That post described FreeBSD, whereas this thread describes OpenBSD. I understand why people refer to “the BSD world” or similar given that these operating systems have a common ancestry, but the different systems diverged around 30 years ago when they all failed to support anything resembling today’s GPUs and WiFi chipsets.
Today, it’s often unhelpful to talk about “the BSD world”, “the BSDs”, or “*BSD” from a technical perspective although culturally they have some similarity, community overlap, and shared conferences. The different BSD-based operating systems share code, some of which finds its way into Linux, Windows, and MacOS, but they also have their own kernel interfaces, development processes and technical focus.
Note that macOS and iOS are BSDs. The XNU kernel began as a single-server Mach kernel with BSD (back when there was only one BSD) as the server providing the POSIX support. With OS X 10.0, the old BSD code was updated with FreeBSD 4.x and then 5.x code. Things like kqueue came from there. The MAC framework that’s used to implement the iOS and macOS sandboxing abstraction came from the (Apple-funded) TrustedBSD project, which implemented the same code for XNU and FreeBSD. Other things, such as the audio and graphics subsystems, were completely different. The Darwin libc was updated from FreeBSD’s at the same time, but later diverged. The POSIX2008 extended locale APIs originated in Darwin’s libc (as an extension to a GNU extension), for example, and the FreeBSD implementation is independent. Similarly, most of the core command-line utilities were forked from FreeBSD, but grew some nice extensions (such as consistently using -h and -H for binary or decimal units), but didn’t always get improvements from upstream.
NetBSD and OpenBSD diverged from FreeBSD further in the past than Darwin, though Darwin has had a lot more full-time engineers working on it and so the divergence is greater.
Overall I agree with the article and it’s pretty accurate with the exception of this paragraph:
Whereas Linux might have some files in ‘usr’, others in ‘bin’, others still in ‘.local’ or even just dumping random files in your ‘$HOME’ directory. OpenBSD has been much more consistent: config files are in ‘.config’, programs you install are in ‘/usr/bin’, it’s refreshing that my first guess of where a file is located is usually correct.
Programs installed are sent to the /usr/local prefix (so /usr/local/bin instead of /usr/bin). Also I’ve never encountered this issue on Linux distros where files are dumped randomly in $HOME unless it’s configuration for applications (some might use .config or .local or even just .appname and this won’t differ from Linux to BSD)
Also I’ve never encountered this issue on Linux distros where files are dumped randomly in $HOME unless it’s configuration for applications
The ~/.config thing, in particular, is just part of the XDG base directory spec, and it’s entirely up to the applications to follow it (or not). Maybe some packages in ports have patches that enable it and haven’t made it upstream, but I really doubt it. If an application dumps things all over $HOME on Linux, it’ll most likely dump them all over $HOME on OpenBSD, too.
Other than that the only time I’ve ended up with files randomly scattered around $HOME was when I passed the wrong --prefix to configure but that’s a completely cross-platform mishap :-).
Yep, and unless OpenBSD just hasn’t patched the exact software I use from ports, the same software on OpenBSD does the same thing. I can only assume the author hasn’t used OpenBSD as much as he has the Linux distro yet, as he must have only installed software which uses the XDG spec (or newer versions of the same software that have been updated to follow XDG if he was on an LTS distro before?).
I built an OpenBSD VM to be my bastion server recently, and I was very impressed with how straightforward it was to strip it down to the bare necessities.
I apologise for being a sceptic but I find this hard to believe:
Isn’t this exactly why people go for Ubuntu or Fedora? Also, just recently there was a post https://lobste.rs/s/15zleo/why_laptop_support_why_now_freebsd_s, which pretty much sounded like an acknowledgement that there is a lot to be done in the BSD world to catch up to Linux, not even mentioning Win/macOS.
Having said that, I wish more cloud/VPS providers and tutorial writers look at / focus on / promote OpenBSD because of its excellent security track record.
[This will be ranty, over-simplified and most importantly highly subjective. I have no interest in converting anyone to OpenBSD or any other BSD. Instead I want to add my experiences to this anyways subjective conversation. I hope this gives an idea of what could be meant by the quoted sentence - or how I interpret it. I use Arch Linux most of the time, so I am also not trying to drive you away from Linux or something]
I didn’t interpret this in terms of (just) hardware support. Hardware support isn’t really about “getting in the way” in my opinion. In most situations it’s either there or isn’t there or more generically it works or it doesn’t. Linux clearly has a broader hardware support than Linux - at least when it comes to laptop/desktop systems.
join <network> wpakey <key>. From Networkmanager to wpa_supplicant to all the ways of configuring a dhcp client and weird, buggy UIs for them are a great big mess. If you are lucky and never have any needs it might work. But the configuration tools are still weird and complicated. And if you start having troubles it’s an even bigger mess to debug.I feel like I’m quite experienced. I have been using Linux for two decades. I can program, I will start up strace or a debugger, if I wanna get down to the root cause. But it feels like Linux is a bit how javascript frameworks. There is a working solution that has that one annoyance, but instead of working on improving it a new framework focusing on fixing that annoyance is being created. Everyone is happy… until they notice that the new way basically makes all the stuff that worked well on the previous solution is cumbersome. Then there is back and forth trolling. If you don’t like the new solution you are dumb, etc. The new solution is the future. Then it settles and finally a new version emerges. The mentioned Pulseaudio/Anti Pulseaudio -> Pipewire example is perfect. Now people only have problems with microphones and watching videos.
I wouldn’t conflate FreeBSD and OpenBSD in that regard. FreeBSD has no sndio by default. Even though you can totally switch to it through the ports systems and I’ve done so. It’s pretty amazing that you can do that. I wished there was something like that in Linux land. Anyways, it’s not there per default, also it’s in port, so third party. There is no hostname.if. I think the default way of doing Wifi is the same as on Linux. For graphics cards. I don’t know what the status is today, but OpenBSD over the last decade or so has been quicker at adding for example support for intel graphics. FreeBSD is a bit slower about adding such things somehow. Also slower than DragonFly for example.
I think the reason is that the FreeBSD culture is different. I think there are more OpenBSD users/devs running OpenBSD on their day to day laptop than FreeBSD people running FreeBSD on their day to day laptop. The whole Gaming on OpenBSD community is a good example on this. Arguably FreeBSD is the better gaming OS. Overall better performance, support for WINE (OpenBSD simly doesn’t have that), official NVIDIA drivers, etc. Yet some projects like fnaify (which evidently is now indierunner?) make running Windows games potentially more convenient than using WINE.
The BSDs are often viewed as “OpenBSD for Routers”, “NetBSD for the toaster” and “FreeBSD for everything else”, often overlooking that they aren’t distros, but independent general purpose OSs. And if you look at macOS also being a BSD, do grep -v, look at how they have dtrace, about how the way you run Docker is through xhyve, which is based of FreeBSD’s bhyve, etc. it really is another BSD. But aside from them never being a good gaming platform one wouldn’t consider it to be a bad desktop/laptop OS. Don’t get me wrong though. OpenBSD, NetBSD, FreeBSD are all not great desktop OSs. My argument here is about how “the BSDs” is a strange grouping. Because the main thing they have in common today is maybe name, maybe license preferences. Even they way closer to FreeBSD DragonFly, today has very different properties. They are father apart than let’s say Android and Debian in many regards.
This just works with pipewire. If it doesn’t for you, open an issue with pipewire. They’re very responsive.
Pipewire goes way beyond what’s possible with OSS. While it may not matter much for most people, there’s no other OS right now which comes close to the minimal latency, custom routed connection graph and trivial codec/sampling changes.
FWIW a lot of people who use one of the BSDs now haven’t used Linux too much in a while, so they just haven’t ran into Pipewire much.
If one’s memories about sound on Linux are from around, say, 2010 or so up until Pipewire age, it’s not surprising that they only remember it as a raging dumpsterfire. I think the only thing that worked worse than what Linux had during that decade was sticking two fingers from your left hand in the audio port and then, based on how it tingled, hitting a really thin membrane with a really tiny hammer really really fast with your other hand. The audio quality would’ve been worse, both because of the inefficient actuation mechanism and because of the highly non-linear signal propagation media, but it would’ve been a lot more reliable than PulseAudio up until 2015 or so, and still a lot easier to troubleshoot after that.
That matches my recollection of PulseAudio from that era, especially on laptop audio hardware. On desktops, with careful sound card selection, it wasn’t that awful.
In contrast, I think I only ever used PA on ThinkPads and it worked perfectly. I mean, at the time this was kinda the default hardware, if it was not the current year’s model.
PulseAudio improved a lot after, how do I put it… after maintainership was taken over by more community-minded people. Unfortunately, there are more fundamental things that no amount of actually looking at punctual bugs can fix.
I also used PA on ThinkPad hardware and some of my favourite bugs, which I never managed to troubleshoot conclusively, were:
One source of PA’s many problems was that, for years, it was written and maintained in terms of well, it works on my machine, you must be doing something wrong. So the layer of resilience (maybe a bit of a fancy word for proper locking and basic sanity checks on data structures, hardware input/output state etc., but anyway) and debugging features that ensures a smooth transition from “works on my machine” to “works on everyone’s machine” was worked in gradually, pretty late, and rather unevenly.
So if your machine happened to be just right, you could go through it without a hitch (I had one of those, too, a hand-me-down old Toshiba, of all things). If it didn’t,
apulsehelped for a while, but that was about it.Fun, although the first one sounds like my #1 Discord-on-Windows issue. Sometimes randomly, sometimes after it updates itself everything looks good, but I don’t hear anything because it’s blasting into the nirvana of my screen and I have to manually reset.
Yeah I’m not defending it per se, it’s just apparently been unbroken on Debian and Ubuntu during this time I spoke of, I never really had a large amount of Linux machines with GUI at the same time.
I up-voted this comment, but wanted to add a “me too”. reezer’s experience is exactly my own.
I enjoy trying different operating systems on my home desktop and laptop. I’ve tried all the major ones and some more obscure ones. I make it my everything-OS for a month or a year, to give it a real go.
OpenBSD has always been the “JUST WORKS” one. The simplest, easiest one to recognize or config my hardware/network/sound/video/USB-stuff, etc.
OpenBSD usually seems to do, in a few config lines, what other operating systems do in a much more complicated way.
From a quick glance through the man page it seems that openbsd’s solution though doesn’t have any support for PEAP / MSCHAPv2 / all the enterprise and academic wifi schemes.
I’m curious with the pipewire freezing video thing, never encountered that across Arch Linux, Fedora, Ubuntu, Debian Bookworm on a variety of hardware
I’m using OpenBSD with Eduroam wifi, I needed to install wpa_supplicant, but it works, and was easier to debug that Eduroam on my android phone…
Never used MSCHAPv2. And from what I read Windows 11 also doesn’t support it because nobody should use it. But yeah, there you have to fall back to wpa_supplicant.
Here I am encountering that across various hardware, with various distributions. It’s not all the same though. Different systems, different issues. I much prefer the video freezing over the screen.
OpenBSD has vastly better Wi-Fi support compared to FreeBSD. If your chipset is supported, you get fast speeds and reliable Wi-Fi. And the config is through the superior ifconfig tool.
https://man.openbsd.org/man4/iwx.4
That post described FreeBSD, whereas this thread describes OpenBSD. I understand why people refer to “the BSD world” or similar given that these operating systems have a common ancestry, but the different systems diverged around 30 years ago when they all failed to support anything resembling today’s GPUs and WiFi chipsets.
Today, it’s often unhelpful to talk about “the BSD world”, “the BSDs”, or “*BSD” from a technical perspective although culturally they have some similarity, community overlap, and shared conferences. The different BSD-based operating systems share code, some of which finds its way into Linux, Windows, and MacOS, but they also have their own kernel interfaces, development processes and technical focus.
Note that macOS and iOS are BSDs. The XNU kernel began as a single-server Mach kernel with BSD (back when there was only one BSD) as the server providing the POSIX support. With OS X 10.0, the old BSD code was updated with FreeBSD 4.x and then 5.x code. Things like kqueue came from there. The MAC framework that’s used to implement the iOS and macOS sandboxing abstraction came from the (Apple-funded) TrustedBSD project, which implemented the same code for XNU and FreeBSD. Other things, such as the audio and graphics subsystems, were completely different. The Darwin libc was updated from FreeBSD’s at the same time, but later diverged. The POSIX2008 extended locale APIs originated in Darwin’s libc (as an extension to a GNU extension), for example, and the FreeBSD implementation is independent. Similarly, most of the core command-line utilities were forked from FreeBSD, but grew some nice extensions (such as consistently using
-hand-Hfor binary or decimal units), but didn’t always get improvements from upstream.NetBSD and OpenBSD diverged from FreeBSD further in the past than Darwin, though Darwin has had a lot more full-time engineers working on it and so the divergence is greater.
I’ve only used Thinkpads, but Ubuntu has been awesome on a 2013 X220 and a 2023 E14
I tried OpenSuSE and that was fine too.
Overall I agree with the article and it’s pretty accurate with the exception of this paragraph:
Programs installed are sent to the /usr/local prefix (so /usr/local/bin instead of /usr/bin). Also I’ve never encountered this issue on Linux distros where files are dumped randomly in $HOME unless it’s configuration for applications (some might use .config or .local or even just .appname and this won’t differ from Linux to BSD)
The ~/.config thing, in particular, is just part of the XDG base directory spec, and it’s entirely up to the applications to follow it (or not). Maybe some packages in ports have patches that enable it and haven’t made it upstream, but I really doubt it. If an application dumps things all over $HOME on Linux, it’ll most likely dump them all over $HOME on OpenBSD, too.
Other than that the only time I’ve ended up with files randomly scattered around $HOME was when I passed the wrong
--prefixtoconfigurebut that’s a completely cross-platform mishap :-).https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded
My point exactly (it’s configuration files for applications).
Yep, and unless OpenBSD just hasn’t patched the exact software I use from ports, the same software on OpenBSD does the same thing. I can only assume the author hasn’t used OpenBSD as much as he has the Linux distro yet, as he must have only installed software which uses the XDG spec (or newer versions of the same software that have been updated to follow XDG if he was on an LTS distro before?).
I built an OpenBSD VM to be my bastion server recently, and I was very impressed with how straightforward it was to strip it down to the bare necessities.