Minigalaxy, the FOSS Linux client for GOG adds support for Wine

Oh, so there is some client for Linux games on GOG. And now with the wine support. I'm looking forward to get my own laptop to return to Manjaro and try to run Mortal Kombat 4 there. It is also will be interesting if they add a proton support, like Lutris did.

Oh, so there is some client for Linux games on GOG. And now with the wine support. I'm looking forward to get my own laptop to return to Manjaro and try to run Mortal Kombat 4 there. It is also will be interesting if they add a proton support, like Lutris did.

There would be Gamehub, it's not only for GOG, but it also works with proton.
I don't know if it's because I have steam installed.

Oh, so there is some client for Linux games on GOG.

There have been GOG clients for Linux for years already, for downloading and updating purposes I mean. The most advanced one is lgogdownloader.

There are currently no multiplayer focused clients, besides for Comet.


Last edited by Shmerl on 21 April 2020 at 2:42 am UTC

Does it keep the games up to date or is manual patching needed when updates are released?

I installed this tonight to check it out. It works pretty good. The new version hasn't hit the Fedora repos yet, but the previous version is pretty good so far. I'm looking forward to the new version with WINE integration.

I have a Win10 I use for classic GOG titles and Facebook Gameroom. If this works well it would be a big step in nuking that VM and recovering 50G.

Does it keep the games up to date or is manual patching needed when updates are released?

Nope, but I expect it's on their roadmap:

Expect to see the following issues:

• Changing the installation directory makes Minigalaxy unable to detect previously installed games


• Updating games has not been implemented yet

I'm still out of luck with this. After my disastrous multi-screen foray into Ubuntu 20.04, I ended up on Mint 19.3, which is based on Ubuntu 18.04 - which MiniGalaxy doesn't support due to, apparently, a lack of an up to date pygobject:

Minigalaxy does not ship for the following distributions because they do not contain the required version of PyGObject:

• Ubuntu 18.04


• Linux Mint 19.3


• openSUSE 15.1

It's a shame. I'd love to give it a shot.

I think "python" is Swahili for "application probably doesn't work"

Translated to Nynorsk? That's excellent news to... let's see, population 5.386 million divided by 12% preferring Nynorsk to Bokmål, divided by 1.85% using Linux on their desktops, we're at roughly 12,000 divided by however many play GOG games...

That's great for that one guy who translated it!

I kid, of course, good to have it in there.

Translated to Nynorsk? That's excellent news to... let's see, population 5.386 million divided by 12% preferring Nynorsk to Bokmål, divided by 1.85% using Linux on their desktops, we're at roughly 12,000 divided by however many play GOG games...

That's great for that one guy who translated it!

I kid, of course, good to have it in there.

A niche of a niche of a niche! That's pretty... niche.

Translated to Nynorsk? That's excellent news to... let's see, population 5.386 million divided by 12% preferring Nynorsk to Bokmål, divided by 1.85% using Linux on their desktops, we're at roughly 12,000 divided by however many play GOG games...

That's great for that one guy who translated it!

I kid, of course, good to have it in there.

That's actually another thing I love about open source. I think lots of indigenous groups trying to preserve their languages should be leaping on open source software. Microsoft is never going to do a translation of Office to Nisga'a, but the Nisga'a can translate Libreoffice if they want.

which is based on Ubuntu 18.04 - which MiniGalaxy doesn't support due to, apparently, a lack of an up to date pygobject

That's what broke it for me as well.

While Wine support is nice in theory, in practice if I have to use wine for the game, I can also use wine to run the official GOG client.

Support for (incremental) updates of Linux games would be a more valuable feature in my opinion. But as it stands, plenty of games either have their final patch available by the time I get around to playing them, or, if it's really a game I must have at release, I might already be done before the first patch is ready :-).

Does it keep the games up to date or is manual patching needed when updates are released?

Nope, but I expect it's on their roadmap:

Expect to see the following issues:

• Changing the installation directory makes Minigalaxy unable to detect previously installed games


• Updating games has not been implemented yet

