Fragmentation isn't a real issue. Fragmentation is an issue which Apple invented to try and kill Android. A developer that knows what they're doing has absolutely no trouble creating a program that will run on any and all Linux distros.

Now, doing so may require fat packaging games into tarballs prepended with a shell script, and possibly along with all the dependencies, but suggesting that fragmentation is some sort of huge bogeyman is just plain wrong.

Now, there are from time to time small ABI compatibility issues that crop up with the kernel, but I've never found one that rendered a program unable to run reliably on the distro I was using. And truth be told, you just test to make sure it works with the most commonly used distros. There's ultimately so many users using just 2 or 3 distros that you don't even need to test any more than that.

Ultimately, GOG tests for XP, Vista, 7 and 8, that's a wider number of OS hardware combinations than you would require to support Linux properly.
If that's what they think, they really aren't in any sort of position to judge whether or not it's feasible. Judging it based upon a complete lack of understanding of the issues isn't going to placate folks.

Just take a look at how Codeweavers does it. It's a shell script with a tar file at the end and I've never had any trouble with it. They install directly to a directory in the user's home directory. Works with pretty much any x86 compatible distro. And they're not the only ones to do it that way.

Yes, it's probably not enough people to justify training staff, but I really don't think that making up excuses like that is a particularly professional way of making decisions.
LOL, it never seeks to amaze me when people think that a license which takes infects other code the way that GPL code does, isn't causing problems.

But, to each his own, I suppose.

I've installed a fair number of pieces of software like that over the years and I've never had any problems with it. Actually, I've had far fewer problems with it than I have had with regular packages because the proprietary packages were designed to be more resilient with regards to problems with other packages.

Unless you're trying to install a piece of software that really has to hook into the kernel, the worst you're likely to deal with is paths that are in weird places and static linking. Which for Gog games on Linux, you're largely doing anyways. Providing users with a particular install of Wine isn't fundamentally any different than providing Windows users with a DOSbox install for individual games.

Now, trying to use the same installer on different OSes is a completely different matter. And I'm not sure why anybody would expect that to work out well is beyond me.

This here and your last post is my problem with Linux users. User experience seems not to matter in the least; if you want Linux to be taken seriously as a consumer platform having a bash script that unpacks an archive in my home directory without asking me anything (or worse, having me specify a path as a command line argument) isn't the way to go forward.

As for trying to use the same installer on different OSes and expect it work, it's supposed to work because you'd different core implementations with the same GUI attached, so it's basically transparent for a user moving from Windows to Linux and backwards or in the future Mac OS.

Now I agree that the only example which comes to mind is the horrid in-house thing done by Adobe for the Creative Suite, which is the reason I'm tasked with finding a viable alternative to hand-coding our own implementation (the current candidate is InstallShield InstallAnywhere 2012 which is proving to be surprisingly good at everything we've thrown at it).

That's also what I think. Supporting the 2-3 major Linux distributions with a shell script installer somewhere in the user home would enable GOG to bring a fairly large number of games with little effort to a lot of Linux people. It seems they don't want the bird in the hand, but rather the two birds in the bush.

You can do anything in a bash script and that includes asking things (both CLI and GUI) to a user for specifying settings and whatnot. I don't see how this is any different from making installers on windows.

Anyhow I will repeat again, I'm not asking for gog.com to make Linux binaries available for the games that already have it (although that is cool), I'm just asking to provide compressed data for their WINDOWS games that don't require running the innopackage setup.exe file. That would make my life easier, just don't make it easily available (use web API and "hide" it from normal users) so people can't complain if it doesn't work. (and I get to work at my Linux installer scripts without problems, providing my linux users a service to make it work easily)

I don't think that they want to. I think that they think that there isn't enough money to make it worth their while. And if that's what they really think, I can't blame them for not wanting to.

But, smaller companies than Gog have managed just fine using a shell script install to the home directory without having revenue coming in from Windows or OSX users, so, I have a really hard time buying the idea that it can't be done. And I know of at least one company that was using a similar methodology to provide drivers for not just Linux, but FreeBSD as well.

What's more, the folks over at codeweavers have managed to create a bottle system. Now, Mr. Gog may not be willing or able to afford to license Codeweavers to do the port or license their software to do it themselves, but Wine can clearly be installed in such a fashion.

I just wish that they would admit that they don't think there's enough potential sales to make it worthwhile. That's all they have to say, this is a business, if they can't turn a profit on Linux support, then I don't think anybody here is going to blame them. But, I do have a real problem with the false dichotomy last time that doing something like a shell script installer would somehow undermine their integrity.

I should probably stop coming in here. All this talk about it being difficult or impossible is making me mad like the idiots that insist that there isn't an adequate replacement for AD for *Nix

