[nicce]

We have quite a lot of disk space these days on computers, so we can just use functional/declarative package managers to use dependencies in any format we like, having multiple versions of the same dependencies simultaneously, if needed.

Steam/Epic/et all. could just host own package registry for games, and there is no conflict with major Linux distributions about binary distribution.

On that case developers can bundle their games as they want, and end-users just use the package manager.

If you look how Steam works under the hood in Linux, it also manages dependencies for each game separately instead of using system libraries in the most cases.

[sylware]

Unfortunately, this is not at all the case.

Collabora "pressure-vessel" (used by valve) is limited as it does not follow the ELF ABI for all ELF binaries, and does take of lot of shortcuts for provider software packages it must import (datafile locations, critical environment variables, etc), and if you don't have "ubuntu", you are done for: I have often arguments with one "pressure-vessel" devs because it is breaking my distro even though it is very vanilla and simple, but not "ubuntu" breaking many of their "shortcuts".

And games would like to run en elf/linux distros without "pressure-vessel" (as far as I know, is not open source), as a set of clean ELF binaries.

But there is light at the end of the tunnel: engines, like godot, unity, UE5 (I think) seems very carefull about ABI issues on elf/linux and the game devs don't need to worry about cherry picking backward symbol version, avoid symbol collision with system ones as it is done for them by engine devs.

But you have engines which expect too much from the user system, that beyond video game core libs/interface: like electron (google blink), which expects a specific version of GTK+ on the user system... so the end of the tunnel is still far away for them.

[nicce]

> if you don't have "ubuntu", you are done for

Steam provided libs seems to be from Ubuntu, but the host does not need to be? Or what did you mean.

I used to make OCI containers from games and run them in Docker/Podman, since there were a lot of GPU specific driver issues, so I could easily swap between different drivers. But I did not notice any issues when running games with Arch or other distros.

Edit: Pressure vessel seems to be open-source

https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/t...

[sylware]

When I said "ubuntu", it a reference to huge and mainstream elf/linux distros.

So to work around ABI instability from the glibc/gcc, you were building a container for each game you wanted to play, this is obviously past the point of being reasonable.

Weird, I did already clone this repo. I could not find pressure vessel code, I guess I missed it??? (BTW, this is a gigantic project, bad omens).

[nicce]

> So to work around ABI instability from the glibc/gcc, you were building a container for each game you wanted to play, this is obviously past the point of being reasonable.

That was my initial reasoning about functional/declarative package managers. They can reach the same but without making full blown containers.

[sylware]

Do you realize how much convolution this is? Without even considering the core of the issue: glibc devs and gcc are making core sys libs backward ABI handling a massive pain in the toolchain, and a kind of "silent killer".

It is inappropriate to consider those containers compared to actually doing something about this backward ABI handling in the toolchain for inexperienced devs on elf/linux (those coming from windows). This is technically more reasonable, with a abysmal difference.

[nicce]

But we would need some solution in the meantime?

It might take some huge effort (and time) to convince the devs. Especially, since development is going towards LLVM ecosystem. Linus prefers compailing Linux with clang these days.

When the ABI handling works well, you could still use the same principles for package managment.