5 ms·

It's worth noting that the native Linux version of games is often buggy and a far worse experience than the Windows version running on Proton. Valve itself is i

It's worth noting that the native Linux version of games is often buggy and a far worse experience than the Windows version running on Proton. Valve itself is infamous for this: the Left 4 Dead 2 native game has multiple very annoying bugs that have been known for 15 years, and that Valve still hasn't fixed. Unfortunately, there is (another) bug that prevents the Windows version running on Proton from connecting to VAC-secure servers or I would have ditched the Linux version long ago. At this point game devs should just discontinue the native version if they aren't going to properly support it and just make sure the game runs flawlessly on Proton.

arcfour 1y ago
I've had the opposite experience, getting great performance in TF2 for example and even Rust on Linux (but with Rust you couldn't connect to EAC secured servers, so, useless outside of testing stuff on a private server).
izacus 1y ago
Is this the case for BG3?
- trenchpilgrim 1y ago
  This is specifically a Steam Deck version and _not_ a general Linux version, so it's likely not applicable in this case. Think of it more like a console native port.
  - gpderetta 1y ago
    I would be surprised if it was hard to run it on a generic Linux.
- SchemaLoad 1y ago
  Often the linux builds do work when they are released, but then an OS update changes some dynamic linked library which then breaks them.
  - a_humean 1y ago
    Except valve runs these games in well defined container runtimes to avoid these issues: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/container-runtime.md https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/b...
    - pipes 1y ago
      That is fascinating. So if I have a Linux version of say a game or emulator, and it seems unstable on steam deck, I could try running it in this container?
      - 0dayz 1y ago
        I believe steam deck already does this, if not yes you can.
      - a_humean 1y ago
        Valve already runs all native linux games I believe in the scout 1.0 runtime by default unless the vendor specifies a newer linux runtime. You can override some of this behaviour by going to the games's preferences within the steam client under "compatibility". It lets you force a specific native linux runtime or run the windows version instead using Valve's fork of wine, proton. Sometimes if there are issues with the native linux release you can quickly swap over to the windows/proton version and see if that fixes issues. Valve are absolute heroes in trying to create stable targets for linux gaming whether that be running windows games via proton or having a stable container target for native support. I haven't had to boot into windows for nearly a year at this point and yet still playing new games on release without much issue (occasionally had to force to use a newer version of proton). The only games I cannot run are competitive multiplayer games that do intrusive kernel level anti-cheat, but fortunately I don't play those games. https://areweanticheatyet.com/ https://areweanticheatyet.com/
        pipes 1y ago
        Yes, owning a steam deck and using proton persuaded me to get rid of windows 11 on one of my pcs. I've been using Linux for years, but always kept switching back to windows for games and general hardware compatibility. I doubt I'll switch to windows again
- chipsrafferty 1y ago
  Yes, BG3 crashed my Linux computer continuously so I could not even play it until I bought a ps5
  - Kudos 1y ago
    I think you might be confused, there wasn't a linux-native version until yesterday.
- WithinReason 1y ago
  The SD version crashes the steam overlay. I didn't check further than the menu yet.
- Kudos 1y ago
  If you want to play on Nvidia, probably yes.
Levitating 1y ago
That's kind of the state of Linux in general. Binaries need to be build against the correct distribution and version. Even static binaries are a gamble.
- vanviegen 1y ago
  Actual static binaries (so including libc) should run just fine anywhere, right? The Linux kernel has always had a very stable ABI.
  - flohofwoe 1y ago
    Yes but that limits you to command line applications. GL and X11 (and I assume Wayland) are always linked dynamically. Granted, those don't suffer from glibc's "DLL version hell", but not sure what happens when you link the main executable statically against musl and then load DLLs which dynamically link glibc. Another option is to dynamically link against an old glibc version, the Zig toolchain makes that easy also for C/C++ projects.
    - electroly 1y ago
      If you statically link musl, dlopen doesn't work at all. You can't load any shared library.
    - badsectoracula 1y ago
      glibc doesn't suffer from DLL version hell as long as you are not doing anything stupid (like using private symbols). If you commit to using just the "C library" bits you can compile a binary linked against glibc on a distro from 1998 and it will work on modern distros just fine. There are many issues with libraries breaking backwards compatibility on Linux (like pretty much all GUI ones) but glibc, X11, OpenGL (and to some extent SDL - it used to not be like that, but in recent years they made "SDL1->SDL2" wrappers and there is or will be a "SDL2->SDL3" wrapper too) are fine. I'm not sure about Vulkan but i'd guess that is fine too.
      - 1y ago
