^^ I'm pretty sure that majority of GOG's current linux users are not expecting "a polished experience without hassle" but would settle for an already made linux port as an unsupported extra. It would be a start at least.

It's a different thing if SteamOS/ChromeOS/WhateverOS really takes off and market share widens. Then there might be a lot of new *nix users who expect things to work just like in Windows.

Also I still don't get the "we'd have to support at least 5 distros"-thing. Why?
"We don't want to limit the choice of OS" You're limiting the choice of OS right now.

It's perfectly fine to support just one, just like Valve does. This might be news to GOG but even if Steam supports only Ubuntu LTS, I can very easily install it on Fedora, OpenSUSE etc. which are not even Debian-based.

But we've been through this already, about a hundred times.

Wine doesn't currently support DirectX 10 or later (unless I'm mistaken) which rules out using it to speed up the porting process for newer games; many of the big-name releases in 2013 required DirectX 10 and the percentage will rise dramatically for 2014 onwards.

And other, great developers said that fragmentation isn't an issue at all.
https://icculus.org/SteamDevDays/SteamDevDays2014-LinuxPorting.pdf#page=7

And that's the problem with "authorities", what do you do when two disagree?
You always quote the one that supports your own view and yes, I do the very same, we humans are like that.

Steam, however, proofs that most issues come from differing library versions, which can easily be mitigated by shipping them with a game/the platform. It's not so different under Windows, too.
Some DLLs are always shipped with a game, to make sure that it works on Windows XP up to Windows 8, for example.

Normal developers are not Icculus. The point is: the linux ecosystem makes it unreasonable and unneeded hard (but not impossible). This problem could have been fixed easily in the last 10 years but wasn't for policial reasons. For instance, for the mentioned library variations, a solution was developed some years ago, called Autopackage, basically bundeling as you describe it. But this project was shot down...like other projects who aimed to make the linux ecosystem better addressable for binary software.

Steam is another bundeling approach, proving that the distros are not addressable in any meaningful way...the only way seems to be bypassing them by bundeling. Meaning, the distros are not part of the solution but are just the source of the problems - since long time.

Autopackage was shot down because, architecturally, it was an eldritch horror.

Yes, Linux can be frustrating, but a lot of it stems from the segment of the developer population that believes it's better to take forever to get a solution than to enshrine an ugly one and have to support it until the end of time for compatibility reasons.

Hence the "If you don't want to wait, bundle it so we don't have to support it" attitude.

It was easy for applications to use but it was an eldritch horror in how it accomplished what it did. Hence, push-back from the platform side of things.

Good point. There is an epidemic of that. (I switched from KDE 4 to LXDE because of it and jwz wrote about the same thing in GNOME.)

I'll give you FatELF and distro packaging. Those are both unarguable cases of nasty politicking.

However, I wasn't considering them relevant because I don't see offering two binaries and a "detect the arch" launcher script as a problem, given that most games need a script anyway to work around the fact that Windows ports usually assume that $PWD will indicate the parent directory while Linux launchers use it to indicate the user's documents directory.

As for glibc, it's maintained by Ulrich Drepper, the man who said "Stop wasting people's time! Nobody cares about this crap." in response to a patch to fix the skewed random distribution of strfry(). There's a reason Debian uses the EGLIBC semi-fork now.

