Small BSD experiment

I started out with NetBSD because it had a new release out not that long ago and along with OpenBSD it seemed to have a character and identity. Plus it featured favorably in a few blog posts, especially with regards to running on some obscure hardware. I don't really have obscure hardware on hand, but portability is a laudable goal regardless.

NetBSD was pretty easy to get running. The installer is quick, simple and friendly. I did mess up one install to the VM a bit by accidentally omitting the package tools like the binary package manager tool pkgin, but I sorted that out quickly.

On the VM I did struggle a bit to get X11 running consistently, since it seems that NetBSD didn't exactly agree with the virtualized graphics hardware, so I had to do some init magic to boot the system up into a VESA graphics mode so I could get better resolution out of it and to get X11 to not freeze up.

Once I had the early issues figured out, I was able to start using NetBSD pretty well. The default X11 session is definitely on the old-school side being based on CTWM but overall functional. I have used more minimal WMs before, so the workflow wasn't entirely alien to me. Having to reload CTWM for new applications to show up in the app launcher was a bit odd but not a major headache. In general NetBSD feels a bit on the primitive or simple side, but things seemed generally well documented and there was a sense of adventure to things.

For example, while NetBSD has a mechanism to upgrade the system from one binary release to another, it seems that some mid-release system upgrades only land into a point release after a while. So, if the base system has a security issue, you are adviced to upgrade from sources. This isn't really a difficult process and there are tools like sysbuild and sysupgrade that make it easier for you. But I have to say, it has been a long time since I have built a kernel, much less an entire userland but it worked out decently well. I think I accidentally screwed it up only once and that was in a VM, so no real loss there.

Most of the stuff I needed was also packaged well-enough in pkgsrc, the NetBSD port collection, although some packages versions were a little on the old side. But technically in order to be productive, I just need Firefox and Emacs plus some programming tools and all of that was easily available, although in NetBSD 10.1 binary packages only Emacs 29 was available. Apparently current non-quarterly pkgsrc now has 30 as well, so presumably that's coming soon.

However, things weren't entirely smooth. When I installed onto my laptop, I was a little surprised to see wi-fi working, but sadly it's not entirely stable. After a while it seems the driver does some funny stuff and the connection is lost until the wi-fi interface is reactivated, possibly with a restart of wpa_supplicant as well. The speeds were also pretty bad, since apparently the iwm driver only supports older wi-fi access technologies. I hope that will eventually catch up, but I don't know how much maintenance the wi-fi stack receives on NetBSD.

Audio, while working, also had some quirks. As long as you are just doing basic things, it seems that things kind of just work. I was able to get Firefox to play some YouTube videos and I got audio output. However, when I plugged in a USB soundcard, the audio suddenly gained noticeable latency and I couldn't figure out how to resolve that. If I moved to NetBSD full-time I would also run into trouble with livestreaming. All of the BSDs still base their audio stack around the OSS sound system, which is neat from novelty perspective but a bit of a pain otherwise. A good chunk of AV software, such as OBS Studio, are based more on audio servers like PulseAudio or Pipewire these days and although OBS has gained some OSS audio support recently, the version in pkgsrc only supports PulseAudio. You can, presumably, get PulseAudio running on NetBSD, but no matter what I did I could not get it to work in any meaningful way.

There are tricks that you can do with ffmpeg to do similar things that you could do with OBS, so it's not like streaming the like wouldn't be possible. Apparently NetBSD's flavor of OSS even has special pseudo-devices that can echo back audio, so you can use them sort of like a PulseAudio monitor device. However, this level of trickery is something I haven't had to deal with since early 2010s on Linux and while casting dark magicks is sometimes entertaining in small doses, it becomes less fun when you are actually relying on it day-to-day.

But even though NetBSD isn't necessarily something I could daily drive, I had fun with it. The system seems to have an identity and a mission and it seems to be being developed by level-headed individuals. And it seems like when you do things in the intended ways, stuff in the base system synergizes quite well. I had a surprising amount of fun playing with the built-in web server, which is intended to be launched as a per-request process by inetd. Definitely not the fastest thing to serve web content, but the setup and configuration were dead-simple.

At the end of the day I decided to move onto other things, since NetBSD seemed like it might not be quite there and I wanted to see if the other contenders had more to offer.

