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: But many (~50%) are supported by a multitude of packages...up to 6 packages (Darwinia, Botanicula, Lone Survivor etc), where in Mac and Win one package is fine.
I don't think that's a fair comparison though... while they share a lot of code, because of the variation that's possible in the way a distro can be assembled each distro should really be considered a distinct OS in its own right IMO. In a similar vein to regular Windows vs Windows Server vs Windows RT etc. Windows and Mac basically only have one supported "distro".

Also I was greeted by "2 packages updated since your last visit" (windows) vs "5 packages updated since your last visit" (linux) -> 150% more, despite that I have ~20% less linux than windows games. Support burden...
I don't think this is a fair comparison either considering that many games in the HIBs have already been out on Windows for a long time, but often have their Linux debut with the HIBs (or otherwise release on Linux some time after the Windows version) so it stands to reason that the Windows versions will have long been exposed to the wider userbase and had their issues ironed out while many of the Linux versions are yet to receive such thorough testing.

With that in mind I can't say I've noticed the Linux games in my Humble Store account (and I have quite a lot- over 150) receiving more updates than Windows games. If anything it feels like they usually receive fewer updates overall because almost all of the non-platform-specific issues have already been ironed out in the Windows version prior to the Linux release...
Post edited January 16, 2014 by adamhm
avatar
shaddim: But many (~50%) are supported by a multitude of packages...up to 6 packages (Darwinia, Botanicula, Lone Survivor etc), where in Mac and Win one package is fine.
avatar
adamhm: I don't think that's a fair comparison though... while they share a lot of code, because of the variation that's possible in the way a distro can be assembled each distro should really be considered a distinct OS in its own right IMO. In a similar vein to regular Windows vs Windows Server vs Windows RT etc. Windows and Mac basically only have one supported "distro".
This thread is called "Linux support on GOG" not "Ubuntu 10.10 support on gog", so it's very fair. But you named and identified correctly one core problem of the linux distro ecosystem: it forms not a coherent, addressable platform, unlike all other successful systems. Nevertheless, people like to talk about linux as OS or platform (like the thread starter) despite it is a non-existing entity.


Also I was greeted by "2 packages updated since your last visit" (windows) vs "5 packages updated since your last visit" (linux) -> 150% more, despite that I have ~20% less linux than windows games. Support burden...
avatar
adamhm: I don't think this is a fair comparison either considering that many games in the HIBs have already been out on Windows for a long time, but often have their Linux debut with the HIBs (or otherwise release on Linux some time after the Windows version) so it stands to reason that the Windows versions will have long been exposed to the wider userbase and had their issues ironed out while many of the Linux versions are yet to receive such thorough testing.
Maybe, but it also illustrates that support is a burden and is not for free.
avatar
shaddim: This thread is called "Linux support on GOG" not "Ubuntu 10.10 support on gog", so it's very fair. But you named and identified correctly one core problem of the linux distro ecosystem: it forms not a coherent, addressable platform, unlike all other successful systems. Nevertheless, people like to talk about linux as OS or platform (like the thread starter) despite it is a non-existing entity.
I don't really see it as a problem as such; it's a natural result of the flexibility and customisability afforded by Linux. It's unrealistic and unreasonable to expect to support all (or even most) distros and it's up to developers and users to decide on a "standard" target distro or set of distros.

If Microsoft were to suddenly make Windows free and open source we'd see the exact same issues emerge, as people start creating their own unique Windows distros making big changes... except that developers would just pick the official, standard Windows for support and all the others would either have to comply with the standard Windows "specification" or deal with compatibility issues.

Now like it or not Ubuntu appears to be emerging as the standard target Linux distro, given how widely used it (and distros based on it) has become and how much support from developers it is receiving. Especially with Valve also promoting it and making it Steam's officially supported distro.

Maybe, but it also illustrates that support is a burden and is not for free.
Supporting Windows & Mac aren't free either.
avatar
ssokolow: ScummVM isn't "emulated". It's a from-scratch rewrite of various game engines (originally just LucasArts SCUMM) for modern platforms.

