Every article tag can be clicked to get a list of all articles in that category. Every article tag also has an RSS feed! You can customize an RSS feed too!
We do often include affiliate links to earn us some pennies. See more here.
Well folks a lot of you saw this one coming, GOG.com have officially responded to us to state that Linux support just isn't happening anytime soon. Quite sad news really, was hopefull on this one since they are such a big name and a pretty decent store too.

Here's the message I got from Trevor Longino, their Head of PR and Marketing, with thanks to Piotr Szczesniak who also works in the PR dept.
Trevor Longino GOG.comHi Liam,

Unfortunately not much has changed in our stance towards supporting Linux in the last few months and there is one main reason for that. Since our birth over 5 years ago we have always provided full customer support for all games we have released. That is not going to change. For every game we release we provide a money-back guarantee: if we can't get the game working on the customer's computer with the help of our support team, we return the money. The architecture of Linux with many common distros, each of them updating fairly often, makes it incredibly challenging for any digital distribution company to be able to properly test the game in question, and then provide support for the release--all of which our users are accustomed to.

Sure, we could probably release a client and sell the games and let Linux users worry about the rest. We don't consider it, however, a viable option for the business model we have followed so far. Apparently our model has its drawbacks, as we cannot make everyone happy, but, as of now, we don't plan on introducing Linux support in the foreseeable future.


So folks no matter the hints, you have it direct from their PR head.

This line is the bit that gets me:
QuoteThe architecture of Linux with many common distros, each of them updating fairly often, makes it incredibly challenging for any digital distribution company to be able to properly test the game in question, and then provide support for the release--all of which our users are accustomed to

It has often bugged me just how many distributions there are, but it's more of a problem with their own policies of refunding if they cannot get it to work for you which is a good policy, but on Linux it is fair enough that it could be trouble for them when someone tries to install x game on "Look Ma I Built A Distro v4" that has some crazy new configuration somewhere.

I will just leave this here:
image

UPDATE #1, I asked if it was basically the amount of distro's and how often they are updated that's really the issue:
Piotr Szczesniak GOG.comIt's a bit more than that.

There are a number of distros. We can support just one (which is how Steam is doing it), but since we believe strongly in freedom of choice, that's not our preference. On the other hand, supporting everything in the world is more burden than any business could assume So, the last time we looked into this, we investigated supporting three common ones: Mint, Debian, and Google's Chrome OS.  We researched the number of OS updates, how often they occurred, when (and how frequently) various libraries are surpassed and deprecated. We then researched how often, for example, updates to these versions of Linux caused problems with DOSBox, SCUMMVM, and other tools that we make use of for our remastering process. 

There is a difference in GOG.com's business model from Steam or any other distributor out there. *We* are on the hook for support of these games. And we update our support as the OSes that our games are running on are updated. That means that, unlike a developer or any other distributor, when we release on a Linux distro, we don't have to test once and then we're done. Each time there is a major update in an OS that we support that changes compatibility, we have to devote substantial time and resources to updating our catalog to work with the update. Sometimes, it may even occur that we cannot fix it in-house but rather have to spend the money to get it fixed by outside resources or else we'd have to remove the compatibility for the game from its game card. Imagine if we had 400 games from our 600+ game catalog supported on Linux and we found that a third of them no longer worked in a distro that we supported. Imagine the time and effort that would go into re-building 130 games.

Now take that kind of time and effort--time and effort that is not required by other OSes except on a one every four or five years' basis--and think of the cost we associate with it vs. the possible revenue that we might earn from Linux. Even if, on average, a Linux distro only has big updates as often as, say, Mac OSX does (every four or so years), unless these big updates are synchronized across the distros (which, historically, they're not) that means we're seeing the need to remaster some of our games every 14 - 16 months. 

Until we can figure out something like a better way to automate testing and building games for GOG.com, there's no way that the economics of Linux support make sense for us. That said, we do know that there are plenty of people who want to be able to play their games with Linux-native support from us, and we continue to look for ways where we can automate this until it reaches a point where it is something that we believe we can do and not lose money at it.

So a long winded answer to basically say "Yes Linux is updated too often for us".

Strikes me as odd since even Windows which was once known for being exceptionally slow to make major OS updates has committed itself to having a much more regular release schedule now, along with Mac having yearly releases.

So, I have asked about that as well and I have also pointed out that Ubuntu for example has LTS (Long Term Support) releases which are meant for things like this, so people don't have to update every 6 months.

UPDATE #2:
Piotr Szczesniak GOG.comNo, it's not.

One, because Windows' faster releases are promised, but I'll believe it when I see it. As for Mac OS:  "The desktop-oriented version, OS X, followed in March 2001 supporting the new Aqua user interface. Since then, seven more distinct "end-user" and "server" versions have been released." (seven versions released over 12 years or about one every other year).

