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
Ganni1987: This situation is not new to GOG, as it already happened in the macOS world where 32bit has been dropped entirely since macOS 10.15. GOG stopped advertising the affected games as Mac supported, however they still provided the downloads and even left a note on the games' page where it says "Mac notice: The game is 32-bit only and will not work on macOS 10.15 and up. " - One game that has this message is 'Volgarr the Viking'.

While I don't agree that they stopped advertising a game as Mac compatible, I can imagine why though - excessive Support tickets. Many people would see the Apple logo without reading the warning and think it's compatible with their system.

I don't think Linux should be treated any differently.
This situation is quite different to the situation with Macs - Canonical are not dropping 32-bit support with Ubuntu, they're dropping support for 32-bit system installations (i.e. no 32-bit .isos & 32-bit versions of many software packages have been culled as they no longer need to be provided to support 32-bit installs etc). You can still install and run 32-bit software on the 64-bit installs.
Post edited May 17, 2020 by adamhm
avatar
Alm888: While it was not the case with me, and most probably with you, general Linux audience has reached a consensus to use Ubuntu as the standard of Linux
This was never the case really (consensus) and while Ubuntu was hyped, today it's not even the most popular distro, for example judging by GOL stats: https://www.gamingonlinux.com/users/statistics

So I don't see any problem for GOG to drop Ubuntu support and focus on distros that provide multiarch.
Post edited May 17, 2020 by shmerl
avatar
adamhm: This situation is quite different to the situation with Macs - Canonical are not dropping 32-bit support with Ubuntu, they're dropping support for 32-bit system installations (i.e. no 32-bit .isos & 32-bit versions of many software packages have been culled as they no longer need to be provided to support 32-bit installs etc). You can still install and run 32-bit software on the 64-bit installs.
AFAICR, Canonical had intended to remove 32bit support "Apple-style" (including kernel-level multiarch support), but it faced huge backlash (even from Valve, that threatened to ditch Ubuntu completely) and was forced to maintain limited sub-set of 32bit libraries (how exactly limited? what if the infamous "libssl.so.1.0.0" and "libcrypto.so.1.0.0" will not be among those libraries?). Even if multiarch still exists, there are no guaranties an application will launch due to missing libraries.

It is easier for GOG to just drop Linux support, considering now it has a plausible excuse.
avatar
Alm888: While it was not the case with me, and most probably with you, general Linux audience has reached a consensus to use Ubuntu as the standard of Linux
avatar
shmerl: This was never the case really (consensus) and while Ubuntu was hyped, today it's not even the most popular distro, for example judging by GOL stats: https://www.gamingonlinux.com/users/statistics

So I don't see any problem for GOG to drop Ubuntu support and focus on distros that provide multiarch.
Seriously?
So, are you going this path of denial? Come on!

How many times we urged developers complaining about huge number of distros to just target Ubuntu and users of other distros will just adapt (because they know what they are doing and can manually install missing libraries)?
With Ubuntu all of its offspring (or "flavors") and bastards (like Mint) will sink too because of common kernel and general inability to maintain custom repositories for missing libraries.

And if not Ubuntu, then which is next on the list? Arch? ARCH!!!
A rolling-release "do it yourself" family without any solid "set in time" set of libraries and environment, but with "I use Arch, BTW" community of users with bright personalities and NTSC (Never Twice the Same Configuration).

