FreeBSD

In my February retrospective I was lamenting the total enshitification of Linux as a whole. I mean the user-land was always plagued by it, which is why we never got the mythical year of the Linux desktop.

However, the Kernel itself has always managed to maintain a higher standard in respect to what was allowed to go in, and most importantly when it came to maintaining backwards compatibility at all cost.

Unfortunately, some sort of a rupture has manifested somewhere around 2014 or so, which cracked open the proverbial back-door, which then in turn led to outside influence, slowly but surely to start creeping in, and taking a tangible foothold; the fruits of which we are witnessing now. But, I am not one to cry over spilled milk too much. I like to leave professional victim-hood to those who have mastered this arcane art, far better than I ever will.

Anyway, I went on and installed FreeBSD in a virtual machine so that I can make an idea about how much hardship would I face, if and when I’d decide to jump ship.

I am in no rush of course, it definitely hasn’t gotten to that point just yet, but just like Jack Torrance, I also like to know who is buying my drinks well in advance.

Let’s start with an obligatory desktop screenshot in order to kick things off on the right foot.

If one doesn’t look too closely, might not be able to tell that this is not my usual daily driver Linux desktop. I was very surprised to find pretty much all the critical pieces of software that I need for my custom openbox based desktop environment.

Now, there are no applets for network manager and bluetooth. I am referring to nm-applet and blueman-applet, specifically. Is this really a humongous problem? Maybe, but in reality I have no way to tell just yet. Necessity is most definitely the mother of invention – as the saying goes around here.

Alright, what does this mean, or rather is this where the good news stops? Not really, no!

The first actual problematic thing of course is the matter of the shebang in shell scripts. And, my .dotfiles are built on the shoulders of shell scripts.

In BSD land, bash resides in /usr/local/bin rather than /bin. While one could just create a symbolic link the proper way to go about it of course would be change the shebang to something like this:

#!/usr/bin/env bash

echo "Hello World!"

However, this raises a fair and rather important question. How many my shell scripts use or need bash specific features? While I do not know the exact answer to that yet, my gut is telling me that probably not a great many. All that to say is that in most cases, the shebang could become /bin/sh instead.

#!/bin/sh

echo "Hello World!"

Retaining my muscle memory to pay attention to this will probably bit me in the backside for a short-while, but that’s a small price to pay. Who knows, maybe I’ll end up on Solaris? I kid, I kid.

Another thing that my .dotfiles rely on is creating aliases and so forth based on a friendly version of the current Linux distribution. As a direct result, I had to come up with a way to detect freebsd, which turned out to be easier than I expected.

$ grep '^NAME=' /etc/os-release | awk -F '=' '{ print tolower($2) }'

Once I figured this one out, then it was just a matter of using it. Take a look at the example below to see this in being used in action.

if [ "$DOT_OS" == "freebsd" ]; then
	alias qs='sudo pkg search'                            
	alias qi='sudo pkg install'
	alias qr='sudo pkg remove'
	alias qu='sudo pkg update'
	alias qd='sudo pkg upgrade'
fi

There are more subtle differences in behavior of certain tools in the user-land, which weren’t so obvious to me coming back after so many years.

One such case is pgrep which happens to be behave differently.

$ pgrep openbox
$ pgrep -a openbox
13666

And, now the same on Linux:

$ pgrep openbox
13666
$ pgrep -a openbox
13666 /usr/bin/openbox --startup /usr/lib/openbox/openbox-autostart OPENBOX

Definitely not end of the world or anything, but I still thought that I’d mention it.

Another such case is make not being GNU make compatible by default. Luckily, gmake is available as a standalone tool, but this most definitely caught me off guard at first.

Now let’s talk about the elephant in the room, which is the C/C++ compiler tool-chain. It is clang, which really shouldn’t surprise anyone, nor should it be the cause of any trouble at all.

$ cc --version
FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-18.1.6-0-g1118c2e05e67)
Target: x86_64-unknown-freebsd14.2
Thread model: posix
InstalledDir: /usr/bin

However, some tools seem to look for gcc rather than cc when trying to look-up and determine the default system compiler. Which is not a very wise or portable thing to do, but alas it is what it is. Such is life. This can generally be overcome by specifying CC=cc, which of course hinges on the fact that the tool will attempt to look-up the CC environment variable at least.

Naturally, gcc is available as well. It would be pretty crazy if it wasn’t, am I right?

$ gcc --version
gcc (FreeBSD Ports Collection) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

What about emscripten? It’s available out of the box as a port, but it’s one of those that you would probably build and/or install yourself in order to get the latest and greatest rather than rely on the version available through the package manager.

$ emcc --version
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.74-git
Copyright (C) 2014 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

That is as far as I got for the moment. I only dipped my toes a wee bit in the so called Linux binary compatibility and chroot-ing which of course is not a concept unique to BSD in particular.

But all that probably will warrant a dedicated post of its own in the future. All in all, it was a short and rather pleasant hit-and-run incursion and reminded me of trying out FreeBSD 5 in 2002 or so, on an ancient Pentium 1 running at a whopping 90Mhz with 32MB of RAM, and a 540MB HDD.

That was the only hardware that I had laying around to spare and experiment with. I totally wasn’t brave enough to add it into the sweet dual-boot mix, that I already had with Windows and Linux on my main desktop machine at the time.