# Charting Bluefin's Course for 2026

Greetings guardians. We had a _fantastic_ KubeCon + CloudNativeCon, with over 9,200 attendees. This made for another great place to gather user feedback, and find out how we're doing compared to the ecosystem.

With the holidays coming up in the US I'd like to spend some time talking about our north star for the project. I received a ton of advice from lots of mentors of mine from around the community.

[bootc team pic]

## Unifying Bluefin

We effectively rewrote most of Bluefin last cycle, the age of rpm-ostree is fully behind us. We've been on `bootc` for a while and the code in the project itself needed to be up to date. Now we're working on reducing more tech debt and improve quality.

:::info[Welcome Timothee Ravier]

Thanks to a new collaborative effort, we're moving from Timothee's unofficial Silverblue images to all new base images that we're building together.

:::

### New Base

This Timothee-powered awesomeness brings some new things to the table:

- One common place for gated kernels - so that we can share work with Aurora. This will allow us to also remove "doing this ourselves" code from both projects and Universal Blue.

We do build more from scratch, and more importantly, continue to decouple ourselves from Fedora policies and focus on the content. It is technically more work, but also the guy who was doing the work and has to do it for Fedora anyway just puts a dinosaur hat on. Voila.

These base images will be much more appealing to third parties since they will be the focal place for Fedora-based base images. I expect third parties to consume them and we'll all enjoy higher quality and less regressions.

### The CoreOS model for the Desktop

This spring we are rolling `bluefin:gts` and `bluefin:latest` into `bluefin:stable` for one "Bluefin". We're doing this for a few reasons:

- The value GTS provided is "older software works better". This is the antithesis of how modern software is developed. What it really means is "no one messed with this".
- `bluefin:latest` - this one is also an antipattern, you want to be able to pin something, and people make assumptions of what it means. We'll transparently move you to `bluefin:stable` too.

It "feels" stabler, but it isn't, it just means no one does enough testing. Now let me show you how we plan to make this a higher quality experience.

Tulip figured this out, here's where we are now. We will be moving to the CoreOS model full time, with three branches.

- `bluefin:next` - all changes will land here first. We make no stability guarantees. It will build daily. This will not replace `bluefin:latest` because we will for sure break things in here. This will build at least daily.
- `bluefin:testing` - When changes in `:next` have been tested by at least one person they queue up to land in testing. We anticipate things to sit in here for a week or two at a minimum unless we need to fix a regression. This builds daily.
- `bluefin:stable` - This is effectively the current version of Fedora, except all changes going into this will have at least be vetted by the previous branches. We do NOT have this today. This is the goal.

Right off the bat we'striving for better testing and quality. renner0 has been adding the beginning of [tests](https://github.com/ublue-os/bluefin/blob/main/build_files/base/20-tests.sh) in Bluefin. This stubbed out first set of checks is our starting point to building "gates" between the branches with tests. This is just a small start to a much larger effort over time, volunteers wanted!

Each set of changes from `next` to `testing` to `stable` will have an open pull request of all the staged changes so you can follow along. It'll be badass. Blossom Badass.

## Unifying the Bluefin Repositories

We've been taking more time moving Bluefin's customizations over to homebrew instead of RPMs. This is for a few reasons.

- Customizations belong in user space and user controlled
- homebrew's automation is incredible. We run our [own tap](https://github.com/ublue-os/homebrew-tap/) and are working to put all the cool stuff in here instead of via the [packages repo](https://github.com/ublue-os/packages)
- Ain't no one want to make RPMs anyway.

And the big one, keeping Bluefin and Bluefin LTS sucks, in this manner we can bring changes to both at the same time instead of moving back and forth. This has annoyed me for a while, so LTS will be rocking and rolling here soon.

> A quote from John Bazzite on the betrayal

## Bluefin for MacOS

Bluefin's command line experience, and "bling" as we like to call it, is coming to MacOS. All the artwork, aliases, brewfiles, etc.

The team has been moving so many things to brew to make parity easier between variants. This makes adding MacOS easier. And most importantly, was one of the most requested things from our KubeCon feedback. This opens up a whole new set of contributors to work on Bluefin, even if they don't use Linux.

