The last commit on that repository was 7 years ago, seems unmaintained. I wouldn’t recommend using this.

If someone decides to use it anyway, don’t use their udev rules. Just install steam-devices or game-devices-udev instead. If you don’t have those packages available in your distro, all rules can be found in the git repo https://codeberg.org/fabiscafe/game-devices-udev

SELinux in Podman works pretty much the same way it works on Docker, so if you are having problems with Podman, you should also be having problems with Docker, so I don’t see how that’s impeding your migration. You need to be more specific about the issues you’re having to get a good answer.

The post by Chris Smart you linked on your comment below is a good start, but everything there also applies to Docker, so if you still didn’t know those basics, you shouldn’t be able to use Docker on Fedora either.

About your question of how to set it up, use-case is an important consideration, there is no generic answer that covers all use-cases. I’ve even found out that for some use-cases (like ad-hoc containers), disabling SELinux within the container (with --security-opt=label=disable) seems to be the most secure option. That’s what I’ve done in contr (see this commit message). I’ve been meaning to blog about that, but never did because I’m in the process of migrating my blog but too lazy to finish it.

I’ve put a lot of links about SELinux in containers in this issue.

Although that link exists, that’s not what is being used by default. [[ is a shell builtin in ash/busybox, so that takes precedence.

On Alpine:

❯ which [[
/usr/bin/[[

❯ command -V [[
[[ is a shell builtin

gog galaxy through wine is not an option…

That’s the primary way I install and play GOG games. It’s easy to set up using Bottles. Galaxy used to run horribly on Wine, but it has improved recently. I help maintain the Galaxy installer in Bottles, and earlier this year we increased its grade from silver to gold, meaning all functions work with minimal glitches now.

It isn’t perfect yet, it lags for about a minute right after launch, and I’d recommend going into settings and disabling the “Cloud saves” and “Overlay” features as these can cause crashes sometimes. Other than that, everything works well and performance is good.

If you have read it, you might have noticed that the theme of the article is a company called Chainguard. Enterprises can pay them and get a secure software supply chain all the way down to the container image. More than that, their container distro is actually free and open-source, anyone can use it for free, it’s a one line change in your build script to go from Alpine to Wolfi. Enterprises can also buy a secure OS for bare-metal from Red Hat, SUSE, etc…

This article lacks focus and mixes unrelated security concepts in questionable ways. It ends like just an ad for Wolfi. Don’t get me wrong, Wolfi is neat, it’s probably deserving of being talked up. But it doesn’t solve the supply-chain issues pointed out by the article (it doesn’t even try). Supply-chain attacks are currently not a major issue in Linux distributions, and enterprises are already tackling the issue of provenance elsewhere, and the article itself notes that. Dependency management for enterprise software is NOT the responsibility of Linux distros. So what is the point of the article? To me, this article is security mumble jumbo.

Thanks for the report. This issue was supposed to have been fixed in the Flatpak package, but you just brought to my attention that part of the fix was accidentally reverted. I’m sending a new PR right now to try to fix the issue again.

Here’s the update, I’ve got the USB-C/HDMI adapter today. Connected it to the port that connects directly to the dGPU and even during boot Plymouth was already outputting video to the TV. I also tested hot-plugging and it just works as expected.

Now for the problems, I ran benchmarks and the performance was as expected, but frame delivery didn’t look as good as when using the HDMI port on this device. It doesn’t show on the performance metrics, but looking at the screen, the frametimes looked off, stuttering. I’m still figuring out where the issue might be to report it to upstream. EDIT: For people reading this in the future, I’ve found the issue to be in GNOME’s compositor, Mutter: https://gitlab.gnome.org/GNOME/mutter/-/issues/3070#note_1865351

I hear you, I have a Legion laptop with a GTX 1060 mobile and I keep the dGPU as primary all the time because I just can’t be bothered by NVIDIA optimus anymore. That’s the reason I decided to upgrade to AMD, even though the performance of the 1060 was still appropriate for me and I wouldn’t have upgraded yet otherwise.

I don’t have any issues with the Strix G15 on Fedora Silverblue. Talking to other owners of the same model and also other Asus AMD laptops on Reddit, I didn’t hear any complaints about that.

The G15 has the HDMI port connected to the iGPU, and the USB-C (DisplayPort Alt Mode) connected directly to the dGPU. I’ve only used HDMI to connect to a TV, I haven’t tested the USB-C output because I don’t have a monitor with DisplayPort. So I can’t really answer your question.

Tell you what, I’ve just ordered a USB-C to HDMI adapter, as soon as it arrives I’ll test the output that’s connected directly to the dGPU and update you on that. I’d bet on it being plug-and-play, but we’ll see. 😉

You shouldn’t generalize your bad experience with NVIDIA’s proprietary driver to Mesa. Graphics device switching just works on Mesa, hence laptops with an AMD dGPU are great on Linux.

Typing this from a 2021 Asus ROG Strix G15 Advantage Edition