Announcement

Collapse
No announcement yet.

Steam For Linux Beta Adds Experimental Namespaces/Containers Support

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

  • #21
    Originally posted by zxy_thf View Post
    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.
    totally agree. Im glad having steam as flatpak running since the libraries of the Nvidia driver (needed by Cuda) are causing issues with the 32bit required by steam. Last straw to grab for me was the flatpak ...but really it just works im really pleased by it.

    Btw it would be interesting to see how large the performance impact is compared system installed steam vs flatpak

    Comment


    • #22
      Originally posted by atomsymbol
      Last edited by atomsymbol; 11-10-2019, 11:48 PM. Reason: Add closing brace
      Thanks for that. I was wondering why it wouldn't compile

      (nice set of observations btw)

      Comment


      • #23
        Originally posted by CochainComplex View Post
        Btw it would be interesting to see how large the performance impact is compared system installed steam vs flatpak
        Should have no performance impact at all, like all containers.

        Consider that with a decent KVM setup (full virtualization) and a passthrough of disk drive (the VM is living in a true disk drive, it's not a virtual disk file in a normal filesystem) and GPU (only way to have any form of GPU performance at all) there is something like 5% of performance loss on the VM.

        Comment


        • #24
          Originally posted by starshipeleven View Post
          Should have no performance impact at all, like all containers.

          Consider that with a decent KVM setup (full virtualization) and a passthrough of disk drive (the VM is living in a true disk drive, it's not a virtual disk file in a normal filesystem) and GPU (only way to have any form of GPU performance at all) there is something like 5% of performance loss on the VM.
          thx for your reply - I know that it shouldn't. But for enthusiasts even 1% counts ....aside of this 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.

          Comment


          • #25
            Originally posted by CochainComplex View Post

            thx for your reply - I know that it shouldn't. But for enthusiasts even 1% counts ....aside of this 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.
            It should even be possible with Flatpak to build a runtime that uses Clear Linux's compile flags, so you can use the Clear Linux optimizations on any distro with Steam.

            Comment


            • #26
              Originally posted by Britoid View Post

              It should even be possible with Flatpak to build a runtime that uses Clear Linux's compile flags, so you can use the Clear Linux optimizations on any distro with Steam.
              Well I'm a bit into docker. Flatpak is rather new for me. But this could be some motivation

              Comment


              • #27
                I think everyone on this site would love to see an interview with GabeN or an engineer on the Valve's team to explain the choices behind their technology and unsuitability of traditional open source solutions like Flatpak! Ever considered arranging something like this? I'm sure Valve would cooperate.

                Comment


                • #28
                  Originally posted by Berniyh View Post
                  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.

                  So you'd rather install random binary software system-wide by a binary launcher that'd require super user caps? :/
                  Or that person may want to use a user read/writable /usr/local or /opt/steam. For multi-user systems, the way Steam works doesn't save on drive space nor are games available to multiple accounts outside of either allowing home sharing or moving all Steam games to a non-home location. The latter is what I do, but custom Protons, etc still have to be done on a per-user basis since they're installed to $HOME/.local/share/Steam when all the individual users really need is their save games and some encrypted file for auto-logins.

                  One of these days I hope they move the Proton compatdata to the various games' installation folders like they did with the shader cache. It gets annoying having to use the numeric codes when I want to wipe a prefix.

                  Comment


                  • #29
                    Originally posted by Creak View Post
                    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.
                    You're right, it isn't related to the game architecture. But a lot of games only have a 32-bit version. Had Steam only been 64-bit, that would in turn require all games to be 64-bit too. But since a lot (not all...) game devs are lazy, they only make 1 binary release for the game, so, the pick the one with the widest compatibility - 32-bit.

                    Originally posted by carewolf View Post
                    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.
                    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.
                    Last edited by schmidtbag; 11 November 2019, 01:56 PM. Reason: wrong use of word

                    Comment


                    • #30
                      Originally posted by ssokolow View Post

                      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.)
                      They already have 64bit binaries. For instance on macOS. So assuming most of their code is platform independent, that is already safe.

                      Comment

                      Working...
                      X