My old Nexus 5 was my first smartphone and probably still holds the top spot for price, performance and usability (at the time) of any phone I've owned. My current Pixel 6 is somewhat close- but there was just something SO solid and magical about the old Nexus 5.

AMD with ray tracing isn't great. Not as bad as it used to be, but pretty lackluster overall compared to Nvidia (and to a lesser extent Intel's GPU offerings). Linux ray tracing via Proton is also not as optimized at present, so that can take something "passable" in windows and make it unplayable on an AMD card in Linux. If you get something overkill for the resolution you're playing at that can somewhat make up the difference.

If you're doing 1080p the 6600 is pretty solid. Or 7600, really. It CAN do higher resolutions, but then you'd need to start doing FSR scaling or drop settings to keep things smooth/consistent.

You seem to be arguing it's all about the implementation of the phoning home itself- I'm arguing that running the entire executable/binary through a virtual environment likely has far more drastic performance implications than a phone home, regardless of frequency. It probably IS mostly an implementation problem, but I'm more inclined to believe that the implementation of the Denuvo virtual environment is at fault, not just a server call and response delay. **EDIT: Apologies, forgot to include a link- see HERE. Looks like a substantial/measurable difference. Not massive, as measured here, but certainly enough that if your hardware is just barely able to run a game it could easily make or break the entire experience.

Regarding performance implications: I believe Denuvo DRM runs through a type of virtual machine environment. While this theoretically should be relatively transparent, there are definitely documented instances of it negatively impacting performance, sometimes severely. Maybe the VM it runs in is just bad with certain instructions/calls on certain CPU's or api's, hard to tell for sure. But it's not nothing.

Self hosting Mealie could be a great option to take things into your own hands.

Software-wise, it seems that the relatively fast adoption of flatpaks and other containerized formats somewhat solves the typical dependency hell that was so common in Linux just a few years back (and to some extent still is an issue today depending on your distro and use case). The hardware support side is a little harder. That's going to be up to vendors to play nice with the Kernel team and/or introduce reasonable userland software that doesn't break the golden rule. Until Linux gets more market share the latter isn't likely to happen. A nice side benefit of the emergence of immutable and/or atomic distros is that users can play around and try things with much lower risk of bricking their systems, so I'd also consider that a step closer in the "it just works" department.

Anyone who ritualistically buys Dell. I believe Intel is on the record as having called Dell "the best friend money can buy."

Are you on Gnome, KDE, or some other desktop environment? I know KDE Wayland and Nvidia do NOT play nice (presently).

Are you running it through Lutris? Steam with Proton? That error seems decidedly like a Wine specific problem, which Proton should have ironed out at this stage for this particular game.

*Unless you're trying to play on hardware with incomplete Vulkan support. Then it's a hardware support problem that is unlikely to be fixed in a reasonable timeframe.

Weird! I'm running Bazzite kde (so fedora based, like Nobara but with different tweaks and it's atomic), and gamescope gives me zero problems. Might be some weird combination of software versions between gamescope and kde in your system. Or just a general kde config problem. I love kde, but all that customization can absolutely come at the price of stability at times.

Might be worth trying gamescope on another known working game too. Would help narrow down if it's gamescope itself or the game you're trying to use it on.

Interesting. I haven't had any issues with gamescope for a long time... Back when it was new I definitely had issues running things with it... But it's been a long time since that's been the case. I can recommend running steam from a terminal and viewing the output after trying to run the game with gamescope. It might point you in the right direction.

Should be something like - "gamescope -W 1920 -H 1080 -f %command%" I will also note that mine tends to crash/not launch if I don't put Mangohud arguments BEFORE gamescope. The w and h arguments are just width and height resolution, so set those to match your monitor. The "-f" is for full screen.

In my experience this is almost always the compositor not properly syncing display frames with the game render frames. The best solution I've personally found is to run the offending game through game scope. It worked for Fallout 4 on my rx 7600xt gpu when I went to lock the fps to 60 (to avoid physics bugs, stupid Bethesda). Without game scope locking the frame rate caused horrendous stuttering despite solid fps.

Maybe not too helpful, but could point you in the right direction: you used to be able to use "gksudo" to get the graphical popup requesting your password in lieu of sudo which would only ask for a password in terminal. I believe gksudo is deprecated/non-existent at this point but there's got to be an alternative out there. Best of luck!