bsergay

You're on fire, fam! Thank you for another quick one.

Before moving on, I want to make clear that I should correct some of my earlier statements. It probably doesn't matter, but for sake of completeness.

I actually even agree with this. But, and here it comes, you limit the use of ‘immutable systems’ when it comes to regular workspaces to just a subset that complies with “if stability (and possibly security) are preferred over absolutely everything else”. However, I’d argue it will soon become the preferred model for most people; simply because I’d argue the net positives dramatically outweigh the (diminishing) net negatives. And this ‘clash’ in perspectives is literally a philosophical/ideological one. Which, I actually tried to allude to in my very first comment. Btw, neither of us is right or wrong; as mentioned earlier, only time will tell.

What I describe above is not meant for immutable systems, but for 'immutable' distros.

This is enough to cause most of the issues.

I didn't imply otherwise 😜. I was just explaining how immutability works on Fedora Atomic.

Not really because this is a pre-installed tool that doesn't require any hassle to get working.

Excellent. I agree. So, "disabling immutability" therefore only applies to 'hacks'. Right?

It wasn't my experience. I've never tried an immutable distro myself because it goes against my personal preferences and needs. I saw that on YouTube. I don't remember what distro it was unfortunately but I'm almost sure it was Fedora based.

Thanks for being transparent! I also appreciate you sticking to your values.

Also in case you didn't know, GTK themes are usually installed in /usr/share/themes so disabling immutable is required to do so even if /usr is the only thing that's immutable.

I knew this (and also how ~/.local/share/themes could be utilized for this). But, fair; this is indeed something that Fedora Atomic's old model didn't allow. Or, at best, very 'hacky'. Like, it's basically not intended for the end-user to put stuff in here. Fedora Atomic's new OCI-enabled model does allow this. But, yeah...; we ain't (necessarily) here to discuss implementations. Fact of the matter and the issue at hand is that traditional distros don't deal with issues like these. Right?

Sure but this excuse won't help new users and won't stop them turning away from Linux.

IMO, if a new user wants to use an 'immutable' distro, then they should just use one of uBlue's images. They're like the Linux Mint or Zorin or Pop!_OS of immutable distros. And, as previously mentioned, uBlue's documentation is at least sufficient. Traditional Linux distros are not to blame if a new user breaks their Manjaro installation. Similarly, 'immutable' distros are not to blame if a new user breaks their not newbie-friendly 'immutable' distro.

I meant the disadvantages of immutable systems here, not stability in general.

I think I got you now. Like with the previously mentioned issue with placing themes inside the /usr/share/themes directory; on any traditional distro, you'd be free to place it there and you wouldn't even have noticed a thing. While some 'immutable' distros, like Fedora Atomic, make this hard. Do you think I understood you correctly?

I have no idea what a runtime is so I can't answer this question.

The expression "during runtime" is used to express a running and/or currently in use system. So, if my device is off, then the expression "during runtime" does not apply. When I'm using the system or even if it's just idling, then the expression "during runtime" does apply. However, it's possible with Btrfs (and more sophisticated technologies) to create a partition/deployment/image on your disk that's currently not running nor in use and which has some changes compared to your running system. Then, once again, the expression "during runtime" does not apply.

