The dead and the reborn BSDs

The BSDs, especially FreeBSD, NetBSD, OpenBSD, DragonFly BSD, are far from being dead. The problem is that they never targeted the desktop users, especially not the laptop users. Here’s what made me reconsider the BSD family one more time.

I shot at a pigeon and killed a crow ■ A few reads for starters ■ A bit of history ■ More memories, and some nostalgia ■ NomadBSD ■ GhostBSD ■ Some thoughts ■ Hope springs eternal (or so they say) ■ Bonus madness

I shot at a pigeon and killed a crow

It’s not this coda that made me think of the BSDs. At least, it wasn’t the only factor. When I complained that Debian 12 was released with FeatherPad 1.3.5, and that it got 1.4.1 in testing much later than EPEL released it for EL9 (MX got it almost immediately), I never thought of checking whether a newer version exists.

It does. And I learned about it when a random Google search led me to pkgsrc.se, which showed it in version 1.5.1. Only then I went upstream:

• 1.5.1 on April 29, 2024
• 1.5.0 on Feb. 17, 2024: “The Qt5 support is removed. After more than 2 years, when FeatherPad could be compiled against both Qt5 and Qt6, it was the time to say goodbye to Qt5. With this change, the legacy encodings are also dropped because Qt6 does not support them.”
• 1.4.1 on June 12, 2023
• 1.4.0 on April 18, 2023
• 1.3.5 on Jan. 8, 2023

I didn’t know that Qt6 was so radical. It looks like Qt5 supported a good deal of encodings, whereas Qt6 only supports Unicode and ISO-8859-1 (Latin-1). However, QTextCodec does convert from and to older encodings, so the developer of FeatherPad has chosen the lazy, easy way out, and he removed features from 1.5.0 onwards. Sigh.

Either way, I was surprised that the distros who come with KDE6 don’t include the Qt6 version of FeatherPad. Yes, it’s not part of KDE, but it’s almost as powerful as Kate, but smaller and faster. The Qt6 version of FeatherPad can only be found in Arch, Mageia Cauldron, OpenMandriva Rolling (and Cooker), openSUSE Tumbleweed (OSS), but not in Fedora, not even in Rawhide.

But I was reminded of packages and ports. And so, I started a (not so long) journey. But, before that, let me declare myself disillusioned by NetBSD’s pkgsrc system, similar to FreeBSD’s ports but aiming for a higher portability, because it only includes calibre at version 5.44.0, whereas the latest version is 7.13.0, which, sure enough, does exist in FreeBSD.

A few reads for starters

🟢 Rachel Kroll, recently enough: Paying a visit to planet BSD (April 29, 2022), with deceivingly shallow comments on Hacker News and on Lobsters. She was comparing FreeBSD 13.0-RELEASE, NetBSD 9.2, DragonFly BSD 6.2.1_REL and OpenBSD 7.1, but without giving names.

I’m going to list a bunch of things that are strange or just broken, but I’m not going to say which one it was. If you’ve used it, you might recognize it. Otherwise, eh.

🟢 Eh. A second read, Ruben Schade: Practical differences between FreeBSD and Linux (May 26, 2024):

The Internet is replete with SEO-optimised comparison sites that offer superficial summaries of LLM-generated data laundered from sites like Wikipedia, so I thought I’d address the comparison here with my own experiences running both in production.

All of these are completely factual, with absolutely no subjective invocations of personal experience, jokes, or silliness.

🟢 A 3rd one. Felix Palmen, in December 2020: Advocacy: Why I personally prefer FreeBSD over Linux:

So, GNU/Linux is a fine and widespread opensource Unix-like operating system with nowadays lots of support, even from commercial entities. Why would you even bother looking at alternatives?

Well, for me, as for many others, the issue was systemd.

…

But this was only what made me test FreeBSD. Let’s get to the actual advantages I found.

Among which:

With FreeBSD (and any other BSD, as far as I know), you can follow stable releases for the OS itself, that go through a classic release engineering process. Still, you can get ports and/or packages of third-party software from a “rolling release” repository. This gives you the best of both worlds. You can have the latest and greatest, bleeding-edge, applications on a well-tested and stable base system.

I don’t know of any GNU/Linux distribution following a similar scheme. If you know one, please tell me!

OK, maybe FreeBSD (is) Ahead Technically, and Liam Proven is free to appreciate NetBSD 10, but in the end, is any of the BSDs practical for the end-user who only uses laptops and desktops?

A bit of history

There was a time when I used to explore FreeBSD, despite my hopes being originally targeted towards NetBSD. Oh, I very much tried to like OpenBSD (because of the pufferfish!) for a long while, but eventually I got bored by Theo’s attachment to Spartanism. Take a look at FuguIta, the only OpenBSD-based LiveCD. It’s faithful to the OpenBSD principles, which mean that once you configure X, you’ll be greeted by twm. In 2024. (Since I love smart logos and mascots, I tried to find a desktop use to DragonFly BSD. I failed.)

