I tried Silverblue for about an hour. Got pretty sick of “Changes queued for next boot. Run ‘systemctl reboot’ to start a reboot” real quick. I don’t see how this is an improvement.
You should be installing software with stuff like flatpak, toolbox or distrobox. If you treat the immutable image as a mutable one there really isn’t an improvement except for less of a chance of instability of updating/changing software that’s running in memory already.
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 can do that in Ubuntu… I’ll admit I simply don’t see the point. Immutable distro users seem paranoid about “some random update messing up their base OS” for some reason and I guess this suits their purpose. I just don’t see that as a problem.
Most people aren’t system administrators and they end up with broken computers for the most basic tasks. It’s one of the major reasons why people hate using Linux desktops.
And even if you’re an experienced sysadmin you can’t account for the entropy that accumulates on traditional OSes. 18.04 -> 20.04 -> 22.04 doesn’t end up being the same as a 22.04 clean install. This is a huge problem, especially for people who don’t know how to manage linux systems. And the people who do manage systems at scale don’t want that behavior either.
But day to day I’m in an ubuntu container and using “normal” package management, I just don’t do it on the host.
If you kept a basic minimal Ubuntu host it would be trivial to maintain. And you can still do your “toolbox” stuff on top of it. No weird immutable stuff needed.
I just don’t see the point. You want new users to understand containers. And to keep track of all the containers they maintain - possibly with different distros and using different things. And remember the difference between them and what is installed in each. Or just maintain one big container which is exactly what they would do normally anyway.
A reproducible system, delivered in a working state where anything you add is overlayed on top without effecting that system. Branches you can move between Fedora numbered versions as well as going Kinoite to Silverblue, while keeping the same stuff you layered on it.
I tried Silverblue for about an hour. Got pretty sick of “Changes queued for next boot. Run ‘systemctl reboot’ to start a reboot” real quick. I don’t see how this is an improvement.
You should be installing software with stuff like flatpak, toolbox or distrobox. If you treat the immutable image as a mutable one there really isn’t an improvement except for less of a chance of instability of updating/changing software that’s running in memory already.
Git? Vim? Fdupes? A dozen other cli applications I install?
Are you saying you can’t use toolbox or distrobox for that?
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.
Yeah those don’t go on your host they go in containers.
So I use non-immutable distros in containers to make up for the failings of the immutable host OS?
You use containers for your tooling, you purposely don’t touch the host operating system, that’s the entire point.
I can do that in Ubuntu… I’ll admit I simply don’t see the point. Immutable distro users seem paranoid about “some random update messing up their base OS” for some reason and I guess this suits their purpose. I just don’t see that as a problem.
Most people aren’t system administrators and they end up with broken computers for the most basic tasks. It’s one of the major reasons why people hate using Linux desktops.
And even if you’re an experienced sysadmin you can’t account for the entropy that accumulates on traditional OSes. 18.04 -> 20.04 -> 22.04 doesn’t end up being the same as a 22.04 clean install. This is a huge problem, especially for people who don’t know how to manage linux systems. And the people who do manage systems at scale don’t want that behavior either.
I go over this in this video: https://www.youtube.com/watch?v=hn5xNLH-5eA
But day to day I’m in an ubuntu container and using “normal” package management, I just don’t do it on the host.
If you kept a basic minimal Ubuntu host it would be trivial to maintain. And you can still do your “toolbox” stuff on top of it. No weird immutable stuff needed.
I just don’t see the point. You want new users to understand containers. And to keep track of all the containers they maintain - possibly with different distros and using different things. And remember the difference between them and what is installed in each. Or just maintain one big container which is exactly what they would do normally anyway.
Here is an alternative Piped link(s):
https://www.piped.video/watch?v=hn5xNLH-5eA
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
You know you can apply live, I do it for when pretty much anything except a kernel update is queued, works fine even if it warns you when you do it
I do not know that. I’m still failing to see the point of this overly-complicated setup though.
apt install git“just works.”A reproducible system, delivered in a working state where anything you add is overlayed on top without effecting that system. Branches you can move between Fedora numbered versions as well as going Kinoite to Silverblue, while keeping the same stuff you layered on it.
It’s truly git for your OS