Yes, though keep in mind containers aren’t like VMs so the hardware isn’t virtualized or anything. The root system and everything in it is still immutable as well. In usage, it doesn’t matter for the container but it isn’t changing the root since what is writable to the container is outside of the root.
Using containers this way is the way Silverblue was intended to be used for by the user and pretty much any other immutable distro of note.
Yeah - I’m quite familiar with containers. I just don’t see the value they’re adding here. Maybe for experimental things or “project-specific” stuff. but otherwise don’t you just end up maintaining a container same as you would your “host OS” in a non-immutable distro?
Your immutable OS stays stable. For example, running a sudo pacman -Syu with a bunch of stuff from AUR in your Arch container for example will not bring down your OS or otherwise make it unstable. The immutable image you first install has been tested and it is the same image as the testers – same with the upgrades and updates, so long as you don’t overlap the image with rpm-ostree in this case.
Immutability keeps your OS stable and if something does happen to go wrong, you just roll it back.
If that isn’t something you need/want then that’s not something you need/want.
It’s definitely not - I’ve just been trying to understand the problem it solves for others though and see if it is something I would be interested in.
From what I can tell I can get all of the advantages in a “mutable” distro (flatpak, distrobox, etc.) without the overly-complex “immutable host” stuff.
I honestly don’t get the fear of “some random update ruins your OS”. Perhaps because I’m not an Arch user.
I am an Arch user and I still don’t get it either. When Arch borks something it’s rarely catastrophic. At worst it’s throw in the live USB, mount your drive and fiddle. And if you are going in as an Arch user, fiddling is something you sign up for.
So the solution to my problem is to create a container for a non-immutable distro?
Yes, though keep in mind containers aren’t like VMs so the hardware isn’t virtualized or anything. The root system and everything in it is still immutable as well. In usage, it doesn’t matter for the container but it isn’t changing the root since what is writable to the container is outside of the root.
Using containers this way is the way Silverblue was intended to be used for by the user and pretty much any other immutable distro of note.
Yeah - I’m quite familiar with containers. I just don’t see the value they’re adding here. Maybe for experimental things or “project-specific” stuff. but otherwise don’t you just end up maintaining a container same as you would your “host OS” in a non-immutable distro?
Your immutable OS stays stable. For example, running a sudo pacman -Syu with a bunch of stuff from AUR in your Arch container for example will not bring down your OS or otherwise make it unstable. The immutable image you first install has been tested and it is the same image as the testers – same with the upgrades and updates, so long as you don’t overlap the image with rpm-ostree in this case.
Immutability keeps your OS stable and if something does happen to go wrong, you just roll it back.
If that isn’t something you need/want then that’s not something you need/want.
It’s definitely not - I’ve just been trying to understand the problem it solves for others though and see if it is something I would be interested in.
From what I can tell I can get all of the advantages in a “mutable” distro (flatpak, distrobox, etc.) without the overly-complex “immutable host” stuff.
I honestly don’t get the fear of “some random update ruins your OS”. Perhaps because I’m not an Arch user.
I am an Arch user and I still don’t get it either. When Arch borks something it’s rarely catastrophic. At worst it’s throw in the live USB, mount your drive and fiddle. And if you are going in as an Arch user, fiddling is something you sign up for.
OK