Immutable in this context refers to an OS that can’t be changed while running. Steam deck does something like that. Basically the all of the OS system files are read only, so that the user or some malware can’t Bork the system. The only parts that are writable are the users profile directory and the logs.
You can still receive updates and install apps. It’s just that that’s handled a bit differently than with a standard OS.
E.g. it could be that the OS provider only issues complete updates, and then you either have to reboot. This is the case with steam os on the steam deck. The System portion of the OS is mounted read only during use.
Sounds pretty secure except for at the update stage, but you said that’s handled differently so maybe that’s more secure too.
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.
I’m no expert on this but I’m pretty sure the /etc directory is writeable too for config files, which sadly still allows a user or malware to still bork the system if they get superuser privilege
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).
good point, that’s fair. The reason I think it bears mentioning is that editing configs under /etc/ is totally something we might expect a user to do. So you could follow a tutorial online that is wrong or outdated and with enough bad luck, tada, you bricked your “immutable” system. Or, less dramatic and more likely, something doesn’t work as intended anymore and you don’t know how to restore to the original config from when you installed.
Sounds proprietary.
An immutable OS is useful for things like an alarm clock, where if you accidentally muted the sound system, you could oversleep. There’s an obvious downside if you’re someone that watches porn on your alarm clock computer, but sometimes compromises must be made.
I used to have a clock that had a USB port for pictures to display. This may be a larger problem than we’re aware of
An immutable OS is fixed and mounted non-writable. Every update you get, every program you install is handled on top of it via containers or filesystem overlays so the underlying OS is untouched. Basically the same concept you know from smartphones or other devices with a “reset to factory settings” function. No matter how hard you screw up your system, you can always reset to the base OS, either by granulary deactivating things installed on top, or by a reset to the working base OS.
That’s interesting. Thanks.
So how are OS updates handled, they are not written into the main OS?
They are written but don’t replace something in the read-only OS. They are just overlayed, so once removed the original is still there. How they do it differs. There are actual overlay filesystems for the job, or some use btrfs where all subvolumes behave mostly like virtual partitions (and copies of a subvolume only take space for changes of the original).
Root directories are no go unless you specifically ask to change them. If you’re developing it’s a lot easier if you can depend on all the programs and dependencies to be the same in the same directories.
It’s like getting a system how you like it and burning it to dvd.
The changes from distro to distro are how they handle your changes. More specially how do we undo changes if it goes wrong
There are a few ways to handle changes some swap from image A to image B like vanilla os
Some just use their rollback image tech they have in standard distros like opensuse aeon .
Some like fedora silverblue use images that pull from a repo if you’ve used docker this might seem familiar.
From silverblue you have ublue project that really pushes the container ethos your distro becomes a host to ask sorts of containers kinda like proxmox.
The end of the day it’s like distros a collection a packages with the essential stuff locked in a non writeable directory.
I hope this is clear sorry I’m dyslexic and it’s bedtime
An OS that has reached perfection and doesn’t need changes anymore. Examples are Hannah Montana Linux, Temple OS, MS-DOS, Novell Netware.
What happens when an immutable OS meets an unstoppable OS?
Can god make an OS so immutable, even he can’t update it?
It’s complicated. Technically no, but God can roll out a new image with the updates, so in practice, yes?
Why is religion never simple…
