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

×
avatar
gooberking: When did we get to, Cross platform installers are hard screw Linux? I thought we were looking for some way to make games run on it, not pursue some utopian idea of how to get one installer to work for everyone. Baby steps.
Infact, my question was not aiming at the technical feasability (which exists no doubt). My question was aiming the "quality of service" definition and philosophy difference between gog.com and the linux ecosystem (or the distro/unix/FOSS way of doing things) & and how this can brought more near together.

Selecting one sub-ecosystem (e.g. Ubuntu 12.04) and expecting that some fuzzy community fixes the rest is a approach which might even work out technical, but is hardly compatible with the self-understanding of gog.com as service provider himself for a convenient, stable & simple gaming experience.

Therefore, what can be done that gog.com find it's place in this ecosystem, that gog.com can provide his services with feasible effort in the linux ecosystem?
Post edited December 13, 2012 by shaddim
avatar
gooberking: When did we get to, Cross platform installers are hard screw Linux? I thought we were looking for some way to make games run on it, not pursue some utopian idea of how to get one installer to work for everyone. Baby steps.
avatar
shaddim: Selecting on sub-ecosystem (e.g. Ubuntu 12.04) and expecting that some fuzzy community fixes the rest is a approach which might even work out techncial, but is hardly compatible with the self-understanding of gog.com as service provider himself for a convienent, stable & simple gaming experience.
I wouldn't call them "fuzzy community fixes", really... Software development cycle (after a release) is all about having people test your software and report bugs so you can fix them. This wouldn't be any different. Look at how Steam is handling their Linux client, they opened the beta for Ubuntu users, anybody else who wanted to get Steam to work on Linux (on their own distro and not ubuntu) they were free to try. Just don't expect official support from Valve.

Then, eventually, Steam got onto the AUR packages (as far as I know) and more users in the community submitted tutorials, patches, bug reports to get Steam running on non-Ubuntu systems.

The point I'm trying to make is that you can just target Ubuntu as a "universal" distro (since it's what more newbie users use) and anyone else who doesn't use Ubuntu (which I assume is more experienced) can surely follow a tutorial written by somebody else.

If Steam can run on Linux (read: Ubuntu) then gog can as well, especially considering the whole gog architecture is much much simpler than Steam.
avatar
shaddim: Selecting on sub-ecosystem (e.g. Ubuntu 12.04) and expecting that some fuzzy community fixes the rest is a approach which might even work out techncial, but is hardly compatible with the self-understanding of gog.com as service provider himself for a convienent, stable & simple gaming experience.
avatar
Morgawr: I wouldn't call them "fuzzy community fixes", really... Software development cycle (after a release) is all about having people test your software and report bugs so you can fix them. This wouldn't be any different. Look at how Steam is handling their Linux client, they opened the beta for Ubuntu users, anybody else who wanted to get Steam to work on Linux (on their own distro and not ubuntu) they were free to try. Just don't expect official support from Valve.

Then, eventually, Steam got onto the AUR packages (as far as I know) and more users in the community submitted tutorials, patches, bug reports to get Steam running on non-Ubuntu systems.

The point I'm trying to make is that you can just target Ubuntu as a "universal" distro (since it's what more newbie users use) and anyone else who doesn't use Ubuntu (which I assume is more experienced) can surely follow a tutorial written by somebody else.

If Steam can run on Linux (read: Ubuntu) then gog can as well, especially considering the whole gog architecture is much much simpler than Steam.
No pun intended with "fuzzy communities"... I was meaning it in role defintion way. The "community" is some non-garantueed, fluktuating/changing & and also additional player in the context of:
ISV -> publisher (gog) -> user
to
ISV -> publisher (gog)-> community(maybe?)->user
avatar
Morgawr: I wouldn't call them "fuzzy community fixes", really... Software development cycle (after a release) is all about having people test your software and report bugs so you can fix them. This wouldn't be any different. Look at how Steam is handling their Linux client, they opened the beta for Ubuntu users, anybody else who wanted to get Steam to work on Linux (on their own distro and not ubuntu) they were free to try. Just don't expect official support from Valve.

Then, eventually, Steam got onto the AUR packages (as far as I know) and more users in the community submitted tutorials, patches, bug reports to get Steam running on non-Ubuntu systems.

The point I'm trying to make is that you can just target Ubuntu as a "universal" distro (since it's what more newbie users use) and anyone else who doesn't use Ubuntu (which I assume is more experienced) can surely follow a tutorial written by somebody else.

If Steam can run on Linux (read: Ubuntu) then gog can as well, especially considering the whole gog architecture is much much simpler than Steam.
avatar
shaddim: No pun intended with "fuzzy communities"... I was meaning it in role defintion way. The "community" is some non-garantueed, fluktuating/changing & and also additional player in the context of:
ISV -> publisher (gog) -> user
to
ISV -> publisher (gog)-> community(maybe?)->user
I see.. although in this case it would be
ISV -> publisher (gog) -> ubuntu users -> somebody gets it running on X distro -> posts on reddit -> X distro users

it's far from the perfect approach but if you just target ubuntu then you've done your job. Let us handle the rest, really.
avatar
shaddim: No pun intended with "fuzzy communities"... I was meaning it in role defintion way. The "community" is some non-garantueed, fluktuating/changing & and also additional player in the context of:
ISV -> publisher (gog) -> user
to
ISV -> publisher (gog)-> community(maybe?)->user
avatar
Morgawr: I see.. although in this case it would be
ISV -> publisher (gog) -> ubuntu users -> somebody gets it running on X distro -> posts on reddit -> X distro users

it's far from the perfect approach but if you just target ubuntu then you've done your job. Let us handle the rest, really.
I have to say, im sceptical that an fourth player here is needed (or has in the average of cases a positive influence) in the general problem of software distribution and deployment. Such chains should be as short as possible (please, not more moving parts which can break!).

Second, I think its really incompatible with the service gog.com is trying to offer himself.

Third, it's also ressource problem, communities are limited. Manpower IS a serious problem in the OSS world. This means some distro (or versions of distro) might be targeted pretty late or not at all, it's not reliable.

So why not fixing this on the root by removing unneeded parts/players and variations, by making the linux ecosystem a platform which is reasonable addressable?
Post edited December 13, 2012 by shaddim
avatar
Morgawr: I see.. although in this case it would be
ISV -> publisher (gog) -> ubuntu users -> somebody gets it running on X distro -> posts on reddit -> X distro users

it's far from the perfect approach but if you just target ubuntu then you've done your job. Let us handle the rest, really.
avatar
shaddim: I have to say, im sceptical that an fourth player here is needed (or has in the average of cases a positive influence) in the general problem of software distribution and deployment. Such chains should be as short as possible (please, not more moving parts which can break!).

Second, I think its really incompatible with the service gog.com is trying to offer himself.

Third, it's also ressource problem, communities are limited. Manpower IS a serious problem in the OSS world. This means some distro might be targeted pretty late or not at all, it's not reliable.

So why not fixing this on the root by removing unneeded parts/players and variations, by making the linux ecosystem a platform which is reasonable addressable?
Don't get me wrong, I'm not saying that's not possible. I'm just saying that my way of doing it (read: targeting only ubuntu and let the others kill each other to port it to other systems) is the easiest and cheapest way of doing it. It was a counter argument to people saying that "development for Linux is too broken and difficult".

There are better ways that allow you to target to multiple distros with relative ease without having to rely on the community to port things.

However, always keep in mind that it is not possible to make everyone happy, if you're using a very obscure distro (or just unconventional one, hard to setup and not very used) then you're on your own. You can't expect a company to target the lowest audience ever.
You want to use your special distro? Then get ready to support stuff that other people don't want to support.
You want to have readily accessible new stuff? Then go with Ubuntu (or similar, debian, fedora, whatever).