haunter 1y ago
Time to link the famous “Win32 Is The Only Stable ABI on Linux” https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/ 500 comments https://news.ycombinator.com/item?id=32471624 https://news.ycombinator.com/item?id=32471624
- athrowaway3z 1y ago
  Correct me if I'm wrong, but I don't think that's an entirely fair comparison? The syscall abi has been stable for decades, and any game that included glibc or compiled with musl keeps running just fine?
  - p_l 1y ago
    You need to include not just glibc, you also need to include ld.so sometimes, because older libs can become incompatible with current ld.so (Linux port of SMAC for example), and I fear what it might do sometimes when trying to link openGL or Vulkan driver that links to newer glibc.
- slightwinder 1y ago
  Oh, is that why steam still depends on trashy 32bit-libs? Last week, after updating my Debian, steam broke because of that s**, and now I have to think about using a separate windows-machine just for this, until steam removes the 32bit-dependencies (which seems to be planned for 2026).
  - SkeuomorphicBee 1y ago
    On my Debian system I use the flatpack version of Steam, it comes with the 32bit stuff inside the container, so you don't need any 32bit packages in the OS.
    - slightwinder 1y ago
      The flatpak-client starts here, but has permissions-problems with installing games. Probably because I have to use a different ssd from the one where the flatpak is installed at.
KolibriFly 1y ago
Unless a studio is fully committed to proper Linux support (like, Feral-level), they might as well just optimize for Proton and call it a day
- pmarreck 1y ago
  One of the reasons Proton has been so successful as a dev target is because the Windows API is not changing anymore and is thus stable. The same, as I understand it, cannot be said about the Linux-native API. SteamOS may have stabilized it somewhat, but there's a reason why the readme on their site for this basically says "it may run on Linux proper, but we're not supporting it except on Steam Deck"
spaceywilly 1y ago
I would tend to agree, I think dev time is better spent supporting Proton. I have even seen benchmarks where Proton on Linux outperforms Windows. As a Steam Deck owner, Proton is fantastic. https://www.forbes.com/sites/jasonevangelho/2024/08/21/linux-scores-a-surprising-gaming-victory-against-windows-11/ https://www.forbes.com/sites/jasonevangelho/2024/08/21/linux...
jonny_eh 1y ago
I started playing Silksong on my Steam Deck using the linux build. Only to discover that it maxed out at 720p (docked), and wouldn't bind right/left trigger for my controller. Enabling proton (to play the windows build) worked great. Controller worked flawlessly and the game ran smoothly at 1080p.
- drnick1 1y ago
  Yes, and sadly this is very commonplace. At this juncture, Linux builds don't make a lot of sense anymore, especially if they are not going to receive much attention when it comes to debugging. The performance penalty of Proton is small enough that it rarely matters. The worst I have seen is perhaps -20% FPS in Helldivers 2 (with an Nvidia GPU), but normally the impact is in the 0 to 10% range, so negligible for all intents and purposes.

arcfour 1y ago

I've had the opposite experience, getting great performance in TF2 for example and even Rust on Linux (but with Rust you couldn't connect to EAC secured servers, so, useless outside of testing stuff on a private server).

izacus 1y ago

Is this the case for BG3?

trenchpilgrim 1y ago
This is specifically a Steam Deck version and _not_ a general Linux version, so it's likely not applicable in this case. Think of it more like a console native port.
- gpderetta 1y ago
  I would be surprised if it was hard to run it on a generic Linux.
SchemaLoad 1y ago
Often the linux builds do work when they are released, but then an OS update changes some dynamic linked library which then breaks them.
- a_humean 1y ago
  Except valve runs these games in well defined container runtimes to avoid these issues: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/container-runtime.md https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/b...
  - pipes 1y ago
    That is fascinating. So if I have a Linux version of say a game or emulator, and it seems unstable on steam deck, I could try running it in this container?
    - 0dayz 1y ago
      I believe steam deck already does this, if not yes you can.
    - a_humean 1y ago
      Valve already runs all native linux games I believe in the scout 1.0 runtime by default unless the vendor specifies a newer linux runtime. You can override some of this behaviour by going to the games's preferences within the steam client under "compatibility". It lets you force a specific native linux runtime or run the windows version instead using Valve's fork of wine, proton. Sometimes if there are issues with the native linux release you can quickly swap over to the windows/proton version and see if that fixes issues. Valve are absolute heroes in trying to create stable targets for linux gaming whether that be running windows games via proton or having a stable container target for native support. I haven't had to boot into windows for nearly a year at this point and yet still playing new games on release without much issue (occasionally had to force to use a newer version of proton). The only games I cannot run are competitive multiplayer games that do intrusive kernel level anti-cheat, but fortunately I don't play those games. https://areweanticheatyet.com/ https://areweanticheatyet.com/
      - pipes 1y ago
        Yes, owning a steam deck and using proton persuaded me to get rid of windows 11 on one of my pcs. I've been using Linux for years, but always kept switching back to windows for games and general hardware compatibility. I doubt I'll switch to windows again
