Announcement

Collapse
No announcement yet.

Steam on linux mentioned by Steam moderator

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

  • #16
    Personally I would prefer them having some closed downloads area on some site where you can download stuff with your account and then have "fetch restrictions" in the package manager, so that you got to fetch the files by hand if they don't want to allow "downloads for everyone".

    This way every distribution could handle the files they want to handle them, eg Gentoo can create an ebuild for it, Debian some adaption to apt and the RPM based distris one working for them.

    IMO steam in general does not have this much benefits for a Linux user since we already do have package managers. And providing a package manager with updates capabilities is the major benefit for Windows users. (Strange OS not to offer a decent package manager... )

    But even if it is a plain port of steam (the package manager, "webshop"/game distribution and drm system known from Windows) to Linux and OSX, it will still be a benefit for many Linux users, since it allows publishers to see that there are users who buy (native) Linux software. Somehow I would not be suprised if the numbers of Linux users reported in the system survey after it is out would indicated that a percentage close to the numbers of vista users is using Linux...

    Short version:
    Yes, it would be great if the *content* normally offered by steam could just be handled by all the package managers directly and not just via steam. Though this is probably unlikely to happen .

    Comment


    • #17
      Originally posted by alex-weej View Post
      I'd be much more interested in them delivering games via APT, secure authenticated over TLS if they're worried about people stealing their games.
      As a content delivery system, apt would be a poor choice for large files. Apt does not download files in chunks like steam does. Steam downloads large files much like bittorrent does, the large file is treated like a bunch of individual identically sized pieces and upon delivery of each individual piece it's checksum is checked using SHA1.

      There is nothing stopping steam from determining the packaging system utilized by a distro. Steam could easily detect the OS and choose the appropriate package type much like it detects if the version of windows is requesting the game and it downloads the appropriate build for that system (ie 32-bit or 64-bit).

      Comment


      • #18
        Here's a wild suggestion. But what IF the Steam "protocol" (a la BitTorrent) could be added to "package kit"? Many distributions have shown interest in it as a unified "frontend" to different package managers. What if Steam could be handled just as another repo, with its own "protocol" (added to Package Kit, through a small package (.deb, .rpm, .tgz or ebuild) and using Steam accounts to download the content. This very same "steam" package could also include a library to identify Steam signed packages at run time to authenticate it (preferably off-line). But there is no telling how are they going to implement it.

        Comment


        • #19
          Originally posted by ivanovic View Post
          Yes, it would be great if the *content* normally offered by steam could just be handled by all the package managers directly and not just via steam. Though this is probably unlikely to happen .
          Yes, it's very unlikely to happen.

          Guys, it's a fact of reality that you've got a dozen or so packaging systems, all different- and we won't get into the deltas between RPM and DEB distributions. What all of you are asking for is a support nightmare. It'd be one thing if we had only ONE packaging system. As it stands, they have a unified means for installing and uninstalling titles from LGP, Runesoft, etc. so I suspect that you're going to find Steam no different. What's important is being able to consistently install and uninstall it over a wide range of systems. Making it do this via your disparate packaging systems, since this stuff ISN'T developed specifically for Fedora, SuSE, Ubuntu, or others, doesn't make as much sense, save for you having a one-stop shop to do EVERYTHING from. Nice, but not practical.

          Keep wishing, but don't expect it anytime soon.

          Comment


          • #20
            Originally posted by Thetargos View Post
            Here's a wild suggestion. But what IF the Steam "protocol" (a la BitTorrent) could be added to "package kit"? Many distributions have shown interest in it as a unified "frontend" to different package managers. What if Steam could be handled just as another repo, with its own "protocol" (added to Package Kit, through a small package (.deb, .rpm, .tgz or ebuild) and using Steam accounts to download the content. This very same "steam" package could also include a library to identify Steam signed packages at run time to authenticate it (preferably off-line). But there is no telling how are they going to implement it.
            Great idea, but i dont think valve would allow it. Having people write their own 10000 different open source steam frontends written in gtk+ wouldnt sound good to them.

            Comment


            • #21
              Originally posted by xav1r View Post
              Great idea, but i dont think valve would allow it. Having people write their own 10000 different open source steam frontends written in gtk+ wouldnt sound good to them.
              Don't forget the 5 in QT, 3 in ncurses, and 1 in tk.

              Comment


              • #22
                And one in WinForms.NET just for the hell of it.

                Comment


                • #23
                  Originally posted by Aradreth View Post
                  Don't forget the 5 in QT, 3 in ncurses, and 1 in tk.
                  And the one in Fltk... >:-D

                  Comment


                  • #24
                    But still all would be using the same backend which in the end I would think is a good thing... Still, probably too much hassle for them to bother.

                    Comment


                    • #25
                      Originally posted by Thetargos View Post
                      But still all would be using the same backend which in the end I would think is a good thing... Still, probably too much hassle for them to bother.
                      Yea, I know. I agree with your idea, i think it'd be awesome, turning steam into some sort of downloading technology, (BT like), and having people write custom frontends for it, but i think valve likes to have centralized control of their steam clients.

                      Comment


                      • #26
                        ...and damn, that's right, i forgot about those. Didnt Trolltech got bought out by another company btw? So tcl and tk are from one company now, i think.

                        Comment


                        • #27
                          Except Tcl and Tk have nothing to do with Trolltech. Trolltech develop Qt, and Nokia own Trolltech now.

                          Comment


                          • #28
                            Originally posted by alex-weej View Post
                            And one in WinForms.NET just for the hell of it.
                            Originally posted by Svartalf
                            And the one in Fltk... >:-D
                            ... I knew I was opening a can of worms with that one. Oh can't forget Swing...

                            Personally I would hope someone would write a frontend completely in spl, that would warrant a read through.

                            Comment


                            • #29
                              ...And, there's always WxWidges , you know, for portability

                              Comment


                              • #30
                                Originally posted by Thetargos View Post
                                ...And, there's always WxWidges , you know, for portability
                                Heh... You're forgetting SWT, now...

                                Comment

                                Working...
                                X