What exactly does uBlue do differently to Silverblue, which makes it easy to modify those parts?

Perhaps I should’ve been more precise/accurate. The images offered by uBlue are relatively vanilla but “batteries-included” images of Silverblue/Kinoite etc that include the essentials from RPM Fusion among others and ensure that your system continues to function optimally regardless of ongoing issues related to mesa/Nvidia or whatever. So by themselves, they don’t do anything special necessarily in terms of modifiability except for having baked in functionality for receiving cosigned OCI images. Which is where the fun begins with the template provided by uBlue making it very easy to create your own custom cosigned OCI image that is modified to your liking and which is continuously pulled from whenever your system does a rpm-ostree update. As the changes don’t happen at the client-level (read: your device), but instead before/during ‘base-image initialization’, one is able to apply changes to e.g the aforementioned /usr directory simply by creating those (modified or not) files in the github repo of their custom image. The linked template is far from exhaustive as one is able to customize it beyond that for which one could refer to the Bazzite or Bluefin images to see the possibilities.

Note that the template of uBlue is only possible because Silverblue/Kinoite etc supports it. So one is able to forego uBlue entirely and create their own image from scratch (as long as it satisifes some criteria). The beauty of (the template provided by) uBlue is that it enables every mortal to engage with that system as it has been made remarkably easy. Heck, I didn’t have any prior experience with git or Containerfiles, but I was able to spin up my own image in like two hours or so.

Eg, how do I alter a file, say /etc/fstsb, in Fedora Silverblue, Nitrux, BlendOS etc?

I’ll answer for Fedora Silverblue as it’s the only one I’m confident about. So, by default, both /etc and /var are writable. Furthermore a lot of traditionally writable parts (like /home) are contained within /var as well. So say you’d want to edit /etc/fstab (which I’ve done in the past), then you’d literally do it the very same way you’d do it on non-‘immutable’ distros. So; copy (the content of) /etc/fstab, change whatever you want and sudo cp the modified file to /etc/fstab and you’re done.

Perhaps interesting to point out is that, on Fedora Silverblue, all changes compared to the pristine copy of /etc (which is kept in /usr/etc) are being tracked and can even be accessed with ostree admin config-diff. Note that ‘traditionally’ the contents of /usr has been one of the harder parts to modify on Fedora Silverblue and I’d argue the average Joe should not engage with it as it’s very easy to mess up. However, uBlue actually enables one to engage relatively easily with those harder to modify parts. And the amount of configurability it allows should definitely put anyone to shame that continues to posit that “immutable is inflexible”.

Not sure which one you’re talking about, but there are multiple copr repos that have very up to date packages.

I likely would have encountered this as I try to take the approach of research, then do.

Props to you mate 👏 ! That’s the way 😉 .

This is the first time I’ve ever posted for Linux help/or guidance.

Thankfully the community is very helpful in general, so you’re in good company :blush: !

Searching forums has historically lead me to an answer close enough to resolve my not-so unique issue.

Yeah lol, we’ve all been there 🤣 .

A lot of negatives seem to come up around Oracle and Canonical being involved with SUSE and Ubuntu

Fedora also has connections to Red Hat, so yeah 😅. I didn’t even know Oracle had anything going with SUSE before the recent ‘alliance’ of sorts in reaction to what Red Hat has done recently. Was that what you meant or has SUSE being working with Oracle for a longer time?

EDIT: I think what I’m wanting is something that gets new features more frequently, yet doesn’t become unstable. I feel drawn to the desktop eye-candy that I see getting featured with KDE desktops. I seem to believe I’m missing out on something, but can’t directly state what. Ultimately, I think I simply want to move to a more core/upstream version of Linux so that I get new functionality faster. I’m trying to find what I desperately need but never knew it existed.

Thank you OP for clarifying! Distros that are closer to upstream, but still accomplish ‘stability’ (often through hand-holding) and on which KDE has great support would be (in alphabetical order):

• Fedora’s KDE Spin: Has a semiannual point release cycle, but still continues to get updates to kernel etc almost as soon as they come. Therefore it’s sometimes referred to as semi-rolling release. In the middle out of these three in regards to how close it is to upstream.
• openSUSE Tumbleweed: Sets out to be the stable rolling release; thus receiving a constant stream of updates without foregoing stability. Perhaps surprisingly to some, it accomplishes this rather gracefully. Being on a rolling release enables it be the closest to upstream between these three.
• Ubuntu (their KDE flavour is more popularly known as Kubuntu): Also has a semiannual point release cycle, but mostly foregoes updates besides security-related ones and the ones received for snaps. It is the furthest away from upstream out of these three.

