We’re initially going to be launching our Linux support on GOG.com with the full GOG.com treatment for Ubuntu and Mint. That means that right now, we’re hammering away at testing games on a variety of configurations, training up our teams on Linux-speak, and generally getting geared up for a big kick-off in the fall with at least 100 Linux games ready for you to play. This is, of course, going to include games that we sell which already have Linux clients, but we’ll also be bringing Linux gamers a variety of classics that are, for the first time, officially supported and maintained by a storefront like ours.
…and the Linux gaming news just keeps on coming. I remember how dismissive many people were back when Valve announced its Steam Machine initiative, stating Microsoft’s hold would never ever be broken.
Makes them sound like Nokia and BlackBerry during the iPhone’s launch, doesn’t it?
This is after they said in september last year to me it would be too hard:
http://www.gamingonlinux.com/articles/gogcom-dont-plan-on-introduci…
They claimed too many distro’s made it difficult and they would only do it if they supported them all, now they come out saying “we support Ubuntu & Mint!”.
Edited 2014-03-18 14:43 UTC
You mean, there is fragmentation in the Linux field ?
Kochise
I do!
But we talk about complex stuff here.
Very complex.
So apps can do 2 things:
Pack all the dependencies and install them alongside of the game (and each game have its own bundle).
Or
Use what is already installed.
(But then some minor differences can become so annoying, and with Linux there are dozens of major distros each with possibly different version of the lib You relay on)
Valve solved that puzzle buy standardizing on common bundle of “base libraries” which game can target. (So they target one target only ;P )
Imagine MS releasing Windows each year, and with different DX and .Net, and VS runtime for each for at least 6y. That is how bad it can be for Linux.
(And that is how bad it will be for OSX/Win when free/cheap OS upgrades kick in)
On the other hand need driver solution. Valve solution is fully open (anyone can contribute, and Valve code is FLOSS), so e.g. GOG also can standardize on it.
Well, Microsoft have at least something to teach to Linux : a very, well, I mean, VERY… **VERY** strong API and ABI interface !
A 1999′ Windows 2000 program can still run on Windows 8. Can Linux say the same ? Microsoft learned a lot with the Windows 95/98 DLL’s Hell, and solved it almost completely.
Kochise
Sure, why wouldn’t it?
X11 is notoriously backwards compatible and even an a.out binary from 1992 will run on the latest Debian.
Dynamic linked libraries are often the problem, but that’s hardly Linux unique… If you can’t find the libraries anymore or the specific library you want to use has a newer version that isn’t compatible with the older version, you could have some headache.
If your binary is statically compiled, (often the case of proprietary software especially on Windows) you should be fine. For the really complicated scenarios, you can go the chroot route.
that’s so true. Today, you cannot even compile a qt app on ubunut and run it on another similar distro without having a GLIBC Number error. That’s so fucking lame. And it was the same during the loki games and corel wordperfect era.
As much as I used to love my linux station, third party commercial apps are simply a no go in the linux world. yeah, yeah, compile the source and stuff. But if I want to play any old linux loki games on a recent distro, I’m better of grabbing a windows cracked version and run it with crossover or transgaming (or whatever name they have those days)
Or if you’re building a commercial app and don’t want to release the source, compile it statically and done.
True and false. Ubuntu had a newer version glibc than most other distributions for a while. Debian testing has in fact came into alignment. Now if you had built on Debian stable then went to run on Ubuntu no Glibc error.
Steam had the same issues. The issue is Linux has backwards compatibility not forwards compatibility with glibc except for a few rare events. So a Distrobution with newer glibc will run what was built on a distribution that has old glibc but not the reverse.
loki games on recent Linux is not hard.
http://www.gentoo-wiki.info/HOWTO_Running_Old_Loki_Games
The loki games are that old they run into a major redesign in glibc and kernel threading. In fact glibc 2.2 to 2.3 was the last time glibc backwards compatibility was busted this was 01-Mar-2003. 06-Mar-2006 was 2.4.0 when it was resolved that solving the compatibility issue was impossible. There were too many minor changes to support the new threading features of the newer kernels to locate what one was breaking old glibc 2.2 applications. Plus it was that the applications were expecting behaviours that were not in any standard. Like depending on c function calls to trigger locking that the newer versions don’t. Yes if your application expects locking do the locking call yourself. Linux world don’t build you application depending on bugs. Bugs get removed.
So to run loki and older applications like that install older glibc. The Current Linux kernel ABI is still compatible with glibc 2.2.5 that was released in 2002. Yes the gentoo binaries for making loki binaries work in fact work on all distributions.
Running on wine is taking a kick in teeth for no good reason. Yes nvidia and ati closed source opengl in fact still checks functionality against glibc 2.2.5.
Running by crossover or transgaming in fact takes unrequited overheads.
Basically over 10 years has passed since the last time glibc has broken backwards compatibility. It is unlikely to ever happen again. Going from userspace threading to kernel space threading was a one off event.
Micorsoft libc has broken more times and require more versions installed over the same time frame.
Linux Distributions don’t want 2.2.5 installed due to security and performance issues. Yes why 2.2.5 does not break loki games is that it performs badly.
If loki had appears in 2004 the problem would have never happened with them.
Sorry to say installing a game from the year 2000 on Windows 7 or 8 its more good luck if it works due to all the security changes. See person being unfair saying hey it simpler to install the games in wine. Reality if you are not running Linux or OS X with wine running the windows binaries is hard. The loki Linux binaries only require minor work around and a tolerance that you have brought back a security risk.
Of course most people talking about loki games don’t mention that the problem is over 10 years old and that time frame in Windows has its own huge issues.
I missed another key point. A lot of loki games in fact work with modern glibc if you lock the application to using only 1 cpu core to prevent particular threading issues. Some applications are just badly coded making those run after OS and hardware changes is hell.
Some programs from windows 2k will run, but not all of them.
Why do you think there are a number of companies stuck on windows XP?
Take a look at this:
http://msdn.microsoft.com/en-us/vstudio/ms788708.aspx
Great VB 6 programs will work on windows 8! Hooray! Oh wait, not all libraries will… Never mind.
Some would say that this far-reaching backwards compatibility is a drawback in terms of, among other things, code complexity and security.
Absolutely. I just installed Return to Castle Wolfenstein on Fedora 20. Many WIndows 95/98 games do NOT play well on Windows 7 or 8.
Windows 95/98 are not Win32.
I’m speaking about the NT5+ line of operating system (Windows 2000, XP, Vista, 7, 8, …)
Kochise
There are many xp games that don’t play well or at all on Windows 7/8.
That’s mostly due to DRM schemes, not the games themselves?
Er.. yes they are. Win32 API was supported. I think you mean “Windows 95/98 are not NT based”. They supported the Win32 API absolutely.
http://www.amazon.com/Windows-Programming-Complete-programmers-refe…
From Wikipedia: https://en.wikipedia.org/wiki/Windows_API
Edit: Both NT 3.x and NT4 supported Win32 as well. Used NT4 for first 3 odd years of my career. NT3.x was weird, as the UI looked like Windows 3.1 with Program Manager etc.
Edited 2014-03-21 13:51 UTC
The Linux kernel ABI has been basically unchanged since the 1.x days, you just need to compile a kernel that can execute 32-bit a.out files for that to work properly. Don’t depend on the layout of /proc or /sys, and bundle your dependencies, and Linux programs can last a long ass time.
tidux,
Well, only the userspace ABI is stable, the kernel ABI does get out of sync with out of tree modules, often requiring them to be updated along with the kernel. I don’t think Kochise was looking to make this distinction, so with that in mind I agree with you that the userspace API in linux has been very stable for a long time now.
“Imagine MS releasing Windows each year, and with different DX and .Net, and VS runtime for each for at least 6y. That is how bad it can be for Linux.”
Yes, but that’s what happens right? You always have to package the msvc runtime you built with because otherwise your app won’t run. And there’s a new one every year. I’ve always found that quite a pain.
They can use Docker to reduce long term support issues.
Yes, to a degree that’s smaller than the fragmentation of most product sectors.
That’s better than nothing I suppose. Linux gamers should be happy with any bone they get thrown.
ilovebeer,
Are you disappointed that linux is making progress? It sure seems that way…
Anyways Ubuntu and Mint are logical choices to support. The RedHat/Fedora/CentOS branches generally target more enterprise needs. Do you know if they’re going to actively block other distros, or they simply leave that as an exercise for 3rd parties to support? If it’s the later, then I hardly see how that could be controversial.
What kind of incentive could they have for that? There’d be zero sense in doing that, they’d only be amassing huge amounts of negative press and that would seriously hurt them.
I’m quite sure they won’t be blocking anyone. Makes no sense to, but they can tell them that if they’re not on distro X, they’re pretty much on their own. Initially, at least.
[/q]
No, not at all. My comment was based on previous observations of the gaming industry and gamers themselves. I don’t actually care one way or the other what becomes of linux gaming. If what I considered to be a really cool game came out for linux only, I would have no problem giving it a go. But, I’m not going to shed tears if that never happens.
I can’t see any motivation or benefit to actively blocking other distros.
ilovebeer,
Neither do I, if other distros are allowed to support it themselves, then Linux wins all around, don’t you agree? What threw me off was your characterization of this as throwing linux a bone, when it’s actually quite significant.
With software coming to the platform, we will begin to see more linux gaming rigs in the living room.
As long as that support works correctly and is reasonably stable I would agree its a linux win. Or at least a good step forward. If this actually materializes and does have any impact then I would need to revise the `throwing linux a bone` comment accordingly. When it comes to linux I’ve lost a lot of optimism over the years so these days I’m reserved when people make announcements. What people say and what winds up happening has a habit of not matching up – I need to see proof before I’m a believer and start passing thumbs ups and tip of the hats.
I certainly believe it’s within the realm of possibility. My living room already has a linux box at its center, though not in a gaming capacity. But, were the games I like & support there, it wouldn’t be much of a leap to add gaming.
Fedora is not more enterprise. Its bleeding edge and a fast moving target, that doesn’t ship binary blob graphics cards. That’s probably why its not supported.
Which is perfectly fine. Target the most popular distros and the rest of us using Arch and stuff will figure out how to get it running ourselves
Much to everyone’s surprise a company changed their stance on a certain topic.
It’s definitely progress, it doesn’t break anyones hold on anything though.
No doubt, and that iphone comparison is about the worst I’ve seen in a while. It almost seems like making announcements is good enough and people don’t care to wait to see when/if the claims become reality and further, if they actually make any noticeable dent in anything. It’s as if all you have to do is announce you’re going to support <any random game name here> in linux, and people immediately start throwing a pre-ejaculation party.
If you want a real world comparison for linux gaming, try “all bark, no bite” because thus far that’s all it’s been.
It should not be understated that this benefits developers greatly ^aEUR as they no longer need to rely on Microsoft to produce API updates for a subset of their audience.
Now saying that everyone has OpenGL 4.x hw/sw support is equally stretching it, they are not limited by corporate interests in that manner. More people will have better access to their hardware with this move, and through that, fewer headaches for game devs.
Another milestone in demise of MS domination. Finally a truly DRM-free gaming distributor rolling out Linux support. Really interesting times.
Provided everyone “play the game” and pay for them. If price is set accordingly (actual GOG pricetag) that would be cool.
Kochise
The demand for this feature on GOG was significant: https://secure.gog.com/wishlist/site/add_linux_versions_of_games
Also, I’m sure many people who started buying Linux games on HB would return to GOG, since GOG is resolute in offering only DRM-free games.
Edited 2014-03-18 18:17 UTC
So is this for old Linux games being ported up, old windows games being made to run under Wine, or old windows games being given Linux native clients? My excitement varies depending on the approach.
I wouldn’t count on GOG using Wine. Wine can be terribly unstable and with having one feature working fine, then suddenly in the next release it being totally broken. As far as I can tell, this announcement means that GOG will provide DOSBox/ScummVM-setups for certain old games and will provide Linux-binaries for games that already have Linux-binaries, like e.g. Shadowrun Returns — GOG so far has only provided Windows-binaries of that, with not even a mention of Linux.
They do no need to depend on a system version of wine. They can ship their own build.
Sort of, kind of like PlayOnLinux approaches stuff.
I would not count wine out either. Some games with ScummVM and DOSBox on GOG now have custom versions. PlayonLinux and other solutions have installed more than 1 version of wine on a system. So game with custom version of wine is possible. Has been done in past most likely other parties will do it again in future.
There, sane things I can think of:
– ship games that already have modern linux builds
– ship dosbox games with their own version of dosbox as they do on windows
– ship games with their own build of wine.
Sure wine depends on a lot of stuff if you want “everything” but for isolated cases, there is no need to ship every possible lib. Just the ones you need.
They already ship System Shock 2 for Mac using a build of wine if I’m not in error.
I wouldn’t like using their own versions of DosBox. What for?
I’d expect at least them releasing new games which have Linux versions already (like HB does).
Then they might as well provide configs for their many DosBox based games in Linux flavor. Their DosBox games already work on Linux perfectly, but configuration files need manual tweaks since they are targeted for Windows DosBox. Those are quite trivial, but GOG can make it more user friendly I guess for those who don’t want to modify configs by hand.
Windows games with Wine? More questionable, but if GOG have resources they can polish Wine bugs for Windows games they distribute. That would probably be their lowest priority.
Edited 2014-03-18 17:25 UTC
I’ve been running GOG games under either scummvm or DOSBox in Linux for a while now.
Works well
GOG will find a lot of their catalog will work with DOSBox with minimum fuss.
HELL — A hefty chunk of their library is distributed WITH DosBox already; the amount of overhead of making those work is exactly zero.
1
Browser: Mozilla/4.0 (compatible; Synapse)
Really? When you show me Linux desktops even reach 20 million THEN you can say something like that, heck is Linux desktops even reached 5 million yet? Go look at the percentage numbers and you’ll see Linux has been pretty much flatline for the past decade with old clunkers like Vista slaughtering it! When your numbers are literally LOWER THAN THE MARGIN FOR ERROR you have zero right for that level of arrogance. Why don’t you add how Haiku is totally gonna stomp Apple?
I’m sorry if some don’t like the truth but the numbers just suck, they really do. I would argue that is a combination of 1.- A SERIOUS case of NIH when it comes to distros that make switching distros over drivers and software incompatibilities a viable strategy (totally unacceptable and frankly insane)
2.- A section of the developer base that treats the OS not as an Operating system to actually allow you to accomplish real work but a political statement and who can and do put their politics above actual functionality,
3.- several critical subsystems being controlled by groups that have a “stability? What’s that?” attitude and whom see absolutely no problem with just throwing out entire systems for what is honestly alpha quality garbage (see Pulse, early KDE 4) with zero thought as to how it will affect the system as a whole and finally,
4.- A large section that believe “hard and complex equal smart” and the larger a pain in the ass something is the better while at the same time frowning upon and even mocking the very idea of what a modern OS in 2014 simply must have like a fully realized and functional GUI that allows the user to do all of the system administration and OS tasks with a minimum of fuss and WITHOUT having to resort to CLI.
Until Linux fixes these problems you can give it up. Just look at what Google did to Android, removed the CLI, removed the driver and subsystem issues by putting a single company in control of the whole stack and by focusing on making a UI that is intuitive, discoverable, and easy to pick up they have gained a good chunk of the mobile market…..does any of what I just wrote sound like the Linux desktop of today? Nope, infighting, NIH, CLI used a crutch because the devs can’t make a GUI and arrogance, THAT is the Linux desktop and THAT is why the numbers stink.