Also, as I just noted below, to support Linux in a manner that we feel is consistent with our standards, we would need to support three distros each of which sticks to its own schedule and period for updates, and each of which brings in a tiny part of the revenue of Windows or even Mac. So, as I noted, it's a question of economics. Until we solve things our own end for how to make this scale economically, I don't see it happening any time soon. That said, we are investigating how to do this for a variety of issues beyond Linux support, so don't give up hope. Just don't expect it tomorrow, either.

About his Mac point - It was one every other year back in 2009 but Mac now does yearly updates, 2011, 2012 and 2013 will have all had Mac OS X releases and they have said it will be yearly.

So basically guys, if you're looking for native Linux support out of the box you'll have to look elsewhere than GOG for now.

We have Steam, Desura, Gameolith, ShinyLoot, FireFlower Games and one day soon IndieCity too. One day GOG.com may support us and I will thank them when they do and we can put all this to rest!

I hope one day they support us but considering their answers I don't ever see it happening. Article taken from GamingOnLinux.com.
0 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
182 comments
Page: «17/19»
  Go to:

helsinki_harbour Sep 9, 2013
Quoting: KristianSteam does bundling just fine.
If you call nearly 1000 open issues "fine" for just the support of only "Ubuntu 12.04 LTS or 12.10 with the Unity", yeah, it is doing bundling fine.
Guest Sep 9, 2013
Quoting: helsinki_harbour
Quoting: Quote from KristianSteam does bundling just fine.
If you call nearly 1000 open issues "fine" for just the support of only "Ubuntu 12.04 LTS or 12.10 with the Unity", yeah, it is doing bundling fine.
Have you bothered to see what those issues are? Only 2 are marked as runtime. Most are issues with the Steam client itself (over 300). Check all the labels on the left side. So yes, the bundling of runtimes aka libs is just fine.
scaine Sep 9, 2013
View PC info
  • Contributing Editor
  • Mega Supporter
Quoting: Silviu
Quoting: Quote from helsinki_harbour
Quoting: Quote from Quote from KristianSteam does bundling just fine.
If you call nearly 1000 open issues "fine" for just the support of only "Ubuntu 12.04 LTS or 12.10 with the Unity", yeah, it is doing bundling fine.
Have you bothered to see what those issues are? Only 2 are marked as runtime. Most are issues with the Steam client itself (over 300). Check all the labels on the left side. So yes, the bundling of runtimes aka libs is just fine.

And a huge number of those open issues are incredibly esoteric - ZFS for example. Or PuppyLinux, or whatever. They only "officially" support Ubuntu, but the GitHub is flooded with distro-specific issues.

Which is great. They could just have shut that door forever, but it's good to see an open attitude to expanding beyond their original promise. I just wish they would close/filter the numerous "Please bring Game X to Steam". Must have been hundreds of +1s for DOTA, and now it's started for other games too.
berarma Sep 9, 2013
Quoting: scaine
Quoting: Quote from Silviu
Quoting: Quote from Quote from helsinki_harbour
Quoting: Quote from Quote from Quote from KristianSteam does bundling just fine.
If you call nearly 1000 open issues "fine" for just the support of only "Ubuntu 12.04 LTS or 12.10 with the Unity", yeah, it is doing bundling fine.
Have you bothered to see what those issues are? Only 2 are marked as runtime. Most are issues with the Steam client itself (over 300). Check all the labels on the left side. So yes, the bundling of runtimes aka libs is just fine.

And a huge number of those open issues are incredibly esoteric - ZFS for example. Or PuppyLinux, or whatever. They only "officially" support Ubuntu, but the GitHub is flooded with distro-specific issues.

I'm sure Windows would have the same kind of esoteric requests in biggest numbers. That has nothing to do with distros but with personal customizations that can be done on Windows too.
helsinki_harbour Sep 9, 2013
Quoting: Silviu
Quoting: Quote from helsinki_harbour
Quoting: Quote from Quote from KristianSteam does bundling just fine.
If you call nearly 1000 open issues "fine" for just the support of only "Ubuntu 12.04 LTS or 12.10 with the Unity", yeah, it is doing bundling fine.
Have you bothered to see what those issues are? Only 2 are marked as runtime. Most are issues with the Steam client itself (over 300). Check all the labels on the left side. So yes, the bundling of runtimes aka libs is just fine.
Steam itself is a application which needs to be bundled: 330 bugs. The games needs to be bundled: ~350 bugs. Linux platform problems (audio, drivers, windowmanager):120 bugs. The majority of bugs seems to be not categorized beside "reviewed", so many relevant bugs are hidden inside the "reviewed" category (950 bugs).
berarma Sep 9, 2013
Quoting: helsinki_harbour
Quoting: Quote from Kristian
Quoting: Quote from Quote from berarmaThere's a solution and it's given in link #3, solution #3. Any developer that doesn't want to open source their project must ship their game with all libraries needed. Not doing so is a call for problems. Open sourced games have the benefit that they may get into the distribution packaging system and thus have the problem solved.

