Oh, I did love the package systems for the distros I tried. Until I ran into something that wasn't in the system, and WINE had issues, and I have a time limit for how long I'm willing to spend fighting the OS for any single program. So now Linux stays on my old PC I converted into a server.

There are some really nice things about Linux that I wish Windows would emulate. And there are some things that I wish Linux would add in from Windows. I haven't found Linux to be consistent and flexible enough to do all the things I do on a daily basis though.

With tech support, a small percentage of customers cause most of the problems. Linux proponents here and elsewhere don't seem to acknowledge that Linux is actually a huge support headache for developers and publishers.

I guess part of my stance on this is having seen quite a lot of virulent and angry Linux supporters who can't stand anyone not liking their OS. So there's that history feeding into my position on this.

Linux is a support headache for those who have no experience in it. GOG will learn. Windows is the same headache to support if you never did that before. Linux has more diversity to address, requiring one to think through a proper distribution method. But that's already a solved problem, not some new unknown challenge.

No it's not "a solved problem".
There is a significant conceptual difference between linux and windows (and MacOS and... android, surprise) which makes linux ecosystem (aka "the jungle of distros") support still a pain in the ass.

It's the missing separation between core and apps. The aspect which is meant if someone talks about "platform", a stable and reliable base (formed by APIs/SDKs and binary compatiblity over years) where apps can be developed, deployed and easy supported also by third-party developer. This is completely missing in the linux world, instead we have there monolithic distros... baking everything centralistic together. and on top of that the fragmentation among all distros.

This was (finally?) also noticed by Ubuntu's Shuttleworth (http://www.markshuttleworth.com/archives/1246)
Marc Shuttleworth: "Separating platform from apps would enhance agility. Currently, we make one giant release of the platform and ALL APPS. That means an enormous amount of interdependence, and an enormous bottleneck that depends largely on a single community to line everything up at once. If we narrowed the scope of the platform, we would raise the quality of the platform. Quite possibly, we could place the responsibility for apps on the developers that love them, giving users access to newer versions of those apps if (and only if) the development communities behind them want to do that and believe it is supportable."

