Announcement

Collapse
No announcement yet.

Steam Beta Brings Many Improvements For Steam Controllers

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

  • #11
    Originally posted by starshipeleven View Post
    Optimal solution is flatpack, they make Steam app itself and each game its own self-contained blob and keep some modules outside like "libraries for games that use ubuntu 12.04" or "libraries for games that use ubuntu 20.04" and so on. Flatpack allows that modular runtime usage, it would save LOTS of space in comparison to Snap that cannot.
    Are there any technical reasons why Steam wouldn't want to use Flatpak? Maybe something DRM related?

    Comment


    • #12
      Originally posted by starshipeleven View Post
      Of course this still means you get various GBs of crap libraries in your system like now (while with snap you would need to clone them for each single game which is a bit retarede), at least they are kept tidy and locked down this way.
      Today a classical game size is between 15 and 40GB, so a few libraries more will not hurt that much. Flatpack Valve, Flatpack!

      Comment


      • #13
        Originally posted by Maxjen View Post
        Are there any technical reasons why Steam wouldn't want to use Flatpak? Maybe something DRM related?
        No, flatpack does not get in the way of DRM as it just deploys applications.
        Steam does not require root permission to install games, but only to install itself (and if Steam itself is flatpacked it probably won't need that even for itself).

        Even if you manage to get your hands on a flatpacked steam game it would be like getting your hands on an archive with a steam game folder, without Steam (and a legit purchase) or illegal hacking it won't start even if you can "install" the flatpack itself.

        The same applies to snap, for that matter.

        Originally posted by Passso View Post
        Today a classical game size is between 15 and 40GB, so a few libraries more will not hurt that much. Flatpack Valve, Flatpack!
        "classical" in the sense of AAA title.

        The overwhelming majority of Steam games (i.e. oldish or indie) aren't above the 3 GB of size.

        1 GB of libraries for a 500 MB-2GB game is a bit too much imho.

        I mean, my linux steam library is around 15 of such games, and I'm not terribly attraced by the idea of... MORE GB FOR THE STEAM GOD!!!!... err I mean wasting 15 GBs or so for nothing.

        On a more serious note, another reason Steam should not go the retarded way is that this will put more stress on their servers. With flatpack you download the libs ONCE, with snaps you download them each time you buy a game.
        Last edited by starshipeleven; 17 June 2016, 09:50 AM.

        Comment


        • #14
          Concerning the Steam Controler: has anyone else been disappointed by the lack of default configuration?
          In 3/4 of my game the controller was not detected has a controller and I had to put by hand all keys (and there is a lot) so that the game thinks it is a keyboard/mouse combo.
          Because my keyboard is not Qwerty, downloading preconfigured ones did not work either...

          Well at least newest games like Talos had a perfect integration out of the box so I hope this situation will improve fast.

          Comment


          • #15
            please no flatpak, developers will start to push all kind of trash and even a simple game will require gnome, kde, X11, wayland, ruby, perl, python, go, C# and java, just because they are lazy. Games are big because of the music,. videos and the content! i don't want having 5 different operative systems installed. In the end, they will start pushing mesa, nvidia and amd drivers and you will have a hell to fix or debug anything.

            Also, between flatpak and snap, i would prefer snap... flatpak is from the gnome/redhat (and a little side step, systemd) guys, so "we know better, fuck your opinions" for everyone

            Comment


            • #16
              Originally posted by higuita View Post
              please no flatpak, developers
              No, I was saying that the packaging is done by Steam.
              Just as Steam deals now with games and packages in its own way and does its own things, if it used flatpack instead it would be better.

              even a simple game will require gnome, kde, X11, wayland, ruby, perl, python, go, C# and java, just because they are lazy.
              Games don't need DEs, the display server cannot be bundled because there would be issues in dealing with physical resources, the rest of shit can be bundled already if they feel like it even without flatpack, but on average they don't as they are too low-performance for a game.

              Also, between flatpak and snap, i would prefer snap... flatpak is from the gnome/redhat (and a little side step, systemd) guys, so "we know better, fuck your opinions" for everyone
              Yea, because Canonical isn't "we know better, fuck your opinions". Mir, bazaar, Upstart to name a few. It's just that Canonical's stuff is shit so most distros don't feel like adpoting their stuff.

              Also, very cool judgement, not on tool's quality but on tool's maker, also +10 points for completely unrelated systemd reference.

              Comment


              • #17
                Originally posted by Qaridarium
                the red hat people already pointed out that flatpack is not mean to compete with snap.
                I said flatpack because flatpack can have modular multi-app dependencies, which are useful in this case, Snap does not.

                also the builds are not bigger for example it is only bigger because it has java version build in and flatpack does not and also the very big difference was because of debug symbols and flatpack did not contrain this.
                Steam takes 1GB or so of Ubuntu libraries with itself. If you make standalone games, in a future where Steam starts using newer libraries than Ubuntu 12.04's and it does not want to break compatibility, it's smarter to keep modules with libraries instead of bundling this 1GB with each single game.

                If it does not upgrade its game libraries from ubuntu 12.04, the problem is moot as it can keep the libs in its own folder and case closed.

                Comment


                • #18
                  Can someone re!Ind me why steam won't update their app to something new, and maybe let us dump the 32-bit stuff

                  Comment


                  • #19
                    Originally posted by Passso View Post
                    Concerning the Steam Controler: has anyone else been disappointed by the lack of default configuration?
                    In 3/4 of my game the controller was not detected has a controller and I had to put by hand all keys (and there is a lot) so that the game thinks it is a keyboard/mouse combo.
                    Because my keyboard is not Qwerty, downloading preconfigured ones did not work either...

                    Well at least newest games like Talos had a perfect integration out of the box so I hope this situation will improve fast.
                    I had that same problem as well initially. In particular trine 3. It's the udev problem others are taking about. For Fedora at least you need to load uinput again during boot. I think that was the module.
                    ​​​​​​

                    Comment


                    • #20
                      Originally posted by jaxxed View Post
                      Can someone re!Ind me why steam won't update their app to something new, and maybe let us dump the 32-bit stuff
                      Because it's a port of the 32bit app they use on Windows and there they still need 32bit support, 99% of games need 32bit anyway and asking them to recompile for lulz isn't gonna happen, and also theoretically 32bits have more performance (mostly a moot point imho).

                      Frankly, I'm not bothered much by the use of 32bit libs, but by the fact that it litters my system with them, sometimes causing architecture issues for some that aren't multiarch-safe.

                      At least on Debian.

                      Comment

                      Working...
                      X