A Geek with Guns - Dinosaur OS

Disabling Homebrew in Dinosaur OS

2026-02-13T13:00:00-06:00

Since I released Dinosaur OS</a> last September, I've had to make very few changes to my image. This is a testament to the overall stability of Bluefin, the image upon which Dinosaur OS is based. But I started receiving error notifications a couple of weeks ago whenever the automatic update service ran. The initial error was actually due to a Flatpak problem. The developer of a package I installed uploaded a new version with the same version number as my currently installed version. This cause the Flatpak update program to fail. I managed to fix that, but the service was still displaying an error because it wasn't able to update Homebrew.

Homebrew is a package manager that was originally written for macOS. It was released back when I used macOS so I tried it and discovered that it was a train wreck and opted to use MacPorts</a> instead. Homebrew had a number of bizarre design decisions. The biggest was it wanted to install packages at a system level. Normally that's not a problem with a package manager, but Homebrew tied the system level directory to your user account's user ID number. Effectively Homebrew installed packages at a system level that only a single user account to use or modify. There was an option to install packages into your home directory, but a number of packages failed to run when you did that.

When it was announced that Homebrew was available for Linux, I dismissed it entirely. Why would I want a poorly designed package manager on a system that already has a plethora of very good package managers? My experience with Homebrew was so bad that I initially intended to remove it from Dinosaur OS. I ultimately decided that enough time had passed that I should give Homebrew another chance. My latest experience mirrored my previous experience.

Homebrew on Linux suffers the same problem as it does on macOS. It doesn't support systems with multiple user accounts well. When Bluefin installs Homebrew, it creates the /home/linuxbrew/</code> directory and sets its user and group IDs to 1000. Bluefin is based on Fedora and by default the first user account created on a Fedora system has the user and group IDs of 1000. All packages installed with Homebrew are installed into the /home/linuxbrew/</code> directory. This means Homebrew on Bluefin is configured so that only the very first user account created on the system can use it.

This is fine for most users, but I'm not most users. I have two user accounts on my system. The first is my administrator account, the second is a regular user account that I use for my day to day tasks. Administrator rights are required to create new user accounts so obviously I create my administrator account first. This means the actual account I use day to day, which has the user and group IDs of 1001 (the default on Fedora systems for the second user account created), can't use Homebrew.

There are ways around this. I could change the owner permissions on /home/linuxbrew/</code> to 1001. Homebrew on Bluefin is setup using the brew-setup.service</code> systemd service, which sets the permissions. I could change that unit file in my image to set the user and group IDs to 1001. Either option would allow my day to day user account to use Homebrew installed packages, but would prevent my administrator account from using them. The bottom line is Homebrew is a poorly designed package manager.

I chose a third option: ignore Homebrew entirely. There was no downside to this option at first, but a few weeks ago changes were made to Bluefin's automatic updater that caused me to reexamine my decision. As noted at the beginning of this article, I started receiving notifications that the automatic update service failed. Checking journalctl showed me the source of the error was that the update utility, UUPD</a>, was unable to upgrade Homebrew. This failure was caused by /home/linuxbrew/</code>, which normally contains the brew executable used to install and update packages, being empty (I didn't investigate why it was empty since I was already done with Homebrew).

Fortunately disabling and removing Homebrew from Bluefin is straight forward. Homebrew is installed by the brew-setup.service</code> systemd service, which is enabled by default on Bluefin. Disabling the service prevents it from automatically installing Homebrew so Dinosaur OS disables it. I also add a script, /usr/libexec/remove-brew</code>, to the image, which removes Homebrew from a system if it's already installed. This makes Dinosaur OS nondestructive in that it won't automatically remove Homebrew from a system where it's already installed. Removing Homebrew requires manual work. It also means Homebrew can be installed again by either starting or enabling brew-setup.service</code>.

I still had the problem where UUPD would throw an error because it was unable to update Homebrew (which was now missing entirely). UUPD on Bluefin accepts arguments that disable update modules though. The final change I made to Dinosaur OS is adding --disable-module-brew</code> to the ExecStart line of uupd.service</code>, which is activated by a timer periodically. uupd.service</code> is a system file, which means the user cannot edit it. Therefore, if you're running Dinosaur OS and install Homebrew, your Homebrew packages won't be automatically updated by uupd.service</code>. The best way to change this behavior is to copy /usr/lib/systemd/system/brew-update.service</code> to /etc/systemd/system/uupd.service</code> and remove --disable-module-brew</code> from the ExecStart line.

