3 ms·

Wouldn't using containers help with that? Stabilizing the whole environment by pinning it to a known-working distribution + version.

sylware 3y ago
This is what valve is doing with collabora "pressure-vessel" at the cost of a very expensive and intrusive kernel mechanism (mount namespace), and beyond sanity complexity ELF handling: they have to "scan" the host system and depending on the GNU versions (modules/symbols) used, have to cherry pick down to the host glibc libs to import into the container (usually it is limited to the driver libs). Currently, "pressure-vessel" is not finished as there are still bugs and missing features (basically speaking, if you don't have a massive and mainstream arch or ubuntu/debian...). Have to check on it in the near future, the devs have to fix the handling of host environment variables and some host libs which are not imported (for alsa dmix and dsnoop IPCs to work as intended in the container singe games need only to care about alsa-lib API). Then to work around the toxic behavior of glibc/gcc devs, valve is building a "mitigation" of extreme cost and complexity with the help of collabora. The guilty are the glibc and gcc devs, they deserve hate, and this is righteous hate. The other mitigation is to drop the ball, and go full wine+vkd3d as a layer to protect game binaries from glibc and gcc devs SABOTAGE. But this is a gigantic shabby kludge (troubleshooting is just horrible, and not breaking anything on the long run...) ON TOP of the already kludgy and bloated glibc/gcc... valve calls its wine+vkd3d version "proton" (probably running in a "pressure-vessel", I don't use proton but a custom lean build of wine+vkd3d). Valve seems not to do that fairly (hope I am wrong): proton is wine+vkd3d with nasty additional components. At least they should backport in plain and simple C everything from proton into wine+vkd3d... but some says there are too many real windows components (actual copies) and nothing really pertinent to backport. On the good side, dx12 is said to be a simpler vulkan, hence games, if coded with a conservative usage of the windows APIs, should really work better and better. Some troubles on the video/audio codecs, but game devs should really use a LGPL ffmpeg/libdav1d statically linked into their binaries for that. Keep in mind: all that should not exist in the first place. The alternative is to be extremely competent on elf/linux and to manage to generate game binaries which will work using only the core video game components, and that even on "older" distros... namely what Ethan Lee is doing, because do not expect game devs to know how to do that, it is a technical abomination ("pinning" can become quickly very hard, and it worsen if the game is using c++): game binaries naively generated on "recent" (for instance glibc 2.34) distros (what "normal" game devs do) won't run on "older" (for instance glibc 2.33) distros. Allready got at least a game and demo in this case on steam.
- speed_spread 3y ago
  Sounds like maintaining a glibc fork would simpler than fighting the official ones with dirty tricks, but I assume they know what they are doing. I am not sure glic maintainers "deserve hate" - very little people actually do. But it is probable that their incentives and culture run against the changes that would be required here. I can figure that "preserving Windows games compatibility" would stand _very_ low on their priority list.
  - sylware 3y ago
    glibc is tightly coupled with gcc. Valve would need to fork glibc and most of gcc (at least the libs). And all distros which want to run games would have to provide video game core components using such runtime. Well, they chose wine+vkd3d (but a fishy "proton" version as I described in my previous post), and a "container". The sabotaging behavior of glibc/gcc devs is not breaking windows games, it is breaking native elf/linux games, to a point you wonder if they are not rolling for msft and friends. Don't worry, they perfectly know what they are doing, hatred well deserved. But there is a long term solution to the core of the issue: ELF has to go, replaced with an excrutiatingly simple executable/shared library format without static loading, that for modern hardware architecture. A bit like json/wayland, namely much harder to abuse. Or in ELF: do deprecate static TLS, static loading and GNU versioning (let's keep the latest ELF relative relocation). Another way I am seriously thinking about: full "IPC" for video game core components: wayland/drm IPC, pulseaudio2 IPC (maybe something simpler though), /etc/resolve.conf, direct linux syscalls (in other words full static linking)... vulkan3D/drm IPC (oooof! super can of worms and lower performance), xkb IPC (oooof! another can of worms). game binaries would be static PIE executables.
0xcde4c3db 3y ago
It might help, but at this point Linux containers can't really stabilize the whole environment, especially for games. Particular pain points include accelerated graphics (which theoretically can have a stable kernel interface, but in practice is so complex and performance-sensitive that it's not stable enough to be a "reference platform", so to speak) and modern game controllers (which present a whole mess of concerns typically "addressed" in Flatpak by granting the device=all permission and hoping for the best [1]). I also know a guy who ran into issues with a kernel update breaking a custom allocator, although I don't know the fine details. That wasn't for a game, but games also use custom allocators for various reasons. [1] https://github.com/flatpak/xdg-desktop-portal/issues/536 https://github.com/flatpak/xdg-desktop-portal/issues/536

