linuxmemes

TempleOS?

If the immutability in OS is well designed, then there shouldn't be really an downsides or loss in comfort. That is, unless you're a linux expert and like to tinker under the hood.

The general idea is, the core of the OS if read-only, and everything else that needs to be modified is mounted writeable. Ideally, protecting the core of the OS from writes, should for example prevent malware from installing a modified kernel or boot loader. Or maybe preventing the user from accidentally borking something so that their system becomes unbootable. How much of an advantage that is practice is dependent on use case. In the case of Steam OS on the steam deck, it's perfect, since boot issues on the steam deck could potentially be tricky to fix as opposed to a standard PC.

Another advantage of immutable could theoretically be wear and tear of certain storage devices. e.g. Think of a raspberry PI and SDcards. If you could have most of the important stuff of the OS as read only on the SD card, and everything else on a usb disk or even an NFS mount, then the SD card should last much longer since no writes are happening on it.

As far as true security benefit is concerned... I can't really say. It depends on how updates and eventual writes are actually handled to the immutable part of the OS. Obviously at some point, changes do happen. Like during a system update. In the case of Steam OS, The system portion is wiped and replaced the new version. Chimera OS, did something similar (I don't know if they still use the same method). They had a read-only BTRFS partition, where they would then provide a new snapshot during an update, which would be downloaded and applied at the next reboot. This approach would hinder automated crypto malware for example (at least for system files).

I find it hard to imagine a system that is not borkable by a superuser. Maybe it's helpful to think of immutable setups as harder to bork by accident during routine maintenance (e.g. through faulty updates) and more resilient to bad code (through containerization).

Aren't apps better compareable to something like flatpack and this is the reason why they are updateable during runtime?

Depending on the use case there's usually a temporary system that's there only to take the update from the user partition and apply it to the system partition. So even if you bork the update it'll still boot into that environment and install the system again. Valve does provide bootable images to put on a USB stick if you do break it pretty bad. It's just a PC, it doesn't do much to stop you from wiping the disk. The route Android took is A/B devices, when you're using A you update B and then reboot into B, then the next update you'll be updating the A partition and reboot into it. Plus if the next one fails to boot for some reason you can revert to the old version as if nothing happened, and retry the update from scratch. Except Samsung, because I don't know I guess they want to turn the updating into a whole experience of anticipation or whatever crap reason they have for it.

Yes, pretty much always has too. /system is normally mounted read-only and all use data is in /data, so when you want to factory reset, you just format /data and reboot and voilà, brand new. Later versions also have a /vendor and a bunch of other partitions but the idea remains the same, as a user you only get to change /data (and /sdcard back before they had any meaningful internal storage, now it's an overlay mount to /data/media/0).