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!
deleted by creator
I think they’re great. I’ve got two Linux newbies running some Ublue variant with no issues
Appimages, flatpaks, snaps
Former OS security guy. Fuck no. Nope nope nope nope.
You’re definitely out of date on your knowledge then. Nothing inherently insecure about any of these. Only download software you trust, just like you should be doing with any software format!
If you trust it, why not just install it like a y other app?
Oh wait, it’s generally pushed for binary only blobs, no source… so why are you even trusting it?
I don’t really know what you’re saying. Most software is distributed as binaries, that doesn’t make them inherently untrustworthy, you just need to have trust in whoever is distributing it. It’s trivial to look at the build process of a flatpak and verify that it is legitimate. Just because the binary isn’t being built from source by every user doesn’t make it insecure.
Who is mostly pushing these containerized apps?
Proprietary software vendors.
Same for who stands the most to benefit from immutable distros. Like Android and MacOS get shipped.
Flatpak is completely open source software and any proprietary software in it has a large warning about how it’s proprietary. I don’t know why you think proprietary software vendors are pushing these. Ublue, NixOS, and Fedora Silverblue are all community run, not being pushed by some malicious group pushing proprietary software.
Why companies even have anything to gain from their proprietary software being in a container? All that would do is make data collection more difficult.
Why do you think all phone makers push it?
There is literally no arguing with people like you, haha
Because it improves security and privacy, something they can advertise as a feature. There’s no negative for them to implement, it’s their phone, they can already collect all the data they want. It still prevents other apps from accessing data they shouldn’t.
Why do you think phone makers push it? What possible malicious reason do you think proprietary software makers have to push containerization and sandboxing? What do they gain?
I can see where you’re coming from because of outdated libraries and flatpak sandboxing not really being a thing (it’s an illusion, really) but you can’t deny that this is the direction we’re moving in, and we need to get flatpak sandboxing and permissions right, to ensure a proper base level of security.
For those unaware:
-
Many flatpaks use older, outdated, or end-of-life libraries
-
Flatpak permissions are messed up because most applications ask to bypass the sandbox at install-time
-
I can see why it’s “former”.
How come?
Yes, who would want sandboxed apps which restrict the app’s access to the system. /s
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, …).
- 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
Nix is atomic, not immutable
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…
Solves the issue tho
Atomic and declarative. Which is way cooler.
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.
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.
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 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 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.
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.
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.
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 as 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.
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 heard both flatpak and immutability are obstacles to developers. How bad is it really?
I’ve had NixOS absolutely refuse to run some compiler toolchain I depended upon that should’ve been dead simple on other distros, I’m really hesitant to try anything that tries to be too different anymore.
I’ve had NixOS absolutely refuse to run some compiler toolchain I depended upon that should’ve been dead simple on other distros, I’m really hesitant to try anything that tries to be too different anymore.
Yes, some toolchain expect you to run pre-compiled dynamically linked binaries. These won’t work on NixOS, you need to either find a way to install the binary from nix and force the toolchain to use it or run
patchelfon it somehow.Or enabling nix-ld can often get such binaries working.
It would be a problem without distrobox. Since that gives you a normal, mutable OS on top, you don’t even notice the immutability.
And Homebrew. I’m a developer and I’ve done all my work just with Homebrew.
if you program using vscodium, do you install a separate vscodium in every distrobox?
Yep, I do currently. I only have one main distrobox.
I had a lot of issues on silverblue using vscodium as a flatpak, I think I will try installing it in a distrobox instead.
It should behave pretty much the same as a normally installed version. Hope it works well for you!
NixOS likely only refused to run it because you weren’t running it in the Nix way. That’s not a jab or anything, Nix has a huge learning curve and requires doing a lot differently. You’re supposed to use devshells whenever doing development. If you want something to just work, you use a container.
Whatever issue you ran into most likely had nothing to do with NixOS being immutable, and was probably caused by the non standard filesystem hierarchy, which prevents random dynamically linked binaries from running.
I’ve never heard of flatpak and immutability being obstacles to developers, in fact I generally hear the opposite. Bluefin is primarily targeted at developers, and some apps, like Bottles, will only officially support the flatpak distribution because of the simplicity and benefits it brings over standard distro packaging.
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.
what does the community think of it?
Everyone has their own opinion, personally I think they’re a great idea and have lots of great applications. But just like rolling vs non-rolling release it’s a personal and application dependant choice.
Do the downsides outweigh the benefits or vice versa?
Again, depends, for my personal computer I wouldn’t use it because I think it could get complicated to get specific things to work, but for closed hardware like the Deck or even a fairly stable desktop used as a gaming system it’s perfect.
Could this help Linux reach more mainstream audiences?
It could, it can also hamper it because people might start to try solutions that only work until next boot and not understanding why, or having problems getting some special hardware to work (more than it would be a mutable distro). But there is a great counter to this which is that once it’s running it will be very difficult to break by user error.
At the end of the day I think it’s a cool technology but that people should know what they’re getting into, just like when choosing rolling vs non-rolling distro, it’s not about what’s better, but what suits your needs best.
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)
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.
