this post was submitted on 27 May 2024
48 points (91.4% liked)
Linux
46819 readers
1395 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
For me:
and their consequences;
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?
Anti Commercial-AI license
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.
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.
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.
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?
Thank you for your reply!
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.
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)
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.
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.
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!
As alluded by the following in my previous comment:
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;
, 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.)
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
.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.
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.
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
.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.
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.
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).
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?
Thank you for the reply!
What you refer to in NixOS is indeed its solution to offer declarative system configuration. But the other two mature immutable distros, i.e. Fedora Atomic and Guix System, have their own solutions. Though, Guix System's solution is a lot more reminiscent of NixOS'. While Fedora Atomic leans on 'the ways' established for OCI (and hence containerfile(s) etc). Even less mature immutable distros, i.e. blendOS and Vanilla OS, have put considerable effort into the works for managing their systems declaratively.
My argument here is mostly just "No occupied storage on device is better than some occupied storage on device.". But yeah, its significance is definitely up-to-debate. Perhaps I should have relied more on the built-in aspect; from the mainstream independent and/or highly popular traditional distros only (Garuda,) Linux Mint(, Manjaro, Nobara) and openSUSE Tumbleweed come with built-in rollback/snapshot functionality. But, regardless, the rollback/snapshot part of the equation is definitely the least special (if at all).
It's indeed related to how some parts of the system are read-only during runtime (under normal circumstances). Hence, some types of attacks are circumvented from the get-go. This, by itself, doesn't warrant the use of an immutable distro over a traditional one; even if the user is security conscious. However, if said user already intends to use a distro that takes security seriously (i.e. Fedora or openSUSE) for the sake of security (or at least it plays some role in their decision-making), then they might as well prefer their atomic counterparts. But yeah, for actual security, one should probs rely on Qubes OS instead. Though, atomic distros have given us the likes of secureblue; which may be the most secure Linux system for general-use we got (besides Qubes OS, if we even count that as Linux). The only other contender is Kicksecure.