Coming from Slackware, I found FreeBSD both different and familiar. I loved the text-based installers that work (and ncurses-based at that!), and both OSes had such great installers (for the time). I’m still puzzled as to why Arch can’t do that. None of the BSDs assist the user with the initial setup of X and desktop environments during installation, but I thought that Arch Linux should do it.

Decades ago, I was used to manually configure X by the means of xf86config or, later, xorgsetup. I was younger and I didn’t have ADHD. But such an approach is definitely anachronistic in 2024.

I found on the intarwebs a footprint from one time in 2008 when I was shocked that Xorg would simply ignore my manual configuration! (Back then, I was Béranger, not Ludditus.) Apparently, I should have added a certain option to xorg.conf.

But I also found a few tidbits from when I was quarreling with a FreeBSD developer, Dag-Erling Smørgrav (des). Not much of that time, but rather his corrections to something I wrote back April 13, 2007: The Sorry State of the Open Source Today. (Obviously, it did not age well, and many of the links are no longer valid.)

Here’s Dag’s first rebuttal. And a second one. A third one. And a last one. Nothing consequential. As for the mailing lists, forums, and whatnot, I’m afraid they did not survive. Neither did my so many posts from the past versions of the blog.

But hey, he was the first one to call me an idiot! I’m now entitled, 16 years later, to call everyone a retard, right?

So I had hard feelings regarding FreeBSD’s developers. Unfortunately, the current status of Linux is much worse than 17 years ago, and that’s not because in the meantime, about 500 distros have died (check with Distrowatch). It’s because Linux (the kernel). And Red Hat (GNOME 3/4x, systemd). And Wayland. And idiots.

More memories, and some nostalgia

There is a problem with those BSDs, nearly a quarter of a century into the third millennium. You see, at least since Ubuntu 4.10, which was 20 years ago, people are used to having live ISOs that allow them to evaluate an OS and its support of their hardware. The purpose? Either to help them know whether it would be a good fit for their needs or even to use it as is—to browse the Internet, write documents, whatever. Before that, only Knoppix did that; from that point onwards, almost everyone tried to do that.

We’re also four years into the Ventoy era, so you don’t have to assign an entire USB flash drive to a single version of a distro or OS. (There are still morons who recommend Balena Etcher or Rufus or whatnot when their distros are Ventoy-compatible.)

But the BSDs are not only enterprise-oriented; they’re completely out of the times. They never cared about live systems, and I don’t mean live CLI systems that can be used to install the OS. What I mean is live X sessions with Wi-Fi support and as much automatic hardware detection as possible!

And there is a good reason for that, beyond mere convenience. It’s not that all OSes should be as simple to install and get working as Windows has always been. It’s not that people shouldn’t learn how an OS works. The BSD family “doesn’t need no stupid users,” right? But let’s put it this way: which one of the two following cases makes more sense?

1. One hundred thousand users install an OS. Each of them needs to spend 8 hours with post-install configuration, tinkering, fiddling, digging, learning, hacking, and cursing. Total wasted time: 800,000 man-hours, or more than 91 man-years of wasted life. If we only count working time, 800,000 working hours divided by 2,000 working hours a year makes 400 man-years of lost work time.
2. Three developers and twenty testers spend one month (176 hours) each developing and testing a thorough installer that covers most post-install tasks, including the setup of X, Wi-Fi, and BT. The users would need zero extra time for that. Total spent time: about 4,000 man-hours, or 2 man-years of spent work time!

Developing a live ISO with X and a desktop environment (Wi-Fi and all) is a different matter, but it would pay off in several ways, including much more consistent feedback from the increased user base.

Not in BSD land. I still remember Jibbed, the one and only NetBSD Live CD. It died in 2016, after having announced their version based on NetBSD 7.0.

What I’m mourning, though, is the memory of the two “FreeBSD distros” that tried to make some sort of Ubuntu out of it: DesktopBSD and PC-BSD.

I’m not sure why their website had a squeezed logo. It used to look better:

The longer-lived one:

For symmetry:

Some explanations are needed. With either of them, you could have an X-based desktop in a few minutes, no hacking required. Then, of course, if you wanted to install them, the installer was also a GUI.

DesktopBSD (Wikipedia, Distrowatch, SF) was mostly the effort of Peter Hoffer to create a Live FreeBSD with KDE3. By version 2.0 aka DesktopBSD Next, with the help of Ovidiu Angelescu (which in the meantime seems to have joined GhostBSD), DesktopBSD managed to add LXDE, GNOME and Lumina to the arsenal, and OctoPkg to the show (which is now used in NomadBSD).

DesktopBSD was just “live FreeBSD + all the stuff that makes it an easy installable desktop environment”; it could have become a success, but the lack of manpower (I guess) killed it.

PC-BSD was a different kind of beast. The only correct Wikipedia page is in Bosnian. Distrowatch redirects to TrueNAS, which has absolutely NOTHING in common with PC-BSD, but it’s offered by iXSystems, which once sponsored PC-BSD. Wikipedia redirects to TrueOS, which is also stupid because it’s just not the same thing!

