Announcement

Collapse
No announcement yet.

Update On The GOG Game Service For Linux

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

  • shmerl
    replied
    And partial virtualization (containers like?) can help with running some older stuff probably.

    Leave a comment:


  • RealNC
    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
    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.

    Leave a comment:


  • dfx.
    replied
    Originally posted by vitiv View Post
    I am really courious on how Valve is going to pull it off, distribution wise, eg. package manager or self-conatined installer. I usually prefer the .sh installers because I mostly find myself installing games on one user as oposed to system-wide.

    That being said, I do understand the guys from GOG's concern, supporting such a huge userbase of distros is in no way a trivial task.
    Originally posted by Rigaldo View Post
    Or they could have some kind of client that installs games in its own folder, like ~/Games(or company name whatever) or /games. So it just needs to download a binary package of their favorite format and unpack. Library issue and breakage you say? Just pack the libraries you compiled with in your package, and it works in ANY Linux, voila. Correct me if I'm wrong, but wouldn't the last part solve breakage for programs?
    I've often read about it, but whatever binary I downloaded tended to work on multiple Ubuntu versions, Arch, Chakra, Fedora, etc. At least when it had it's needed libraries with it. So I thought BS whenever I read about such stuff ..
    and i don't prefer ".sh installers" and "installing games on one user". i even have 'noexec' on my /home and no desire for any binaries there, thank you very much. so, "I thought BS whenever I read about such stuff".
    ...BUT having their own game-launcing package managers (like Steam), that manage a particular subset of the file-system (like /opt/<manager-name>) is not a bad idea at all, actually. especially since there is not a lot of steps between game "store" app, and various multimedia "store" app, which those eventually will become.

    Leave a comment:


  • Almindor
    replied
    Packaging and testing

    I started a small company with the intent of packaging and testing commercial/closed source or even open source applications for the most wanted distributions. I even started to make an automated build/test system (sort of Jenkins-like but more for testing than just building), but whenever I contacted a potential customer (Humble Bundle, some indie game developers and others) their reaction was always "very interesting and we need it but it's too expensive for us for the Linux platform atm.".

    Go figure... well needless to say the company is dead now and I'm not resurrecting it. I wouldn't be surprised if I offered the same to GOG they would reply the same way as well. They all think it should be done for free or in other words "why pay for Linux testing and integration when Windblows and Mac are 'free'"

    Leave a comment:


  • Chewi
    replied
    Originally posted by [Knuckles] View Post
    Just wanted to add: think of deb and rpm and most other formats as zip/rar/tar.bz2. The issue is not the container, it's what you put in there, and how you get it to run across distros.
    Spot on, my thoughts exactly. Many of the older games are already bundled with DOSBox. Should they do that for Linux even though most distros have their own package for it? Should it be 32-bit? 64-bit? Static or bundled/unbundled shared libraries? PulseAudio support or plain ALSA? Do they provide GUI and/or console installers? Does the GUI installer use GTK+/Qt/whatever? Repeat all that again for newer games under Wine but also consider that Wine tends to suffer from regressions so the latest version may not always be best.

    Personally I hate bundling and think they're trying too hard. For the DOS games at least, the current downloads suit me fine. Until quite recently, the experience was very painful because they use the InnoSetup format, which was impossible to extract without Wine until InnoExtract came along. I started packaging some of the games with native Linux engines for Gentoo a while back and another user has been carrying that forward lately. It would be nice if distros could also package at least the non-native DOS games, which run very reliably under DOSBox. I can understand their reluctance to deal with Windows games but even those could potentially be put in a Gentoo overlay with a big fat warning. It's something I've thought about for some time but haven't had the motivation for.

    Leave a comment:


  • [Knuckles]
    replied
    Just wanted to add: think of deb and rpm and most other formats as zip/rar/tar.bz2. The issue is not the container, it's what you put in there, and how you get it to run across distros.

    Leave a comment:


  • [Knuckles]
    replied
    I just bought 4 games in a sale on GOG today to run with wine/custom engines (the HoMM series), it's nice to know I haven't misplaced my money. Who knows, maybe someday those will run properly on linux too.

    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:
    <snip>
    This is not the main issue. Actually you talk about the main issue: common system libraries that sometimes have to change their ABI (image libs, sound, X, ...).

    I think once you solve that, you can talk about a common packaging format. Otherwise, it really doesn't matter. You can already use alien to go from rpm to deb, and vice-versa, so if a package is done properly, you can convert, and it will work.

    Many times it won't work, exactly because of those library dependencies. So mucking around with the format of the packages and even the frontend application won't solve the issue.

    Leave a comment:


  • Detructor
    replied
    just use CPack. Your packaging problem just got solved. (at least that's what I heared...I'll be using that stuff in a few weeks (hopefully))

    Leave a comment:


  • Rigaldo
    replied
    Or they could have some kind of client that installs games in its own folder, like ~/Games(or company name whatever) or /games. So it just needs to download a binary package of their favorite format and unpack. Library issue and breakage you say? Just pack the libraries you compiled with in your package, and it works in ANY Linux, voila. Correct me if I'm wrong, but wouldn't the last part solve breakage for programs?
    I've often read about it, but whatever binary I downloaded tended to work on multiple Ubuntu versions, Arch, Chakra, Fedora, etc. At least when it had it's needed libraries with it. So I thought BS whenever I read about such stuff ..

    Leave a comment:


  • vitiv
    replied
    I am really courious on how Valve is going to pull it off, distribution wise, eg. package manager or self-conatined installer. I usually prefer the .sh installers because I mostly find myself installing games on one user as oposed to system-wide.

    That being said, I do understand the guys from GOG's concern, supporting such a huge userbase of distros is in no way a trivial task.

    Leave a comment:

Working...
X