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 crowA few reads for startersA bit of historyMore memories, and some nostalgiaNomadBSDGhostBSDSome thoughtsHope springs eternal (or so they say)Bonus madnessGhostBSD revisited, part 1GhostBSD revisited, part 2: the revelationSpeaking of FreeBSD…

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, 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.


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 /usr/local/lib/ Undefined symbol "g_once_init_enter_pointer"
nomad@NomadBSD$ leafpad /usr/local/lib/ 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.


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/ | 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/" 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,” 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, you said? ( 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.

Solving the lack of hardware support before the year 2000

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.


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.

GhostBSD revisited, part 1

It was something that was still pestering me, so I decided to revisit GhostBSD. First, by reading.

I reread Liam Proven’s GhostBSD makes FreeBSD a little less frightening for the Linux loyal (Nov. 7, 2023), and took the occasion to read his FreeBSD 13.1 is out for everything from PowerPC to x86-64 (May 20, 2022).

From the FreeBSD 13.1 one:

Are you less than enthusiastic about the way modern Linux is evolving, with systemd and Wayland and Flatpak and containers everywhere? Then this could be the OS for you.

But saying that, get ready for a surprise. Installing FreeBSD is a little bit like installing Linux was in the 1990s. The installation process is text-based, and when it’s done, you should have a computer that can boot from its own hard disk, connect to the internet (preferably over a wired Ethernet connection), and give you a command prompt. And that’s it. After that, you’re on your own.

Linux is a native PC OS: it was first developed on x86 PCs, and only later ported to other architectures. It feels at home on a PC. It uses standard PC partition types, it happily co-exists with other OSes, it uses native screen resolutions and control keys and other things as a matter of course.

FreeBSD, like the other BSDs, is different. It is not native to the PC, and while it runs fine, it expects a substantial primary partition to itself, inside which it builds its own partitioning system. Its console runs in plain VGA mode, and simple things like Ctrl-left and Ctrl-right don’t work to edit the command line.

When you run Linux on a non-PC machine, such as a Raspberry Pi, it makes the computer act a bit like a PC. When you run FreeBSD on a PC, it makes a PC act a bit more like a Sun workstation or a DEC minicomputer.

For example, once FreeBSD is installed, you can mount Windows and Linux partitions if you wish, no problem. What you can’t do is put FreeBSD’s root file system in one PC partition, its home file system in a different PC partition and so on, as you can with virtually every normal Linux distro. FreeBSD does things its own way. If you want to put it on bare metal, our recommendations are: use a desktop, not a laptop; have a wired internet connection, not Wi-Fi; and dedicate the entire PC to FreeBSD, don’t try to dual-boot it with anything else. And as always, update the PC’s firmware before you start.

Some readers were keen to correct the author. E.g., “Your comments on partitioning are completely wrong.” Despite the many details, it was a bit confusing.

There was nothing stopping you using two or more MBR partitons for the same FreeBSD install. — FreeBSD’s built in partitioning scheme doesn’t have to be used.

You could easily install FreeBSD the same crappy way Linux is installed on MBR: assign a few MBR partitions to FreeBSD, and don’t use freebsds own partitioning within it.

You could also mix and match MBR partitions at will — the point is, you rarely saw it that way because it was a restriction.

OK, but can I use a separate SSD to host my /home that would survive between installations, like I do in Linix? I’m sure I can, but spreading those slices on several partitions risks being a nightmare.

Another one: “Adding a GUI is easy”:

Not true that you’re on your own installing a desktop environment.

In the FreeBSD world, this is simply separated from the OS installer, for good reasons. The basic text mode OS installer can literally be completed in a few minutes and if you’re building a headless server, that’s probably all you want before setting up your services.

To install a desktop environment (or a simple window manager if you prefer), just do the following after the OS is installed and booted:

  1. pkg install desktop-installer
  2. desktop-installer

Follow the instructions on the screen and you’ll soon have the desktop of your choice up and running. All the mainstream DEs (Cinamon, Gnome, KDE, Lumina, LXDE, LXQT, XFCE, etc.) are directly supported and there’s a custom option for installing any other DE/WM in the FreeBSD ports tree.

OTOH, in his FreeDOS and FreeBSD prove old code never dies, just gets nifty updates (July 2, 2024), Liam breaks the good news: FreeBSD 15 is supposed to feature a graphical installation program! The April 2024 Software Development Update mentions Pierre Pronchery as leading this project; he’s a Frenchman living in Germany, and a member of the Board of Directors for The NetBSD Foundation! (Couldn’t rather NetBSD have a GUI installer? He’s been developing for NetBSD since May 2012!)

Back to the article on GhostBSD 23.10.1, which ends this way:

