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.
Doesn’t that lead to huge redundancy – say, multiple java copies effectively existing in the system? And also to software not optimized for the system (I assume flatpaks are pre-compiled)?
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.
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.
Flatpaks really have the added benefit of things just work. Many distros have problems with codecs for example and need to install extra packages to get video working in Firefox. The flatpak version doesn’t require any of this and you can just install and move on with your life. Yes dependencies are “redundant” sometimes but you have the added benefit of a really clean base system without hundreds or thousands of lib or dev packages. Also sometimes you need a specific version of a dependency. Let’s say you need to update it for compatibility with a specific package but that breaks another which needs an older version. The system can stay especially clean when it comes to the toolbox utility and dev environments (this is available in other distros as distrobox I think).
Not necessarly, as far as i understand it flatpak uses ostree to re-use already existing “components/parts” , if possible. ref. https://ostreedev.github.io/ostree/
But it highly depends on the types and maintainance cycle of the software you have installed if this technique has a major influence. At the worst case every software you install has its own “special” requirements … unlikely … but for some (for example older) software that might very well be the case.