I'm still out of luck with this. After my disastrous multi-screen foray into Ubuntu 20.04, I ended up on Mint 19.3, which is based on Ubuntu 18.04 - which MiniGalaxy doesn't support due to, apparently, a lack of an up to date pygobject:

Minigalaxy does not ship for the following distributions because they do not contain the required version of PyGObject:

• Ubuntu 18.04


• Linux Mint 19.3


• openSUSE 15.1

It's a shame. I'd love to give it a shot.

This has been an issue with desktop for a while. To the point where Laptop/Desktop OEM System76 suggests you update every 6 months when they release their Ubuntu-based distro. To the point where they have a nice Rust-based updater that works quite well (I used it for Pop!_OS 19.04 -> 19.10 without issue). The idea here is that many desktop OSes are going to more of a rolling or semi-rolling release model. Partially due to security and partially due to the fast rate at which software moves these days. The days of the LTS on desktop are numbered, I think. At least for things like gaming.

I'd suggest trying the Pop!_OS 20.04 beta and see how that works for you.

While it is nice to have (yet another) game launcher, the real issue with (no) Galaxy on Linux is the libraries it provides, or in the case of Linux, doesn't. Things like multiplayer, achievements, game content unlocks etc., which frankly shouldn't even be a thing on "we don't DRM" GoG.

I really hope Galaxy never makes it to Linux. Instead, I'd like GoG to actually be true to their vision and require game developers/publishers to remove any dependency on such kinds of stuff, and do so on any and all platforms.

Wishful thinking.

This has been an issue with desktop for a while. To the point where Laptop/Desktop OEM System76 suggests you update every 6 months when they release their Ubuntu-based distro. To the point where they have a nice Rust-based updater that works quite well (I used it for Pop!_OS 19.04 -> 19.10 without issue). The idea here is that many desktop OSes are going to more of a rolling or semi-rolling release model. Partially due to security and partially due to the fast rate at which software moves these days. The days of the LTS on desktop are numbered, I think. At least for things like gaming.

I'd suggest trying the Pop!_OS 20.04 beta and see how that works for you.

Nah, Pop is based on Gnome Shell, and their multi-monitor support means that you can't have your panel on a non "primary" display. But I need the panel to appear on the secondary display. Actually, I think the problem is the underlying GDM, because LightDM-based Unity didn't do this, while GDM-based Gnome-shell, XFCE, Unity(!) and Budgie all exhibited the same behaviour. It was just too much effort to get going.

As for LTS dying a death? Nah. Maybe for consumer distros... maybe. But the Redhats and Canonicals of this world need to support the concept of LTS for enterprise support. You might love rolling distros, but in my experience, they break too often, while I typically game at the cutting edge while on an LTS for periods of up to 2.5 years - or in the case of 12.04 to 16.04, just over four. They're stable and, thanks to PPAs, still cutting edge. Also, I just can't be bothered upgrading the core O/S that often. It does nothing for me. My PPAs do all the heavy lifting.

There are edge cases though, like mininova's insistence on some brand new feature of pygobject. Fair enough. I'll take that hit for the stability/reliability and convenience. And ultimately, I could upgrade it... I just don't care enough about their project to be bothered.

Good stuff! Finally, Baldur's Gate EE will install without the damn libssl.so.1.0.0 error we encounter in the Linux version...

People are talking about pyg object . . . so does this have something to do with bacon, or what?

Nah, Pop is based on Gnome Shell, and their multi-monitor support means that you can't have your panel on a non "primary" display. But I need the panel to appear on the secondary display. Actually, I think the problem is the underlying GDM, because LightDM-based Unity didn't do this, while GDM-based Gnome-shell, XFCE, Unity(!) and Budgie all exhibited the same behaviour. It was just too much effort to get going.

I'm not going to try and dissuade you from your favorite distro, but GNOME does allow the panel on non-primary displays. It's an option in the system menu and in GNOME tweaks.