FreeBSD is quite different from Linux, and even experienced Linux users will find themselves lost sometimes. … However, as vast sprawling modern subsystems such as systemd, snap, Wayland, and Flatpak take over more and more of Linux, FreeBSD offers a refuge where you will find traditional Unix sanity. And for now, GhostBSD is by far the easiest way to put it on a PC alongside some other operating systems.

On Reddit, Liam bothers to add interact with people on the unofficial r/freebsd. Say, here:

My point here is that a lot of elements of modern Linux are upsetting traditionalists — systemd, Wayland, GNOME >=3, Snap/Flatpak, and so on.

If someone used to be happy with Linux but is getting less so with the modern changes, FreeBSD is a refuge, but installing it is still way too much like Linux in the 1990s.

GhostBSD is an answer to that.

You have to understand (because I do) that Liam is a traditionalist person, with an emphasis on ergonomics. In his How tech went from free love to pay-per-day (July 2, 2024), he reacts in the comments section, e.g. to the Wayland mania:

That point being that the older version of KDE and the older display server offers the functionality a pro artist needs. Their greater point being that the newer KDE 6 on the newer Wayland does not yet offer this. In other words, its point is not that in 2024 it is finally ready. The real point here is that this already worked better in prior versions and the newer versions represent a serious degradation in functionality.

The greater point of linking to the blog post also seems to have gone over your head: that while you, like many many others before you, constantly berate FOSS users and FOSS for being inadequate and not ready and not competitive with paid-for proprietary “pro level” tools, in fact, that there are full time professional creative artists working with FOSS and making a living doing it.

This was the point of my earlier “you can’t buy software” article:

That vendor lock in happens as much in user minds as it does in file formats and other techie details. You reinforce the mistake made by the commenter that protested that the Ribbon is fine and it’s old and we should all get used to it and stop complaining.

It’s not about whether it’s a better UI. I gave a list of reasons why it’s worse, but that’s not the point.

The point is that it’s a nonstandard UI and a as such represents a new proprietary “standard” and that reinforces vendor lockin.

17 years into the infamous Ribbon, here’s another comment of his:

I could talk, at considerable length, about keyboard navigability, searchability by reading for those of us who are highly text-centric, avoidance of precision targeted clicking on graphical objects for those of us with moderately poor motor skills, about accessibility for users with real impairments such as no or very low vision, or perfectly good vision but poor motor control (for instance, thanks to Parkinson’s) leading to inability to precisely click, and many more carefully reasoned objections.

If you don’t have motor control or vision problems yet, don’t worry, the odds are that you will.

But that is criticising the specific design.

Let’s take a different view: the implementation.

Then I could move on to inflexibility. I turn off all Office app toolbars because I like text, and I use menus only, via keystrokes if possible. (It’s not possible on macOS, for instance.) But I also want to see the maximum amount of my work. This article was written in MS Word, in Outline mode. I want to see as much text as possible. That means more lines: bigger letters are counterproductive. That means I want screen height on a widescreen display. So, docks and panels and taskbars are on left and right, not at the top or bottom. Horizontal space is cheap. Vertical space is precious.

But I can’t move the Ribbon. It can’t work vertically. There is no option.

I want to see as many lines of my document as possible and nothing else taking vertical screen space. I will surrender a line to a title bar or status bar if I must, but not a big fat strip. That’s bad. That’s a horrible egregious waste of space.

But with this implementation, there is no option. I can hide it but that makes it even worse: I can only search it by interacting with it. I can read and memorise a menu tree of a hundred commands in a few days of use and cope with some options moving.

I can’t readily memorise a little tabbed icon grid. I have a fairly poor visual memory but an excellent textual one. Once upon a time I could close my eyes and tell you every entry and subentry on every menu and every dialog box in MS Word and MS Excel. I didn’t try to memorise them: I just used them a lot and it stuck. I knew exactly which dialog I wanted, which tab, and the alt-keys to get there.

This doesn’t work ribbons. As GJC points out, hotkeys still work, but not all of them, and I can’t browse through menus looking for the option that might have moved in one recent release. The specific hotkey for bigger or smaller text works, but not alt-o for fOrmat, F for font, alt-Y for stYle. What’s left is not useful for me. Taking 90% of the keyboard UI away and leaving a token tenth without the framework around it is no use. Do I mentally categorise menu commands vs hotkeys? No!

Once again, this UI discriminates unfairly against people with skills like mine. I’m not disabled but it’s a bad fit for my personal strengths. It may fit others well but remember that one size does not fit all.

But let’s move to a more general case still.

This is vendor lock in.

The commands for the MS Office don’t work in the LibreOffice ribbon-a-like. They don’t work in Notepad or Notepad++. They don’t work in macOS Text Edit. They don’t work in Kate or Gedit or Leafpad or Geany.