The last true PC-BSD release was 10.3, in 2016, in which the installer was also offering Lumina (since 9.0, also GNOME, LXDE, and XFCE, in addition to KDE). The last true-to its-spirit release was 8.2 Hubble, in 2011, using KDE 4.5.5. The founder and the last one to take care of it was Kris Moore from iXSystems.

The truly revolutionary concept that PC-BSD came with was their .PBI set of packages that included all the libraries needed to run the program. They were akin to Flatpaks, but back then people compared them to Microsoft’s .MSI. Flatpaks got invented while PC-BSD was moribund…

Here’s Dedoimedo with a review of PC-BSD 7.1 Galileo, and here’s a video review of the same release that shows the PBI installer. From the latter, I stole this screenshot for you:

Prior to version 9.0, the .PBIs were downloaded from pbiDIR. Then, this was replaced by AppCafe, which looked like this (source), only to be later embedded in the control panel (the 2nd screenshot here):

Of course, I was against those .PBI files. A waste of space and whatnot. While I could, I held hopes that DesktopBSD would be revived and gain momentum. But both “FreeBSD distros” died.

And dead they stayed. Or did they? Are there any worthwhile successors? This is what I have examined lately.

NomadBSD

One of the two major live systems based on FreeBSD is NomadBSD. Unfortunately, it’s a persistent live system, which means it cannot be Ventoy-compatible, and you should dedicate it an entire flash drive. Of the three users’ reviews on Distrowatch for the latest version 140r, two are 10/10, and one is 1/10. From that last one, I’ll agree with this simple fact: “The OctoPkg application is essentially useless.”

I took nomadbsd-140R-20240126.amd64.ufs.img.lzma (German server), and I sacrificed a Samsung FIT Plus 64GB for the purpose of this experiment.

I first tried it on my Acer TravelMate P645 from 2016, the one for which they screwed the kernel (for the sake of P648/P658) so that Linux cannot sense anymore that I inserted a jack in order to use external speakers. Well, guess what? NomadBSD (FreeBSD, actually) had no problem with that! The output went wherever I wanted it to go!

The only problem: the mic couldn’t be detected. I don’t know what the checkbox does in the DSBMixer, but I couldn’t make it work. On the other hand, the webcam just worked! But with no microphone, that doesn’t help much.

Then, I noticed that it cannot mount exFAT flash drives:

It’s a known issue since 2022, why is it still there? All I had to do:

sudo pkg install fusefs-exfat

Note that the devices can be mounted automatically, if desired:

What bothered me next? The brightness set to 100%. This is the default when the OS doesn’t decide otherwise, and when the laptop’s brightness keys are not handled.

As I noticed about three years ago, LXQt has a specialized tool for that, called lxqt-config-brightness. All you have to do is this:

sudo pkg install lxqt-config

You won’t get any launcher in XFCE’s menu, but you can run either lxqt-config-brightness directly, or lxqt-config.

A bug that one can notice in the above screenshot is that, even with opacity set to 100%, windows can be partially translucent, for a reason of their own.

Then, as another display bug (and it’s Intel), I’d like to draw your attention to this gray stripe that appeared at the bottom of the screen. When it shows up, it’s there to stay for the rest of your session:

As a side note, there is another way to change the brightness:

xrandr --output eDP-1 --brightness 0.5

Obviously, that value can go from 0.1 to 1.0.

How about OctoPkg being as useless as beautiful?

Indeed, it’s 100% useless, because it can only be used to update the already installed packages, but not to install any new package! Yeah, do that thing to me sideways.

Next thing: the installed Firefox cannot display some websites as desired. I noticed that Outlook goes back to an extremely primitive look:

Of course, it’s firefox-esr, not the “proper” firefox. But Firefox ESR 115 works just fine in Linux! I found the answer to that later, while in GhostBSD. For now, let’s live with this takeaway: Firefox ESR in FreeBSD is crippled.

Fortunately, there is a “Linux Browser Installer GUI”! Unfortunately, it cannot install any Firefox, so I tried Chrome:

Apparently, to FreeBSD, Linux and Ubuntu are synonymous. There’s even a symlink from /compat/linux to /compat/ubuntu. WTF.

After having installed half of the Universe, (the Linux version of) Chrome failed to work. It crashed, then it tried to restore, then it crashed, and so on. It just couldn’t work!

Then I noticed that a lot of binaries didn’t work, such as the preinstalled image viewer and the preinstalled text editor:

nomad@NomadBSD$ viewnior 
ld-elf.so.1: /usr/local/lib/libgdk-x11-2.0.so.0: Undefined symbol "g_once_init_enter_pointer"
nomad@NomadBSD$ leafpad
ld-elf.so.1: /usr/local/lib/libgdk-x11-2.0.so.0: Undefined symbol "g_once_init_enter_pointer"

Now, you see, I couldn’t tell if this was broken from the beginning, or whether this happened after I installed something. Because this fucking stupid system could not be just a Live ISO, but a “live system with persistence” that works like an installed system, I cannot “reset” it. To do that, I’d had to download again that image and to dd it again to the flash drive. In contrast, any normal Live ISO would be like a newborn with each boot. If I wanted persistence, I’d have installed the OS, dammit!

