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
shaddim: And has still not understood the "personal computing" revolution in 80/90s which empowered the users to simply install software from whatever source (shop, internet) themself by "double click" by having technically a stable and easy to address platform.
avatar
gooberking: Does get a bit more complected if you go off repository, but most of the people you describe aren't likely to need much that isn't there.
I talk exactly about the non-repository use case, direct deployment to users. The use case which allows also ISVs to create software indepentend from platform vendor and to deploy the result directly to the user (without guardians in the middle which protect a walled garden). The use case which creates also enourmous ecosystems of applications around a platform (in contrast to the limited selection in repros). And games are the prime example for such software which wants to be installed directly by the users.
Post edited September 08, 2013 by shaddim
avatar
shmerl: How is GOG better than HB in this aspect? All DRM free games you bought on HB are also in your profile there. Not different from GOG in this regard. And archiving them is even easier, since they give you an option of using BitTorrent to download them.
avatar
gooberking: It's easier for me because I come here all the time and its all in one nice, graphical, click me page. With HB I don't have a profile, I have links in e-mail to my downloads of separate bundles I've saved in some folder in an email account. I also have to figure out what I want to do with all the games I don't really want, but got because of the bundle nature. Or do I back up their windows version of something if I have it on GOG and was just shooting for Linux? Just juggling multiple stores complicates things, and HB just feels a bit cluttered in comparison.

I've never used a BitTorrent so I can't speak on how it could or couldn't make life easier.
Ah, I see. It's easy to fix. Simply register on Humbe Bundle using the e-mail on which you got your links for games from HB. They will then connect all the games you purchased from them to that account, and you'll have them conveniently in your profile, same thing as on GOG. And any future purchase even made through Humbe Store widget will go directly to your profile as well. If you don't want to register, well, why are you complaining it's somewhat messy to keep track of all those e-mails and links?-) A few first purchases I made on HB were also without an account, but when I realized one can register - I did, it was very simple, not more complicated than on GOG. And having all games collected in your profile is a plus if you have a lot of them.

BitTorrent protocol has several benefits when downloading. It provides easy pausing / resuming, checksums / repairs and distributed download (so in most cases it's faster). Plus normally clients allow capping download speed, which most browsers don't.
Post edited September 08, 2013 by shmerl
avatar
CatShannon: In any case, from my experience, there wasn’t a single native Linux game that I had serious problems with and that I couldn’t get to run on my ArchLinux 64-bit system.
I understand GOG's concerns to some degree. What will happen with games which are not relying on SDL let's say, and tie into X directly for some weird reason? Linux is switching to Wayland soon enough. It can create a big mess for gaming potentially, unless games avoid X dependencies or developers will promptly update their games for the Wayland world. It's just one example.

If GOG can really come up with ways of long term support better than Steam - it's great. But I don't think it has to take years to do that.
Post edited September 08, 2013 by shmerl
avatar
shaddim: *Ahhh*... the anectodal computer iliterate friend/family member, let's de-bust this. The core point is: linux on the desktop is only fine for the computer impaired and the admin/devs. The use case in-between for the power-user, the original PC use case is not addressed (or even understood). Why it works for your mom? Because you act as admin for her, installing the apps and your mother just uses browser, email and open office. She will not try to install software or games meaning this is more or less the workstation-server setup, the use-case unix was used for in the 70s. And I would argue, linux is still stucking in this limited workstation-server mindset, built around a powerful admin and stupid user. And has still not understood the "personal computing" revolution in 80/90s which empowered the users to simply install software from whatever source (shop, internet) themself by "double click" by having technically a stable and easy to address platform.
My parents install software on their own just fine. To them, it's as natural as installing any Windows application. Even more easily, actually, because a package manager does it all for them. And now even Windows 8 uses such a model with the Windows Store.

* Number of times I've had to "admin" Windows for them: at least seven or eight times. Three of those times was due to malware.
* Number of times I've had to "admin" Mint for them: other than the installation, zero. Not once. It's been almost three years now.

So in this case, the anecdote is not debunked by your statement which relied on a blind-faith presumption.

I should also point out that an OS's history has nothing to do with its presentation. Windows 2000-XP (and maybe Vista/7, though I'm less certain) came from the Windows NT line which, surprise, was intended for corporate workstations-and-servers. And yet that turned out to be completely irrelevant, especially when you consider that another OS which is supported -- Apple's -- is built on the same Unix/POSIX principles as Linux. And don't say "Oh but one is BSD, the other is Linux", because your statement about "workstations" and admins doing everything for the stupid users on the other side of campus, was a quality rooted in both OSes' histories.