Menu trees work everywhere. The subset that’s applicable was standardised A THIRD OF A CENTURY AGO by IBM CUA and everyone still sticks to it more or less, but the Ribbon is ™© to Microsoft™ and it doesn’t work anywhere else. It would cost any other vendor that wanted to adopt it.

Well, enough of Liam.

GhostBSD revisited, part 2: the revelation

Back to our sheep, I tried, for a change, GhostBSD’s XFCE Community Edition, which worked about just as fine as the official MATE one, but didn’t shine in any particular way.

And an idea occurred to me. In the Live ISO session, I thought of this: 16 GB of RAM might be enough to allow me to install KDE and to give it a try! Why didn’t I consider this before?

Several official summary documentation pages can be found, but I’ll mention the most basic and straightforward ones:

  • about FreeBSD/Setup tells you to start with pkg install --quiet --yes kde5 plasma5-sddm-kcm sddm xorg. More generally, “To install the current official release, get ports or packages.”
  • The FreeBSD Handbook says, in Chapter 8, that you could use a metapackage (pkg install kde5), or install a minimal KDE (pkg install plasma5-plasma) that doesn’t even include Konsole (pkg install konsole).

I won’t enter into details. Fact is that I couldn’t find any of kde5, plasma5-plasma, x11/kde5, or x11/plasma5-plasma in GhostBSD’s packages!

Naïve as I was, I suspected a broken package. Occasionally, a port fails to build. KDE itself was occasionally broken in latest (see here and here), but not this time.

FreshPorts for x11/kde5 showed successfully built KDE 5.27.11/23.08.5 packages for both FreeBSD:14:quarterly and FreeBSD:14:latest (also for the upcoming FreeBSD:15:latest). WTF then?!

The explanation came from Eric Turgeon, the founder of GhostBSD, in a forum thread, in reply to a comment that summarizes the idea behind the FreeBSD packages (“latest” or “quarterly”). Let’s quote from that comment first:

  • FreeBSD ports are “rolling release”, which means they are constantly updated on the “main” branch, and a package repository called “latest” is constantly rebuilt from the main branch. If you use that repository, you will in most cases always have the newest versions of the software offered.
  • Every quarter, a new “snapshot” branch is created. Updates to main will only be “cherry-picked” there when they fix a security vulnerability or some other severe malfunction. A package repository called “quarterly” is built from that branch, and FreeBSD release versions come pre-configured to use that repository. This is meant for people who want to avoid larger package updates all the time, you’ll have these larger updates only 4 times a year (when the next snapshot branch is created).
  • Repositories are built for each supported FreeBSD release version, but they are built from the same ports tree, so no matter which FreeBSD version you use, you will get the same versions of software installed from ports/packages.
  • “Outdated” ports are possible for a lot of different reasons, being unmaintained is one of them, but as already mentioned, the vast majority of ports is actually maintained. [Other reasons skipped by me.]
  • In most cases, there’s no need to build anything yourself. Updates to the “main” branch of ports will be available as packages from the “latest” repository several days later. You’ll only have to build yourself when you either want to make use of build-time options (like options of individual ports or some setting in DEFAULT_VERSIONS) or you actually want to work on ports yourself. There are lots of possibilities to build ports, even just using make from within the ports tree. The most reliable and robust way though is to build your own package repository using ports-mgmt/poudriere.

And Eric’s addition:

Regarding GhostBSD, I build the packages from which contain all the same ports as plus our OS and GhostBSD specific ports. GhostBSD builds the OS packages from ports. GhostBSD ports tree is synced from FreeBSD ports once every week or 2.

Packages are built about every two weeks unless there are CVEs in the default set of packages. I try to stay on top of CVEs as much as possible. I also try to help when I can with MATE ports on the FreeBSD ports side.

To put it in simpler words: GhostBSD is for FreeBSD what Manjaro is for Arch, meaning that GhostBSD, for some unexplainable reason, DOES NOT use the already built FreeBSD packages, but its own rebuild of them! How stupid and useless is that?!

I’ll show you how stupid and harmful that is.

GhostBSD, and by this I mean Eric, doesn’t rebuild everything that FreeBSD builds. Eric doesn’t care about KDE, but he cares to build some other packages that normally people would build from ports (so this explains ghostbsd-ports). So you’ll find something like that:

So KDE is uninstallable in GhostBSD. Building from ports is nonsensical, as long as FreeBSD has those packages!

I tried the impossible, which, again, is like mixing Manjaro with Arch: I wanted to use FreeBSD’s repository instead of GhostBSD’s, or alongside it. In both cases, troubles arose.

