Hi there folks, I’m still learning about Linux and have yet to dip my toes properly in any arch based distro. Have for the moment fallen in love with the immutable distros based on Universal Blue project. However I do want to learn about what arch has to offer to and plan on installing default arch when I have time. But have been wondering why I haven’t heard of any immutable distros from arch based distros yet.

So, am left wondering if there are talks within that Arch community of building immutable distros?

While writing this post I found a project called Arkane Linux, which seem to be very interesting. Does anyone have nay experience with it? Is there a specific reason why immutable wouldn’t be a good idea when based on Arch?

Project: https://arkanelinux.org/

  • yala@discuss.online
    0·
    4 months ago

    For me:

    • atomic updates
    • reproducibility
    • (to some degree) declarative system configuration
    • increased security
    • built-in rollback functionality

    and their consequences;

    • rock solid system even with relatively up to date packages
    • possibility to enable automatic updates in background without fearing breakage
    • (quasi) factory reset feature
    • setting up a new system in just a fraction of the time required otherwise

    are the primary reasons why I absolutely adore atomic/immutable distros.

    Furthermore, it minimizes all kinds of issues related to or caused by bit rot, configuration drift and hidden/unknown states. (Note that you won’t reap all of these benefits on all atomic/immutable distros.)

    • Samueru@lemmy.ml
      0·
      4 months ago

      You get all of this by using Btrfs in a regular distro.

      Recently kdeconnect broke on me, I just rolled back the snapshot to the day before.

      • yala@discuss.online
        0·
        4 months ago

        You get all of this by using Btrfs in a regular distro.

        No you don’t. Refer to this reply I’ve written to someone else.

        Btw, Btrfs is only a file system, snapshot-functionality isn’t automatically implied with it. See traditional Fedora as a reference; i.e. defaults to Btrfs, but doesn’t set up Snapper/Timeshift or anything to that effect.

        But, even then, snapshot-functionality provides only of a small subset of the benefits in an inferior way (as I’ve explained in the reply to the other person).

        • Samueru@lemmy.ml
          0·
          4 months ago

          What do you mean by declarative system configuration? that thing that nixos does that you set it up thru its config file?

          I’ve also kept several month old btrfs snapshots on my system and I don’t see a problem with it, they only add like 3 GIB of storage each when they are that old.

          Also I’m not sure what you meant by increased security? Is it more secure simply because you can’t edit the root filesystem?

    • ddh@lemmy.sdf.orgEnglish
      0·
      4 months ago

      Yep, also ability to rebase to some other image. Maybe that’s what you meant by setting up a new system.

      • yala@discuss.online
        0·
        4 months ago

        Rebasing is (strictly speaking) found exclusively on Fedora Atomic (though I wouldn’t be surprised if Vanilla OS has also started supporting this like Fedora Atomic does). While achieving something similar on NixOS or GuixSD isn’t necessarily hard, the term “rebase” is not used for either of these systems.

        Setting up a new system with little to no nuisance is a direct consequence of managing your system declaratively. So no, I didn’t mean rebasing. Though, in your defense, Fedora Atomic does achieve it through rebasing. But, even then, it’s only one part of the puzzle.

        • biribiri11@lemmy.ml
          0·
          4 months ago

          ostree is based on OCI images, the basis for containers and the like. “Rebasing” just refers to swapping out the OCI image containing your root with another.

    • dsemy@lemm.eeEnglish
      0·
      4 months ago

      (Note that you won’t reap all of these benefits on all atomic/immutable distros.)

      That’s because most of these benefits are not a result of a distro being immutable.

      • yala@discuss.online
        0·
        4 months ago

        You should define what “being immutable” means (according to you).

        Besides, the questioner asked what the benefits of an immutable distro are. The only three mature immutable distros possess all of these qualities. And even if some of these qualities may be found on other distros that are not qualified as immutable. Fact of the matter is that the immutable variants of these features are far and wide superior over their counterparts found on traditional distros.

        • dsemy@lemm.eeEnglish
          0·
          4 months ago

          I guess I’d define it as a distro where the base system is read-only and changes or updates to it are done by replacing it atomically.

          Fact of the matter is that the immutable variants of these features are far and wide superior over their counterparts found on traditional distros.

          How exactly? Just saying it doesn’t make it true. Except for atomic updates (which are basically the main point of these distros, and why they’re also called “atomic”), what can they do that you can’t on a normal distro?

          • yala@discuss.online
            0·
            4 months ago

            Thank you for your reply!

            I guess I’d define it as a distro where the base system is read-only and changes or updates to it are done by replacing it atomically.

            Aight. I got no qualms with that definition for an immutable distro. However, small nitpick, the term “base system” can be very murky at times. And perhaps I would rephrase the part addressing changes/updates to “changes or updates to it are intended to be applied atomically”.

            Btw, I think this conversation is primarily on semantics and some assumptions we’re making related to that. So, I agree with you that (strictly speaking) immutability is only part of the puzzle (perhaps I might even refer to it as an enabler) for acquiring a lot of the aforementioned benefits to the degree by which it’s attained. So, the precise implementation of immutability is at least as important.

            For example, openSUSE Aeon/Kalpa, as much as I like them, have not been able to deliver most of these benefits beyond what traditional distros are capable of. Despite these distros being immutable*. However, they’ve recognized their faults and intend to move towards an image-based solution in order to improve. Similarly, Vanilla OS has recognized that their first vision of ABRoot wasn’t fit and thus overhauled it to be more in line with Fedora Atomic. We should continue to regard their initial visions as immutable distros despite ‘their failings’, but should also recognize that their failures aren’t representative of what immutable distros are or can be.

            How exactly?

            what can they do that you can’t on a normal distro?

            Alright, let’s start:

            (Note that the immutable distros will only be represented by Fedora Atomic, GuixSD and NixOS. The others are either too niche or immature)

            • atomic updates; no need to explain as you’ve established this yourself.
            • reproducibility; I’m not talking here simply about “reproducible builds”. Instead, I’m referring to how, on a daily basis, the system is actually built up from the ground (or at least capable of doing so without the hassle of actually committing to a complete reinstall). Some references in case you’re interested to know more about this. This is something I’ve simply never seen on a traditional distro. Though I hope you can correct me on this.
            • declarative system configuration; atomicity is just a pre-cursor or enabler for this. Nonetheless, ultimately, it’s a feature found exclusively on immutable distros. In case you mention Ansible, you should be aware that Ansible (at best) offers convergent system management. The aforementioned immutables succeeds effortlessly in (the superior) congruent system management. Refer to this article in case you’re interested in the differences.
            • increased security; Linux’ security standards leaves a lot to be desired. Unfortunately, whatever immutability offers in that regard, is far from enough to bridge the gap. By contrast, Qubes OS, while not being immutable (and technically not even a Linux distro), succeeds at setting an excellent security standard. But even they acknowledge the benefits that immutability provides for security (even on Qubes OS).
            • built-in rollback functionality; I can’t remember how GuixSD and NixOS far surpass anything else out there in this regard. However, for Fedora Atomic’s OCI model, it’s required that some registry builds your images. Currently, these images are stored for 90 days by default. Which means that I can go back to any one of these without keeping the snapshots on my own device. While it’s technically possible to keep snapshots from the last 90 days with Snapper/Timeshift, most sane people would simply not do it as it’s overkill and/or wasteful of storage. However, Fedora Atomic allows such functionality without burdening your system. Hence, it’s superior. Though, once again, perhaps this functionality is somehow available on traditional distros. But I’m simply unaware of it*.

            There’s no need to go over the “consequences” as they’re (as the name implies) consequences of what has mentioned earlier. Hence, as their causes are better than the one found on traditional distros, so are the consequences better than how they’re found on traditional distros.

            Finally, minimizing bit rot, configuration drift and hidden/unknown states are direct consequences of atomicity and declarative system management. Hence, immutable distros perform better at this compared to traditional distros.

            • dsemy@lemm.eeEnglish
              0·
              4 months ago

              (Note that the immutable distros will only be represented by Fedora, GuixSD and NixOS. The others are either too niche or immature)

              This was my issue with your original comment - I’m aware most of the work on features like these is based on immutable distros, but just being immutable doesn’t mean it will have those features.

              When it comes to reproducibility and declarative system management, I think you’re right that they’re only available in immutable distros.

              The security benefit of a read-only filesystem isn’t very significant IMO, and for some immutable distros, interesting parts (to attackers, like /etc for example) are mutable anyway.

              And I don’t use any snapshot solution currently, but don’t most of them only store the parts that change between snapshots? According to the Arch Wiki, Snapper’s “default settings will keep 10 hourly, 10 daily, 10 monthly and 10 yearly snapshots”. This doesn’t seem like much of an advantage for immutable distros, really.

              There’s no need to go over the “consequences” as they’re (as the name implies) consequences of what has mentioned earlier. Hence, as their causes are better than the one found on traditional distros, so are the consequences better than how they’re found on traditional distros.

              I disagree with this though. “Better” is very subjective - I for one consider being able to have an up to date system that can have parts of it updated without rebooting to be much nicer than using something like rpm-ostree, even if it is safer to use in theory (I can’t remember the last time I had an issue when installing a package; rebooting to apply an install atomically will likely make no difference to me other than wasting my time). I know I can use containers to get around this, but once again, this just adds to the hassle.