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

×
avatar
king_mosiah: Flatpak
avatar
clarry: Documentation is too sparse and I cannot be arsed to read the source right now but it looks nasty and doesn't seem to solve any problem I have. But again it does seem to introduce the problem that AppImage has, namely that now I need more tools and steps to tweak the files.

and Snaps
avatar
clarry: Compressed and read-only, it seems to have exactly the same problems that AppImage has.

All three are introducing problems for me and not solving one I have. Apparently they could solve one problem for you, namely having to run an installer before playing a game. Is that such a major problem?
So the only problem you have is that it makes it harder for you to get to the data files on a non-linux system?
Post edited November 02, 2016 by king_mosiah
avatar
king_mosiah: So the only problem you have is that it makes it harder for you to get to the data files on a non-linux system?
You're really good at ignoring whatever I write :(

No, I really want to modify the contents of a game installation on a Linux system too.

And I really don't want to make bad performance tradeoffs.

Yes I do also want to access the data files on non-linux systems.

The installer isn't sexy, but it works and doesn't really create any problems for me. The things you are proposing would.

EDIT: Another problem I just realized is that these application containers are for a single application. As it is gog is distributing installers that install multiple applications, e.g. game client, game server, configuration tool, etc. I can easily run whichever I want. And GOG can include launcher shurtcuts for all of them, including shortcuts for the same binary with different command line options.

With these single-application containers, they'd have to break these binaries into multiple containers (potentially duplicating all game data..), *or* they'd have to create custom launchers (the "single app") that execs one of the binaries in the container. How are such launchers going to be less sexy than a windows-like installer?
Post edited November 02, 2016 by clarry
avatar
king_mosiah: So the only problem you have is that it makes it harder for you to get to the data files on a non-linux system?
avatar
clarry: You're really good at ignoring whatever I write :(

No, I really want to modify the contents of a game installation on a Linux system too.

And I really don't want to make bad performance tradeoffs.

Yes I do also want to access the data files on non-linux systems.

The installer isn't sexy, but it works and doesn't really create any problems for me. The things you are proposing would.
Appimage Flatpak and Snap would not stop you from modding your game. As far as I can tell Flatpak, at the very least, has no real performace tradeoffs. And finally, it is not the fault of any of these formates that BSD has no utilities for at least extracting them; They're all F/OSS, and nothing is stopping anyone from making a utility to do so.

The point you make in your edit is moot though, since there is no Galaxy client on Linux.
Post edited November 02, 2016 by king_mosiah
avatar
king_mosiah: As far as I can tell Flatpak, at the very least, has no real performace tradeoffs
Well if you understand it as well as you appear to understand AppImage, then I'd wait for a more authoritative source. Why is the documentation so bad anyway?

How does flatpak solve the problem of games with multiple binaries and command line options? This has nothing to do with Galaxy.

Nothing can stop me from modding my games. A lot of things can make it harder and more time consuming, which I do not welcome. You are just proposing to make life harder for me so you don't have to run an installer. And then you'll have to run custom launchers.
Post edited November 02, 2016 by clarry
avatar
king_mosiah: As far as I can tell Flatpak, at the very least, has no real performace tradeoffs
avatar
clarry: Well if you understand it as well as you appear to understand AppImage, then I'd wait for a more authoritative source. Why is the documentation so bad anyway?

How does flatpak solve the problem of games with multiple binaries and command line options?

Nothing can stop me from modding my games. A lot of things can make it harder and more time consuming, which I do not welcome.
Wow, you're getting snippy... Flatpaks are going to be handled by GUI frontends like Gnome Software and KDE's new "app store". So there's no need to use the CLI, and I see no reason why Galaxy could not do the same.
Post edited November 02, 2016 by king_mosiah
Personally, I'm rather fond of the current mojo installers. The previous tarballs were good too, but the mojo installer allows for incremental updates, which I'm a big fan off.

I'll agree with clarry, AppImage seems like a solution to a problem that no one has. If all we're talking about here is bundling library files in the AppImage, what is stopping GOG from bundling the same library files in the mojo installer. Nothing, that's what.
avatar
king_mosiah: Wow, you're getting snippy (dislike of change is rather typical of BSD users I find). Flatpaks are going to be handled by GUI frontends like Gnome Software and KDE's new "app store". So there will be no need to use the CLI; and I see no reason why Galaxy could not do the same.
Wow. I find it bizarre that we both agree the current installers aren't sexy, but then you would propose another disgusting GUI frontend solution to problems introduced by your solution for getting rid of the installer.

Basically your problem is that you hate red, you prefer blue, so you want to make things blue, and also make my life hard in the process.

avatar
hummer010: If all we're talking about here is bundling library files in the AppImage, what is stopping GOG from bundling the same library files in the mojo installer. Nothing, that's what.
Exactly (and library files & other stuff are already bundled with games, as has been pointed out). Actually the problem seems to be that king_mosiah doesn't like the installer and would rather look at some gnome/kde app store.
Post edited November 02, 2016 by clarry
avatar
king_mosiah: Wow, you're getting snippy (dislike of change is rather typical of BSD users I find). Flatpaks are going to be handled by GUI frontends like Gnome Software and KDE's new "app store". So there will be no need to use the CLI; and I see no reason why Galaxy could not do the same.
avatar
clarry: Wow. I find it bizarre that we both agree the current installers aren't sexy, but then you would propose another disgusting GUI frontend solution to problems introduced by your solution for getting rid of the installer.

