Bluefin Blog

Bluefin Server Alpha 2

2026-09-08T02:11:44.000Z

Alright, here it is, Bluefin Server, this one actually boots. This is the base of the Bluefin Factory, the thing you'll build your homelab on. And in turn, your desktops or whatever you want. Kubernetes for the home.

An FSDK-based, image-based Linux server OS.**

To celebrate this milestone, enjoy the latest video, with some fresh lore!

Bluefin Server targets the same use-case space as Flatcar Container Linux, Kairos, Fedora CoreOS, and Talos, but is built from scratch with BuildStream 2 from freedesktop-sdk (FSDK 26.08) components and uutils coreutils.

It is designed to be installed and then managed entirely through the Kubestellar GUI. I'll be releasing point releases quickly over the next few days. After the install it will give you a web address, then you go to it on your computer. Then that's it, your perfect home server.

Except the dashboards are empty. The more people we have making these the better, including a ZFS one! This variant will have ZFS support so now's the time to jump onboard!

It is DDI first: the OS payload is a compressed XFS DDI filesystem image that is deployed by an offline, systemd-native installer.

Release status: Alpha

Bluefin Server is currently in Alpha:

Milestone status: Phase A (reproducible build path, uutils, k0s sysext, graph validation) is complete. Phase B (automated boot verification on lab cluster) is in progress.
systemd-sysupdate should work, we're about to find out! configurations.
Readiness roadmap: Track completed criteria and remaining gates toward 1.0 in docs/MVP_1_0_READINESS.md.

How this works

A/B root rollback — an MVP 1.0 gate: 50-root.transfer names root-a and root-b; the installer currently creates only root-a.
DDI-first delivery — the installer embeds the OS payload as a data partition; no network is required at install time. This is basically Linux systemd style.
Minimal, distroless OS image — no shell in the running rootfs by default IS what we are shooting for. We'll probably fail at this lol.
systemd-native installer — systemd-sysinstall provides the interactive terminal UI and systemd-repart handles partitioning and block-copy DDI placement. Finally distro installers can all go die!
Optional k0s as a systemd-sysext so the base image stays distroless. We started with k3s but I want to see how this one goes, stripped down for the home.

SSH ON: SSH is enabled for cluster boot tests and remote debugging. It is scheduled for removal once diagnostics move to serial logs or a guest agent. See docs/skills/factory-integration.md.

Quick start

Bare metal sorely needed! However this runs on any Linux, feel free to fire up a VM and start designing that dashboard! Once we get home assistant and all the goodies it'll be amazing! Thanks for checking it out!

You need only podman and just. BuildStream runs inside the FSDK bst2 container, so BuildStream is not installed locally.

just validate              # resolve the element graph
just show-me-the-future    # end-to-end QEMU installer smoke test

See AGENTS.md for the full build command matrix, hard rules, and agent skill routing.

Contributing

See CONTRIBUTING.md for the contributor checklist, Conventional Commit rules, and docs/skills/index.md for task-specific guidance.

I Dreamed of Linux Laptops for My Family

2026-09-08T00:00:00.000Z

Original post

A belated happy five years to Universal Blue, and how wanting laptops my family could actually live with turned me into an open source maintainer.

This is my personal site. Opinions here are my own and don't necessarily reflect those of Red Hat.

Maybe you saw that Universal Blue recently celebrated its five-year anniversary. Aurora, Bazzite, and Bluefin (the OG) all marked it with posts of their own. I’m thankful to be a part of the team that’s done such great work. I’m usually content to just get things done in the background, but it’s high time I share some of my thoughts about this project and organization we call Universal Blue.

When Jorge Castro made that initial commit five years ago, he was doing different things than we do today. He was running Fedora Silverblue or openSUSE MicroOS, using various scripts to shape the installation into his dream. It was a beginning.

I was in a different, but similar place. I could see the day approaching when my kids were going to need laptops for school, and they already wanted to do more gaming. I didn’t love managing Windows even for myself and didn’t want to manage multiple installs, but multiple Linux installs weren’t much more exciting. I was experimenting to find a solution to make supporting my family’s laptops seem less like sysadmin work, to find something that would “just work” instead.

My GitHub and private Git server are littered with repos full of old dotfiles, configs, Ansible playbooks and shell scripts. I was determined to pre-configure and automate all the post-install Linux things. For me, this “perfect Linux laptop” idea was brewing in 2021. That’s probably when I started to get a solid base of Ansible to manage my family’s Linux systems.

Though I’ve consistently been using Linux on the server for 30 years, desktop use has been more intermittent. “The Year of the Linux Desktop” is almost a perennial joke, and laptops almost always meant more pain than a typical desktop PC. It’s been decades since I bought into the religious wars of macOS versus Windows versus Linux versus BSD. At some point, pragmatism set in. I don’t really care which OS you’re running, but maintaining a fleet of laptops for your family is still a pain, except perhaps if they are all Chromebooks.

In November 2022, I stumbled across a blog post and video by Jorge. He’d been writing (and talking) about immutable Linux OSes, and at that moment he was comparing Fedora Silverblue and openSUSE’s MicroOS. MicroOS caught my attention as something I might use to make my family’s laptops a little bit more reliable. It promised something like ChromeOS that could still function as a normal system. I found it intriguing, but there were enough rough edges that I just couldn’t switch off the Ansible-customized Ubuntu which had become the in-home standard.

In December 2022, Jorge posted something magical. Fedora had released an experimental feature for Silverblue and Kinoite: container-native rpm-ostree. It meant we could have a custom built operating system image, but built like any other Docker image. I’d been living and breathing Docker images. I’d been running Kubernetes at home. I’d packaged applications in Docker images for work and home. The promise of pre-built application images, running the same thing everywhere, was now available as a custom operating system! I could bake in customizations for my family, fixes for all the quirks that normally I had to fix after an installation, or whatever I wanted. Maybe most importantly, all of the package and upgrade conflicts which inevitably occurred for any package management system were no longer an issue.

Quote

That whole class of problem would happen in CI, not on my laptop, certainly not on my wife’s or kids’ laptop!

And NVIDIA, oh, NVIDIA: the greatest love/hate of any Linux user who’d chosen to use it. Powerful and wonderful when it works, but often a pain to get going: NVIDIA would get the same treatment.

Fun fact, I’d used both Fedora Silverblue and CoreOS before, but I found them too restrictive without a better way to customize the defaults to have a better overall user experience. It’s kind of crazy that this turned around so quickly once I could participate in building the OS image itself. Container-native truly opened the door wide for new contribution in this space. It certainly did for me!

This is where I stopped watching what Jorge was doing from afar and got involved.

The ublue-os GitHub org and a Discord server had both been created. I joined the chat and saw them working on a pre-built NVIDIA kmod. I had some of my own custom images going, but I jumped in to help with that NVIDIA kmod; I had a vested interest in making it work. My first official contribution was on February 20, 2023. It wasn’t much, but Universal Blue was (and still is) a welcoming community, and I quickly became involved in more and more code reviews and code contributions. Not even a month later, I’d forked Kyle Gospodnetich’s serverblue repo into uCore, with his blessing of course. By then Kyle was fully invested in Bazzite!

The rest, as they say, is history! And frankly, most of the history is public record because all of our commits, issues, PRs and discussions are out in the open. It’s Open Source Software, after all. I found a passion for participating in the shared effort of building and maintaining our various Universal Blue projects; I stuck with it.

Quote

One day I looked up and realized, “oh, I’m a maintainer.”

Achieving that “status” was never a goal; rather, it was a natural progression. uCore became my primary Universal Blue project, and I’m practically its sole maintainer, though I’m also a core maintainer across all of Universal Blue, and a user of most of it. Working in the server space certainly matches my traditional interests, so I’m glad I can assist with the desktop projects but don’t need to carry that load alone.

Bluefin and Bazzite fulfilled the dream of Linux laptops that “just work.” Ansible ceased to be used for desktop/laptop management as the prebuilt images (bOS, my lightly personalized version of Universal Blue images) became the new home standard. My boys got Dell laptops with NVIDIA cards which enabled some 3D gaming as well as school, and maintenance was minimal, since those failures now occur in CI and never make it to the laptops themselves. My wife and daughter got a matching pair of HP laptops with AMD integrated graphics, better battery life and still some light gaming ability.

