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.
An OS that has reached perfection and doesn’t need changes anymore. Examples are Hannah Montana Linux, Temple OS, MS-DOS, Novell Netware.
Every time I think I've managed to erase NetWare from my brain, someone has to drag it back up angry fist-shaking
We need you to fix the thinnet again.
(”obviously“ sarcasm)
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.
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.
What if a new OS comes with, say, a GPU driver that is not compatible anymore? Is there not even an override for this possible? I have a PC with the GTX 970 which in computer terms is basically just after the meteorite crash ending the jurassic era. And i have been considering to use Bazzite OS for this machine.
I've read several topics trying to explain it and this single comment does a way better job, thank you XD
If you don't mind me asking a follow-up, why are non-immutable OS's in Linux more popular? Or in other words, is there a definite downside to an immutable OS that people should be wary of? I was planning to install Fedora 40 soon, but now I think I may opt for the Atomic one (with the KDE env) instead.
Regular Linux distros have 30+ years of history. It's what most of us are used to. Immutable/atomic/transactional OSes are relatively recent hence the relatively low adoption rate.
Also, atomic OSes are, by nature, much harder to tinker with. After all, the goal is to provide the exact same image for all users. As a power user, it's a bit frustrating. As a new user, having a virtually unborkable system is excellent.
If you plan on installing an atomic variant of Fedora, may I suggest uBlue Aurora instead of Fedora Kinoite? It is based on Silverblue/Kinoite but includes by default, among other QOL improvements, the restricted-licence codecs that must be manually installed in official Fedora products.
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 know of a good specific example of a downside. I play SS14 on Steam Deck and musical instruments in it require midi support. This means I need to properly install FluidSynth, but I can't. I can get the flat pack, but the game won't recognize that it's there because it's looking in the wrong place.
This is why I'm going to install bazzite on my deck.
Is Android immutable?
Yes, pretty much always has too.
/systemis normally mounted read-only and all use data is in/data, so when you want to factory reset, you just format/dataand reboot and voilà, brand new. Later versions also have a/vendorand a bunch of other partitions but the idea remains the same, as a user you only get to change/data(and/sdcardback before they had any meaningful internal storage, now it's an overlay mount to/data/media/0).
I believe the original idea was mainly focused around making software developer's lives easier, by (as you say) making versions of linux os's with known, static, unchanging, immutable, standard system configurations, which could not be altered by the user.
Again, I think the main idea here was basically focused around making either new distros, or sort of locked down versions of distros such that they could be deployed in I guess an enterprise or some kind of group environment, so as to greatly streamline the process of software development.
You say 'can receive updates', and I am not sure if you mean higher level app updates, or lower level system updates.
When people attempted to evangelize this immutable concept to me a few years back, they would say the whole point is that lower level updates on which many other things depend do not happen, that you would have to do basically a completely new install of a new immutable version when one comes out.
Kind of like 'more stable than stable.'
But... judging by other comments here, it would appear that this concept of immutable has uh... changed, lol.
Also, for what its worth, the Steam Deck OS is basically just a standardized version of Arch, upon which sits the whole nifty Steam Deck UI and Controller mappings, with the system set to read only by default.
You can change this and then do whatever the hell you want, if you so please.
I think its just one line in the terminal after you have set up your user as a system admin.
Immutable distros were originally very focused on servers, and more recently distros for workstations has stated gaining more interest as the concept has matured.
With the advent of cloud computing "immutable infrastructure" started becoming more and more popular. This concept started out as someone sitting down and grabbing a normal Linux distribution, and installing all the necessary bits for the server purpose they needed. Then baking that into an image. Now you could launch new copies of that machine whenever you felt like it, and they would behave exactly the same. If any of them started doing something wonky, you just destroyed it and launched a new copy. This was very useful for software developers and operations people who could now more easily reason about how things behaved. And be sure that the difference in behaviour wasn't because someone forgot to enable a setting, install a tool, or skipped a step in the setup.
On the software development side, you also simultaneously saw more and more developers make use of functional programming methods, and al'ng with those immutable data structures. Fundamentally, instead of adding an item to a list, you make a new list with all the old and the new items in it. You never change the data after it's creation. Each "change" is a new copy, with the difference already built in.
Then containers started becoming popular. Which allowed software developers to build a container image on their local computer, and then ship that image to a server, where the image behaved exactly as it did on their local machine. This also meant that the actual OS became less and less important, as everything needed by the container was already bundled in the container. The containers also worked as "immutable", since everything you would install or change within the containers would be immediately lost when the container was destroyed, and recreating it would be exactly as when the image was built.
The advent of containerised workloads, gave rise to a lot of different Linux distributions. Since the containers pretty much only needed the Linux kernel from the OS, it was pretty easy to make a container-centric operating system. And in turn lock down everything else, even completely omitting having a package manager. Stuff like CoreOS, Flatcar, Rancher OS, and many others were immutable linuxes that only catered to containers. I don't know the exact mechanism for all of these, but at least the original CoreOS and Flatcar make the actual system read only, and on top of that had two man partitions, one of the partitions would be the current system, and the other would be where updates were downloaded. Once an update was downloaded and ready, you just rebooted the machine, and it would be running off the updated partition. Which also meant easy rollback if you got a broken update. You could just boot off the other unupdated partition.
Containers were however rather ill suited for desktop applications, as there were no good way to provide a GUI. You could serve up a Web page, but native GUI apps were tricky.
That's where Flatpak, Snaps and all that came, which essentially brings the container mentality to normal desktop apps. This brought immutability to individual apps, as they brought their own dependencies. And therefore didn't have to rely on the correct versions of dependencies being available on the machine.
The logical next step was of course to add immutability to workstation distributions. This is where the popularity of Fedora Silverblue, NixOS, and many others really started taking shape.
I believe Fedora Silverblue uses ostree to make the system "immutable". Of course you can still make changes to your system, but the system is built to be completely aware of the state before and the state after, this is what's called "atomic". There's no such thing as a partially installed package. There is only the state before installing something, and the state when the thing is fully installed. You can roll back to any of the previous states, to recover from a broken update or misconfiguration. This also makes trying out new things with no risk. Trying out a new desktop environment, and it broke your system? Just roll back. Accidentally uninstalled a critical package? Just roll back. What to try out a new display manager? Just apply the config and roll back if you don't like it.
SteamOS also does the thing with multiple partitions, and even allows you to turn off the immutability. Other distributions aren't as lenient. There's no way to turn off the immutability in NixOS or Fedora Silverblue.
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
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.
You see, some operating systems are mostly operated by sound. If you mute them, they stop working. So it makes sense that you can't mute them.
My mother in law runs on such an operating system.
That's why processors are using GigaHertz to work
The penguin must scream!
Can't turn the sound off, duh 😹
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
Have you used Docker before?
You know how Docker images are read-only? Changes are layered on top, but the base image itself is read-only and all other files are stored in a volume outside the container. Containers are seen as ephemeral. When you upgrade to a new version of the image, the container is deleted and a new fresh one is created.
Imagine that but for the whole OS.
A related concept is an "atomic" OS, which means upgrades are atomic. Atomic in this context means that either the whole upgrade succeeds, or the whole upgrade fails. It can't get stuck in a half upgraded state. If you've dealt with databases before, it's a bit like database transactions.
None of us knows!
There's a group of hardcore hackers that keep bringing it up and we're all afraid to ask.
PS: Kudos for biting the bullet.
Then an immutable OS is the right OS for you!
No changing the system files! Ever! (Until you can.)
It's a kind of Linux distro which doesn't need to be taken care of, a plug and play Linux, after a decade using traditional Linux OSes I think it is the future of Linux because it just works out of the box without any tweaking needed just like android so anyone can use it. I am very satisfied with Bluefin which is based on the immutable Fedora version.
A little too pitchy imho. It is just a regular linux distro with each system update creating a new fs snapshots .
Just use Nix/Guix lmao
It's the newest hype for Linux nerds. You literally can't get them to shut up about their OS.
