To me, Endless OS seems to be the best fit for you; install it once and you never ever have to give it a second glance for troubleshooting or whatsoever. It achieves this through using “a read-only root file system managed by OSTree with apps installed using Flatpak.”. This translates to:

• The most important system-related files being protected from change by yourself and others.
• Ensurance that your base installation is exactly the same as the one tested and used by its developers. And thus an (in-)direct quality control and maintenance by the very people that work on it.
• As the base system is not changing beyond what is provided by the devs, installation of applications is relegated to flatpaks (see Flathub for the App Store).
  • Flatpak is a packaging format that doesn’t interact with the base system to install software; think of it like how applications are installed on your phone. With this, you can still install software you need without compromising changes to the base system.

Been trying for days to install Private Internet Access’s client in a custom Bazzite image, but it’s slow-going to troubleshoot each failure to build, and I feel like I’m fighting GitHub more than the install script.

Have you contacted the Discord servers for Bazzite/uBlue and/or BlueBuild in hopes of resolving the issue?

They’re cool and very much willing to help out. They solved my issues a bunch of times with my own custom image. Perhaps, they are even capable of offering a solution to resolve the problem without requiring a custom image.

Wish ya good luck!

Thank you so much for correcting me! I’ll edit my earlier post to reflect this! Your work on Bazzite is much appreciated! Thank you!

Thanks for the clarification! We actually run very similar systems; I’m on the hardened Bluefin-dx image as per secureblue.

Regarding Steam, Bazzite -one of Bluefin’s uBlue siblings- actually switched over to RPM Fusion’s Steam due to issues with the Flatpak. EDIT: The former is false. The Deck images have always been on RPM Steam. Only the Desktop images moved to RPM Steam (from Distrobox-Arch) for support consistency reasons. Appreciation goes out to quarterlife@lemmy.sdf.org for correcting me!

I don’t know what exactly is the way to go for you. But I can suggest the following possibilities (from own experience):

• Install RPM Fusion’s Steam through layering with rpm-ostree.
• Use Steam bundled with Bazzite- Arch; this is what Bazzite used to use in the past.
• Or (very unconventional) use the Steam bundled with Conty.

Is this on one of Fedora’s images or on one of uBlue’s images? Regardless, could you specify what exactly we’re dealing with?

Thanks for clarifying!

That’s pretty strong language

I agree. But in this case it was 100% justified as OP just (hopefully reversibly) destroyed their installation.

and what I was responding to.

Thanks for properly nuancing my stance. Though, perhaps consider to do so right away next time 😜.

Perhaps you were being hyperbolic.

It was deliberate. But I wouldn’t refer to it as hyperbolic. Perhaps more in the style of an elder sibling scolding their younger sibling to be better next time 😉. Apologies if I missed the mark, though.

😂. Thanks for the clarification!

Thank you for giving me the opportunity for a refresh 😛. And thank you for the very civilized conversation. I wish you a great day!

Yes. Not everything I have is installed through the Google store.

I understand from this, that it is implied, that the majority of what you have installed, has been done through the Google store though. By extension, I assume that -by default- you entrust installing software to the Google store. Hence, if all of the above is correct, then you actually don’t commit to ‘the Windows-way’ by default; but only by exception. Which is exactly my point.

But you’re acting like one needs to have some expert skills to install things outside of the package manager.

I feel you’re reading too much into it. In my first comment, I didn’t even mention package managers. In the second comment, I only wrote -and I quote- “Those should first and foremost be consulted. And for 99% of the cases; this is the intended, supposed and supported way of installing said software.”. I don’t see where expert skills are implied if one chooses to go outside of it. Please feel free to help me understand where I did.

It’s generally preferred for a number of reasons but it’s not bad “per se” to install something outside of it.

I never implied otherwise.

On your phone, do you search the software you want to install through your browser? After which, do you download the install script and try to run it?

No, of course not. Instead, you pay a visit to the accompanied software center. Searching, installing and upgrading all occur through that.

Similarly, on Linux, your chosen distro comes with a (or perhaps multiple) package manager(s) and a software center. Those should first and foremost be consulted. And for 99% of the cases; this is the intended, supposed and supported way of installing said software.

This should suffice for the sake of brevity. If you’ve still got questions, please feel free to ask them.

Sure, but even in those “few cases” Testing will get them soon.

Didn’t I allude to that with:

"it doesn’t receive the security backports like Stable does nor does it receive them as soon as Unstable/Sid does.

Though I do notice that the above sentence contains an error that is perhaps misleading. By definition, Unstable/Sid doesn’t receive security backports. Instead, the updates related to security are (usually) first received in Unstable/Sid. So, the above sentence tried to portray the following picture related to security:

Unstable/Sid ~ Stable >> Testing

I did read at some point that Testing may receive security updates later than stable, might be in those cases in which backports come straight from unstable.

That’s basically the point I’ve been making 😉.

I think the only remaining point of contention is the degree by which Stable does receive security backports right after Unstable/Sid does while Testing only receives it later.

Honestly, I don’t know the specifics. But Debian Testing’s wiki entry notes security concerns multiple times. And it’s all related to the fact that they don’t receive the security backports as soon as Stable receives them. The explanation related to security updates concerning the three distinct branches is covered in even more detail over here.

