Steam for Linux can now run games in a special container

Flatpak is a container solution that installs programs into sandbox directories and isolates them from your system.

Flatpak does not sandbox applications *unless* the flatpak requests it. It would be interesting once it starts enforcing it.
I don't know how steam flatpak is packaged though. With or without a request for containerizing.

I think you confused Flatpak with Snap.


Last edited by Nevertheless on 11 November 2019 at 1:09 pm UTC

That's the 32bit solution right there. Excellent.

Edit: Please disregard this post. I misunderstood.

It is one! Valve just won't support it officially..


Last edited by Nevertheless on 11 November 2019 at 2:15 pm UTC

That's the 32bit solution right there. Excellent.

It is one! Valve just won't support it officially..

Eh? This is official Valve stuff, it means they can easily bundle all the libs needed into a runtime people can directly pick on a system that doesn't then have those libs needed. I assume that's a big part of the point of this, like Beamboom said.

That's the 32bit solution right there. Excellent.

It is one! Valve just won't support it officially..

Eh? This is official Valve stuff, it means they can easily bundle all the libs needed into a runtime people can directly pick on a system that doesn't then have those libs needed. I assume that's a big part of the point of this, like Beamboom said.

Oh sorry.. My mistake. I thought he was referring to Flatpak.


Last edited by Nevertheless on 11 November 2019 at 2:14 pm UTC

1.How is this different from the previous Steam Runtime? Or was that thing for running Steam and this one for running games? Similar names are a bit confusing.

2. This innovation in the future will help to get rid of 32-bit libraries in distributions (as they wanted to do in Ubuntu) or is it a completely different thing?

3. Will this be automated for all games in the future, or will each one always have to be installed manually?

Could this be another hint towards the rumoured cloud service?

I'd assume it is more a let's-kill-32-bit (see e.g. ubuntu) fail-safe. Thoughts?

I wonder if that means that the Steam client itself will finally be 64-bit.

edit: It probably does not, unfortunately: "The system tries to use the host OpenGL implementation in the container using libcapsule." (source: Reddit

So, Steam will still need 32-bit libs to be able to run 32-bit games.


Last edited by AsciiWolf on 13 November 2019 at 3:46 pm UTC

Sounds pretty much like the sandboxes in Solaris or side-by-side-installations on MS(-xerox-apple...)-Windows. Actually a good way to keep applications running without interfering with each other, especially if you have common lib-dependencies but need different versions in order for the app to operate correctly / not to crash.
But long term it can still be a problem, i.e. when a special soundsystem isn't sound supported anymore at all, but only through wrappers (think about OSS). The same might apply to graphics, input devices and other stuff at some time. So I hope they understand that for this to work they will in the end need to write and maintain some wrappers to keep the old games going. Unfortunately OpenSource doesn't help here very much as some system stuff surely does change significantly over time and you won't be able to simply recompile without touching source code. But lets be optimistic and keep fingers crossed that it works out somehow.
Sure this can be also used for efficient/save cloud services. But it also will help you a lot the more apps/games you own that quickly aren't updated anymore for newer OS versions. It can significantly increase the amount of time you're able to use your stuff, hopefully until a point in time where you're actually not interested at all anymore in those games/apps.
Conclusion: as long as the steam desktop client stays alive, with local installation and hardware use, I think this is a very nice step forward.

Does this mean a Windows friend could run the Linux version of a game? Like, I could finally play some of my co-op games that don't support cross-platform play? I doubt this is the case, but one can hope.

For some reason, they are still too scared to boot into a flash drive to play the Linux version of a game. I even told them I'd buy a dedicated hard drive for them to isolate Linux stuff and they could dual boot. :'( Being the 1% sucks sometimes.

Looks like it is now on the stable release of Steam.

Sounds pretty much like the sandboxes in Solaris or side-by-side-installations on MS(-xerox-apple...)-Windows. Actually a good way to keep applications running without interfering with each other, especially if you have common lib-dependencies but need different versions in order for the app to operate correctly / not to crash.
But long term it can still be a problem, i.e. when a special soundsystem isn't sound supported anymore at all, but only through wrappers (think about OSS). The same might apply to graphics, input devices and other stuff at some time. So I hope they understand that for this to work they will in the end need to write and maintain some wrappers to keep the old games going. Unfortunately OpenSource doesn't help here very much as some system stuff surely does change significantly over time and you won't be able to simply recompile without touching source code. But lets be optimistic and keep fingers crossed that it works out somehow.
Sure this can be also used for efficient/save cloud services. But it also will help you a lot the more apps/games you own that quickly aren't updated anymore for newer OS versions. It can significantly increase the amount of time you're able to use your stuff, hopefully until a point in time where you're actually not interested at all anymore in those games/apps.
Conclusion: as long as the steam desktop client stays alive, with local installation and hardware use, I think this is a very nice step forward.

Emphasis mine

I think this is a great thing. It gives some extra life to old games. And since the wrappers are FLO (free-libre-open), if there is enough demand for it, it can be maintained by volunteers or paid for by volunteer donations (think some person on Patreon maintaining a small number of wrappers or a kickstarter to update wrappers for old-game-we-all-liked). Hypothetically some art organizations might want to pay some dev to update the wrappers as well to preserve some significant game. So I think FLO helps quite a lot in this. It opens many potential doors. I'm starting to like Valve more and more.

For some reason, they are still too scared to boot into a flash drive to play the Linux version of a game. I even told them I'd buy a dedicated hard drive for them to isolate Linux stuff and they could dual boot. :'( Being the 1% sucks sometimes.

One way out is to offer to do the whole process for them. Possibly so they can see how easy/hard it is.

Does this mean a Windows friend could run the Linux version of a game? Like, I could finally play some of my co-op games that don't support cross-platform play? I doubt this is the case, but one can hope.

For some reason, they are still too scared to boot into a flash drive to play the Linux version of a game. I even told them I'd buy a dedicated hard drive for them to isolate Linux stuff and they could dual boot. :'( Being the 1% sucks sometimes.

It's not a Linux emulator. It's based on Linux Namespaces, which is a feature of the Linux kernel to isolate kernel resources. This can't be built into the Windows client.

Could this be another hint towards the rumoured cloud service?

Imho it's just embracing present day tech with its perks.

Then what will follow will ofc be built over present day stuff so yeah, it's also a step forward in the cloud race.