3 ms·

Prediction: Valve will cleanup the technical abomination which is the current steam client: clean 64bits (yeah, the core is still 32bits...), libdl-ing all its

Prediction: Valve will cleanup the technical abomination which is the current steam client: clean 64bits (yeah, the core is still 32bits...), libdl-ing all its system deps (yeah, it is still statically loading libgl...), static libstdc++ and static libgcc to avoid those horrible ABIs, shell scripts with program helpers and conservative usage of command options and not bash scripts using command niche options (often gnu only, or alternative breaking, for instance alternatives of the "official xz"). Ofc, beyond compile-time OS abstraction tables of functions, proper runtime fallback tables of functions (wayland->x11, vulkan->GL->CPU), but since libcef (the steam client is moving to libcef) is blink, they don't do anything, google seems to do everything here (hope I am wrong). Ofc, all game engines will be coded properly the same way. It seems unity3D is doing exactly that (but their vulkan3D backend seems far to be on par with their glcore backend). Elephant is the room: c++ is not mean for binary-only games on elf/linux since the static libstdc++ does not libdl (dlopen/dlsym/dlclose) its system dependency (unless it was fixed by c++ gcc devs and I missed it). absolute truth: c++ syntax has a toxic complexity, not to mention its absurd and grotesque _very few_ required compilers in size and complexity. And of course: Silksong, Half-life 3, dota2 out of beta and more native AAA (irony). I don't talk about proton, which does just displace the QA which should be done by the game devs on native elf/linux to the "proton devs" (probably a money sink hole for valve) which have to deal with the massive bloat and kludge, msft grade (yeah...), of its code and SDK. It would be more reasonable with a lean build of wine(win64 core)+only vkd3d(dx12->vulkan), but I guess few to no games would run on that. Heard proton has straight copies of windows components... which would make things even worse.

recursive_loops 4y ago
I for one would be very happy if they clean up the 32bit parts. On Fedora I haven't been able to get rid of a start-up warning saying 32 bit libs are missing (installing them doesn't seem to fix it). Fortunately I can launch games and do Steam Link just fine, so it's more an annoying dialog to click "Ok" on. But it does break anytime they push updates as Steam can't restart itself. I also occasionally have to `pkill -9 steam` as it doesn't properly handle signals so will ignore anything it can. Minor complaints to be sure, but would be great to get cleaned up.
smoldesu 4y ago
> the "proton devs" (probably a money sink hole for valve) It's probably a ridiculous figure. However, compared to the amount Sony/Nintendo/Microsoft spends engineering their console runtimes, I bet it makes a lot more sense. It also helps that Valve doesn't have to maintain Wine by themselves, with various cross-platform stakeholders funding and making contributions. It's obvious that Proton/DXVK/Wine is a passion project for Valve, but much harder to tell if they're seriously threatening the idea of a "Windows runtime". > Elephant is the room: c++ is not mean for binary-only games I think I agree with you. Steam's runtime provides a lot of stuff (probably standardized libstdc++), so it's hard to truly evaluate how true this is. That being said... both Steam and Wine do a really good job juggling it. Steam works roughly the same on NixOS, Arch, Flatpak and Snap - that's a better starting point than most software clients get.
- fbdab103 4y ago
  >if they're seriously threatening the idea of a "Windows runtime". From my vantage point, it certainly seems successful. I finally ditched my Windows gaming-only PC last year. Granted, people like me are likely less than a single digit percentage of gamers, but we exist, and as Proton compatibility improves, the percentage could rise.
  - smoldesu 4y ago
    Yep, I'm in the same boat. I reserve my judgement though, since a lot of people are still Windows-first and Microsoft has yet to make a Hail-Mary powergrab for DirectX.
  - pjmlp 4y ago
    I advise a visit to OS/2 museum.
- 7speter 4y ago
  I guess it's a sinkhole, but its more of an investment for Valve's future. If Microsoft comes down hard with pushing the Microsoft Store, especially since they now own how many different game studios, Valve (and the other Launcher/Gaming storefronts) will be pushed out of existence. Now, while Valve continues to hold influence in how games are distributed online, they are finding a way to exist without Windows and Microsoft. Steam is the easiest way to get games to play on Linux, and people can (and will) jump the Windows ship and still be able to buy games from Steam, allowing Steam to weather any attempts by Microsoft to put it out of business.
PaulDavisThe1st 4y ago
> c++ syntax has a toxic complexity irrelevant. any language that allows polymorphism (i.e same name for a procedure call with different versions used for different argument types) has to do some sort of naming trick to make this possible (since the idea is unknown at assembler or linker level). what makes c++ tricky for linkage is almost entirely just this, which has nothing to do with c++ syntax at all.

recursive_loops 4y ago

I for one would be very happy if they clean up the 32bit parts. On Fedora I haven't been able to get rid of a start-up warning saying 32 bit libs are missing (installing them doesn't seem to fix it). Fortunately I can launch games and do Steam Link just fine, so it's more an annoying dialog to click "Ok" on. But it does break anytime they push updates as Steam can't restart itself. I also occasionally have to `pkill -9 steam` as it doesn't properly handle signals so will ignore anything it can. Minor complaints to be sure, but would be great to get cleaned up.

smoldesu 4y ago

> the "proton devs" (probably a money sink hole for valve) It's probably a ridiculous figure. However, compared to the amount Sony/Nintendo/Microsoft spends engineering their console runtimes, I bet it makes a lot more sense. It also helps that Valve doesn't have to maintain Wine by themselves, with various cross-platform stakeholders funding and making contributions. It's obvious that Proton/DXVK/Wine is a passion project for Valve, but much harder to tell if they're seriously threatening the idea of a "Windows runtime". > Elephant is the room: c++ is not mean for binary-only games I think I agree with you. Steam's runtime provides a lot of stuff (probably standardized libstdc++), so it's hard to truly evaluate how true this is. That being said... both Steam and Wine do a really good job juggling it. Steam works roughly the same on NixOS, Arch, Flatpak and Snap - that's a better starting point than most software clients get.

fbdab103 4y ago
>if they're seriously threatening the idea of a "Windows runtime". From my vantage point, it certainly seems successful. I finally ditched my Windows gaming-only PC last year. Granted, people like me are likely less than a single digit percentage of gamers, but we exist, and as Proton compatibility improves, the percentage could rise.
- smoldesu 4y ago
  Yep, I'm in the same boat. I reserve my judgement though, since a lot of people are still Windows-first and Microsoft has yet to make a Hail-Mary powergrab for DirectX.
- pjmlp 4y ago
  I advise a visit to OS/2 museum.
7speter 4y ago
I guess it's a sinkhole, but its more of an investment for Valve's future. If Microsoft comes down hard with pushing the Microsoft Store, especially since they now own how many different game studios, Valve (and the other Launcher/Gaming storefronts) will be pushed out of existence. Now, while Valve continues to hold influence in how games are distributed online, they are finding a way to exist without Windows and Microsoft. Steam is the easiest way to get games to play on Linux, and people can (and will) jump the Windows ship and still be able to buy games from Steam, allowing Steam to weather any attempts by Microsoft to put it out of business.

PaulDavisThe1st 4y ago

> c++ syntax has a toxic complexity irrelevant. any language that allows polymorphism (i.e same name for a procedure call with different versions used for different argument types) has to do some sort of naming trick to make this possible (since the idea is unknown at assembler or linker level). what makes c++ tricky for linkage is almost entirely just this, which has nothing to do with c++ syntax at all.