Björn

Maybe https://github.com/papi-ux/polaris

Maybe Polaris is what you’re looking for. It’s meant for game streaming. But of course you can stream whatever you want.

Definitely Debian. You’re already used to it and personally I highly value the stability it brings for servers.

At least voice and video are often done peer to peer. So the strain on the server would be almost zero.

They aren’t the same at all. SteamOS is based on Arch and Bazzite on Fedora. They use different versions of software. Bazzite just aims to work the same as SteamOS.

The advantage of Bazzite is that you have more control over your system.

Avoid XWayland

It added 3.13 ms of latency, more than all other effects combined. Wayland is close, but X11 still wins

Though only by 0.14 to 0.22 ms. Given there are efforts to optimize KWin, this gap will likely close sooner rather than later. And who knows, other Wayland compositors might already be better. VRR has the biggest effect

VRR was faster in every pairing (0.26 to 0.45 ms) and also flattened the latency distribution. dxvk-low-latency is a win across the board

0.10 to 0.29 ms in capped scenarios is a nice boost, but the real strength of the fork shows in the uncapped test case, where it gained 0.84 ms over default dxvk.

Additionally, in scenarios where XWayland can’t be avoided, it recovered a full 2.1 ms. Conclusion

Not factoring in XWayland, applying every optimization (X11, VRR, low-latency) compared to a default setup (which, on a modern Linux system, I assume is plain Wayland) moved the median down by 0.72 ms.

That does not sound like a lot, but the raw latency does not tell the whole story as VRR additionally reduces latency jitter, and dxvk-low-latency’s pacer is great at smoothing out real-world scenarios where frame time dips and GPU-bound situations occur.

Can’t speak for the Lemmy devs but you should make sure that you understand every single line of change you propose. AI tends to get details wrong.

Fitting that r/selfhosted can’t selfhost.