bsergay

Could you describe what has transpired before? Have you actually installed Debian? Are you still trying to boot into the install medium?

Perhaps sharing device specs might be helpful.

Gentoo is considered stable

Honestly, I'm too unfamiliar with Gentoo to make a proper assessment on this. Though, even my (simple) understanding allows me to understand it as follows:

• Gentoo is not a point-release distro. Hence, by definition, it satisfies the definition of a rolling-release distro.
• Furthermore, regarding Portage's branches, this page suggests only two branches; Stable and Testing. With Stable being set as the default one. Furthermore, AFAIK, tests occur for over a month over at the Testing branch before updates enter the Stable branch. Hence, more time is taken compared to other rolling-release distros.

Which, I believe is what's alluded to here: "The update philosophy of a distro is generally not related to its release cadence, as you can have rolling release distros that are relatively stable (for example, Gentoo) and point release distros that are relatively bleeding edge (for example, Fedora)."

Is there any reason why you would deem Gentoo as not stable? If so, what?

but fedora “leaning unstable”?

For the sake of completeness, proper quotation would have been "leans bleeding"

I'll give you that the article is definitely not exhaustive and/or properly clarified. Perhaps for the sake of brevity, idk. Hence, I believe that this confusion is justified. However, again, I think the raised point is justifiable based on the following:

• Fedora is known to push new tech first. Heck, it even adopts it first; e.g. PulseAudio, systemd, GTK4, Wayland, PipeWire etc. Hence, this causes Fedora to feel bleeding edge; i.e. because its users are literally the first to test it en masse.

May I ask why you think Fedora does not lean towards unstable?

Anyway what is that whole un/stable supposed to mean anyway?

I agree it causes more confusion/conflation that it has any right to.

All non-rolling distros try to be stable.

It depends on the used definition of "stable" 😅.

