It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
Community
General discussionAppimage of game distribution on Linux?(63 posts)(63 posts)
(63 posts)
Pages:
1
2
3
4
5
This is my favourite topic
Posted October 20, 2016
I was just wondering how other Linux users would feel about this? Games sold on GOG usually come packed with their own libraries anyway, so it seems to me appimages would be a bit more convenient than the Windows-like Mojo installers that are used here currently.

AppImages are basically .DMG files for Linux; you just download the file, mark it executable, and you're good to go! Link for more in-depth information below.

http://appimage.org/
Post edited October 20, 2016 by king_mosiah
Posted November 02, 2016
avatar
king_mosiah: I was just wondering how other Linux users would feel about this? Games sold on GOG usually come packed with their own libraries anyway, so it seems to me appimages would be a bit more convenient than the Windows-like Mojo installers that are used here currently.

AppImages are basically .DMG files for Linux; you just download the file, mark it executable, and you're good to go! Link for more in-depth information below.

http://appimage.org/
Well, I say that I think it'd be really great. However, when I asked over on reddit, people seemed to say that it was less buggy to keep it the way it is now.
Posted November 02, 2016
avatar
king_mosiah: I was just wondering how other Linux users would feel about this? Games sold on GOG usually come packed with their own libraries anyway, so it seems to me appimages would be a bit more convenient than the Windows-like Mojo installers that are used here currently.

AppImages are basically .DMG files for Linux; you just download the file, mark it executable, and you're good to go! Link for more in-depth information below.

http://appimage.org/
That's great except the three biggest distros use different methods.

Arch uses PacMan, Fedora uses DNF, and people who like month old leftovers or older enjoy apt.

Between those three, they all have different means of dependency revolvers.

Not all distros will have the required deps, and even worse ones don't allow i686/x64 to coexist in the same environment.

And as I've learned while trying to play with OpenRCT2's Linux distro, some .so files just straight up don't exist for certain distros. Like Libcrypto, even though I installed both i686 and x64 libssh files.
Post edited November 02, 2016 by Darvond
Posted November 02, 2016
Huh. Pretty cool; didn't know (or remember?) it existed such a thing. I, for one, would approve of a migration.

And as for distro support, the only distros GoG officially supports are the last two Ubuntu LTSs anyways, so if anything this has the potential of improving things further for people on lesser distros.
Posted November 02, 2016
avatar
king_mosiah: I was just wondering how other Linux users would feel about this? Games sold on GOG usually come packed with their own libraries anyway, so it seems to me appimages would be a bit more convenient than the Windows-like Mojo installers that are used here currently.

AppImages are basically .DMG files for Linux; you just download the file, mark it executable, and you're good to go! Link for more in-depth information below.

http://appimage.org/
avatar
djotaku: Well, I say that I think it'd be really great. However, when I asked over on reddit, people seemed to say that it was less buggy to keep it the way it is now.
Buggy? Anyway, there isn't much of a drawback over tarballs; since you can open an AppImage, if needed to remove/add a lib or make some other change.
avatar
king_mosiah: I was just wondering how other Linux users would feel about this? Games sold on GOG usually come packed with their own libraries anyway, so it seems to me appimages would be a bit more convenient than the Windows-like Mojo installers that are used here currently.

AppImages are basically .DMG files for Linux; you just download the file, mark it executable, and you're good to go! Link for more in-depth information below.

http://appimage.org/
avatar
Darvond: That's great except the three biggest distros use different methods.

Arch uses PacMan, Fedora uses DNF, and people who like month old leftovers or older enjoy apt.

Between those three, they all have different means of dependency revolvers.

Not all distros will have the required deps, and even worse ones don't allow i686/x64 to coexist in the same environment.

And as I've learned while trying to play with OpenRCT2's Linux distro, some .so files just straight up don't exist for certain distros. Like Libcrypto, even though I installed both i686 and x64 libssh files.
These are the problems addressed by appimages (or at least mitigated). The same appimage for Krita, for example, works with all my Arch, Fedora and Debian based boxes. Try it for yourself.

https://krita.org/en/download/krita-desktop/
Post edited November 02, 2016 by king_mosiah
Posted November 02, 2016
Oh! And unlike Flatpak and Snap, AppImage does not depend on systemd; if you're the type that cares about that sort of thing.
Post edited November 02, 2016 by king_mosiah
Posted November 02, 2016
I am personally very excited for AppImages! So far it's the fastest and easiest way to run third party applications that are not available in the distribution repositories. And it (more or less) works across all distributions.

It is different from Mac .dmg, though. The content of a .dmg file is an .app bundle that user moves to the Applications folder on user's Mac (which is something similar to Program Files folder on Windows). That way the application is installed locally in a officially supported path.

