Do an update, this was an error due to moving over to dnf5.

Yes, it's a container like an app container you would deploy on docker or kubernetes.

It starts with a dockerfile with a FROM fedora, the difference is there's an entire OS in there, with a kernel and everything. Then an action runs podman build on that container every day, which is then shoved into an OCI registry (in this case ghcr.io).

Then instead of each client doing package updates via a package manager it effectively does the equivalent of a podman pull on your laptop, and then stages the update for deployment on the device. Everything is running on the bare metal on the device, the cloud native part is the build process, pipeline, and delivery. Then rinse and repeat for updates.

It's a bit like rancherOS except using podman.

Yes, bootc containers are OCI containers, the major difference is there's a kernel in there.

Hi I'm the guy who posted the report. Your quote is exactly what it is, we use cloud native server tech to make Bazzite. Things like bootc, podman, OCI containers, etc.

all I want to run is a “normal” PC with a Linux distro.

That's exactly what's happening!

I don’t want is to have it running, or heavily integrated in some proprietary-ish cloud.

It does, just not ours, Valve runs that part. 😼 I'm happy to answer specific questions if you have any!

The entire purpose is to conveniently access your files, so if that's a problem use containers normally or pass a -h during distrobox create if you want to isolate home directories.

Hi! Universal Blue co-maintainer here, here's the TLDR. You've got the basic descriptions right, "Universal Blue" is mostly the parent organization that holds everything in github.

We take Fedora's Atomic OCI images and customize them for different use cases (Aurora, Bazzite, and Bluefin) and then publish base images so people can make their own versions of whatever they want. So if you wanted to take Silverblue, Kinoite, and make your own custom image you can mostly just grab whatever you want and shove it into an OS image. Bluefin started off as a "fix me" script for Silverblue that added all the stuff I wanted and then once I was shown what Fedora wanted to do with it the natural progression was to just make it a custom image. We just released 3.0 a few minutes ago actually!

Basically in Fedora 41 the tech will become more widely available with official OCI base images and better tooling. We just decided to start way earlier in the process so we could get all the automation out of the way, build a community, get familiar with it, etc. Happy to answer any other questions you may have!

ublue co-maintainer here. I go over a bunch of the reasons here: https://www.ypsidanger.com/homebrew-is-great-on-linux/

Namely we needed a way to complement Flatpak and brew was a natural fit. It's an ecosystem reason not a technical one. It has everything we need and a good deal of Bluefin's target audience are already using it on mac. So for us it's an easier lift to just add homebrew and move on to larger problems.

Plus it's nice that they're working with the openssf to secure the supply chain pipeline, and it's nice that everything is in github where we can inspect it, use the same tooling we use for the OS, etc.

I’m unclear how mature the project is and whether it will be updated in a timely manner long term

ublue and bluefin co-maintainer here, we've been around for a while now (3rd birthday coming up!) and have been around in a more unofficial capacity for longer.

Bluefin is feature complete and is in maintenance mode, it's just going to get updated in perpetuity to 41, 42, etc. We invested in automation first so most of the maintenance is automatic and it doesn't take much for our team to do it. Right now most of our major ticket items are waiting for things to finish landing in upstream Fedora, most of which are targetted towards F41. A good portion of the team have been around in OSS for a long time and a bunch of us work in the industry and depend on Bluefin for our jobs, so much so that we have a great working relationship with Framework, so we're supporting those laptops as a community option for them.

Aurora is relatively new, coming in just as Plasma 6 landed in fedora. Most reports with issues we get for it are things like it being a new major release, wayland/nvidia issues, etc.

Hopefully that answers some of your questions, if you have more feel free to ask!

installs all those things and sets things up properly on a standard fedora install?

That's exactly what all universal blue images do. It's just that setup is done every single day in github from scratch and stamped out as an image so that the end result gets to your computer as a finished deployment artifact. Leads to better update reliability, built in rollback.

The biggest benefit is that it's easier for a community to fix the fast moving gamer stuff as a config layer on top of a distro that's delivered this way than me having to manually figure out what component of my gaming setup changed that week.

I work on this image and daily drove it for a while. It's basically Matt Hartley's TLP power recommendations out of the box (we collaborated on this, he's the Linux support person at Framework)

I have an intel FW13 and now prefer the newer gnome-power-profile that we ship instead of the TLP-based recommendations. It has all the latest patches from upstream and it works great on both AMD and Intel systems. I don't personally have an AMD Framework but we have enough people using it to know that the gnome-power-profile setup is awesome thanks to AMD's contributions to gnome-power-profile.

Ideally a Framework image shouldn't need to exist

to make things more complicated Fedora is considering switching to tuned which is another, third power manager which should unify the stack. Universal Blue is currently testing this in the bazzite:testing branch of that custom image and we're hoping to get that feedback back to Framework. Hope this helps!

the package entropy over time will get me the very dependency issues that Flatpak wants to solve.

You can declare your distroboxes so that they get created regularly from scratch instead of upgrading in place: https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-assemble.md

That way the entropy never hits you. Then use the Prompt terminal https://gitlab.gnome.org/chergert/prompt to make it just part of your terminal ootb.

Author here. The distro comes with the filesystem compression and deduplication already set up and I don't need to manage it, so of course I'm going to use it.

Given the cost of storage I have no problems spending a barely noticeable amount of space to use flatpaks given all the problems they solve.