As for LTS dying a death? Nah. Maybe for consumer distros... maybe. But the Redhats and Canonicals of this world need to support the concept of LTS for enterprise support. You might love rolling distros, but in my experience, they break too often, while I typically game at the cutting edge while on an LTS for periods of up to 2.5 years - or in the case of 12.04 to 16.04, just over four. They're stable and, thanks to PPAs, still cutting edge. Also, I just can't be bothered upgrading the core O/S that often. It does nothing for me. My PPAs do all the heavy lifting.

There are edge cases though, like mininova's insistence on some brand new feature of pygobject. Fair enough. I'll take that hit for the stability/reliability and convenience. And ultimately, I could upgrade it... I just don't care enough about their project to be bothered.

With the exception of really, really traditional enterprises, the "LTS" model is still becoming a slowly dying breed. Largely relegated to running old applications that can't be run on newer systems (though containers are helping with that where it's possible) and running as Hosts for Storage/Virtualization/Container clusters. And even then it's limiting as many of the container and virtualization systems require newer kernel features to perform well.

Add in the fact that security and competition has forced things to move at a faster pace.... and vendors rarely backport patches to non-system software (aside from traditional ones which are struggling to get the newer companies as customers). Simply put, while there will always be a use for LTS type systems (just like there are still COBOL apps), it will become far more rare.

Even where I work, none of our applications go through a traditional release process. Everything moves forward in smaller iterations..... sometimes they can't (I.E. Once you upgrade a Kubernetes Master, it can't be downgraded easily.... and every vendor from Microsoft to Google to RedHat and others will tell you NOT to downgrade it).

• New feature work - deploy the code as soon as it's merged, even if it's inactive. Find potential bugs faster.


• Deployment bug breaking something - Fix and roll forward.


• Change in container breaking something - Fix it, build, and roll tag forward.


• Etc

Why am I saying all this? I come from a Linux Systems Engineer background and now work as a Platform Developer (doing a lot of the same things, just with code) and the traditional "LTS" method is not scalable in today's world of security and competition.

A RedHat employee I work with in an automation-based open source community was talking today about how he feels SLES and RHEL took the "LTS" concept a bit too far as he can't get things working sometimes due to library or kernel issues....... at RedHat.


Last edited by EagleDelta on 22 April 2020 at 3:21 am UTC

I won't quote your post EagleDelta, but I guess time will tell. But if Canonical announce that 20.04 is the last LTS, or even 22.04... I'll be gobsmacked. Similarly, if Steam announce that their new target for compatibility is a rolling release, I'll be gobsmacked all over again.

I suppose time will tell.

Very surprised to hear you say that the panel can be moved to a secondary monitor. I researched this problem for weeks, also raised it on our own Discord, but everyone confirmed - when you change your primary monitor, the panel instantly wants to live there. Some of the hacks allow you to manually move it over to the secondary monitor, but on restart, it rehomes itself again. Pretty frustrating.

As for my "favourite" distro - well sure, that's Ubuntu, obviously. I've been a massive part of that community since 2006. At least... it was until I tried Mint again recently for the first time in about five years. It's pretty incredible and I honestly wonder if I'll ever find myself going back to Ubuntu after trying it. I also really liked Solus/Budgie. I'm going to keep track of that one, such a beautiful desktop.

I won't quote your post EagleDelta, but I guess time will tell. But if Canonical announce that 20.04 is the last LTS, or even 22.04... I'll be gobsmacked. Similarly, if Steam announce that their new target for compatibility is a rolling release, I'll be gobsmacked all over again.

I suppose time will tell.

I don't think they'll drop the LTS.

What I'm saying is that software is not building against LTS anymore - they build against what they need. Instead, either software packages their own deps or leave the LTS behind. Many times things like performance fixes and certain bug fixes no longer get backported unless the distro does it. Hell, the community I'm in doesn't. Part of the problem is that LTS-styles of Distro/OS will keep their system-installed languages long after those versions are EOL'd upstream because "LTS".

The idea that "Long-Term Support" is somehow more stable has actually been proven largely wrong. The issue isn't Rolling vs LTS - it's individual project's dev process. A Dev team that releases often, with small changes (as small as can be), has a much higher rate of finding and fixing bugs faster than a project that only releases things in large chunks.