I understand that, unlike BSD, the many, many distros of the Linux do things differently. There's not "One Single Linux Way", the way that BSD maintainers do things, but I don't agree that this is cause for as much confusion about Linux support as people choose to be confused about it. Go with what the usage statistics say for desktop users, and then only guarantee support for certain flavors of distros. There is a reason those are the most widely used, because free operating systems run within the rules of the invisible hand of the free market as much as commercial OSes do -- there are concrete reasons why those distros are the most popular. You can support the most widely-used format, and not worry about whether or not Slackware or Gentoo users will have trouble running it because you can label your release as being for those types of distros only.

According to Distro Watch, the three most widely-used distributions are all Debian based (Mint, Ubuntu, and of course Debian itself). So with the standards these three have in common for software packaging, there is a momentum that can be exploited.

So no, Linux support is not that expensive if you have someone knowledgeable about this in your company who can plan accordingly.
Post edited September 08, 2013 by solzariv
Distrowatch should never be used for any Linux usage estimation. Their numbers have nothing to do with actual distros deployment.
The DistroWatch Page Hit Ranking statistics are a light-hearted way of measuring the popularity of Linux distributions and other free operating systems among the visitors of this website. They correlate neither to usage nor to quality and should not be used to measure the market share of distributions. They simply show the number of times a distribution page on DistroWatch.com was accessed each day, nothing more.
Post edited September 08, 2013 by shmerl
avatar
solzariv: My parents install software on their own just fine. To them, it's as natural as installing any Windows application. Even more easily, actually, because a package manager does it all for them. And now even Windows 8 uses such a model with the Windows Store.
You have not read what I wrote: selecting stuff from the tiny repro is not the same as have a selecting from the complete internet, a vast ecosystem. Repros offering a inferior selecting. Also you are limited to a specific version, whci is a problem on LTS distros. Which AAA application or recent AAA game you will find in repros?