(and noticed several times before, e.g. Ian murdock http://ianmurdock.com/linux/software-installation-on-linux-today-it-sucks-part-1/ or this http://www.diytechtools.com/blog/2012/09/29/736/736/)

Yeah, the individual experience will be vastly different depending on the programs involved.

I'd rather have GOG developing a way to run early Windows games so we can start getting those released. That's going to take a lot of development resources.

Excellent that this is getting more attention! This is exactly the problem I've had with Linux. The best word to describe it is rigid, I think - very strong inside the accepted paradigm, but easily broken once something different is tried.

It is a solved problem - don't beat a dead horse. Steam solves exactly that, even though they chose an overkill method to do that (they expect a huge "runtime" to be present). More modest method is to ship only those libraries which are required for the game (SDL and etc. for example). This is solved. If you think it's not - you didn't develop any games or didn't talk with developers about it.

Real (and not imaginary) problem is the shift in the graphical stack on Linux which is happening now. Xorg is going to be replaced with Wayland. Add to that the whole Mir mess introduced by Canonical for Ubuntu. This might disrupt things. And even here, if developers use SDL and other higher level APIs without going directly into X anywhere - it won't affect their games much.

Data suggests that people don't think it's a solved problem. Including Mark Shuttleworth, and if anyone would know it would be him. Including all the needed code isn't solving the problem, it's doing an end-run around the problem. It probably works (I don't have Steam), but it's not an elegant solution.

Yup, the continual shifting is part of the problem. You can't support something that changes constantly. Even using higher-level APIs, those APIs have to change to support the new stack, so there's going to be a support gap where distros using the new graphical stack won't be able to run the old games until the APIs catch up. That's never a good situation to be in.

There is no "elegant" solution, there are practical ones. Bundling is one way. Having a standard base is another, but much harder to achieve (LSB and etc. just didn't work out). Therefore bundling is something you can use here and now without theoretizing how hard it is to come up with a perfectionist approach.

Wayland kind of shifting is not continuous. It's a huge change that was looming and now is actually coming. It coincided with the rise of Linux gaming which makes things more challenging, but not impossible.

And if you rely on stable APIs (SDL, ALSA and etc.) then they abstract the underlying changes for you.

I don't consider Steam a solution, for technical and for political reasons: it's a ugly entangled wrapping layer on top of all the mess (not really "overkill" as other solutions without distro cooperation won't work ) and second it's an walled garden ecosystem.

If you speak about bundeling approaches (, [url=http://0install.net/]0install, ), I'm a fan too of them, but some minimal cooperation ("support") by the distros is needed. What I have seen up to now was more a active sabotaging of such approaches, most infamous the shot down of autopackage ([url=http://web.archive.org/web/20080331092730/http://www.linux.com/articles/60124]Autopackage struggling to gain acceptance).

This solves would only a small subset of the incompatbilities arising between various distros... if it would work, e.g. 32bit/64bit binary app deployment is still problem on linux while 32bit stuff work flawless out of the box on 64bit windows (FatELF could have helped here... but guess what, shot down by traditionalists).

First of all, most Linux gamers use 64 bit distros these days. 32 bit just don't cut it anymore. While some support is good, I wouldn't worry about it. One can even dare to release 64 bit only - 32 bit is becoming obsolete.

That if we are talking about high end gaming on x86_64 of course. On embedded the situation is quite different yet, and for ARM / Atom one has to release 32 bit binaries so far. But Linux gaming on ARM is practically non existent (and I'm not talking about Android, I'm talking about normal Linux like Sailfish, Nemo, Plasma Active, Ubuntu Touch and etc.).

About packaging, I liked how Torchlight for Linux was packaged and bundled. Really good job.

Indeed, I'm also positive about that too...finally something moves :) There are even more positive signs: Chakras semi-rolling release model is infact the separation between core and app (allowing slow core progress and fast progressing apps) The Half-Rolling Release Model Or gnome OS with [url=https://people.gnome.org/~alexl/glick2/]glick2[/url]

This is typical nerd techno-enthusiasm (relevant xkcd comic)... linux defined 32bit deprecated years ago without good reason... and still most applications don't need it nor have most user a clue why the could need it.
Best reason not to go 64 bit is compatibility... the reason why the the steam client is 32bit. The beauty of wide compatiblity is not well understood in the linux domain.

PS: torchlight was also the game without heads for half a year on linux (worked everywhere else fine http://forums.runicgames.com/viewtopic.php?f=24&t=33360&start=60) and about stable APIs (you mentioned SDL) mouse is broken now because of... SDL broke mouse support, such regressions are unheared with dirextX (http://forums.runicgames.com/viewtopic.php?f=24&t=33360&start=60#p474739)

About need to support 32 bit - tell that to developers like CDPR with their Witcher 3 and Cyberpunk 2077. They'll laugh and... anyway will release their future games as 64 bit only. Time to wake up.

Didn't see any problems with SDL in Torchlight, and heads bug is fixed, I tried Torchlight recently, it worked fine. To avoid such things they had to bundle SDL, I thought they already did.

After half a year... and they broke something else. This was not a seldom case or a exception, I would argue, such problems and regressions are characteristical for the over-complicated and fragmented linux ecosystem with binary deployed apps (e.g. therefore I'm not surprised to see no reduction in the number (nearly 1000) of open issues over time with steam on linux ).

DirectX also has regressions, otherwise GOG wouldn't spend time adjusting older games for recent Windows. It's business as usual. Anyway, such regressions aren't common. That mouse regression is strange.

So the last three consecutive releases on GOG (the Penumbra series, Amnesia: The Dark Descent, and Brütal Legend) all have Linux clients, but are obviously not available on GOG. This is becoming irritating.