With uBlue you can fork the project, edit a containerfile, and you’re off to the races. That’s not something that Fedora lets you do.
Besides that point, how different are uBlue and Fedora in terms of the infrastructure used to deliver atomic updates?
Good question… I’ll take a stab at answering.
First, we don’t consider Universal Blue (uBlue/ublue/etc) to be a distinct distribution of Linux. This is Fedora, and depending on which flavor you install, it’s Silverblue, Kinoite, Sericea, Onyx, etc… (those listed are official Fedora “Immutable”/Atomic Desktop flavors).
Second, what uBlue does different from the official releases is that we’re taking advantage of a still (officially) experimental feature ostree native containers. This feature was originally slated for Fedora 38 but now for Fedora 40. It works quite well, but for full distribution support, the Fedora team is working to cleanup rough spots, etc.
More technically, the difference is that container images can be used as the remote storage and transport mechanism, rather than the ostree specific repos which had been used. However, on the user’s system, the differences are very limited. The main difference is the different remote URL one sees.
Regarding infrastructure… Fedora has to host their bespoke ostree mirrors with partners, etc… but for ostree native containers, we can use any container registry to host the images. The uBlue project uses Github to provide Continuous Integration and build automation, plus the Github Container Registry (ghcr.io) for hosting our images. As a DIY user who wants to build things on their own, one may choose any registry, including one self-hosted at home.
Certainly we’ve put an emphasis on using “cloud-native” tooling, CI, Containers, etc to build our extension to Fedora.
Also, while any user can DIY it if they desire, and we try to keep a core set of images suitable for further customization, much energy has been put into the “ready to go” desktop Bluefin and the gaming oriented Bazzite.
For more info you can take a look at the uBlue website where some of the info above can be found, and more.
If I’m following correctly, Silverblue from Fedora is just an OS with rpm-ostree, and that’s not the same as a container image. With ostree native containers future versions of Fedora Atomic will be container images. The advantage of booting off a container image instead of whatever Silverblue is currently is that you can edit a containterfile to make changes to the image in CI and that a container image can be distributed from multiple places - not just the Fedora Project itself.
Because uBlue is a container image specifically, that enables the customization we see downstream in the form of Bluefin and Bazzite. This is not something unique to uBlue. This is common in the cloud native world. All Fedora Atomic is doing is allowing their stock images to become a container image and thus enjoy the benefits that come with that.
Is that right?
Related question: what is the difference between how an update happens in Silverblue vs uBlue?
For uBlue my understanding is that when you get an update you are downloading a whole image that contains the new version and then booting off of it when you restart. I think this is how chromeOS does it as well.
For Silverblue I thought it was the same, but I remember hearing somewhere that all that is touched are the parts of the OS that changed in the update. They’re being merged in with that git structure that ostree brings to the table, but you’re not downloading and booting off a new image with every update.
Am I understanding this correctly, or does Silverblue also boot off an entirely new image with each update?
Your understanding is correct.
Fedora Silverblue ships updates in the form of ostree commits. The architecture of ostree allows updated commits to only contain the changed files from the previous commit. This reduces the amount of network bandwidth required when updating between commits at the cost of more individual network transactions. (ostree also supports static deltas which packs the updates into a smaller amount of files and reduces the amount of network transactions.)
The current implementation of ostree native containers does not have any specialized incremental update support, aside from what is possible with the OCI specification. This means that if your new ostree native container that you are updating to contains the same layers as your previous ostree native container, those will not be fetched as they are already on disk. Due to how ostree commits are packed into an OCI container image, fetching the full container image is often required when updating. This is an obvious drawback from the ostree upadate commit model, but one that many users are willing to work with because of the flexibility that working with container images provide.
(There’s interest in improving this support in the future, but it is a complex topic with many opinions - Support layer deltas by alexlarsson · Pull Request #902 · containers/image · GitHub)
I just discovered this this week!
Yeah, that implementation would be great to have as part of the whole ostree native containers ecosystem! Some of the concerns I have heard with this approach are around the proliferation of delta manifests/layers and what kind of problems that introduces for registry administrators/operators.
I think it is a good short term solution while the longer term problem is addressed somewhere in the OCI spec, for example.
Thanks for confirming what I thought, as well as confirming the drawback that I figured would be there. Either way this is all very exciting. The fact that it’s still a developing space makes it even cooler!