I'm sorry this is happening to you. I'm on the team that helped bring podman into the CNCF and I worked on ubuntu for over a decade, this isn't a technical problem this is a business one.
Podman is in universe, so Canonical doesn't care unless you pay. Fair enough, good engineers cost money. RH isn't going to pay.
Podman engineers would love to be in Ubuntu, the Red Hat engineers would love to directly upload into Universe. Everything in this thread makes sense, it's a matter of who wants to pay for it. End users have been asking for this for years.
The engineers don't make the decisions. Canonical doesn't want to pay, Red Hat doesn't want to pay. Users stuck in the middle.
I get podman from brew even on Linux because the idea that vendors fighting over uploading tarballs to a server is stupid. Fuck distros.
This memory bandwidth combo is amazing for homelabbers. kyuz0's work on these containers has made the investment in this kit so valuable I hope Framework is sending you hardware!
https://projectbluefin.io/server/ is what I'm hoping to ship, designed to just ship setups like this ootb and things like this would be so much harder without kyuz0!
(Note: The 64GB ones are going for $1700-ish empty, the prices on the 128's are outrageous we can just keep making the labs more deterministic over time!)
Lots of orgs have been documenting their moves to KubeVirt over the past year or so. There's KubeCon video recordings on the youtube channel from Amsterdam with lots of this kind of stuff, especially from european end users.
One thing I find consistent is orgs are also looking at the whole stack, this is just another major component of digital sovereignty.
Disclaimer: work for CNCF on this but worked on the first version of VMWare Tanzu so every announcement in this space is interesting lol.
Both approaches are indeed competitive, but you can also leverage both to achieve the same thing. We're experimenting with a pure ddi Bluefin, a buildstream/GNOMEOS one that spits out a bootc image, as well as a Bluefin that is just a systemd-sysext on top of GNOME OS. Chef's choice!
There will be many ways to slice this problem -- my opinion is that in the end it will be how you design the infrastructure to make these and not the artifacts themselves.
We already have CentOS/Fedora builds alongside these, long term we'll see which ones end up being the most efficient. Buildstream is a tool which people should look at in this space too: https://buildstream.build/index.html
> customized via a Containerfile could work too? Except rebooting/reimagine for every change sounds tedious as hell.
You can do this today with Aurora, Bazzite, Bluefin, and other bootc systems. The system updates by default are weekly and require a reboot but when you move most of the stuff into the userspace most of that stuff updates independently anyway.
> In one example I cite in my article, ChatGPT Agent spends fourteen minutes futilely trying to select a value from a drop-down menu on a real estate website
Man dude, don't automate toil add an API to the website.It's supposed to have one!
ostree is the library that rpm-ostree and bootc share. However bootc is moving over to composefs as a backend. This effectively makes it distro agnostic and there are communities forming: https://github.com/bootcrew
Fedora still uses rpm-ostree, when you do an update it's pulling from an ostree remote served from a server. bootc replaces that with just an OCI registry. We ship the `rpm-ostree` binary on the systems still. It's still used for things like adding kernel boot arguments.
Generally speaking new users can skip the rpm-ostree parts and just start with bootc. I am not an expert in this, there's a rust library in there somewhere. Hopefully someone can help fill in the blanks.
For Bluefin LTS we're in control of all the 3rd party repositories we use. We depend on EPEL but so does everybody else. I am unaware of any kernel patches that we are shipping since we ship the default CentOS Stream kernel and the optional hwe kernel ships CentOSs' kmod kernel.
Co-maintainer here. I dogfooded Silverblue for about 2 years before deciding to do this. Initially Bluefin was just a "fix me script" that did the usual bits. When bootc came around this let me put that script in GitHub CI and then just consume the fixes I want. A few of us started to do this and then since a bunch of us were kubernetes nerds we defaulted into "let's make this together."
Here are some of the changes:
- We add all the codecs, and drivers in the build step so the user never has to care.
- We turn on automatic updates by default, these are silent
- We remove Fedora's broken flatpak remote and go full Flathub out of the box
- We handle major version updates for you in CI, there's no "distro release day" update that's just a normal update that day
- Since we use bootc it's easy for people to FROM any of our images and make a custom build, and we ship a template for anyone to do so: https://github.com/ublue-os/image-template
- You can turn on "developer mode" which gives you vscode with devcontainers, docker, incus, etc in addition to podman.
- We integrate homebrew out of the box for package management for the CLI, flathub handles the GUI packages - we don't want to be a distro, in this world the base image is a base image and my relationship is with brew and flathub. I don't need or want to have a relationship with my OS.
- We gate kernel versions to avoid regressions, so we can avoid certain releases or "ride it out" until fixes are published.
- We ship [Bazaar](https://github.com/kolunmi/bazaar) - which is a flatpak only store designed for performance. Since the OS is a different layer we can throw away all those packagekit jankfests and start from scratch.
As for the desktop, I worked on Ubuntu for about a decade and wasn't happy with the direction Ubuntu was going at the time. Fedora had rpm-ostree/bootc but didn't know what to do with it so they were just sitting on the tech. So I just combined them, the desktop has an Ubuntu-like layout and vibe.
The clear benefit is that you have one image for everything, whereas local layering in Silverblue doesn't really make sense to me anymore, if you want to handle a bunch of local packages just use a traditional distro. Because doing that in Silverblue breaks just as often as it does in package distros. Pure image mode is the strongest benefit. It's 2025 I refuse to do "post installation crap" that should be automated, bootc lets me do that!
Co-maintainer here. When I saw one of these I immediately want to run Bluefin on it.
In spirit I would love to support this, someone with one of these would need to PR in support, but it's usually taking the enablement instructions from NVidia and putting it in a dockerfile. Bluefin is already working well on on the Ampere ARM workstations that System76 sells. Getting it on one of these would be awesome.
Hi Jeff, I'm a linux ambassador for Framework and I have one of these units. It'd be interesting if you would install ramalama in fedora and test that. I've been using that out of the box as a drop in replacement for ollama and everything was GPU accelerated out of the box. It pulls rocm from a container and just figures it out, etc. Would love to see actual numbers though.
No but Bazzite DX is almost done so we can start working on Bazzite GDX soon, which is going to be our game dev image. Though hopefully as more things become flatpak native ideally someday the idea of specialized images won't be so necessary.
No thanks I'll get it from podman.