This is literally the embodiment of production development hell, where by the time a developer releases its product targeting library X said library changes 23 times breaking API in the process and no user is capable of answering a simple question of "What did you update?" after a game that worked yesterday does not work anymore (because of "rolling release").
avatar
Alm888: And if not Ubuntu, then which is next on the list? Arch? ARCH!!!
Using "popular" distros was the pitfall of such approach to begin with. They should use the distro that does the job. Other distors can adjust if needed. Ubuntu doesn't do the job? Use something else, like Debian, openSUSE or whatever else.
Post edited May 17, 2020 by shmerl
hullo, Jasper
avatar
Alm888: It is easier for GOG to just drop Linux support, considering now it has a plausible excuse.
It certainly *feels to me* like they already dropped it, just letting it rot along. (if there are some guys in GOG working hard on the linux part, sorry, but I'm describing how it looks from the outside)
avatar
ped7g: It certainly *feels to me* like they already dropped it, just letting it rot along. (if there are some guys in GOG working hard on the linux part, sorry, but I'm describing how it looks from the outside)
To me it looks like they pushed Linux support to some low paid contractors. The Bard's Tale IV release problems were almost anecdotal.
Post edited May 18, 2020 by shmerl
avatar
Ragmand: Chroot could also work, but now you need sudo privileges to play your games, which will be a problem for households with small children who aren't yet responsible enough to be a sudoer. Plus, I would have no clue how to install an entire Linux distro into a chroot folder, I'm only barely able to use chroot from a live DVD to fix a borked GRUB.
To install the chroot, you can just use a tool like debootstrap (for Debian and Ubuntu chroots). To allow non-root use of the chroot, there's schroot.
avatar
Alm888: AFAICR, Canonical had intended to remove 32bit support "Apple-style" (including kernel-level multiarch support), but it faced huge backlash (even from Valve, that threatened to ditch Ubuntu completely) and was forced to maintain limited sub-set of 32bit libraries (how exactly limited? what if the infamous "libssl.so.1.0.0" and "libcrypto.so.1.0.0" will not be among those libraries?). Even if multiarch still exists, there are no guaranties an application will launch due to missing libraries.

It is easier for GOG to just drop Linux support, considering now it has a plausible excuse.
Do you have some evidence for you reasoning or are you just throwing out hypotheticals, 'cause fearmongering is always so much fun :/
I'm pretty certain Canonical never said anything about dropping kernel-level support for 32bit. So solutions like flatpak, snaps or other containerization, or 3rd-party repositories for 32bit packages were(are) always still a possible solution.

Your idea that they would declare openssl a nonessential package is frankly absurd.
They also did a decent job in involving the community, re-addeding packages when somebody asked for it.
https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility

Seems total nonsensical to me to make such a panic about it at this point. As far as gaming is concerned, things will largely be the same on 20.04 as they were on 18.04.

There is of course always the chance that some dependency is not available anymore because it's too old and therefore dropped from the repository(32bit & 64bit). But that's not a new problem.
avatar
Alm888: It is easier for GOG to just drop Linux support, considering now it has a plausible excuse.
avatar
ped7g: It certainly *feels to me* like they already dropped it, just letting it rot along. (if there are some guys in GOG working hard on the linux part, sorry, but I'm describing how it looks from the outside)
hmm, what exactly are the problems you are having?
I might have a skewed perception of the problem due to my small(ish) library, but for me things work more or a less as good/bad as they always have.
It still is (and always was) a low-level effort, but it still provides me with playable games.
I can't really see a notable drop in quality specific to the linux packaging.
Post edited May 19, 2020 by immi101
avatar
immi101: Do you have some evidence for you reasoning or are you just throwing out hypotheticals, 'cause fearmongering is always so much fun :/
Easy, pal! No need for strong words. I'll let this accusation slip this time, but I didn't like it one bit.

And as for your request for source material… Please, consider this:
1) 20 June 2019: initial news on 32 support dropping;
2) 22 June 2019: Valve's response/threat to Canonical;
3) 24 June 2019: Canonical's desicion to "…build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS".

And I admit that yes, the initial 32bit support removal was ambiguous: Canonical did say there would be other means to restore support via 3rd party effort, but it was left hanging in the air as to which ones. After all, one could just substitute Canonical's 64bit exclusive "mainline" kernel with multiarch-capable patched one. And we won't know this as the plans were postponed for now (at least till 22.04 arrives).

avatar
immi101: Your idea that they would declare openssl a nonessential package is frankly absurd.

I might have a skewed perception of the problem due to my small(ish) library, but for me things work more or a less as good/bad as they always have.
Yes, ignorance is bliss. I was referring to libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb explicitly. An outdated library with "heartbleed" vulnerability. It was expelled from most of the distros, but was still present in Ubuntu 18.04 and you would be surprised how many games on GOG actually require this exact library:
1) "Undertale", "VA-11 Hall-A: Cyberpunk Bartender Action" and other games on this engine;
2) The Red Strings Club
3) Surviving Mars;
4) Hyper Light Drifter;
5) Mable & The Wood (LOL! This one is already for Ubuntu 19.04);
6) Risk of Rain;

