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!
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
Thank you)
Immutable vs Mutable weird normalMore like familiar and unfamiliar
Yeah that’s what they said
The root filesystem is being read from somewhere, and if it’s being read from, it can be written to. Having an extra step or two in the way doesn’t make it “extremely secure”.
if it’s being read from, it can be written to.
Why would being able to read imply being able to write?
Having an extra step or two in the way doesn’t make it “extremely secure”.
Well it can greatly improve security by preventing a compromised app to achieve persistence.
Unless “read-only” is being enforced by hardware (reading from optical media, etc), a compromised sudo user can circumvent anything, and write anywhere. A read-only flag or the root filesystem being mounted from somehwere else are just trivial extra steps in the way.
Improved security != extremely secure, is all I’m saying. There are a lot of things that go into making a system extremely secure, and while an immutable root filesystem may be one of them, it doesn’t do the job all on its own as advertised in this post.
I remain interested in the immutables or atomic distros because I know a lot of smart people that swear by them.
I also don’t try them just yet because I know a lot of dumb people like me that end up breaking a lot of stuff before quitting them altogether.
They could be amazing and just not perfected yet or they may be a meme and no one’s proved it outright just yet. Will be lurking this thread either way lool :D
These distros are great for beginners or less technically savvy. They’re really just harder for people who have been using Linux forever and are very accustomed to the old ways.
Yeah I think atomic is more appropriate but I’m not exactly sure what the difference is?
Immutable = Read-Only Root FS && Updates entire system image rather than individual files
Atomic = Updates as single transaction (all or no update) && Containerization w/ Rollback capabilityThis is quick summary from quick research pls correct where technically wrong.
That makes sense, bazzite is referred to as atomic (that’s what I meant in the above comment about atomic being more appropriate, forgot to add that context though lol) specifically instead of immutable. Bazzite updates like you said and you can always roll back, thank you for the explanation!
If we’re asking what people mean when they use those descriptors, then you’re correct.
However, literally speaking, in this context, immutable only means read-only, and atomic only means that updates are applied all-at-once or not at all (no weird in-between state if your update crashes halfway through).
The rest of the features (rollbacks, containerization, and immutable meaning full system image updates) are typically implied, but not explicitly part of the definition.
I knew a real wizard would clarify sooner than later. Much obliged and keep up the good work anon!
- You can still apply updates live, e.g. on Bazzite (Fedora Atomic) with the
--apply-livetag (or however it’s spelled). - The root partition isn’t read only per se, but you have to change it from upstream image instead of the one right now. You can use the uBlue-Builder for example to make your own custom Bazzite spin just for you if you want.
- Both aren’t inherently secure or insecure. It’s harder to brick your system, yeah, for sure, but you can still fuck up some partitions or get malware. It’s just better because everything is documented, saved, containerised and reproducible.
- And you can still install system software, e.g. by layering it via rpm-ostree. Or use rootful containers in Distrobox and keep using apt in there.
Distrobox is something I want to start playing with, I like the idea of the containers
I run bazzitr and distrobox is amazing. No need to worry about distro when some devs only provides deb only.
- You can still apply updates live, e.g. on Bazzite (Fedora Atomic) with the
N I x o s
deleted by creator
Atomic and declarative. Which is way cooler.
Solves the issue tho
Well it’s a bit confusing. On Guix’ wiki General features you can read:
Guix keeps track of these references automatically so that installed packages can be garbage collected when no other package depends on them - at the cost of greater storage requirements, all upgrades in Guix are guaranteed to be both atomic and can be rolled back.
The roll-back feature of Guix is inherited from the design of Nix and is rarely found in other operating systems, since it requires an unorthodox approach to how the system should function (see MicroOS).
And then on its wiki Guix System (operating system) Roll-back you can read:
This is accomplished by a combination of Guix’s functional package manager, which treats each package and system configuration as an immutable and reproducible entity,[58] and the generation system which maintains a history of system configurations as “generations.”
So the system configurations on a Guix system are actually immutable, as opposed to regular gnu+linux distributions, which can change the system configuration on the fly. What else is immutable on Guix, I can’t tell, but at least you can not change its system configs. What is atomic is the upgrades.
I’m not sure, but as Guix borrowed these properties from Nix, I’d think this applies to Nix as well.
In other words, at least the Guix system has immutable components. And further, the system config which is immutable, is also declarative. Combining those two things might be intimidating, since it’s not like on the fly one can go and change the system config, which might be required when debugging some misbehavior, and it’s what most distros document, then one needs to learn about guile, and a bit about functional programming I guess or at least their basics… Deploying systems might take advantage of such declarative configurations though…
I really appreciate rarely seeing the message “update complete, please reboot now”. I would consider myself on the tech savvy side though.
Yeah what I really meant was you don’t have to have much linux experience to jump in, I definitely like the idea of not doing live updates now that I know it’s an option
I’m using Bluefin and overall it’s great. However, there are some unique issues due to immutability and flatpak.
- It’s more difficult to utilize a NAS. For example, on something like Mint, I can open Proton Drive on Firefox, and I can upload files from my NAS to PD.
On Bluefin, I can access my NAS and all files using the Files app, but not using I cannot accomplish the above task in the same way. Firefox cannot fully access my NAS, and I have not figured out how to make it work. I’ve played around with Flatseal, but can’t get it to work. Instead, I need to use Files to download the files from my NAS to a local folder, and then I can use Firefox to upload to PD from that local folder. I’m guessing there is a better way, but I haven’t figured it out yet.
- I would desperately like to use a screenshot tool with built-in annotations, but I haven’t found a flatpak that works. As I understand, it might have something to do with Wayland and/or my Nvidia GPU.
So while most things “just work,” there are some problems. Planning to stick with it and keep learning. I do love the concept and I’m overall very happy with the everything.
For #1 could you use distrobox to run it with another OS? I’m pretty new to all this so I could be way out in left field lol.
I added this edit above. Pasting here in case you are curious. Cheers.
EDIT: This thread motivated me to try and fix this issue. Installing Firefox using rpm-ostree worked. I expected it would, though I am still hoping to figure this out using the Flatpak version at some point. I also tried using Distrobox/Box Buddy to create a Fedora 40 box and install Firefox there. That version of Firefox couldn’t even see my NAS at all (unlike the Flatpak which could see my NAS but couldn’t upload files from the NAS to Proton). This was my first time ever using Distrobox. I thought it was super cool to see it in action and get a working Firefox, even though I couldn’t use it to access my NAS as hoped.
I haven’t tried any distobox stuff yet but I’m very curious. I will at some point.
Whoever downvoted this is lame. I appreciate your question.
I use Proton Drive on Librewolf on Bluefin without issues, so that seems a little odd. It might be an issue with what access you’ve given the fkatpak. Flatseal is the right place to look.
Are you using librewolf to upload files from your NAS to Proton Drive?
I readily admit I am still not super proficient with flatseal. I spent a lot of time trying to fix this by adjusting the file permissions, but I’m now wondering if it was some other local network setting I missed.
I also don’t use fstab to mount my NAS. I just sign in using Files which creates a smb link. On Firefox/proton drive website I can see the files but I cannot upload them directly to Proton Drive from my NAS using Firefox (or Zen) on bluefin.
In the Filesystem section for that app in Flatseal, you need to add the path to your NAS drive (the same SMB path that it’s mounted in the Files app). That will give your FF flatpak access to that location.
These seems to be related to flatpak, not immutability.
is nixos considered immutable or mutable? kind of has characteristics of both.
nixos and guix are immutable and two of the only immutable distros I like
The store is immutable but the system itself definitely isn’t.
The store is immutable
What does that mean, that the store is immutable? I never used NixOS, so not sure how to interpret that.
Packages in nix are in the store directory, each package in a dir named after the package hash. So you can have 15 versions of firefox installed, for instance, and the different versions go in different folders with different hashnames.
When it’s time to set up a user env, their specific version of firefox is (conceptually) symlinked into the users profile. When that user executes firefox it gets one out of the 15 versions. Another user may get a different one.
Anyway, the package store is off limits to users, and a real bad idea to modify for root too.
I see. I think the term “sandboxed” would be more appropriate than “immutable” in this context. Similar to Flatpak, where multiple versions per package can be installed at the same time.
That’s not what sandboxed means and Nix isn’t sandboxed.
Sandboxed means it runs in a separate container, often with limited permissions; raising security at the cost of performance.
They are “sandboxed” by separate namespace. It functions conceptionallyas a container that does not interfere with the other packages. The limited permission system is not a must part of any sandboxing, its just common in popular packaging systems. The term doesn’t only have a singular meaning. It certainly is a better term than “immutable” to describe the concept of Nix packaging.
I’d argue it’s closer to a mutable distro than an immutable one.
Nixos tends to lean on the term reproducible instead of immutable, because you can have settings (e.g files in /etc & ~/.config) changed outside of nix’s purview, it just won’t be reproducible and may be overwritten by nix.
You can build an ‘immutable’ environment on nix, but rather than storing changes as transactions like rpm-ostree, it’ll modify path in /nix/store and symlink it. Sure, you can store the internal representation of those changes in a git repo, but that is not the same thing as the changes themselves; if the nixpkgs implementation of a config option changes, the translation on your machine does too.
Nixos tends to lean on the term reproducible instead of immutable, because you can have settings (e.g files in /etc & ~/.config) changed outside of nix’s purview, it just won’t be reproducible and may be overwritten by nix.
Interesting. If possible, could you more explicitly draw comparisons on how this isn’t quite the same over on say Fedora Atomic? Like, sure changes of
/etcare (at least by default) being kept track of. But you indeed can change it.libostreedoesn’t even care what you do in your home folder. Thus, changes to e.g.~/.config(and everything else in/var[1]) are kept nowhere else by default.
- Which happens to be more crowded than on other distros as folders like
/optare actually found here as well.
~/.config is probably a poor comparison on my part; it’s management is actually done by home-manager rather than Nixos proper, and I can’t think of another OS that fills this same role.
Nixos generates (for example) /etc/systemd/network to a path in /nix/store and symlinks it to it’s appropriate locations. After the files are generated the appropriate /nix/store paths are (re-mounted? Over-mounted? I’m not sure the implementation) made read-only (by default), but anything that isn’t generated is absolutely both mutable and untracked, and that “not tracking everything in /etc” is more what I’m going on about.
If you use Nixos as intended (when you find that a package is lacking a config option you want, create your own nix option internally) the distro is effectively immutable, but if you use Nixos for anything moderately complex that changes frequently e.g. a desktop os, you eventually run into the choice: become competent enough to basically be a nixpkgs contributor, or abandon absolute immutability.
I think the first option is worth it, and did go down that route, but it is unreasonable to expect the average Linux consumer to do so, and so something like fedora atomic is going to remain more “immutable” for them than nixos.
This need to git gud is thankfully lessening with every commit to nixpkgs, and most people can already get to most places without writing their own set of nix options or learning how to parse //random markup language// into nix, but you’ll eventually run into the barrier.
- Which happens to be more crowded than on other distros as folders like
I used an immutable fedora on my surface pro 4, I wanted to shoot myself in the face every time I had to install anything. I’m good on that for the rest of my natural life.
Was what you wanted not available in a flatpack/ app image?
Wasn’t about that at all. Any DNF action took a lightyear… man just typing out those long commands (very hard to remember coming from apt) nevermind the much crazier wait time. Using toolbox for dev environments to compile things was a total nightmare. I’m sure there’s a scenario where it’s ideal, that was certainly not my situation.
Gotcha I was just wondering what the limitations are, I’m still messing with and I’ve not hit one yet but I was curious where they pop up. So for devs immutable distros don’t play well, that definitely makes sense!
From what I gather, if you like tinkering and compiling and installing random weird apps then immutable can be a serious pain in the ass like I discovered.
Did you ever try using Distrobox? That’s the recommended way if installing random apps.
I’m not sure that would’ve influenced my situation with a dual core i5-6300U and 4gb ram, it’s a pretty sluggish thing from the get go. But good to know about distrobox maybe that can help me in the future. Now rocking Debian and it’s great.
Debian sounds like a great fit for you. But it’s good to know that Universal Blue has a lot of tools available for installing and tinkering that many just don’t know about. They are extremely powerful OSs.
It’s definitely great for the mainstream. Think of Linus Sebastian who has somehow broken every OS except for SteamOS.
It’s not great for me who uses Arch Linux btw with the expectation that if the system doesn’t break on its own, then I will break it myself.
And anybody who thinks that Linus doesn’t look for those ways to break Linux is deluding themselves. He’s a fucking asshole.
He can be an asshole, but I believe finding bugs is part of his job.
Would you rather have him find them and complain to a community who might know what they could be, or someone else who will just complain and buy a MacBook instead?
Honestly, I would say it isn’t great for anyone who has to do something low level even once. Now that there are open source nvidia kernel drivers that has solved a pretty big issue for most people who would be interested in immutable distros, but there are still many other drivers and issues that your regular user may face.
One example off the top of my head is that flatpaks specifically can’t ship systemd services if I recall correctly. A lot of wayland apps for thigns like input have to use daemons because of wayland’s security model. Lact for AMD and now Nvidia GPU control, ydotool, or even gui versions of such tools for remapping input.
Snaps require custom kernel modules that aren’t used outside of ubuntu, so I hesitate to trust them regardless of any of the other issues people have with them.
This basically leaves appimages which aren’t available for everything and don’t always seem to work at least not as reliably as flatpak. I even tried to package the rstudio forensic software as an appimage myself, so I could have an easy way to use that proprietary piece of software, but I just couldn’t get it to work. I couldn’t get it to work with distrobox either using the official methods they provide to install it on linux. I did get it working in a chroot for some reason, but it had graphical issues. In the end, I made a PKGBUILD for arch and got it working that way.
The point of all this is that a lot of times people say immutable is great for average, non tech savvy people, but I believe that literally everybody ends up needing to do low level stuff at least once or twice every so often. Which simply isn’t a great experience since you end up having to do layering which throws these theoretical average users right back into the normal complexity of a mutable system, but with even more uncertainty in my opinion.
Now then with all of these caveats. I do still agree that immutable distros are great for the aforementioned group of people and I know this statement contradicts a lot of what I have described above. The reason why I think they are great for the less tech savvy people however isn’t because of any actual technical merit of the systems design though. Immutable distros are great for people like Linus Sebastion because it limits what they can do. You simply have to accept what is there the same way that you have to on proprietary systems like Mac and Windows. Those systems force you to do things a certain way unlike Linux and that is what people like Linus need because they have no business mucking around with the system to begin with.
Lastly, all of this only works because devices like the Steam Deck are being run on specific hardware thus guaranteeing there compatibility. This is what we ultimately need. There would be much less need for low level operations to get drivers or change settings to make wifi or audio work right on a billion different devices if these people were buying linux compatible hardware in the first place.
These are valid concerns but to me they sound more like lack of tooling rather than inherent disadvantages of immutable distros. Linux distros have not historically been designed from the ground up for immutability and it makes sense that there are issues that aren’t handled optimally. Surely we can come up with clean and simple solutions to basic problems like setting up daemons and drivers if we work on it!
Weird, I don’t have any issues developing custom systemd services or similar on my Kinoite installation. Packages that need to run on the host system can be layered, everything else is running in distrobox.
You can install packages in immutable distros. It’s just not as easy and recommended as a last resort.
With Universal Blue (Bazzite, Bluefin, Aurora) you can install packages with “layering”. It’s basically modifying the image by adding packages on top of what is shipped by the distro, and those packages get added each time the image is updated.
The better, more involved solution is to create your own image from the base image. That gives you a lot more control. You can even remove packages from the base image.
Secure != stable Immutable distros aren’t always more secure but rather more stable and hard to break Also btw nixos can apply updates without rebooting
I wouldn’t call NixOS immutable.
In your opinion, when can we refer to a distro as being immutable? How do you regard the likes of Fedora Atomic, openSUSE Aeon or Vanilla OS? Are any of these immutable in your opinion?
To be honest I don’t know these very well. I only use NixOS. My understanding is that in an immutable distribution the root filesystem is read-only. Granted in NixOS the nix store is immutable and most things in the root filesystem are just links to the nix store, but the root filesystem itself is not read-only.
It can be made to be by pinning various things which are not by default.
What things?
At the surface, you can pin the commit you pull packages from, but if you want to go deeper, you can essentially define your own channel and dependent binaries, allowing you to store every aspect of how a generation is built.
Yes, or use flakes which gives you a lockfile pinning everything. But this is related to reproducibility, not immutability.
If you control everything in the build it is, and every generation is immutable.
Isn’t immutability related to the root filesystem being read-only? I can write on my root filesystem, even if it’s mostly links to the store I can replace those links.
NixOS is immutable and atomic, but it isn’t image-based.
Immutable simply refers to how the running system configuration can’t be changed by simply putting a file somewhere (e.g. copy a binary to
/bin, which is a bad idea).For example, Fedora Atomic and derivatives are image based, although they are more flexible than the A/B types like SteamOS.
OpenSUSE MicroOS uses btrfs snapshots to apply updates atomically, and is more flexible than most image based immutable distros.
Edit: But I don’t think those terms have a single definition, so how would you differentiate these terms?
I’m on NixOS right now and just dropped a Chewy in my
/bin, only had tosudo touch /bin/chewy.Good point. I’ll have to stop using immutable and stay with atomic (and declarative).
Interestingly
/binand/usr/binare not in PATH by default, so/bin/chewycan only be executed by its path directly and won’t affect the systems reliability.That doesn’t make it not immutable. /bin is not a critical directory in NixOS, only the contents of /nix are, which are immutable. /bin isn’t even part of your path by default.
Well that was an approximation to keep it simple and disprove the given example. There are other directories in the root filesystem that are in the path by default, or used in some other critical way (like
/etc). Even if they are links to directories in the nix store you can replace the link.
deleted by creator
Do you have any examples of the kind of “tinkering” you couldn’t do with an immutable distro? I haven’t run into any restrictions after more than a year.
deleted by creator
… why would you want to install packages with
sudo? The proper way is to install them (as a user, not root) usingrpm-ostree, which will layer the packages on top of the image, automatically installing them for every future system as well.You haven’t actually looked into immutable distributions, have you?
deleted by creator
I keep hearing this, but people never elaborate on those “other reasons”. Did I miss where you mentioned them?
You mentioned storage, but AFAIK atomic Fedora doesn’t use more space (unless you keep multiple versions for rolling back).
deleted by creator
Of course it’s ok! You do whatever you want. Though I’d like to clear up a couple of misconceptions:
I don’t want to deal with images. I don’t want to have to be cleaning the system from those images to reclaim my storage.
You don’t have to, happens automatically.
I dislike flatpaks, snaps and appimage on which immutable distros rely.
Fair, though you don’t have to use them at all - you could run everything in a distrobox.
The lack of customization as you can’t modify system files or install traditional packages outside the immutable framework, which limits personal tweaks.
This really depends on what system files you mean. Anything in
/etc/? Fully writable. Everything is configurable either in your home directory or in/etc/, so I haven’t run into any issues with not being able to modify something - and if you do run into that, you always have distrobox.Apps availability, not all apps on the planet exist in flatpaks.
Don’t need to, you have distrobox for that.
The learning curve.
That’s fair. It’s been very small for me, and the issues have helped me become a better Linux developer, but it does bring its own problems in some cases.
Having to change the way I interact with my computer completely, I’m too fucking lazy for that and way too cozy where I am.
That’s the thing, I hear this a lot, and I just don’t know what the big changes are. I installed Kinoite, set up a distrobox, and have been smooth sailing since - all my previous installations have had far more issues, and I just haven’t really changed much (besides switching from Ubuntu to Fedora, but I’m happy about that, fuck Canonical).
I’m not really sure how the upsides of immutable distros work. I’ve been using linux for a long time and I’m not an expert but I’ve learned bits of things here and there.
I recently bought a steamdeck and it’s running an immutable distro. I don’t really know how to use software that’s installed via flatpak because it’s weird.
I have a game installed that runs badly (unplayable for me) through proton. I can launch it through q4wine if I switch the steamdeck into “desktop mode” and it runs much better.
If it wasn’t an immutable distro I could pretty easily make a shell script that launches the game through wine. Then I could add that shell script as a non steam game and it would (I think) run well, and I’d be able to launch it from the non desktop side of steam OS that is a lot more streamlined.
There is something comforting to me about immutable distros though.
I feel like I don’t remember half the shit I have installed on my computers. If I wanted to start cutting things out I don’t know where I’d start. But with flatpaks I get the sense I could probably just wipe anything I don’t use out of the flatpak directory and I probably wouldn’t break anything.
I’m fairly certain you could still run that shell script on steamOS? I don’t understand why an immutable distro would keep you from doing that. It’s essentially what Lutris and Heroic Games launcher do.
deleted by creator