chipsrafferty 1y ago
Yes, BG3 crashed my Linux computer continuously so I could not even play it until I bought a ps5
- Kudos 1y ago
  I think you might be confused, there wasn't a linux-native version until yesterday.
WithinReason 1y ago
The SD version crashes the steam overlay. I didn't check further than the menu yet.
Kudos 1y ago
If you want to play on Nvidia, probably yes.

Levitating 1y ago

That's kind of the state of Linux in general. Binaries need to be build against the correct distribution and version. Even static binaries are a gamble.

vanviegen 1y ago
Actual static binaries (so including libc) should run just fine anywhere, right? The Linux kernel has always had a very stable ABI.
- flohofwoe 1y ago
  Yes but that limits you to command line applications. GL and X11 (and I assume Wayland) are always linked dynamically. Granted, those don't suffer from glibc's "DLL version hell", but not sure what happens when you link the main executable statically against musl and then load DLLs which dynamically link glibc. Another option is to dynamically link against an old glibc version, the Zig toolchain makes that easy also for C/C++ projects.
  - electroly 1y ago
    If you statically link musl, dlopen doesn't work at all. You can't load any shared library.
  - badsectoracula 1y ago
    glibc doesn't suffer from DLL version hell as long as you are not doing anything stupid (like using private symbols). If you commit to using just the "C library" bits you can compile a binary linked against glibc on a distro from 1998 and it will work on modern distros just fine. There are many issues with libraries breaking backwards compatibility on Linux (like pretty much all GUI ones) but glibc, X11, OpenGL (and to some extent SDL - it used to not be like that, but in recent years they made "SDL1->SDL2" wrappers and there is or will be a "SDL2->SDL3" wrapper too) are fine. I'm not sure about Vulkan but i'd guess that is fine too.
    - 1y ago

haunter 1y ago

Time to link the famous “Win32 Is The Only Stable ABI on Linux” https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/ 500 comments https://news.ycombinator.com/item?id=32471624 https://news.ycombinator.com/item?id=32471624

athrowaway3z 1y ago
Correct me if I'm wrong, but I don't think that's an entirely fair comparison? The syscall abi has been stable for decades, and any game that included glibc or compiled with musl keeps running just fine?
- p_l 1y ago
  You need to include not just glibc, you also need to include ld.so sometimes, because older libs can become incompatible with current ld.so (Linux port of SMAC for example), and I fear what it might do sometimes when trying to link openGL or Vulkan driver that links to newer glibc.
slightwinder 1y ago
Oh, is that why steam still depends on trashy 32bit-libs? Last week, after updating my Debian, steam broke because of that s**, and now I have to think about using a separate windows-machine just for this, until steam removes the 32bit-dependencies (which seems to be planned for 2026).
- SkeuomorphicBee 1y ago
  On my Debian system I use the flatpack version of Steam, it comes with the 32bit stuff inside the container, so you don't need any 32bit packages in the OS.
  - slightwinder 1y ago
    The flatpak-client starts here, but has permissions-problems with installing games. Probably because I have to use a different ssd from the one where the flatpak is installed at.

KolibriFly 1y ago

Unless a studio is fully committed to proper Linux support (like, Feral-level), they might as well just optimize for Proton and call it a day

pmarreck 1y ago
One of the reasons Proton has been so successful as a dev target is because the Windows API is not changing anymore and is thus stable. The same, as I understand it, cannot be said about the Linux-native API. SteamOS may have stabilized it somewhat, but there's a reason why the readme on their site for this basically says "it may run on Linux proper, but we're not supporting it except on Steam Deck"

spaceywilly 1y ago

I would tend to agree, I think dev time is better spent supporting Proton. I have even seen benchmarks where Proton on Linux outperforms Windows. As a Steam Deck owner, Proton is fantastic. https://www.forbes.com/sites/jasonevangelho/2024/08/21/linux-scores-a-surprising-gaming-victory-against-windows-11/ https://www.forbes.com/sites/jasonevangelho/2024/08/21/linux...

jonny_eh 1y ago

I started playing Silksong on my Steam Deck using the linux build. Only to discover that it maxed out at 720p (docked), and wouldn't bind right/left trigger for my controller. Enabling proton (to play the windows build) worked great. Controller worked flawlessly and the game ran smoothly at 1080p.

drnick1 1y ago
Yes, and sadly this is very commonplace. At this juncture, Linux builds don't make a lot of sense anymore, especially if they are not going to receive much attention when it comes to debugging. The performance penalty of Proton is small enough that it rarely matters. The worst I have seen is perhaps -20% FPS in Helldivers 2 (with an Nvidia GPU), but normally the impact is in the 0 to 10% range, so negligible for all intents and purposes.