OpenBSD is the security oriented BSD. Their mission seems to be providing an OS that minimizes security risks via some OpenBSD-specific mechanisms like additional system calls that allow restricting application behavior without having to build a separate sandbox around them. It all sounds kind of cool.

And it definitely was the most secure operating system experience I had. When I attempted installation into a VM, the install process crashed partway through with a kernel panic.

The most secure operating system is one that will never allow malicious code to be run, so OpenBSD inarguably lived up to that standard. Well done on keeping up with the bit.

Next.

FreeBSD's main claims to fame seem to be three-fold: it has the best modern hardware support of the BSDs, it allows ZFS to be run without the associated difficulties of ZoL and it has jails. No FreeBSD user has been able to clearly explain why jails are the best thing since sliced bread, especially with the world having standardized on OCI containers, but regardless they love to talk up jails so it bears mentioning here as well.

I was able to get FreeBSD working in a VM, but I found the default experience a bit bare-bones and the documentation implied a fair bit of configuration and tuning to get everything I would want up to a reasonable standard, especially since the default X11 session based on TWM was quite horrendous, so I went looking for a shortcut.

FreeBSD is kind of like the Arch or Debian of the BSD world in that there are distros based off of it. One of them, GhostBSD, is intended as a desktop-ready spin on FreeBSD. If we wanted to make an uncharitable comparison, you could think of FreeBSD as Arch Linux and GhostBSD as Manjaro. It utilizes the FreeBSD ports tree as its base source of packages, but maintains a separate version of it that gets synchronized on a separate schedule, they build their own packages from it and they also add some packages of their own into the mix. Also, GhostBSD is pre-configured to use the Mate desktop environment and runs stuff like PulseAudio out of the box.

When I installed GhostBSD onto my laptop, it ran mostly fine and without issues, although somewhat similar wi-fi issues reared their heads again. Apparently the FreeBSD project has finally managed to port iwlwifi with modern wi-fi access tech from Linux, so FreeBSD 14.3 might be able to support more stable and faster wi-fi. Sadly GhostBSD at the time of writing is still based on 14.2, so I didn't get to test that in practice.

GhostBSD was ultimately what I ended up loading up on my laptop for the week at the summer cottage and it basically worked fine. Main thing I noticed was that obviously DRM'd content wouldn't run without Widevine and Widevine isn't really supported on the BSDs. FreeBSD world has some hacks to run a browser with Linux emulation to get it working, but I couldn't really be bothered. At the end of the day I don't think I can fault the OS for stupid decisions by streaming sites and their clunky DRM that doesn't even solve any real problems.

I was able to also load up the system with basically all the software I would need in order to even do my own livestreaming and such. The version of OBS in the ports also supports OSS and OpenBSD's sndio, so technically using PulseAudio wouldn't really even be necessary. Similar to NetBSD, FreeBSD has a tool called virtual_oss which allows creating virtual loopback devices for audio capture. It could still be easier and I don't entirely understand why they couldn't just include a monitor device by default, but I was able to plug it into OBS via the OSS Audio source plugin.

There were some issues along the way though, which mainly came down to the ports tree. It seems that FreeBSD ports quality varies a lot and some ports seem to be bit-rotting pretty fast. I wanted to install OpenMW on my laptop to do a bit of Morrowind, but there was no binary package for it in GhostBSD. When I attempted to build it from source, I realized why. Apparently that port just broke some point earlier this year and couldn't even build without patches and once the patches were applied, it apparently fails to run due to some OpenAL incompatibility.

Another similar case was yamagi-quake2. The binary package exists, but has no video output. Apparently the port was made somewhat clumsily and some of the video-related modules were not being found and therefore the game launches headlessly. Apparently the port maintainer had either forgotten they were the maintainer or somehow the port got dumped on someone else, because they started their reply to a bug report with something akin to "apparently I am the maintainer". Some ports also seem to make some pretty weird decisions around their dependencies. When I attempted to install Luanti, it wanted me to uninstall OBS Studio and a few other packages, because it insisted on LuaJIT support to come from openresty-luajit instead of luajit-devel. I don't entirely understand why those two packages exist separately and I understand even less why a block game would insist on LuaJIT from an OpenResty package. Anyway, I solved that problem by making a copy of the Luanti port, swapping the package dependency and then building it myself. It worked fine.