Basically your problem is that you hate red, you prefer blue, so you want to make things blue, and also make my life hard in the process.

avatar
hummer010: If all we're talking about here is bundling library files in the AppImage, what is stopping GOG from bundling the same library files in the mojo installer. Nothing, that's what.
avatar
clarry: Exactly. Actually the problem seems to be that king_mosiah doesn't like the installer and would rather look at some gnome/kde app store.
Y'know, ultimately it's not our problem you choose to run BSD; it's yours. And are you just ignoring the part where I mentioned that Galaxy could manage Flatpaks?
Post edited November 02, 2016 by king_mosiah
avatar
king_mosiah: Y'know, ultimately it's not our problem you choose to run BSD; it's yours.
You're setting up a straw man and hanging on to an irrelevant detail. Right now I'm on a Linux laptop, but again it's none of your business.

And are you just ignoring the part where I mentioned that Galaxy could manage Flatpaks?
The solution GOG has chosen works independent of a desktop environment, a third party gui frontend, or galaxy. I'm happy with the situation. I don't want Galaxy, and indeed it doesn't exist for Linux as you said.

You're just constantly proposing that I be forced to use crummy tools to deal with problems your solution introduces.
avatar
hummer010: Personally, I'm rather fond of the current mojo installers. The previous tarballs were good too, but the mojo installer allows for incremental updates, which I'm a big fan off.

I'll agree with clarry, AppImage seems like a solution to a problem that no one has. If all we're talking about here is bundling library files in the AppImage, what is stopping GOG from bundling the same library files in the mojo installer. Nothing, that's what.
The advantage of AppImage is the lack of an install process; the advantage of Flatpak would be security.
avatar
king_mosiah: Y'know, ultimately it's not our problem you choose to run BSD; it's yours.
avatar
clarry: You're setting up a straw man and hanging on to an irrelevant detail. Right now I'm on a Linux laptop, but again it's none of your business.

And are you just ignoring the part where I mentioned that Galaxy could manage Flatpaks?
avatar
clarry: The solution GOG has chosen works independent of a desktop environment, a third party gui frontend, or galaxy. I'm happy with the situation. I don't want Galaxy, and indeed it doesn't exist for Linux as you said.

You're just constantly proposing that I be forced to use crummy tools to deal with problems your solution introduces.
Again, there is no need to get hot under the collar about this. You wan't Mojo? Fine. I never said GOG should do away with Mojo (I don't understand why they had to do away with tarballs). Why not do what Humble does? Allow the publisher the option of offering various other formats; GOG could even mandate having a Mojo installer as the minimum requirement. That way everyone could (potentially) be happy.
Post edited November 02, 2016 by king_mosiah
avatar
king_mosiah: The advantage of AppImage is the lack of an install process;
How is that advantageous? I'd rather decompress once, and not at every runtime.
avatar
king_mosiah: The advantage of AppImage is the lack of an install process;
avatar
hummer010: How is that advantageous? I'd rather decompress once, and not at every runtime.
Same here. The AppImage concept is great for portability, but in the end it's just another wrapper to what one wants to get out of an installer/package/archive: the actual game files and nothing else.

I think the current Mojo installers offer a good compromise - you can just unzip them if you don't want to bother with the installation process or you can just run them as intended if you're not a power user.
avatar
king_mosiah: The advantage of AppImage is the lack of an install process;
avatar
hummer010: How is that advantageous? I'd rather decompress once, and not at every runtime.
Not to mention that this wouldn't really be healthy for things bigger than say...a gigabyte.
avatar
Darvond: And even the current installer isn't perfect, as I found out with Little Inferno requiring some i686 deps. (Resolved, thankfully.) I know that one can use the ldd command in order to check and see what libraries/so files are required. I wonder if GOG can/has implemented such a thing?
(...)
If the game needs extra dependencies we always put that information in the system requirements field of the game, see here for Little Inferno:
https://www.gog.com/game/little_inferno

That solution is obviously far from perfection (as we use only names of Ubuntu packages, and it puts a bit of extra effort on the user).

The problem is, Linux is still fresh grounds for many game developers and often they don't know they can satisfy dependencies by putting needed libraries in the game folder or that they should produce a 64 bit binary. And what to do about old games, that were compiled years ago only with 32 bit in mind? Or with game engines that don't offer 64 bit support, such as Game Maker?

And shipping the libraries with the game by GOG might sometimes prove problematic, as it causes compatibility issues (that's why we stopped doing so for some time already).

There are situations where you cannot avoid installing extra dependencies on the user's side. We are actively investigating possible ways of fixing that problem.

RE: AppImages

As many of you noticed, AppImages have their own disadvantages.

I believe they are not suitable for shipping games, at least not in the current shape and surely not for DOSBox or Wine titles, or any other games that require ability to write files in the game folder.

We're gonna stick with installers in the foreseeable future.
Post edited November 03, 2016 by linuxvangog
avatar
linuxvangog: As many of you noticed, AppImages have their own disadvantages.

I believe they are not suitable for shipping games, at least not in the current shape and surely not for DOSBox or Wine titles, or any other games that require ability to write files in the game folder.

We're gonna stick with installers in the foreseeable future.
Ah yes, it's not just me who wants to mod and tweak game configs, it's the games themselves.

I'm glad to know we came to the same conclusion. The blue penguins really have done their homework :-)