jcastro

5.7.0+ds2-3build1

No thanks I'll get it from podman.

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 is amazing!

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!)

There's nothing weird about container development, this is modern linux everything happens in user space.

A lot of work ahead.

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.

is currently converging on a different proposal by systemd developers that's standardized by the UAPI Group

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

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!

OS/2 my beloved.

I still don't even know what a DistGit or COPR is.

I agree, I hate all of this too. The wolfi version will be much better.

I would be in trouble if I didn't trust jreilly1821 since he's one of the Bluefin maintainers. And the nvidia binaries come from an nvidia employee.

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.

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.

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!

More info here since I'm leaving out a bunch of stuff: https://docs.projectbluefin.io/introduction

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 everyone! I built this 4 years ago as a passion project and now it's led to a culmination of things that led to release. Happy to answer questions!

just to move the clock from the center of the status bar to the side.

And I like linux because there are plenty of people who also do not care about this and want to just use their computer.

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.

Great work on this!

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.

Right, Bluefin is for container development.

Bluefin contributor here, why are you using homebrew that way? For development use a container.

Would love to see this for matrix!

Interesting, I don't think I've seen this in the wild (~30 million pulls across ublue) - but I think I've seen this issue mentioned before.

I'll bring it up during the next bootc meeting[1], which are public btw! Thanks for using bazzite!

1: https://github.com/bootc-dev/bootc?tab=readme-ov-file#commun...

An OSTree based atomic system is pretty close, although there is some added complexity.

The author mentions this as well but there's no details there. We've been shipping chromeos-style images with universal blue for over 4 years and the ostree parts are invisible to end users. What do you feel takes away from the user experience?

Such a cool project.

One of my fondest memories was making my own steamOS with Clear Linux: https://community.clearlinux.org/t/notes-on-building-a-clear...

And now I work on bazzite.gg, thanks for making a kickass OS Arjan and Co!

For the confusion around verified publishing, this is something the CNCF encourages artifact authors and their projects to set up. Here are the instructions for verifying your artifact:

https://artifacthub.io/docs/topics/repositories/

You can do the same with just about any K8s related artifact. We always encourage projects to go through the process but sometimes they need help understanding that it exists in the first place.

Artifacthub is itself an incubating project in the CNCF, ideas around making this easier for everyone are always welcome, thanks!

(Disclaimer: CNCF Staff)

Say, including the signing keys for Chrome's 3rd-party repo statically instead of fetching them over the network.

This is a fantastic idea, it sucks to have an upgrade blocked by a slow repo, if you wouldn't mind filing an issue or sending a PR I'd love to have this. Thanks for the feedback!

It uses 20 different copr repos (granted, half are their own), and I didn't count how many packages. Best I can tell, none of the versions are pinned.

Contributor here, we've been working on this diligently over the past cycle (the rest of the org is mostly done, Bazzite is largest so we're only getting to it now). We're hoping to be done over the summer with published SBOMs and all that good stuff.

comaintainer here, here's the docs for the arm build: https://docs.projectbluefin.io/lts#differenceserrata

Here's the issue for homebrew on linux/arm: https://github.com/Homebrew/brew/issues/19208

And here's the FOSDEM talk: https://fosdem.org/2025/schedule/event/fosdem-2025-6373-home...

Their answer instead was to refer the court to Destiny 2 YouTuber MyNameIsByf’s 10 hour video on Destiny lore

Hah this isn't just the court, everyone who plays this game has to watch YouTubers explain it because they don't do it in the actual game.