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!

  • lnxtx (xe/xem/xyr) ( lnxtx@feddit.nl ) 
    link
    fedilink
    English
    arrow-up
    94
    ·
    2 years ago

    Immutable, doesn’t mean extreme secure. It’s a false sense of security.
    It could be more secure.
    But during a runtime, it is possible to overwrite operational memory, mask some syscalls, etc.

    That’s my 3 cents.

  • 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.

    • D_Air1 ( D_Air1@lemmy.ml ) 
      link
      fedilink
      arrow-up
      8
      ·
      2 years ago

      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.

      • chunkystyles ( chunkystyles@sopuli.xyz ) 
        link
        fedilink
        English
        arrow-up
        4
        ·
        2 years ago

        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.

      • 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?

  • 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.

    • chunkystyles ( chunkystyles@sopuli.xyz ) 
      link
      fedilink
      English
      arrow-up
      12
      ·
      2 years ago

      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.

    • Norah (pup/it/she) ( princessnorah@lemmy.blahaj.zone ) 
      link
      fedilink
      English
      arrow-up
      10
      ·
      edit-2
      2 years ago

      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 gamemode package. 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.

    • You can still apply updates live, e.g. on Bazzite (Fedora Atomic) with the --apply-live tag (or however it’s spelled).
    • The root partition isn’t read only per se, but you have to change the upstream image itself instead of the one booted 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 transparently identifiable (ostree works like git), saved (fallback images), 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 or Pacman in there.
  • Grangle1 ( Grangle1@lemm.ee ) 
    link
    fedilink
    arrow-up
    18
    ·
    2 years ago

    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.

    • 0x0 ( 0x0@programming.dev ) 
      link
      fedilink
      arrow-up
      5
      ·
      2 years ago

      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.

  • kibiz0r ( kibiz0r@midwest.social ) 
    link
    fedilink
    English
    arrow-up
    17
    ·
    2 years ago

    NixOS is kinda the best of both worlds, because it does everything in a way that is compatible with an immutable fs, but it doesn’t force you into abiding by immutability yourself.

    You can always opt into immutability by using Impermanence, but I’ve never seen any reason to.

    Edit: That said, the syntax has a steep learning curve and there are tons of annoying edge cases that spawn out of the measures it takes to properly isolate things. It can be a lot to micromanage, so if you’d rather just use your system more than tinker with it, it may not be a good fit.

    • 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”

  • tisktisk ( tisktisk@piefed.social ) 
    link
    fedilink
    English
    arrow-up
    13
    ·
    2 years ago

    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

      • tisktisk ( tisktisk@piefed.social ) 
        link
        fedilink
        English
        arrow-up
        8
        ·
        2 years ago

        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 capability

        This is quick summary from quick research pls correct where technically wrong.

        • T0RB1T ( T0RB1T@lemmy.ca ) 
          link
          fedilink
          arrow-up
          9
          ·
          2 years ago

          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.

        • Kroxx ( Kroxx@lemm.ee ) OP
          link
          fedilink
          arrow-up
          1
          ·
          2 years ago

          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!

  • penquin ( penquin@lemm.ee ) 
    link
    fedilink
    arrow-up
    10
    ·
    2 years ago

    I think it’s good if you have a ton of storage and want to set it and forget it. For me, immutable depresses me. I came to Linux for the tinkering and the ability to do what I please to my system, not to be restricted. That’s just me, though. For handhelds/strictly gaming machine (a Steam machine for example)? I think immutable is the perfect fit for it.

  • 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.

    • ivn ( ivn@jlai.lu ) 
      link
      fedilink
      English
      arrow-up
      4
      ·
      2 years ago

      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 patchelf on it somehow.

    • Same issue, I still use nix on m’y laptop because it’s neat as can be, but I have to admit developing on nix can be quite a hassle if you don’t go it “the nix way”, moreover some packages don’t work as well because nix doesn’t link binaries the standard way (zed editor for example)

    • 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 /etc are (at least by default) being kept track of. But you indeed can change it. libostree doesn’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.


        1. Which happens to be more crowded than on other distros as folders like /opt are 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.

    • The barrier for me is that I use a lot of apps which require native messaging for inter-program communication (keepass browser, citation managers talking to Libreoffice, etc.), and the portal hasn’t been implemented yet. Its been stuck in PR comment hell for years. Looks like its getting close, but flatpak-only is a hard no go for me until then.

      Even after that, I would worry about doing some Dev work on atomic distros, and I worry about running into other hard barriers in the future.

  • rumba ( rumba@lemmy.zip ) 
    link
    fedilink
    English
    arrow-up
    7
    ·
    2 years ago

    Then you have NixOS, which is declarative, and fairly immutable.

    You don’t have to reboot to make changes, but you can’t just run unlinked binaries either.

    You can’t do things like edit your hosts table or modify the FS for cron jobs. The application store is unwritable, but you can sync new apps into it .

    You have to make changes to the config file and run a rebuild as root.

    • just for clarity: you can modify stuff like hosts or cron jobs but it’d get overwritten iirc? you can also make the change in the config and have it persist (reproducibility being the main point, not disallowing you to edit your files)

      • rumba ( rumba@lemmy.zip ) 
        link
        fedilink
        English
        arrow-up
        3
        ·
        2 years ago

        No, that file is located in the nix store and linked back, If you become root and try to edit /etc/hosts It will complain that you cannot edit the linked file.

        If you go and try to edit the store directly you will meet the same kind of dead ends because /nix/store is a ro bind mount

        With enough root access, time and persistence you could eventually unwrap its flavor of immutability which is why I said mostly immutable. Compared to most operating systems where you can just slip a quick edit into a cron job it’s leagues ahead.