That's how it works everywhere by the way, you target the biggest platform and if the platform you're using isn't a big player in the game then maybe it's time to change platform (or make it a desirable platform by adding features that will make people migrate to yours).
avatar
Morgawr: That's how it works everywhere by the way, you target the biggest platform and if the platform you're using isn't a big player in the game then maybe it's time to change platform (or make it a desirable platform by adding features that will make people migrate to yours).
Thanks for well formulating this, that's more or less my point overall! :)
I would love to see linux becoming a big, real platform instead of an fragmented ecosystem, so that it can be taken seriously by hardware providers, ISV, publishers (gog.com!) etc as it is reasonable addressable.

And no, just accepting & adapting to this fragmentation (like you suggest) should not be the solution, I think this mentality ("somehow and with much and continuous community work it is survivable") was also preventing the realization of a linux platform (in the last 2 decades).
Post edited December 13, 2012 by shaddim
avatar
shaddim: And no, just accepting & adapting to this fragmentation (like you suggest) should not be the solution, I think this mentality ("somehow and with much and continuous community work its possible") was also preventing the realization of a linux platform (in the last 2 decades).
It's not the solution. There are a lot of different solutions but as gooberking said earlier, we need to take baby steps and slowly work toward it.
You start by supporting one Linux platform (The most popular) and, depending on your resources (developers, investment, whatever), on a few other popular platforms (in this case for example it'd be Ubuntu, Debian, Fedora). As time goes on it either works or it doesn't (as many things in life) but regardless people will either move to the supported platform (helping to create a unified environment) or they will try to port the software themselves to their own.
This, to me, is the solution we can strive to achieve as of 2012 (almost 2013).

Knowing the Linux community, it's a winning approach as things have showed us in the past. Many projects started exaclty like this. Just look at the wine project, it's a "community project" (or at least started as one, now it's backed by companies and has a "professional" version too) and yet it's developed by a lot of people and works exactly like this.
avatar
shaddim: And no, just accepting & adapting to this fragmentation (like you suggest) should not be the solution, I think this mentality ("somehow and with much and continuous community work its possible") was also preventing the realization of a linux platform (in the last 2 decades).
avatar
Morgawr: It's not the solution. There are a lot of different solutions but as gooberking said earlier, we need to take baby steps and slowly work toward it.
You start by supporting one Linux platform (The most popular) and, depending on your resources (developers, investment, whatever), on a few other popular platforms (in this case for example it'd be Ubuntu, Debian, Fedora). As time goes on it either works or it doesn't (as many things in life) but regardless people will either move to the supported platform (helping to create a unified environment) or they will try to port the software themselves to their own.
This, to me, is the solution we can strive to achieve as of 2012 (almost 2013).

Knowing the Linux community, it's a winning approach as things have showed us in the past. Many projects started exaclty like this. Just look at the wine project, it's a "community project" (or at least started as one, now it's backed by companies and has a "professional" version too) and yet it's developed by a lot of people and works exactly like this.
NO no... you mixing here two kinds of community projects: software projects which become continously better, progress and at some point are useful (like wine, inkscape etc) . Great, it works, I love it!
Second kind (the one we are talking about here) is the sisyphonian task of continously repacking of software for adapting & upgrading various distros, libs etc. It's not rewarding, its brings no progress in nothing, it is boring and it wastes just OSS ressources. It's unneeded and should be taken out of the software deployment chain!! Please!
Post edited December 13, 2012 by shaddim
avatar
Morgawr: It's not the solution. There are a lot of different solutions but as gooberking said earlier, we need to take baby steps and slowly work toward it.
You start by supporting one Linux platform (The most popular) and, depending on your resources (developers, investment, whatever), on a few other popular platforms (in this case for example it'd be Ubuntu, Debian, Fedora). As time goes on it either works or it doesn't (as many things in life) but regardless people will either move to the supported platform (helping to create a unified environment) or they will try to port the software themselves to their own.
This, to me, is the solution we can strive to achieve as of 2012 (almost 2013).

Knowing the Linux community, it's a winning approach as things have showed us in the past. Many projects started exaclty like this. Just look at the wine project, it's a "community project" (or at least started as one, now it's backed by companies and has a "professional" version too) and yet it's developed by a lot of people and works exactly like this.
avatar
shaddim: NO no... you mixing here two kinds of community projects: software projects which become continously better, progress and at some point are useful (like wine, inkscpae etc) . Great, it works, I love it!
Second kind (the one we are takling here ), is the sisyphonian task of continous repacking of software for adapting & upgrading various distros, libs etc. It's not rewarding, its brings no progress in nothing, it is boring and it wastes just OSS ressources. It's unneeded and should be taken out of the software deployment chain!! Please!
Oh, now I see what you're saying. Sorry I didn't fully understand at first.
On this basis, then yes I agree with you. It's better to target a standardized way that works everywhere without having to rely to third party (see: community) to patch and port the software to their distro.

However this is one of those things that make "developing for Linux" harder (in the eyes of people not used to it). It's a problem not trivially solved and I fear it would be way too out of the scope of THIS problem (aka creating a standardized platform has to happen naturally through continuous usage of a winning model instead of expecting it from people).

Overall, if you're excellent developers, you try to target everything. If you're good developer (just with not enough resources) then you target the most popular versions and let the "hipsters" (tongue-in-cheek) plan accordingly for their own version.

If you're a bad developer you just make sure it runs on your PC and everyone else can screw themselves (I CERTAINLY hope it's not the case here haha)
avatar
Morgawr: Overall, if you're excellent developers, you try to target everything. If you're good developer (just with not enough resources) then you target the most popular versions and let the "hipsters" (tongue-in-cheek) plan accordingly for their own version.

If you're a bad developer you just make sure it runs on your PC and everyone else can screw themselves (I CERTAINLY hope it's not the case here haha)
Well, no. Sorry, I can't stand this wastage of ressources...it's conceptually plainly wrong!

To take your "babystep picture": we should use this development ressources instead for wastage *again* on surviving in this crappy situation, better for some micro-steps in direction of a real solution ...maybe by some distro independent package format like zeroinstall or autopackage. Maybe some complettly different idea, I dont' care, but please some progress! It can't be that the best idea is just to continue this inherently broken and flawed development cycle??

Is the linux ecosystem really doomed to be static and fixed in that regard? Where is the innovation power?
Post edited December 13, 2012 by shaddim
avatar
Morgawr: Overall, if you're excellent developers, you try to target everything. If you're good developer (just with not enough resources) then you target the most popular versions and let the "hipsters" (tongue-in-cheek) plan accordingly for their own version.

If you're a bad developer you just make sure it runs on your PC and everyone else can screw themselves (I CERTAINLY hope it's not the case here haha)
avatar
shaddim: Well, no. Sorry, I can't stand this wastage of ressources...it's conceptually plainly wrong!

To take your "babystep picture": we should use this development ressources instead for wastage *again* on surviving in this crappy situation, better for some micro-steps in direction of a real solution ...maybe by some distro independent package format like zeroinstall or autopackage. Maybe some complettly different idea, I dont' care, but please some progress! It can't be that the best idea is just to continue this inherently broken and flawed development cycle??

Is the linux ecosystem really doomed to be static and fixed in that regard? Where is the innovation power?
You know how it goes...
http://xkcd.com/927/ (and I hate myself for linking this but it's true in this case)

We've gone too far in the Linux community to just pop up and come up with a packaging standard to enforce to everyone. Due to the nature of the environment you can't just do that and expect everyone to comply (and even if they did it'd take years to fully integrate into the system).

The best approach we have left is the usually most popular (and natural) one, that is start supporting the popular standard and let the rest slowly fall into obsolence. It's harsh but unfortunately it seems to be the only acceptable way
avatar
shaddim: Well, no. Sorry, I can't stand this wastage of ressources...it's conceptually plainly wrong!

To take your "babystep picture": we should use this development ressources instead for wastage *again* on surviving in this crappy situation, better for some micro-steps in direction of a real solution ...maybe by some distro independent package format like zeroinstall or autopackage. Maybe some complettly different idea, I dont' care, but please some progress! It can't be that the best idea is just to continue this inherently broken and flawed development cycle??

Is the linux ecosystem really doomed to be static and fixed in that regard? Where is the innovation power?
avatar
Morgawr: You know how it goes...
http://xkcd.com/927/ (and I hate myself for linking this but it's true in this case)

We've gone too far in the Linux community to just pop up and come up with a packaging standard to enforce to everyone. Due to the nature of the environment you can't just do that and expect everyone to comply (and even if they did it'd take years to fully integrate into the system).

The best approach we have left is the usually most popular (and natural) one, that is start supporting the popular standard and let the rest slowly fall into obsolence. It's harsh but unfortunately it seems to be the only acceptable way
No, it's not result of that what I'm suggesting. In the classical approach you would be right, someone publishes/presents the real/best/universal distro format (or even distro). But no one agrees... the other distros believe in their own stuff for marginal technical reasons, so no progress here possible, as consensus would be required.

My suggestion is to take these whinners out of the chain overall. No consensus required. App developer and distributors (like gog) just have to start to use (and develop) distro agnostic formats like CDE, autopackage, portablelinuxapps etc.. and gradually the importance of distro packaging and distro fragmentation (on all levels) will fade. That was the concept of Mike Hearn of the Autopackage project too. And as I believe the very reason why it was fought so hard (and unfair) by the distros, they fought against the end of their importance.

PS: I agree on your "obsolence" formulation, but we have to work on that actively!... it will not happen by itself, the fragementation effect is due to the nature of the OSS environment way stronger than the consolidation force of the "obsolence" (or say it another way there is already an enourmous pile to clean).
Post edited December 13, 2012 by shaddim
avatar
gooberking: When did we get to, Cross platform installers are hard screw Linux? I thought we were looking for some way to make games run on it, not pursue some utopian idea of how to get one installer to work for everyone. Baby steps.
avatar
shaddim: Infact, my question was not aiming at the technical feasability (which exists no doubt). My question was aiming the "quality of service" definition and philosophy difference between gog.com and the linux ecosystem (or the distro/unix/FOSS way of doing things) & and how this can brought more near together.

Selecting one sub-ecosystem (e.g. Ubuntu 12.04) and expecting that some fuzzy community fixes the rest is a approach which might even work out technical, but is hardly compatible with the self-understanding of gog.com as service provider himself for a convenient, stable & simple gaming experience.

Therefore, what can be done that gog.com find it's place in this ecosystem, that gog.com can provide his services with feasible effort in the linux ecosystem?
I was speaking more directly on this notion of AndrewC wanting a unified Windows/Linux installer for applications so he doesn't have to go about doubling his work effort. I honestly don't know if I've ever seen such a thing, and my initial reaction is WFH does that have to do with anything? Lets not get ahead of ourselves, and just start with getting games more frequently deployed on Linux first, then go from there.

I do rather dislike the mentality of "we will make it work," when applied to GOG given their desire to be active in supporting their products. But I also don't think its incompatible with GOG's supportive goals to select one of these "sub-ecosystems." In fact if we are to bring GOG and Linux closer together then that just may be the only reasonable option as a starting point. It's not the cleanest situation, and people may have to compromise in places to make it work. Be it gog being willing to offer something without support to the few, or the few being willing to deal with Unity on one partition to gain access to support.

Now if GOG is totally unwilling to compromise on the support issue, and linux people are totally unwilling to accept the idea that guarantees can not be extended to every pet distro and that all games can magically be turned into linux natives, then I'm not sure there is anything to be done to bring those two camps together.
avatar
gooberking: Be it gog being willing to offer something without support to the few, or the few being willing to deal with Unity on one partition to gain access to support.
Thankfully, targeting Ubuntu doesn't mean targeting Unity then hehe.
Ubuntu has a huge number of forks which have 100% compatibility with the "original" ubuntu (see: Xubuntu, Lubuntu, Mint etc) and it's the biggest chunk of entry-level Linux distro.