There's a reason moving from Ubuntu 18.04 to Ubuntu 20.04 or from Windows 7 to Windows 10 is such a big deal, especially in enterprise. It's not because "LTS" is better, it's because the changeset is now so freaking big that there could be hundreds of bugs just waiting to hit you depending on everything from hardware configuration to software that's running. Using Pop!_OS or Manjaro and updating with each new release instead of waiting means that my potential list of bugs going from 19.10 to 20.04 is going to be far, far less than from 18.04 to 20.04 or especially from 16.04 to 20.04.

Where LTS really shines (for us) in today's world is in container images. We can atomically test a new LTS very, very quickly as we just use the same Dockerfile and change the source image. It will either work or not, but it won't affect the running containers until we are ready to roll it out. Contrast that to the past where we'd spend weeks preparing servers for upgrades from 14.04 to 18.04.

Very surprised to hear you say that the panel can be moved to a secondary monitor. I researched this problem for weeks, also raised it on our own Discord, but everyone confirmed - when you change your primary monitor, the panel instantly wants to live there. Some of the hacks allow you to manually move it over to the secondary monitor, but on restart, it rehomes itself again. Pretty frustrating.

I stand corrected. It was Dash-to-Dock that lets you do that, not GNOME itself. I've never dug too far into it. Since the panel doesn't track anything for me other than notifications, tray icons, and the log in panel I don't use it on both screens. I use the overview and workspaces to organize things. Digging through a panel because too frustrating for me. Just SUPER -> click Window is faster (for me).

As for my "favourite" distro - well sure, that's Ubuntu, obviously. I've been a massive part of that community since 2006. At least... it was until I tried Mint again recently for the first time in about five years. It's pretty incredible and I honestly wonder if I'll ever find myself going back to Ubuntu after trying it. I also really liked Solus/Budgie. I'm going to keep track of that one, such a beautiful desktop.

I used to like Mint, but I feel that Cinnamon is buggy and just not up to snuff in the same way that GNOME is. Also, the sheer amount of work that System76 puts into making Pop!_OS feel like great UX makes it my all time favorite. Their curation of the Nvidia drivers for me, including 3rd party software I need in the Pop!_Shop (that most distros don't), their UI into the firmware updater, and their absolutely amazing recovery and OS upgrade tools blow anything that Mint, Ubuntu, or Elementary have to offer out of the water. That and GNOME has become incredibly performant and extensions like Dash-to-Panel/Dash-to-dock and Arc-Menu are just amazing. Pop!_OS 20.04 is also coming with a Tiling/launcher extension for GNOME shell built by System76.

I used to really like Solus, but kept running into issues where software I needed was missing or deemed unnecessary.


Last edited by EagleDelta on 22 April 2020 at 8:29 pm UTC

Well, an interesting read. I get your point about LTS now, that makes much more sense, ta. Although you claim moving between LTS releases is a big deal... I've never found that to be the case. Indeed, I jumped two releases back in 2012 when I didn't like the look of 14.04, and waited until 2016 to upgrade. My HWE Kernel and PPAs kept me up to date on everything I cared about - kernel, drivers, and primary software. And since it was LTS, I still another year of support to manage the transition to the more modern desktop.

Ultimately though, all your (excellent) arguments fail for me until GDM fixes its multi-monitor support. I like the look of Pop_OS but it's based on GDM and I don't feel like experimenting with LightDM and I'm not a fan of Gnome-Shell anyway, which I still find clunky, rigid and generally unpolished.

Pop_OS has a nice recovery tool, but it's quite low level. I actually prefer Mint's approach of using an integrated Timeshift. It's the only OS I know of that builds a Timeshift capability into the core OS, which is quite nifty. Never had to use it yet though, so it's unproven, I suppose (for me). I'm only 2 months into my Mint journey so far though.

I'm also surprised to hear you say that Cinnamon is buggy. Amazing that my experience can be so positive, while yours is negative (and vice versa for Gnome Shell).

It's both a strength and an infuriating weakness of the Linux ecosystem that there's just so much choice, so many ways to do things.