Hacker News Reader

> ...drag-and-drop into Electron apps like Discord randomly fails, adding a new widget to the panel and suddenly it’s invisible, notifications appearing floating in the middle of the screen, removing an audio output (like unplugging headphones) seems to cause it to randomly choose an alternative, brightness on my monitor randomly shifts even after turning off DCC, GNOME apps have wonky themes, GNOME apps can’t detect light/dark mode so they just pick one… I could go on.

Hey, you can't possibly be having these problems! You're using a RedHat-derived distro! That means it uses Wayland! And the Wayland people have been telling us all for years that Wayland is good for daily use for everyone, and that it should be the default everywhere!

(Do note that the above is bitter, bitter sarcasm. I'm so, so disappointed by how the Wayland folks tend to use political pressure (rather than plain declarations of both capabilities and shortcomings) to muster up general support for their project.)

> ...but many have weird bugs like crashing when you Alt-Tab out.

Would it be easy for you to compile a list of like five or ten games that do this? I'm curious to see if I can reproduce this on my Steam-on-xorg-on-Gentoo-Linux machine with an AMD graphics card.

I don't doubt your report, not even a little bit, but -personally- I've found window management on Linux to be light-years better than on Windows. I can put nearly every game I've tried in my huge-ass Steam library on fullscreen on another virtual desktop, flip over to some other desktop (or window) to check something, and flip right back to find the video game still fullscreen and still running happy as a clam. [0] (To say nothing of the total lack of Windows-typical jankiness when changing the screen resolution on an "Exclusive Fullscreen" game.)

Whereas on Windows, it's kinda a crapshoot regarding both what state your desktop will be in when you Alt+Tab out of a fullscreen game and what state that game will be in when you Alt+Tab back. And if that game is "Exclusive Fullscreen" and is not running at your desktop's resolution, all the windows on your secondary monitor are probably going to be rearranged when the game starts, and will definitely be rearranged when you Alt+Tab out and maybe then again when you Alt+Tab back in.

[0] Two very notable exceptions to this are Red Dead Redemption 2 (it notices that its no longer the foreground window and "helpfully" makes itself windowed) and the Linux version of Dead Cells (it "helpfully" minimizes itself when it's no longer the foreground window.).

I run modded Skyrim (SE) via Steam on Bazzite, and it works fine. I just installed Vortex inside the same Proton prefix as Skyrim, installed all my mods via Vortex (and made sure there weren't any conflicts) and it all worked fine. I think I might've had to install .NET as well to get Vortex going, it's been a while so I don't recall, but there should be some update guide somewhere.

RE Anti-cheat, it's not ALL of them, it's only kernel-based ones. For eg, BattlEye, EAC, VAC, and nProtect Gameguard all work just fine, but of course, the game studio will need to enable that support. Arc Raiders, Marvel Rivals, Fall Guys etc all use anticheat and they work fine.

RE KDE, I haven't experienced most of those issues. I don't use Konsole (Ghostty is far better anyways). As for Discord, Equibop is a far better client compared to official.

RE GNOME, unfortunately GNOME and KDE have never really gotten along, personally I avoid GNOME/GTK apps are far as possible.

> 90% of games work fine, but many have weird bugs like crashing when you Alt-Tab out.

This isn't particularly linux-y of an issue. I've had the same sort of behavior in numerous games on Windows, up to and including crashing the graphics driver when alt-tabing out of a full screen game. Seems to be something gamedevs are not commonly testing, and perhaps difficult to defend against when a game is directly interacting with the GPU.

Yeah I distinctly remember a time in my life where most of my Source Engine games would explode if I alt-tabbed in Windows Vista.

> Seems to be something gamedevs are not commonly testing, and perhaps difficult to defend against when a game is directly interacting with the GPU.

I can guarantee you any gamedev worth his salt will have used alt-tab at some point in the game's development on windows. It's an incredibly common hotkey to use, and the devs very likely have multiple ides, notepads, image editing software running concurrently. You seem to be trying really hard.

> when a game is directly interacting with the GPU.

Most devs are using cross platform graphics APIs. OpenGL/DirectX/Vulkan. Alt-tab breaking is likely an OS issue.

> I can guarantee you any gamedev worth his salt will have used alt-tab at some point in the game's development on windows.

Not exactly a repeatable testing framework, that.

> You seem to be trying really hard.

I almost strained a typing finger! /s lol

> Most devs are using cross platform graphics APIs. OpenGL/DirectX/Vulkan. Alt-tab breaking is likely an OS issue.

All the OSes seem to suffer from it similarly. More likely an issue that even the cross-platform graphics APIs rely heavily on shared memory buffers and most games depend on code written in languages which aren't strictly memory safe. Sharing a memory buffer between CPU and GPU (or even just multiple CPU cores) is quite difficult to do safely under all possible circumstances without proper language support.

Yea I don't know how you can consider something as not 'tested' without a testing framework behind it.

Perhaps you're not a software developer. Most devs understand that there's a big difference between "it worked for me a few times on my development workstation" and "it's routinely tested in all possible configurations under a variety of circumstances as part of a test harness or CI/CD process".

In fairness to game devs, alt-tab'ing out of a running game would be a challenge for many testing frameworks as it's not something you can do at compile time, requires running the game for a period of time (CI servers don't typically have GPUs), requires some sort of keyboard/mouse automation, and interaction with the underlying OS in addition to the game.

Issues which aren't added to some sort of test suite/CI tend to creep back in to codebases. Especially rapidly developed codebases like games. And threading issues are notoriously challenging to reproduce. Hopefully that helps you understand the difference.

Many game devs develop on windows and for good reason in that most of their customer base are there, plus the stability of drivers there.

Your assumption of what you've been taught in compsci circles with many resources at their disposal does not hold up in places in which fast iterations are required, and with little time to set up testing frameworks because as you said they're hard to test.

> Many game devs develop on windows

I would say most game devs. That doesn't change a thing I've said.

> plus the stability of drivers there

Driver code for Nvidia, AMD, and Intel are all shared across Windows and Linux these days. Have been for years. AMD's even made a point of pulling improvements from the Linux drivers back into the Windows drivers.

> Your assumption of what you've been taught in compsci circles with many resources at their disposal does not hold up in places in which fast iterations are required

I have developed games. I write libraries useful for gamedev. Every game developer I know uses version control and most use CI. Contrary to your opinion, version control and CI help to iterate faster with greater confidence, and don't require lots of resources, just a GitHub account and 5 minutes.

What an odd thing to argue.

> Every game developer I know uses version control and most use CI.

Funny because I know game developers who don't use CI. And I've developed games too. It's not as universal as you claim it to be. It was never about arguing the effectiveness of CI.

> I know game developers who don't use CI

I'm sure they're out there. A bit like publicly declaring you drive without wearing a seatbelt.

> It was never about arguing the effectiveness of CI.

The original point was that alt-tab'ing out of a game can result in unexpected behavior on any OS. Shared memory buffers in graphics APIs are the most likely culprit. And all graphics APIs on all OSes use them. I'm still not sure what exactly you're trying to argue about that.