This is exactly what modern games do on Windows anyway as far as shipping with DirectX, the Visual C++ Runtime, .Net, etc goes. Every single GOG game that uses Dosbox ships with it separately as well.

Bundeling was the approach of Autopackage, worked not robust enough (you can't bundle everything) as nobody was cooperating with autopackage and therefore this crap wasn't fixed (and is still not). As the distros refused to support this idea (because of conservatism and elitism) the project died. Other technologies who aimed also on making binary software deployment easier like FatELF by Ryan Gordon faced the same fate.

It's a lot more easier than that, the solutions you propose are flawed IMHO. You can't force distributions to participate in solving a problem they don't have. Distributions don't have to support nor develop this solution, that idea is utterly wrong, it's commercial developers because it's their problem, and one that can be solved as easily as creating a pool of libraries they can ship with their software.

Maybe it's a problem that should be solved by the development tools, in any case, it's not distributions nor users that have to come up with the solution.

If some day there's big profits to make in the GNU/Linux market it won't matter there's 1000 distributions to support, they will come up with a solution, hopefully the one I'm advocating for or something even better. They don't see enough benefit compared to other markets, so they make up an excuse and say it's our fault.

Steam won't do it because they're just trying to pressure Microsoft and maybe use us as beta users for some upcoming gaming console.

It makes me sick this non-issue is talked about so much, let's kick the developers butt for giving stupid excuses. No system has zero porting cost and zero support cost, GNU/Linux is easy in that aspect. There's indie developers doing it, GoG might be small but no smaller than does indies, sometimes one-man teams. How are they not ashamed for making excuses up?
scaine Sep 9, 2013
View PC info
  • Contributing Editor
  • Mega Supporter
Quoting: Quote from berarma
Quoting: Quote from helsinki_harbourBundeling was the approach of Autopackage, worked not robust enough (you can't bundle everything) as nobody was cooperating with autopackage and therefore this crap wasn't fixed (and is still not). As the distros refused to support this idea (because of conservatism and elitism) the project died. Other technologies who aimed also on making binary software deployment easier like FatELF by Ryan Gordon faced the same fate.

It's a lot more easier than that, the solutions you propose are flawed IMHO. You can't force distributions to participate in solving a problem they don't have. Distributions don't have to support nor develop this solution, that idea is utterly wrong, it's commercial developers because it's their problem, and one that can be solved as easily as creating a pool of libraries they can ship with their software.

Maybe it's a problem that should be solved by the development tools, in any case, it's not distributions nor users that have to come up with the solution.

If some day there's big profits to make in the GNU/Linux market it won't matter there's 1000 distributions to support, they will come up with a solution, hopefully the one I'm advocating for or something even better. They don't see enough benefit compared to other markets, so they make up an excuse and say it's our fault.

Steam won't do it because they're just trying to pressure Microsoft and maybe use us as beta users for some upcoming gaming console.

It makes me sick this non-issue is talked about so much, let's kick the developers butt for giving stupid excuses. No system has zero porting cost and zero support cost, GNU/Linux is easy in that aspect. There's indie developers doing it, GoG might be small but no smaller than does indies, sometimes one-man teams. How are they not ashamed for making excuses up?

Read the slides there on AutoPackage - by far the biggest problem was that distros didn't care. In fact, I remember Autopackage when it was being touted in 2005/2006 - it wasn't that distros didn't care. In fact, the distros (or at least the communities around the distros) actively lambasted the Autopackage idea. Loudly resisted getting the equivalent of InstallShield for their platform. This wasn't apathy, it was outright denial and bluntly worded hatred of the idea.

So there's absolutely nothing "easy" about packaging.

Now I don't know if you guys have tried installing your Humble games through the Ubuntu Software Centre, but after you've added enough, having it trying to update 20+ PPAs is a pain, and meanwhile full updates for patches is also hellish. Not to mention the timeout issues during download over WIFI which seem to plague my laptop (but not Steam).

So what are GoG's options then? Plenty, I'm sure, but instead of a standardised installer for all linux distros, they have to spend days/weeks with experienced linux sysadmins to investigate the possibility of how they achieve this.

So call bullshit all you want, but it SHOULDN'T BE THIS HARD. But as helsinki points out, elitism is rampant and here we are.
Shmerl Sep 9, 2013
I think packaging and deployment while being an annoyance, are minor issues in comparison with what TheEnigmaticT was saying about long term support. To take a recent example. I got one game on Humble Bundle while being on Debian testing during the recent Wheezy release freeze. The game didn't work, since it was built against newer glibc than the one used in that Debian. The freeze was longer than usual and those freezes are annoying, but it was still less than a year long, so Debian testing didn't fall behind glibc wise that much. Now, this might be not the most common situation, but it's still a possibility. And now with major X.org -> Wayland shift coming along, some games also can break I bet. All this is not the end of the world or the reason to avoid supporting Linux. But those are real concerns.

Really, I have no idea how GOG can solve this "ideally". They only can support such and such range of middleware long term. Unless they are willing to stretch their support too wide making builds for all kind of combinations, which is costly.
berarma Sep 9, 2013
Quoting: scaineRead the slides there on AutoPackage - by far the biggest problem was that distros didn't care. In fact, I remember Autopackage when it was being touted in 2005/2006 - it wasn't that distros didn't care. In fact, the distros (or at least the communities around the distros) actively lambasted the Autopackage idea. Loudly resisted getting the equivalent of InstallShield for their platform. This wasn't apathy, it was outright denial and bluntly worded hatred of the idea.

So there's absolutely nothing "easy" about packaging.

Now I don't know if you guys have tried installing your Humble games through the Ubuntu Software Centre, but after you've added enough, having it trying to update 20+ PPAs is a pain, and meanwhile full updates for patches is also hellish. Not to mention the timeout issues during download over WIFI which seem to plague my laptop (but not Steam).

So what are GoG's options then? Plenty, I'm sure, but instead of a standardised installer for all linux distros, they have to spend days/weeks with experienced linux sysadmins to investigate the possibility of how they achieve this.

So call bullshit all you want, but it SHOULDN'T BE THIS HARD. But as helsinki points out, elitism is rampant and here we are.

I've read them and that's why I say the idea is flawed. This project can't/shouldn't be forced on distros. It doesn't matter how much user communities want it, it has to be done out of the distro for obvious reasons. It doesn't solve a problem distros have but it would create a lot, don't you see why distro developers don't like the idea?

Bundling your libraries with your game isn't hard, it's a lot easier than anything you've proposed, no need for a new packaging system, no need for a new executable file format. All games distributed for any system already do that to a certain extent, so what's the problem? None, now bundle your games with the libraries they need.

They don't do it because they don't care, it's not because it's hard or impossible. It's the easiest, most feasible and standard solution.
scaine Sep 9, 2013
View PC info
  • Contributing Editor
  • Mega Supporter
Quoting: berarmaI've read them and that's why I say the idea is flawed. This project can't/shouldn't be forced on distros. It doesn't matter how much user communities want it, it has to be done out of the distro for obvious reasons. It doesn't solve a problem distros have but it would create a lot, don't you see why distro developers don't like the idea?

Bundling your libraries with your game isn't hard, it's a lot easier than anything you've proposed, no need for a new packaging system, no need for a new executable file format. All games distributed for any system already do that to a certain extent, so what's the problem? None, now bundle your games with the libraries they need.

They don't do it because they don't care, it's not because it's hard or impossible. It's the easiest, most feasible and standard solution.
Forced on distros? No-one was forcing the distros to do anything. It was the distros communities that killed this project, it was the communities that refused to use it. Uptake was nil.
It doesn't solve problems that distros have?? It solved two crucial problems that all distros have :
1. Packaging later versions of something outside of your distros landscape. PPAs fix that to a certain extent in Ubuntu, but it's a pain if you have too many and there are some things you actually don't want constant updates on. Autopackage offered this. It offered back in 2006 when Ubuntu was tethered to Firefox because of Gecko dependencies in multiple other packages, which meant that you couldn't update Firefox without updating your whole distro. Even in LTS!
2. Crap uptake from resellers because they have to support at least three methods of packaging - apt, rpm and tarball for the rest. And tarballs are shit - you have to extract them after download, make stuff executable, create system shortcuts, different people put them in different places making support a nightmare. Debs and rpms solve some of that but they're two separate systems, so again, not a solution. Autopackage was that solution. One of a few actually, but the one that seemed to have the most (ha!) momentum.
So basically: backlash. No one touches it. Project dies.
I started this thread resenting GoG for not trying hard enough. Now, thanks to all this dredging up past pain and seeing the same attitudes prevalent today as 7 years ago, I actually understand why they want to stay clear of linux. Unless you're launching on Desura or Steam, getting your game to the masses is a hot mess.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.
Buy Games
Buy games with our affiliate / partner links: