It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
Community
General discussion (archive)Is the Linux ecosystem ready for gog.com?(211 posts)(211 posts)
(211 posts)
Pages:
1
5
7
8
9
10
11
15
This is my favourite topic
Posted December 13, 2012
avatar
Kristian: The forest is GOG's seeming irrational ill will toward Linux to the point of them not even wanting to distribute ALREADY existing Linux installers/binaries as unsupported extras despite willing to do the exact same thing with for example The Lady, The Mage, and The Knight tech demo distributed along side Beyond Divinity.
avatar
rampancy: The point he was trying to make is that the fragmentation issue is real, and a mental gaffe like the one you've latched onto doesn't make it go away. I mentioned putting up .DEB and .RPM packages as a potential solution, but I know there are other package managers out there, and a lot of users would likely cry foul for not having their preferred package manager not being supported.

People calling for GOG to throw up Linux binaries seem to imply that said binaries will work universally on all systems across all distros and hardware configurations; or at least, that we can assume the same level of hardware/OS homogeneity that we can for Windows or OS X. Is that actually a valid assumption to make across Linux as a whole?

I also don't buy the argument around the Beyond Divinity tech demo. Simply because...it's a tech demo. It's not a full game, nor is it a binary to get a full game working on a previously unsupported OS. If they did do something like put up the original Mac OS 9 releases of games like Shadow Warrior and Duke Nukem 3D up as extras, then yes, I'd fully agree with you. But they haven't.

And finally, it's really time to stop assuming that GOG has some kind of anti-Linux agenda or that they somehow hate Linux users. There's absolutely nothing at all from them, officially, unofficially, explicitly, or implicitly, to suggest that they're not supporting Linux out of petty spite. They made that decision because in terms of their own business calculus, the gains aren't worth the potential risks. Acting like GOG is somehow engaging in some anti-Linux conspiracy isn't going to help them change their minds.
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.
avatar
Spongeroberto: I'm a bit fuzzy here, why would the Linux ecosystem need to be 'ready' for gog?
avatar
Miaghstir: Because GOG doesn't want to simply put up a .tar.gz file that the users have to figure out how to extract/install themselves (or even .deb and .rpm packages), but a single shiny installer that works everywhere it's supposed to.

(My guess for what they'd like: the simpleness of a .deb/.rpm with the universality of source.tar.gz, coupled with some nice GOG.com branding throughout the installation process.)

But no, it's not GNU/Linux that need to be ready for GOG, it's GOG that needs to make a decision and work out how to support GNU/Linux and whether the gain is enough for the cost needed. For now it seems they've either decided that they do not have the capacity/capability to give GNU/Linux the level of support they'd like (even if that may be a higher level than most vocal people are asking for), or that the cost of doing so would be too high.
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.
avatar
imAgi: Linux plays nicely with others, it is the others that have the problem/need to be ready.
avatar
Snickersnack: Eek!! Don't say that in front of the BSD guys!
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.
Post edited December 13, 2012 by hedwards
Posted December 13, 2012
avatar
orcishgamer: Oh fuck it, even IBM's shell scripts aren't "right" on all systems. I wish people would quit acting like installing proprietary and complex software is always so easy, because sometimes it just really isn't.
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.
Posted December 13, 2012
avatar
orcishgamer: Oh fuck it, even IBM's shell scripts aren't "right" on all systems. I wish people would quit acting like installing proprietary and complex software is always so easy, because sometimes it just really isn't.
avatar
hedwards: 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).
Posted December 13, 2012
avatar
hedwards: ....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. ...
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.
Posted December 13, 2012
avatar
AndrewC: 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.
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)
Posted December 13, 2012
avatar
hedwards: ....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. ...
avatar
Trilarion: 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.
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
Post edited December 13, 2012 by hedwards
Posted December 13, 2012
avatar
hedwards: 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.
Post edited December 13, 2012 by shaddim
Posted December 13, 2012
avatar
AndrewC: 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).
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.
Posted December 13, 2012
avatar
hedwards: 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.
avatar
AndrewC: This here and your last post is my problem with Linux users.
avatar
hedwards: 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.
avatar
AndrewC: This here and your last post is my problem with Linux users.
*sigh* I'm also baffled. It's surprising how uncritical a vocal group of the linux users still is, even in the face of obvious serious problems (Someone just read one of the references?).

Maybe some kind of geek proud "I can cope with that crap, so I'm a hacker, great!" And maybe also some kind of misfocussed loyality "I adapted to that, so you have to stand that too!" Seems the denial of problems ("There is no problem...at all!!!") is still strong, also in the (not so hardcore) gog.forum, sadly. There was also the opposite reaction, some kind of frustrated(?) acceptance ("Yeah, there are serious problems, since years... unlikely fixable.") by some people (now mac refugees?).

No one was going into my specific question if "zeroinstall", "autopackage" or some other approach could lower the adaption threshold for gog.com. What happens with the middle ground position between the two polarized reactions? People which believe that re-adjustment and adaption is possible, required and normal...also for the linux ecosystem?

(PS: I really appreciate the "linuxongog" initative by Morgawr, a active step at least. Irritatingly, adpation was only requested from the gog.com side, again some misfocussed upstream-downstream distro thinking which plainly will not work out & and also misses the big problems :/ )
Posted December 13, 2012
avatar
hedwards: 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?
Posted December 13, 2012
avatar
hedwards: 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
avatar
shaddim: 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.
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.
Posted December 13, 2012
avatar
Morgawr: 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.
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!
Post edited December 13, 2012 by AndrewC
Posted December 13, 2012
avatar
hedwards: Windows is missing all sorts of basic functionality, just to force people to pay too much for an upgraded version.
avatar
JMich: ? What basic functionalities are missing from Windows?
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.
Posted December 13, 2012
avatar
JMich: ? What basic functionalities are missing from Windows?
avatar
hedwards: 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.
Posted December 13, 2012
avatar
Morgawr: 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.
avatar
AndrewC: 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!
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.
Post edited December 13, 2012 by Morgawr
Pages:
1
5
7
8
9
10
11
15
This is my favourite topic
Community
General discussion (archive)Is the Linux ecosystem ready for gog.com?(211 posts)(211 posts)
(211 posts)