Quote

These systems just keep updating.

Are there occasional hiccups? Yes. Is it massively easier to maintain than before, when every other update seemed to result in a broken NVIDIA kmod or some other issue? 100%! I confess the boys argued their way into Windows specifically to play a game which still doesn’t work on Linux with Proton, but they miss the Linux desktop and I think I’ll win them back soon.

There is another important thing. I want to say “thank you” to Jorge and Kyle. Each had their own dreams… Kyle’s vision was to bring the “just works” gaming experience of the Steam Deck to any desktop or handheld, while Jorge pushed for the “just works” experience of a Chromebook but with more power and flexibility. Kyle, Jorge and I worked and gamed together, and Kyle would sometimes join me and my boys for gaming sessions. I wasn’t always sure how to relate to Jorge’s ambitious goals, but he challenged me to think bigger. Beyond these two, a whole group of people came together as friends and teammates to support each other personally and technically as we built the various Universal Blue projects.

Quote

This team has brought dreams to life.

One of those dreams has been to get people jobs! Most of us did this work outside our day jobs. Eventually some folks set up sponsorship via GitHub, etc, and that’s been awesome to help offset the costs of development, but day jobs pay the bills. The community and network Jorge built here has been excellent in that regard. Contributors to Universal Blue at different career stages have found their way into new opportunities at several different software companies. I’m one of them. My fairly recent start at Red Hat is a great example. My previous years of experience were crucial, but learning specific technologies and Open Source methodologies with Universal Blue provided a direct path to what Red Hat needed. So when I say I’m thankful for this project, and for the opportunity to participate, I mean it. My Universal Blue experience had already been personally and technically rewarding, but finding a job in Open Source through this project experience was next level!

Thank you to everyone who has contributed to a Universal Blue project, however big or small! Thank you for all the users! This has been a great adventure, and in the best possible way, I don’t see an end in sight.

Announcing mcp.projectbluefin.io

2026-09-07T19:00:00.000Z

Model Context Protocol (MCP) is an open protocol for LLMs and agents to talk to each other. We're now serving the Project Bluefin organization knowledge base and live factory state at https://mcp.projectbluefin.io/mcp.

Right now hive.projectbluefin.io exposes an API that has things that are useful for agents. We use it to dole out work to volunteers and to get review tasks. This is what's letting us scale out in ways we haven't been able to before. Hive has a nice Knowledge Base that it exposes, so this initial cut is to search that knowledge. This is mostly useful to connect whatever agent you use to our stuff and get context for your agent. So if you want to do Bluefin things you just add this. I've updated the Agentic Contributor Guide, note that our hive API endpoints are published, so if you're building a deep integration it probably makes sense to work with the Hive API directly. Feedback and usage notes welcome!

Endpoint Details

URL: https://mcp.projectbluefin.io/mcp
Transport: Streamable HTTP / Server-Sent Events (SSE)
Authentication: None (public, read-only)
Health Check: https://mcp.projectbluefin.io/health

Available Tools

Here's what's exposed:

Tool	Description	Parameters
`search_knowledge`	Search Project Bluefin knowledge base: engineering patterns, test coverage gaps, CI conventions, and repo findings across `projectbluefin/*`.	`query` (string, required) `limit` (integer 1–25, default 10)
`get_factory_status`	Live factory status from Hive: hub health, active contributors, actionable items, per-tier limits.	None
`get_work_queue`	Live work queue and triage state from Hive: issues ready to implement and triage grouping.	`limit` (integer 1–25, default 10)
`get_index_status`	Operational health, record count, and timestamp of the published knowledge index.	None
`get_quickstart`	Onboarding checklists (`first-pr`, `run-tests`, `factory-gates`, `branch-rules`).	`topic` (enum, required)
`get_repository_map`	High-level component map, entrypoints, and branch targets for `bluefin`, `bluefin-lts`, `common`, `dakota`, `documentation`.	`repo` (enum, required)

Archaeopteryx August 2026

2026-08-31T00:00:00.000Z

Completed work

258

24 planned • 234 opportunistic

Contributors

0 first-time contributors

Activity

Completed work across the configured factory portfolio.

Daily merge calendar

Daily merged pull requests

541merged pull requests

Source: GitHub GraphQL · August 2026 UTC (2026-08-01 to 2026-08-31)

Show the numbers

Bluefin: Welcome to the Jungle

2026-08-27T22:45:00.000Z

wolves.projectbluefin.io

A follow up to The Future of Bluefin - Time to be Honest.

The Future of Bluefin - Time to be Honest

2026-08-27T05:13:56.000Z

Alright everyone we've heard the feedback. You'd like to press X to pay your respects and get to work. Start the Q+A please!

Reaffirming our Commitment to Upstream Kernel Development

2026-08-21T02:21:50.000Z

Earlier this month Ahmed Adan and the rest of the Dakota team worked to bring the Open Gaming Collective kernel as an option for Bluefin's new "Gaming Mode". These kernels are explicitly designed to ship greg k-h's kernel and only ship patches that have a path upstream.

Here's some context:

ghcr.io/projectbluefin/dakota-gaming:testing (and stable)
ghcr.io/projectbluefin/dakota-nvidia-gaming:testing (and stable)
Gardiner Bryant's Coverage
Bazzite Announcement

The Wolves Are Coming

2026-08-17T03:23:14.000Z

Jorge Castro 🇵🇷 🦖@castrojo.bsky.social
Three years ago today. Nova they won't let us down, I promise.
Aug 17, 2026, 3:18 AMView on Bluesky

Bluefin Gaming Mode and Dakota Alpha 5

2026-08-03T00:41:00.000Z

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.

The world has changed! Here's the good stuff.

What it comes with

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!

Open Gaming Collective

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.

And I'm sure I missed some.

How to Get It

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.

Image	Stream	Command
Gaming	Stable	`sudo bootc switch ghcr.io/projectbluefin/dakota-gaming:stable`
Gaming	Testing	`sudo bootc switch ghcr.io/projectbluefin/dakota-gaming:testing`
NVIDIA Gaming	Stable	`sudo bootc switch ghcr.io/projectbluefin/dakota-nvidia-gaming:stable`
NVIDIA Gaming	Testing	`sudo bootc switch ghcr.io/projectbluefin/dakota-nvidia-gaming:testing`

ISO Downloads

Jovial July 2026

2026-07-31T00:00:00.000Z

Completed work

126

19 planned • 107 opportunistic

Contributors

0 first-time contributors

Activity

Completed work across the configured factory portfolio.

Daily merge calendar

Daily merged pull requests

553merged pull requests

Source: GitHub GraphQL · July 2026 UTC (2026-07-01 to 2026-07-31)

Show the numbers

Bluefin's Sausage Factory

2026-07-28T01:06:00.000Z

RELEASE SOUNDTRACK TO HUNT BYThe Forbidden Factory

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.

Under the Hood: The OCI Toolchain

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.

Practical Walkthrough: Adding an Application

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:

ChairLift’s Applications view.

ChairLift’s Maintenance view.

ChairLift’s Updates view.

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 dnf5 install -y ) 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.

Change Processes

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!

Two Eras of OS Engineering

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.

The Final Shape

Shove your Linux dreams in git

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.

The DevOps Part

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.

This is not a dunk

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!

Why Bluefin is all in on agentic development

2026-07-23T20:48:00.000Z

Is AI good or bad for open source? This is 58 minutes of me explaining what I've learned on this.

If you're here for the hot take: Are we really all on the same side? There are two worlds in Linux. What reddit/masto/youtube thinks "Linux" is. And then how Linux actually is.

Our value to our users is that we give you Linux as designed by the professionals. The flex is leveraging the collective knowledge of the community. New users have been led to believe that shipping three-year-old kernels and old software is the right way to consume Linux. Good luck with that. When it comes to my Linux, we listen to Lennart. We do listen to GNOME developers. Linux is about choice. We choose a well-designed system and thank the UNIX gods every day that we don't have to deal with that stuff.

