I’ve heard of immutable OS’s like Fedora Silverblue. As far as I understand it, this means that “system files” are read-only, and that this is more secure.
What I struggle to understand is, what does that mean in practical terms? How does installing packages or configuring software work, if system files can’t be changed?
Another thing I don’t really understand is what the benefits as an end user? What kinds of things can I do (or can be done by malware or someone else) to my Arch system that couldn’t be done on an immutable system? I get that there’s a security benefit just in that malware can’t change system files – but that is achieved by proper permission management on traditional systems too.
And I understand the benefit of something declarative like NixOS or Guix, which are also immutable. But a lot of OS’s seem to be immutable but not purely declarative. I’m struggling to understand why that’s useful.
You’re right - having multiple copies of everything is a drawback of housing each application in its own container or VM. The standard rejoinder is that disk space is cheap. The validity of that rejoinder depends on what you’re doing and what hardware or budget you are working with.
Another problem is that old versions of these dependencies will be baked into an image that is then used for many years without updates. This ensures the application keeps working without being disrupted by an update to a shared library, but it also means things like security flaws persist. Arguably, this is mitigated by only that image having the problem, but one insecure app can be a real problem - especially when it accesses shared resources - and when the same problem applies to many applications.
Compiled code optimized for a specific system’s hardware is less relevant than it used to be - even Gentoo users do not focus on this anymore. Rolling your own container isn’t much harder than compiling with your own options.
Thank you for all this info!
Another argument for the each app has the library it needs model is that your system no longer is pinned to the least common denominator which means apps should be able update their packages faster without the concerns of other apps.
You also have flatpak’s runtime concept which means you could force an app to try and run with a newer runtime.