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/
But have been wondering why I havenât heard of any immutable distros from arch based distros yet.
If your question is âWhy doesnât Arch have its own atomic/immutable spin/flavor like Fedora and openSUSE have in their Silverblue/Kinoite and Aeon/Kalpa respectively?â, then the answer simply lies in the fact that Fedora and openSUSE have a lot more incentive for venturing the unexplored waters of atomicity/immutability as their enterprise counterparts exist and will benefit majorly from it. And I havenât even mentioned how most of the new stuff first appear on Fedora (systemd, PipeWire, Wayland etc) before theyâre adopted on other distros.
The enterprise counterparts also allow funding that is essential for erecting this from the ground. But, even then, the shift towards atomic/immutable is a difficult one with a lot of hardships and complexity. From the ones that have developed their atomic/immutable projects retroactively (so GuixSD and NixOS donât count as theyâve been atomic/immutable (and declarative) from inception), only Fedoraâs (Iâd argue) have matured sufficiently. But Fedora has been at it since at least 2017, so theyâve had a head start compared to the others.
In contrast to Debian (through Canonical), Fedora (through Red Hat) and openSUSE (through SuSE), Arch has literally no (in)direct ties to enterprise. Hence, it will only adopt an atomic/immutable variant if the incentive is high from the community or if itâs very easy and only comes with major benefits. But, as even openSUSE is currently struggling with their atomic/immutable variants, it has a long road ahead before it becomes something that can be easily adopted by Arch. Hence, donât expect Archâs atomic/immutable variant any time soon.
However, if any derivative suffices, then at least the likes of blendOS, ChimeraOS and even SteamOS are worth mentioning here.
The biggest issue with immutable OSs is the lack of containerized apps. Most devs simply donât distribute their apps in flatpaks etc. Install fedora atomic. Fist think I want to do is install xpipe to manage my servers. Canât be donât in an unprivileged flatpaks. Great layer it on.
Letâs try seafile next to sync my files and projectsâŠthe flatpak is maintained by a random volunteer and most up to date version is from a year ago. Great, layer that in as well.
Letâs install a command line tool, before it was 1 line, now itâs a whole lot of googling only to discover that the best way is probably to just have a whole other package manager like brew
The concept is great and it has lots of potential, just it will only work if devs start packaging their stuff in a format that works with the new paradigm (containers)
Yeah, I played with Silverblue for the first time a week or two ago, when I decided to move back to Gnome from Plasma. When I realized that Iâd need to layer adw-dark to get rid of the light settings panel in Gnome Console, and then layer in aptx and ldac support, and then some drivers for hardware accel in Firefox⊠I came to undestand that truly approaching this as minimally layering, and instead properly relying on flatpak and toolbx/distrobox wasnât going to work out. Instead Iâm just going to get anxious every time I have to say, âwell fuck, I guess I have to layer this too.â
That and I really donât like the mess of a filesystem. So back to Arch, with some things learned to keep stuff I donât like out of my base system. I can use a Bazzite-Arch container for Steam, to avoid having to enable multilib, for example. Well, if I can figure out the performance issues, anyway. And I know Iâm weird, but Iâd kind of like to avoid using AUR on my base system, and Flatpak kind of terrifies me for the reasons you mentioned
I do look forward to an immutable future, but I donât think itâs going to make me happy for some time. Maybe Nix or GUIX, but that sounds like a winter project. I know some folks use an Arch base with Nix layered on top, but that rather sounds like the inverse of what Iâd ideally want. It seems like the beauty of Nix is that you donât have to worry about layering, because YOU declare the base?
The biggest issue with immutable OSs is the lack of containerized apps.
Disagree. This is a non-issue for NixOS and Guix System. If anything, what you say only (somewhat) applies to Fedora Atomic or otherwise immature and/or niche immutable distributions.
For Fedora Atomic (and others that operate similarly), pet containers (read: Toolbx (and later Distrobox)) were originally envisioned as the solution. But, even Nix (and as youâve noted brew on opinionated uBlue) has been used to that effect.
Though, yes, I donât ignore that sometimes you just gotta layer it. Thankfully, as thatâs exactly why we got that feature đ.
I donât think xpipe would work, it needs too many permissions.
Something like seafile would work, better than overlaying it I guess but still isnât park of a package manager with easy auto updates etc like it would be if the devs published to flatpak.
At the end of the day itâs a lot more work that the promise of opening discover, searching an app and hitting install.
Not everything should be flatpakâd. In your case, xpipe (and in the future, waypipe) should always be installed in a docker container containing your normal âmutableâ OS. Itâs why Fedora is evaluating Ptyxis: when you open a terminal, instead of defaulting to your immutable root, it can be set up to go to a container which has your home mounted but a traditional, mounted root.
What are âcontainerized appsâ? Do they run in docker, podman, firejail, or bubblewrap? Also, what is their benefit?
In contrast to Debian (through Canonical), Fedora (through Red Hat) and openSUSE (through SuSE), Arch has literally no (in)direct ties to enterprise.
LOL Fedora and opensuse are copying from the commercial distros, but Debian is not copying Ubuntu (literally the opposite)
Fedora and opensuse are copying from the commercial distros
How are they copying if Fedora and openSUSE Tumbleweed are upstream to RHEL and SLE respectively?
Btw, I donât understand what your comment was set out to do. Could you elaborate?
What matters is the important stuff like deciding what package format to use, how to handle the biggest bugs, default filesystem, systemd or not, and who gets to decide all this stuff and so on. Some distros follow the company decision and some do not. Get it?
But have been wondering why I havenât heard of any immutable distros from arch based distros yet
SteamOS running on Steamdeck is Arch and immutabl/atomic for anyone not familiar.
Another one is blendOS
blendOS keeps everything simple, delivering on application and game compatibility from various sources while offering a lightweight atomic & declarative Arch system.
Aside from what others have already mentioned, atomic distros usually come with âbatteries includedâ, they have a desktop environment and bundled software. The goal is to have a complete setup where only the user space will need to be modified (for example by installing applications through Flatpak).
Arch doesnât really have a âbatteries includedâ default install.
I think a true arch linux experience can be done with immutable distros by modeling themselves after something like a nixos config or an rpm-ostree treefile. Like, during bootstrapping, youâd feed in a config file which would install everything into a future RO root. Would definitely be a lot of work, though, since pacman does (and probably will never) have the capability to manage multiple read-only roots.
steam deck? I wonder how many full-time staff valve devotes to testing and pushing regular updates.
I think a lot of arch people want the bleeding edge updates, so it seems a lot like to go btrfs or and setup snaphots or something if they want a safety net.
What is the benefit of an immutable distro?
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.)
Yep, also ability to rebase to some other image. Maybe thatâs what you meant by setting up a new system.
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.
Oh no⊠what is rebasing in this context? This isnât something related to git, I imagine?
(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.
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.
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.
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).
Honestly, IMO the end-user benefit is mostly that it sounds cool.
All the benefits Iâve heard (including the ones in this discussion) donât actually derive from âimmutabilityâ but from releases that stay the same for longer (which is what âmore stableâ used to mean), or the ability to roll back your system to some âknownâ working state (which you can do with snapshots and in a plethora of other ways).
What immutability means is that users are unable to alter their system, or at least not expected to⊠basically, it means what in corporate lingo would sound âaltering your system is not supportedâ and that the distro actively makes it hard for you to do so.
This means users will not break their system because they followed badly some instructions they found on some badly written forum post anymore and blame the distro for it, but it also means that users who actually have a reason to alter their system and know what they are doing will have a hard time doing it (or be unable to), which is precisely why I left macos and went back to linux for my work computer some ten years ago (I spent half a day doing something I could have be done with in five minutes and said to myself ânever againâ).
For the team/company that builds it, an immutable distro will likely be easier to test and maintain than a âregularâ one, which should then indirectly benefit the users (well⊠as long as the team/company interests are aligned with the usersâ of course: shall windows get easier for microsoft to maintain, how much benefit would trickle down to its end users?).
Users who switch to an immutable distro should see a decrease in bugs short-term. In the longer run, Iâd expect distros (especially the âcommercialâ ones) to reduce the effort they spend in QA until quality drops again to whatever level is deemed appropriate (if bread costs less Iâm still not gonna buy more bread than I need⊠same goes for quality).
Basically, it all boils down to âimmutable distros cost less to maintainâ (which, donât get me wrong, is a net positive).
I must say I find it slightly concerning to have heard several âveteranâ linux users say that immutable distros are so great that they will install one on their parent/child/SO/friendâs PC but on their own.
Itâs also a bit unnerving to notice that most of the push for immutability seems to come from companies (the likes of debian/arch/gentoo/etc. are not pushing for immutability AFAIK, and they certainly donât have the initiative in this field).
Iâm not sure how much immutable distros will benefit the community at large, and⊠Iâm not even sure they will end up being very successful (windows/macos follow in whatever makes is more profitable for microsoft/apple, linux users have choice).
I hope that immutable distros will prove both successful and good for the user community at large.
edit: Forgot to explain the positives I hope for: since immutable distros should require less effort, I hope this will lead to more/better ânicheâ distros from small teams, and to distros with bigger teams doing more cool stuff with the extra manpower
Essentially: read-only system files.
In immutable distros, you or any other programs that are installed on the system cannot modify the system files. That includes the system configuration files as well as applications. Its goal is to solve the problem of an entity gaining admin privlieges to your system and cause loads of damage. There are some addtional benefits too:
- Updates apply at reboot
- Root partition is read-only
- Considered very secure
- Sandboxed applications via flatpaks, snaps and appimages.
But then you also canât make any changes to the system files. I thought the point of Linux was having more control
Config files are still editable. Most of them (rpm-ostree, for example) have a mechanism for managing packages, and subsequently rolling back if anything goes wrong or completely resetting, and leave /usr/local writable. For stuff like development and working with compiler toolchains, you should be using a container. I use vscode exported in a distrobox running Fedora 40, for example.
