Guardians ... a new Dakota arrives, likely our last before beta. @ahmedadan brings us an example of the power we can wield with BuildStream and The Final Shape. (Ask him about his COSMIC image!)
The builder is back in business and we now have enough institutional knowledge to make getting a new one and swapping it in easier. Improvements in the tooling in general has helped. And my homelab is doing from-source builds in 8 minutes, that's 4 minutes faster than assembling RPMs. We intend to make it trivial for anyone to deploy these on any modern infra. Buildstream and Kubernetes is a beautiful thing.
First let's get the versioning out of the way. Since we're based on freedesktop-sdk project we'll use their version. In this case, 25.08.11. The 11th release of the August 2025 major update. 26.08 is our next update. Yes, that's next month. :) Bluefin will remain versionless and tested as a whole, you'll just switch aggressiveness with game mode if you want:
Kernel: 7.0.11
Game Mode Kernel: 7.1.4-ogc1
GNOME Shell: 50.3
freedesktop-sdk: 25.08.11
bootc: 1.16.6
systemd: 260.2
Flatpak: 1.18.0
:testing GNOME 50 development builds
:stable Publishing daily if tests pass, moving to every other day for beta, weekly for GA
:next GNOME 51 rolling builds, currently busted.
We're helping out GNOME OS by shipping a new zswap configuration, based on their inprogress work upstream. Dakota uses zswap backed by a disk swapfile, rather than zram.
zswap.enabled=1 keeps recently swapped pages compressed in RAM, avoiding disk I/O when they are needed again.
zswap.compressor=zstd selects Zstandard: generally a good compression-ratio/CPU-speed balance.
zswap.max_pool_percent=20 caps the compressed RAM pool at 20% of installed memory.
zswap.shrinker_enabled=1 lets the kernel reclaim zswap memory under pressure by writing colder compressed pages to the backing swapfile.
vm.swappiness=100 makes the kernel treat reclaiming anonymous memory to swap as comparable in cost to reclaiming file cache. Since zswap absorbs the initial swap writes in RAM, this aims to preserve filesystem cache without immediately incurring disk latency.
The backing store is /var/swap/swapfile, created on demand at min(RAM / 2, 8 GiB) when the disk is large enough. Dakota explicitly disables GNOME OS's zram device, so it does not stack zram and zswap; The kernel arguments live in /usr/lib/bootc/kargs.d/20-zswap.toml, so bootc applies them on image switches and upgrades.
Feel free to give feedback on the swap stuff, it's an exciting area where we can hope to help out GNOME!
As part of our mission to improve the Linux desktop we're offering a "Game Mode" to Bluefin, which will pull in a bunch of stuff. It will be available in a checkbox in the control panel and is basically a lightweight Bazzite-lite built with BuildStream.
Yes, an OGC gaming kernel with aggressive updates but at least upgrades will work, lol. It will slay, so it is also aliased to dakota:btw. For the discerning raptor rider.
The kernel includes gaming-focused patches/features, including sched_ext and ntsync
Steam and its 32-bit compatibility libraries and controller udev rules, etc all built in - this is basically the Steam flatpak, you'll show up as "Freedesktop" in the Steam Charts
Gamescope and the Steam Big Picture gamescope session
GameMode, MangoHud, and vkBasalt for performance management, metrics, and post-processing.
InputPlumber, SDL controller database, and handheld/controller support. Note that we don't support handhelds but shrug it's all Linux.
All that extra Vulkan, SDL, audio, X11, USB, and input compatibility libraries for native games and stuff. Shout out to Kyle Gospo for the guidance!
First-boot Flathub installs for Lutris, Heroic, Bottles, ProtonPlus, Protontricks, and GOverlay.
There will be a GUI for this soon, in the meantime enjoy! You can't rebase to this from another image, if you're not on dakota already you need to reinstall.
If you want to understand how a modern Linux distribution is made, you eventually have to look at the "sausage factory" - the intricate pipeline of code repositories, build systems, test suites, and orchestrators that turn raw source files into something you can boot on physical hardware.
Supakeen posted The Fedora 45 Sausage Factory, and the curtain was pulled back on Fedora's use of dist-git, Koji, Bodhi, Pungi, and openQA to make Fedora.
People are asking "what's the equivalent of this in Bluefin?" Most of this stuff sounds like a Pacific Rim sequel, so let's take a look. We are currently in the process of moving away from our own legacy sausage factory to Bluefin's final destination: Kubernetes.
projectbluefin/common: The shared "org brain" containing system configurations, desktop defaults, documentation, and foundational OCI layers. When most of you think "Bluefin", it's in here.
Image repos (bluefin, bluefin-lts, dakota): Derivative image definitions that consume common and layer specific desktop experiences or lifecycle variants.
Instead of spec files and tarballs, Bluefin's definitions rely on Containerfile directives and declarative package manifests. But in some cases you may still find a vestigial inline package install in a script.
I've read comments on Reddit that think that all of this is GitHub-specific. GHA is there because we're lazy. At the end of the day, all of Bluefin is locally buildable on any service. And on any OS: you can build Bluefin on Macs and Windows too. Each repo has its own Justfile covering different tasks.
The entire point of cloud native is that you should be able to build the thing anywhere. If you get confused by "cloud native", try to remember "API Native" instead. Let's look at some standard OCI things:
[ git ] [ buildah ] [ podman ] [ skopeo & bootc ]
Declarative Config ---> Daemonless Layer ---> Local Execution ---> Registry Transport
& Tracking Composition & Inspection & Host OS Deployment
git: Tracks everything. This is the single source of truth. This is called declarative config and has all the config files.
Linux distributions talk about "rolling vs. stable" - this doesn't make sense in modern Linux. The entire thing is a git branch. It's what you choose to ship.
You need to ship the entire git branch. That means releases AND rolling tags, feature branches, testing branches, "test this crazy thing here temporarily branches", all of that. git is fully open source and not under the control of any single vendor. When the Bluefin factory is cooking things that used to take months now take hours:
OGC Gaming kernel and stack on Bluefin Dakota
buildah (Daemonless Builder): Assembles container layers statelessly without requiring a background daemon or root privileges on host runners. buildah is a CNCF Sandbox project and not under the control of any single vendor.
podman (Local Validation): Enables local parity. Developers can run podman run locally to inspect built layers before pushing code. podman is a CNCF Sandbox project and not under the control of any single vendor.
skopeo (Transport & Tags): Handles low-level OCI manifest operations - copying images directly between registries, inspecting layers, and managing release tags. skopeo is a CNCF Sandbox project and not under the control of any single vendor.
bootc (Target Deployment): Bridges standard OCI container images directly to the target machine's disk. It handles kernel handoff, transactional filesystem updates, and automatic rollbacks. You're not going to believe it ... bootc is a CNCF Sandbox project and not under the control of any single vendor.
Let's add a new application. Let's say the control panel we've all been missing. Brian Ketelsen, Father of Bluefin and now control panel connoisseur has blessed us with this:
He's been rolling with this in his custom image. And if you're like me you probably want that thing right now. Here's the Git repo. Not distribution specific either, Brian's images are based on Debian. See how weird it is to classify things the old way? Who cares. It doesn't even ship on the image it ships in homebrew lol.
In Bluefin, adding an application comes down to choosing where the change belongs in the repository tree:
Option A: At the Shared Level (projectbluefin/common)
This is 95% of it. Someone saw a new app in Flathub and wants to feature it, or we need to swap out a component when an app gets deprecated, etc. Chairlift will go here.
Contributor: edit a central Brewfile (for Homebrew CLI utilities or Flatpak desktop apps).
Option B: At the Image Level (bluefin, bluefin-lts, dakota)
Contributor: edit an image-specific build script (e.g., build/10-build.sh executing dnf5install -y <package>) or a bst definition file.
This is usually system-level stuff, or may be things the user doesn't see that we deal with. For example, NVIDIA drivers on all three are installed differently. Or if your hardware acceleration breaks, etc. Anything that touches the metal, like that OGC kernel.
We have a lazy consensus model - in the early days of Universal Blue we had full-blown specs and it looked similar to what you see in Fedora today. These days you can file a bug in common and if maintainers have consensus, we do it.
This can cause friction for new users who do not understand Bluefin's mission. An open process doesn't mean a free-for-all. It also means we force work OUT of the org. For example, in Dakota we'll be prototyping zswap configs, but -
However, the entire process is in the air. Six months ago I would have told you, "if you didn't file a bug, I don't care; you didn't put in any effort, so I won't either." Now I can point an agent to my entire Discord and slurp out months of people's actual bugs and get actionable feedback.
This is why IMO the best thing we could invest will be ujust report. We make it easier for people to submit their technical data, opt-in. But that is a post for another day!
Fedora's sausage factory is a masterclass in classical Linux release engineering. But we are a small project and cannot afford such complexity.
And then you would say, "But Bluefin is Fedora/CentOS, you can't make Bluefin without it." And you'd be right! And then the other half of the room would say, "Listen to the k8s guy talk about complexity!" And they would also be right!
The last bit is BuildStream, which effectively replaces just about everything in that Fedora diagram with a single, simple CLI tool. BuildStream is hosted at the Apache Foundation.
If you're a developer, the entirety of your existence lives in git.
Anything you want, any version you want, we're going with GNOME OS versions first
But then add things like OGC kernels, nicer Mesa, etc. We're finishing up the Dakota gaming image now and there will be a nice GUI to make all of your lives happier.
This is GitOps, so forking, etc. is encouraged. Pretend you can get a Bluefin for every possible iteration (because you can!) Some of you will think this is about images, but most of you will do the smart thing and swap out Brewfiles and "top 10 kickass Flatpaks" and so on. Both of these ecosystems are distribution-agnostic.
A vendor-neutral, well-maintained toolchain makes your dream real
You know when I say "distroless", "cloud native", "the Kubernetes moment", and all of that stuff? And then people laugh? This is what I mean. Moving away entirely from the concept of distribution tooling to commodity tools.
It's down to git, bst, and bootc. BuildStream can output your dream in one go. THE ENTIRE MIDDLE PART GOES AWAY. No intermediary format - it goes right to a format that we can run tests on, scan, etc. You don't need "distro builders"; you just need normal containers!
I could give a sysadmin these three tools and a laptop with the right creds and publish Bluefin, and none of you would notice.
So on the one hand, we have The Final Shape. It's clear what I think: we optimize for correctness in Linux first, your shitty VPN RPM be damned.
What Fedora Hummingbird brings to the table is to take all of that operational knowledge Fedora has, and then bring THAT into the container-native space. They are, after all, building a Linux distribution.
Which is also why we say we're not a Linux distribution. Dakotaraptor was born into cloud native. It will never have to deal with COPRs or akmods or any of that stuff. It will just have what it needs with a handful of tools and infrastructure.
I would argue our appeal is that we start from the success of Kubernetes. I have now experienced BuildStream with Buildbarn and Kubernetes.
From a technical perspective, it excels at everything we need it for and I have yet to see anything even in the same ballpark.
From a cost perspective, it's unbeatable. Every infrastructure provider in the world sells K8s, and everyone's laptop has podman.
Contributors
That last one. Millions and millions of developers know this tooling already. This is a great opportunity to meld the distribution processes with new people coming in at Hummingbird Factory level.
Our message to contributors remains the same. Use the tools everyone else is using - bias towards trusted vendor-neutral organizations. I have annoyingly pointed out which of these tools are hosted by the CNCF and the Apache Foundation. This is what "Cloud Native Linux" is.
I liken Fedora to last year's McLaren. When it comes to traditional Linux distros, you'd have a tough time beating Fedora. And just about everything you hate about it has nothing to do with the tech and probably the policies.
This is why Fedora Hummingbird's factory is appealing to me. As you can tell, I can't shut up about it.
But things change, and every year the users demand the spectacle. Fedora Hummingbird is a ton of well-funded enterprise tech - they've got wind tunnels, an awesome factory, engineers fighting to be the best. Inserting all of that Fedora operational DevOps knowledge into a modern Hummingbird design would slay.
Fedora Hummingbird is built with this same collection of CNCF and Apache projects. Combined with other open source projects, many of which are controlled by a single vendor, but have years of enterprise pedigree with billions of dollars worth of ecosystem to show for it.
Loop closed ...
Mastery of these tools is in high demand. Even if you skip all of the operating system parts, all of these skills are useful for much more. The desktop is but a sliver of places you'll find these tools.
Some will grab RPMs and debs, some will grab bst. All will need Kubernetes.
We should encourage this, all in the name of sport! Sharing about 95% of the tooling and the people. Let's not forget that Ubuntu's putting in some great laps!
We hope that you're enjoying the holidays! We're making some important changes to how Homebrew and command-line tools work in Bluefin. These changes will land in this Tuesday's weekly build.
Homebrew's path will now be placed after the system path. This will cause brew doctor to complain, but we feel that this will lead to a cleaner experience overall. This has been working well in testing, and the change is already on the daily builds if you're using one of them.
Atuin has been causing some issues, so we've disabled it by default to ensure a stable experience with bluefin-cli. We plan to investigate a better integration for Atuin in the future.
We will be publishing a large year-in-review update next week that will cover these topics in much more detail, but we wanted to give you a heads-up on these behavioral changes before they land. In the meantime, we've set up todo.projectbluefin.io for you to follow along with the major changes coming in Bluefin. Thanks!
We've created a new repository to make it much easier to add Homebrew to your custom bootc images. @ublue-os/brew repository provides a pre-packaged OCI container image that bundles everything you need to add Homebrew to your custom image-based systems. This is an evolution of a long journey to integrate homebrew better onto our Linux systems. Instead of manually setting up Homebrew, configuring services, and managing shell integrations, you can now include everything with a single line in your Containerfile.
On first boot, the brew-setup.service automatically extracts Homebrew to /var/home/linuxbrew/.linuxbrew, sets up proper permissions, and makes it ready to use. The image also includes timers for automatic updates and upgrades, keeping your Homebrew installation current.
This removes a bunch of the manual stuff you had to do in your template to get the full thing, now it's much easier and reliable for everyone. Once we're done the container will rebuild after a Homebrew release, keeping us up to date and safe!