A lot more can be said concerning the differences between these three distros. However, working with them either from inside a VM or through a Live USB is probably a lot more valuable. All three are great picks, so you should be fine regardless.

Please feel free to inquire if you so desire!

You can even install KDE on Mint, and configure it however you want.

Personally, I’d advice against this as KDE is not supported on Linux Mint. While this doesn’t have to mean much, it does mean a lack of polish and sophistication you might expect on Kubuntu or Fedora’s KDE Spin or openSUSE (on which KDE is the default DE). This might result in some edge-case bugs and other mishaps that might trample your experience; thus giving you the wrong idea about KDE. Instead; consider booting into a Live USB of any distro that comes with KDE by default.

I’m a simple man; I like to use GNOME so any terminal that feels at home on GNOME suits me. Currently, I’ve been in a phase in which I primarily use GNOME Console because of how GNOME Terminal doesn’t play nice with tiling managers. Though Black Box is definitely tempting me.

Somehow it looks veiny, black and kinda nsfw…

First of all: thank you! The necessary info is there and it’s written splendid. I think it or a future iteration should definitely be considered as a sticky post in the long run.

A few nitpicks which you may or may not agree with:

• In the section in which you talk about update frequency, you end the paragraph with something along the lines of “new and stable”. While this is correct technically, you should define what you mean with ‘stable’ here. Because there exist two (somewhat related) definitions for ‘stable’:

  1. “(Certain) resistance to breaking” - which is used in the context of “stable rolling release” when one refers to something like openSUSE Tumbleweed. This definition does not necessarily oppose new.

  2. “Release model in which packages are frozen over a long(er) period of time and primarily only continue to receive security updates” - which is e.g. used in the name of the “Debian Stable” distro. This definition does oppose new.

• In the section about desktop environments you mentioned something along the lines that Fedora defaults to GNOME. This applies only to their Workstation and Silverblue distros. For which both other “Spins” exist, which happens to be the recommended method of installing another desktop environment on Fedora; similar to how “Flavors” work for something like Ubuntu. While one can technically install it like how you’ve mentioned it, I wouldn’t recommend it to a newer user.

Get your priorities straight. Picking a distro to stick with becomes a lot easier that way.

To give an example of how I dealt with this myself in the past.

Number 1 priority for me was and still is security. I’m willing to give up performance and convenience for the sake of security. A shortlist of distros that in some capacity suffice: Fedora, openSUSE, Gentoo, Arch(/Artix), Alpine, Void, Spectrum OS, Qubes OS, Kicksecure, Whonix, Tails.

However…:

• Whonix and Tails fall off for not being a daily driver.
• My laptop can’t handle Qubes OS.
• Spectrum OS is still WIP.
• Gentoo, Void and Arch(/Artix) require the user to set it all up themselves, but as a newbie I needed a distro that would do the heavy-lifting for me.
• Alpine seemed cool, but I wasn’t able to deal with issues related to musl.

So Fedora, Kicksecure and openSUSE remain. While Kicksecure (arguably) has superior defaults (when it comes to security), it is still a relatively small project compared to juggernauts like Fedora and openSUSE, so I was inclined to dismiss it unless Fedora and openSUSE weren’t able to keep up. Then I learned about how both Fedora and openSUSE had so-called immutable variants, so I got interested in those and what they had to offer. And even though they were still a bit crude, unpolished and kinda finicky to work with; the promise and potential was clearly there. I was especially amused by how Fedora’s rpm-ostree enabled one to forego unknown states, bitrot, configuration drift etc and was a very serious step-up compared to all the other options. Soon after I realized that I had found the distro and the rest is history… Since, I’ve obviously found other distros that had some interesting things going on, however none of them (besides the promise of Vanilla OS’ 2.0) has been able to deliver in terms of security and reproducibility. So for me it’s still rather clear cut.

In your case, to me at least, it seems you’re inherently attracted towards stable distros (like Debian) but lust after rolling release due to the newer packages they offer. So in your case I’d actually recommend the following:

• Main system: Debian(/Devuan)
• Install Nix and access Nix packages through there.
• Finally, install packages you still need but can’t find elsewhere through the AUR but within a container. I would recommend Distrobox as it makes this go rather easy and painless.