But at the end of the day I think the biggest problem I had with the FreeBSD ecosystem was that it didn't seem to have anything very interesting going on. It was close enough to Linux to be just sort of ordinary, while also then stumbling around the finish line to just make it a sort of "we have Linux at home" experience.

All of the BSDs I tried successfully seem to have varying levels of identity trouble in the modern operating system space. They simultaneously seem to want to maintain their own culture and customs, but at the same time are not big or influential enough to really extend that comprehensively.

The audio story of the BSDs is a good example of this tragedy. All of the BSDs want to be based around some variant of OSS, but in order to get the wider open source software ecosystem to work properly, they need to either patch it up or port in stuff like PulseAudio. But the stuff that uses PulseAudio doesn't cleanly interact with the stuff that uses OSS, so as a user you either only depend on the base use case of "it produces audio output" or you sprinkle in hacks like running stuff via padsp to make OSS apps visible to PulseAudio. And things are also not helped by the BSDs going their separate ways with audio. OpenBSD uses sndio which at a quick browse seems to just be a less featureful and more obscure PulseAudio, the pseudo-device stuff between NetBSD and FreeBSD works seemingly very differently. So, while there probably is some kind of a base level of common functionality, anything more advanced becomes platform-specific.

And in terms of hardware support and such, it seems all of the BSDs are now just chasing after Linux. FreeBSD in particular seems to port large chunks of the Linux kernel in order to get better hardware support going.

While the BSDs do still seem to innovate in the OS space for some things, it seems like generally those things are pretty niche. And even the much hyped jails of FreeBSD seem to be making way for more ordinary OCI tech with the porting of Podman.

Things are probably not helped by a seemingly loud contingent of users in the BSD communities that seem to have a fundamental belief of making sure things don't really change and a conspiracy-theorist mindset towards newer init systems and display tech. Especially on the FreeBSD and GhostBSD side, I was quite annoyed by how much uncritical hyping of XLibre was taking place. Anybody with eyes and brains should be able to recognize that the project will not go anywhere and the upstream will migrate to Wayland over time. NetBSD and FreeBSD have some level of early Wayland support, but I wouldn't be surprised at all to see the respective userbases to be vehemontly against moving in that direction.

So, all of that puts BSDs into a kind of an awkward position. There is a sort of tug-of-war happening where the upstream ecosystem is clearly moving onwards while there is likely a substantial user base that has bought into all sorts of anti-Linux conspiracy theories or just have a general mentality around refusal of change. And while the BSDs do collaborate and port over stuff from each other, they are still different enough between each other that many solutions end up being very custom and fragmented.

If I was approaching the BSDs purely as a Linux user aiming to find a better system than what I already have, I don't think I would find one. Despite how much hate some people throw at systemd, what is there in the BSDs isn't honestly super special in any way. Messing with init happens pretty rarely for me and despite running things quite stock, the fragility of the init still reared its head with some services launching without internet access and then complaining that they were not able to connect to the internet. On systemd that service would have just waited for the network.target and not be so whiny. And the X11 experience is just sort of quaint, it even still has the good old tearing issues that seem to elude fixes that I remember from years back.

So, experimenting with the BSDs hasn't made me a convert for sure. However, I did find it kind of fun in the adventure and learning kind of way.

After I got back from the summer cottage, I ended up wiping the GhostBSD install from my laptop and put NetBSD back in. Toying around with NetBSD was more exciting than the Linux-lite experience of GhostBSD, which was basically the major decider. It's not a system that I would take with me as a main daily driver if I needed actual work to be done, but as a secondary system to play with it works quite well. I do wish the wi-fi trouble got fixed eventually, so that there would be less restarting of the network stack to get packets flowing, but it is what it is. If I have it running in a kind of server-mode on my desk while hooked to ethernet, it should work well enough.

I think one thing that came out of this is that I will probably pay a bit more attention to what sort of change, if any, will take place in the BSD world over the coming years. The Linux world is going through some changes and I think some of those changes will eventually impact the BSD world in a major way, so I am curious how each of the operating systems decides to tackle them.

If I had to guess, OpenBSD is probably in the most comfortable position, since they already own their own X11 server and are probably more than happy to keep coming up with their own solutions. So, maybe the BSDs will just huddle up closer together. We'll see I suppose.