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
clarry: I know this is in vain. But there. If only for fun.

http://www.gog.com/wishlist/site/bring_back_tar_balls
Just voted. :-)
avatar
clarry: I know this is in vain. But there. If only for fun.

http://www.gog.com/wishlist/site/bring_back_tar_balls
In the mean time:

gog script to tar.gz converter

example: Shadowrun Dragonfall: gog_shadowrun_dragonfall_director_s_cut_2.6.0.10.sh
usage: ./gogzcnv.sh gog_shadowrun_dragonfall_director_s_cut_2.6.0.10.sh

https://pastee.org/6rjzj

WYSIWYG:

- creates an gog_shadowrun_dragonfall_director_s_cut_2.6.0.10.tar.gz tarball
- root dir is "shadowrun_dragonfall_director_s_cut"
- pure shell script... BUT "unzip" must be installed (if you haven't already done so)
- if you want multi-core compression, install "pigz" - enables itself by default if available
- output is quite similar to the abandoned tar.gz files
avatar
linuxvangog: Guys, if you REALLY want to unpack it without running the installer, someone already explained how to do that in this thread. But I can assure you this is certainly NOT the supported way of installing our games from now on and if you do that we CANNOT guarantee that everything will work without problems.
avatar
eiii: Do you at least test and guarantee that the game works when it is installed* with one user (e.g. a dummy system user) and run as a different ("normal") user later?

Edit: *installed as installed with your official Linux installer
i think there are just a lot of games where a system-wide installation for multiple users does not work.
Especially all those old DOS games who just dump their savegames and settings into the installation folder. But even some of the newer linux games work like this.
I never really looked into the DOS games packaged for linux from GOG, but I don't see how you want to make those work with per-user settings & savegames. Unless you go as far as ssokolow and look into filesystem overlays/redirection or do a lot of symlinking. Which imo is just not worth the time and effort.
And a game installed into the system where the (normal) user doesn't have write access, just gets annoying once you start to look into modding ;)
i personally think treating games as personal data and throwing them into $HOME works just fine.

And since all the licenses we get here are personal, single-user licenses anyway i don't really see the necessity of a guarantueed working multi-user setup.

just my 0,02€
avatar
ssokolow: My decision to remove write permissions from game folders after install is completed and symlinking any bits they complain about into $HOME for backup is already outside the range of supported installation configurations. (And I HAVE discovered some games which simply refuse to work in that configuration. As soon as I have time, I'll be looking into whether Ubuntu kernel builds include any overlay filesystems I could use to get the last laugh.)
avatar
vv221: I think you already know I do something similar with my ./play.it project.
Could you please explain the method you use on your side? (be it here or in the ./play.it dedicated thread)

Comparing methods to take the best of both is usually how I improve my scripts ;)
Since most of my native games are OK with being installed read-only, I just manually unpack them, change them to "root:root 644 or 755" ownership and permissions, and see if anything breaks.

I didn't want to throw too much effort at a solution which will eventually be replaced by an overlay filesystem to properly support finicky games and DOSBox games.
avatar
eiii: Do you at least test and guarantee that the game works when it is installed* with one user (e.g. a dummy system user) and run as a different ("normal") user later?

Edit: *installed as installed with your official Linux installer
avatar
immi101: i think there are just a lot of games where a system-wide installation for multiple users does not work.
Especially all those old DOS games who just dump their savegames and settings into the installation folder. But even some of the newer linux games work like this.
I never really looked into the DOS games packaged for linux from GOG, but I don't see how you want to make those work with per-user settings & savegames. Unless you go as far as ssokolow and look into filesystem overlays/redirection or do a lot of symlinking. Which imo is just not worth the time and effort.
And a game installed into the system where the (normal) user doesn't have write access, just gets annoying once you start to look into modding ;)
i personally think treating games as personal data and throwing them into $HOME works just fine.

And since all the licenses we get here are personal, single-user licenses anyway i don't really see the necessity of a guarantueed working multi-user setup.

just my 0,02€
It works, it's just that there's things that GOG would have to do to make make it work. Probably something like unionfs mounted over the top of the installation directory would be the easiest fix. It would mean that you absolutely could not use the same game by different people at the same time, but it would work.

There's also solutions to the problem involving hard links and profile specific copies that would probably also work.
avatar
immi101: i think there are just a lot of games where a system-wide installation for multiple users does not work.
Especially all those old DOS games who just dump their savegames and settings into the installation folder. But even some of the newer linux games work like this.
I never really looked into the DOS games packaged for linux from GOG, but I don't see how you want to make those work with per-user settings & savegames. Unless you go as far as ssokolow and look into filesystem overlays/redirection or do a lot of symlinking. Which imo is just not worth the time and effort.
And a game installed into the system where the (normal) user doesn't have write access, just gets annoying once you start to look into modding ;)
i personally think treating games as personal data and throwing them into $HOME works just fine.

And since all the licenses we get here are personal, single-user licenses anyway i don't really see the necessity of a guarantueed working multi-user setup.

just my 0,02€
avatar
hedwards: It works, it's just that there's things that GOG would have to do to make make it work. Probably something like unionfs mounted over the top of the installation directory would be the easiest fix. It would mean that you absolutely could not use the same game by different people at the same time, but it would work.

There's also solutions to the problem involving hard links and profile specific copies that would probably also work.
as I said, of course you can make it work somehow by jumping through several hoops. It is just a considerable amount of additional work. Considering that there hardly is any use-case where you really need a working multiuser setup, i don't think it is worth the effort. I rather get my linux installer quicker and without any complicated setup.
For me the best case scenario would be where every game is just a self-contained, portable folder, that I just need to unzip and be ready.

side note: using a non-upstream kernel feature like unionfs isn't really a working solution for the installer, i think. There is overlayfs in new-ish kernels which supposedly can do the same. But I haven't tried that yet.
@ssokolow
though you might want to check that out. It might do what you want for your sandboxing
Post edited August 16, 2015 by immi101
avatar
immi101: i think there are just a lot of games where a system-wide installation for multiple users does not work.
It's not about multi-user installation, but about privilege separation. And so far this has to work for all games were a .deb package has been provided. You just have to set the permissions on selected files or directories correctly in the package. This was not perfect, but a lot better than the new method which probably sets anything to be writable by the user which also executes the game. This widely opens the door for all kinds of malicious attacks.

With the new installer the information which files need to be writable probably gets lost and GOG leaves us alone to find that out when they do not support installation with one user and use as another user.

avatar
immi101: Especially all those old DOS games who just dump their savegames and settings into the installation folder. But even some of the newer linux games work like this.
DOS did not know any better (and therefore got it's pile of worms and viruses). But newer Linux games, that's a shame. Any examples for that?

avatar
immi101: I never really looked into the DOS games packaged for linux from GOG, but I don't see how you want to make those work with per-user settings & savegames. Unless you go as far as ssokolow and look into filesystem overlays/redirection or do a lot of symlinking. Which imo is just not worth the time and effort.
Agreed. It's OK for me when old games can only be used sensibly by one user. What bothers me is when the user which runs the game also can overwrite it's installation.

avatar
immi101: And a game installed into the system where the (normal) user doesn't have write access, just gets annoying once you start to look into modding ;)
You just have to do the modding with the same user you have used to install the game. Modding is a kind of installation process, not normal game usage.

avatar
immi101: i personally think treating games as personal data and throwing them into $HOME works just fine.
There's another reason why I don't like that, backups. Game installations can be quit big, so they either blow up your backup unnecessarily or you have to exclude the directories manually from the backup, which is tedious and error prone. That's also the reason why I want saved games to be separated from the game installation as there's no need to back up your game installation, but of course I want to back up my saved games.

avatar
immi101: And since all the licenses we get here are personal, single-user licenses anyway i don't really see the necessity of a guarantueed working multi-user setup.
I don't know if the license is bound to the user which has installed the game or to the PC where the game is installed. But that doesn't matter for me as my goal is not multi-user usage but privilege separation.
avatar
hedwards: It works, it's just that there's things that GOG would have to do to make make it work. Probably something like unionfs mounted over the top of the installation directory would be the easiest fix. It would mean that you absolutely could not use the same game by different people at the same time, but it would work.

There's also solutions to the problem involving hard links and profile specific copies that would probably also work.
avatar
immi101: side note: using a non-upstream kernel feature like unionfs isn't really a working solution for the installer, i think. There overlayfs in new-ish kernels which supposedly can do the same. But I haven't tried that yet.
That surprises me seeing as that's what they use with those Live CDs, it seems odd to me that it wouldn't be in the kernel.

Anyways, Linux is a multiuser and multitasking OS, it seems crazy to me that the games here haven't been set up to handle that.
avatar
immi101: i think there are just a lot of games where a system-wide installation for multiple users does not work.
avatar
eiii: It's not about multi-user installation, but about privilege separation. And so far this has to work for all games were a .deb package has been provided. You just have to set the permissions on selected files or directories correctly in the package. This was not perfect, but a lot better than the new method which probably sets anything to be writable by the user which also executes the game. This widely opens the door for all kinds of malicious attacks.
hmm, i don't really see any dangerous attack vector. at least not on a standard desktop pc that is basically used by a single user. What exactly can happen when the user can overwrite the game files? The game executable doesn't do anything critically, so I don't see how it could lead to an privilege escalation. All you can do is execute some code with the rights of the user. But then, you already could do that at the point when you modified the game, right?

If an attacker can place some malicious code under your user account, your account is already compromised anyway. Having write access to a game won't make that any worse.
Unless I am missing something here?

avatar
immi101: Especially all those old DOS games who just dump their savegames and settings into the installation folder. But even some of the newer linux games work like this.
avatar
eiii: DOS did not know any better (and therefore got it's pile of worms and viruses). But newer Linux games, that's a shame. Any examples for that?
Kerbal Space Programm

avatar
immi101: i personally think treating games as personal data and throwing them into $HOME works just fine.
avatar
eiii: There's another reason why I don't like that, backups. Game installations can be quit big, so they either blow up your backup unnecessarily or you have to exclude the directories manually from the backup, which is tedious and error prone. That's also the reason why I want saved games to be separated from the game installation as there's no need to back up your game installation, but of course I want to back up my saved games.
I absolutely agree that this is a nice feature. I just don't think that we can expect that gog will develop such a solution for games where this doesn't work out-of-the-box. In the end they are just the distributor, not the game developer. Demanding a guarantee that things like that will always work in their installer seems unfair to me.

avatar
hedwards: That surprises me seeing as that's what they use with those Live CDs, it seems odd to me that it wouldn't be in the kernel.
live cds usually have a custom kernel. But when making an installer that you want to work in as many environments as possible it's just not a good idea to rely on a feature that is not a standard kernel component.

avatar
hedwards: Anyways, Linux is a multiuser and multitasking OS, it seems crazy to me that the games here haven't been set up to handle that.
well, as I said above. That is mostly up to the developer, isn't it? Not GOG. Depending on how the game exactly handles this, support may be easily added .. or it might just be so much work that it isn't really worth the time.

(ps.: i don't think there are any games that can't handle the multitasking :p)
As someone who actually thinks, that the .sh files are a rather good idea (compared to the .deb anyway), is there any reason for me to keep the tar.gz files?
Since the .sh can be extracted instead of installed as well, I don't really see any downsides yet, but maybe I missed something, apart from the fact, that you have to create a directory yourself if you choose to extract rather than install.
avatar
Klumpen0815: As someone who actually thinks, that the .sh files are a rather good idea (compared to the .deb anyway), is there any reason for me to keep the tar.gz files?
Since the .sh can be extracted instead of installed as well, I don't really see any downsides yet, but maybe I missed something, apart from the fact, that you have to create a directory yourself if you choose to extract rather than install.
If you're fine with them, then why not? Personaly, I don't want to run any scripts - there's no point for me. I install them inside my home directory and don't want any system wide installations. Speaking of just extracting them (those hybrid scripts) there are several downsides for me: a) unzip has to be installed - tar/gzip is basically always available, b) extracting them generates a warning (because of that script in front of the zip archive) and thus an exit code of 1 - not successful - bad for scripting, c) archives are bigger, d) unzip doesn't support multi-threading -> unpacking takes longer (and gzip is generally faster anyway).
Post edited August 16, 2015 by classicgogger
avatar
immi101: If an attacker can place some malicious code under your user account, your account is already compromised anyway. Having write access to a game won't make that any worse.
No, placing the code on your system alone is only the first step. An attacker also must manage you to execute that code. If all the programs you execute are installed as system programs which you cannot overwrite as a normal user he has no chance. His code will never be executed. But when an attacker finds a file which you usually execute and which he can overwrite then he has won. And that's where your game binary comes handy, which you have installed as a normal user and which he can overwrite. So the attackers code will be executed when you start your game the next time.