sylware 3y ago

This is what valve is doing with collabora "pressure-vessel" at the cost of a very expensive and intrusive kernel mechanism (mount namespace), and beyond sanity complexity ELF handling: they have to "scan" the host system and depending on the GNU versions (modules/symbols) used, have to cherry pick down to the host glibc libs to import into the container (usually it is limited to the driver libs). Currently, "pressure-vessel" is not finished as there are still bugs and missing features (basically speaking, if you don't have a massive and mainstream arch or ubuntu/debian...). Have to check on it in the near future, the devs have to fix the handling of host environment variables and some host libs which are not imported (for alsa dmix and dsnoop IPCs to work as intended in the container singe games need only to care about alsa-lib API). Then to work around the toxic behavior of glibc/gcc devs, valve is building a "mitigation" of extreme cost and complexity with the help of collabora. The guilty are the glibc and gcc devs, they deserve hate, and this is righteous hate. The other mitigation is to drop the ball, and go full wine+vkd3d as a layer to protect game binaries from glibc and gcc devs SABOTAGE. But this is a gigantic shabby kludge (troubleshooting is just horrible, and not breaking anything on the long run...) ON TOP of the already kludgy and bloated glibc/gcc... valve calls its wine+vkd3d version "proton" (probably running in a "pressure-vessel", I don't use proton but a custom lean build of wine+vkd3d). Valve seems not to do that fairly (hope I am wrong): proton is wine+vkd3d with nasty additional components. At least they should backport in plain and simple C everything from proton into wine+vkd3d... but some says there are too many real windows components (actual copies) and nothing really pertinent to backport. On the good side, dx12 is said to be a simpler vulkan, hence games, if coded with a conservative usage of the windows APIs, should really work better and better. Some troubles on the video/audio codecs, but game devs should really use a LGPL ffmpeg/libdav1d statically linked into their binaries for that. Keep in mind: all that should not exist in the first place. The alternative is to be extremely competent on elf/linux and to manage to generate game binaries which will work using only the core video game components, and that even on "older" distros... namely what Ethan Lee is doing, because do not expect game devs to know how to do that, it is a technical abomination ("pinning" can become quickly very hard, and it worsen if the game is using c++): game binaries naively generated on "recent" (for instance glibc 2.34) distros (what "normal" game devs do) won't run on "older" (for instance glibc 2.33) distros. Allready got at least a game and demo in this case on steam.

speed_spread 3y ago
Sounds like maintaining a glibc fork would simpler than fighting the official ones with dirty tricks, but I assume they know what they are doing. I am not sure glic maintainers "deserve hate" - very little people actually do. But it is probable that their incentives and culture run against the changes that would be required here. I can figure that "preserving Windows games compatibility" would stand _very_ low on their priority list.
- sylware 3y ago
  glibc is tightly coupled with gcc. Valve would need to fork glibc and most of gcc (at least the libs). And all distros which want to run games would have to provide video game core components using such runtime. Well, they chose wine+vkd3d (but a fishy "proton" version as I described in my previous post), and a "container". The sabotaging behavior of glibc/gcc devs is not breaking windows games, it is breaking native elf/linux games, to a point you wonder if they are not rolling for msft and friends. Don't worry, they perfectly know what they are doing, hatred well deserved. But there is a long term solution to the core of the issue: ELF has to go, replaced with an excrutiatingly simple executable/shared library format without static loading, that for modern hardware architecture. A bit like json/wayland, namely much harder to abuse. Or in ELF: do deprecate static TLS, static loading and GNU versioning (let's keep the latest ELF relative relocation). Another way I am seriously thinking about: full "IPC" for video game core components: wayland/drm IPC, pulseaudio2 IPC (maybe something simpler though), /etc/resolve.conf, direct linux syscalls (in other words full static linking)... vulkan3D/drm IPC (oooof! super can of worms and lower performance), xkb IPC (oooof! another can of worms). game binaries would be static PIE executables.

0xcde4c3db 3y ago

It might help, but at this point Linux containers can't really stabilize the whole environment, especially for games. Particular pain points include accelerated graphics (which theoretically can have a stable kernel interface, but in practice is so complex and performance-sensitive that it's not stable enough to be a "reference platform", so to speak) and modern game controllers (which present a whole mess of concerns typically "addressed" in Flatpak by granting the device=all permission and hoping for the best [1]). I also know a guy who ran into issues with a kernel update breaking a custom allocator, although I don't know the fine details. That wasn't for a game, but games also use custom allocators for various reasons. [1] https://github.com/flatpak/xdg-desktop-portal/issues/536 https://github.com/flatpak/xdg-desktop-portal/issues/536