I talk exactly about the non-repository use case, direct deployment to users. The use case which allows also ISVs to create software indepentend from platform vendor and to deploy the result directly to the user (without guardians in the middle which protect a walled garden). The use case which creates also enourmous ecosystems of applications around a platform (in contrast to the limited selection in repros). And games are the prime example for such software which wants to be installed directly by the users.

Ah, I see. It's easy to fix. Simply register on Humbe Bundle using the e-mail on which you got your links for games from HB. They will then connect all the games you purchased from them to that account, and you'll have them conveniently in your profile, same thing as on GOG. And any future purchase even made through Humbe Store widget will go directly to your profile as well. If you don't want to register, well, why are you complaining it's somewhat messy to keep track of all those e-mails and links?-) A few first purchases I made on HB were also without an account, but when I realized one can register - I did, it was very simple, not more complicated than on GOG. And having all games collected in your profile is a plus if you have a lot of them.

BitTorrent protocol has several benefits when downloading. It provides easy pausing / resuming, checksums / repairs and distributed download (so in most cases it's faster). Plus normally clients allow capping download speed, which most browsers don't.

I understand GOG's concerns to some degree. What will happen with games which are not relying on SDL let's say, and tie into X directly for some weird reason? Linux is switching to Wayland soon enough. It can create a big mess for gaming potentially, unless games avoid X dependencies or developers will promptly update their games for the Wayland world. It's just one example.

If GOG can really come up with ways of long term support better than Steam - it's great. But I don't think it has to take years to do that.

My parents install software on their own just fine. To them, it's as natural as installing any Windows application. Even more easily, actually, because a package manager does it all for them. And now even Windows 8 uses such a model with the Windows Store.

* Number of times I've had to "admin" Windows for them: at least seven or eight times. Three of those times was due to malware.
* Number of times I've had to "admin" Mint for them: other than the installation, zero. Not once. It's been almost three years now.

So in this case, the anecdote is not debunked by your statement which relied on a blind-faith presumption.

I should also point out that an OS's history has nothing to do with its presentation. Windows 2000-XP (and maybe Vista/7, though I'm less certain) came from the Windows NT line which, surprise, was intended for corporate workstations-and-servers. And yet that turned out to be completely irrelevant, especially when you consider that another OS which is supported -- Apple's -- is built on the same Unix/POSIX principles as Linux. And don't say "Oh but one is BSD, the other is Linux", because your statement about "workstations" and admins doing everything for the stupid users on the other side of campus, was a quality rooted in both OSes' histories.

I understand that, unlike BSD, the many, many distros of the Linux do things differently. There's not "One Single Linux Way", the way that BSD maintainers do things, but I don't agree that this is cause for as much confusion about Linux support as people choose to be confused about it. Go with what the usage statistics say for desktop users, and then only guarantee support for certain flavors of distros. There is a reason those are the most widely used, because free operating systems run within the rules of the invisible hand of the free market as much as commercial OSes do -- there are concrete reasons why those distros are the most popular. You can support the most widely-used format, and not worry about whether or not Slackware or Gentoo users will have trouble running it because you can label your release as being for those types of distros only.

According to Distro Watch, the three most widely-used distributions are all Debian based (Mint, Ubuntu, and of course Debian itself). So with the standards these three have in common for software packaging, there is a momentum that can be exploited.

So no, Linux support is not that expensive if you have someone knowledgeable about this in your company who can plan accordingly.

Distrowatch should never be used for any Linux usage estimation. Their numbers have nothing to do with actual distros deployment.

You have not read what I wrote: selecting stuff from the tiny repro is not the same as have a selecting from the complete internet, a vast ecosystem. Repros offering a inferior selecting. Also you are limited to a specific version, whci is a problem on LTS distros. Which AAA application or recent AAA game you will find in repros?