Eventually, I noticed that Geany worked, but saving a 2 KB text file on the USB stick with exFAT took an eternity. WTF?!

If you liked the transparency of the “Linux Browser Installer GUI” window, here’s more: the right-click menus are not disabled; the gray on gray is the way the creator of this “distro” liked it!

I wonder how a disabled menu entry looks like…

At some point during my tests, I wanted to give it a try on my other Acer laptop, the one from 2023. It couldn’t get past this:

Of course the fucking system configuration has fucking changed, you moron! If I need a different flash drive for each laptop, that what the fuck is “nomad” in that? If your designer hadn’t insisted in making it an installation, a normal Live ISO would have worked! Probably. Possibly. Who could tell?

Either way, on the laptop on which it runs, in almost half of the time, I just cannot shut down or log out:

That’s a thing that happened in the past in XFCE sessions under some Linux distros. I tried the fixes recommended back then, to no avail. Brutality is the only one that works:

sudo shutdown -h now

Voilà. The glory of NomadBSD. Did it live up to its promises? Certainly not. Would I ever use it again? Only if I’m dead and I don’t realize it.

GhostBSD

It’s time for the other live FreeBSD, which is GhostBSD. Its reviews on Distrowatch are mixed, but I’d say it worked better in my experience than NomadBSD. Funny thing, one of its sponsors is iXsystems, those who backed PC-BSD many years ago.

Also, let’s note that Jesse Smith liked GhostBSD 23.10.1, with a few caveats:

The project does a great job of installing and configuring FreeBSD to be used as a desktop operating system. In this aspect, I cannot find fault with it. However, GhostBSD also inherits its parent’s weaknesses when it comes to desktop computing. Wireless drivers, running closed source applications such as Steam, and running less popular open source applications all run up against the limits of what FreeBSD is currently able to do when compared to Linux. GhostBSD is great if you have a wired network and want to run popular open source applications exclusively. It shines in this area. However, when stepping a little outside of this well-trodden ground the platform bumps up against its limitations.

For people who like FreeBSD and want to get up and running with a desktop quickly, GhostBSD is ideal. For people who enjoy Linux and stick to open source software exclusively, GhostBSD might be a good fit too. However, people who need non-free firmware, run closed-source applications, or who have exotic hardware might find GhostBSD limited compared to mainstream Linux distributions.

Even more surprisingly, Sean Davis (bluesabre), the Xubuntu technical lead, tried it end-2021, and found it to be “A different OS experience, but incredibly familiar.” In VMware Player, which is not telling anything about the hardware support.

So I got GhostBSD 24.04.1, the build from May 20, not the latest build which, annoyingly, has the same version and file name, only the SHA-256 is different. It is Ventoy-compatible (check here and here).

At the end of the first session on my old laptop, I forgot to unmount the flash drive used for screenshots, and somehow the shutdown failed to flush the data to the drive. WTF, FreeBSD?! OK, let’s do it again.

Starting as usual, with my 2016 Acer, the one whose output audio socket was broken by the Linux kernel team. Why should this dialog box be so wide?

Sure enough, the audio output just works when connected to external speakers:

Unfortunately, here too, the mic wasn’t working. The webcam did work.

Notice how, despite Wi-Fi being fully functional and with an excellent strength, the icon looks like it were terribly weak.

The huge assets of GhostBSD are its two GUI tools, “Update Manager” and “Software Station”:

Among its 34,456 packages, both Firefox and Firefox ESR were offered:

As the full Firefox 126 was installed, I’m not sure why the checkbox wasn’t selected.

As the “current” Firefox was displaying everything as expected, including Outlook Mail, I wanted to try the ESR version. I decided to use the CLI, hoping to learn something from that, and I was rewarded!

sudo pkg install firefox-esr
...
Message from firefox-esr-115.11.0_1,1:

--
## Missing features

Some features found on Windows, macOS and Linux are not implemented:

- Encrypted Media Extensions (requires Widevine CDM binary)
- Process sandboxing (requires Capsicum backend)
- Reduced memory usage (requires mozjemalloc)
- Crash Reporter (requires Google Breakpad and reproducible builds)
- WebVR (requires open source runtime)
- TCP fast open
- `about:networking#networkid` (requires link state notification)

## Audio backend

Currently used audio backend can be inspected on `about:support` page.
Supported backends and default probing order is as follows:
- `pulse-rust` if `pulseaudio` package is installed (PULSEAUDIO option)
- `jack` if `jackit` package is installed (JACK option)
- `sndio` if `sndio` package is installed (SNDIO option)
- `alsa` if `alsa-lib` package is installed (ALSA option)
- `oss` (always available)
To force a specific backend open `about:config` page and create
`media.cubeb.backend` preference.

Microphone selection only works in `oss`, `pulse-rust` backends.
Other backends are limited to `default` which is usually `/dev/dsp`,
so use virtual_oss to reroute microphones from non-default devices.

## Gamepad API

Requires evdev(4) joystick support. On FreeBSD 13 and later enable hgame(4)
while older versions can use sysutils/iichid or multimedia/webcamd.

