Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 31

Thread: Update On The GOG Game Service For Linux

  1. #21
    Join Date
    Oct 2008
    Posts
    64

    Default

    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.

  2. #22
    Join Date
    Mar 2012
    Posts
    122

    Default

    Quote 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 syntax apt-get/apt-cache syntax description
    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

  3. #23
    Join Date
    Dec 2009
    Posts
    344

    Default

    Quote 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.

  4. #24

    Default

    Quote 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.

  5. #25
    Join Date
    Dec 2009
    Posts
    344

    Default

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

  6. #26

    Default

    Quote 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.

  7. #27
    Join Date
    Aug 2007
    Posts
    6,631

    Default

    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.

  8. #28
    Join Date
    Mar 2012
    Posts
    83

    Thumbs down 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.

  9. #29
    Join Date
    Jul 2009
    Posts
    33

    Default

    Quote 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.

  10. #30
    Join Date
    Nov 2009
    Posts
    379

    Default 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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •