this post was submitted on 27 May 2024

48 points (91.4% liked)

Linux

48332 readers

719 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

AgreeableLandscape@lemmy.ml

nooter692@lemmy.ml

MarcellusDrum@lemmy.ml

cypherpunks@lemmy.ml

cyclohexane@lemmy.ml

d3Xt3r@lemmy.nz

Are we going to see arch based immutable distros in the near future? (self.linux)

submitted 6 months ago* (last edited 6 months ago) by Sunny to c/linux@lemmy.ml

63 comments fedilink hide all child comments

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/

top 50 comments

sorted by: hot top controversial new old

[–] yala@discuss.online 35 points 6 months ago* (last edited 6 months ago) (8 children)

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.

[–] Sunny 8 points 6 months ago

Thanks very much for the detailed response - this was very insightful!

[–] Lem453@lemmy.ca 5 points 6 months ago (6 children)

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)

[–] yala@discuss.online 4 points 5 months ago* (last edited 5 months ago)

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 😉.

[–] jcarax@beehaw.org 4 points 6 months ago

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?

[–] Giooschi@lemmy.world 3 points 6 months ago (1 children)

Can't those be installed in toolbox?

[–] Lem453@lemmy.ca 2 points 6 months ago (1 children)

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.

[–] biribiri11@lemmy.ml 3 points 5 months ago

I know ssh -X works fine in a rootless podman container, and so does waypipe. I’d be shocked if xpipe didn’t.

[–] biribiri11@lemmy.ml 2 points 5 months ago

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.

load more comments (2 replies)

load more comments (6 replies)

[–] pushcart@lemm.ee 25 points 6 months ago* (last edited 6 months ago) (1 children)

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.

[–] BrianTheeBiscuiteer@lemmy.world 3 points 6 months ago

astOS and Arkane Linux too.

[–] narc0tic_bird@lemm.ee 9 points 5 months ago (2 children)

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.

load more comments (2 replies)

[–] JackGreenEarth@lemm.ee 7 points 6 months ago (5 children)

What is the benefit of an immutable distro?

[–] yala@discuss.online 14 points 6 months ago* (last edited 6 months ago) (3 children)

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.)

[–] DarkDarkHouse@lemmy.sdf.org 3 points 6 months ago* (last edited 6 months ago) (3 children)

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

[–] yala@discuss.online 2 points 6 months ago* (last edited 6 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.

load more comments (2 replies)

[–] dsemy@lemm.ee 2 points 6 months ago (5 children)

(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.

load more comments (5 replies)

[–] Samueru@lemmy.ml 1 points 5 months ago (1 children)

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 5 points 5 months ago* (last edited 5 months ago) (1 children)

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 1 points 5 months ago* (last edited 5 months ago) (1 children)

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?

[–] yala@discuss.online 1 points 5 months ago* (last edited 5 months ago)

Thank you for the reply!

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

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.

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.

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).

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

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.

[–] gomp@lemmy.ml 10 points 6 months ago* (last edited 6 months ago)

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

[–] CrabAndBroom@lemmy.ml 4 points 6 months ago

I could see it being useful for like an office or something, where you do a big roll-out to a bunch of people. I'd assume having the system files be read-only and (presumably) the same on every system would eliminate a lot of guesswork for IT troubleshooting.

[–] Sunny 2 points 6 months ago (1 children)

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.

[–] JackGreenEarth@lemm.ee 6 points 6 months ago (3 children)

But then you also can't make any changes to the system files. I thought the point of Linux was having more control

[–] DarkDarkHouse@lemmy.sdf.org 7 points 6 months ago

The entity gaining access to system files and doing damage, it’s me.

[–] biribiri11@lemmy.ml 6 points 6 months ago

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.

load more comments (1 replies)

[–] oo1@kbin.social 7 points 6 months ago

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.

[–] biribiri11@lemmy.ml 6 points 5 months ago

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.

[–] Zetaphor@zemmy.cc 5 points 6 months ago (1 children)

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:

https://youtu.be/CwfKlX3rA6E

[–] Sunny 3 points 5 months ago

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.

[–] Wolfram@lemmy.world 3 points 5 months ago (1 children)

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.

[–] Sunny 2 points 5 months ago

Thanks for insight!

[–] Andromxda@lemmy.dbzer0.com 1 points 5 months ago

SteamOS is arch-based and immutable

[–] ulkesh@beehaw.org 1 points 5 months ago (2 children)

Honestly, I'd rather it didn't, or at least maintain the standard Arch as it is today. I get the appeal of immutable distros/installs, but they are just not for me. They feel like a lot more work, for not much benefit.

Also, given that Fedora atomic distros are the ones people seem to compare against, I don't like that flatpak is effectively required. I like flatpak and what it offers, I don't like that all apps I install must be flatpak, or that I have to go around that default in some way (when I tried one of the atomic spins, I kept running into apps that just didn't distribute as flatpak and it made things more difficult). I suppose this old dog doesn't want to deal with some new trick just to use his system like he always has with a simple pacman -S or apt install.

[–] biribiri11@lemmy.ml 4 points 5 months ago (1 children)

You don’t have to install everything as a flatpak if you don’t want to. You can totally install most things in a rootless distrobox container, then use distrobox export (if you’re using distrobox instead of toolbx) to get a nice desktop entry. It’s how I run VSCode and Quartus Prime, for example.

[–] ulkesh@beehaw.org 3 points 5 months ago

Or I could run pacman -S code on a system that doesn’t require hoops to jump through.

I think I just don’t see the reason or benefit of going the immutable distro route. At least not yet, for me. I’ll never say never, of course. Right now it feels like extra steps to achieve the same thing.

[–] Sunny 3 points 5 months ago (1 children)

Its honestly not that bad installing apps on these distros. Yeah the main one is flatpak, secondly appimages as easy as ever, and any other app can be installed via distrobox and exported if needed. If not that, then apps can also be layered onto the system if needed.

Ultimately it boils down to user preferences, but considering the growth and popularity of Immutable versions of distros, I would be surprised to not see a few more attempts from the Arch side of Linux.

[–] ulkesh@beehaw.org 2 points 5 months ago

I’m not trying to be a Luddite here, I love technology when it solves a real problem. I guess I just don’t have a problem that an immutable distro would solve.

load more comments