And that Windows 8 is also now swithcing to a walled garden model is a shame... :(

Which means exactly, it is expensive. You need some expensive specialist. Which is the reason why e.g. Ryan Gordon is so valuable for companies and the Humble indie bundle because he and another handful of specialist in world know how to do address linux more or less. Normal developer hate workarounding the rough edges in the linux ecosystem (http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/). For instance, after Idsoftware lost their specialist for linux they dropped support competely for rage (http://www.phoronix.com/scan.php?page=news_item&px=MTA5MzQ).

But you're not limited to repositories for the package manager. What's so complicated about double-clicking a .deb file, compared to double-clicking a .zip or .exe?

Rage for Linux was cancelled because Rage itself wasn't successful.

Also, you're talking about porting games, but this thread is about GOG hosting games that the developers have theoretically already ported. GOG doesn't need to hire a senior dyed-in-the-wool Linux guru to get basic one-click packaging together for software that's already made.

External debs are hard to provide for a ISV, as he has to address all distro variants specifically. So in general they are not available & or working not that well, or are outdated. Also, taking packages outside the distros repro negates the often mentioned advantages of a linux distro: not a well checked software experience and no malware safeness anymore.

I'm talking about linux suport, which is hard in all forms on all levels. And gog would need multiple well experienced devlopers doing nothing else than repackaging and fixing packages & dependendcies on distro & game upgrades all the time. As we see already on the pretty slow game update speed for the current windows GOG packages, GOG seems to be on its limits for "repackaging" already.

Based on my experience with a large library of games from the Humble Store (which provides mix of .deb, custom installers, .tar.gz) amongst other things, the process of installing things on Linux vs Windows isn't that different. Now I can't speak from personal experience as I've never developed anything for Linux before & I don't have a huge deal of Linux experience in general (having only used it for about half a year so far), but I notice that article about Osmos is from more than 3 years ago... However, from reddit earlier this year: A rather different viewpoint from another dev...

He doesn't "have to". As I already said, just look at the three most widely-used desktop distros, and target those, test it for those, and make it clear in your disclaimer that YMMV for end users who are using any other distro. Some distros are more suitable for desktop use than others, so there's no reason to support ones the vast majority of the Linux running, desktop-using public aren't using, and nobody will reasonably expect it any other way. I shouldn't expect to be able to run Witcher on a Windows Server box -- same deal here. We don't need repros for the Windows or OSX versions, so I don't know why it has to be the case for Linux. It's an option, a nice thing to have, but it's not a requirement. Besides, I'm not going to worry about downloading malware from GOG. And GOG's Windows packages for some games are often outdated anyway with missing patches or the wrong version entirely (how long did the GOG version of Fallout include the UK censorship? A year or more?), so I don't see how that's any different. That's something GOG needs to change in their culture, it's not an issue specific to OS support. It sounds like we're coming to an agreement that the issue is that GOG's company culture has shortcomings it needs to address, which don't necessarily have anything to do with real or perceived "difficulties" with operating systems. Really, anyone who embarked on a career in software shouldn't be balking at any notion of "difficulty". Kitchen too hot, yada yada.

I can give you an explanation why it is normally a requirement in the linux ecosystem in contrast to windows or MacOS which dont' require repositories. Repositories and their dependency resolution is the linux ecosystem solution to the problem of dependency hell. Repositories keep in centralisitc way system (OS) and apllications in sync and working. The solution in the windows and MacOS world is a stable API + bundeling of changing dependencies. Advantage of the second approach is that ISVs can create software which will work over a long time and can be deployed directly to users. This works as the API is garantueed and supported (by the platform provider) and the rest can be bundled. For linux there is no comparable stable modern OS API with garantueed GUI/multimedia/installation support across the linux ecosystem. Everything changes from distro version to distro version and is different form distro to distro. So bundeling is hard or impossible because some things can't be bundled, you would need a reasonable API. In short, the linux ecosystem forms unlike Windows (and to some degree Mac) NOT a open platform for binary software produced by ISVs. This is a serious design fault, rooting long back to unix history.

PS: autopackage was a approach 2006 trying to achieve what is existing for windows and mac since long time, working bundeling. But as it faced furious resistance by the distros ([url=http://web.archive.org/web/20090305035002/http://plan99.net/~mike/xmlpres/presentation.xml]http://web.archive.org/web/20090305035002/http://plan99.net/~mike/xmlpres/presentation.xml[/url]) the project was stopped. And up to now there isstill no solution.

PPS: about the Maia dev, as far as I can see he talked primarily about developing of software on linux. Which is a different topic than the support of the vast linux ecosystem with the development result, the binary software. Development is fine on linux, just the platform qualities are horrible.

Sorry to interrupt, but I'd like to draw attention to the wish I just created: Show which games use Wineskin/WIne

In light of the fact that Linux is a potential benefactor (with regards to WINE) in the same way that Mac games have been, it should be a logical step to support the recognition of WINE on the respective game pages where it has been used to create a Mac port. Really, Linux should be reaping the benefits from this already, since the WINE community is very Linux-centric (whereas it's progenitor, the Codeweavers community is Mac-centric).

The steam "solution" (still heavy struggeling https://github.com/ValveSoftware/steam-for-linux/issues?state=open) is an additional layer (bypassing all distro infrastructure), some form of excessive bundling + limiting the scope to only 2 specific ubuntu versions and one DE ("Steam for Linux is only supported on Ubuntu 12.04 LTS or 12.10 with the Unity") . Steam itself acts as centralisitic walled garden repro for the games (which is bad).

Edit: about indies... they try their best & fix broken packages regularly ;) multiple bundles per distros (count the number of packages in the humble bundle libary!), minimization of dependencies + clever selection of stable and old libs. For instance, try the well made loki packages now several years without fix, it is unlikly that a single one of them works on a recent distro. In contrast, most of normal made windows software for windows 95 still works fine up to win8.
voted.

related wishes for a better recognition of support projects / transparency for users
http://www.gog.com/wishlist/site/show_which_games_use_dosbox_or_scummvm

wine related
http://www.gog.com/wishlist/site/beat_steam_work_with_wine_to_make_all_windows_games_work_on_linux_and_work_well
http://www.gog.com/wishlist/site/wine_as_a_supported_platform

I just remembered another potential wish: "Add successful Mac ports to the tests on the WINE app database" (appdb.winehq.org).

I think this is the ethical thing to do on GOG.com's part, since they're not contributing financially.

But I'll leave the actual creation of such to when it can be made more eloquently than my current overtired state.

Thanks for the support! I Voted for the ScummVM one a while ago (it inspired mine), but I did just add my vote to the "WINE as a supported platform" wish. I felt it's stated directive was a bit more clear than it's duplicate.