We choose not to let people dictate to us how to use our computers. The science is out. The experts have spoken. I've been fortunate to have access to Greg K-H during his time, and we spent a long time discussing how this affects our communities. And he's right. The damn things are finding bugs. And I'm tired of Linux's bullshit. And I mean that in a loving manner. 90% of this crap is passing a 0 or 1 to some silly argument because Asus hates you.

We've got new territory to explore and we're moving quickly. My lesson from six months of AI is "Seven Days to the Wolves". Where will we be when they come? I've been doing this job a long time and it took me fifty-eight minutes of Puerto Rican mansplaining and a cloud-native symphonic metal musical to explain it. LOL.

Five Years of Bluefin

2026-07-21T16:09:23.000Z

First let's celebrate. It's five years of Bluefin and Universal Blue! Thanks for riding with us. Starting later this year you can join Bluefin, Rafael, and the rest of cloud native as Bluefin comes to your hands.

We're proud to announce Seven Days to the Wolves, a comic and musical series set in an alternate future where Maintainer-Guardians fight alongside users for survival. We hope to expand this into the world's first cloud-native musical to be performed live at KubeCon (We have goals!).

In the meantime, enjoy this multi-hour metal maelstrom of death and destruction. #stopjohnbazzite

BLUEFIN: SEVEN DAYS TO THE WOLVES

Will you be ready when they come?

Parts of the story will be dropping over the next few years and will star some of your favorite OSS heroes!

The Great Migration

We're in the process to moving to the factory to build Bluefin. This process is opt in and will be a transparent to most of you. The TLDR is you'll see your image name change from gchr.io/ublue-os/bluefin to projectbluefin/bluefin.

It's midsummer so not a bunch of changes on the images. We'll work on this in 2H2026 so for now there's no need to worry, just chill and enjoy your Linux!

Bluefin

Let's start with Bluefin.

The new Bluefin is a tad smaller. We're dropping the dedicated DX images, everything we support is in brew now and is operating system agnostic. We aim to ship the most popular developer environments in cloud native and hope you give us feedback on things. ujust devmode is the CLI and remains unchanged.

Don't expect many changes here other than moving to sealed images at some point. projectbluefin/bluefin:next is in place if anyone wants to start working on that.

Anyone who is interested in driving forward with the Fedora base images is encouraged to work here. This is also the first time this Bluefin has an aarch64 version!

Bluefin Repo

Bluefin LTS

Bluefin LTS has also moved over to the factory. Bluefin GDX users have been moved here already. Nothing to report, though we turned off the ISO downloads to the old versions so people don't get confused. Once everything is set here we'll relaunch new ISOs.

Not much to say here, I'm mostly here for the fuzzy brown guy. Bluefin GDX has been retired as an image, the proper Nvidia tools are on the nvidia images themselves, and most of what was "GDX" is now in userspace with brew and containers, enjoy!

Bluefin LTS repo

Dakota

Dakota is our latest and most sophisticated raptor, featuring the cutting edge of Linux desktop development. It's built from GNOME OS using BuildStream.

Most of the work I've been involved with this cycle has been working on this. (And failing lol). Ahmed and Jordan just got the builds online and we'll probably do another alpha later this month. Things are really great here and I spent some time with the GNOME OS and systemd folks in Berlin this summer to ensure we're on the right track.

James and I worked on the ISOs this cycle, and we finally have one unified ISO that covers Nvidia/AMD/Intel on one ISO. Needless to say this is my raptor of choice and I'm hoping to play with more builds this weekend. Once the builders are up I'll start work on Bluefin's "game mode", offering the very best of OpenGamingCollective's tech.

Dakota repo

Bluefin and The Forbidden Factory

The "factory" is a culmination of everything we've been building. I guess it'd be the equivalent of "Universal Blue 4.0". It's simultaneously the most important change in Bluefin's history, and the most invisible! Also spoiler alert it's the second comic!

It's a combination of the server OS, FSDK containers, Kubernetes, Argo, BuildStream with Buildbarn, and everything you need to build Bluefin "on the spot". Basically, instead of "the OS" consider the entire toolchain "the product". Unlike the old methods, this new factory is all about leveraging clankers and putting them to work effectively via hive.

The Factory is a result over about a year of convergence with many groups. We've assembled GNOME 50 desktop tests and have started work on KDE. We test everything in this thing. Each test runs through a full suite. Checks everything, network, apps, and other functionality. We can finally automatically test everything and then post a screenshot at the end of the test.

Fully automated testing

The screenshot you see on the Bluefin releases will be the real release on your computer. Every default app will be tested and will have evidence backing it up. If a e2e test doesn't pass, no Bluefin that day. Computer running weird? Run ujust report and submit the issue and a clanker will go figure that crap out. Life's too short.

And not just Bluefin. We're throwing everything at this thing. Aurora, Bazzite, Fedora Silverblue, Zirconium, GNOME OS. Every time there's a published image we run a battery of tests on it. We are not yet doing visual recognition - this is to catch visual regressions. Right now we're just hoping someone on a testing build is paying attention. It's encouraging to see members from bootc and the UAPI Group working in this space. The idea is to have a completely manageable, reproducible, and sovereign system to run everything, not just a few desktop images.

The Factory dashboard is one of the best ways to see whether an image is actually ready to ship. This is meant to expose more broken things before they reach you. Check out the Hummingbird public meeting this Thursday, where I hope to present on the components in more detail!

I'll also be doing a complete factory tour and explaining our experiences with agentic development. I look forward to moving faster here! I spent a good deal of time on the charts:

Factory snapshot · July 20, 2026 snapshot

The dashboard is live, so those numbers will move after this post ships. The Factory dashboard and its underlying data are the sources for this snapshot. We'll continue to add information here over time!

Freedesktop SDK Containers (Alpha)

Every factory needs purpose-built containers. Since the goal is a fully offline, self-contained build system, we built our own — carved from freedesktop-sdk components using the distroless playbook. 90% of "distroless" is deleting all the docs and not providing shells. We're able to do this quite easily with BuildStream

BuildStream is amazing

I was able to make a mostly functional OS in about 45m with BuildStream. Bluefin will continue to move in this direction since it's clearly got the community momentum we're looking for.

The current images range from a ~40 MB distroless base (glibc, coreutils, CA certs, tzdata) up through distroless Python, Buildah, and Skopeo variants. I also made an omnibus lab-runner with kubectl and a few other tools in one convenient package and a shell for ops work. Two prototypes are worth calling out:

Homebrew nspawn container — a Homebrew developer environment packaged as a systemd-nspawn machine image rather than an OCI image. The systemd folks think this approach is worth investigating, and this is the result of some beer drinking in Berlin. I haven't tried it yet but if you're one of those distrobox-adjacent folks it might be interesting for you.

All images are keyless-signed with Sigstore Cosign and include BuildStream-native SBOMs. Tags track the FSDK point release. The actions are easy to copy — fork and go, no key wrangling required. I am finding the base images to be quite good, and in general I find the fsdk containers to be a nice alternative to Chainguard and other distroless images. For us the benefits are simple, these are the same libraries as the operating system so it doesn't cost us much to make these.

Bluefin Server (Alpha)

Bluefin Server v25.08.13 targets the same space as Flatcar Container Linux, Fedora CoreOS, and Talos — but is built from scratch with BuildStream 2 from freedesktop-sdk components. This one was kind of an accident. I needed a server OS for the new homelab and there wasn't an easy way to get a newer kernel in Flatcar. Since we have BuildStream, making this was pretty straightforward. This is basically the Dakota setup without the desktop.

The OS payload is a compressed XFS DDI filesystem deployed by an offline, systemd-native installer. This is using systemd's new interactive installer. Burn it to disk and run through it and then you're done.

Key properties:

DDI image-based updates with atomic rollbacks via systemd-sysupdate
Minimal, distroless rootfs — going to shoot for no shell by default with a GUI but we'll see how far we get on that
k3s for kubernetes available as a systemd-sysext
GPG-verified SHA256SUMS, BuildStream-native SBOMs, keyless signing throughout, all that crap
Currently on the GNOME Desktop kernel but I am shopping around, since we're using UKIs swapping out kernels is easy

