Steam For Linux Beta Adds Experimental Namespaces/Containers Support

[starshipeleven]

My real concern is it seems Value created yet another containerization solution, and we already have (at least) three.

They are just making a different frontend (adding features to their own client/package manager), but are using same Linux features Flatpak and Snap and LXC and Docker are also using.
AppImage is a completely different animal, and it kind of stinks.

I agree that using Flatpak directly it would have been optimal, but this is still not as NIH as developing their own system from scratch, as most of the functionality is already there and used by all other modern container providers.

This also means their container support will become production-ready very quickly, as it's just a matter of them learning how to set things up correctly from their own client.

[starshipeleven]

This is really great news. Finally they are using a serious approach that will allow them to deal with the future and eventually update their shit ancient Ubuntu 16.04 runtime.

I'm a bit disappointed that they are not using Flatpak though.

[Britoid]

This is really great news. Finally they are using a serious approach that will allow them to deal with the future and eventually update their shit ancient Ubuntu 16.04 runtime.

I'm a bit disappointed that they are not using Flatpak though.

They're using the same tech as Flatpak, they're even using Flatpaks data structure (~/.var/app/com.steampowered.App[AppId]). Eventually the Steam Flatpak should be able to use this stuff too so Steam itself is flatpakked, but for various reasons uses its own namespace setups for games, which is probably for the best.

[Berniyh]

I wish steam supported system-wide installation with no game data or executables in user-writable directory.

That's a pretty bad idea, but you can get it working by selecting a Steam Library on a different partition outside of your home directory as well as setting the corresponding links for the other steam directories.

I'd like to have my home partition mounted with noexec.

So you'd rather install random binary software system-wide by a binary launcher that'd require super user caps? :/

[Marc Driftmeyer]

Some notes, in no particular order:

Steam for Linux was released on 2013-Feb-14. According to https://web.archive.org/web/20140210....com/hwsurvey/ the market share of 32-bit Windows was about 20% in January 2014, which is non-negligible. According to this archived page, the share of 32-bit in Linux clients was somewhere between 5.25% and 5.25+39.26=44.51%.

64-bit games in year 2014 might have had about 20% smaller revenue potential than 32-bit games. This percentage in the case of a concrete game was higher or lower than 20% depending on the kind of audience the game was targetting in year 2014.

Steam is a GUI launcher for maintaining installations of applications and for launching those applications. There is no immediate danger of it overflowing the size of the 32-bit address space. The current (year 2019) RES of process "steam" on my machine is about 250 MiB and VIRT is about 1150 MiB. If VIRT was approaching 2048 MiB then it would be of concern.

From the viewpoint of a Steam Linux game, it doesn't matter whether the launcher is 32-bit or 64-bit. Steam Linux games can, most likely since 2013-Feb-14, freely choose whether they want to be 32-bit or 64-bit.

The launcher isn't performing a lot of 64-bit integer arithmetic operations.

64-bit floats are supported in x86 CPUs since i486 (introduced in April 1989) which was the first x86 CPU with an integrated floating-point unit.

steamwebhelper is a 64-bit application. Steam overlay has both 32-bit and 64-bit versions.

People who bought 32-bit Linux games are expecting that the games will be playable (directly, or indirectly through some form of emulation) throughout their entire human lifetimes. This is a timespan of about 50-70 years. ---- In the past, when games were distributed on tapes/floppies/CDs/DVDs, it was natural for the buyer not to expect for the bought game to be playable on a new system that does not support the old medium on which the game was originally distributed. ---- In the present, most games are being distributed digitally via Internet downloads. Unless an unexpected technology is discovered in the next 70 years that obsoletes the current form of game distribution, the main distribution medium for computer games in year 2019+70=2089 will be the same as today. (It is however possible that because of hardware compatibility reasons cloud gaming services might over time switch to renting games (i.e: the buyer's right to play the game expires after a predefined amount of time) instead of selling games (i.e: the right to play the game never expires); the gamer does not own the hardware on which the game is running in the cloud.)

I have no desire to install over 500MB of 32 bit libraries to satisfy Valve's 32 bit'ism.

[carewolf]

Valve kinda shot themselves in the foot when they made Steam a 32-bit application. But, the idea of containers isn't a bad one.

Not really, it is trivial to change to being a 64bit application, all it needs is a recompile, but I guess they prefer not to have two clients for linux, and still have a few on 32bit linux.

[khnazile]

So you'd rather install random binary software system-wide by a binary launcher that'd require super user caps? :/

Yes, because it saves space if you have multiple users. And it's not necessary should require super user caps, it could use a restricted user account of it's own. And also it could ask for administrator authorization before installing something. Polkit allows that.

[ssokolow]

Not really, it is trivial to change to being a 64bit application, all it needs is a recompile, but I guess they prefer not to have two clients for linux, and still have a few on 32bit linux.

They'd still need to do a bunch of testing to make sure that no "assume word size without asking for it" bugs crept in. (Stuff like assuming the size of an int.)

[Guest]

I think that steam play should be eventually supported by this as well. Wine isn't a perfect security solution in general, and providing 32 bit libraries to support 32 bit software and prefixes is quite important, as distros might drop support for dependencies needed to run 32 bit wine.

[starshipeleven]

They'd still need to do a bunch of testing to make sure that no "assume word size without asking for it" bugs crept in. (Stuff like assuming the size of an int.)

webapplications don't care about much of that. See my post https://www.phoronix.com/forums/foru...42#post1138142 about how most of the Steam client is a web application (i.e. a local website) running on Webkit.