I recently took up Bazzite from mint and I love it! After using it for a few days I found out it was an immutable distro, after looking into what that is I thought it was a great idea. I love the idea of getting a fresh image for every update, I think for businesses/ less tech savvy people it adds another layer of protection from self harm because you can’t mess with the root without extra steps.
For anyone who isn’t familiar with immutable distros I attached a picture of mutable vs immutable, I don’t want to describe it because I am still learning.
My question is: what does the community think of it?
Do the downsides outweigh the benefits or vice versa?
Could this help Linux reach more mainstream audiences?
Any other input would be appreciated!
Immutable ≠ atomic
Bazzite is atomic (not immutable), same with Silverblue and other Fedora variants (they’re all atomic, even on their main page it says atomic). It’s kinda misleading ngl
Fedora Atomic IS immutable. Rpm-ostree just layers (or hides) stuff on top of the already existing image. If you layer something, e.g. Nvidia drivers, you still download the same image everyone else uses, but basically compile the driver from fresh and put it on top. And that takes time. This is the reason using rpm-ostree to layer stuff is not recommended.
That’s why uBlue exists for example. It gives you a sane start setup, where all drivers are already built in into the image. And then you can either use the clean base and add your own stuff to create your own image, or use already great ones like Bluefin or Bazzite, where everything you want is already included.
Atomic just means that every process is either completed without errors, or not at all. This way, you don’t get an half updated and broken system for example in case you loose power. Happened to me quite a few times already, but never with Fedora Atomic.
Pretty much anything outside of
/var/(even/home/is placed inside/var/) is read-only, and if you want to modify your install, you have to build your own image. Therefore, it is both immutable AND atomic.That’s why I prefer the term “image based”
Isn’t that just their nomenclature for immutable?
What’s the difference between an atomic distro and an immutable one?
A distro can be both atomic and immutable, and they often go hand in hand.
Immutable simply means the core of a distro is read-only, meaning it cannot be modified by usual means. There are still ways to modify these files, but it works differently than in other distros.
Atomic distros are ones that update atomically. Atomic is used to describe an operation that cannot be cancelled in the middle of it, they either complete, or nothing changes. This means you can’t break things by cancelling an update midway through. Atomic distros also often come with the ability to rollback to the previous build of the system.
Doesn’t all immutable distros have updates that can’t be cancelled and that will either complete or not change anything?
I only just started learning about immutable distros so I may be completely wrong but it’s how I understand them to work when reading about it.
Immutable ≠ atomic, but they generally come as a package deal. Bazzite, Silverblue, and all those other distro’s that call themselves atomic are also immutable. An atomic distro is just one with atomic updates, and an immutable distro is any distro with a read-only core.
These distro’s have started mainly calling themselves atomic because they agree that immutable is a poor description that generally confuses users.
Since the idea is that the “root partition” is immutable, serious question:
How do you fix a hardware config issue or a distro packaging / provision issue in an immutable distro?
Several times in my Linux history I’ve found that, for example, I need to remove package-provided files from the ALSA files in
/usr/share/alsain order for the setup to work with my particular chipset (which has a hardware bug). Other times, I’ve found that even if I set up a custom.XComposefile in my $HOME, some applications insist on reading the Compose files in/usr/share/X11/localeinstead, which means I need to be able to edit or remove those files. In order to add custom themes, I need to be able to add them to/usr/share/{icons,themes}, since replicating those themes for each $HOME in the system is a notorious waste of space and not all applications seem to respect/usr/local/share. Etc.Unless I’m mistaken on how immutable systems work, I’m not sure immutable systems are really useful to someone who actually wants to or needs to power user Linux, or customize past the “branding locking” that environments like Gnome have been aiming for for like a decade.
My guess would be: have an additional overlay filesystem on top of your immutable root and apply all your fixes to it.
On the one hand sounds sensible, on the other hand I wonder if that’s possible when wanting to apply things that need to take place as early in boot as possible (eg.: modprobe options for a module, apparmor profiles, …).
For my needs, I’ve build a static system with buildroot for a pi zero. No updates, no modifications on the system, no remote access. Some directories are in tempfs, and after a reboot the system is fresh again. when needed, I removed the sd card and copy a new image
I use this board for a pulseaudio/mpd player, it’s not intended for a desktop usage, but I’m happy beiing able to configure a system like this one. For me, there is no maintenance, and this is exactly what I wanted
Is there debian based immutable distro?
Yes, it’s called VanillaOS! https://vanillaos.org/
Isn’t it based on Ubuntu?
I think it was prior to version 2, but these days it’s based on Sid - https://vanillaos.org/nerd-info
Good. I just quickly glanced at the site and there were multiple mentions of Ubuntu… Glad they switched to Debian, this way I might try it on second PC.
Thank you)
I wonder if you can download Apparmor and Apparmor-d on mutable distros, But I faced issues of bwrap and I couldn’t find a SELinux equivalent for Apparmor-d i tried allowing Bwrap but it didnt work so i uninstalled Apparmor.
I love building my own uBlue image. Tinkering is done in toolbox containers, definite changes are baked into the image. Completely custom (to me) and when you get it right it will just work anywhere. If I would brick my PC/storage I can just boot up another and restore my (back-upped) home dir with very little effort.
Immutable distros are great for applications where you want uniformity for users and protections against users who are a little too curious for their own good.
SteamOS is a perfect use case. You don’t want users easily running scripts on their Steam Decks to install god knows what and potentially wreck their systems, then come to Valve looking for a fix.
Immutable distros solve that issue. Patches and updates for the OS roll out onto effectively identical systems, and if something does break, the update will fail instead of the system. So users will still have a fully functional Steam Deck.
If you’re not very technical, or you aren’t a power user and packaged apps like Flatpaks are available for all your software, then go for it. I prefer to tinker under the hood with my computers, but I also understand and except the risk that creates.
Immutable distros are a valuable part of a larger, vibrant Linux ecosystem IMO.
So Bazzite basically is an immutable 3rd-party SteamOS. It was originally designed for handhelds (though has desktop images now) and includes the Steam Deck’s
gamemodepackage. That means it has the same interface, but working on a Legion Go or an Ally X. If anyone here has* any of those three you should seriously check it out!The other thing as well is that more often than not, the update will succeed and you won’t figure out until the next boot that something is wrong. However, Bazzite has a rollback tool so you can just change back to the previous image, reboot again and get to gaming.
That’s the best reason for immutable for gaming IMO. I don’t want to be fucking around with the OS when I’m in the mood to game. Being able to quickly rollback and jump into things in ~10 minutes or less is how it should be.
Immutable are the ultimate tinkerer’s distros. It’s just a different way of tinkering. True tinkering in immutable means creating your own image from the base image and that allows you to add or remove packages, change configs, services, etc.
Example: you create your own image. You decide you want to try something, but you’re being cautious. So you create a new image based on your first with your changes. You try it out and you don’t like it or it doesn’t work for some reason, you can just revert back to you other image.
Another thing worth mentioning, with these distros, you can switch between images at will. I’m new to Linux as my daily driver desktop OS, and I’ve rebased three times. It’s really cool to be able to do that.
Don’t know why this would be downvoted. Atomic distro’s are a tinkerers paradise, as all of it can be done fearlessly. I can make stupid changes to configurations that I don’t understand on NixOS, then when things break, simply revert the git commit and rebuild. (Or reboot to the last build if I broke it bad enough).
Who knows. People are passionate about Linux. And downvoting takes no effort. And people downvote stuff randomly.
if something makes linux more secure, safer or easier to use then it’ll be hated because people in the linux community are allergic to all those things. Secure boot? they hate it, wayland? they hate it, immutability? they hate it, flatpaks/sandboxed app? they hate it, gnome? they hate it. Even rust is hated by many.
I personally vastly prefer mutable distros for my own system, but I understand the appeal for those who like them. As long as mutable distros remain an option I don’t mind immutable distros.
As long as mutable distros remain an option
Precisely this, linux is about choice. It’s not like suddenly most distros would change init systems and make it near impossible to choose… oh, wait…
I prefer mutable and see immutable mostly as lazyness but if people wanna use’em go for it, i’m not pushing mutable down their throats.Linux isn’t about choice, it’s about freedom. Distro’s don’t owe you the choices you want, because the devs have the freedom to make what they want. You also have the freedom to modify them or make whatever distro you want.
turn off. immutable
I need to run immutable distros more, and I need to figure out how to roll my own images.
Desktop side, I need certain things in the base image rather than adding more layers or using a container. Things like rsync, nvim, git, curl, lynx, etc.
Would immutable distros help reach more desktop audiences? Perhaps. It’s more about applications though. The biggest help has been electron apps and the migration to web apps. The Steam Deck is successful because it has applications people want.
Server side, they look really promising for bare metal servers. Provided, there is an easy way to compile custom images. Being able to easily rollback to a known good image is very enticing, as you point out.
I am a big fan of breaking my system
Stock fedora is just for you my man, it breaks by itself
deleted by creator
Arch doesn’t break by itself tho, well… If you don’t update it for few months then yes, it breaks by itself
deleted by creator
Manjaro enters the room…
Has anyone had good success with setting up a development environment in an immutable distro? I love the entire concept because it fits with a lot of my other software preferences, but the tools for containerized dev environments felt frustrating.
Like, what do you do for your editor? vscode + devcontainers feel like the best option, but it’s rough when I need other IDEs (like I use some of the Jetbrains products). Stuff like toolbox works well too, but to get an editor in that, you have to install it in each one, or make a container that has it built in.
Otherwise, I’ll stick with plain Fedora — I use flatpaks for all of my apps anyways (except my editor)
Personally, I have found the developer experience on Bluefin-dx (the only one I’ve tried…) to be…. mixed.
VSCode + Devcontainers, which are the recommended path, are pretty fiddly. I have spent as much time trying to get them to behave themselves as I have actually writing code.
Personally, I’ve resorted to using Homebrew to install dev tools. The CLI tools it installs are sandboxed to the user’s home directory and they have everything.
It’s not containers - I deploy stuff in containers all the time. But, at least right now, the tooling to actually develop inside containers is kind of awkward. Or at least that’s been my experience so far.
I think the ublue project is fantastic and I really like what they are doing. But most of the world of developer tooling just isn’t there yet. Everything you can think of has instructions on how to get it going in Ubuntu in a traditional installation. We just aren’t there yet with things like Devcontainers.
Using brew is the recommended method on uBlue, so you’re already doing the right thing.
That being said, I use Jetbrains and devcontainers on Bluefin-DX and it’s been flawless for me, straight out of the box.
Hmmm, interesting. I like brew, for sure. And devcontainers worked ok for me when I was working on something by myself.
But as soon as I started working on a side project with a friend, who uses Ubuntu and was not trying to develop inside a container, things got more complicated and I decided to just use brew instead. I’m sure I could have figured it out, but we are both working full time and have families and are just doing this for fun. I didn’t want to hold us up!
Our little project’s back end runs in a docker compose with a Postgres instance. It’s no problem to run it like that for testing.
Maybe a re-read of the documentation for devcontainers would help…
I do my main development with Bazzite. I use the Neovim flatpak for my editor and toolbox for builds and such.
Running cli apps like neo vim from a flatpak is frustrating… “flatpak run com.something.neovim” is just the worst way to handle things. Complete deal breaker.
Why is it a bad way to handle things?
I have an alias set up and SDKs enabled. The experience is indistinguishable from a regular install. But you could also layer it onto the os image or install it in user space if you don’t like flatpaks for the extra resource usage or something. That’s a complete non issue for me though.
I have an alias set up and SDKs enabled. The experience is indistinguishable from a regular install.
That’s not indistinguishable - that’s you working around the problem of running
flatpak run some.domain.IForget(which - BONUS is case sensitive which is awesome) to run neovim.Snaps install a binary you can run. Flatpaks make you remember the 3 part domain to run things. So you setup aliases after installing things to run them, and if you uninstall them you need to remove your aliases. It’s a complete own-goal by the flatpak developers that this mess exists and is completely unnecessary. Simply providing an option to create and manage a script in .local/bin or something would be all it takes to make flatpaks usable from the CLI in a way that isn’t obnoxious.
That’s a good point. I should have said “indistinguishable after some tinkering”. You raise a valid complaint, though it’s not a deal breaker for me.
I use Jetbrains, devcontainers, and distrobox on Bluefin-DX and it has been flawless out of the box. There’s a single command to install the Jetbrains toolbox, which let’s you then manage all their apps.
Couldn’t recommend it enough, made my development lifecycle so easy.
How do you use the Jetbrains tools with distrobox? So far I’ve manually installed the toolbox inside my distrobox, but that doesn’t seem to be the preferred approach.
ujust jetbrains-toolboxNo need for distrobox for that - it’s a built-in
ujustcommand, put there by the creators of uBlue. It really has everything you need out of the box.More info in the docs: https://docs.projectbluefin.io/bluefin-dx#jetbrains
Yes, I got that running - but how do I then allow the Jetbrains tools to use CLI tools in the distrobox?
For distrobox, you can export your CLI tools, then use them anywhere in your system:
distrobox-export --bin /usr/bin/some_app --export-path ~/.local/binAlternatively you could
distrobox enterfrom the Jetbrains terminal.I would generally use
brewfor installing system-wide CLI tools, and use a devcontainer if I want to have a specific dev environment for a project.
i started learning rust with nixos, you can declare a shell.nix with everything needed for the environment, and those things will only be available in that folder.
there are caveats and annoyances to this like building a python environment costed me some time, because python packages sometimes require compling and all the shared libraries in nix are not in the right path (because you can have multiple versions installed) so you need to set some env vars to patch this.
nothing that gpt cannot solve.
I don’t mind flatpaks, but overall I don’t enjoy how software installs on immutable distros if it’s not flatpacked. It’s quite a kludge.
what does the community think of it?
It’s important to note how the Linux community interacts with change. In the past, whenever a change has been significant enough to influence individual workflows, it often provoked strong reactions. This was evident when systemd was introduced and adopted by distros like Arch and Debian. Even though systemd was arguably superior in essential aspects for most users, it failed to meet the needs of at least a vocal minority. Consequently, community endeavors were set up to enable the use of Debian or Arch without systemd.
Similarly, the introduction of immutable distributions seems to upset some people, though (at least to me) it’s unjustified. Immutable distributions don’t necessarily alter the traditional model. For instance, the existence of Fedora Silverblue doesn’t impose changes on traditional Fedora; let alone Arch or Debian.
But, overall, most Linux users aren’t bothered by it. Though, they often don’t see a use for themselves. Personally, I attribute this at least in part to existing misconceptions and misinformation on the subject matter. Though, still, a minority[1] (at best ~10%) actually prefers and uses ‘immutable’ distros.
Do the downsides outweigh the benefits or vice versa?
Depends entirely on what you want out of your system. For me, they absolutely do. But it’s important to note that the most important thing they impose on the user is the paradigm shift that comes with going ‘immutable’. And this is actually what traditional Linux users are most bothered by. But if you’re unfamiliar with Linux conventions, then you probably won’t even notice.
As a side note, it’s perhaps important to note that the similarities between traditional distros are greater than the similarities between immutable distros. Also, Fedora Atomic is much more like traditional Fedora than it is similar to, say, openSUSE Aeon or Vanilla OS. Grouping them together as if they are a cohesive group with very similar attributes is misleading. Of course, they share a few traits, but overall, the differences are far more pronounced.
Therefore, it is a false dichotomy to simply label them as traditional distros versus immutable distros. Beyond these names, which we have assigned to them, these labels don’t actually adequately explain how these systems work, how they interact, how their immutability is achieved (if at all), what underlying technologies they use, or how they manage user interactions. The implications of the above. Etc.
Could this help Linux reach more mainstream audiences?
The success of the Steam Deck and its SteamOS are the most striking and clear proof of this. So, yes. Absolutely.
- Not accounting SteamOS users.
I switched to silver blue after a bad update and my experience has been almost identical if not smoother than standard fedora
