4 ms·

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

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.

4 ms·

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

by speed_spread 3y ago

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.