I’m trying to get a better understanding of rpm-ostree. Please correct me if any of the following is wrong.
rpm-ostree supports installing and updating operating systems with
immutable file system trees
OCI containers
The first one is the original way of doing things. It uses a git-like file versioning model with hardlinks to update file systems. The second method uses complete container images.
It seems that all the immutable Linux operating systems use the second approach or want to switch to the second approach. But I haven’t found any explanation why the second approach is preferred. If we only consider network bandwidth, then the first approach seems to be better, because you only transfer the files that have changed.
What is the reasoning to prefer one approach over the other?
This is exactly what I was wondering as well. I’ve heard it said that ostree is like git, but acts on entire filesystem trees. And rpm is linked with ostree to manage the packages. And recently this was extended to support container images. So why was this done? Just because it was a technical challenge or are there actual advantages to the container based approach as compared with the plain rpm-ostree one? And what are also the downsides?
As far as I can tell, vanilla Silverblue, Kinoite and the rest still use plain rpm-ostree and aren’t switching to container images(?) The Universal Blue variants all use container based, github-centered deployments. OpenSUSE Aeon/Kalpa are more similar to Silverblue and variants. VanillaOS is container based too I guess?
Thanks! What I get from the video is that the tooling and infrastructure around building, managing and distributing containers is simply way more evolved than the tooling around classic rpm-ostree and therefore you can achieve much more with a lot less effort if you just use the existing container tools? In particular, you can more easily keep track of some upstream distribution and re-apply your own changes whenever there’s an update.
Before the OCI workflow was added if you wanted to make a custom thing you’d start with that repo and then make your own using that tooling. Then this spec happened:
Basically ublue is just a project built around using that spec to make custom images. There are technical differences but the huge difference isn’t technical at all - there are waaaaaaaay more people that know containers than know how to use ostree directly.
Now there’s a unified method of making your OS image and the thing you run on that OS. So it’s a huge efficiency win!
There is also work being done upstream on a better way to manage container image updates such that you don’t have to download a whole new image every time you want to update. As far as I understand, that is what is currently keeping Fedora from adopting the OCI model for updates for the stock images. The move to provide OCI images from the official Fedora registry is for uBlue’s and the Linux community’s benefit while also teeing up the next challenge of not having such bulky updates.
To add to what joseph has said, the right people are involved who can solve the problem already know this and it’s on their radar upstream!
We consider the lack of an installer and lack of deltas to be the last two major problems that need to be solved and it’s one of the reasons we’re still in Beta.
By lack of installer you mean an installer specifically tailored for container based OS images? The existing Fedora installer (in uBlue images) was pretty seamless for me, but I also steered clear of dual booting & manual partitioning, warned beforehand from the release notes.
I am daily driving a Lenovo Ideapad Gaming 3 w/ Nvidia 3050ti GPU. I might as well make an image and post it somewhere in the hopes to help those who in the future might need it?! Hmmm
Outside of the Nvidia driver, I also run systemd-boot so maybe this isa ll worth while.
