It’s not so much that you can’t change parts of your system permanently. Think of it more so like the system partition of the OS is versioned like it’s a git repo. Each time you make a change to the OS filesystem the change is written to a new version of your OS that is layered onto the previous version, and then those changes are commited to the filesystem store, and a new boot entry is created.
So it’s a slightly more involved process to install new/update system packages (you have to reboot into the new version of the OS for the changes to take effect), but you gain a massive advantage in stability as a result (if the new version fails to boot or has other unexpected behavior, just reboot into the old, known working version).
Interesting, I’ve never heard it described that way. I’m running Bluefin for a year, and up to now I’ve just avoided making any system level changes. I run flatpacks for most things, and containers for any odd bits that need dependencies.
Is what you’re describing, using rpmostree? I haven’t used it yet, afraid of messing things up, because I LOVE the stability I have now.
Used to run Ubuntu, and I’d reinstall for every new release, because I’d already mucked up my install anyway so might as well start fresh. And other times I’d just break stuff so thoroughly I needed to reinstall.
Yes, you’d use rpm-ostree install on some downloaded RPM after adding the repo manually in /etc for updates later (they really make it painful because layering system packages should always be a last resort).
You’re doing things correctly already. If everything is working fine with all the applications installed in a containerized way (distrobox, flatpak, etc.) no need to mess with rpm-ostree.
100% I was in the same boat as you with the yearly Ubuntu refreshes, and that got so old. Now if there’s an update the breaks something I just rollback and pin the working version until there’s an update that works or I have time to troubleshoot the issue.
It’s not so much that you can’t change parts of your system permanently. Think of it more so like the system partition of the OS is versioned like it’s a git repo. Each time you make a change to the OS filesystem the change is written to a new version of your OS that is layered onto the previous version, and then those changes are commited to the filesystem store, and a new boot entry is created.
So it’s a slightly more involved process to install new/update system packages (you have to reboot into the new version of the OS for the changes to take effect), but you gain a massive advantage in stability as a result (if the new version fails to boot or has other unexpected behavior, just reboot into the old, known working version).
Edit: I’m using Bazzite on two devices btw
Interesting, I’ve never heard it described that way. I’m running Bluefin for a year, and up to now I’ve just avoided making any system level changes. I run flatpacks for most things, and containers for any odd bits that need dependencies.
Is what you’re describing, using rpmostree? I haven’t used it yet, afraid of messing things up, because I LOVE the stability I have now.
Used to run Ubuntu, and I’d reinstall for every new release, because I’d already mucked up my install anyway so might as well start fresh. And other times I’d just break stuff so thoroughly I needed to reinstall.
Yes, you’d use rpm-ostree install on some downloaded RPM after adding the repo manually in /etc for updates later (they really make it painful because layering system packages should always be a last resort).
You’re doing things correctly already. If everything is working fine with all the applications installed in a containerized way (distrobox, flatpak, etc.) no need to mess with rpm-ostree.
100% I was in the same boat as you with the yearly Ubuntu refreshes, and that got so old. Now if there’s an update the breaks something I just rollback and pin the working version until there’s an update that works or I have time to troubleshoot the issue.