• If "stable" is used here in the context of name for used branch (of the repository). Then yes, but this also satisfies rolling-release distros; as they, by default, ship software with their own designation of "Stable" (even Arch). (For the sake of completeness, I'm aware that some distros default to testing/unstable branches.) Hence, using this definition of "stable" is not very productive.
• If, instead, "stable" is used in the context of stability. Then, also yes. And, yet again, this also satisfies rolling-release distros. It's not like any reasonable distro is out there to deliver software that's known to cause issues and whatnot. The distros only differ in how exhaustive their testing is. Which gets us to...
• If, finally, "stable" is used in the context of how well-tested the distro is. This also ties in to the earlier presented definition for name of the used branch (of the repository). Because we all know that Arch's Stable repository is wildly different from Debian's Stable repository. And here, unsurprisingly, we find wild differences that are also actually helpful in a productive conversation.
• (Surprise,) tied to the previous point, "stable" could also refer to how often the distro requires you to update. With "stable" being used to indicate that updates are only required between (infrequent) point-releases. However, non-intrusive security updates should be able to get through regardless.

What can break are third party repos and stuff you compiled yourself.

Sorry, I can't agree with you on this. Even if this is said in the context of non-rolling distros, my experiences with Fedora suggest otherwise. Granted, Fedora is sometimes referred to as semi-rolling release distro. So, perhaps it (and direct derivatives) are the exception.

With fedora that can “break” twice a year.

Agreed (with earlier mentioned caveat*).

With a rolling distro that can “break” on every updates

Agreed.

• Aeon
• Argon and Krypton
• Kalpa
• Leap Micro

Laptop

I'm personally a fan of NovaCustom; not as upgradable as Framework, however 7 years of parts are definitely nice to have. They also offer video tutorials on how to replace parts. Good stuff.

But, like any vendor targeting Linux, its devices can be more expensive than what you'd expect from Asus, Lenovo etc.

Perhaps the most important questions that need answering are the following:

• How much computation power is required? I.e. do 10th generation Intel chips suffice or not?
• Are you okay with buying devices second hand?
• How much explicit Linux support do you require from the vendor?
• Do you live in Europe or in USA (or close enough) to buy from Linux-first vendors and not be deprived from sending and receiving the devices (for reparations and what not) due to associated costs and time?

Distro

As for distro, it all comes down to personal taste.

• Linux Mint Cinnamon Edition if you require a popular, reliable and beginner-friendly base.
• If you don't like how Cinnamon (the Desktop Environment) looks and/or feels, perhaps consider Pop!_OS, Tuxedo OS or Zorin OS instead.
• However, if you prefer minimalism, then the likes of Debian and openSUSE Leap have to be mentioned.

All of the previously mentioned distros are known to ship older versions of software. This is excellent if you require stability above all, but what if you want a distro built on more up to date software? Well, consider the following then:

• Fedora; software found here is at max six months old. Relatively minimal. However, it may require you to fiddle with codecs and what not on first boot. Thankfully, there's a lot of documentation out there to help you with this. Just ensure that the documentation is written relatively recently.
• If you like what you see from Fedora, but would rather prefer a distro that's properly setup right from the get-go; then perhaps consider one of uBlue's images instead. These are known to provide the most stability out of the (relatively) up to date distros. Please ensure to thoroughly read through its documentation, though. The uBlue images are excellent, but their inner workings can be different from other distros. Hence, you should rely on its own documentation first. And only after you've determined that it's not found within should you consider consulting other sources.

Perhaps, you might prefer software updates as soon as they're available. Hence, Fedora (and derivatives) didn't quite cut it. Then, you should consider so-called rolling release distros. However, take note; every update comes with the risk of potentially breakage; i.e. something will misbehave that didn't before. The chance of this is relatively small; probs in the order of 1%. This chance persists; regardless of the chosen distro. Hence, with distros that update more often, it's more likely that some breakage will occur at some point.

With that out of the way, we should mention noteworthy rolling release distros:

• openSUSE Tumbleweed is for those that absolutely require a rolling release, but desire as much stability as possible. Both openSUSE's testing as well as built-in Btrfs + Snapper work hard to ensure a smooth ride.
• EndeavourOS or Garuda Linux are the entries from the lineage of the (in)famous Arch (btw). EndeavourOS is primarily known for its easy installation towards a minimal Arch system. Garuda Linux, on the other hand, is more opinionated and therefore comes with all the bells and whistles you'd expect from a distro oriented towards gamers. Still, it comes with Btrfs + Snapper built-in. Which is exactly why it's mentioned here. Note that you can setup Btrfs + Snapper yourself on EndeavourOS.

Thanks for reading through it and giving your thoughts!

Could you elaborate on the mistakes/oversights found in the "Stable vs bleeding edge" section?

Running software you know you can’t trust is idiotic no matter how well you sandbox it.

Qubes OS disagrees.

Thank you for your honesty! I only intend for the truth to prevail and/or to reach mutual understanding. So please don't feel attacked. If somehow I came off as such, my apologies; that has never been my intent.

No sorry, Fedora Atomic has allowed changes to /etc since at least 2019. Regarding NixOS, the consensus is that it's an immutable distro. The immutability of /nix/store/ suffices for this.

Your notion on Fedora Atomic was false. So, what other 'immutable' distro did you have in mind when making that comment?

/etc can’t be edited on immutable distros

False on at least Fedora Atomic^[1]^, NixOS^[2]^ and openSUSE Aeon^[3]^..

Which 'immutable' distros are you referring to?

1. On Fedora Atomic, changing /etc is literally identical to how it goes any other distro; or at least 1-to-1 as on traditional Fedora. The bonus is that a pristine copy of the original /etc is kept inside a sub-directory of /usr. Furthermore, all changes compared to the pristine copy are kept track of.
2. On NixOS, changes have to be applied through configuration.nix. Though, regardless, it's effectively possible to edit and populate /etc like it is on other distros.
3. It's explicitly mentioned that /etc does not belong to the immutable base.

Unfortunately, you've yet to respond. Therefore, I was unable to verify everything mentioned below. Regardless, for the sake of completeness, I would like to give a brief overview of our interaction and how I have perceived it.

My intent regarding this conversation:

• Reach a common ground on our understanding of the topic at hand. Like, what even is an 'immutable' distro.
• Highlight how the basic notion of an 'immutable' distro' encompasses a wide variety of distributions that differ from each other more than traditional distros do.
• Understand why, despite acknowledging the importance of implementation, you still believe it's inconceivable for future implementations to overcome current shortcomings.

However, we weren't able to get that far. This is IMO primarily due to the following:

• Abrupt end of the conversation by you. This is basically the reason.
• Your misrepresentation of yourself. I accurately point towards the pain point. However, you -for some reason- deny it or accuse me of intentionally misunderstanding. However, eventually; like a few comments down the line, you accept my earlier found pain point. This just makes conversation take way longer than it has to. Like when I rephrased your understanding of 'immutable' system to one in which some directories are immutable. You first accused me of misunderstanding, but later used partial immutability yourself.
• Your use of words, phrases, and sentences without recognizing the need for definitions. When later prompted to give definitions, you've failed spectacularly at giving complete and/or sufficiently clarified ones. This prompts me to ask for clarifications, and the cycle continues... I believe this stems from your lack of familiarity with the subject matter. Like how I had to explain to you what runtime is. A word which is used in the actual definition of 'immutable' distros.

The points you actually raised to discredit 'immutable' distros:

• Unfit for old PCs and/or HDDs. Answer: This is related to implementation. You even agreed to this when you noted yourself that this is not an issue on NixOS. So, busted.
• Different workflow compared to traditional distros. Answer: I don't quite recognize why this is a problem. The workflow on the very first Debian is different from how it's today. Does that make Debian's current iteration bad? No, obviously not. Similarly, it being different is not inherently a wrong/bad thing. So, again, busted. The important part is documentation/guides/tutorials that facilitate the needs of people that intend to switch and/or try it out. Which brings us to...
• Lack of resources. Answer: This doesn't make it inherently bad. It just makes it harder for users to learn how to interact with the system. And, again, this continues to improve as the user base becomes bigger. When I made the switch (over two years ago), resources were abysmal. However, today, projects like uBlue have produced good documentation for its users. And it will only ever improve. Yet, again, busted.
• Tampers tinkering. Answer: In the absolute sense; no. There's only very little you can't do on current 'immutable' distros. And there's active effort to work those things out. So, it's related to implementation and/or maturity. It's also not clear what prevents a future implementation of an 'immutable' distro to be interacted with exactly like how we interact with traditional distros. Consider looking into stuff like systemd-sysext if you want to see a glimpse of what's yet to come. Thus, this point is also refuted.

There is perhaps a lot more I could go over, but I'll suffice with this for the sake of brevity.

My apologies for being persistent; I'm just very much saddened that the IMO great conversation abruptly ended when it was so close to resolution. Regardless, this will be my last attempt at engaging in hopes of continuing the earlier conversation. However, full disclosure, if you don't respond, then I will leave you with a final message in which I will lay out what I got from this conversation and my overall view in regards to how it went etc.

So, without further a due.

I would like to cut the chase and be very direct:

• Finally, we've come to a common ground on what an 'immutable' distro even is. However, it's still unclear why the perceived inconveniences/difficulties are not merely related to implementation. Like, for all we know, in some future implementation of an 'immutable' distro, you could run whatever command you run to place your themes in /usr/share/themes, (soft-)reboot and find the theme in the designated folder. To me, it seems, as if you dismiss this possibility. If this is correct, why do you think that's the case? Isn't there more reason to be hopeful considering the mere fact that we're currently able to apply tons of customization that were previously inconceivable?
• You accuse the complete industry for misunderstanding and misusing 'immutable' distros. While, simultaneously, relying only on very basic second-hand information for your views on 'immutable' distros. Is this sensible to you?
• It seems as if you're not open to consider many other possible benefits that come with 'immutable' distros. The most recent addition/example of this would be openSUSE going in the direction of an OOTB measured boot with their openSUSE Aeon. Like, how did you even perceive this and did it make you rethink the possible benefits? Do you think it's conceivable that other people might have legit reasons for preferring 'immutable' distros that go beyond what you had previously described?

Is this different from UKI? If so, how? Thanks in advance!