3,486 karma · joined March 22, 2011
There's decades of this stuff.
No thanks I'll get it from podman.
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.
I'm working on a three node strix halo agentic OS factory designed to be maintained by local agents: https://github.com/projectbluefin/testing-lab
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.
We're working in this space with Project Bluefin: https://github.com/projectbluefin/dakota
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
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.
Man dude, don't automate toil add an API to the website.It's supposed to have one!
I agree, I hate all of this too. The wolfi version will be much better.
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.
Here's their diagram: https://bootc-dev.github.io/bootc/filesystem-storage.html
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.
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!
More info here since I'm leaving out a bunch of stuff: https://docs.projectbluefin.io/introduction
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.
And I like linux because there are plenty of people who also do not care about this and want to just use their computer.
Great work on this!