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/
(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.
Thanks for the quick reply!
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.
As alluded by the following in my previous comment:
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.
So, to conclude this point; yes, an immutable distro is not required to come with all those features by strict virtue of its immutability.
Arguably, our talk might have resolved a lot earlier if in your original comment;
That’s because most of these benefits are not a result of a distro being immutable.
, you had replaced “immutable” by “atomic”. To be clear, the “immutable” in “immutable distro” is not the correct adjective if we want to be descriptive. That’s probably why you chose to give the (current) definition of “immutable distro” rather than “being immutable” when prompted. Hence, the name “immutable distro” is continuously being redefined and rehashed based on the distros that are represented by them. The popular definition for “immutable distro” right after SteamOS 3.0 was released, was very different from the definition you gave it earlier. Which was again very different when we had only NixOS and Guix System as our points of references. Just like how I mentioned to not have any qualms with your earlier definition, I likely wouldn’t have any qualms with earlier shifts of the definition. Therefore, I’d argue, the notion of "immutable distro" is perhaps best defined by the distros that it represents. And currently, within the discourse, Fedora Atomic is its flag bearer. Hence, why a lot of other comments found under this post make assumptions based on that as their point of reference. But, I see Fedora Atomic merely as an iteration of NixOS but image-based (Colin Walters has even reported to be inspired by NixOS). And, the other (notable) immutable distros are heading that way. (And some, like blendOS, might already have come very close to that vision already.)
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.
It may not be very significant, but it is significant enough that even Qubes OS (with their excellent model) aspires to it. Btw, I never implied or said that security became perfect (quite the opposite actually) just by virtue of becoming immutable. Instead, I only said it improved*. Finally, I suppose it’s worth mentioning that e.g. Fedora Atomic does track the changes to /etc, keeps a pristine copy of /etc and allows you to flush /etc.
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.
No space occupied on your machine is better than some space occupied on your machine. I only said it’s better, its significance is definitely up to debate though.
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
To be clear, I didn’t intend to imply that literally all consequences are better. With “consequences”, I actually implied the points that were mentioned in the comment you first replied to; 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.
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
Let’s not disregard NixOS and Guix System 😅. Furthermore, I understand the frustration. Thankfully, even in Fedora Atomic, there’s a plethora of alternative package managers you can use to suit your needs; AppImage, Flatpak, Guix, Homebrew, Nix etc. Besides, I don’t think you install new software every single day. FWIW, systemd does offer the soft-reboot functionality; though, the biggest problem for me personally is restarting all the programs that were open. So yeah… Though, this might be an issue of the past with the upcoming systemd-sysext.
(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.
This criticism is absolutely fair. I know you felt compelled to said this only due to a misinterpretation of what I meant with “consequences”. Nevertheless, I am totally with you that the ‘Fedora Atomic’-model is not perfect. And, perhaps, never will be. For all we know, it will coexist with traditional distributions perpetually.