You missed the point. No one in this thread questions the technical possiblity. Question was if the philosophy of the linux ecosystem of continous changing parts is enough compatible with the pilosophy of gog.com which tries to providing a stable, simpel and satisfying user experience.

And what can be done to reduce this (small or not so small) gap, to reduce the adapation treshold for gog.com.

I see.

First off, I'm not a Linux user. So, you can put away the bullshit ad hominems.

Secondly, this is a game store that focuses on games that are mostly at least 8 years old or older. And you're trying to convince me that people are concerned with form over function? Are you kidding me? I've seen more bitching on this site about Mr. Gog bringing new games here than most other things.

Thirdly, there's nothing stopping Gog from writing a simple installer with a few dialogue boxes if it's really that big of a problem. Even without going to the trouble they could script a few questions about where one wants the files. But, as a general rule, the home directory is the correct place for such files, unless one is planning on sharing with multiple users on the same machine. And that rarely works out well on any platform I've ever used.

If you're going to bitch about Linux users, you could at least bother to do some research before you mouth off. Linux users can focus on functionality because the OS actually has some. Windows is missing all sorts of basic functionality, just to force people to pay too much for an upgraded version.

? What basic functionalities are missing from Windows?

Not really, I see a lot of bullshit rationalizations of why it's harder to support Linux than other OSes, and honestly, it's based largely on ignorance. Nothing about it is difficult and smaller shops than GOG have managed just fine.

As I said before, if Mr. Gog doesn't think there's enough users to make it worthwhile, that's fine, but lying about the difficulties is not something which is going to wash.

Speaking strictly on the point quoted above. The main issue with that is that it looks like crap, and I really mean like crap compared to any other decent installer out there. Let's not kid ourselves that a GUI done in a terminal will ever look good.

Besides this one point that's more about the user experience is another important one which people seem to miss when it comes to software development in general: you're duplicating effort! I already have all the pages of the installer done for Windows along with the logic behind them and other related assets (images, etc.), why should I have to start from scratch when doing the Linux installer? And why should I do that and come out with something that's crappier and more prone to breakage? Why reinvent the wheel?

That's the thing you're missing, it's not about it "being different from making installers on Windows" (despite the fact that it is, at least from a UX perspective), it's about requiring more resources for little benefit.

Heck, that's one of the major reasons I earn a paycheck every month, to prototype, implement and judge different installer systems out there and find out if we can find something that's reusable across platforms so we won't have to duplicate our effort and double our support costs. Maybe with the money they're paying me in the short-term they could just write their own engine (or hack together a bash script), or keep on using the current Java abomination that they're using in Linux so that it at least looks and behaves consistent between Linux distros, but guess what, in the long term they'd still have to support two completely different code-bases which translates into money spent.

Also, what if I'm using a modified version of bash? Are you sure that your script will work correctly? In the end, your #!/bin/bash only forces to script to run in that particular shell no matter the current running one (I'm partial of zsh myself), but doesn't check to see if it's the sane/default bash shell.

It's easy to talk about things in a vacuum, and it's even more simple to completely disregard user experience, but in the long term trust me that this will come back and bite you in the ass, HARD!

Well, trace, the ability to mount images, the ability to change the system fonts to pretty much any language you want. Mind you, those are the ones that spring to my mind, there are others as well.

If you want to have a full OS, they expect you to shell out a ton of money for it.

You really consider the ability to mount images a basic functionality? Really? Fucking really? I mean, my mind boggles here.

You sir have a widely different understanding of basic than the rest of the world it seems.

I wasn't talking about GUI terminal (which isn't "GUI", really hehe), I was talking about real windows popping out and asking you questions. You can do all of that in bash (see: Zenity for example) and the look is platform dependent, it depends on your desktop environment. If you have an ugly look -like I do haha- then it will look ugly but consistent with your OS.

as for the rest... honestly that's a moot point, I have never used gog on Mac but I'm pretty sure they had to re-write a big chunk of their installer to get it working on Mac... and OSX isn't that different from Linux so they could re-use that. It's not reinventing the wheel, it's more like planning ahead and not making one software that is going to be locked in a single platform and then complaining later.

But I'm pretty sure that's not their main issue, really, it's a rather naive and irrelevant one. It took me 3 days to develop a fully functional UI/installer for gogonlinux using python (and I had never touched a single line of python before), I'm confident the gog developers are much better at this than me.

EDIT: To answer to the last question.. no, #!/bin/bash forces you to use bash which exists on any Linux distro (even non-linux ones). Even if you use zsh, tcsh or whatever for your own terminal emulator, you will still have bash installed and if I call a script with #!/bin/bash then that will work as indented. Plus, there are POSIX standards for the shell (admittingly, bash has extensions not supported by other shells and not POSIX) and you can adhere to that without problems.