Alpha 1 is live. Beta comes after the 26.08 FSDK bump next month. KubeStellar dashboard integration is in progress but not ready yet.

Testsuite: Full Desktop and Image Coverage

Bluefin's automated test suite is the quality gate between an image build and promotion. It runs headless Wayland desktop sessions in QEMU on standard GitHub Actions runners and can be supplemented with any hardware.

What it covers

Here's what we've got working on so far. Shoutout to Christian Schaller at Red Hat for guidance:

smoke — core GNOME, Settings, MIME handlers, accessibility, desktop identity, Orca, input methods, keyboard layouts, XWayland, ScreenCast, screenshot portals, Online Accounts, and printing
common — portable SSH health checks for Flatpak, portals, polkit, shell behavior, immutability, and system health
vanilla-gnome — upstream GNOME OS baseline
developer — Homebrew and Ptyxis on developer variants
dx — VS Code, distrobox, JupyterLab, and mise
software — Bazaar app-store behavior and Flatpak CLI health
lifecycle — bootc upgrade, rollback, and migration
security — Cosign signature verification
hardware — udev rules and emulated peripherals
bazzite — Bazzite-specific extensions
flatcar — Flatcar OS boot and lifecycle

The smoke and common suites are designed to run against any GNOME bootc image so feel free to take it for a spin.

How it works

Behave runs the Gherkin scenarios and step bindings
qecore-headless bootstraps the Wayland and D-Bus session
Dogtail drives the accessibility tree through AT-SPI
gnome-ponytail-daemon provides coordinate injection for Wayland
GNOME Shell Eval handles the GNOME 50+ top-bar fallback
Shared SSH steps assert system state from outside the VM
Dynamic suite sharding distributes large smoke and common runs
Coverage counts and screenshots publish to the Live Build Health Dashboard

We'll continue to expand it as some tests are better than others.

Reusable integration

Image projects can call the reusable e2e.yml workflow or the gnome-e2e@v1 composite action with an OCI image, selected suites, a test ref, optional native-app skipping, Flatpak screenshot IDs, zstd:chunked coverage, VM memory, CPU count, and disk cleanup. The suite also provides reusable ISO validation for downstream projects. None of this has been tested outside of myself so if you're diving in get ready to get dirty!

Local development uses Python 3.14 with behave, qecore, and dogtail; full GUI runs require a live Wayland and AT-SPI session. The repository includes Argo and KubeVirt plumbing, a coverage dashboard, Codecov reporting, Flatpak caching, and the container images used by the test jobs. (The whole enchilada!)

Successful run · 4 / 0 / 4 Failed run · 3 / 1 / 4

Does this mean I'll get less bugs?

Yes and no. Most of these aren't blocking yet. A few of them catch issues you've reported in old-bluefin. Some of them give us capabilities we've never had, like mass upgrade testing.

If we had perfect Linux tests no one would ship because the entire desktop stack is a tyre fire lol. However with better, more automated testing we can get to where we need to be!

Suncatcher

Bonus wallpaper from Natalia and Delphic!

The Lab, Actions, and Finpilot

projectbluefin/lab is the "everyday" part of the lab. It contains everything I am running in the homelab to test Bluefin, etc. It runs image and ISO tests in KubeVirt, handles graphical checks on the lab hardware, and collects screenshots and results that can be attached to a build. That lets us validate the thing people actually install, not just the container build that produced it. These tests are additive and listed on the website.

We're adding these as gates, which means when a contributor merges something it will land in a testing branch. Then as part of the release processes all of these tests run. The lab repo is for people who want to add their homelabs to help with Bluefin. It's messy in there, but if you know K8s, help is always wanted!

The intent is for these to be driven by GitOps, which means no access control or people connecting to remote servers, your agent either opportunistically finds work or is assigned work from hive. Lab repo

projectbluefin/actions is the shared build layer behind the factory. Repositories can use the same workflows for bootc image builds, multi-architecture publishing, signing, SBOMs, and release metadata instead of each project inventing its own supply-chain plumbing. This is the sort of infrastructure that is invisible when it works, but it is what makes the rest of the factory repeatable. These actions are all new and heavily centralized, so if you want your custom image to use the latest tech, check out this repo.

finpilot is still there and now has a new maintainer! This hasn't been integrated into the factory but it's working pretty great. finpilot repository

Merch

The Bluefin store has a couple of especially good ways to rep Bluefin. All of the proceeds go towards artwork, and the kid's shirt is priced the lowest we could make it.

Dakotaraptor Forever

Celebrate the stable release of GNOME OS in the official Dakotaraptor shirt.

Shop the shirt - from $23

Bluefin Official Shirt

First among equals, the leader of the pack, in a soft everyday tee.

Shop the shirt - from $25.50

Bluefin Women's Rawr

Stabby stabby stabby - a relaxed-fit everyday tee with a little more raptor energy.

Shop the shirt - $16

What's next

The 26.08 FSDK release is next month and Dakota's looking to move to beta so there's plenty to do. In the meantime enjoy your day and rock out to some Wolves metal! Then we cycle into Fall.

As always thanks for joining us and keep on rocking! Feel free to ask questions, we covered a ton!

Organizational Migration for Bluefin LTS/GDX

2026-07-02T13:00:00.000Z

Hello guardians,

We're starting the transition away from ublue-os/bluefin and bluefin-lts to projectbluefin. This is part of the move to factory.projectbluefin.io. I'll have more details over the next few days. It's our fifth birthday on July 21st so in a way we're kinda relaunching Bluefin. I hope to post updates between now and then so that we can party after.

tldr: GNOME 50, newer kernel support, cleaner OCI layers, NVIDIA as a proper separate image, no more -dx/-gdx images, all userspace baby! You don't do anything but hang out.

LTS and GDX users, this one's for you, the rest of you will come later. GDX's builds have been struggling so you're going first. Thanks to those who tested; we found real issues that have helped the project.

Upgrade Instructions

There are none, this will happen automatically.
If your Linux Lizard Brain starts to want to jump out of your skull please follow the manual directions to upgrade

`ublue-os/bluefin-lts` → `projectbluefin/bluefin-lts`

The biggest change is image consolidation, DX/GDX images have been merged:

"Bluefin DX" will be moving off of images and into userspace with ujust devmode, if you're missing anything please file an issue.
"Bluefin GDX" will also be moving to userspace with "ujust aimode", but this doesn't exist yet.
aarch/amd64 all across the board, even ARM/Nvidia hell yeah! (It's Ampere time!)

We're also adding hooks for the IDEs/tools in Bazaar to highlight some of these. So instead of images these will just be modes you can add on. One of the reasons we were struggling with GDX is the GitHub runners didn't have enough space/resources for something so large.

CUDA can now just be consumed via containers - the ujust aimode will look just like the developer mode but we'll have options for pytorch, etc. If you're on an AMD machine you might have seen the preview in bctl

Wow that's ugly! Now you see why we hid it, but you get the idea, start thinking of bundles. bctl is short for bluefin control but probably won't expose it, centralized just is just too good.

OCI Things

These images use chunka to create smaller layers, and LTS was already svelte. This brings us in full upstream alignment with bootc.

Signing: We moved from keys to Keyless OIDC (Fulcio/Rekor), ensuring that my shame will live on in the past. This is nice for custom image builders too, no more pub key in your root and pasting in github secrets to get going. Savage. Not fully implemented yet, but still working on it.
SBOM: Each image has full SBOMs etc, I'm still working on these, but both of these steps are modelled after proper usage according to upstream. The docs, website, and ujust changelog will source from these if they aren't already.

The end state is any version of anything that you see on the website should be what's on the latest image and not manually updated.

Kernels

No one was using vanilla Bluefin LTS (who wants to use 6.12 lol) so we've consolidated everything onto Fedora's kernels

Other

GNOME is now 50 across the board
:testing branches will land all code, if you're a nerd hop onto these
These images are a huge improvement, especially with our testing suite (more info later), however you will for sure find cosmetic issues since we tend to ignore those until the end lol.
Please use ujust report, even for minor issues!

Migration Schedule

Legacy Image	Auto-Migrated?	Target	Status
`ublue-os/bluefin-gdx:lts`	Yes, automatic	`projectbluefin/bluefin-lts-nvidia:stable`	Canary rolling out now
`ublue-os/bluefin:lts`	Soon	`projectbluefin/bluefin-lts:stable`	After canary validates
`ublue-os/bluefin:lts-hwe`	Soon	`projectbluefin/bluefin-lts:stable`	After canary validates
`ublue-os/bluefin-dx:lts`	Soon	`projectbluefin/bluefin-lts:stable`	After canary validates
`ublue-os/bluefin-dx:lts-hwe`	Soon	`projectbluefin/bluefin-lts:stable`	After canary validates

Feel free to ask questions!

Source Discussion

GitHub Discussion #4802

Juravenator June 2026

2026-06-30T00:00:00.000Z

Total Items849 (152 planned, 697 opportunistic)Automation39.4% (551 bot PRs out of 1400 total PRs)Contributors16 total, 0 new

Desktop

GNOME desktop environment, Aurora variant (KDE), and terminal enhancements

Planned Work

fix(motd): build umotd from source, move to shared layer, remove legacy ublue-motd by @castrojo in #744
fix(ux): toggle-user-motd exits 0 when user declines and fix fall-through by @castrojo in #662
fix(ujust,gnome): fix changelog repos + LTS support + BT auto-switch by @castrojo in #543
fix(gnome): open documentation link as local PDF with browser fallback by @castrojo in #637
test(bling): add bats coverage for bling.sh by @castrojo in #629
test(scripts): add bats coverage for ublue-motd and profile.d scripts by @castrojo in #628
chore: simplification audit — remove dead weight, harden edge cases by @castrojo in #569
feat(ghostty): add GNOME profile for new users by @castrojo in #548
feat(fonts): set Adwaita Mono as default monospace, move opendyslexic to Homebrew by @castrojo in #547
feat: replace logomenu with custom-command-menu extension by @castrojo in #514
fix: add help: URI handler to redirect to GNOME help website by @castrojo in #509
fix(bling): skip brew bundle when bluefin-cli disables bling by @hanthor in #362
feat: replace old MOTD with umotd by @castrojo in #489
fix(#266): drop monospace-font-name override — use GNOME default (Adwaita Mono) by @hanthor in #348
fix: remove Readymade installer from dock favorite-apps by @hanthor in #353
feat: switch to ublue-os/aurorafin-shared by @renner0e in #395

Opportunistic Work

feat(brew): move CLI tools to brew-preinstall, remove starship image binary by @castrojo in #554
fix(ci): remove stale che/nerd-fonts COPR check by @castrojo in #502
feat(fonts): remove font RPMs and nerd-fonts COPR from OCI image by @castrojo in #476
fix: migrate custom-command-menu dconf to command1..N tuple format by @castrojo in #348
feat(build): add extension-builder stage to avoid build deps in final image by @castrojo in #333
security: verify starship binary checksum before extraction (CWE-494) by @castrojo in #173
fix(e2e): pin testsuite test_ref and restore shell defaults by @castrojo in #337
feat(fonts): remove jetbrains-mono-fonts-all from OCI image by @castrojo in #144
fix(packages): remove che:nerd-fonts COPR install by @castrojo in #79
fix: migrate custom-command-menu dconf from entryrow* to command1..N tuples by @castrojo in #76
fix(ci): use epel-10 chroot for jreilly1821/c10s-gnome-50 COPR URL by @castrojo in #55
fix(hive): hero font rendering + more sparklines by @castrojo in #919

Dakota (GNOME OS Prototype)

feat(fonts): remove jetbrains-mono from image, manage via Homebrew by @castrojo in #763
fix(gnome-ponytail-daemon): use systemd.bst for systemd.pc pkgconfig by @castrojo in #725
feat: add gnome-ponytail-daemon to image by @castrojo in #618

Development

Development tools and IDE integrations

Planned Work

feat(dx): add tuna-os/Tavern flatpak to DX mode by @castrojo in #792
feat(bluefinctl): wire ujust recipes to bctl + move caffeinate to profile.d by @castrojo in #730
feat: rewrite toggle-devmode to be standalone DX mode by @castrojo in #545
fix(dx): move vscode extension installs to Brewfile by @castrojo in #635

Opportunistic Work

Bump dockerd to 29.6.1 by @jumpyvi in #460

Homebrew

Package Updates

36 automated updates this month via GitHub Actions. Homebrew tap version bumps ensure Bluefin users always have access to the latest stable releases.

Quick Summary

Tap	Updates
production-tap	30
experimental-tap	6

View all production-tap updates (30)

Megalosaurus May 2026

2026-05-31T00:00:00.000Z

Total Items290 (33 planned, 257 opportunistic)Automation53.4% (332 bot PRs out of 622 total PRs)Contributors37 total, 17 new

Desktop

GNOME desktop environment, Aurora variant (KDE), and terminal enhancements

Planned Work

fix: removing search-light from the enabled extensions until there's a fix by @pfanzola in #324
feat: Add gradia flatpak and remove shortcut by @coxde in #335
Revert "feat(bluefin, gschemas): specify mutter experimental features… by @coxde in #321
fix: update bazaar refs to new bazaar-org location by @castrojo in #337
fix: removing tailscale from the enabled extensions list by @pfanzola in #323
fix: adjust font size to match upstream by @ehsanullahjan in #309
feat(just): move powerwash to shared again by @renner0e in #328
fix: don't show failure message on bluefin-cli by @renner0e in #303

Opportunistic Work

fix: ensure xdg-desktop-portal starts after gnome-keyring-daemon by @leafyoung in #4539
feat(extension): Add gradia capture extension by @coxde in #4651
feat(ci): auto-bump GNOME extension submodule tags by @ahmedadan in #4577
feat(extension): add Custom Command Menu by @castrojo in #1367
feat(extension): Add gradia capture extension by @coxde in #1364
Correct errors in lazy-days wallpaper by @delphicmelody in #88
fix: correct errors in eyes wallpaper and optimize file size by @delphicmelody in #87
ci: verify wallpaper cask checksums on pull requests by @ahmedadan in #393
fix: correct kde and gnome sha256 for bluefin-wallpapers-extra 2026-05-09 by @ahmedadan in #392
🔍 fix(css): remove Arial font overrides — use system font stack (fixes #817) by @kubestellar-hive in #859
fix(tips): wire fetch-gnome-extensions into build pipeline and add tests by @castrojo in #846
blog: Bluefin Spring 2026 Part 1 — Fedora 44, GNOME 50, ASUS, new com… by @castrojo in #818
fix(tips): restore gnome-extensions fetch script and wire into build pipeline by @castrojo in #809
feat(artwork): sync lazy-days and other new upstream wallpapers by @castrojo in #781

Dakota (GNOME OS Prototype)

Remove command-order from 05-dakota-custom-command-menu by @StorageB in #584
fix: move Dakota wallpaper month selection to runtime by @castrojo in #526
patches: bump libgvc to fix gnome-shell audio port SIGABRT by @hanthor in #569
fix: remove search-light shell extension by @joshyorko in #515
fix(oci): correct ldconfig invocation — pass explicit conf path by @castrojo in #518
fix(oci): run ldconfig after package install in image assembly by @castrojo in #517
feat(menu): add Containers entry to custom command menu by @castrojo in #472
feat(extension): Add and enable gradia capture extension by @coxde in #483
bluefin: disable shell motd by default by @hanthor in #446
Drop gnome singed modules by @alatiera in #429
revert: "chore(deps): update gnome-build-meta junction: 50.1-9 -> 50.1-11" by @castrojo in #422
Remove command-order from 05-dakota-custom-command-menu by @StorageB in #416
fix(dconf): set ublue logo and leftmost position for custom-command-menu by @castrojo in #396
Update gnome and freedesktop-sdk junctions by @alatiera in #372

Development

Development tools and IDE integrations

Planned Work

feat(ide): add VSCode Insiders to ide Brewfile by @castrojo in #338

Opportunistic Work

fix: remove swtpm workaround, add ramalama alias, clean orphan modules by @castrojo in #4677
Adds ROCm Info utility by @DarkGhostHunter in #4661
docs(agents): slim AGENTS.md, add docs/skills/, integrate testsuite CI by @castrojo in #1373
fix(vscode): fix brew bump by using explicit linux string in URLs by @nklowns in #411
fix vscode cask by @inffy in #413
fix(vscode): disable built-in update checks for brew installs by @ahmedadan in #407
fix: icon for jetbrains toolbox and vscode by @dreamyukii in #396
Add Antigravity IDE cask by @hanthor in #400

Dakota (GNOME OS Prototype)

fix(ujust): dx-group — guard PKEXEC_UID, offer reboot by @castrojo in #597

Homebrew

New Applications

The following applications were added to our Homebrew taps this month:

Application	Description	Status
antigravity-cli-linux	Terminal interface for Antigravity agents
antigravity-ide-linux	AI Coding Agent IDE
antigravity-ide-linux	No description available
antigravity-linux	No description available
antigravity-sdk	Python SDK for building with Google Antigravity
vmbuddy	QEMU wrapper with sensible defaults

Use ujust bbrew to browse and install these packages. Follow the tap instructions if you want to do it by hand.

Package Updates

90 automated updates this month via GitHub Actions. Homebrew tap version bumps ensure Bluefin users always have access to the latest stable releases.

Quick Summary

Tap	Updates
production-tap	23
experimental-tap	67

View all production-tap updates (23)

Knuckle: Flatcar Container Linux for the Home

2026-05-28T13:00:00.000Z

Check out this announcement about Azure Container Linux GA. I won't be talking about Azure Linux 4.0. That's the "distro".

Let's talk about Flatcar Linux instead. This is an OS that's stripped down, designed for you to drop what you want on it. It is in the CNCF and a perfect fit for us. Every raptor needs a nest. Afterall, linux is linux. Our homelabs should be badass.

The Problem with Installing Flatcar (and CoreOS)

Both Flatcar Container Linux and Fedora CoreOS use Ignition for first-boot provisioning — a powerful declarative system that requires you to write a complete JSON (or Butane YAML) config file before you can install. There is no interactive configuration during install it's pretty nerdy. Basically for all intents and purposes, uninstallable for enthusiasts. For experienced Kubernetes operators this always-in-pain life is fine, but for homelab users and folks new to container-native Linux, it's annoying. And our mission is to help OSS developers which means, we cover all aspects. And from reading the room, I think a lot more people are going to want to self host. And so are organizations. This is why it has to be cloud native, you gotta have the server ↔ client goodness to compete.

It would be madness to create our own installer, so Knuckle just translates that stuff into something the Flatcar installer understands and then that's it. It's the real image. And we added some nice conveniences like choosing systexts. That's it. A pure vanilla brick wth a fancy ignition translator. What are you going to build with yours? Here's what we've been working on:

Enter Knuckle

Knuckle is a TUI "installer" for Flatcar Container Linux. It gives you an Ubuntu-server-style guided wizard that generates a valid Ignition config and passes it to flatcar-install — no hand-crafted JSON required. Knuckle is "basically Azure Container Linux (Home Edition)." but it's the upstream unbranded one with not many strong opinions.

We even wired in the sysexts and whatnot.

Note: Knuckle is pre-alpha software. It will wipe the target disk. UEFI-only; BIOS/legacy boot is not supported.

Why Flatcar?

Flatcar is an awesome OS, here's a list. I like it because it offers different stability channels, making it easy to canary test on clusters, etc. But it's also a great building block to build your server on:

Read-only system partition — dm-verity protected; eliminates a whole class of vulnerabilities
Automatic atomic updates — using the same mechanism as Google ChromeOS; atomic rollbacks supported, this is actually built with Gentoo upstream!
System Extensions (sysexts) — Extend your server with the Flatcar Bakery
Ignition provisioning — declarative first-boot config, shared format with Fedora CoreOS
No package manager — user workloads run as containers (Docker, Kubernetes) or sysexts; the OS itself never drifts
CNCF governance — vendor-neutral, community-maintained, built to outlast any single company's interest
Production-proven at scale: Adobe (18,000+ nodes), STACKIT (20,000+ nodes, their customers' most popular OS choice), and many more

People sometimes ask why we don't make a Server Edition. It's because we don't care about distributions it's all Kubernetes. :) And even if it fails at that we can prove people want it. But the nice thing about flatcar is it comes empty and is great for lots of projects. For me it's the last OS you install on your new server build. Problem solved, I have jellyfin to set up let's go!

Intent

This project is intended to spread the use of Flatcar Linux and Fedora CoreOS to the home enthusiast audience. Digital Sovereignty isn't just for nations, so we're going to use the tools nations use to make our lives awesome. We hope that this will live somewhere upstream and unites the CoreOS family.

Knuckle is feature complete, we won't be adding whizbang features, it's vanilla only and will only ever support vanilla. However ...

Bluefin Server?

Since this is all well designed cloud-native stuff: "upstream + opinion = product".

k8s configured for single node operation, easy to expand (you just set up another one)
Single webui to schedule whatever you want, say jellyfin, all the self-hosted stuff of your dreams
All that dashboard stuff you want to show off to your friends with
kubevirt out of the box, import your old VMs and redeploy on your new system.
Out of the box gitops so you can operate the entire cluster from version control
No CLI, No ssh, or kubectl access at all - entire cluster is API or MCP driven, magical tailscale integration
Standard industry gear, Kubernetes, Argo Workflows, k8s-mcp-server, bring your own workload

Now THAT is an opinion! I have a version of this running in my lab now, and we'll keep iterating, so start with ideas. It's still early days but I'm sure many of you will start prototyping with Flatcar, sky's the limit!

Get Knuckle

Download the installer ISOs from the GitHub Releases page:

Architecture	Download
amd64	`knuckle-installer-stable-amd64.iso`
arm64	`knuckle-installer-stable-arm64.iso`

SHA256 checksums and cosign signatures are published alongside each release.

SSH in as the core user with the key you configured
The OS updates itself automatically on the schedule you chose during install
Add software via sysexts (/etc/extensions/), containers (Docker/Kubernetes), or distrobox
Reprovision by re-running knuckle — no in-place mutation

Discussions

Gradia Capture Comes to Bluefin

2026-05-23T00:00:00.000Z

Screenshots are bug reports, social posts and memes. The faster you can capture the thing, draw an arrow at the thing and send it, the better.

Bluefin is rolling out an upgraded screenshot experience with Gradia and Gradia Capture. The Gradia Flatpak is built in and ready out of the box for new users (Existing users might need to install it in the Bazaar App Store, we'll figure out how to automate it, send issues!) and Gradia Capture hooks into GNOME's screenshot flow so the path from capture to annotation feels native.

Gradia Capture enhances GNOME's screenshot flow with annotation, OCR and Gradia integration.

Capture, mark up, send it

Gradia gives you the finishing tools that screenshots usually need before they are useful: text, arrows, censoring, padding and quick upload. Gradia Capture brings that into the screenshot moment with annotations and OCR text recognition, optionally you can hand it off to Gradia for further editing.

Gradia and Gradia Capture are built by Alexander Vanhee. If this saves you time, please send some support upstream. Supporting builders like Alexander helps keep that momentum going and helps modern Linux desktop like Bluefin keep shipping great apps out of the box.

💙 Support Alexander on Ko-fi

Discussion Thread

Making Our Own Fate: Dakota Alpha 2

2026-05-13T16:00:00.000Z

Part 4 of 4

Bluefin Spring 2026: Fedora 44
Bluefin Spring 2026: Part of a Growing Ecosystem
The Dinosaur and the Hummingbird
Making Our Own Fate: Dakota Alpha 2you are here

The Final Shape is here...

RELEASE SOUNDTRACK TO HUNT BYBluefin and the Lost Tribe of Contributors

Ok look we made another Bluefin. I know what you're thinking (especially you McPhail!). We got rid of Bluefin GTS and now the team decided to make another one. How many of these things are there, it's like a string of Jurassic Park sequels. First let's level set. The product is Bluefin. That's the default Fedora one.

Your favorite murder chicken is safe. We don't expect normal people to know what Dakota is anymore than we expect them to know what a Koenigsegg is. I can't even pronounce that name! We remain a project designed for cloud native practicioners, so we offer the very best tech the desktop has to offer. And there's good tech in BuildStream and GNOME OS, there's a compelling set of options here. This one just goes all in. I would not call yesterday's Fedora Hummingbird announcement a coincidence.

And now for the mysterious new raptor who keeps making waves:

Bluefin Dakota

latest-20260613June 13, 2026

Kernel7.0.7Gnome50.2Mesa26.0.6Podman5.8.2Nvidia610.43.02bootc1.16.0systemd260.2pipewire1.6.1flatpak1.16.6

View on GitHub →Image details →

Dakota is our newest "distroless" raptor. It's built from source and directly published as a bootc image, no traditional package manager involved at all.

Wait, this is just Gentoo.

Chris Aniszczyk, CTO Linux Foundation and former Gentoo contributor

Dakota features a more aggressive push away from legacy technologies, pure image mode only. Just the best desktop we can ship, direct from GNOME and Freedesktop SDK right to you. We remove the concept of "the Linux distribution" being a platform and the top primitive, the Freedesktop SDK libraries and Flathub are our platform. No compromises. Dakotaraptor is daily driveable and has quickly exceeded all expectations.

GNOME 50, Linux 6.19.x, Mesa 26.x, and Freedesktop SDK 25.08.11 libraries
systemd-boot, UKIs, UEFI only, compiled for the x86-64-v3 architecture level
Oxidized coreutils - same sudo-rs and uutils setup as Ubuntu - thanks to Canonical for funding this important work
Mostly feature complete, it's a full Bluefin
Custom Command Menu — Dakota features a newly refined menu. We hope to bring this menu to other Bluefins over time.
Ghostty as the default terminal

Since Dakota is brand new there's no users to transition when we switch something. We are switching to Ghostty as the default terminal. This has always been a fan favorite so we're starting with it fresh here.

Last I talked to Christian Hergert we discussed having ptyxis just use a libghostty backend. This is not only totally possible but would be the ideal situation! Someone please make this.

Changes since Alpha 1

Thanks everyone who helped test, you've done a great job!

LUKS encryption works on install
Full Nvidia Image
- nvidia-container-toolkit
Efficient layering - this image uses the upstream chunkah tool for more efficient downloads. We expect efficient delta downloads to land sometime this summer, but the infrastructure is in place now
Linux 7.x kernel will land once some of the bootc issues with 7.x are resolved
Beta target: Probably a month or so; GA target: Fall 2026
Want to help? GNOME OS upstream is always looking for help: os.gnome.org

Gotchas

And the big one. We cannot guarantee that this installation will be the final layout. GNOME OS is transitioning to systemd-homed eventually. That will mean either a manual transition or reinstallation. As such we likely will not go GA until this transition completes. We expect a lazy summer beta.

What now? It has been an absolute pleasure working with BuildStream over the past few weeks. The team has committed to the hardware necessary to make builds faster and the local development experience has been the best we've ever had. It has become clear and obvious to me that the combination of BuildStream and bootc brings a level of automation and developer experience that will be tough to beat.

Here's the hot take: If you look at all three raptors, all else being equal, the best development experience and best infrastructure always wins in this space. We have over a decade of cloud native industry experience to prove it, Kubernetes runs the world for a reason. This workflow is now in the Linux desktop space. I firmly believe that buildstream/bootc combined with our gitops approach will deliver a fantastic product.

Thanks to Brian Ketelsen and James Reilly for the Tuna installer. Yes they called it the Tuna installer. lol.

Thanks to Jordan Petridis, Valentin David, Adrian Vovk, Felicitas Pojtinger, and the GNOME OS team for their expertise and advisory roles - we couldn't do this without you!

Bluefin's Download Diet: Introducing Chunkah

Yes, they called the upstream rechunker "Chunkah". A rechunker is a thing we use to take an image and reslice it into more chunks. ghcr.io/projectbluefin/dakota is sliced into 120 layers instead of one big unresumable download for updates. It also takes content of the image into account. The idea being if you have components that update often, they would be group together in layers, and things that don't get updated often are group together.

That means if your computer doesn't need that layer for that update, it doesn't get downloaded. Additionally partial zstd:chunked pulls will complement the layering. This will mean that your computer will also only download the parts of the layers it needs. When combined this finally brings efficient downloads to the bootc ecosystem. Initial findings are looking good.

These alpha images are rechunked by Chunkah, but unified storage does not work on the composefs backend to bootc yet so it's not done.

Why tho? A Call to Action

After all that praise of an alpha product of all things, some may misconstrue this as abandonment of the other Bluefins or a lack of focus. Now let's talk about how we got here.

Disclaimer

This section is my opinion and does not reflect the views of the team, but is instead a reflection of my 20+ year journey working in Linux.

-- jorge

The Shoulders of Giants

Bluefin's mission is sustainaiblity, that means people. Bluefin LTS is there so we have a reason to bring people like Carl George and Shaun McCance into our ecosystem. Without Bluefin LTS Red Hat would not have as much of a financial incentive to help us out. We drive bootc forward, they invest in the software and sell it as part of their product. It's the Circle of Life, but with Linux. Red Hat did afterall, give us millions of dollars of engineering for free.

Same thing with Fedora, it's our line to that center of gravity. And we have a new approach with Fedora Hummingbird, attracting more people. It's not about the software, it's about the ecosystems we make along the way. Sounds like the kind of tripe the Linux Foundation loves to peddle! Dakotaraptor has one foot in the bootc world and one in the UAPI world.

Speeeeed

We will participate in both of those large ecosystems; that brings in the largest group of talent. Projects live and die based on the contributors that show up. We will always endevaour to work the best people at the cutting edge of Linux. We're ops people, mastery of all Linux is a requirement.

The CNCF Community via bootc, composefs, podman, and oras. The UAPI community bringing in the Linux userspace. Sounds great, let's go. Someone from Amutable please save me a shirt!

The Race to Sustainability

Colin Walters describes communities like this as "Centers of Gravity" - and we're all in one gigantic galaxy, everyone pulling and pushing around different ecosystems. All made possible by open source tools, amazing.

The state of Dakota Alpha 2 is impressive considering how few people it took to make it. For us our job is to make Bluefin as thin of a config layer as we can, our opinions are mostly in userspace anyway. It should be noted that this way is always cheapest. It is always cheaper to fix things upstream closer to the source. It's called "shifting left", yes there's a term for it lol. Welcome to cloud native.

It's here

There are those that will say that GNOME OS and KDE Linux make no sense, that's what distributions are supposed to do. I push back against that. 4% marketshare in 30 years is not a success story. And the ones that are growing are designed to be used as reliable clients and not package manglers.

Timothée Ravier once said, people don't want distributions they want experiences. And these operating systems will prove it. No one will ever give you a better KDE experience than KDE. That wasn't true in the past because distributing software over the internet was hard. Now not only is it much easier, these organizations can start greenfield with the state of the art rather than trying to adapt old techniques to the new world.

Best infrastructure wins. Fastest and cheapest development wins.

If you're into GNOME work on GNOME OS, if you're on KDE work on KDE Linux. If you like Fedora work on that. Make a friend, donate to an app developer.

Prove it, nerd

I will be discussing this in my talk at the Linux Application Summit: Making our own Fate: Why GNOME and KDE need operating systems - be there!

This is of course, all from our point of view.

GNOME OS would prefer we ship a DDI image. And some would prefer we don't exist at all and just sit as a systemd-sysext in GNOME OS. Sure, someone make one, we have buildstream, would you like fries with that? And with so many RPM-based people in the bootc world I am sure there are people who prefer that Bluefin just focus on being a Fedora with batteries included and nothing else.

But we are a forcing function - the dinosaurs are there to remind us that only the best survive the harshest ecosystems. This is especially true in the resourced starved Linux desktop ecosystem. We will continue to push. Some software is not going to make it. See you in the trenches, thanks!

It really is just a conspiracy

We built Universal Blue. Aurora, Bazzite, and Bluefin, as a team.

Then opportunites opened up for our contributors to work for organizations at the forefront of Linux. The Linux Foundation, Microsoft, Chainguard, Red Hat, and others. Driven to build around open standards but leaving room for commercial entitities to exist and thrive. And that's just the core team, as you can see from our contributor lists, the cloud native ecosystem is a significant center of gravity in open source.

You have proven that enthusiasts matter and can shape the future of the desktop. Level up your skills and organizations looking for open source talent will take you seriously, and in today's brutally competitive job marketplace, expertise in open source matters.

There's no right way to Linux, but there are certainly wrong ways to Linux. If you're new to Linux, welcome. We are your starter dungeon. We're your sysadmin team, nice to meet you, we've got your back. Greatness awaits. And also pain. Mostly pain.

Merch

Celebrate the release of a new top predator with our stylish "Dakotaraptor Forever" shirt.

Dakotaraptor Forever$23.00

Buy →

Bluefin Women's Rawr$16.00

Buy →

Universal Blue Polo Shirt$60.50

Buy →

Check out the rest on store.projectbluefin.io →

Download

Dakotaraptor Alpha 2

Alpha testing ISO — not for production use. 📖 Read the documentation.

dakota-live-alpha2.iso

AMDIntel

📥 Download ISO🧲 Torrent🔐 Verify

dakota-nvidia-live-alpha2.iso

Nvidia

📥 Download ISO🧲 Torrent🔐 Verify

The Resonant Assembly

One last group of people to thank. These community members participated in GitHub Discussions over the last six months. Asking questions, sharing tips, helping newcomers, and keeping the conversation going is just as valuable as code. Thank you for your help, it's important!

The Resonant Assembly

Filing Issues

Discussion Thread

The Dinosaur and the Hummingbird

2026-05-12T15:30:00.000Z

Part 3 of 4

Bluefin Spring 2026: Fedora 44
Bluefin Spring 2026: Part of a Growing Ecosystem
The Dinosaur and the Hummingbirdyou are here
Making Our Own Fate: Dakota Alpha 2

Hey, you know who is good at making "distroless images"? Distros.

Scott McCarty, Challenger of The Final Shape

It seems Fedora Hummingbird has been revealed. Of course Red Hat built this, modern infra demands modern images. All they had to do was put a kernel in there. So they did. It's awesome that this will be done in Fedora!

Red Hat's announcement

I had heard the rumors. But it wasn't until I put two and two together and realized that Red Hat had quietly hired two Universal Blue core maintainers. They will be on the team building this. In the open, along with everybody else. This will take them some time to cook, there is a ton of work ahead. But it's closer than you think. I was able to cobble together a prototype in a day. Most of what you're about to see was grabbing the Fedora RPMs and and smelting it together. But it worked. It booted just fine.

This is also the reason why we're not doing the stable->testing->next plan. We'll likely do more one off testing branches, but work on the sealed images and Hummingbird will attract the right kind of nerds to make this interesting. I think it's cool that they're putting this in Fedora. You have the evolution of the tried and true way + a continuous integrated option that can be the prototype for a greenfield Silverblue and Kinoite.

This does not exist (yet)

Well, I got what I wanted, a CoreOS style base image to have a true "CoreOS Desktop". So is Fedora rolling or stable? Yes.

I hope some of you step up and accept's Scott's challenge, we have an opportunity to do something brand new, chances like this don't come along often! A place for a cloud native in Fedora, I can't wait to see what Legends rise.

Bluefin Blog

Bluefin Server Alpha 2

Release status: Alpha​

How this works​

Quick start​

Contributing​

I Dreamed of Linux Laptops for My Family

Announcing mcp.projectbluefin.io

Endpoint Details​

Available Tools​

Related Reading​

Archaeopteryx August 2026

Activity

Daily merge calendar

Daily merged pull requests

Bluefin: Welcome to the Jungle

wolves.projectbluefin.io​

The Future of Bluefin - Time to be Honest

Reaffirming our Commitment to Upstream Kernel Development

The Wolves Are Coming

Bluefin Gaming Mode and Dakota Alpha 5

What it comes with​

Open Gaming Collective​

How to Get It​

ISO Downloads​

Jovial July 2026

Activity

Daily merge calendar

Daily merged pull requests

Bluefin's Sausage Factory

Under the Hood: The OCI Toolchain​

Practical Walkthrough: Adding an Application​

Option A: At the Shared Level (projectbluefin/common)​

Option B: At the Image Level (bluefin, bluefin-lts, dakota)​

Change Processes​

Two Eras of OS Engineering​

The Final Shape

Shove your Linux dreams in git​

A vendor-neutral, well-maintained toolchain makes your dream real​

The DevOps Part​

This is not a dunk​

Why Bluefin is all in on agentic development

Five Years of Bluefin

BLUEFIN: SEVEN DAYS TO THE WOLVES​

The Great Migration​

Bluefin​

Bluefin LTS​

Dakota​

Bluefin and The Forbidden Factory​

Freedesktop SDK Containers (Alpha)​

Bluefin Server (Alpha)​

Testsuite: Full Desktop and Image Coverage​

What it covers​

How it works​

Reusable integration​

Does this mean I'll get less bugs?​

Suncatcher​

The Lab, Actions, and Finpilot​

Merch​

Dakotaraptor Forever

Bluefin Official Shirt

Bluefin Women's Rawr

What's next​

Organizational Migration for Bluefin LTS/GDX

Upgrade Instructions​

ublue-os/bluefin-lts → projectbluefin/bluefin-lts​

OCI Things​

Kernels​

Other​

Migration Schedule​

Source Discussion​

Juravenator June 2026

Desktop​

Planned Work​

Opportunistic Work​

Dakota (GNOME OS Prototype)​

Development​

Planned Work​

Opportunistic Work​

Homebrew​

Release status: Alpha

How this works

Quick start

Contributing

Endpoint Details

Available Tools

Related Reading

wolves.projectbluefin.io

What it comes with

Open Gaming Collective

How to Get It

ISO Downloads

Under the Hood: The OCI Toolchain

Practical Walkthrough: Adding an Application

Option A: At the Shared Level (`projectbluefin/common`)

Option B: At the Image Level (`bluefin`, `bluefin-lts`, `dakota`)

Change Processes

Two Eras of OS Engineering

Shove your Linux dreams in git

A vendor-neutral, well-maintained toolchain makes your dream real

The DevOps Part

This is not a dunk

BLUEFIN: SEVEN DAYS TO THE WOLVES

The Great Migration

Bluefin

Bluefin LTS

Dakota

Bluefin and The Forbidden Factory

Freedesktop SDK Containers (Alpha)

Bluefin Server (Alpha)

Testsuite: Full Desktop and Image Coverage

What it covers

How it works

Reusable integration

Does this mean I'll get less bugs?

Suncatcher

The Lab, Actions, and Finpilot

Merch

What's next

Upgrade Instructions

`ublue-os/bluefin-lts` → `projectbluefin/bluefin-lts`

OCI Things

Kernels

Other

Migration Schedule

Source Discussion

Desktop

Planned Work

Opportunistic Work

Dakota (GNOME OS Prototype)

Development

Planned Work

Opportunistic Work

Homebrew

Package Updates

Quick Summary

Desktop

Planned Work

Opportunistic Work

Dakota (GNOME OS Prototype)

Development

Planned Work

Opportunistic Work

Dakota (GNOME OS Prototype)

Homebrew

New Applications

Package Updates

Quick Summary

The Problem with Installing Flatcar (and CoreOS)

Enter Knuckle

Why Flatcar?

Bluefin Server?

Get Knuckle

Discussions

Capture, mark up, send it

Discussion Thread

Changes since Alpha 1

Gotchas

Bluefin's Download Diet: Introducing Chunkah

Why tho? A Call to Action