## smb:// issues
Network group, machine, and share browsing does not work correctly.

## sftp://
Only sftp access using public key authentication works. To easily
setup public key authentication to `remote_host`:

    $ ssh-keygen
    $ cat ~/.ssh/id_rsa.pub | ssh remote_host "cat >> .ssh/authorized_keys"

The SSH server on `remote_host` must allow pub key authentication.

Ça s’explique, alors. I wonder how the “normal” Firefox isn’t crippled.

Oh, ESR being as described before, it’s a terrible choice for FreeBSD:

But let’s install stuff from the Software Station, shall we? Say, Calibre:

Oh, 7.11 isn’t the last one. What if I tried to build 7.13 from ports? (It’s uglier here.)

Then I got this error:

make: "/usr/ports/Mk/bsd.port.mk" line 1177: Unable to determine OS version. Either define OSVERSION, install /usr/include/sys/param.h or define SRC_BASE.

This forum thread is partially misleading. What do they mean by “I would not recommend you to use ports unless you know what you do”? Get lost! As for “also make sure to use https://github.com/ghostbsd/ghostbsd-ports,” get lost too, because there is absolutely no guidance on how to use the GhostBSD mixed ports from Git, whereas the standard FreeBSD ports can be used by anyone! As this came from Eric Turgeon, the founder of GhostBSD and working at iXsystems, it left me disappointed.

The real fix is elementary:

sudo pkg install os-generic-userland-devtools

Unfortunately, building Calibre takes too long, and the OS is already in the RAM, the filesystem is in the RAM, it might run out of space, so I canceled it eventually. But it can be done.

I forgot about the mounting of USB drives. Unlike with NomadBSD, GhostBSD doesn’t lack the exFAT support. What it lacks is a functioning automount! I mean, it’s installed, but it doesn’t work. I got it working this way:

sudo pkg install -fy automount
sudo service devd restart

I still can’t understand why automount needed to be reinstalled, but it’s the only thing that made it work!

For the brightness, you know the drill: install lxqt-config, which will not show up in the menus:

Strange enough, if only lxqt-config is installed, launching lxqt-config will lead to an empty window! Only lxqt-config-brightness works. (In NomadBSD both worked.) But I didn’t want to install portions of LXQt I didn’t need.

LibreOffice 24.2.3.2, you said? (24.2.4.2 just entered the ports on July 1, but we have this package for now.) Oh well, it’s hidden among 117 localizations:

The FreeBSD people had to have their own idiots. You see, their philosophy is that you have to have the localization prefixed to the package if you want to install it by name only! The following two commands are equivalent:

pkg install editors/libreoffice-ca
pkg install ca-libreoffice

Somebody must’ve fallen on his head when he was a kid. Idiocies aside, LibreOffice runs fine:

What else? Oh, the tiny fonts! (Dedoimedo, where art thou?) Scaling in MATE means 100% or 200%, so the only workaround is to change the DPI for text from 96 upwards.

Getting to the newer laptop:

• Wi-Fi & BT: unsupported, because MT7663. I used TP-LINK’s UE300 Ethernet adapter, and it worked.
• The audio output worked, the mike didn’t. The webcam did.
• Obviously, no brightness keys, no volume keys, etc. It’s a laptop, and FreeBSD isn’t for laptops.

An attempt at a bottom line: It’s not unusable. It’s pretty much OK. Once installed, maybe the mike can be fixed. 

If there is a spiritual successor to DesktopBSD and PC-BSD, then it’s GhostBSD, except that it doesn’t come with KDE, which is a shame.

Some thoughts

Coming from some recent frustrations with Linux, it’s worth emphasizing this aspect:

With its packages and ports, FreeBSD doesn’t necessarily get stuck with obsolete software, even when using -RELEASE and not -STABLE or -CURRENT. That’s because if the “quarterly” base system updates are only minor and the binary packages aren’t updated to the last version, there are also the ports. One can switch from “quarterly” to the “latest” branch of the ports, thus being able to build the latest packages while the base system remains unaffected (the kernel, system libraries, and core utilities). Moreover, regardless of whether you’re using the “quarterly” or “latest” ports branches, -RELEASE remains -RELEASE, if this is what you settled for. That’s a smart philosophy; I wish Linux had it, and not just in those immutable distros.

Alas, the downsides of FreeBSD remain. Will a proprietary VPN that comes as a Linux binary work via the Linux emulation? The Linuxulator is not magic, you know; quite the contrary: “We currently claim compatibility with Linux 3.2.0.” And how about the performance of such a VPN? Then, are the programs running through WINE slower on FreeBSD compared to Linux? That might very well be the case. And will the laptop-specific hardware ever be properly supported?

Questions, questions, questions.

Hope springs eternal (or so they say)

If it weren’t taken from Alexander Pope’s poem “An Essay on Man” (1733-1734), specifically from “Hope springs eternal in the human breast,” and well-established, it should have read “Hope springs eternally,” because this is about how hope springs, and a verb would require an adverb, hence “eternally.” But then, “Think different” and “You’re holding it wrong” have also changed the language. No “-ly” these days. But I digress.

