Sorry I didn’t get back sooner, but I made some progress.

What do you mean with “work in progress”?

Their words (second video, I think), and more in reference to how they are still working out how they haven’t yet covered all of the use cases (like maybe my needs can’t currently be met by rpm-ostree or bootc). rpm-ostree has functional limitations, and bootc is still being developed. Obviously, both are still useable and useful, and Universal Blue has been using them for quite a while. I may have been reading too much into it with the “depreciation” comment.

So, did you try the following methods when installing the .run file? If so, how did it go?

It can’t work on its own. Running with sh or making it executable runs the script, but it fails when it tries to write its icon and .desktop entry to /usr (it also doesn’t take an --appimage-extract argument). You can use sudo rpm-ostree usroverlay to create a temporary FS overlay for /usr, but it’s wiped on the next boot. Still, that allowed the installation to complete.

I discovered that it’s installing all of the necessary components to /opt, and they remain functional. I was able to manually run the daemon script required and get a WireGuard tunnel established in the client.

Now, I’m trying to get a .service module to work so it can run automatically as root on a reboot with systemd. So far, it’s giving me a 126 exit code, so I still haven’t figured out how to escalate its privileges automatically, but this is the most progress I’ve made to date.

Correct, and if you just type ujust, you’ll get a list of all the “recipes” you can apply with that command (that’s what they’re called).

Alternatively, OP can contact the maintainers and see if they can add the necessary recipe. They’re really nice and responsive—even offered to add a semi-common print driver to the image for another user.

But wait. One update failed. Why? Ah, the rescue partition is too small… THE ONE THAT DUMB SON-OF-BITCH CREATED ON ITS OWN AS PART OF THE INSTALL!

Shit, I forgot about this bug! Such a weird design choice to make the installer fuck up its own partitions.

I feel like it’s more common in indie games to get post-launch improvements like FSR. Still, seems like it’s becoming more common, especially in games that are graphically intensive.

I don’t like the fact that even if you have a Pro or Enterprise license, some amount of telemetry is still being sent to MS for any number of nebulous reasons.

At least with bigger names like Fedora et al, they give you the option up front to opt-in, and you can have a reasonable amount of trust that they won’t do it in secret.

The Microsoft support forums are pitifully hilarious, too.

“Hi, I need help with N. I’ve tried X, Y, and, Z.”

“Hello, sorry to hear that you’re having trouble with N. Have you tried X, Y, or Z?”

“Yes.”

“I’m sorry to hear that it’s still not working. Please refer to this thread, and feel free to contact Microsoft Support with any future questions. Have a nice day.”

“But my problem still isn’t solved. Hello?”

You know, in case anyone was under the illusion that these ghouls were content to just fuck the US.

Authoritarian ultra-capitalists gonna make that money if it kills us all.

I wasn’t that into computers at that point in my life, but it was definitely a time where “computers” was a hobby, in the same way that restoring old motorcycles was/is a hobby. Sure, you might take it out for a spin every now and again, but a lot more time is spent tinkering than simply using.

I’m constantly amazed by how much better the end-user experience is today, even just from 10 years ago. The installers are better, the pre-configured software and settings are more thoughtfully chosen, and now we’re at the beginnings of meaningful Linux gaming for non-hobbyists.

We truly stand upon the shoulders of giants, and I look forward to the future.

MX Linux is the sister project, and I think it also can work on very old hardware.

It had problems with my multi monitor setup, but it booted so ridiculously fast, even on a live ISO. Certainly worth a look.

And this is why I think Valve was very shrewd when it came to deciding what hardware to use. Not only is AMD better supported, but it feels like every update just keeps improving everything.

Doesn’t matter if it’s actually better on paper (I don’t know if it is or isn’t), because it feels like the value only improves.

It may work to swap drives, but you should definitely minimize physical swapping if possible. Pick where the drives will live, then try to stick with that (or be ready to do some troubleshooting). Create a Linux install media for your chosen distro, put the empty drive in the laptop, and boot from the install media. Most distros come with a graphical installer, so you should be able to navigate from there.

Also, for the best experience, the drive inside the laptop should be your daily driver, anyway. USB-C is great, but you’ll have the best I/O with the slot on the mainboard, which is both physically closer to the CPU and likely uses NVMe. If you plan on making Linux your daily driver, that should be the drive in the laptop.

Lastly, try booting from a live ISO where you can give it a test run before you install. Might identify any glaringly obvious issues with your hardware before you go through the trouble, though not all distros have live media.

Good luck, OP! I’m right there with you, making the switch to Linux, though I’m just going to relegate Windows to a VM.

The complaining will continue until post quality improves.

I bought it specifically because it directly and indirectly supports the Linux community at large. I’m now working on moving away from Windows for gaming, because they’ve made it possible with what they’ve done with tools like Proton and gamescope.

Okay, I appreciate the links. I’ve had a chance to go over both, and I think I get the gist:

• rpm-ostree is a work in progress, and it will be depreciated and replaced with bootc + dnf

However, I’m still struggling to understand how it all works together. For example, I have a VPN client that is installed via a .run script, so it doesn’t work with ostree. If I wanted to apply this software to my system, I’d have to create a bootable container, then rebase to that. But my goal isn’t to create a new image, just to apply transient packages to the base Bazzite image, so my remaining questions are these (and it’s fine if you don’t know):

If I made a bootable container(file), would that derived image fall out of sync with the parent Bazzite project? Would I have to manually build a new container and rebase each time I wanted to check for updates? I feel like I’m on the cusp of seeing the big picture, but I’m not quite getting it, and maybe that’s because I haven’t worked at all with services like Podman and Docker.

I don’t know why this never occurred to me. This is what I’m going to do from now on.

Not Brazzite, “Bazzite.” It’s a mineral, and its naming proximity to an adult website is entirely coincidental (and I would hazard a guess that the mineral was named first).

Honestly, I’m not that concerned with Bazzite being newer, because it’s based on Fedora CoreOS. It utilizes rpm-ostree to manage system upgrades, so for any bad updates, you just rollback to any previous deployments (and you can pin specific ones so you are guaranteed a stable rollback point). Additionally, you can rebase at any time, so you can swap out the system layer for another ostree-based image without touching any of your files in /etc, /var, and /home.

Pop!_OS is a great choice, too, but the biggest problem facing the family of Universal Blue distros isn’t notoriety, it’s the fact that Fedora Atomics in general are still relatively new. The examples are still being written, and people are getting used to new tooling.

But if you don’t need specific customizations like me, and all your software can be found as appimages or flatpaks (or is already installed), Aurora, Bluefin, and Bazzite are all rock-solid choices that will “just work.”

That’s a good idea.

There was a post about that exact issue not that long ago, basically, you have to do some networking trickery to get some printers to work.

I agree that there’s a big learning curve, though it’s a nice option if everything you need can be found as a flatpak or appimage.

They could get RasPis below 4th gen running outdated software, I guess. I think I read elsewhere that Debian already had a patch out some time ago, so that number is also likely diminishingly small.

Stuff you do and don’t document or don’t force yourself to recognize comes back to bite you years later when you can’t use the normal tooling in order to deal with it.

And it’s this right here that forces me to really consider if Bazzite is right for me in this case (and why I didn’t just immediately go with the easier rpm-ostree option). Podman is kind of a necessary tool, at least currently, and if your use case falls outside flatpaks, rpm-ostree, and appimages, it’s Podman or bust (and I currently have an app like that, which I haven’t yet figured out).

I appreciate your experienced advice. I have probably a total five years of experience, so I would be foolish not to consider to the long-timers offering similar advice in these comments.