Isn’t this almost the inverse argument to the android vs iPhone thing? Like the iPhone being (traditionally) more expensive for the “same technology from 5 years ago”? I don’t really have a horse in this race, I’m a firm believer in use what you like and is easiest/best for you. But I do feel compelled to call this one out a bit.

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.

My friends and I all LOVED the pick-up nature of SG1. We’re all adults with busy lives, so hopping into a ~5 minute casual match was just so easy. And the casual nature made it feel like we could have success without “grinding” the game. I guess that is explicitly not the intent of SG2.

The shift from “we’re making a fun and relatively casual arena shooter with a neat gimmick and extremely rewarding fundamentals” to “we’re making a generic e sport shooter” was swift and, frankly, uncalled for.

Even with nvme drives which supposedly “don’t need” to use BFQ, I STILL always swap it since it maintains responsiveness across the system during heavy IO loads. I used to have similar full system freezes when downloading steam games which notoriously overload your IO in Linux. BFQ was the solution every single time.

Edit Try following the instructions detailed in this post to add a systemd rule to set the scheduler: https://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler

The second answer that shows an actual rules.d file example has always worked for me. If using nvme or old school spinning rust you’ll need to change it up a bit. Instead of “noop” set it to “BFQ”.

Try swapping to BFQ io scheduler and see if that makes a difference.

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.

Ooooh okay. Yeah, I avoided the playstore version. I’m pretty sure I had read somewhere early on that the Playstore version would lack features or otherwise be behind in some ways due to complying with certain Google specific requirements to be allowed on the storefront. Kind of like KDEConnect.

I’ve got it opening YouTube links by default… At least from within other apps. In Firefox I can also hit “open in app” and it pops right up. Casting works too.

I’m going to assume it’s not Universal Blue… But parts of your description reminded me of it.

I have personal experience with BTRFS and Windows. And that experience is that it’s roughly as stable/complete as NTFS is for Linux. 6 of one and a half dozen the other. I can’t recommend either situation for guaranteed stability long term between systems if one really needs to swap between the OS’s frequently while accessing all the same files.

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.

I can’t even fathom how many layers deep we are in sarcasm.

Oh I never said I didn’t like anything. Chocolate and vanilla are both great. And they certainly must compliment the soup.