last one) even "X4: Foundations" requires this (albeit they promised to remove this dependency).
The list goes on endlessly (just google "libcrypto.so.1.0.0 site:https://www.gog.com"). :)

What are the chances Ubuntu will contain 32bit version of outdated and confirmed-vulnerable security library?
avatar
Alm888: ...
3) 24 June 2019: Canonical's desicion to "…build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS".
right, but the important bit of quote is this: "We will put in place a community process to determine which 32-bit packages are needed to support legacy software, and can add to that list post-release if we miss something that is needed."
So the argument that Canonical might be mean to us and simply decide to exclude an important package doesn't really hold much ground I think.

What are the chances Ubuntu will contain 32bit version of outdated and confirmed-vulnerable security library?
well, the same chance they will keep the 64bit version. ==> Zero. Nada. Null. ;)
Upstream support for that branch of openssl ran out in the beginning of the year iirc, so the package got dropped for 20.04.
For 32bit and for 64bit.
This is the problem that I mentioned at the end of my post. But it has nothing to do with the whole discussion about phasing out 32bit support. This problem about closed-source software depending on some outdated, no longer available library is with us since the dawn of time for linux gaming ;)
remember libpng12 ? :p

apologies if my tone put you off, I just find it incredibly irritating and frustrating when people so quickly jump to drastic conclusions. In the end, nothing has really changed so far in practice. It puzzles me how one can come to the conclusion that it would be better to drop linux support altogether.

side note:
i am fairly certain the openssl package(1.0.2n) is young enough to never have been affected by heartbleed. Didn't that only affect the 1.0.1* branch?
Post edited May 20, 2020 by immi101
avatar
Alm888: Yes, ignorance is bliss. I was referring to libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb explicitly. An outdated library with "heartbleed" vulnerability. It was expelled from most of the distros, but was still present in Ubuntu 18.04 and you would be surprised how many games on GOG actually require this exact library:
1) "Undertale", "VA-11 Hall-A: Cyberpunk Bartender Action" and other games on this engine;
2) The Red Strings Club
3) Surviving Mars;
4) Hyper Light Drifter;
5) Mable & The Wood (LOL! This one is already for Ubuntu 19.04);
6) Risk of Rain;

last one) even "X4: Foundations" requires this (albeit they promised to remove this dependency).
The list goes on endlessly (just google "libcrypto.so.1.0.0 site:https://www.gog.com"). :)

What are the chances Ubuntu will contain 32bit version of outdated and confirmed-vulnerable security library?
For Undertale, I just run the Windows version under WINE; chances are the other games using that engine would also work well that way.

Of course, I question why a single-player game needs an encryption library, especially since it's one of those libraries that has been known to break ABI compatibility.
How can I tell if a game is native or uses wine on the gog store page? Anyone know?
avatar
dtgreene: For Undertale, I just run the Windows version under WINE; chances are the other games using that engine would also work well that way.

Of course, I question why a single-player game needs an encryption library, especially since it's one of those libraries that has been known to break ABI compatibility.
I must respectfully reject the proposal, as I did not pay GOG for a Windows™ game and expect proper support.
Supplying the needed libraries manually seems to be a better idea.

And speaking of WINE…
avatar
Truth007: How can I tell if a game is native or uses wine on the gog store page? Anyone know?
Normally, it is stated in the "system requirements" part of the game page (see attachment) as is in case of "Flatout 2".
Attachments:
wine.jpg (36 Kb)
avatar
dtgreene: For Undertale, I just run the Windows version under WINE; (…)
avatar
Alm888: I must respectfully reject the proposal, as I did not pay GOG for a Windows™ game and expect proper support.
Supplying the needed libraries manually seems to be a better idea.
./play.it provides the missing library for Undertale, in addition to dependencies handling and a required workaround to avoid a crash on AMD GPU: Install Undertale on Linux