Announcement

Collapse
No announcement yet.

Steam For Linux Beta Adds Experimental Namespaces/Containers Support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Steam For Linux Beta Adds Experimental Namespaces/Containers Support

    Phoronix: Steam For Linux Beta Adds Experimental Namespaces/Containers Support

    Longtime Linux game developer Timothee Besset has outlined the support introduced by Valve this week in their latest Steam Linux client beta for supporting Linux namespaces / containers. This experimental functionality may in the end provide better support for 32-bit compatibility as more Linux distributions focus solely on x86_64 packages, reducing some of the fragmentation/library conflicts between some Linux distributions and Steam, and other headaches currently plaguing the Steam Linux space...

    http://www.phoronix.com/scan.php?pag...Exp-Containers

  • #2
    As mentioned in the article, I think this is yet another NIH syndrome. Value really does not need to reinvent flatpak/snap/AppImage again.

    Comment


    • #3
      Originally posted by zxy_thf View Post
      As mentioned in the article, I think this is yet another NIH syndrome. Value really does not need to reinvent flatpak/snap/AppImage again.
      They aren't:

      The flatpak solution wraps the entire Steam client, whereas Valve's approach is to wrap individual games first. Both approaches rely on the same technologies and we are looking into improving compatibility in the future.
      That's from the linked Valve statement (emphasis mine). All they are doing is working on compatibility issues with the needed approach to containerize individual games and not have layers of containers which the unofficial Steam flatpak would require. Right now it's a container for each game nested inside the Steam container. That's an awkward and unworkable solution both in the near and long term.

      Comment


      • #4
        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.

        Comment


        • #5
          schmidtbag I think there's a difference between Steam in 32-bit and the games launched by it. The games architecture isn't related to Steam's architecture IMHO.

          Comment


          • #6
            Originally posted by stormcrow View Post

            They aren't:

            That's from the linked Valve statement (emphasis mine). All they are doing is working on compatibility issues with the needed approach to containerize individual games and not have layers of containers which the unofficial Steam flatpak would require. Right now it's a container for each game nested inside the Steam container. That's an awkward and unworkable solution both in the near and long term.
            I'm Okay with a containerized steam with nested containerized games.
            The native steam causes lots of troubles on my system and the flatpak one works flawlessly, and to containerize individual games also makes sense to me because there are likely fewer compatibility issues (just think of how much effort MS put in order to maintain backward compatibility).

            My real concern is it seems Value created yet another containerization solution, and we already have (at least) three.
            Last edited by zxy_thf; 11-11-2019, 12:33 AM.

            Comment


            • #7
              Originally posted by schmidtbag View Post
              Valve kinda shot themselves in the foot when they made Steam a 32-bit application.
              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.)
              Last edited by atomsymbol; 11-11-2019, 12:48 AM. Reason: Add closing brace

              Comment


              • #8
                I see only positives in this. (And have been advocating it for a long time.)

                For those worried about a multitude of "container solutions", I will insist that this is not a problem, but rather exactly the intent of platform support for various and diverse container-ish features in Linux. One size does not fit all, and it's absolutely fine and good for Valve to create the best possible custom delivery system for games, with great user experience as the goal. What you want in gaming is not want you want in phone apps and not what you want in desktop applications (drag and drop!) and not want you want in system daemons and not want you want in Kubernetes pods and not what you want for Cloud-Native Network Functions (CNF). Open source will allow us to share technologies between these various containerized environments where relevant and appropriate.

                Container-like tech is a great way to deliver complete software or software components in many contexts. There are trade-offs, though. Duh. And so you want to weigh pros and cons and choose the best set of solutions for the particular experience you deliver.

                If Valve had to wait for the hobby community to solve the game delivery challenges we would all still be playing SuperTuxKart (no offense intended, great game!) and fiddling with WINE settings to almost get a few Windows games to run. Thank you, Valve, for charging ahead.

                Comment


                • #9
                  For anyone who's wondering who "Timothee Besset" is, he's better known as TTimo and he was basically the Linux dev at id since around the late 90s. (IDK when he left there, but I'm assuming not too long after JohnC did). He's a great guy, and while the whole Flatpak vs Snap vs etc clusterfuck is something I'm already sick of, I have a lot of faith that whatever Valve's doing with it will be better off for him being involved.

                  Comment


                  • #10
                    I wish steam supported system-wide installation with no game data or executables in user-writable directory. I'd like to have my home partition mounted with noexec.

                    Comment

                    Working...
                    X