Steam For Linux Beta Adds Experimental Namespaces/Containers Support

[carewolf]

That's exactly the point of what I said. It's trivial, yet, they didn't do it. And as a result, most games ported to Linux only supplied 32-bit versions. Had Steam only been 64-bit, we wouldn't have any 32-bit binaries (or at least they would've had to include some extra libraries.

In my experience most Steam games on Linux either have both 64-bit and 32-bit binaries or are 64-bit only. I only have a small handful of old Steam games that are 32bit only. I am starting to have more that are 64-bit only than 32-bit only.

[schmidtbag]

In my experience most Steam games on Linux either have both 64-bit and 32-bit binaries or are 64-bit only. I only have a small handful of old Steam games that are 32bit only. I am starting to have more that are 64-bit only than 32-bit only.

Actually looking back, I don't know why I said "most". I meant to say "many", because like you said, a lot supply both binaries. But still... this whole problem could've been effortlessly avoided had Valve only allowed Steam to be 64-bit. Catering to the dozen or so people who use Steam and can't upgrade to 64 bit most likely cost Valve more money than they would've gained by widening such a market. I don't know of anyone who willfully plays games on 32-bit Linux with a 64-bit capable processor, and I'm sure if such people had to switch, they would.
Having 32-bit support just added a layer of unnecessary complexity, and the news today is solid proof of that.

[Weasel]

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

Amen.

And to those who said "should've forced all games to be 64-bit", guess what? Most developers would not have bothered to port at all if their game was 32-bit only and it required to be 64-bit. They already don't want to port, considering the low amount of Linux ports, and that's assuming same architecture.

[xeekei]

How will containerised games affect streaming/recording with other software, such as OBS?

[arQon]

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.

You have clearly NEVER actually done this, and have absolutely no clue what you're talking about. I've ported both games and other apps from 32-bit to 64-bit, and can tell you that while it "only" takes weeks of dev and QA time for typical apps it can easily take months for a game engine full of blocks of asm for critical paths. Game engine codebases are generally at least a decade old, with only the renderer getting respun every few years, and enormous chunks of them - not to mention assorted third-party libs - are built with an implicit knowledge that ints and pointers are 32-bit.

The Steam client is doubtless much closer to a "simple" app than a game, and yeah, it's hard to excuse Valve for not having ported it yet given how important a part of their business it is. But it's also VERY old, and pretty much held together with scotch tape and baling wire at this point, and like any project with a mountain of technical debt to it there will be a genuine fear of touching it at all, especially since it IS almost their entire business.

"Just recompile it" shows a level of ignorance so complete that it blows my mind you even felt qualified to post it. And what's the real benefit to Valve for doing that? Having to maintain two clients, as you say, when there's zero user benefit to a 64-bit app in the first place and that platform is less than 1% of your market. Remember that until, what, ?about two years ago, if that? Ubuntu et al were still pushing their 32-bit builds as the "default" install.

Steam's stats aren't perfect, but Valve also has a lot more information about who's running Steam than you or I do. And if I was them, I wouldn't bother with a 64-bit Linux client at all either, until I could see that well over 95% of Linux users were on 64-bit systems, AND that there were a lot more of them than there are.

[carewolf]

You have clearly NEVER actually done this, and have absolutely no clue what you're talking about. I've ported both games and other apps from 32-bit to 64-bit, and can tell you that while it "only" takes weeks of dev and QA time for typical apps it can easily take months for a game engine full of blocks of asm for critical paths. Game engine codebases are generally at least a decade old, with only the renderer getting respun every few years, and enormous chunks of them - not to mention assorted third-party libs - are built with an implicit knowledge that ints and pointers are 32-bit.

I do that for a living. For any well-written program it is a simple recompile. If you are doing something overly clever with pointers and packing, and you are an amateur and did it wrong, it might need some rework, I fix bugs like that from time to time, but usually only in stuff like JIT compilers and image format parsers where such low-level trickery might make sense, this is rare in most application,and please note what I wrote above: Steam already has 64-bit binaries, just not on Linux. So any such problems would already be solved.

And for the love of God.. The steam client and all the steam games are entirely separate things. The games are already in 64-bit. We are talking about the launcher and nothing else.

[starshipeleven]

That's exactly the point of what I said. It's trivial, yet, they didn't do it. And as a result, many games ported to Linux only supplied 32-bit versions. Had Steam only been 64-bit, we wouldn't have any 32-bit binaries (or at least they would've had to include some extra libraries.

The main reason the games were 32bit was because they were 32bit on Windows too, and to the contrary of Steam client they actually need fixing to be 64bit native.

But it is a moot point, especially with Proton project now you can start using older Windows games, which are mostly 32bit for obvious reasons.

Having 64bit steam client is pointless, you still need 32bit libs.

[starshipeleven]

"Just recompile it" shows a level of ignorance so complete that it blows my mind you even felt qualified to post it.

Or maybe he knows the Steam client is mostly a webapp? (because it is) Just maybe.

[starshipeleven]

it would be interesting if it might be even faster because the flatpak version uses the libs, to a certain extend, desired by steam designers. One could even rebuild the pack with optimized versions I m thinking ahead of a clearlinux like approach - having libraries which are possible faster then the "system native / bare metal" ones.

With a container you are bare metal, and yes you can use optimized versions that are faster.

That's why Clear Linux has docker images https://hub.docker.com/u/clearlinux

[CochainComplex]

With a container you are bare metal, and yes you can use optimized versions that are faster.

That's why Clear Linux has docker images https://hub.docker.com/u/clearlinux

with bare metal I mean "system native" - I know that stuff running in a virtual environment like docker is bare metal because of the way how virtualisation is handled on cpu side. How would you distinguish between both implementations?

p.s.:for that very reason: on my nas system running Debian Stretch I'm using ClearLinux Containers (Mariadb and redis).