Hehe, that’s very close to my reaction when I first heard about it 😜. I wasn’t able to find any of the technical details either, so I approached them through one of their community channels and they’ve been very patient and helpful. So, IIUC, they leverage bootc usr-overlay. But where bootc usr-overlay is transient, thus making anything installed through dnf go away on every reboot. RakuOS has somehow hacked their way to make it persistent instead. For more details, I’d suggest making contact with them. Perhaps you can retrofit their solution to your own system 😉.

Alright, that was quite illuminating. I suppose I was definitely not grasping the full extent of the extensibility found on Guix. And, perhaps more importantly, how it’s a defining feature of Guix. Thank you; I appreciate it.

I’m literally a newb to Guix, so please forgive me for my ignorance.

But while using (parts of) rde by regarding it as a channel is found within its documentation, I don’t think it’s the full picture. Like, rde is also a distro, at least by the admission of its creator. The same can not be said about nonguix. So, to be frank, I don’t think it’s just another Guix channel.

Having said that, I am still very new to all of this. So, if I’m incorrect and/or my understanding is lacking, then please feel free to correct/educate me on this.

While I think hearing about the sequence is cool as well, I was actually more interested in the (in)direct motivation behind it. Like, how did Arch Linux (specifically) manage to pique your interest?

Arch was my first choice

Could you please elaborate on that? Like, how did it become your first choice?

This isnt a distro

I don’t think you know exactly what constitutes an entire distribution.

Then what is? And which authorities endorses that view? Or…, is it perhaps possible to arrive at that definition by (logical) necessity? If no such authorities exist and if it doesn’t follow by necessity, then how is your definition anything but arbitrary?

Unsure whether it fits with the rest, but I’d argue it is an innovative and very compelling ‘standard’ that is competing with everything else mentioned in this thread.

So, the basic idea is as follows: if it is so difficult to deal with the loss of the main package manager found on the mutable/traditional variant, why don’t we pursuit ways to not lose it in the first place and thus try to make it coexist (somehow) with the atomic model. Enter RakuOS’s hybrid design in which everything installed through dnf is overlayed persistently over the bootc-managed base system.

Thank you very much for the detailed and well-sourced write-up!

It has been my pleasure 😊. I really appreciate your kind words 🤍.

It kind of proves OP’s point though: distros do come with a lot of idiosyncrasies of “how things are done around these parts”.

Absolutely. But, I think it’s nuanced and the lines are becoming increasingly blurry. If something based on Fedora can become something based on Arch (and vice-versa), if almost any distro has multiple releases/channels/braches, if software for/from any distro can be installed on every other distro, then… at what point is it truly “around these parts” rather than “with those not-hardcoded system specifications”? Kinda like how DEs can be (un)installed, and how those come with implications on how some stuff is done…

FWIW, uBlue has been brewing for almost three years now for their CLI stuff: see this issue tracker and this blogpost from Bluefin’s creator.

The distrobox workflow overall has mostly been superseded by better alternatives^[1]. Though, for completeness’ sake, openSUSE’s atomic offering continues to heavily rely on Distrobox. But, in their defense, I think their atomic offerings are simply better^[2] suited for it.

Not the one you asked, but I think the answer lies in the bold part:

most of these will make new users unhappy or even question their sanity.

For example, I can’t imagine any of the uBlue projects causing major difficulties. Though, edge cases do exist; adding kernel mods can still be a bitch, even if there are efforts to improve this.

I just thought that the phrase “the distro you are using doesn’t matter” is used to combat the analysis paralysis that many new users experience.

And -to be frank- while Ubuntu and NixOS don’t even remotely resemble each other, I can’t be the only one that feels that most traditional distros do feel kinda same~y.

Is there something locked down like Bazzite but with long term LTS release cycle?

The only high confidence projects I know of are:

• Bluefin LTS
• Endless OS, also see its documentation

There’s also stuff like HeliumOS, stillOS and probably other images based (in)directly on RHEL Image Mode.

I suppose because it simply is 😅.

To be honest, I’d say they’re being pretty generous in this case. The category for “Advanced Users” also includes the likes of Debian, RHEL(-clones) and SLE, none of which throw you right into a TUI; unlike Arch* 😅.

Furthermore, while archinstall has done a tremendous job at streamlining the process, the lazy noob that wants to rawdog it, will probably give up on their attempt. Contrast that to the installers of every other non-“Experts” distro, which by virtue of its non-archaic UI would have fulfilled its purpose.

And the troubles go well beyond initialization:

• Rolling release cadence with minimal testing amounts to plenty of breakage. To put into perspective, even if it’s not that bad in practice; Arch will break more often than (almost) any other distro on that list.
• As the previous point is known to cause plenty of agony, users are implored to stick to these instructions found on the excellent ArchWiki to combat that. While I’m sure Arch users are thankful for the instructions, it’s crazy that it is even required. Note that it’s expected that your Arch system is current and up-to-date. So you have to go through that routine at least once a week.
• The amount of packages in its own repositories is relatively slim, all of the other big-shot distros have larger repos. As such, the community relies a lot on other repositories; use of the AUR (in particular) is very prominent. But, as recent news has shown, you shouldn’t blindly trust that. Instead, you ought to look into the PKGBUILDs to ensure it doesn’t do anything shady. While this can make installing software more painful than it has any right to be, updates often involve changes in the PKGBUILD(s). In which case, you’re expected to go over it once again 😅…

There’s more to it than that, but I hope the case has been made pretty clear. With Arch, it’s (almost) as if you’re babysitting the system to ensure it doesn’t shit itself. By contrast; distros like Debian, Fedora and/or openSUSE mostly just work.

In case you wonder why people put up with all that shit, Arch does occupy a (relatively) unique spot if you want the following combined:

• Latest and greatest.
• Very big (user) repository.
• Lean. It comes with almost no defaults. With Arch, there’s no such thing as debloating or anything.

Hence, if you’re looking to build your very own system from (close to) scratch to a highly customized setup that does exactly what you want…, then Arch it is.