Note that in GhostBSD, instead of the global /etc/pkg/FreeBSD.conf and your /usr/local/etc/pkg/repos/FreeBSD.conf addition (read this), you have /etc/pkg/GhostBSD.conf and /usr/local/etc/pkg/repos/GhostBSD.conf. Also, GhostBSD has signature_type: "pubkey", whereas FreeBSD has signature_type: "fingerprints", and you need to point to the correct signature, which was (I guess) not standard, so this was my modified /usr/local/etc/pkg/repos/GhostBSD.conf:

FreeBSD: {
  url: "${ABI}/latest",
  signature_type: "fingerprint",
  pubkey: "/usr/share/keys/pkg/trusted/",
  enabled: yes

Regardless of whether I was using both GhostBSD’s and FreeBSD’s repos or only FreeBSD’s, KDE couldn’t install because of this conflict:

pkg: kf6-kguiaddons-6.0.0 conflicts with kf5-kguiaddons-5.115.0 (installs files into the same place).
Problematic file: /usr/local/bin/kde-geo-uri-handler

I don’t understand why KDE5 tried to install kf6-kguiaddons-6.0.0. That was with GhostBSD’s repos disabled; otherwise it would have tried to install GhostBSD’s newer kf6-kguiaddons-6.2.0.

Anyway, I should have disabled GhostBSD’s repos from the beginning, because the conflicting package was kf5-kguiaddons-5.115.0 from GhostBSD; FreeBSD had kf5-kguiaddons-5.116.0.

And I suspect that the dependencies were fucked-up by the presence of numerous kf5-* and kf6-* packages (82 and 71, respectively) in GhostBSD’s repos, despite KDE not being there. Some apps were, such as both GhostBSD’s builds of konsole-23.08.5 and konsole-devel-24.01.90. Why would people use KDE apps outside KDE? That would make sense for Dolphin, but less so for Konsole. BTW, Dolphin only exists in the development 24.01.90 version, so it can’t be used in KDE5. Not by using GhostBSD’s packages, anyway.

GhostBSD’s packages are a complete, total mess. This is exactly why GhostBSD shouldn’t be used with FreeBSD packages, but I wouldn’t use it at all! It’s sort of Manjaro, with the timeline reversed, i.e. some of its packages are newer, not older than upstream.

Software Station is great, but GhostBSD sucks.

Eventually, I managed to install a minimal KDE, which however, because of the mixed packages, failed to start:

End of story. Anyone should install FreeBSD, not GhostBSD. The important lesson learned is that GhostBSD is not the right path to follow.

It’s always better to use something mainstream. In Linux, I opted for Alma Linux (RHEL being the most mainstream possible, but I wouldn’t pay for it), despite the non-branched EPEL for minor versions being stupid, with openSUSE Leap as a secondary option. Fedora is schizophrenic and it might soon drop X11 entirely. Other people could probably use Debian or Ubuntu, and Mint has become mainstream enough. For a BSD flavor, as the same Liam says:

Surveys suggest that about 75 percent of BSD users run FreeBSD. NetBSD focuses on being portable and supporting as many types of computer as it feasibly can. OpenBSD focuses on security and correctness.

FreeBSD just tries to be a capable, modern OS. It targets only reasonably modern hardware, and of all the BSDs, FreeBSD has the best support for modern PCs and the biggest selection of apps and drivers. There are native FreeBSD versions of many well-known FOSS tools, as well as some proprietary components such as Nvidia graphics drivers. If what you need isn’t FOSS or can’t be ported for some reason, FreeBSD can emulate Linux and run Linux binaries directly.

That’s Plan B. For the time being, I’m sticking to Plan A, waiting for FreeBSD 15.0-RELEASE to happen, somewhere in 2026, or as early as December 2025.

Speaking of FreeBSD…

…here’s a random set of FreeBSD 14.1 vs. DragonFlyBSD 6.4 vs. NetBSD 10 vs. Linux Benchmarks on specific hardware (64-core AMD Ryzen Zen 4 Threadripper 7980X, 128GB DDR5-4800, 1TB Crucial NVMe SSD, Radeon PRO W7900 graphics).

There are too many of them, so I’ll show you the geometric mean of the tests, and a few selected ones, to see how unexpected some results can be:

All things considered, I find FreeBSD more promising than I expected. But Liam Proven was proven right 😉 when he said that you should have a wired internet connection, not Wi-Fi. Only older Wi-Fi chips work in FreeBSD. As for “use a desktop, not a laptop,” it depends. There are people using FreeBSD on laptops.

FreeBSD could be a great way out of systemd, Wayland, GNOME, GRUB2. I forgot to mention how stupid and poorly designed is GRUB2.