[rvrb]

As someone quite happy with a vanilla Fedora Silverblue install on both my desktop and laptop, can anyone explain why I would rebase to Bluefin instead? It seems like there must be technical merit to the Universal Blue spins beyond adding preinstalled software/configs, but I can't find it, despite looking.

[cosmic_cheese]

Haven't used Silverblue or Bluefin but the way I've seen it explained is that Bluefin, Aurora, etc include a number of QoL and practicality adjustments that make them nicer/easier to live with as a desktop OS than baseline Silverblue is.

[nikodunk]

Yes! I used to use Silverblue too. Things like Tailscale, Docker, Davinci Resolve, nvidia drivers, and all codecs are a button-click away or already properly set up for you out of the box on the universal blue projects.

[jcastro]

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

[mixmastamyk]

Sounded interesting until you got to homebrew. Have you deactivated its telemetry? Also it talks to github often as well?

Like the dino theme.

[NewJazz]

Hmm so you don't use rpm-ostree? Or ostree at all? Sorry I'm just having trouble finding some of the technical implementation details, seeing a lot of details on the UX though.

[jcastro]

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.

[trogdor3000]

Boots currently relies on OSTree, you use OSTree enable base images. But the work is well on its way to transition to composefs which uses kernel native tech to replicate the features need from OSTree, so any systemd enabled distro can become bootc-able, for a bunch of example see: https://github.com/bootcrew

[joemccall86]

I can answer for me coming from the same boat... exactly zero risk to try, given how easy it would be to rebase back onto silverblue. I didn't have to worry about the codecs Fedora couldn't legally ship so I could remove an overlay, plus I figured bootc was the future and I wanted to see it working.

[rvrb]

Sure there is zero immediate risk, I just genuinely don’t know what I would get out of taking on the risk of adding a community maintained middleman into the supply chain. I know, because rpm-ostree, it’s not the same as some random distribution. If there’s nothing to get out of it personally that layering a package or two can’t give me (or better, writing my own simple image).. why?

I’m not saying there isn’t a reason; I’m genuinely looking for it