Blizzard Still Has a World of Warcraft Linux Client

[haplo602]

fragmentation ? leave that to the distros

I don't get them ... I mean the developer is free to pick any set of ligraries he needs, post them and leave the rest to the distribution maintainers to cope with.

That easy. Since the users have a vote in almost every popular distribution (ok, maybe not Ubuntu :-)), the distro maintainers WILL create packages to install the game with all it takes. Given the popularity of WOW, that would prove quite successful I expect.

The fragmentation is a strength, since every distro comunity looks after themselves, they will patch/create etc. distro packages for applications and report back any bugs etc. That's almost a free workforce.

[quintesse]

Kirurgs wrote: "So just DON'T prohibit blobs"

Yeah but just doesn't go well with the whole idea behind FLOSS. Besides if everybody would think like you we would never get any good open/free 3D gfx drivers.

I'm hoping the new WebGL-enabled browsers will finally push the development of better drivers. We've at least seen much improvement the last couple of years. Before it was unthinkable to even contemplate having open/free drivers for 3D, nowadays having a composited desktop is normal.

@allquixotic: somebody might have to come up with some kind of stable API wrapper around core functionality especially for distributing binaries on Linux. But they'll probably have to do it themselves because I don't see any of the FLOSS developers try it (why would they?).

[mirv]

I can understand from one point of view all the targetting of different distros, with different library versions, etc, but on the other hand there are cases of a single person (Mr. Ryan Gordon) managing to overcome those problems for a host of games, then there's the indie scene, and let's not forget Id Software (granted, they don't officially "support" linux, but all their stuff works anyway), and some of the people on this forum get around it too.
So whatever other reasons exist, I tend not to believe the one of it being too difficult to target multiple distros, or linux in general.
Just my 2c on the matter.

[fnf_]

Just to reinforce what I just wrote:

Jump ahead to 2015. Distros shipping the latest n' greatest (Ubuntu, Fedora, OpenSUSE, etc) are using new ABI versions of core system libraries. By 2015 it's safe to assume that libstdc++ will have bumped again; it's also possible that an X server may not even be running if Wayland takes off. It might even go through such upheaval that the glibc ABI changes, though this one is extremely stable and the least likely to have changed by 2015.

Now try to run a game from 2007 that uses C++. Try it. Regardless of whether or not libstdc++ is statically linked into the 2007-era binary executable, or loaded at runtime, you will encounter a problem.

(a) If libstdc++ is statically linked, then attempting to map in any libraries that use a different version of libstdc++ will fail. Since the system version of libstdc++ (the one whose ABI is required by your system libs) is not ABI-compatible with the one statically linked into the binary, it is not possible for the libraries to get mapped into the binary, and the program will not start.

(b) If libstdc++ is dynamically linked, then the developer had better ship their own libstdc++.so with the distribution of their software, or it's only going to work on a very small number of distros that were explicitly tested. So let's assume they ship a libstdc++. The executable links against that with LD_LIBRARY_PATH in a wrapper script. OK, now what? We have an old libstdc++, again, in the process space. Trying to load our system libs gives us the new libstdc++ from /usr/lib{32,64}. Boom.

Basically, every Linux binary that links against system libs more than libc.so.6 is a ticking time bomb. At some point in the not too distant future, an incompatible ABI break will occur in the libraries that the binary is dependent upon, and it will fail to start.

This is not an issue at all with open source projects, because you just recompile it against the latest toolchain, and fix any build errors that crop up. The process is quite easy. But from a software distributor's perspective, it's a royal pain in the ass, because it requires constant maintenance to keep up with the latest distros. And if the ABI breakages are especially frequent for some reason, then you end up with a laundry list in your download page. For Ubuntu versions 8.04 to 9.04 and Fedora 9 through 11, download this binary. For Ubuntu versions 9.10 through 10.10 and Fedora 12 through 14, download this binary. And so on and so forth. Distributors hate that -- and rightly so.

To date, the only binary package distributor that seems to get it 100% right with binary packages is Sun/Oracle, especially with VirtualBox. Their build system must be unimaginably atrocious, but they support a ton of recent distros with packages built explicitly for each distro of interest. I have yet to install a mainstream distro that they don't support. Take a look for yourself: http://www.virtualbox.org/wiki/Linux_Downloads

Eighteen separate packages!

The other amazingly cool thing about the VirtualBox binary packages is that they only support distros that are currently within the post-release update cycle from the distributor. So when Fedora 12 got EOL'ed, they stopped making Fedora 12 builds of VirtualBox. Keeping up with all of that is nothing short of amazing.

But we can't expect every Joe who wants to distribute a Linux game to navigate this morass, and create a similarly masterful build system, and distribute updates on a 3 to 6 month schedule to keep them working properly with the latest distros. And you still have the issue of people who insist on using ancient distros (quite a few), eventually losing support unless you backport application changes and make packages for their distro.

It's a terrible situation, and the only hackjob of a semi-solution would be to "just do it" the nasty Microsoft way. That is, you would have to make Side-by-Side Configuration (i.e., multiple versions of the same shared library loaded into a process's address space, mapped out differently for different components of the process) a design requirement of your dynamic linkage system and file format. Then you would have to work backwards from there to determine what changes would be necessary to ELF, ld-linux.so, glibc, the kernel, and so on. Not to mention that multiple versions of the same library could have conflicting resource usage at the syscall level, such as file descriptors and temporary files, and you'd need a way to account for that.

