I'm a strong believer in the next generation Linux desktop model - which splits what is typically one monolithic system into different layers. This has been great for us at Universal Blue because it allows us to reuse Fedora's OCI images to deliver a more reliable and customizable experience for users.
However some users struggle with the concept of running workloads in containers. They're used to
sudo apt install npm and whatever tools directly on the host. Though I do recommend setting up distrobox as your main user interface, this method has some unfortunate drawbacks:
- Users need to set it up this way. We do some of that in Bluefin but it's kinda janky.
- There are UX problems that aren't being actively worked on.
- There's a mental leap that non-cloud-native developers must make that they don't appear to be making.
On the last point, when you're in a distrobox it makes managing podman containers for development different than just about anything else. This leads to unfortunate situations like this thread where the user thinks that you're supposed to interact with the system service inside the container, and the preferred solution ends up being a layered package.
If you're thinking "Why don't they use the linuxserver/syncthing container that has over 100 million pulls?" ... I found myself thinking that too but that's a problem for another day.
I typically don't follow brew, it's that weird Mac thing right? It ends up that about two years ago they switched to using GitHub Packages. This might seem like not a big deal but then as I read on it became clear that
homebrew is just using OCI artifacts as a package manager. Here's the neovim package.
It gets even better for us Linux users – the analytics are completely open and the user can opt out if they wish.
This is nice for people getting started on things like Fedora Silverblue because usually they just want to install
htop or whatever other tools they're looking for without the complexity.
It's nice that the packages are maintained by both MacOS and Linux people, it's a much larger community. They have just about everything. And you can do declarative config via a
Brewfile if you want to do that.
The network performance is awesome because it's just hosted on ghcr.io, It's also very easy to set up a pull through cache on your network using any OCI registry you want if you miss your
- It lets people install packages who don't care about containers. "I just wanted to install neotopfetch!"
- It's self contained in
/home/linuxbrew/.linuxbrewand can easily be blown away - doesn't interfere with the system
- It has just about everything people could want in there
- There are lots of linux users, not even close to the number of MacOS users but that's more than enough.
- It's mostly GitHub native, there's lots of automation. Here's dysk being upgraded. You can observe the packages being built in GitHub actions and being pushed to the registry.
- The packages are just OCI blobs stored on ghcr.io, same place the OS is, making caching locally awesome and avoiding distro mirrors entirely.
But no Linux ARM
Unfortunately there are no ARM linux binaries yet, but that's a solvable problem. You also lose points with the gatekeeping Linux types for not using a "proper" package manager, so maybe that's actually an advantage!
A great compliment for Flatpaks
People keep trying to shove CLI applications into Flatpaks for some reason, even though it's not designed to do that. Now just about any CLI tool is at your fingertips. It's maintained by a well structured community, and I love that they have GitHub sponsors, it only took me a few seconds to send them some money.
And crucially both Flathub and Homebrew publish their usage analytics for everyone to see. No hidden numbers.
Having it be an OCI blob is the thing that makes this really nice. My OS, my devcontainers, and my CLI tools are all hosted on a registry.
- Operating System: image based, no need for the user to use a package manager
- GUI apps: Flatpaks via the GNOME Software Center or KDE Discover
- CLI apps: Homebrew
And for the developers that's the usual, standard OCI containers. VSCode with devcontainers is my preferred recommendation since it's already a popular choice, and of course, toolbox and distrobox (as well as raw podman) is also available so you always have other options.