I want to believe in the future of the BSDs as OSes for the desktop. Most realistically, of FreeBSD. By itself or via projects such as GhostBSD, which currently seems the closest to a solid live ISO that can be installed.

There must be a solution for when Linux becomes completely and utterly unusable, because of bloat, bugs, and madness. We’re approaching that threshold.

Maybe, beyond the official FreeBSD Handbook, I should take another look at Absolute FreeBSD, now in its 3rd edition, end-2018. I’m pretty sure that most of its contents will remain valid for years to come. It’s a good book. I owned in print the 1st edition of Absolute OpenBSD, and I wasn’t impressed. It never got beyond the 2nd edition, 2013. Meh.

The problem is that it’s not easy to believe. It’s not enough to want to. I’ve tried to believe in God in the past. I failed. I tried to start smoking, like, 20 times. That didn’t work either.

I also tried my chance with the BSDs in the past, and I have just revisited them.

They’re not there yet. If ever. While Linux is supported by Intel, IBM (Red Hat), Google, AMD, and many others, and enterprise-grade support (Red Hat, SUSE, Canonical) helps with the market share, FreeBSD only has the backup of, like, Juniper Networks, NetApp, Netflix, and that’s for servers. Slim chances for that to change.

Bonus madness: a Chimera

I couldn’t let this without a comment. Here’s the supreme madness: Linux plus FreeBSD userland and some weird design decisions, all in Chimera Linux! Non-GNU, mind you.

Distrwatch has added Chimera Linux to their waiting list in October 2021. It’s still awaiting.

The very short version: “Chimera Linux is a distribution which uses the Linux kernel and FreeBSD userland. The system is built entirely with the Clang/LLVM compiler.”

The website is pretty informative, but I was puzzled as to its color palette. These guys seem to like colors in this range: Purple Heart, Terra Cotta, Medium Orchid, Light Mulberry. Nothing wrong with that.

So:

Chimera comes with a novel userland setup based on FreeBSD core tools (replacing coreutils and related projects like findutils, diffutils, sed or grep; read our FAQ for details about why).

The FreeBSD tools were chosen for their high quality code and solid feature set. However, Chimera does not aim to replicate the FreeBSD experience on Linux in general, instead having its own choices and workflows.

The LLVM/Clang suite provides the system toolchain (clang, lld) as well as runtime parts (compiler-rt, libunwind, libc++). The C library is provided by musl, patched to use LLVM’s (also used e.g. in Android and Fuchsia) Scudo allocator for performance as well as security.

This means Chimera is not a GNU/Linux system, as it utilizes neither GNU utilities, nor GNU libc, nor GNU toolchain. However, the project is not anti-GNU/GPL, and its userland choice is primarily technical. Users are generally free to use whichever software they like.

They seem to care about hardening:

Chimera’s package collection is more strongly hardened than usual, utilizing multiple techniques as needed/allowed, including common ones such as stack canaries and PIE as well as less common ones such as a subset of UBSan and CFI.

This is also enabled by our different tooling choices; the BSD userland is easier to harden, the LLVM toolchain provides the methods, and the rest is a matter of how it’s put together. Relatedly, Chimera is entirely compiled with Link-Time Optimization thanks for Clang ThinLTO (which mitigates the burden on our infrastructure), which reduces binary size, improves performance, and allows certain security hardening methods to be effective.

Then, this is what they consider to be “clean and consistent”:

The system does not insist on legacy cruft and since it’s a new system, it can afford to start over. That is also reflected in its software choices, preferring modern solutions such as Wayland and PipeWire.

…

We are also putting a lot of effort into writing fresh low-level plumbing. For example, Chimera comes with first-class and built-in support for user services and other things dependent on session tracking (such as a shared session bus), implemented from scratch thanks to our Turnstile project, finally bringing functionality previously only available on distributions using systemd. This is being implemented in a vendor-independent manner so that other distributions can adopt it.

Proper service management infrastructure is a major overall goal. For all intents and purposes we aim to provide infrastructure that can rival systemd in terms of practicality but with a less problematic implementation. Most non-systemd distributions have been largely ignoring this aspect to say the least, which is now finally getting fixed.

Chimera is not a “minimalist” system. It wants to be simple and grokkable, but also practical and unassuming. It can be made pretty small or pretty large, it does not try to emulate anything or hold onto old ways for no reason, rejects reactionary tendencies, and tends to be opinionated in various ways.

Uh. With sort of packages and ports:

Chimera uses binary packaging. The choice of package manager is apk-tools, known from Alpine Linux. Chimera is not a fork of Alpine, and uses the next-generation version of apk-tools, known as APKv3, being the first distribution to practically deploy it at this scale.

To build the binary packages, it uses a custom, written-from-scratch infrastructure called cports, with a build system called cbuild, written in Python. It is designed to be strict and correct, while minimizing the maintenance cost and allowing it to be managed with a small number of maintainers. Best practices are enforced via aggressive linting and a strict sandbox. The system is also very fast, improving build speeds (by not spending time in cbuild pointlessly) and reducing reliance on caching.

