Another prominent example is Android. Sure system apps can be upgraded individually – by storing the new version in a restricted part of the ‘user’ partition – but otherwise the system files are strictly read only until a new ‘image’ is ‘flashed’ to it by the update system or a power user with debugging tools. In the past, a common use of root capabilities was to remount the system partition as read/write and then change files on it directly. It’s more complex now.
That’s also why system apps can be rolled back to the stock version, and can sometimes be disabled, but can’t be directly uninstalled like user apps. Only the updated version on the user partition (if there is one) can be removed.
Another prominent example is Android. Sure system apps can be upgraded individually – by storing the new version in a restricted part of the ‘user’ partition – but otherwise the system files are strictly read only until a new ‘image’ is ‘flashed’ to it by the update system or a power user with debugging tools. In the past, a common use of root capabilities was to remount the system partition as read/write and then change files on it directly. It’s more complex now.
That’s also why system apps can be rolled back to the stock version, and can sometimes be disabled, but can’t be directly uninstalled like user apps. Only the updated version on the user partition (if there is one) can be removed.
Aren’t apps better compareable to something like flatpack and this is the reason why they are updateable during runtime?
Sure they are, but system apps are still installed in the immutable space initially, which is the important thing, that updates to it can’t go there.
I don’t know how desktop immutable systems deal with that.