What are immutable distros, and are they the future of Linux?

I hate YouTube videos.

If this was an article, it could be read quickly and with no annoying YouTube influencer in my face.

Or being forced to find a headset somewhere because my hearing is shit and I can't make out what they're saying (and don't get me started on the auto-generated sub's).

Also, not having ads waved in my face on YouTube is a plus.

Also, I read a lot faster than the average youtuber talks.

Some things benefit from video, but tech articles tend to not fall under that category.
Read the description.
- The description is not written like a blog post, because it assumes the user will watch the video.
  
  There is usually no point even reading it.
It's also on YouTube, but this link is not YouTube

Are we trying to make YouTube a generic word now?
- Haha didn't even notice it was hosted somewhere else since I didn't click the link.
  
  But the point is, videos have a lot of downsides and very few upsides. Sometimes it's good to get a visual explanation of something but more often than not, videos are designed to focus on the influencer and to be entertaining.
  
  I just want to get to the information myself.
Actually I often prefer videos for less important stuff and I'd wish that more high quality audio or video content was available for certain topics. Low quality content is easy to come by, but I often have difficulty finding content from knowledgable people in audio or video form.

My reasoning is that I can do something else, like playing a game, while listening to videos in the background. It also allows me to take my eyes from screens and look into the distance while still learning something new.

love this guys videos, just watched this one earlier today

Immutable distros seem to get a lot of hate, and a lot of it seems misplaced (and imo from people that haven't really read up on it). I want to try to clear up a couple of common misconptions:

Immutability: Immutability is not the purpose of coreos or microos, but rather a side effect. The purpose is reproducibility, and for that immutability is needed. This is related to the mechanism used to achieve reproducibility. That doesn't mean immutability isn't a useful side-effect (security), it just means it's not the main objective.

Reproducibility: The main desired outcome. And why I don't understand opinions like "why are they still made (since nobody wants it)". Reproducibility has been worked on for along time in the OS world and is a worthy goal. We aren't there yet but an obvious use case is voting machines. A more immediate benefit is: we can finally guarantee that a collection of packages that has been extensively tested will be deployed bit to bit in all servers.

User usage: there is an argument to made that this isn't useful in end-user distros, and is more of a server feature. Largely for linux power users this will continue to be true. But for others: it lets the distro makers make a stronger guarantee on the interoperability of the programs packaged in a specific version. A OS version has been tested thoroughly and you get a bit to bit copy of it. No more "package X broke package Y". Or "package Z is missing from the dependencies". Reproducible distros have the potential to be a more "out-of-the-box" stable experience.

I would argue that calling them "immutable" is part of what is fueling a lot of the hate and misconceptions. I would prefer "reproducible distros". Another often ignored aspects is the the newness of the technology. While these distros look to provide a more stable experience, for now that won't be case (but they aren't far away anymore).

Final note: to those power users that hate the idea that they can't "control" the distro, coreos based distros are already capable of using containers images as a transport. This means you can do anything you want through a Containerfile. And you can deploy this exact configuration to all you computers. No need for scripts to extract and install your desired configuration, just pull your personal OS image from your image registry.

Wrap up: I don't understand how a someone who uses linux in the server world can not see the value of this tech. It offers a long wanted solution to server deployment: using container engines ability to abstract the OS environment from the application environment. To be short: it lets the OS and the apps it runs live "their own life", with independent update cycles.

As someone who runs 7 servers in different datacenters (including cloud, local, and 2 in my home rack), being able to test and update on one system, then push that update to all the others, is a dream. Immutability is a step in that process, since it prevents weirdness from creeping in between updates. My only gripe right now with the options is they all still feel bloated. I miss original Rancher. All I need is Docker/Podman, and maybe wireguard to string the servers together. Likewise, my data hoarder computers need only zfs and enough on top to link them safely (so, wireguard). If I could focus on 2 stacks that I can push out elsewhere easily, I would be soooo much happier. Sain immutability tools are honestly magical.
- coreos doesn't feel bloated to me at least, no comment on others. I can't think of anything "excess" in it. It has docker, podman and wireguard-tools, other than that all the packages are pretty "essential".
  
  rpm-ostree on the other hand does feel bloated (and is included), but check out https://github.com/containers/bootc. I have high hopes for it.
