not if you just postpone updating to the same schedule as Debian, lol.

LOL, indeed.

About the breaking part, kudos to you for doing a great job at maintaining Arch. But I assume/think^[Please feel free to push back on this.] most people don't enjoy 'babysitting'^[This term isn't meant derogatory or anything. But it's what comes up to me whenever I see how involved this is. By contrast, I actually do apply daily updates on my semi-rolling daily driver. But I never have to give it any thought. Heck, it even happens automatically.] their OS 😅.

Thanks for the elaboration!

The reply was already becoming quite long, so I deliberately chose to cut some corners here and there. I was hoping that the "somewhat" qualifier would do the heavy-lifting 😜.

I used it in this sense. But yeah, I admit it's not the traditional dictionary meaning. Unsure if it would be right to qualify it as a semantic change, though.

Hmm..., not sure if it satisfies your requirement, but you can basically create your desktop from Emacs. You may find an example below.

See exwm

It has been my pleasure :) . Thanks for the kind words!

Arch is an OS that’s quite fully featured

Not entirely sure what you mean with that.

suited to veteran/power users

The gist is that Arch pretty much comes with little to no defaults. So, you are literally put into the position to make all the important decisions. Which, as you might have imagined already, basically requires you to be pretty knowledgeable on Linux in the first place. Thus making it mostly unsuitable for new users. Though, I won't dismiss a special breed of newb that somehow manages to rawdog it quite 'successfully'.

because it has regular updates

We refer to its release cycle as rolling release. Which basically alludes to the absence of a point release.

The version of Linux Mint you were on is 21.2 and you'll soon be on 22.3. After some time, you'll be on 23.x etc. These are referred to as point releases. So, whenever a new point release update hits, you'll receive a couple of months' worth of updates. And between two consecutive point releases, you'll receive little to no updates. So, basically, Linux Mint deliberately chooses to hold updates of. By doing so, it ensures you'll only receive updates that have undergone thorough testing.

Arch, on the other hand, has a much leaner testing phase. Heck, as pointed out earlier, it doesn't even wait for a certain moment to reach before it outputs an update. Instead, after the packages have had some testing, it pushes the updates out for its users to receive it. As such, you'll receive constant updates. And you're somewhat expected to at least perform daily updates. By doing so, it ensures you'll always have access to the latest and greatest.

Note that Arch is not the only rolling release distro. But, out of the 'Big 3'^[The others being Debian and Fedora*.], it's the only one that is rolling release by default.

Its release cycle does indirectly contribute to Arch being less newbie-friendly. Basically, any update comes with the risk of causing breakage. On Debian, this risk is partly mitigated by the infrequency of updates and by pushing out very well-tested updates to begin with. On Arch, you just have to deal with it every once in a while.

Note, however, that it's most often your fault and not Arch's. Secondly, after dealing with this a couple of times, you'd have acquired some excellent skills in troubleshooting.

highly mutable

Traditional distros are basically equally mutable. So, Arch doesn't (necessarily) outdo e.g. Debian or Fedora in this regard.

It has its own repo too by the looks of it?

It does. But that's a thing with independent distros. Linux Mint is a derivative of Ubuntu. Which, itself is a derivative of Debian. Debian, however, is independent. Similarly, Arch isn't derived from anything else; hence, it's an independent distro.

The list of independent distros isn't huge or anything, but I suppose there are at least a couple of dozens of 'm.

As for the own repository part, both pkgs.org and repology.org feature some resources on that.

hardened

This is an important keyword but perhaps not sufficiently discussed. I'd reckon focusing on it will be pretty helpful.

So..., what is it you want? Is it

• A. Make a fortress out of a very decent starting point? To daily drive it afterwards*.
• Or B. Daily drive a fortress built by someone else?
• Or perhaps even C. Something else entirely?

By the rest of your post, I'd bet on B. Which, puts us into an interesting situation...

systemd free