Perhaps, I could be even more elaborate. So, on the overwhelming majority of 'immutable' distros (Guix System and NixOS are literally the exception) that offer a built-in mechanic for installing packages to the immutable base system (like the aforementioned rpm-ostree that's found on Fedora Atomic), the changes are not meant to be applied directly on the running system. So, for example, right after rpm-ostree install emacs, I can't just type emacs in a console/terminal and expect it to open. Nor does it appear in the app drawer. Only after the (soft-)reboot will I be able to use Emacs; be it through the console/terminal or find it in the app drawer.

So, these are examples of 'immutable distros' that are only (meant to be) immutable during runtime, because it's possible to apply changes to a system that's not currently running/in-use/idle or whatsoever.

I use the term "immutable system" because someone can create an immutable fork of BSD or even Windows can become immutable. It's not just about Linux.

Interesting. Thanks for that clarification.

WOW, I just noticed something. You’ve been using the term “immutable system” for quite some time. And, I’ve primarily been using the term ‘immutable’ distro.

The crux of this conversation lies here I believe. Your notion/understanding of an immutable system is probably more correct and more in line with what you'd expect from its name. However, the name "'immutable' distros" is unfortunately not descriptive. Contrary to what you'd expect, it's not a distro that happens to be an immutable system; at least, not in the absolute/complete sense.

I agree with you that this is misleading and a poorly chosen name. Heck, Fedora agrees with you; they've changed "Fedora Immutable Desktops" to "Fedora Atomic Desktops" because of this. However, as bad as the name is, people use the term "'immutable' distros" when talking about Fedora Atomic, Guix System, NixOS, openSUSE MicroOS and Ubuntu Core.

That's why I said this:

Interesting. Here’s the thing; I am unaware of any so-called ‘immutable distro’ that fits this definition/description/notion/idea/understanding of an immutable system. So…, where do we go from here?

And, to be honest, I'm not sure if you answered the bold question.

Thanks (once again) in advance! And apologies for this long comment 😅.

Quick reply. Awesome!

Idk if it changes anything but in that part of my comment the word “workspace” should’ve been replaced by “workstation”. I guess I chose a wrong word in autocorrect.

Nope, it doesn't. But thanks for clarifying!

An immutable system is when everything (or almost everything) except for /home is read-only.

Interesting. Here's the thing; I am unaware of any so-called 'immutable distro' that fits this definition/description/notion/idea/understanding of an immutable system. So..., where do we go from here?

Idk if my English was an issue there but it looks like you understood that part completely upside down.

In retrospect, I think you actually did an okay-job at explaining your thoughts. But, yes; I did indeed misunderstand. Thanks for clarifying!

Probably. Idk anything about ostree.

In Fedora Atomic, most of /usr is immutable. IIRC, this is even the only directory (combined with the sub-directories found within) that are immutable. However, the command rpm-ostree install <package> allows the user to install packages into /usr. However, this change doesn't happen during runtime. Instead, a new image/deployment is created with the newly installed package that you can access after a (soft-)reboot (or with --apply-live if you like to live on the edge).

Based on this, does this still apply as "disabling immutability"?

What I meant is that if you want to manually edit a file anywhere except for /home (or do any manual changes to the system like installing a GTK theme), you have to run a command (I forgot which one) to disable immutability for the directory it’s in (or only for the file; I don’t remember).

This seems to be based on your own experience. If so, would you be so kind to inform me on which distro this was?

For new users it can be a problem because it may be hard for them to find a good tutorial that covers all the steps, especially at the start of the “immutability boom” if it’s ever going to happen.

Currently, apart from the documentation provided by uBlue and Guix, there's definitely a lack of good resources for 'immutable' distros. That's simply a fact. But, thankfully, this is not a problem by design; we just need people that are willing to put in the effort.

As I just said, more stability means that issues are more stable and hard to solve as well.

Sorry, I'm having a hard time understanding this. Could you perhaps provide an example of this from e.g. Debian? It can be any distro that's regarded as 'stable'*.

Unless I'm wrong, you seem to have missed the following. It would be awesome if you could touch upon these as well:

Furthermore, is it required that an immutable system should remain immutable at all times for it to be considered an immutable system; i.e. changes are not allowed besides ‘hacks’? Or is it perhaps possible for a system to be deemed immutable if it only possesses immutability during runtime?

Thanks in advance 😊!

WOW, I just noticed something. You've been using the term "immutable system" for quite some time. And, I've primarily been using the term 'immutable' distro.

Thank you. Thank you.

I am sorry, mister/miss. Something weird happened to my Lemmy account and it was inaccessible for 2 days.

No worries, fam 😉.

Immutable distros are good for cases when the machine is meant to be used for very specific tasks and applications while maintaining extreme stability and ease of updating. This includes OSes for ATMs, machinery control panels, enterprise office computers with very strict policies, educational computer class devices. I am not sure whether they are good for critical infrastructure such as aerospace industry and on-board computers so I can’t comment on that and it’s too early to do so anyways.

I think we very much agree on this. I am actually surprised 😜. Perhaps we (possibly) only 'disagree' on the following:

Immutable systems can also be used for regular modern workspaces if stability (and possibly security) are preferred over absolutely everything else.

I actually even agree with this. But, and here it comes, you limit the use of 'immutable systems' when it comes to regular workspaces to just a subset that complies with "if stability (and possibly security) are preferred over absolutely everything else". However, I'd argue it will soon become the preferred model for most people; simply because I'd argue the net positives dramatically outweigh the (diminishing) net negatives. And this 'clash' in perspectives is literally a philosophical/ideological one. Which, I actually tried to allude to in my very first comment. Btw, neither of us is right or wrong; as mentioned earlier, only time will tell.

For me an “immutable distro” is defined more by its read-only (or R/W with write being disabled by default) root file system than by reproducibility or any other stuff.

Alright. So, you prefer to refer to 'immutable' distro in the literal sense.

~~Regarding the status of the read-only (or disabled R/W) root file system, does this have to apply to the complete root file system; i.e. absolute? Or does it suffice if only a select subset of the system is read-only (or disabled R/W)?~~ I wanted to ask this, but later on you made clear that a system does not have to be completely and absolutely immutable for it to be considered immutable; a couple of read-only directories suffices.

Furthermore, is it required that an immutable system should remain immutable at all times for it to be considered an immutable system; i.e. changes are not allowed besides 'hacks'? Or is it perhaps possible for a system to be deemed immutable if it only possesses immutability during runtime?

Thanks in advance for yet another set of clarifications 😜!

Afaik NixOS does not use any form of read-only FS so that’s why it is not an immutable distro to me.

Teaser; the Nix Store, i.e. /nix/store, is immutable.

“Disable immutability” means “allow persistent changes for files and directories located in specific directories that are not in the /home directory/partition (“read-only” directories)”.

Very interesting. So, on Fedora Atomic, rpm-ostree install <package> would be considered "disable immutability". Right? But, this does not apply to flatpak install <package>. Right?

No matter how good your distro is, there always will be new users that need fixes or customizations that require extra steps and research on immutable (as in my definition) distros. This increases the chance of them giving up on Linux or creating angry/toxic posts on Linux related websites and communities.

To be clear, new users will most likely experience some issues on Linux for the time being. I don't think that 'immutable' distros are immune to that. Nor do I think they're particularly more troublesome. If anything, they allow for more stable experiences overall; which you seem to allude to as well.

My previous comment was perhaps too enthusiastic 😜 . I'd like to slim it down as follows:

• First of all, thank you! It has been a lovely interaction so far. Your clarifications have been very helpful!
• I'm still very much interested in how you think 'immutable' distros should be understood and used.
• If I understood you correctly, you don't regard NixOS as an 'immutable' distro (or at least not representative), would you be so kind to elaborate on this?
• Some of your notions regarding 'immutable' distros don't align with my own experiences; i.e. a user with over two years of experience with Fedora Atomic and who has played around with Nix. Especially the following parts:

In the case of immutable distros, I feel like it’s gonna be some nice to watch chaos because new users will have to understand how to disable immutability to install drivers and fixes which means much more research (because most answers will just say “disable immutability for the directories that the fix needs” and the user will have no idea of any of that) and terminal commands.

To be absolutely clear, these notions are (almost) alien to me. I've only come across these with new users that had fallen for the (infamous) XY problem. But that's not even remotely representative. Hence, would I be correct to assume that your understanding of 'immutable' distros is relatively shallow? Which, to be absolutely fair, is totally fine.

Though, the possibility exists that your understanding of "disable immutability" is correct, but this particular phrase happens to be misleading instead. Hence, could you perhaps elaborate on what you mean with "disable immutability"? Like, how does that look like on any 'immutable' distro you're familiar with?

Thank you in advance 😊!

Thanks for the suggestions!

It has been my pleasure 😊!

With these, do you get a full desktop environment or are they quite specific to being that home entertainment experience, more like a smart TV?

So, if intended as a HTPC, both Bazzite and ChimeraOS are 'meant' to be used with Gamepad UI; i.e. the one found on the Steam Deck. Of course, this is your console experience. However, just like the Steam Deck itself, it offers access to its so-called "Desktop mode". Which, as you'd expect, is a full desktop environment. For Bazzite, you get to choose between GNOME and KDE Plasma. While ChimeraOS currently only offers GNOME.

LibreELEC, on the other hand, is a distro that merely functions as a wrapper for Kodi. Hence, there's no desktop environment (by default).

Bazzite, ChimeraOS and LibreELEC come to mind as distros fit for HTPC/console experiences.

Arch does not just randomly break

You might be right. However, the experiences of my own and many others seem to 'contradict' this.

FWIW, I've run Arch and EndeavourOS in the past. And, for some reason, (seemingly) entirely out of the blue, it just stopped booting. I put in some effort with troubleshooting. But, at some point, I just got tired and/or didn't ever want to deal with this anymore and left it for what it is. I've left Arch behind me ever since.

To be fair, I've had a similar experience with Nobara. So, this is not necessarily an 'Arch-thing'. However, a significant part of the community has experienced similar issues on non-stable distros (i.e. distros that don't have a slow release cycle).

While I'd be the first to admit that this is (perhaps) merely a skill issue, the fact of the matter is that similar experiences on other OSes are practically non-existent. Hence, it's a hard sell to someone that has enjoyed 'stability' in the past.

Thanks for the reply!

In general, I'd have to say I agree with your post:

• Reset option is indeed a necessity. Especially on 'immutable' distros. Because, why even bother otherwise?
• Their community seems less diverse compared to Fedora's. Granted, I believe Fedora's community is probably most diverse due to how (relatively speaking) popular it is in combination with its release cycle being (roughly) in the middle of what you'd get otherwise with Arch on one end and Debian on the other.

However, I'm hopeful of what they'll cook for their 'immutable' spins.

Btw, FWIW, regarding the reset option, perhaps there's reason to be optimistic regarding its future; here's Richard Brown on the topic and here's a page he refers to related to this.

Thank you!

I definitely hope that the noise ration will improve (by the amount of noise decreasing) over time. But, as it stands, the community is still relatively small. I get your grievances, but I honestly don't know what the best set of directives would be.

I think I agree with the other commenter that you should just take a break.

Sorry, I tried to search it but to no avail. What are the WRB apps?