Guardians,
We’re about due for a status update, here are the details. Greeting from Las Vegas, USA! If you’re at OracleWorld this week holla at me! Let’s get the important stuff out of the way.
If you’re using secure boot you need to ensure that you have the Universal Blue key enrolled in your system:
If you are missing this key you need to enroll it via the docs. Note that secure boot is opt in, you don’t have to use it if you don’t want to, but if you have it turned on follow the instructions in the docs:
Do note that it is entirely possible to enable secure boot and not have the key enrolled and have a functional system. This means that the system won’t load any akmods but if your hardware is linux friendly you might not notice at all! (I had a laptop like this, it’s sneaky!).
Retrospective
Bluefin GTS has found it’s audience, there’s solid value in going from mature GNOME point release to mature point release, allowing the ecosystem to mature, etc. This F40 cycle has been quite smooth, I am confident that this will make a great GTS, F39 was when we brought in ptyxis and that’s led to some teething issues, but that’ll all be behind us once it rebases to F40. Fedora’s terminal experience is now class-leading, thanks to all of you who have helped with the testing. Leave a comment on how this cycle was for you!
The flatpak font issue has been our outlier for this cycle: Broken UI fonts for Libreoffice flatpak and other applications · Issue #1558 · ublue-os/bluefin · GitHub
I will be honest with you, I hate this issue with the fury of a thousand suns. We were never able to figure it out, and it confirms my belief that computers were a mistake. If you got bit by this one, sorry. The good news is that it seems to be confined to F39, so I’m looking forward to burying this one for good.
bluefin:stable aka Bluefin
Bluefin GTS is great for a work machine or a PC for a loved one that you’re stuck having to do IT for.
But it is our intent for Bluefin to also be the world’s greatest desktop for enthusiasts. The intent here is simple, build the world’s best GNOME desktop, but we can’t do that if we’re always stuck one version behind. We announced the bluefin:stable tag on 1 July. It took us a while to get there, the first step was getting the infra in place.
Note that if you’re on Aurora you’ve always been on
stable, there’s no gts version of Aurora. (Because otherwise you’d be on Plasma 5, no thanks!)
We were hoping to just switch stable to the fsync kernel as soon as possible but in order to ensure we give people time we’ll likely do this as part of the F41 process. A non-vanilla kernel means you need to have our keys enrolled, otherwise your system won’t boot, so we’ll take it slow. We wanna move to fsync for a few reasons:
- We wanna sunset the Surface images (and Asus too) at some point, if we move to kernel-fsync we get those patches ootb, that clears up builder time and removes confusion for folks. This is more about hardware enablement than anything else.
- kernel-fsync is the same kernel Bazzite uses. And it’s used by Nobara, and incorporates patches from CachyOS, it’s become the defacto enthusiast kernel for Fedora based systems, and we have an awesome working relationship with Jan.
- We fully intend to bring in sched_ext packages that Bazzite uses to allow for our users to play with this exciting new technology. I’m very keen on shipping something like
bpflandas our default scheduler inbluefin:stable. What’s awesome about this stuff is you just run it in your terminal, which means we can keep the stable scheduler that comes with fsync (BORE), but allow our users to prototype bpf schedulers on the fly. This is awesome stuff for enthusiasts, I recommend deep diving into this! - @jardon is working on a PR that will warn you if you have secure boot enabled but haven’t enrolled the key
- We’ll likely do this via a notification on the desktop too
- We plan on adding a check to the rebase helper to ensure you can’t rebase onto an fsync kernel unless you have our keys enrolled.
Product Updates
When we first started all we could make was bluefin:latest, then we added gts, and now we have stable. We feel like this gradiant of throttle settings can cover a bunch of use cases. But explaining this to users is challenging, especially since we’ve had to grow and adapt over time.
Therefore unless the world explodes we will bring bluefin:stable to the masses as Bluefin. (It’s been purposely hidden on the website.) So this fall when F41 releases the two Bluefin products will be:
- Bluefin GTS: this will still be the recommended default, always follows Fedora -1, and will continue to use a vanilla Fedora kernel, following the Fedora CoreOS kernel cadence. This is no change from what we have today. This is for most users.
- Bluefin: This will be
bluefin:stable, we intend to put it on the website as a peer next to Bluefin GTS. If it’s not obvious by now, Bluefin’s purpose is to be the best Linux desktop in the world for enthusiasts. We intend to do this by leaving behind every antipattern that has kept the Linux desktop behind up to now, we will make our own fate. - Aurora: No change, you’ve always been on
stable, you only need to make sure you have the keys enrolled.
But what about latest users? We’ll keep this hidden from a product perspective, if you know how to Linux you know how to find it. If this entire post is confusing think of it this way:
Bluefin for you, Bluefin GTS for those you love
Bluefin and Bluefin GTS
Since stable follows the CoreOS cadence this will likely be about a month after F41 releases. So we end up in this weird situation. Due to the release schedule, this will release in a non-intuitive way:
- When Fedora 41 releases on October 22 then
bluefin:latestwill move to Fedora 41 that day. For those of you who want the latest bling. bluefin:gtswill rebase to Fedora 40bluefin:stableandaurora:stablewill rebase to Fedora 41 at some point after, this will depend on when Fedora CoreOS rebases to F41. This is our first time going through this for a major release so we’re not sure how it’ll “feel” in practice, but by the time this happens we’ll have plenty of data. And by data I mean Bazzite users testing ahead of us.
- Do note that October 22nd is a slushy date, it’s not uncommon for Fedora releases to slip. Actually you can almost guarantee it’ll be delayed, but generally speaking most people won’t notice.
This means that the people who want slow releases via bluefin:gts will upgrade first. These are the majority of Bluefin users. aurora:stable and bluefin:stable will update about a month after.
Note: you can do a fastfetch to see what image you’re on to see how it affects you:
Future Proofing
We closely follow and work with the Fedora team on Atomic, we’re all aligned on bootc, zstd:chunked, and all that stuff.
- Note that Aurora and Bluefin are not yet using hhd-rechunk: GitHub - hhd-dev/rechunk - Bazzite has been testing this and we’ll likely move to it for F41, this solves a bunch of bandwidth consumption issues, and when used in conjuction with zstd:chunked it should provide us with more efficient download sizes, as well as smaller images to begin with.
- composefs has been punted to F42 upstream, so no need to worry about this for now
- No meaningful updates on systemd-sysexts
- We’ve had regular meetings with the Fedora, Podman, and other associated teams within Fedora and Red Hat, so we’re feeling pretty good about this next cycle. As always, Fedora is looking for volunteers, if you want to help bring this to fruition faster, we encourage you to participate at the source!
- I have a semi-regular call with Christian Schaller to ensure we’re strategically aligned with where RHEL is going.
- Members of our team regularly sync with the Fedora CoreOS folks.
If you’re new here and not sure how we roll: our purpose is to advance the next generation linux desktop and that means coordinating with Fedora on a regular basis. We are not a distribution, our purpose is to take Fedora into new territories by applying known-good cloud native patterns to end users.
Thank you so much for being a part of this journey!
