I wonder how all these other newer games that offer Linux versions of their games manage? Do they offer different subversions for each Ubuntu and each other flavor or have they found a way to mitigate all these Linux differences? These and the Dosbox games, I cannot really understand where the big technical difficulties are supposed to be.

Just one example: Netbeans only has one installable for Linux and it is a shell script. Why aren't they suffering too from all these problems?

No they don't. They mitigate it, I believe, by including the libraries they use.

This is how Steam for Linux works too, but you can provide an environment variable where it will use the system libraries instead (which yields better performance at the risk of things not working/crashes).

Unreal Tournament 2004 still works fine for me and has done on every Linux OS I've played it on.

Official support is not an option. GOG isn't as big as Steam and thus they don't have such resources but I really have no idea why they can't offer the needed files with an added disclaimer that they don't offer any support for the linux users. I imagine the average Linux user who's into gaming, not your Mom or Dad using Ubuntu (obv nothing wrong with that distro) is usually at least somewhat computer savvy so could easy solve all the problems either by himself or asking a linux dedicated community. I really can't see how this could hurt them, unless we assume that people are stupid and would spam their support and flame the forums anyway?

You are right, it's not impossible to workaround "many" problems and pitfalls and make fairly robust releases...but it is very hard, requires non-obivous in detail knowledge and is still not bulletproof .
As it is hard, we have only a handful of skilled enough porting programers to linux which have handled 90% (?) of the humble bundle linux builds : ryan gordon, edward rudd and Ethan Lee

The Osmos developer Dave Burke wrote about his experience on porting a game to linux, fairly good read of a first hand experience. http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/

Me and another user have even volunteered to be the "Linux Support".. so we'd receive the support emails relating to the Linux gamers.

This is pretty much where GOG could let the community show their stuff in an even more public way..

"We don't officially support Linux versions due to a lack of resources, but as several community members have volunteered to act as support, we do provide the files as extras".

Not me, Parallels works very well for my gaming needs. I have been toying with Crossover for a few.

I used to have a Boot Camp partition, but I almost never booted into it (once a year, at best?), it was a waste of a Windows license (though I could use the same one in Parallels or VMWare) and disk space. Especially disk space, if you have to reserve enough space for your game installs it becomes more of a burden. When you use a VM for that kinda thing it's a little more flexible.

I do have a pretty hefty iMac though, with plenty of GPU power, RAM and CPU. So I don't notice VM overhead too much. The hard drive can be a bit of a bottleneck though.

That being said, I rarely get Mac-specific games, for point (a) on your list. I get indies that are multi-platform, or Steam games that have Mac versions. If there's an option, I *always* play the Mac one, so I don't know why I shy away from Mac-only ones (I shoulda grabbed the X3 deals a few days ago).

I guess I kinda have small hopes that I will play on my Linux HTPC in Wine someday.

Shaddim pretty much took the words right out of my mouth and said it 100x better than I could have.

I don't think most people appreciate how challenging it can be to make a binary-only release that works across multiple Linux distributions or versions of a distribution. I've wrestled with almost all of the issues he's mentioned here, along with a few others he didn't, and all of my "solutions" ended up being hacks.

I'll tell you a secret: windows faces the same issues and solving them is kludgey. Does this look like something that was engineered ? It's been tacked on to solve some of the issues people throw in our faces when complaining about linux.

http://en.wikipedia.org/wiki/Side-by-side_assembly

Interesting, another first hand experience. Would you like to elaborate some of the other issues which had arised for you?

Well, no ones denies that the windows ecosystem has flaws too... but their flaws can't be an excuse for 1-2 decades of stagnation on the way of forming a viable platform to be addressed by ISVs. Windows made his homeworks, the DLL hell is gone... while the distro fragmentation is more alive then ever on linux.

GOG will support Linux when pigs fly in a frozen hell with a church in it.

The most prominent issue I've encountered was with library/symbol versioning, particularly with glibc, which you cover pretty well. While Ubuntu seems to be fairly up to date with glibc versions, other distros are still using old versions with some fixes ported in and others not.

In cases where I resolved the versioning, I ran into handfuls of other problems. In one case, I encountered a BAD pthreads bug in earlier versions of glibc that had not been fixed in a relatively recent distro. I spent a good day or two trying to figure out what was wrong with my code, when the bug existed in glibc. In other cases, I encountered ABI compatibility issues and crashes that occurred during loading due to changes in the ELF format. I had a few other obscure issues that I don't recall off the top of my head, but those three were the ones that stuck in my mind and occurred the most consistently.

I would imagine these problems become more pronounced as you use libraries that have less consistent APIs and behavior, particularly those with any kind of kernel mode interaction outside of standard system calls. For what I have done, I've only needed to use standardized libraries, so nothing with that type of interaction. In one case, I got tired of trying to deal with finding the right shared object dynamically and just distributed a SO of the problematic library, then dynamically loaded it. There was much swearing that day, because I shouldn't have to do that for a library that's guaranteed to be on the system already.

To be honest, after about a week of trying to get some of my applications to run on multiple distributions, I gave up. I'd resolve one issue, only to have another rear it's head. They are all internal applications, so the solution was to just tell people to run them in a VM if they used a different distro or compile from source. Oddly enough, none of the issues I encountered could really be resolved via code (aside from the pthreads nonsense), almost all of them were related to stuff the compiler did and the ELF format, so compiling from source almost always worked.

If anyone missed, the major thread about it is here: https://secure.gog.com/forum/general/linux_support_on_gog

Good read, thanks. About the varying Pthread patch level in the glibc I was not aware of.

And as additional hint, if you still have a in-house deployment use case where some performance losses are acceptable (you used system virtualization), Philip Guo's CDE might be an good appoach for you. It's an clever application level virtualization approach, fast and easy to create and pretty robus. Software is better intgrated than with system level virtualizationt. http://www.pgbovine.net/cde.html

I recommend also Guo's (a computer scientist, wrote his PhD on this topic) insightful Goggle techtalk http://www.youtube.com/watch?v=6XdwHo1BWwY

I'm always baffled why so soledom (or never?) someone sees the burden of change on the shoulders of the distros? Why the ISVs has to cope with this crap? The distros should FINALLY come to the point providing a unified linux platform, they had now 15 years (and several initatives e.g. LSB) ... my tolerance towards them is exhausted.

a simple and reasonable start point... I agree

Yes and yes. http://www.gog.com/news/gogcom_soon_on_more_platforms