This is also a way for us to give MacOS people "the hookup". We can bring Podman, Podman Desktop, and all of the amazing cloud native projects we include as "one bundle" for them as one experience.

## Bootcrew Unlocked the World

> Tulip, the bootc team gave you the tool to get rid of these things, and you decide to make more?
>
> -- Jorge, Journal of the Damned, Volume 6

The [bootcrew](https://github.com/bootcrew) kind of threw the entire `bootc` world as Tulip, Robert, and [whoever] worked with the `bootc` team to bring the composefs branch into shape. This allows the community to make [bootc images of everything].

This is also another reason why we're moving to homebrew for the content. Someone would have to make RPMs and packages for all of these. That's a hard nope.

At KubeCon Robert Sirchia from SUSE asked if we'd ever consider using [the OBS] so we can make more Bluefins. And of course we've both always wanted a "Greenfin" based on Tumbleweed (who wouldn't?). This will be much easier with Bootcrew's [opensuse image] + the homebrew parts, which are distribution and operating system agnostic!

## Joining Forces

And finally, what I am most excited to share with you today. The bootcrew also unlocked the gem for us. A functional [GNOME OS bootc base image].

The original CoreOS had a lasting impact on Linux. It is the original "cloud native Linux". Totally different from traditional distributions. Our golden path.

When Red Hat bought CoreOS there was a fork named Flatcar Linux, which continued the CoreOS model forward. Flatcar is also in the CNCF, and my server Linux of choice. Others sprung up like Kairos (also in the CNCF). Talos is also awesome, Bluefin contributor Justin Garrison works there and is always pushing the boundaries.

Interestingly Red Hat transformed CoreOS into the new `rpm-ostree` and then `bootc` models. Flatcar Linux evolved into becoming heavily invested in [sysexts] and other interesting Linux userspace bits. With the history lesson out of the way ...

## A New Bluefin

`bluefin:distroless` will be based on GNOME OS and follow the principles from Lennart's [blog post] and input from GNOME. This isn't an official GNOME project. Our purpose here is to _productize_ a stable GNOME experience, which is what we've always wanted to do. And the best way to get that is from GNOME itself.

Bluefin's contract with GNOME then becomes as a pipeline to send interested developers to GNOME OS, which will help accelerate the flywheel of contributions into the ecosystem.

Just like CoreOS before it, I believe an OS made like this _must_ come be fresh and not an _adaptation_ of a model we're trying to move away from.

- GNOMEOS base image gives us the smallest Bluefin, ~2GB vs ~4GB to start off with.
- `systemd-boot`, `systemd-homed`, UKIs, and a bunch of modern features
- someone add all the features
- A community of experts around the epicenter of userspace development: https://uapi-group.org/
- Utilizing `bootc` as a bridge between that group and the [15.6 million cloud native developers] that are more comfortable in Bluefin than raw GNOME OS.

:::tip[Distro wars]

The "distro wars people" would pit `bootc` and cloud native vs. the systemd folks. Of course we're going to use both. Red Hat funds one, Microsoft funds the other. Both have strong communities of volunteers and enthusiasts working with both.

:::

This Bluefin will be the purest form.

This Bluefin will come with the same `next` -> `testing` -> `stable` branches, a gated kernel, and all the same features from Bluefin. Note: Local Layering is not a feature here, the last parts of the old model won't be coming with us.

The most important addition to this is of course the community of experts that come along with it. Jordan P has been working with us more closely and has helped to make this happen. And finally, a reason to work with Adrian Vovk and Valentin David. :D

We expect this Bluefin to not only be the most technically interesting, but to be at the forefront of Linux desktop development at the speed of development directly from upstream instead of a traditional distribution.

## Putting it all together

Wow, this ended up being longer than the release announcement lol. There's also some other major sweeping changes:

- We'll be emphazising when feautures land in Bluefin instead of being "locked in" to release schedules from Fedora. This means more GNOME and Apps, less distro.

now is the time to get involved blah blah