All cbuild builds are done in a minimal, reproducible container. This is implemented with Linux namespaces and is a part of the sandbox strategy.

Chimera has nothing to do with Void:

If Chimera build templates and process seem suspiciously similar to Void Linux’s xbps-src, cbuild originally started as a rewrite of xbps-src to attempt to eliminate its various issues, and the main developer/founder of Chimera also worked on Void Linux. However, no actual code is shared with xbps-src.

It’s also unrelated to Alpine:

Besides using the same user-side package manager (apk-tools), Chimera is unrelated to Alpine. The version of apk-tools it uses is also different, and the source packaging system as well as all actual packaging are written from scratch.

Obviously, it’s also unrelated to ChimeraOS, originally GamerOS.

What is the project’s take on systemd?

The short answer is “it depends”.

The long answer is that as an init system and service manager, it has been a net functional improvement for Linux, as while it might not have come up with anything particularly new, it did bring various things such as service supervision by default and user services to Linux in one package that distros could adopt. Until systemd, there wasn’t anything else that would really do the trick (djbware and stuff derived from djbware does not count, as it’s lacking too much stuff that even various hacked together rc implementations on top of sysvinit added eventually). Other solutions such as dinit/s6 did not exist at the time. Most distros were using various shell-script-based rc systems, which did not supervise their services, which both added extra complexity to the daemons (because they need to be able to daemonize themselves, typically with the double-fork and setsid approach) and made the system less resilient (because it is impossible to robustly track daemonized processes, so the service manager could not e.g. properly restart them, and in case of a daemon crash, they were prone to scenarios such as another process taking over the original daemon’s PID, with the service manager still “tracking” the old PID via pidfile). Additionally, the shell infrastructure around init scripts can hardly be called simple.

However, as a whole, the implementation of systemd is rather messy, and now comes with a lot of unrelated components which are nevertheless all tied together with the same libraries and build system and impossible to isolate. Those unrelated components tend to be a hit and miss, with some of them being potentially interesting, and others outright poorly thought out.

Additionally, systemd is written to deliberately (ab)use every single non-portable extension under the sun, making it poorly portable not only to non-Linux systems, but also to various Linux distributions, unless said distribution is based on the mainstream software stack. That would make it a hard sell for Chimera. …

That’s why one of the goals in Chimera is to implement the actual useful systemd functionality, but independently and in our own way, without the shortcomings.

Another side of the coin is the so-called “systemd-free community”, which tends to spread a lot of misconceptions and frankly deranged opinions that end up hurting any sort of positive effort. Chimera as a project denounces such people, and is explicitly not a part of this community. Such people should also not view Chimera as some sort of haven, because it is not. The project is explicitly anti-elitist and aims to find constructive solutions.

Ouch. Mamma mia. So, why use a BSD-based userland anyway?

While coreutils may seem lightweight enough to not cause any issues already, there are some specific reasons the system uses a BSD-derived userland. The primary one is probably that the code of the BSD versions is overall much cleaner and easier to read. There are no cursed components such as gnulib, the codebase is leaner, and more aligned with the project’s goals.

Other reasons include helping the goal of improving software portability, as using a different userland tends to expose a lot of assumptions in various codebases, as well as improving bootstrappability and additional convenience; the core userland tools are not just coreutils, but also a lot of tools around that (findutils, grep, sed, and so on) and some of those actually already introduce undesired dependencies into the bootstrap path. In Chimera, all those tools are neatly wrapped in a single package that depends on very little, while providing pretty much all functionality one needs to get things done. This means we are not only replacing the GNU utilities, but we also have a replacement for things such as Busybox at the same time, re-using the same environment to power our initramfs and other components.

Being a single lightweight package, it makes hardening the userland a lot easier too. It is possible to compile the Chimera userland with CFI and other techniques very easily, and it applies to all of the tools. With GNU tools trying to using these tends to fail, and addressing the issues becomes harder because it is out of our control and involves a much chunkier codebase where more can go wrong and where things are harder to track down.

Relatedly, it also helps cbuild/cports a lot. The way cbuild works, you are building everything in a little container that dependencies are installed into. Our BSD-ported utilities also replace some core portions of util-linux, which need to be present in the build containers. The util-linux package normally depends on things such as PAM and udev. That means if we were to use GNU utilities, we’d need a separate, stripped-down build of util-linux just for the containers, because everything that’s in the build container as well as every dependency of it is a part of the bootstrap process. That would mean either having to make this stripped-down version coexist with the full version installed in target systems, or make them conflict. For example Void Linux does the latter, and it creates trouble for instance whenever something wants to run a test suite and the test suite has a dependency on some missing util-linux tool. In Chimera, there is no need for util-linux anywhere in the base container or its bootstrap path, and such templates can simply add util-linux to their checkdepends.

…

However, using an alternative userland is not and never was the project’s primary selling point. The userland tools are a means to an end, and the end is creating a well-rounded, general-purpose, practical operating system that addresses various real issues that Linux distributions tend to have. The tools simply exist to help us get there eventually.