Basically, after I’ve read all of that, it’s clear as day that security is not a priority on Testing. And while band-aid solutions do exist, it’s simply not designed to be secure.

Found on the same page you cited from (even same paragraph):

“Backports are packages taken from the next Debian release (called “testing”), adjusted and recompiled for usage on Debian stable. Because the package is also present in the next Debian release, you can easily upgrade your stable+backports system once the next Debian release comes out. (In a few cases, usually for security updates, backports are also created from the Debian unstable distribution.)”

Thanks for the reply!

Devuan Ceres probably makes the most sense indeed. Wish ya good luck with it!

FWIW, while it defaults to runit instead, I still felt the need to mention Void Linux.

1, directly from the website Link

I hope you’ve now understood why -on Linux- you should never try to install stuff like how you were used to on Windows. Unless, you 100% know what you’re doing.

Read this for the most complete and comprehensive answer on the matter.

TL;DR: Like Fedora Atomic, it utilizes OCI images for its immutability. However, while Fedora Atomic combines this with libostree/OSTree for git-like management of your system, Vanilla OS (instead) keeps it relatively simple with just A/B partioning; which indeed is somewhat reminiscent to what’s found on Android.

Am upgrading from thinkpad to framework 16 with amd. Looking for distro reccommendations.

I would start looking at what’s supported to begin with.

I did the whole distro chooser quiz but didnt help much.

FYI, it isn’t as helpful as you would hope and hasn’t been updated in quite a while. Don’t be too much bothered with the result. But thanks for sharing some tidbits from the quiz as it helps the community to better help you!

avoid systemd

Are you sure you want this?

stable

Does this refer to unchanging (for long periods of time except for security updates)? Or, instead, for being less inclined to break after an update?

Is testing/unstable got wayland?

I don’t recommend going for (Debian’s/Devuan’s) testing (branch) as it targets a peculiar niche that I fail to understand; e.g. it doesn’t receive the security backports like Stable does nor does it receive them as soon as Unstable/Sid does. Unstable/Sid could work, but I would definitely setup (GRUB-)Btrfs + Timeshift/Snapper to retain my sanity.

are they reliable enough?

Depends on how reliable you want them to be. OOTB, their reliability definitely ain’t great, though.

If so what do I go with.

Consider answering all questions found in this comment and we’ll be better equipped to help you out with this.

Also hows the hardware comparability with framework i assume it wont be too bad to get set up.

Overall, it’s pretty good; epecially so on the supported distros.

Btw, you strike me as a (relatively) new user that doesn’t seem to have a good understanding on Linux yet. Is this correct?

Thank you for sharing your experiences!

May I ask you what made you pursue an Arch installation in the first place?

Can I run KDE and Gnome on bazzite?

Both GNOME and KDE Plasma are supported on Bazzite.

How can I install and manage multiple images?

Multiple images can only coexist as follows:

• Dual-boot
• Rebase to second image -> pin second image with sudo ostree admin pin <insert digit> -> rebase back to original image. From now on, you can access this second image from GRUB. It’s recommended to designate a different user to the second image; and only access it through that. While what has been just described technically works, and you could even keep the second image up to date with a super cumbersome upgrade path, managing a system like this is not supported and could lead to unforeseen circumstances. Though, it is valid to pin your original image -> test another image through rebasing (and a new designated user) -> rollback to original image. Pinning the original image is not necessary, but I like to play safe. Note that rpm-ostree reset might be needed sometimes for rebasing.

Now I suspect that perhaps the game freeze wouldn’t happen with Gnome either. So I want to have both on bazzite, but can’t figure it out.

So, IIUC, you’re just interested to know if this problem persists on GNOME or not. So, consider the following:

• Pin your current deployment with sudo ostree admin pin 0.
• Create a new user, but don’t use it yet.
• Rebase to Bazzite’s GNOME image.
• Reboot
• Enter through the new user (or create a new one).
• Test out whatever you want.
• Rollback through rpm-ostree rollback
• Reboot
• Continue using your original user.

Thank you for the clarifications!

Regarding what you mentioned on Debian; ultimately, you’re a lot more experienced than I am with it. But, IIUC, Debian 12 should have done a great job at easing (new) users into its ecosystem. Not sure if it’s sufficient though.

First of all, thank you for this! This effort is very much appreciated and will definitely make it easier to parse through Linux; especially for beginners.

Having said that, some personal nitpicks of mine:

• I absolutely love Fedora. But if it’s named first on your list of beginner distros (presumably due to alphabetical ordering), then it better be easy as hell and work as expected OOTB. Unfortunately, that ain’t the case. Hence, at least mentioning the Howto page of RPM Fusion would have been sensible to combat issues users might experience otherwise.
• I’m fine with the inclusion of openSUSE Aeon, but openSUSE Kalpa is literally in Alpha. Therefore, it’s too early to be recommended.
• I’m personally not very bothered with Fedora Workstation on the list of distros geared towards beginners, while Debian is found on the list of power-user distros that beginners should avoid instead. (I’m a die hard Fedora fanboy anyways.) However, I am curious to your reasoning/justification.
• Alpine Linux was originally envisioned as an embedded-first distribution. Therefore, most of its design choices revolve around that; small, secure, simple et cetera. The way that you describe/depict Alpine Linux, is more in line with how I would for (what I’d refer to as) demonstrative distros like Artix and Devuan.