Announcement

Collapse
No announcement yet.

Update On The GOG Game Service For Linux

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

  • #21
    If a game has a Linux version and it is made and supported by the developer please allow the option to download the Linux version if at all possible.
    For those games which have a native Linux version, GOG can use the "Humble Indie Bundle"-way, providing at least and tgz-archive in the download-center. All Humble Indie Bundle games are packaged so that they can run on a bunch of distributions.

    See for example Torchlight:

    This game runs flawlessly on Ubuntu, Fedora and OpenSuSE. And this game is not a small SDL-based 2D-game. And all HIB provides is a single installer-package which includes all necessary binaries and libraries (Those who are not commonly provided by the distribution. In this case libOGRE).

    Today distributions are no comparison to the ones a few years ago. Inter-distribution-compatibility is much better than people commonly think. There are many applications which run flawlessly an all different kind of distributions even if they where only tested or certified for a single one.

    The biggest problem today is to run an old binary-only Linux-games or applications on a modern distribution. But modern applications or games are not a big problem.

    Comment


    • #22
      Originally posted by Ericg View Post
      I know this discussion is going to end up here anyway so im just trying to be ahead of the curve... standardization of packages on the linux desktop?

      Format: RPM
      Frontend: PackageKit


      Justification:

      1) PackageKit-- distro agnostic, backend agnostic (packagekit can even hook into pacman for christs sake)

      2) RPM-- I know people get really up in arms about RPM vs Deb but my personal vote goes to RPM because Enterprise already does RPM (RHEL + CentOS) and you can do delta packages. Maybe delta's are more an issue of apt-get vs yum but under Debian you download the whole new package, under Fedora you only get the binary difference. I like delta's.

      I realize because of Ubuntu that .deb has kind of become 'the standard' for desktop but really it'll probably come down to punching match between Red Hat and Canonical then between RPM and Deb since Ubuntu has desktop and Red Hat has enterprise unless by some miracle they can come together and settle on a package format and package manager (again..yum..please. yum search is so much saner than apt-cache search).

      For libraries either run statics, supply them yourself, or have distros package all versions of a libraries wherein there was an ABI break so that we can just run stuff across the board as long as its ABI compatibile (obviously if there was an API break then its an ABI break too) this way when you install the package it just pulls in the library dependencies it needs from the repos


      disclaimer: no, I'm not one of those "We need a stable kernel interface! Backwards compatibilty for 20years!" guys, or even release to release. I actually have no problem breaking BC, but if they are going to mandate specific library versions then thats probably the best way to do it.
      Aptitude was at a time the recommended package manager for debian (because of technological advantages over apt-get) but I believe they don't care what you use now. If the main reason you prefer yum over apt is because you find yum more usable, you'd probably be happier with aptitude over apt on a debian based system.

      aptitude update apt-get update update package archive metadata
      aptitude install foo apt-get install foo install candidate version of "foo" package with its dependencies
      aptitude safe-upgrade apt-get upgrade install candidate version of installed packages without removing any other packages
      aptitude full-upgrade apt-get dist-upgrade <package> install candidate version of installed packages while removing other packages if needed
      aptitude remove foo apt-get remove foo remove "foo" package while leaving its configuration files
      N/A apt-get autoremove remove auto-installed packages which is no longer required
      aptitude purge foo apt-get purge foo purge "foo" package with its configuration files
      aptitude clean apt-get clean clear out the local repository of retrieved package files completely
      aptitude autoclean apt-get autoclean clear out the local repository of retrieved package files for outdated packages
      aptitude show foo apt-cache show <package> display detailed information about "foo" package
      aptitude search <regex> apt-cache search <regex> search packages which match <regex>
      aptitude why <regex> N/A explain the reason why <regex> matching packages should be installed
      aptitude why-not <regex> N/A explain the reason why <regex> matching packages can not be installed

      Comment


      • #23
        Originally posted by glasen View Post
        For those games which have a native Linux version, GOG can use the "Humble Indie Bundle"-way, providing at least and tgz-archive in the download-center. All Humble Indie Bundle games are packaged so that they can run on a bunch of distributions.

        See for example Torchlight:

        This game runs flawlessly on Ubuntu, Fedora and OpenSuSE. And this game is not a small SDL-based 2D-game. And all HIB provides is a single installer-package which includes all necessary binaries and libraries (Those who are not commonly provided by the distribution. In this case libOGRE).

        Today distributions are no comparison to the ones a few years ago. Inter-distribution-compatibility is much better than people commonly think. There are many applications which run flawlessly an all different kind of distributions even if they where only tested or certified for a single one.

        The biggest problem today is to run an old binary-only Linux-games or applications on a modern distribution. But modern applications or games are not a big problem.
        Yep, that was the whole point. To encourage GOG to include native Linux games in their catalog. Torchlight from "Humble Indie Bundle" is a beautiful packaging and implementation example. But I think they worry about what you wrote last - that with ABI and API changes, their games might start breaking at some point on latest distributions. Another use case. What if they ship a game for X, and the distro switches to Wayland (the switch will be coming to everyone at some point in the future)? Just something to consider. Even though it all might be solvable, but it'll require some investment of their resources. So they are hesitant yet.

        Comment


        • #24
          Originally posted by ownagefool View Post
          If the main reason you prefer yum over apt is because you find yum more usable, you'd probably be happier with aptitude over apt on a debian based system.
          The main reason I prefer Fedora's packaging system over Debian systems' is because it doesn't treat 64-bit x86 like it's a completely different architecture. Debian's 32-bit compatibility libraries (and all the installation issues for programs that were 32-bit only) all came from a retarded decision about the file system, that 64-bit libraries should go in /usr/lib and 32-bit libraries should be moved to /usr/lib32.

          Let's screw compatibility for fun, just because we think that /usr/lib needs to represent the preferred ABI. Well, that and they didn't want to make a special case in their tools for x86_64 (never mind the existence of the /usr/lib32 directory...). If they had followed the FHS and LSB standard, all the Debian distros ought to have been able to use the existing 32-bit library packages directly, at least eventually. Then, 32-bit application support wouldn't have been limited to the nearly worthless ia32-libs.

          As for everything else related to these formats and systems, rpm vs deb, yum vs apt, they're the same. The UI may be different, but I haven't noticed any major differences in their capabilities.

          For GOG, I imagine there are some legitimate compatibility concerns (e.g. can a glibc ABI change cause the program binary to break?), but I'd be curious if they're mostly daunted by the number of Linux distros and how many setups they might need to replicate in order to provide support.

          Comment


          • #25
            Debian already introduced multiarch, which is a good and flexible approach: http://wiki.debian.org/Multiarch

            Comment


            • #26
              Originally posted by shmerl View Post
              Debian already introduced multiarch, which is a good and flexible approach: http://wiki.debian.org/Multiarch
              Of course. I haven't tried a Debian-based distro since Ubuntu 12.04 came out, but in April, multiarch still wasn't fully-realized. There were still many packages to be converted; meanwhile, the lack of good 32-bit support continued.

              In the past, this was the most common show stopper for the users close to me--They would have some 32-bit application or userspace driver (usually for a printer) that could not install due to an unavailable library. Once that happened, Linux usually got too intimidating.

              (As an aside, the most common usability issues for Fedora were usually due to the X.org release being too new for proprietary driver support or due to something SELinux-related. You just need to add "check for interference from SELinux" after "check the firewall." But it's a MAC implementation--It's not doing its job if it doesn't get in the way! )

              It will be water under the bridge after this development is complete. The spec is interesting, and if it works out well, hopefully the file system changes will get blessed and picked up by other distros.

              Comment


              • #27
                Multiarch is not always unproblematic, it introduces some stupid side affects as well. Especially when you try to install i386 binary only printer drivers (like those funny ones from brother). Then you get extra depends of i386 packages which can hurt the system during updates (which are btw. not even really needed - you could hack the package to be "all" and use it without). I also did not manage to compile wine (32 bit) on wheezy/multiarch yet - i dislike using a chroot for that part (i also wanted to compile doom3 gpl 32bit as well but did not succeed). It can solve problems but introduces new ones. Maybe it is better with rpm based systems as they switched earlier.

                Comment


                • #28
                  Dissapointed

                  Well, finally GoG had its October event and the news is that Linux will not be supported in the near future.

                  What a bullshit.

                  MAC version had a barely 1000 votes request vs a 7000 plus Linux one.

                  Even Desura and Humble Bundle that were smaller have the balls to be on Linux.

                  I'm very dissapointed.

                  Comment


                  • #29
                    Originally posted by DebianLinuxero View Post
                    Well, finally GoG had its October event and the news is that Linux will not be supported in the near future.

                    What a bullshit.

                    MAC version had a barely 1000 votes request vs a 7000 plus Linux one.

                    Even Desura and Humble Bundle that were smaller have the balls to be on Linux.

                    I'm very dissapointed.
                    I believe it comes down to numbers, they (GOG/CDPROJEKTRED) believe that linux users wont pay like mac users will, one could argue this evidence is born out via Apple App store vs the Android One, more apps on the Android store yet studies claim most of the apps for sale are being actively pirated, while on the Apple store less apps but apple users are buying them in droves with little to no piracy. So take a chance on an unknown Operating System (for them) that may see their games completely pirated or one thats guarranteed profit.
                    I know we can argue that the Humble Indie Bundles/Desura etc sell a lot of games to linux users but they arent looking at that, we will have to wait for Steam for Linux before we see GOG/CDPROJEKTRED wetting their feet in the Linux pool. And remember also Steam did the samething they debuted for Mac before they officially announced Linux Support.

                    Comment


                    • #30
                      MAC hrhr

                      Pay What You Want for Interplay Games, GOG goes Mac, and other great news from our Conference.

                      They even send bloody advertisement to Linux customers

                      Who is actual using Apple computers? I know a lot of people with those brick-phones, while I use a small handy one from Sony.
                      I have yet to find one of those people who really do use and have Apple products... they must be concentrated in the USA?

                      Comment

                      Working...
                      X