Announcement

Collapse
No announcement yet.

Update On The GOG Game Service For Linux

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

  • ownagefool
    replied
    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

    Leave a comment:


  • glasen
    replied
    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.

    Leave a comment:


  • shmerl
    replied
    Look at the thread name and proposal text itself and various discussions in that wishlist item. The proposal says:
    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.
    That was always implicitly understood that the main point of this are native Linux games. Anyone can already take DosBox game from GOG, unpack it and use (with some config tweaks may be). Or run some Windows game which is compatible with Wine. There is literally zero input required from GOG for it. The whole point of that wishlist entry is asking GOG to start shipping games which provide native Linux builds.

    Leave a comment:


  • glasen
    replied
    As far as i can see the representative of GOG just wrote that they are evaluating ways to ensure that GOG-games can be as easily installed and run as on Windows. There is absolutely no single word about native Linux games.

    Leave a comment:


  • shmerl
    replied
    You didn't follow the discussion. The issue is about GOG adding native Linux games and supporting them. DosBox and etc. are not an issue.

    Leave a comment:


  • glasen
    replied
    I don't understand what your problem is. Most of the games from GOG are old Windows 95-games or even older DOS-games. All DOS-games (e.g. "Wing Commander 3") come with a bundled version of DOSBox because it is the only possible way to play these old games on a modern Windows system (There is no 16bit sub-system in all 64bit versions of Windows any more).

    So why discuss about packaging managers or system libraries? None of these game will ever be ported to Linux (Okay for some of them a Linux binary client exist), so the only possible way to run them on Linux is to use some emulator. This means DOSBox for DOS-games or Wine for Windows-games. There is no other way.

    All GOG has to do is bundle the games with Wine or DOSBox and ensure they will run flawlessly on the most common Linux-distributions (Means Fedora, OpenSuSE and Ubuntu). And to ensure everybody can install them, they should use the installer the Humble Indie Bundle uses for their game. This installer is brain dead easy to use and even allows to register the game in the distributions package manager to allow easy uninstalling of the game via the package manager.

    And if you crying know "What is with the dependencies of Wine or DOSBox?"

    There are plenty of examples of programs which come bundled with a custom version of Wine (e.g. "TeamViewer") and run perfectly on a bunch of distributions without any problems. And DOSBox is very easy to compile as a static binary (Only one file) so there is no need for some libraries.

    Leave a comment:


  • yogi_berra
    replied
    Originally posted by RealNC View Post
    Nope. Instead, use installers that come bundled with all needed libraries. No dependency tracking. Just like they do for Windows. You get an *.exe, you run it, the game and the DLLs it needs get installed. It's the only sane way to deal with the madness of non-standardized software installation between distros.
    Nah, that makes sense, it will never fly on linux.

    Leave a comment:


  • disi
    replied
    I wonder if they officially work together with PlayOnLinux?
    PlayOnLinux is available on every major distribution.

    To install a game:
    1. look up the game in the PlayOnLinux database to make sure there are installation scripts for it
    2. buy the game on the GOG website
    3. in PlayOnlinux and click install for the game
    4. enter your GOG credentials
    5. it will be downloaded/installed with a corresponding wine version which is known to work with the title
    6. click play


    OK, it is not native Linux but you know how weird companies are with their source code and how much money they want for old titles or sue private people who recreate a game on Linux (worst companies to name just one: Blizzard)

    Leave a comment:


  • M1AU
    replied
    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.
    Yes, please do it.

    Leave a comment:


  • [Knuckles]
    replied
    Originally posted by shmerl View Post
    And partial virtualization (containers like?) can help with running some older stuff probably.
    Yeah. We've been further from just providing a virtual machine image with minimal linux distro + supported stuff + wine or whatever.
    Cross-platform, and it will always work.

    Leave a comment:

Working...
X