Instead of that, AppImage uncompresses the application on each run, which might make the application start considerably slower. This acts like portable applications known from Windows:
http://portableapps.com/about/what_is_a_portable_app
avatar
Darvond: [Some] (..) distros (..) don't allow i686/x64 to coexist in the same environment.
This is sadly a problem that AppImage doesn't solve and also a reason why we chose to use an installer that is started via a shell script.

Btw
avatar
Darvond: Arch uses PacMan, Fedora uses DNF, and people who like month old leftovers or older enjoy apt.
Shots fired! :)
Post edited November 02, 2016 by linuxvangog
Posted November 02, 2016
What's wrong with the scheme GOG currently uses?

I tried that subsurface appimage. It didn't run. I extracted it, and there are no executable elf files. Even if I tried to run them, the libraries wouldn't be found..

Sorry but I actually care about getting access to my games' files. And tinkering with them. Having to repackage them into some binary blob (only for it to extract them when you run the blob..) is a major inconvenience.
Posted November 02, 2016
avatar
Darvond: Arch uses PacMan, Fedora uses DNF, and people who like month old leftovers or older enjoy apt.
People who like the be free testers for an extremely buggy alpha version of Red Hat, use Fedora. :)

I mean seriously. I recall when I tried to use Fedora, it was almost impossible to use due to all the bugs. When it finally got relatively stable... they replaced it with another buggy release of Fedora (I presume that earlier stable Fedora became a Red Hat release then).

If one wishes to use a free Red Hat family distro, I presume CentOS is the way to go, not that awful Fedora. Stay away from it, it is highly carcinogenic.
Post edited November 02, 2016 by timppu
Posted November 02, 2016
Although it's nothing new, several have tried similarly paths with ordinary software, I think it's a great idea. Only problem is that Linux is too fragmented and everyone wants to have their own "thing".

Dependencies will always be a hazard zone unless they can agree on one standard. Prepackaging every single dependencies into every app could make it humongous.

And of course - if it's approved by the great LinusMan himself - then this is gonna be huge! "Thumbs up!"
Post edited November 02, 2016 by sanscript
Posted November 02, 2016
I could see it working for smallish apps whose internals nobody wants to tinker with.

It won't work so well for games that are multiple gigabytes in size and that you want to mod and tweak.
Posted November 02, 2016
avatar
linuxvangog: Instead of that, AppImage uncompresses the application on each run, which might make the application start considerably slower.
did you try and measure how much slower that actually is?

most modern file systems support on-the-disk compression, because it is usually said that decompression is faster than reading from the harddisk.

AppImage would have the other advantage that it works nicely together with firejail, allowing you to easily sandbox these untrusted binaries :p
Posted November 02, 2016
avatar
sanscript: Although it's nothing new, several have tried similarly paths with ordinary software, I think it's a great idea. Only problem is that Linux is too fragmented and everyone wants to have their own "thing".

Dependencies will always be a hazard zone unless they can agree on one standard. Prepackaging every single dependencies into every app could make it humongous.

And of course - if it's approved by the great LinusMan himself - then this is gonna be huge! "Thumbs up!"
The Krita AppImage is just under 80 Mb. Not that bad really.
avatar
linuxvangog: Instead of that, AppImage uncompresses the application on each run, which might make the application start considerably slower.
avatar
immi101: did you try and measure how much slower that actually is?

most modern file systems support on-the-disk compression, because it is usually said that decompression is faster than reading from the harddisk.

AppImage would have the other advantage that it works nicely together with firejail, allowing you to easily sandbox these untrusted binaries :p
On my desktop, it's about an extra second.
Post edited November 02, 2016 by king_mosiah
Posted November 02, 2016
avatar
immi101: did you try and measure how much slower that actually is?
No serious benchmarks, but with a timer, AppImages were considerably (a few seconds) slower. Using regular SATA hard drive, not a SSD.

avatar
immi101: most modern file systems support on-the-disk compression, because it is usually said that decompression is faster than reading from the harddisk.

(...)
Is ext4 modern? :)
Post edited November 02, 2016 by linuxvangog
Posted November 02, 2016
avatar
clarry: What's wrong with the scheme GOG currently uses?

I tried that subsurface appimage. It didn't run. I extracted it, and there are no executable elf files. Even if I tried to run them, the libraries wouldn't be found..

Sorry but I actually care about getting access to my games' files. And tinkering with them. Having to repackage them into some binary blob (only for it to extract them when you run the blob..) is a major inconvenience.
The problem is that the current Subsurface appimage is whoever put it together added some libs that should be blacklisted, so it causes problems on Arch and Suse based distros. Try the Krita or Kdenlive appimages and see how they work.
Pages:
1
2
3
4
5
This is my favourite topic
Community
General discussionAppimage of game distribution on Linux?(63 posts)(63 posts)
(63 posts)