And that Windows 8 is also now swithcing to a walled garden model is a shame... :(

avatar
solzariv: So no, Linux support is not that expensive if you have someone knowledgeable about this in your company who can plan accordingly.
Which means exactly, it is expensive. You need some expensive specialist. Which is the reason why e.g. Ryan Gordon is so valuable for companies and the Humble indie bundle because he and another handful of specialist in world know how to do address linux more or less. Normal developer hate workarounding the rough edges in the linux ecosystem (http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/). For instance, after Idsoftware lost their specialist for linux they dropped support competely for rage (http://www.phoronix.com/scan.php?page=news_item&px=MTA5MzQ).
Post edited September 08, 2013 by shaddim
avatar
solzariv: My parents install software on their own just fine. To them, it's as natural as installing any Windows application. Even more easily, actually, because a package manager does it all for them. And now even Windows 8 uses such a model with the Windows Store.
avatar
shaddim: You have not read what I wrote: selecting stuff from the tiny repro is not the same as have a selecting from the complete internet, a vast ecosystem. Repros offering a inferior selecting. Also you are limited to a specific version, whci is a problem on LTS distros. Which AAA application or recent AAA game you will find in repros?
But you're not limited to repositories for the package manager. What's so complicated about double-clicking a .deb file, compared to double-clicking a .zip or .exe?

avatar
solzariv: So no, Linux support is not that expensive if you have someone knowledgeable about this in your company who can plan accordingly.
avatar
shaddim: Which means exactly, it is expensive. You need some expensive specialist. Which is the reason why e.g. Ryan Gordon is so valuable for companies and the Humble indie bundle because he and another handful of specialist in world know how to do address linux more or less. Normal developer hate workarounding the rough edges in the linux ecosystem (http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/). For instance, after Idsoftware lost their specialist for linux they dropped support competely for rage (http://www.phoronix.com/scan.php?page=news_item&px=MTA5MzQ).
Rage for Linux was cancelled because Rage itself wasn't successful.

Also, you're talking about porting games, but this thread is about GOG hosting games that the developers have theoretically already ported. GOG doesn't need to hire a senior dyed-in-the-wool Linux guru to get basic one-click packaging together for software that's already made.
avatar
shaddim: You have not read what I wrote: selecting stuff from the tiny repro is not the same as have a selecting from the complete internet, a vast ecosystem. Repros offering a inferior selecting. Also you are limited to a specific version, whci is a problem on LTS distros. Which AAA application or recent AAA game you will find in repros?
avatar
solzariv: But you're not limited to repositories for the package manager. What's so complicated about double-clicking a .deb file, compared to double-clicking a .zip or .exe?
External debs are hard to provide for a ISV, as he has to address all distro variants specifically. So in general they are not available & or working not that well, or are outdated. Also, taking packages outside the distros repro negates the often mentioned advantages of a linux distro: not a well checked software experience and no malware safeness anymore.

avatar
shaddim: Which means exactly, it is expensive. You need some expensive specialist. Which is the reason why e.g. Ryan Gordon is so valuable for companies and the Humble indie bundle because he and another handful of specialist in world know how to do address linux more or less. Normal developer hate workarounding the rough edges in the linux ecosystem (http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/). For instance, after Idsoftware lost their specialist for linux they dropped support competely for rage (http://www.phoronix.com/scan.php?page=news_item&px=MTA5MzQ).
avatar
solzariv: Rage for Linux was cancelled because Rage itself wasn't successful.

Also, you're talking about porting games, but this thread is about GOG hosting games that the developers have theoretically already ported. GOG doesn't need to hire a senior dyed-in-the-wool Linux guru to get basic one-click packaging together for software that's already made.
I'm talking about linux suport, which is hard in all forms on all levels. And gog would need multiple well experienced devlopers doing nothing else than repackaging and fixing packages & dependendcies on distro & game upgrades all the time. As we see already on the pretty slow game update speed for the current windows GOG packages, GOG seems to be on its limits for "repackaging" already.
Post edited September 08, 2013 by shaddim
avatar
shaddim: You have not read what I wrote: selecting stuff from the tiny repro is not the same as have a selecting from the complete internet, a vast ecosystem. Repros offering a inferior selecting. Also you are limited to a specific version, whci is a problem on LTS distros. Which AAA application or recent AAA game you will find in repros?
Based on my experience with a large library of games from the Humble Store (which provides mix of .deb, custom installers, .tar.gz) amongst other things, the process of installing things on Linux vs Windows isn't that different.
Which means exactly, it is expensive. You need some expensive specialist. Which is the reason why e.g. Ryan Gordon is so valuable for companies and the Humble indie bundle because he and another handful of specialist in world know how to do address linux more or less. Normal developer hate workarounding the rough edges in the linux ecosystem (http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/)..
Now I can't speak from personal experience as I've never developed anything for Linux before & I don't have a huge deal of Linux experience in general (having only used it for about half a year so far), but I notice that article about Osmos is from more than 3 years ago... However, from reddit earlier this year:

Maia dev here! The game supports Linux natively (C++ for the win!). Interestingly its far easier to dev for Linux than Mac at the moment.

...

Firstly I can use a windowing system I am comfortable with. So I have Linux Mint, set up pretty much like Windows.

I can choose my IDE.. so codeblocks which is very generic and quick and easy to use. Opposed to Xcode 4 that you are forced to use, is completely baffling to get started with.

Libraries on Linux are a bit complexer, but it is at least logical.

User data is all in the same place on Linux. Opposed to app data on Mac that has to be stored way out of the way, making it hard for people to share files, or have editable configs.

A lot of Macs software rules make things like modding hard, or using different open source licenses.

Getting Maia fully working and tested on Linux took 5 days (including time that was me fixing stupid bugs that were cross platform and getting ATI drivers that didn't suck.)

The Mac build however, is still ongoing and is no end of pain.

Oh and Apple don't support up to date OpenGl so I have to rewrite half my engine to make it work. :(
A rather different viewpoint from another dev...
avatar
solzariv: But you're not limited to repositories for the package manager. What's so complicated about double-clicking a .deb file, compared to double-clicking a .zip or .exe?
avatar
shaddim: External debs are hard to provide for a ISV, as he has to address all distro variants specifically.
He doesn't "have to". As I already said, just look at the three most widely-used desktop distros, and target those, test it for those, and make it clear in your disclaimer that YMMV for end users who are using any other distro. Some distros are more suitable for desktop use than others, so there's no reason to support ones the vast majority of the Linux running, desktop-using public aren't using, and nobody will reasonably expect it any other way. I shouldn't expect to be able to run Witcher on a Windows Server box -- same deal here.
So in general they are not available & or working not that well, or are outdated. Also, taking packages outside the distros repro negates the often mentioned advantages of a linux distro: not a well checked software experience and no malware safeness anymore.
We don't need repros for the Windows or OSX versions, so I don't know why it has to be the case for Linux. It's an option, a nice thing to have, but it's not a requirement. Besides, I'm not going to worry about downloading malware from GOG. And GOG's Windows packages for some games are often outdated anyway with missing patches or the wrong version entirely (how long did the GOG version of Fallout include the UK censorship? A year or more?), so I don't see how that's any different. That's something GOG needs to change in their culture, it's not an issue specific to OS support.

avatar
solzariv: Rage for Linux was cancelled because Rage itself wasn't successful.

Also, you're talking about porting games, but this thread is about GOG hosting games that the developers have theoretically already ported. GOG doesn't need to hire a senior dyed-in-the-wool Linux guru to get basic one-click packaging together for software that's already made.
I'm talking about linux suport, which is hard in all forms on all levels. And gog would need multiple well experienced devlopers doing nothing else than repackaging and fixing packages & dependendcies on distro & game upgrades all the time. As we see already on the pretty slow game update speed for the current windows GOG packages, GOG seems to be on its limits for "repackaging" already.
It sounds like we're coming to an agreement that the issue is that GOG's company culture has shortcomings it needs to address, which don't necessarily have anything to do with real or perceived "difficulties" with operating systems. Really, anyone who embarked on a career in software shouldn't be balking at any notion of "difficulty". Kitchen too hot, yada yada.
avatar
solzariv: We don't need repros for the Windows or OSX versions, so I don't know why it has to be the case for Linux. It's an option, a nice thing to have, but it's not a requirement.
I can give you an explanation why it is normally a requirement in the linux ecosystem in contrast to windows or MacOS which dont' require repositories. Repositories and their dependency resolution is the linux ecosystem solution to the problem of dependency hell. Repositories keep in centralisitc way system (OS) and apllications in sync and working. The solution in the windows and MacOS world is a stable API + bundeling of changing dependencies. Advantage of the second approach is that ISVs can create software which will work over a long time and can be deployed directly to users. This works as the API is garantueed and supported (by the platform provider) and the rest can be bundled. For linux there is no comparable stable modern OS API with garantueed GUI/multimedia/installation support across the linux ecosystem. Everything changes from distro version to distro version and is different form distro to distro. So bundeling is hard or impossible because some things can't be bundled, you would need a reasonable API. In short, the linux ecosystem forms unlike Windows (and to some degree Mac) NOT a open platform for binary software produced by ISVs. This is a serious design fault, rooting long back to unix history.

PS: autopackage was a approach 2006 trying to achieve what is existing for windows and mac since long time, working bundeling. But as it faced furious resistance by the distros ([url=http://web.archive.org/web/20090305035002/http://plan99.net/~mike/xmlpres/presentation.xml]http://web.archive.org/web/20090305035002/http://plan99.net/~mike/xmlpres/presentation.xml[/url]) the project was stopped. And up to now there isstill no solution.

PPS: about the Maia dev, as far as I can see he talked primarily about developing of software on linux. Which is a different topic than the support of the vast linux ecosystem with the development result, the binary software. Development is fine on linux, just the platform qualities are horrible.
Post edited September 09, 2013 by shaddim
avatar
shaddim: ...In short, the linux ecosystem forms unlike Windows (and to some degree Mac) NOT a open platform for binary software produced by ISVs. This is a serious design fault, rooting long back to unix history. ...
You say there is basically no binary compatibility (neither backwards, nor betweens distros). Well this is bad. All dosbox based games however should be doable because dosbox should be contained in most repos. On the other hand all the modern indie games who offer a binary Linux version, how are they doing it without a repo?

How many distros is the Linux version of Steam supporting? Is their solution for distributing binaries also based on repositories?
Post edited September 09, 2013 by Trilarion
Sorry to interrupt, but I'd like to draw attention to the wish I just created: Show which games use Wineskin/WIne

In light of the fact that Linux is a potential benefactor (with regards to WINE) in the same way that Mac games have been, it should be a logical step to support the recognition of WINE on the respective game pages where it has been used to create a Mac port. Really, Linux should be reaping the benefits from this already, since the WINE community is very Linux-centric (whereas it's progenitor, the Codeweavers community is Mac-centric).
Post edited September 09, 2013 by elus89
avatar
shaddim: ...In short, the linux ecosystem forms unlike Windows (and to some degree Mac) NOT a open platform for binary software produced by ISVs. This is a serious design fault, rooting long back to unix history. ...
avatar
Trilarion: You say there is basically no binary compatibility (neither backwards, nor betweens distros). Well this is bad. All dosbox based games however should be doable because dosbox should be contained in most repos. On the other hand all the modern indie games who offer a binary Linux version, how are they doing it without a repo?

How many distros is the Linux version of Steam supporting? Is their solution for distributing binaries also based on repositories?
The steam "solution" (still heavy struggeling https://github.com/ValveSoftware/steam-for-linux/issues?state=open) is an additional layer (bypassing all distro infrastructure), some form of excessive bundling + limiting the scope to only 2 specific ubuntu versions and one DE ("Steam for Linux is only supported on Ubuntu 12.04 LTS or 12.10 with the Unity") . Steam itself acts as centralisitic walled garden repro for the games (which is bad).

Edit: about indies... they try their best & fix broken packages regularly ;) multiple bundles per distros (count the number of packages in the humble bundle libary!), minimization of dependencies + clever selection of stable and old libs. For instance, try the well made loki packages now several years without fix, it is unlikly that a single one of them works on a recent distro. In contrast, most of normal made windows software for windows 95 still works fine up to win8.
avatar
elus89: Sorry to interrupt, but I'd like to draw attention to the wish I just created: Show which games use Wineskin/WIne

In light of the fact that Linux is a potential benefactor (with regards to WINE) in the same way that Mac games have been, it should be a logical step to support the recognition of WINE on the respective game pages where it has been used to create a Mac port. Really, Linux should be reaping the benefits from this already, since the WINE community is very Linux-centric (whereas it's progenitor, the Codeweavers community is Mac-centric).
voted.

related wishes for a better recognition of support projects / transparency for users
http://www.gog.com/wishlist/site/show_which_games_use_dosbox_or_scummvm

wine related
http://www.gog.com/wishlist/site/beat_steam_work_with_wine_to_make_all_windows_games_work_on_linux_and_work_well
http://www.gog.com/wishlist/site/wine_as_a_supported_platform
Post edited September 09, 2013 by shaddim
avatar
elus89: Sorry to interrupt, but I'd like to draw attention to the wish I just created: Show which games use Wineskin/WIne

In light of the fact that Linux is a potential benefactor (with regards to WINE) in the same way that Mac games have been, it should be a logical step to support the recognition of WINE on the respective game pages where it has been used to create a Mac port. Really, Linux should be reaping the benefits from this already, since the WINE community is very Linux-centric (whereas it's progenitor, the Codeweavers community is Mac-centric).
avatar
shaddim: voted.

related wishes for a better recognition of support projects / transparency for users
http://www.gog.com/wishlist/site/show_which_games_use_dosbox_or_scummvm

wine related
http://www.gog.com/wishlist/site/beat_steam_work_with_wine_to_make_all_windows_games_work_on_linux_and_work_well
http://www.gog.com/wishlist/site/wine_as_a_supported_platform
I just remembered another potential wish: "Add successful Mac ports to the tests on the WINE app database" (appdb.winehq.org).

I think this is the ethical thing to do on GOG.com's part, since they're not contributing financially.

But I'll leave the actual creation of such to when it can be made more eloquently than my current overtired state.

Thanks for the support! I Voted for the ScummVM one a while ago (it inspired mine), but I did just add my vote to the "WINE as a supported platform" wish. I felt it's stated directive was a bit more clear than it's duplicate.
Post edited September 09, 2013 by elus89