Too much blah-blah. The decision is an interesting one, and there are technical advantages, but I’m not a fan of the way they explained it.

The cherry on the cake: Why choose GNOME as the default desktop?

There are two major desktops that provide a properly functional Wayland implementation, and that is GNOME and KDE. Compared to KDE, GNOME is much smaller and simpler to build (and less time/resource-consuming), and its Wayland support feels more stable. Additionally, it has consistent and well-defined UX. GNOME is also more portable than KDE, primarily due to relying on WebKit rather than a Chromium derivative as its web browser engine of choice. The founder of Chimera also uses GNOME as their daily driver.

Other desktops usually do not meet the Wayland requirement, and tend to have UI/UX that is way more all over the place. … The default desktop in Chimera should be comprehensive and unassuming.

Of course, users are free to choose any desktop they desire. If one is not available in the package collection, patches are welcome.

Oh, fuck. Fuck, fuck, fuck! How can they be productive in GNOME?! Chimera Linux seems to have five developers: q66 (the founder), psykose, deathmist, zdykstra, triallax. Take a look at their Github accounts and projects. They seem quite hard-working people, interested in experimenting with a lot of stuff. Zoomers, on the younger side. Possibly unsure about the relation between their biological sex and their assumed gender identity. Either way, Chimera Linux surely is a one-of-a-kind project, innovative, and highly experimental at that.

So I gave it a try to chimera-linux-x86_64-LIVE-20240421-gnome.iso. Only 1 GB, and definitely minimalistic.

Standard GNOME crap:

Wayland, what else?

Given that their package management is non-standard, it doesn’t integrate in GNOME Software, which sees exactly nothing:

Once you install the Flathub support, it will see the Flatpaks and Flatpaks only:

Using the CLI, you can add repos and install packages:

I am not familiar with the supreme pile of excrement that is GNOME, but it seems there is a bug here. Have you noticed the Text Editor icon in the dock (Dash)? Well, its icon is not here:

Nor is it here:

But the app does exist, and it works!

WTF. If GNOME can be so fucked up in such a minimal setup, then I just can’t. If I remove the icon from the dock, how am I supposed to be able to access it, if it’s not in that fucking GNOME Shell list of apps?

😲 Wait! I forgot to tell you about the installer in Chimera Linux! I mean, there is no installer. The installation has to be done by hand, à la Arch, except that you can do it in a GNOME Wayland session. Here’s how to do it, plus a few post-install steps. Some major topics are documented, such as Network, Xorg, GNOME. If you have no wired Ethernet and the Wi-Fi doesn’t work post-install, I smell trouble. Also, how are you supposed to “apk add networkmanager” if your network doesn’t work? (“Please insert floppy…”)

Of course, I understand that some people might like it. Those who swear by macOS and iOS and who believe in the Tooth Fairy. Take this guy, who spent A Month on Chimera Linux last year. Read his review; it’s informative.

Strange enough, the reviewer normally prefers the Awesome tiling window manager. Strange choice for someone who since 2017 is in the search of an alternative to macOS, who tried some Linux distros (OMFG, he liked Files aka Nautilus! How can people live with only two views, and no compact file list view?), then he really moved his desktop PC to FreeBSD with GNOME3. Good for him. Not for his laptop, yet.

He obviously couldn’t settle for Windows and, after Two Years on Linux, he embraced Awesome (which required a lot of customization to be able to adjust the brightness and the volume from the keyboard, and many more things much more complex than that), and switched back from FreeBSD to Arch Linux. Among the reasons: ZFS is not better on FreeBSD than on Linux; jails are terrible compared to Docker; in FreeBSD there are bugs with supplied patches that sit unmerged for months; Electron doesn’t support FreeBSD. And two highly subjective ones: “I met and was exposed to a large community doing all kinds of interesting things with Linux.” and “The reaction to the improved FreeBSD Code of Conduct last year by some of the community deeply troubled me.”

OK, he tried Void Linux (musl) on the Huawei MateBook X Pro and he plans “to keep using it as the primary OS on this laptop.” Still, he did spend a month on Chimera Linux, and “It is currently my aim to use Chimera on my desktop computer at some point in future too. That probably won’t be until after the beta phase is reached though.”

To me, Chimera Linux is pure lunacy: a mixed bag of good intentions, interesting technical choices, and dumb ones. But what do I know? I can’t even use GNOME; I’m not smart enough or moron enough for that.

Maybe Chimera is for exactly such people: coming from macOS, but finding both Awesome and GNOME, err, awesome. People who, after having ditched all desktop environments for a tiling window manager (“My problem with KDE is the aesthetic. KDE and Qt really don’t seem to align with me. … Things like menus attached to windows, icons on buttons, icons on menu items, Application launcher menu (“Start” button), bottom task bar, and apply buttons in configuration dialogs all feel very foreign to my Mac using past.”), have the guts to create a site called Desktop Institute (now defunct), with the subtitle “Researching a better desktop environment.”

Schizophrenic software developers need operating systems and window managers written by other schizophrenic software developers.

We, the rest of the planet, are not so much into sharing the same needs.