Assuming^[To be honest, I don't see any reason to not grant them the benefit of doubt. As far as I can tell, their lists look complete.] DistroWatch does a decent job at tagging/categorizing, there are only a handful of distros that are both systemd-free and tagged with "security". Note that half of these don't survive it upon closer inspection, which leaves us with Alpine, HardenedBSD and OpenBSD.

If you're well-versed into hardened distros, you'll note the absence of Linux' finest in this category; namely Kicksecure and secureblue. Their absence is due to their (heavy) reliance on systemd for additional hardening.

Furthermore, note that DistroWatch doesn't mention how well the likes of Artix, Gentoo and Void (among others) would function as excellent starting points to build your own fortress from.

You can access those past images/snapshots even from a new install ;) .

As it seems to have been some time since it started, I'd suggest trying out the oldest still accessible snapshot/image.

Others have basically already pointed out how you should go about diagnosing the problem. Which, by itself, is already very valuable.

Below, I will try to touch upon some tips and tricks that are worth noting in this context, assuming Bazzite*.

• Pinning a specific deployment to return back to. As we'll be doing some time traveling in a bit, it's definitely recommended to pin your latest deployment (just in case) before you do anything else. See this entry in Bazzite's documentation on that.
• Rolling back to images from a certain day. So, IIRC, all of the uBlue products keep around 90 days worth of images you can rollback to. See Bazzite's documentation on brh for more information. With this (and some effort), you can literally pinpoint the exact date from which you started to have problems with gamescope/game mode.
• Looking into the exact changes between two deployments. So, after you've identified the last properly working deployment and the first deployment that started misbehaving, you can invoke the rpm-ostree db diff command to see what has changed between the two deployments. Note two things on this:
  • That the hashes coincide with the ones you actually want to compare.
  • The command catches only changes in packages. However, a config diff applied by Bazzite's maintainers will not be shown here.
• Asking help from community channels. You can even start here. But basically, a project's discord/discourse is undoubtedly better equipped in helping you out. See this entry on Bazzite's documentation for links.

Wish ya good luck fam 😉!

Alright, excellent. Thank you for the reply!

So, IIUC, you want a clean slate. Furthermore, you want plenty of tinkerability. And, finally, OpenRC enjoys a preference.

Still, I want to limit our search (for now) to (relatively) upstream distros on which OpenRC is known to work pretty well. We have to start our search from somewhere and this seems to be the most sensible starting point at this point.

If you've dismissed Artix, that basically leaves us (in alphabetical order) to:

• Alpine
• Debian
• Devuan
• Gentoo

IIRC, most (if not all) of these offer very minimal images. So, hopefully you'll enjoy those.

Thankfully, these are meaningfully different from eachother (for the most part). So choosing between these shouldn't be too much to ask.

FWIW, Gentoo comes undoubtedly with the least amount of defaults and thus behaves the most like a blank slate.

I am most fond of Arch

But what is it that you like about Arch in the first place?

I found that I’m more comfortable with OpenRC as init and process management.

Like, do you want to limit your options to distros that are well supported by OpenRC? Or, is this simply a preference kind of thing?

the Artix forums also seem to house at least some transphobia

Do you want to engage in distro-specific forums or was your engagement in there mostly out of necessity?

as opposed to configured by me.

Excellent, so you're a builder/tinkerer that prefers a clean slate to work from.

Assuming you're involved with the development on AstrOS, thank you first of all for your efforts and secondly for providing your perspective on the matter!

Imo it generally does too much.

Oh, I can definitely see that; probably the consequence of retrofitting an OCI/Docker image into an OS 😅. I suppose that its relation with (rpm-)ostree doesn't help either.

Systemd-sysupdate being simple as hell makes it just way more solid.

That's some cool insight. Thank you.

I think it also depends on grub and stuff

I believe it did, yes. But, AFAIK, systemd-boot has been supported since earlier this year. I believe that change has also been instrumental in the relatively recent activities surrounding so-called sealed images.