Comments URL: https://news.ycombinator.com/item?id=47582504

Points: 5

# Comments: 0

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!

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...

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?