avatar
immi101: Kerbal Space Programm
Oh, I had that on my wish list. :(
avatar
Klumpen0815: As someone who actually thinks, that the .sh files are a rather good idea (compared to the .deb anyway), is there any reason for me to keep the tar.gz files?
Since the .sh can be extracted instead of installed as well, I don't really see any downsides yet, but maybe I missed something, apart from the fact, that you have to create a directory yourself if you choose to extract rather than install.
avatar
classicgogger: If you're fine with them, then why not? Personaly, I don't want to run any scripts - there's no point for me. I install them inside my home directory and don't want any system wide installations. Speaking of just extracting them (those hybrid scripts) there are several downsides for me: a) unzip has to be installed - tar/gzip is basically always available, b) extracting them generates a warning (because of that script in front of the zip archive) and thus an exit code of 1 - not successful - bad for scripting, c) archives are bigger, d) unzip doesn't support multi-threading -> unpacking takes longer (and gzip is generally faster anyway).
Thanks, this clears some things up.
They should just eliminate the debs and keep the tarballs then in addition to .sh .
avatar
hedwards: It works, it's just that there's things that GOG would have to do to make make it work. Probably something like unionfs mounted over the top of the installation directory would be the easiest fix. It would mean that you absolutely could not use the same game by different people at the same time, but it would work.
I wrote something based on symbolic links and local copies of specific files for DOS/Windows games, that works well so far.
Of course it would be a mess to do it for each game you install, so I automated the process too.

Here is an example for Divine Divinity if you feel curious:
[url=https://debian-facile.org/utilisateurs:vv222:games:divine-divinity]https://debian-facile.org/utilisateurs:vv222:games:divine-divinity[/url]

PS: My method works on multi-users systems too.
Post edited August 17, 2015 by vv221
avatar
Klumpen0815: Since the .sh can be extracted instead of installed as well, I don't really see any downsides yet, but maybe I missed something, apart from the fact, that you have to create a directory yourself if you choose to extract rather than install.
The difference between the old .tar.gz files and the new .sh format is less technical, but more in the responsibility. The .tar.gz files were officially provided by GOG, so extracting the game from the .tar.gz file and running it that way was officially supported, which it isn't anymore now.

The difference between the .deb files and the new .sh format is that with the .deb file GOG was forced to set the permissions correctly as the game has been installed under a different user (root) as it has been run later. They now can be more careless with the permissions as they require the game to be installed with the same user which later runs it. That makes the life harder for people which want to install the games read-only under an own user and generally doesn't increase the security of the game installations.