[...]
avatar
Porkepix: My mistake. I thought it was some ugly trick with an emulator layer as CIDER is for example to run Windows-only games on OS X.
Fair enough. Given how unique ScummVM is, being a collection of 34 different game engines (with many more in development) sharing a common UI and OS interface layer, supporting nearly 200 games, I can easily see how you'd mistake it for an emulator or binary translation layer.

The only other place I can think of where something similar happened is Gargoyle whic combines 11 different interactive fiction (text adventure) runtimes into one program and it's nowhere near as well-known as ScummVM, even relative to the community it serves.

avatar
shaddim: Following your argumentation that reimplementing a API/ABI is not emulation and the not unusual experience that WINE games run often fine where "native" ports struggle, WINE should be maybe [url=http://www.codeweavers.com/about/blogs/jwhite/2012/06/05/whining-about-wine]accepted as stable, working and unified gaming solution for the problematic linux ecosystem. As it was also proposed by John Carmack.
I have seen that article and, while I initially had an emotional reaction to it (which means it'll be a hard sell for people less used to stopping to rationally consider things) I have given the idea some thought.

I already accept things like DOSBox as isolation layers and, in some ways, I actually prefer Wine for its ability to control what games are allowed to do. (eg. Disabling desktop integration so games don't clutter up my Documents folder with save files, forcing a virtual desktop so I can work around a game's broken idea of what fullscreening should imply on a multi-monitor desktop, getting working audio in something that was tested against PulseAudio but not bare ALSA+dmix, getting sane resolutions out of a game that, natively, only lets me select windowed resolutions that match what's allowed for fullscreen resolution changing, etc.)

Given GOG's comment that games modernized using DOSBox or ScummVM result in the fewest support requests on Windows, I'd say that the concept of using an emulator or API/ABI shim as an isolation layer between the game that never changes and the platform which changes rapidly can definitely work.

The problem is really one of getting Wine to the degree of stability DOSBox and ScummVM show, given that they're trying to implement a much much larger ABI and one that, unlike DOS and SCUMM, continues to grow and change.

My #1 rule for acceptable isolation layers is that I have to be able to run all of my games on the same build, which also has to be the newest (or, if they react promptly to regression reports, the second-newest), so I can feel safe in the knowledge that they actually are serving their role as an isolation layer. (With Wine, most of my games are on 1.6.x as provided by the official stable-release PPA but some have to run in 1.2.x because of regressions I just noticed or in 1.7.x because they depend on freshly-implemented Direct3D functionality... or require non-redistributable Microsoft libraries like XNA 4.0 or quartz.dll or XAudio2 to be installed to make the game work.)

I don't want to end up stuck doing my own patching and compiling to keep some ancient pre-regression Wine versions working on my system while I wait for the developers to mature "the proper implementation" to the point where my game accepts it as much as "the old, cheap hack".

Wine just isn't mature enough yet for me to accept it as an official solution rather than a DIY-only one and that's a bit of a chicken-and-egg problem in the near future since, without more acceptance, it'll be harder to up the rate at which it matures.

Also, I know it's unfair, but one of the reasons I like Humble Bundles is that, if I have both the native Linux port and a Windows version running in Wine, I have twice as many chances to make the game playable by fiddling around with things. If it's just running in a QA'ed build of Wine and that breaks, there's less chance I'll be able to get the bare Windows installer to work in another copy of Wine. (One of the reasons I'm hoping that, 10 years from now, darling will still be around and will have grown complete enough to run OSX ports on Linux. That would give me three chances to get a game working acceptably.)

I take that view mainly because of compromises I make elsewhere. Basically, aside from a few tiny exceptions (nVidia Binary Drivers, Flash, and Skype) which I hope to be able to replace in the near future (Nouveau, Shumway, WebRTC), games are the only closed-source software I allow on my system.

I don't intend to hold games to the same open-sourceness policy I use elsewhere because I understand that I'm dealing with a tortoise-and-hare situation. Open-source is great for stuff where slow-and-steady improvement over a decade or more wins the race (kernels, office suites, browsers, game engines for genres where technology has matured and stabilized and innovation has moved into storytelling, etc.) but proprietary development wins when you're competing by being on the cutting edge as it continues to flee from you. That market makes games more of a "throwaway software" model where there's no time to slow-and-steady your way to a workable game engine.

However, since closed-source software isn't open to myself and the rest of the world to debug and patch in perpetuity the way I've grown used to with open-source code, I consider it effectively unmaintained, unsupported, and frozen. As such, I hold my games to a higher standard elsewhere to compensate... hence desiring both a Windows version and a native Linux port so I have twice as many chances to get the thing working 5/10/15/etc. years down the road without having to dig out an old PC and find an old OS install CD because the VirtualBox 3D guest drivers no longer support kernels that old.
avatar
adamhm: Now like it or not Ubuntu appears to be emerging as the standard target Linux distro, given how widely used it (and distros based on it) has become and how much support from developers it is receiving. Especially with Valve also promoting it and making it Steam's officially supported distro.
I still wonder why. Ubuntu is slow and awful, that's why more and more people change to Mint, which is still based on it, but nobody can say for how long, seeing how the Ubuntu developer ranted at Mint some time ago because he was obviously jealous.

Regarding the longterm support stuff mentioned here:
Try running some Win95-games on WinNT, Win2k, WinME, WinXP-SP3 or Vista and you will see, that the problem exists there too and is nothing special.

A Linux distro common for games WILL be chosen and by now, it looks like it will be Debian, since SteamOS is a Debian7 after all, afaik. If GoG would focus on Debian just like Steam then, I am sure, that people would be happy. Whoever uses an incompatible Linux distro for work will install this one for games then and everything is fine, that's how we work anyway. HB could focus on it too then.
Most people wouldn't need a second OS though, because Debian stuff works well on many systems.

Having a really polished high compatible version of WINE would be neat too of course, but copanies would have to put money in it.

In conclusion:
Debian emerges as the common gaming distro of the future.
SteamOS is Debian7, PyraOS (OpenPandoras successor) will be Debian, HB games run well on Debian and others may focus on it too. Mobile systems with ARM processors have their Debian already too.
There are tons of games working on Debian already.
It's the best maintained distribution not related to a company and it has been this way for over a decade.
Stable, free of law-suit, what else would a gamer want?

At least it is sure that the next gaming OS will not be Windows8. :D
Post edited January 16, 2014 by Klumpen0815
avatar
Klumpen0815: I still wonder why. Ubuntu is slow and awful, that's why more and more people change to Mint
Well if Ubuntu is slow it's because of Unity. Honestly I haven't used that much. I'm using XFCE on 12.04 and there's nothing slow about it. Also used the KDE variant of the previous LTS and while KDE isn't the fastest it still wasn't slow.
avatar
Klumpen0815: I still wonder why. Ubuntu is slow and awful, that's why more and more people change to Mint, which is still based on it, but nobody can say for how long, seeing how the Ubuntu developer ranted at Mint some time ago because he was obviously jealous.
Since cross compatibility between Debian, Ubuntu and Mint is very good, I wouldn't complain about this choice though.
Well, for a standard to emerge it needs to be:

A: The only available option
B: Just so good that the majority agrees on it
C: Promoted by someone with enough influence to convince developers and users to accept it and with sufficient resources to support it

Ubuntu meets condition C, being backed and supported by a large company (Canonical) and heavily promoted by another large company (Valve) that happens to have a big influence in the games industry, both with developers and users. AFAIK Valve also helps developers port their games to Ubuntu.

Having a really polished high compatible version of WINE would be neat too of course, but copanies would have to put money in it.
I'm hoping that Wine will eventually take on a role more akin to DOSBox or ScummVM, becoming necessary only for older games without any available native ports.

As for putting money towards Wine development... http://www.codeweavers.com CrossOver is essentially a commercial version of Wine and supporting them helps fund Wine development.
avatar
shaddim: This thread is called "Linux support on GOG" not "Ubuntu 10.10 support on gog", so it's very fair. But you named and identified correctly one core problem of the linux distro ecosystem: it forms not a coherent, addressable platform, unlike all other successful systems. Nevertheless, people like to talk about linux as OS or platform (like the thread starter) despite it is a non-existing entity.
avatar
adamhm: I don't really see it as a problem as such; it's a natural result of the flexibility and customisability afforded by Linux. It's unrealistic and unreasonable to expect to support all (or even most) distros and it's up to developers and users to decide on a "standard" target distro or set of distros.

If Microsoft were to suddenly make Windows free and open source we'd see the exact same issues emerge, as people start creating their own unique Windows distros making big changes... except that developers would just pick the official, standard Windows for support and all the others would either have to comply with the standard Windows "specification" or deal with compatibility issues.

Now like it or not Ubuntu appears to be emerging as the standard target Linux distro, given how widely used it (and distros based on it) has become and how much support from developers it is receiving. Especially with Valve also promoting it and making it Steam's officially supported distro.
Android is free and open source platform and I fail to see a crazy forking into incompatible branches. Also the BSDs are relative resistent against forking. And the reason is: developers and users LOVE stable platforms. That the linux ecosystem tries to provide choice by the horde of distros is an architectural misdesign rooting back waaaay to the ancient unix history. In general, choice should be provided by the available software ecosystem + some customization of a unified platform, not by a endless stream of slightly incompatible OSes'.
Post edited January 16, 2014 by shaddim
avatar
shaddim: Android is free and open source platform and I fail to see a crazy forking into incompatible branches. Also the BSDs are relative resistent against forking. And the reason is: developers and users LOVE stable platforms. That the linux ecosystem tries to provide choice by the horde of distros is an architectural misdesign rooting back waaaay to the ancient unix history. In general, choice should be provided by the available software ecosystem + some customization of a unified platform, not by a endless stream of slightly incompatible OSes'.
Well as far as I know (I admit I don't have much experience with Android) it's a little more difficult to create Android forks given the need to root devices first and then there are issues with closed source components, getting drivers etc.

Also, both the stock Android system and BSD provide a base that forks build upon and use as the standard. As I said earlier if Windows were to become open source then the official release would be supported and used by developers as the standard and forks would either comply with it or deal with compatibility issues.

There is no such standard base distro for Linux yet... although as I already said it appears Ubuntu is being placed into that role.
Post edited January 16, 2014 by adamhm
avatar
Klumpen0815: Regarding the longterm support stuff mentioned here:
Try running some Win95-games on WinNT, Win2k, WinME, WinXP-SP3 or Vista and you will see, that the problem exists there too and is nothing special.
There is no concept at all of backward comaptiblity or shims or adaption layers at all in linux, as the relevance of binary backward comaptiblity is regard irrelavant or even a weakness. The assumption still prevalent in linux is: everything releant is available as sourcecode and re-compiling is easy. Both is wrong.

avatar
Klumpen0815: A Linux distro common for games WILL be chosen and by now, it looks like it will be Debian, since SteamOS is a Debian7 after all, afaik.
Not true at all. First, Debian is by no means a end-user distro (or gaming), not all all. They are proud on being very free and getting rid & providing no support for commercial/proprietary binary blob stuff (liek third party bianry games) Also, the assumption games working under SteamOS (whcih is just a debian FORK) will therefore run under debian is very wrong: SteamOS defines a new platform built from parts of debian, but following completely different update and compatiblity principles than debian. They were incompatible from the beginning and will keep diverging.
Recently they changed the runtime engine again, removing more dependecies in some lib to isolate steam even more form common distros (and their crazy variances).
avatar
shaddim: Android is free and open source platform and I fail to see a crazy forking into incompatible branches. Also the BSDs are relative resistent against forking. And the reason is: developers and users LOVE stable platforms. That the linux ecosystem tries to provide choice by the horde of distros is an architectural misdesign rooting back waaaay to the ancient unix history. In general, choice should be provided by the available software ecosystem + some customization of a unified platform, not by a endless stream of slightly incompatible OSes'.
avatar
adamhm: As I said earlier if Windows were to become open source then the official release would be supported and used by developers as the standard and forks would either comply with it or deal with compatibility issues.
As Windows has a platform design crazy forking would NOT happen when becoming open source. The comaptibility to the enourmous ecosystem is the strength of windows.

That is also the reason why ReactOS as clone would be a good idea, access to the great software ecosystem of windows, with a free and open source OS whcih will be most likely will not end in distro craziness
Post edited January 16, 2014 by shaddim
avatar
shaddim: There is no concept at all of backward comaptiblity or shims or adaption layers at all in linux, as the relevance of binary backward comaptiblity is regard irrelavant or even a weakness. The assumption still prevalent in linux is: everything releant is available as sourcecode and re-compiling is easy. Both is wrong.
I'm yet to encounter any issues with backward compatibility, but I'm sure Valve will be at least helping work on a solution, if not developing one themselves.

As Windows has a platform design crazy forking would NOT happen when becoming open source.
Oh, it would. But you'd find that most of the "crazy forks" would generally be made with specific purposes in mind and wouldn't be used or supported as a mainstream desktop OS.

As there is currently no standard desktop Linux distro, there's a lot of variation between distros intended for use as a desktop OS. Everyone has their own idea for what the standard should be, but few have the influence and resources to actually set the standard (which is where Canonical, Valve etc. come in).

However the way things are going it looks like Ubuntu will be used by developers as the standard for desktop Linux.
Post edited January 16, 2014 by adamhm
If supporting Linux is so horrible, how does HB manage to offer games that run on my Linux OS?
Are they some kind of octopus like alien wizards? Do they have a dev-breeding machine?
It's a bit like the talk about veganism. If you believe all the sceptics, none would survive but instead they are mostly way more healthy and just have to learn a bit more about stuff (nutricients in this case, not libraries or the terminal ;).
Fun fact: Most Linux users I know are vegans by the way. ^^

http://www.bbc.co.uk/news/technology-25758308
Interesting to see, that WinXP still has nearly 30% of the market share. That underlines Linus' theory, that the choice of the mainstream OS is made by the sellers of PC systems. Manypeople don't buy a new pc every 5 years and so the OS doesn't change for them, therefore the still big share of WinXP.
Post edited January 16, 2014 by Klumpen0815
Steam Dev Days Highlights. CD Projekt RED better have been there!
avatar
Klumpen0815: If supporting Linux is so horrible, how does HB manage to offer games that run on my Linux OS?
Are they some kind of octopus like alien wizards? Do they have a dev-breeding machine?
Sadly not, the genius porting wizards who do ~80% of the ports are a scarce ressource: Edward Rudd and Ethan Lee. Therefore e.g. the vessel build was delayed half a year.

As you keep on the notation "it is possible therefore it must be easy", here some ressources: * Porting Osmos to Linux: A Post-Mortem (part 2/3) "Didn’t Love: Supporting multiple Distros/DEs/WMs/drivers/etc.The #1 obstacle to getting more games on Linux is that it’s very difficult to get your game working correctly and acceptably on all machines. It’s really hard to guarantee a smooth experience for all players when there’s a combinatorial explosion of possible distributions, desktop environments, window managers, driver/hardware versions — each with their own unique foibles, bugs, and undocumented behaviours."
* Autopackage: "Random Collection of Current Linux Problems Binary Portability" While some years old (sadly) still uptodate, the most comprehensive collection available.
* Portablelinuxapps: "Historically, UNIX and Linux systems have made it easy to procure source code, however they have made it comparably difficult to use ready-made software in binary form ..."

avatar
Klumpen0815: http://www.bbc.co.uk/news/technology-25758308
Interesting to see, that WinXP still has nearly 30% of the market share. That underlines Linus' theory, that the choice of the mainstream OS is made by the sellers of PC systems. Manypeople don't buy a new pc every 5 years and so the OS doesn't change for them, therefore the still big share of WinXP.
What? very speculative interpretation....
While it is true that the speed of hardware & software upgrades has cooled down, compared to the 80s and 90s upgrade races, the conclusion is not necessary that people who concious decide to stay on XP as it completely fullfills their requirements are to "stupid " to understand the greatness of linux and need it "shoveled" pre-installed with hardware. The notation that linux adaption requires enforcement is a really disturbing and often up cropping vision of some linux proponents. The notation that Windows PC users are too stupid and need to be pushed/educated is completely wrong and against the very vision of a open & free community movement. Firefox for instance also doesn't came preinstalled and was still able to capture a notable marketshare and has now the majority (on most places on the world). This shows: people are aware and motivatable for new things and open ideas. Which means, that the linux desktop is still not on track is primarely a intrinsic problem of linux itself. Damned, don't argue for excuses, fix the crap finally!

avatar
adamhm: Oh, it would. But you'd find that most of the "crazy forks" would generally be made with specific purposes in mind and wouldn't be used or supported as a mainstream desktop OS.
Again, the fundamental difference of windows to the linux distro concept is: windows adapts to "specific purposes" by third-party ISV software + some customization (without breaking the platform compatibility), while the linux distro model suggests for every specific purpose you need a own OS variation (and break happily the compatibility). The forking and breaking is concept inherent in linux but not in windows (neither in macos nor in android). To overcome this flawed architecture a clear separation between core and apps needs to be defined and defended (a stable API/ABI).

avatar
ssokolow: Given GOG's comment that games modernized using DOSBox or ScummVM result in the fewest support requests on Windows, I'd say that the concept of using an emulator or API/ABI shim as an isolation layer between the game that never changes and the platform which changes rapidly can definitely work.
I completely agree, WINE could be a reasonable approach for GOG, providing already a "good" (while not perfect) isolation. Associated community wish: Wine as a supported platform
Post edited January 16, 2014 by shaddim
avatar
shaddim: Android is free and open source platform and I fail to see a crazy forking into incompatible branches.
Google has very strict rules about Android and they'll only give you a license to distribute the Google Apps (App Store, Maps, GMail, YouTube, etc.) and services (Google's attempt to convince app developers to depend on a closed-source library) on your device if you join the Open Handset Alliance and follow their rules.

...and one of the rules for OHA membership is "you must only use Google-approved Android. You can't sell both ours and some other fork unless that other fork passes our strict compatibility tests. (For example, because Amazon's Kindle Fire OS is an Android fork that's too different, they're not allowed to use the Google Apps and Libraries if they decide to make an ordinary Android device.)

It's sort of like the smartphone version of Microsoft's old "If you offer machines with other OSes preinstalled, we'll charge you full price for your Windows licenses."

avatar
shaddim: Also the BSDs are relative resistent against forking. And the reason is: developers and users LOVE stable platforms. That the linux ecosystem tries to provide choice by the horde of distros is an architectural misdesign rooting back waaaay to the ancient unix history. In general, choice should be provided by the available software ecosystem + some customization of a unified platform, not by a endless stream of slightly incompatible OSes'.
The BSDs aren't relatively resistant to forking. In fact, they have it much worse than Linux:

In the beginning, there was 386BSD, an x86 port of BSD UNIX.

From 386BSD, came FreeBSD and NetBSD. Two different OSes which, since each one maintains its own kernel and core userland and has its own ABI, are more different than any two Linux distros. (You need to enable the built-in Wine-like ABI shim to run a FreeBSD binary on NetBSD or vice-versa.)

OpenBSD then forked off from NetBSD and, again, they maintain their own kernel and core userland. (They're not really intended to be a desktop OS but they do illustrate how, where Linux fires off new distros, BSD sometimes produces entire new OSes.)

Later, DragonFly BSD forked off from FreeBSD 4.8, leaving us with four independent operating systems with common heritage. (Independent in the sense that borrowing code from each other is about the same as borrowing code from the Linux ecosystem. They may be more closely related to each other than to Solaris or MacOS X, but they're still separate OSes.)

In addition, FreeBSD has various distros in the Linux-like (same stuff, different mix) sense such as PC-BSD, FreeSBIE, Frenzy, GhostBSD, etc.

Finally, many devices also run closed-source forks of FreeBSD such as JunOS which runs Juniper Networks switches and the Playstation 3 and 4 OSes. (Compare that with Android where device drivers are the only part of the platform stack not shared back as source code.)

Also, note that the ABI compatibility layers in NetBSD and FreeBSD aren't just simple, always reliable "your on-disk format is laid out like this while mine is laid out like that" affairs for compatibility within the same family of OSes. They also support other POSIX-compliant OSes like Linux, Darwin (OSX kernel), and Solaris and, like Wine, they're not guaranteed to be reliable or performant.