I really hope that, as musl-libc continues to fill out its peripheral feature set, someone decides to add some compatibility symbols and get distros to migrate to it. It explicitly takes a forward-compatible approach. (It's already pretty complete, as the chart on the site shows.)

No argument there. Icculus and I both agree that only fools or people with a lot of time on their hands offer distro packages.

I think Trine 2 is the most elegant Linux offering I've yet seen. (Unpack the tarball and the game has a first-run wizard which offers to install a launcher menu icon)

...but my install.sh script which users can double-click to add a launcher and desktop icon is also a good way. (The developers just fill in 8 variables in the script and it does the rest.)

Also, I prefer tarballs to binary installers because, for stuff not managed by the system package manager, I prefer the MacOS-style "Just delete the folder to uninstall" approach.

Well so far i have bought about 90 games here.
So i voted for no drm with my wallet.
Now i will vote for linux with my wallet on the places that promote linux games.

Were did you get that?
Tell me one indie game that needs DirectX10, all I know work with DirectX9 or OpenGL,
because that's what WinXP has to offer and a lot of people still use WinXP.

Gog would only have to support Debian and the rest would be handled by the people anyway.

He didn't say one thing about indies. He suggested that "big-name releases" are transitioning over to DX10 which wine does not support. One could argue the transition has been slow, but the idea that at some point devs are going to stop worrying about making DX9 and DX10 versions of games is perfectly reasonable. DX10 adoption has been extremely slow, but if you are suggesting it will never move into mainstream acceptance (especially now that XP support is on the copping block) then I think you're off the mark.

Given that, the idea that Wine can just be some magic band-aid for mass porting is extremely problematic, as well as putting Linux back in the same position that it always has been as a platform that can be ignored, not programmed for, and left to take care of itself. I'm surprise J.C. thinks it's a good, general solution to the problem. Maybe he is imagining a more perfect world version of Wine that doesn't have near the issues it does, but Wine is nothing more than a stop gap/fill-in measure that may be nearing the end of its beneficial growth. I mean, how can a platform claim to stand on its own if no body is actually coding for it? All that means is people can keep not thinking about the ecosystem at all.

Wine is fascinating tech, important tech, but when it comes to emerging software it's a transition piece not an end game.

And to add to the lack of DX10 being a problem, the lack of proper xInput support is another big issue with not actual remedy in sight.

Why not? Adopting DX10 is not a nature law... Several "innovations" pushed for dubious reasons by MS were rejected by the market before, why not DX10?

That's skewed point of view: Wine is (mostly) not a emulator but a implementation of a API, and therefore native to the linux domain. As Linux defined not a similar comprehensive API, why not adopting a existing one? One with existing tools, competence & big software stack already... it makes sense to go for Wine.

Nobody must adopt DX10, I was just stating that it is not wild speculation, or outrageous for someone to believe that it will eventually supplant what is now an extremely old API. While the existence of shaders puts a lot of possibility in the control of devs (instead of trusting an API to deliver new effects) that doesn't mean DX9 will realistically remain the de facto standard forever. Maybe DX10 never takes over, but what happens in a couple of years and DX12 comes out and ends up being a decent product people want to get behind? The problem isn't that DX10 isn't supported after years of it existing, it's that ANY new API is going to have to be dealt with, and that if the entire Linux Gameing Ecosystem is dependent on Wine then it's asking for lag times at the very least. DX10 has been around for years now, and if WIne hasn't been up to the task of supporting it yet. What are the odds it is going to deal gracefully with any new emerging API changes?

And your right me being skewed. Skewed in the sense that I don't think it is inherently healthy for Linux to be wholly reliant on another platforms software. At some point you aren't even running another OS so much running Windows via some Open Source Proxy. I certainly can see how it is an advantageous solution from a business perspective in some situations, and opens the doors to the past, but that doesn't mean it should just be the way to go. I think an OS needs native software to be whole and stand on its own. Sure it needs to get to that point, and Wine is a way to get there, but it's not a destination.

Because the latest gen consoles have arrived and official XP support is almost over.

We'll be seeing a lot more shader model 5 and 64bit games for those reasons. Nevermind the fact that PCs have been capable of 64bit shader model 5 for years, because the industry has been advancing with the consoles. With Windows that means DX11 unless another API takes over.

I wouldn't mind seeing OpenGL supplanting DX on Windows, though. Linux, Play Station, Mac, Steam OS...let it dominate Windows too. I've noticed better performance using OpenGL over DX with games that use multiple renderers. Plus that removes some leverage from MS because they use it to help obsolesce their OSs and lock-in vendors.

AMD have released Mantle, but we'll have to see where that goes. Let Xbox have its DX. :P

They <span class="bold">are</span> working on DirectX 10 support... it just got slowed to a crawl because they want to focus on the Direct3D command-stream rewrite first. (Their work to rewrite the translation layer so the D3D->OGL conversion can happen on a separate thread.)

There is a patchset you can try... they just haven't finished squashing regressions in it and cleaning up the code for merging into mainline. Current tests show that, if you've got more cores than the game would use under Windows, some games now even run faster with Wine than Windows with the patchset applied.

Once they've got that done, their focus will shift to DX10/11 and optimizing the translation layer. (At the moment, with stock Wine, you can expect about 50% of Windows D3D9 performance.)