[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.

[sylware]

There are 2 main axis to work on, which are abysmally less costly than any container based mitigation of the issue, since with the following we get "clean" sets of ELF binaries:

- educate the devs on the matter. Those not using an engine already taking of that (this reduce by A LOT the amount of devs to teach).

- work on a toolchain switch to link with version symbol names from a backward ABI, easily (not having to manually enumerate all version symbol names and use the binutils gas .symver directive, or install a 10 years old distro). And a toolchain which does default to -static-libgcc, -static-libstdc++ (when c++ is used) and -ftls-model=global-dynamic while we are at it (in order to spare those expensive static TLS slots).

I do consider that gcc and clang(llvm) are lost for sane open source. Their absurd and grotesque size and complexity make them more toxic than anything else. Look at tinycc, cproc/qbe, simple-cc/qbe.