What you end up with is the unfortunate realization that the core GNU/Linux operating system's plumbing is fundamentally unprepared for a long-term binary ecosystem. It is unfortunate for people looking to make money by selling per-user licenses of proprietary software to GNU/Linux users. It is advantageous to those willing to release source code, because the infrastructure built up around easy distribution for open source projects is quite good.

What you said is true theoretically, but incompatibilities happen with all operating systems. You can only postpone breakages by static-linking or shipping your own dependency libraries, although failure will occur where you start assuming compatibility at lower levels of the software stack.

Practically I concur with Kirurgs: developers don't have to perfectly support every Linux distros under the sun, but one of the most recent versions of popular distros. The number may vary, but at the minimum they should publish a generic tarball that works in all distros.

An important point that I'm sure you are aware of: Windows and Mac OS developers face these problems everyday but somehow they managed to do it just fine. It is OK if your 5-year-old software cannot run under the latest 2011 OS.

[quintesse]

the distro maintainers WILL create packages to install the game with all it takes

I think you're mistaken, lots of distributions will definitely NOT install something that is not open source. Fedora, OpenSUSE and Debian are 3 large ones that won't for example.

[Chewi]

I think you're mistaken, lots of distributions will definitely NOT install something that is not open source. Fedora, OpenSUSE and Debian are 3 large ones that won't for example.

Perhaps but someone would at least create unofficial packages in a heartbeat. Still, I admire Gentoo for leaving this ethical decision to the user.

[blackiwid]

So a bit stupid bullshit from a stupid company

I programmed also a game and I did have the oposite problem, its hard to compile gstreamer or something like that under Windows, in Linux there are libs for that installed everywhere or can be installed. You set a dependency, as a bigger software-company you have just to make a readme where stands which librarys are required the distros do the rest if it is wanted.

But if they not want to support linux just dont do it, stop flaming stupid crap. What do they want change the lisence of all linux or other packages to lets say a propriatery and make closedsource only software one linux that supports one big company or what? Why blabber about something that will not change anyway. Linux is not made so that some linux-migrated kids can play propriatary games. If that does work too ok, but thats not the main point of linux and free software.

[Mickabouille]

To me, that seems absurdely easy to solve for Blizzard.
If I remember their (Wow) business model, they don't sell the client, they sell the access to the servers.
They just have to let the sources (and resources) for the client out. Whatever integration problem could be done by those who want to run the game (if they feel like doing something useful for once).
Granted, it would probably never be packaged by distros as they wouldn't care about a free client without a server.

[chrisr]

The WoW client is free to download, since WoW is a subscription game

For years its been said that Blizzard has developed a Linux client for its very popular World of Warcraft MMORPG game but that it's never been publicly released.

The bulk of the client download is the game data as well, which is presumably the same for both Windows and Linux clients. The actual client binary itself is probably relatively small.

I wonder if a Linux client could be distributed as a SRPM, with a few core dependencies such as gcc v4.x and glibc? I'm envisaging linking precompiled objects against system libraries more than compiling here, but I suppose the main point is that since the client already exists, the remaining problem would "only" be packaging.

There are probably more than enough players on Linux at least to test whatever Blizzard has.

[Yezu]

Just to reinforce what I just wrote:
(...)
Now try to run a game from 2007 that uses C++. Try it. Regardless of whether or not libstdc++ is statically linked into the 2007-era binary executable, or loaded at runtime, you will encounter a problem.
(...)

I really don't understand Your problem. It's obvious there might be issues, but they are exceptions not the rule.

I'm running Doom 3 (from 2004) on my Fedora 14 with no issues at all. I had no problems with the game since Fedora 10.

Also I am totally unable to run Sacred Plus or Soldiers of Anarchy on Windows XP SP3, because they were not targeted for that version of the os (they work on Wine though :P).