Overall I still like Bluefin a lot. I agree with most of the design decisions and appreciate that it's been easy for me to change the decisions I dislike. I continue to run Dinosaur OS on my desktop systems and haven't faced any catastrophic problems. If you want to create your own image based on Bluefin and want an example image to get started, check the Dinosaur OS repository</a>.



Introducing Dinosaur OS
2025-09-05T12:00:00+00:00
Along with my new laptop</a>, I decided to try a new operating system. I've been running Fedora Workstation since I bought my ThinkPad P52s in 2018. It's a great distribution. However, I've been interested in immutable Linux distributions for a long time. Unfortunately, getting the proprietary Nvidia driver (the P52s has an Nvida GPU) working on Fedora Silverblue without having to disable SecureBoot was a hurdle I didn't want to jump over. Fortunately, my new laptop has an AMD processor and integrated GPU so I don't have to deal with Nvidia's shenanigans anymore. I originally intended to run Fedora Silverblue, but then I came across Bluefin</a>, which is a Universal Blue</a> image, which is a Silverblue based image meant to be a foundation for building images.</p>
Immutable Linux distributions differ from typical distributions in a number of ways. The biggest difference, which is in the name, is that the base system is immutable. This means you can't install packages in the normal manner. Silverblue has support for overlay packages, but installing overlay packages on an immutable distribution can cause headaches down the road (especially when performing major version upgrades). The advantage is that upgrades are simple and rolling back to a previous version is as simple as rebooting. Rebasing to other immutable images is also simple (as is rolling back if you decide you don't like the new image).</p>
I chose Bluefin over Silverblue for a few reasons. First, Silverblue uses the Fedora flatpak repository by default and all of the included flatpaks are sourced from that repository. I prefer to use Flathub because the packages are up-to-date. Bluefin uses Flathub. Second, Bluefin includes Distrobox</a>. Silverblue includes Toolbox, which I find inferior to Distrobox. Third, Bluefin includes Bazaar as its graphical Flatpak manager. Silverblue, like Fedora Workstation, still uses GNOME Software, which is so buggy that I end up managing flatpaks via the command line when I use Workstation. Fourth, dinosaurs. Bluefin's theme involves dinosaurs and dinosaurs are cool (hence the name of my modification of Bluefin).</p>
There's just one problem with Bluefin (Silverblue has this problem too). It doesn't include libvirt. I rely heavily on libvirt. It's my virtual machine manager of choice. Installing libvirt on Fedora Workstation was a simple dnf command away. But Bluefin is immutable so dnf isn't a lot of help. Bluefin does offer a solution out of the box in the form of the Bluefin Developer Experience (DX). Bluefin includes an easy way to rebase to Bluefin DX. The problem with Bluefin DX is that it includes a lot of tools I don't want to use such as Docker, Visual Studio Code, and Incus. This lead me down a rabbit hole of learning how to make my own modified version of Bluefin.</p>
Modifying Bluefin or any other Universal Blue image is dead simple. There's a handy template</a> that you can fork to get started. From there you can modify the Bluefin build process to add, remove, or modify whatever you want. The result of my efforts is Dinosaur OS</a>. Dinosaur OS is basically Bluefin with libvirt added. There are a few other minor modification too, but the inclusion of libvirt is the main difference. Switching from Bluefin to Dinosaur OS is as simple as issuing the sudo bootc switch ghcr.io/christopherburg/dinosaur-os</code> command. Once it completes downloading and staging the image, reboot your computer and you'll be in my modified version of Bluefin.</p>
The instructions to get started are all in the template's README.md file. But there are two files that will contain a lion's share of your changes. The first is Containerfile. The second is /build_files/build.sh. I've organized my repository since my initial release, but most of the changes are made by the shell scripts in /build_files/. For example, /build_files/base/00-install-libvirt.sh executes dnf to install the libvirt packages. It also adds the libvirt group to the image so you can add user accounts to the group. It also enables a systemd service that fixes some SELinux permission issues. None of this was my original idea. I pieces together how Bluefin DX</a> installs libvirt and made those modification in my image.</p>
Now that it's configured, my GitHub repository rebuilds the image once a day. This pulls in the updates from Bluefin, which in turn pulls in the updates from its base Universal Blue image. Dinosaur OS downloads new images automatically so when I reboot my computer, I boot into the latest image.</p>
I don't expect anybody to run Dinosaur OS themselves. It's custom tailored to my use case. My hope is that it can work as a template or example for anybody who wants to make their own image. The coolest thing about image based distributions is that it's trivial to make a bespoke image that fits your use cases. The coolest thing about using Universal Blue as the foundation is that it automates most of the work.</p>