I’d like to know, what’s the real difference between Silverblue and all the other distrubutions (even Fedora core).I know it’s an immutable host (with commited images from Server) etc. etc. but I’d like to be able to administrate Silverblue completely like any other distro. I know there is a development mode etc. (all changes are lost after reboot) but is Silverblue easily managable (like the others) or do we have to spend a lot of time (even with sudo) to get something configured (compared to other classic linux distrubutions). Somethings shouldn’t be configured due to these immutable restrictions…
Symlinks of unwritable folders to writable folders is IMO a kind of vamp. If I want to change something in these folders, I’ve to change them in the symlinked folders (/var)?
I don’t forget the fact that Silverblue (ostree) is pushing the use of containers and that’s one of the reasons of the immutable part of it but, I stay perplexed but I love new technologies/systems…
Silverblue is a desktop OS aimed squarely at developers. It’s focused on hassle free container management and development in said containers. In that goal I think it succeeds.
Within a week or so I’v been able to:
Get familiar with ostree and all of its benefits
Settle in with my normal windows manager and user land tools (i3,urxvt)
Use my dotfile repo to replicate my old env perfectly
Use podman to grab a python3 image and run my python status bar in it (instead of layering python on my ostree)
Use toolbox to compile tools I need and then have access to those compiled tools in my home directory.
Benefits to me:
Updates are safe. I don’t have to worry about a bad package ruining my os or leading to a failure to boot.
When I run ostree update it tells me all of the fixes for all of the vulnerabilities and their CVEs so I can look them up. It also tells me their criticality.
Podman is easy to use, pretty much the sayme syntax as docker without having to run a daemon. All of it is in user space!
The tool box shares my home dir automatically
I can version all my utilities in containers and then run different images while I fiddle with configuration.
When I was installing python on a container I never had to worry about mucking up my os python libraires… you know… the ones yum rely on.
Can you elaborate on what part of the FS you’re trying to manage? Or maybe the changes you’d like to make and your reasoning for them?
The goal I think is that you want to create a common os image, or a few for different purposes, that you deploy to systems. You manage everything else in containers.
Etc and “home” are still writable and you can manage those just like you would any other OS: Puppet, Chef, Ansible, Fabric, vim, etc…
What do you mean by “classic administration”? Most stuff ends up being similar-ish, but if you mean e.g. persistently dropping random binaries in /usr that won’t work and is generally a bad idea on any distro (worth noting that /usr/local isn’t managed by OSTree and is free range).
@refi64: Not every binary (dropped in /usr) is bad. But if I want to change/adapt something in /dev or /bin for example? I need to adapte these in the symlinked folders to get this changed on the whole system?
Think of it like git. You’ll start with a base ostree image and make modifications to it / rebase it. Then you can “pull” those changes to your ostree. Once you have an image you like and the infra to host it it will be easy to restore that image to any number of boxes and retain your settings.
In general changes like these would be very infrequent.
If you want to avoid rebase you could do something like set your path in bashrc you could even just drop all your stuff in opt and add it to your path.
By default you should be installing things with flatpak or running them in containers and avoiding frequent changes to the os image.
In general this kind of separation between os and user land is safer and more reliable
/dev is unmanaged by OSTree, it’s still a normal devtmpfs. /usr binaries aren’t supported; in general package managers tend to assume they have full control over /usr anyway, outside of /usr/local.