LWN: Comments on "The state of Linux gaming in the SteamOS era (Ars Technica)"

The state of Linux gaming in the SteamOS era (Ars Technica)

oak — Wed, 11 Mar 2015 20:08:59 +0000

Some historical trivia:

This is similar to the idea from decade ago, on which Sratchbox v1 (distro cross-compilation utility) is based:
http://scratchbox.org/documentation/

Nokia used it to cross-build all the Maemo and MeeGo distributions (which used Busybox for base systems, proprietary code for GUI & apps and normal Debian packages for most of the rest):
http://en.wikipedia.org/wiki/Maemo

Scratchbox prototype was actually presented in FOSDEM on 2003, but at that time it used binfmt_misc to run cross-compiled binaries on remote machine (with desired architecture) using ssh & NFS.

Qemu user-space emulation for ARM matured enough for use only later on. For few years it was used in Scratchbox alongside "sbrsh" + SSHFS (sbrsh tool was developed because "ssh" doesn't forward enough of the process run-time environment to the remote machine). Sbrsh is still part of Debian, fakeroot's TCP mode was originally added to support sbrsh.

The state of Linux gaming in the SteamOS era (Ars Technica)

flussence — Wed, 11 Mar 2015 17:03:28 +0000

IIRC, it *was* completed but couldn't be released because of the licensing terms of a proprietary third-party middleware library.

The state of Linux gaming in the SteamOS era (Ars Technica)

ThinkRob — Wed, 11 Mar 2015 02:09:23 +0000

> Epic was also an early exception -- there was a promised port of one of the Unreal Tournament releases that went on for years yet never materialized.

Both UT and UT2004 were ported to Linux. I've played both on Linux (although UT2004 was the more polished of the two; as I recall it shipped on the CD, had an installer, etc.) UT3 was the only one I know of that was mentioned but not ever (AFAIK) completed.

The state of Linux gaming in the SteamOS era (Ars Technica)

pabs — Mon, 09 Mar 2015 14:29:13 +0000

I just logged into a Gentoo box and I don't see anything resembling Debian multi-arch. Do you have a link to Gentoo multi-arch stuff?

The state of Linux gaming in the SteamOS era (Ars Technica)

granquet — Thu, 05 Mar 2015 16:13:59 +0000

I'm quite satisfied with how gentoo handles multi-arch/lib for the past 10 years :)

of course, installing steam and running it with the "gentoo x86_64" libs seems to fail at the moment ...
had to revert to using the libs shipped with steam :-/

The state of Linux gaming in the SteamOS era (Ars Technica)

pabs — Wed, 04 Mar 2015 14:27:11 +0000

Some folks in Debian are working on cross-compiler support for Debian architectures. Hopefully early during the stretch cycle that work will be useful.

https://wiki.debian.org/CrossToolchains

The state of Linux gaming in the SteamOS era (Ars Technica)

pabs — Wed, 04 Mar 2015 14:25:18 +0000

I was responding to a comment that was talking about 32-bit vs 64-bit x86 (satisfied by multi-lib in Fedora) not cross-CPU things that need multi-arch. I hope Fedora one day adopt multi-arch but so far it seems only Debian and derivatives have been interested in that.

The state of Linux gaming in the SteamOS era (Ars Technica)

thestinger — Tue, 03 Mar 2015 16:34:20 +0000

That's how things are done on Windows anyway.

The state of Linux gaming in the SteamOS era (Ars Technica)

rleigh — Tue, 03 Mar 2015 08:25:41 +0000

The support is transparent, there's nothing to configure. It's done with a setup script (https://github.com/codelibre-net/schroot/blob/master/etc/...) to bind mount the emulator into the chroot. So long as you have the static qemu binary around and it's registered with binfmt_misc (should be automatic), it'll just work with a foreign arch in the chroot. IIRC you just need qemu-user-static and binfmt-support installed.

The state of Linux gaming in the SteamOS era (Ars Technica)

droundy — Mon, 02 Mar 2015 23:24:04 +0000

Can you point me at documentation for using schroot in this way? My cursory googling didn't give any hint of this functionality, which sounds really useful.

The state of Linux gaming in the SteamOS era (Ars Technica)

rleigh — Mon, 02 Mar 2015 21:03:43 +0000

It's been integrated with schroot for some time. You can run programs of a different architecture in the chroot completely transparently using binfmt_misc/qemu. We use this with sbuild to permit Debian package building for different architectures (in addition to the existing cross-build support).

The state of Linux gaming in the SteamOS era (Ars Technica)

drag — Mon, 02 Mar 2015 20:41:29 +0000

I would love to see integration of Qemu binfmt support into one of the container-style virtualization implementations.. most notibly nspawn.

Setting up cross-compiler and testing environments is a big pain in Linux, even though it can be made to work very well.

I know a lot of projects have trouble with getting some of the more esoteric hardware platforms supported in a easy way into their compile/test environment. It would be a cool thing to be able to use big/available x86_64 machines to compile and test software easily for platforms that have limited memory/cpu restrictions for software projects that don't have the resources needed to maintain a bank of different types of hardware for each type of platform they need to support.

The state of Linux gaming in the SteamOS era (Ars Technica)

helsleym — Sun, 01 Mar 2015 22:27:58 +0000

I disagree with your "more than enough games to play" assertion. Almost all of the titles you mention are id Software games. id ported and released their game clients and servers on Linux when very few studios would even port their titles' servers. Epic was also an early exception -- there was a promised port of one of the Unreal Tournament releases that went on for years yet never materialized. Even id's Linux support waned. It's a bit of an exaggeration to put it this way but tons of minesweeper, solitaire, and tetris variations written in a vast array of programming languages, libraries, toolkits, etc. are not "plenty of games to play".

If anything the article understated the difficulty of Linux gaming when you consider how buggy, slow, and unreliable gaming under Wine has been despite the spectacular work of the dedicated and talented Wine community. Wine was useful but let's not kid ourselves that it was an experience non-Linux enthusiasts would ever put up with.

Modern gaming on Linux is an incredibly rich and seamless experience by comparison to 5+ years ago. Many folks are doing great work and the progress has been astounding. There are still plenty of great titles that are not being developed on or ported to Linux but I am optimistic that Valve and others will keep winning more converts.

The state of Linux gaming in the SteamOS era (Ars Technica)

mathstuf — Sat, 28 Feb 2015 23:59:56 +0000

binfmt support for it via Qemu exists[1].

[1]https://wiki.debian.org/QemuUserEmulation

The state of Linux gaming in the SteamOS era (Ars Technica)

vonbrand — Sat, 28 Feb 2015 22:18:28 +0000

Your x86_64 won't be able to run ARM binaries anyway.

The state of Linux gaming in the SteamOS era (Ars Technica)

zyga — Sat, 28 Feb 2015 18:17:19 +0000

Fedora? At least as far as I know, F21 that I'm running now cannot co-install arm libraries (multiarch). I don't think steam cares though.

The state of Linux gaming in the SteamOS era (Ars Technica)

pabs — Sat, 28 Feb 2015 00:24:49 +0000

Which distro doesn't have multilib/multiarch support? I thought we solved that already.

The state of Linux gaming in the SteamOS era (Ars Technica)

tjc — Fri, 27 Feb 2015 18:02:31 +0000

> The release of Doom for Linux in 1994 actually prompted me to ditch my DOS (And Windows 3.11), and change wholly to Linux.

The release of Doom source code in late 1997 prompted me to do the same! I worked on a DOS source port for a short while, but eventually dropped that and stayed with Linux.

The state of Linux gaming in the SteamOS era (Ars Technica)

tetromino — Fri, 27 Feb 2015 17:26:11 +0000

> you should not need a root

s/root/chroot/

The state of Linux gaming in the SteamOS era (Ars Technica)

tetromino — Fri, 27 Feb 2015 17:25:18 +0000

Ask your distro to improve their multilib/multiarch support. It's 2015, you should not need a root just for using i686 libraries on amd64.

The state of Linux gaming in the SteamOS era (Ars Technica)

luya — Fri, 27 Feb 2015 17:14:21 +0000

Some games like Phantasy Star Online 2 can run smoothly on Wine, one of issues is anticheat rootkit like nProtect Gameguard needing direct access to hardware thus violating security policies. Those examples show how some Microsoft Windows games have a very bad practice of coding procress.

The state of Linux gaming in the SteamOS era (Ars Technica)

flussence — Fri, 27 Feb 2015 16:32:54 +0000

I hope one of the preconditions for removing the beta label is a 64-bit version; I shouldn't have to keep a multilib chroot around to play x86-64 games.

It's somewhat twisted that Valve is bringing the Windows maladies of DRM and i686-only binaries to Linux in 2014/5 — and being showered in praise — after their competitors have been quietly "getting it" for 10 years.

The state of Linux gaming in the SteamOS era (Ars Technica)

raven667 — Fri, 27 Feb 2015 16:32:03 +0000

> This article seems to overstate the difficulties of gaming on Linux

One of the ways that games have been successful is by defining their own userspace, bundling their own C, C++, SDL, GL, etc. libraries and not depending on the system libraries which in some cases don't have enough long term ABI compatibility to be relied upon to run say Quake3 from 1999 without included or static libraries from 1999.

The state of Linux gaming in the SteamOS era (Ars Technica)

mordae — Fri, 27 Feb 2015 11:08:31 +0000

> And today, almost a third of my 900+ Steam games library have Linux binaries and they all "just work". Double-click, install, play.

Well, I have some problems with games linking against older C++ runtime and crashing when their dependencies move on to newer one. Trine seems to bundle a lot of libraries one needs to remove in order to resolve some conflicts and I know that eventually it won't work at all when it's dependencies get incompatible.

On the other hand, I might be able to play them in a container.

The state of Linux gaming in the SteamOS era (Ars Technica)

Seegras — Fri, 27 Feb 2015 09:41:15 +0000

And I forgot, about 80% of the Windows games run out of the box on wine, plus another 10% can be made to work with cracks, weird configs and sometimes re-implementing third-party libraries such as xlive. Yes, it's definitely not something you want (for instance, all of them are slow to start), and not something the average person wants to involve itself with, but it's better than nothing.

In the end, native ports are so much more convenient, and also, they're a great way for quality control for the developer: Every port turns up bugs that, when fixed, raise the quality of the game on ALL platforms.

The state of Linux gaming in the SteamOS era (Ars Technica)

Seegras — Fri, 27 Feb 2015 09:31:22 +0000

The release of Doom for Linux in 1994 actually prompted me to ditch my DOS (And Windows 3.11), and change wholly to Linux.

As for now, I've got 634 Linux games on Steam alone, and about a 100 more from Humblebundle, Desura, GOG, Tuxgames and Loki.

The state of Linux gaming in the SteamOS era (Ars Technica)

ledow — Fri, 27 Feb 2015 08:52:23 +0000

Precisely.

And today, almost a third of my 900+ Steam games library have Linux binaries and they all "just work". Double-click, install, play.

If people bother to produce programs for Linux, they tend to work for a very long time (never break userspace!). And games are easy to cater for as they never really need any kind of privileged or low-level access to things (about as low as you want to give them is an OpenGL interface, really). The worst that happens is that the developer has to bundle a few static libraries or similar into the download anyway.

Linux gaming is now basically the same as Mac gaming - if you can be bothered to recompile and re-target your code for those platforms, you can just add it as a one-click download option to your game and it'll work for the foreseeable future.

The state of Linux gaming in the SteamOS era (Ars Technica)

einstein — Thu, 26 Feb 2015 22:02:15 +0000

This article seems to overstate the difficulties of gaming on Linux. I was playing doom on Linux in 1994. While there have historically been far fewer titles available for Linux than for windows, there have always been more than enough games to play. While there was no half life, there was doom series, the quake series, return to castle wolfenstein, unreal tournament etc. As far as the hand wringing over different distros and different libs, there are ways to handle that. C'mon, we know it's possible, since I was able to play the same old quake 3 arena binary that I bought in 1999 over a period of 10 years and several distro changes.

At any rate, I'm glad to see that more titles are coming to Linux now.