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.
Thanks very much for the detailed response - this was very insightful!
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)
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 😉.
Can’t those be installed in toolbox?
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.
I know
ssh -Xworks fine in a rootless podman container, and so does waypipe. I’d be shocked if xpipe didn’t.
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?
Actually yes. Fedora atomic has a system called toolbox that uses podman to encapsulate desktop apps. Flatpak also provides a sandboxed container.
The idea is to keep the OS and apps separate as much as possible for both security and stability.
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?
Don’t feed the trolls :)
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?
Thank you for clarifying.
I’m not very familiar with how stuff works over at (open)SuSE. However, for Fedora, we know that they’ve gone against Red Hat’s policy more than once. At the end of the day, it is
(at the very least in name)a community distro.But, I think we can at least agree on the fact that Canonical’s influence on Debian is definitely less than Red Hat’s influence on Fedora or SuSE’s influence on openSUSE.
Btw, consider conveying this better next time 😅. I think most others, like me, misunderstood you 😜.
Have a nice day!
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.
astOS and Arkane Linux too.
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 always thought immutable distros would be for servers. Am I missing the point?
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.
Give NixOS a shot. It’s got a learning curve that may be difficult if you’ve never read code, but it’s my preferred immutable setup.
It even has more packages than Arch.
Here’s the video that got me onto it:
Have actually tried it! And while I love the concept and how it works, its a bit too much to learn for me at the moment. It’s defo something I am going to pick up again in the future though! Also amazed me exactly how many more packages it had available than the AUR, mind blowing.
Here is an alternative Piped link(s):
https://piped.video/CwfKlX3rA6E
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
There have been at least 1 PoCs for arch linux based on ostree: https://wiki.archlinux.org/title/User:M1cha/Install_Arch_Linux_inside_OSTree
In addition, VanillaOS’s ABRoot has been packaged through the AUR
SteamOS3 is immutable and arch-based. You can see a fan-recreation of the image builder here
Otherwise, you can use the alpine linux immutable root with atomic upgrades guide.
Generally speaking, though, pacman is really basic, and the majority of the atomic/immutable magic happens in the package manager. That’s why only existing, complex package managers such as rpm-ostree (which shares a code base with DNF) have full support for it.
I just started toying with Arkane Linux. It’s fairly easy enough to make your own image and they provide some simple templates you can use if you don’t want Gnome. To me, the greatest thing about Arch is the AUR and unfortunately it doesn’t support AUR packages out of the box. This might not be a problem since you could mostly get along with flatpaks or distrobox. It might be a chore for someone new to Arch to have to compile something straight from the AUR that your device needs to function, like what I’ve had to do.
Thanks for insight!
SteamOS is arch-based and immutable
deleted by creator
lol
Both features are important IMO, reproducibility is for being able to define certain aspects of your machine in a way that you can nuke it and, as long as you have its configuration (declarative for Nix, other implementations might have it as imperative), bring it back just how it was set up, without differences or breakages; while immutability is for being always confident that whatever* you do to your machine, you won’t be able to break it because the root, which holds the functioning core of your system, can’t be messed around with, NixOS has both I believe.
*not really “whatever”, because there are still some ways to break, but you have to be very deliberate in doing it (think
rm -rf /*), but in normal operation you won’t just somehow install something or upgrade your packages and be left with an unusable systemNo, just because it is reproducible doesn’t mean you are able to (re)produce something that works. With something like fedora silverblue you know that this specific composition of packages and their versions has been tested, and that all the other users run this exact composition as well.
When you roll your own composition, where you install whatever stuff, you may be the one finding out that there’s some conflict between package a version u.v.w and package b version x.y.z.
Unless you both use exactly the same config files… Which is the point of nixos… Everything is versions locked. If you have a working config you can give it to your buddy and build it and it’ll work the same way
If you have a working config, thats exactly the point. Before you built your config, you don’t know. If you deploy silverblue, you know it will work beforehand because exactly this config, including /etc, has been tested upstream before. What you are to your buddy, Fedora Atomic is to me. The difference is, it is not just one person that tested some config they decided on on their single piece of hardware, it is the effort of a full blown distro team.