Because I forgot one of the most important features: true automatic updates with auto-revert. Reproducible OS's are updated in the background and the updates don't take effect until you reboot. This means you can finally safely update the OS. And if something fails, the bootloader can autorevert to the previous working version.

This is more impactful in server world. In your personal computer you update packages and most of the time "everything is fine", if it's not you reboot. But accurately knowing which packages require a reboot has been a long standing problem, which reproducible OS now fix by just not doing that. In server world an update breaking things can take time to find and can affect multiple machines at the same time. The stakes are higher to make sure updates are stable.

Nick is probably my favorite Linux YouTuber. He seems to be the only one to understand that Linux has to look and feel sexy for new people to stay on board.

Personally I'm not super into the idea of immutable Distros, they kind of feel like Phone or Game console operating systems due to being read-only and containerized.

I prefer being able to change stuff without it being overwritten in the next update which is one of my many complaints with the steam deck and it's immutable OS, the system is locked to read-only and even if you unlock it it'll get relocked and all your changes undone at the next update.

It is actually pretty fine for steam deck. It's has to be a console like experience.

For a desktop os? not so much
- Well on my SteamDeck I wanted to install Portmaster for Adblocking and network filtering, and also wine because running Windows apps with a click on the Desktop > Opening Bottles and setting each one up before, Also wanted to switch KDE for Gnome because KDE sucks on a touch screen big time where Gnome is much more touch friendly. Also wanted to install neofetch as well but just ran it as a script to get what I needed. Yes I can disable the read-only and do it all anyway, it's not really locked down but because SteamOS doesn't respect or honor changes they'll just undo it whenever I update.
The point is you don't need to change stuff. You tell the resulting state of the system, the system will generate that state for you.

You don't change some file somewhere, you change the pipewire settings in your configuration file and rebuild. You save your config to version control so you can recreate the exact copy of your system any time and on any computer by just letting it download the locked versions of all of the packages you have installed.
- Well back when I didn't know any better and would go through linux installations because I would break things but also because many of the "recommended linux distros" had problems (f*** you Canonical forcing buggy snaps onto us) I might've thought it was an awesome idea. But now that I know better (both how to not break stuff + fix things if they're broken, and know when people are recommending glitchy trash) it just feels more restrictive. Kind of like a game console, android phone, or S mode. It's not necessarily as restrictive as those things because you can turn it off and do what you want but the updates to the OS will almost never respect the changes you make, as I know from SteamOS.
  
  Because I want to Install portmaster or create services to launch my own scripts on Boot without them being purged blindly by an update (just like How on Game consoles System updates will remove installed homebrew) I'm not into the idea of using immutable systems that lock you out of changes you might want to do that aren't official.
At least in coreos. rpm-ostree let's you "layer" packages on top of the base image, so when you install the next update it will automatically install your packages on top. You get to have the cake and eat it too.

How’s this different from Docker over LXC in terms of practicality?

Permanently Deleted
- Just to add since you said "aren't that much different from docker".
  I don't see any relation between microos or ostree mechanisms and docker, although they both depends on a container engines to abstract OS from APP env. microos uses btrfs features, ostree uses mounting and symlinks ("classic unix'y stuff") to accomplish the "immutability".
  
  On that note containers are pretty "classic unixy stuff" too. If you go under the hood mounting, cgroups, network namespaces and other kernel features are how it accomplishes everything (although you can customize to use forexample btrfs as a backend).
  
  Not hating on NixOS here at all, I think of it as: it is to personal distros what coreos is to server distros. It emphasizes the features that users want, while coreos emphasizes server features: notably coreos looks to minimize package customization (pushing that to container world) and NixOS looks to enable package customization. For people that use linux for personal use, nixos features are bound to be more attractive.
  
  whether there is enough demand for separate solutions for each (since they arguably can handle each others usecase) remains to be seen.
Docker and guis are not great friends. Docker containers are mainly for web services

If a lot of people don't prefer immutable distributions, why are they made? I still don't understand who this is for.

Colossal waste of developer time and system resources. No thanks. At that rate just port the whole userland to nodejs electron too.