Linux Support!

[mngrif]

IS AWESOME.

It works absolutely perfectly! "dpkg -i factorio*deb" was absolutely all that I needed to do, aside from running the game itself. Simply double clicking the .deb works fine as well, as expected. I already had the 32bit libraries installed, thanks to Steam and Java requiring them. It's probably safe to say that if Steam runs for you, Factorio should run as well, as the dependancies are darn near the same. I'm running it on Linux Mint, with the proprietary fglrx drivers (ATI HD5770). Much to my delight, it was silky smooth with no frame drops or stuttering, or any of the usual crap that I associate with gaming under Linux.

Thanks!

[zlosynus]

Hi!

I think they have all libraries they need directly part of the compiled code so no prerequisites are needed at all. I don't like this decision from the programmers point of view, but installing and everything is much easier.

[mngrif]

There are always dependencies, even if it's just libc. Here's what Factorio depends on (just the output of ldd, package names can be inferred):

Code: Select all

kosh games # ldd factorio 
	linux-gate.so.1 =>  (0xf7730000)
	libasound.so.2 => /usr/lib/i386-linux-gnu/libasound.so.2 (0xf761c000)
	libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xf75f3000)
	libjpeg.so.8 => /usr/lib/i386-linux-gnu/libjpeg.so.8 (0xf759b000)
	libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf7465000)
	libXcursor.so.1 => /usr/lib/i386-linux-gnu/libXcursor.so.1 (0xf745a000)
	libXinerama.so.1 => /usr/lib/i386-linux-gnu/libXinerama.so.1 (0xf7456000)
	libXrandr.so.2 => /usr/lib/i386-linux-gnu/libXrandr.so.2 (0xf744b000)
	libGL.so.1 => /usr/lib32/fglrx/libGL.so.1 (0xf7360000)
	librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7357000)
	libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf726e000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7242000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7224000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7079000)
	libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf705e000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7059000)
	libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf7040000)
	libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf701e000)
	libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xf7013000)
	libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xf700c000)
	libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf6ffa000)
	libatiuki.so.1 => /usr/lib32/fglrx/libatiuki.so.1 (0xf6fe3000)
	/lib/ld-linux.so.2 (0xf7731000)
	libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf6fdf000)
	libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf6fd7000)

Statically linking to the more obscure libs is absolutely the correct decision for a game. Otherwise you will run in to stupid situations where Linux Mint uses a different libasound than Ubuntu, but doesn't contain Ubuntu's version of libasound so your only option is to roll your own. It's crap like that which makes me hate using Linux as a desktop OS.

Output from "apt-cache show factorio":

Code: Select all

Package: factorio
Status: install ok installed
Priority: extra
Section: games
Installed-Size: 48312
Maintainer: factorio-pkg <pkg@factorio.com>
Architecture: i386
Version: 0.1
Depends: libasound2 (>= 1.0.16), libc6 (>= 2.15), libgcc1 (>= 1:4.1.1), libgl1-mesa-glx | libgl1, libjpeg8 (>= 8c), libpng12-0 (>= 1.2.13-4), libstdc++6 (>= 4.6), libx11-6, libxcursor1 (>> 1.1.2), libxinerama1, libxrandr2 (>= 2:1.2.0)
Description: Building factories on allien planets.
 Long description goes here.
Homepage: http://www.factorio.com

[ddeath]

I don`t know why but when I was trying to start factorio... it says something like: failed to initialize audio or something like that....
I`m using Linux mint 14 with cinamon... and the solution is just to install lib32asound2-plugins package and it helps me

[MF-]

Yes, it needs working ALSA output. In my case via alsa2pulse plugin.

[Blackence]

Yeah, thanks for the excellent linux support!

I'm a little worried about the libX11 etc. dependencies. They are no problem now, but in a few years this might be considered deprecated and we need some ugly XWayland compat layer to play factorio and can't get rid of good old X. As I understand it, factorio uses allegro for drawing and other low-level stuff.

Would it be difficult for devs to provide factorio as a dynamically linked (against allegro) binary, getting rid of all direct dependencies on libX*? That way, in case a wayland-supporting allegro library emerges in the distant future, we could still use factorio and have it communicate with the display manager natively. Of course, keep the user-friendly statically linked binary as the "main" download. Or maybe the allegro .so can be included and dynamically linked against in the main tarball, which would still allow users to replace that .so with some future wayland-enabled allegro lib.

Of course, allegro might be considered deprecated by the time wayland hits mainstream distros. This is the big big issue with Linux software, APIs are just too unstable everywhere so that makes it difficult to keep up even for open-source projects where everyone could adapt the code to new APIs. I still think it's easier to adapt the (then possibly deprecated) liballegro interfaces to some new technology than it is to create a libX11 shim that uses wayland behind the curtain (basically what XWayland is supposed to do AFAIK, but then we can't get rid of X). Basically, the simpler the API the factorio binary links against dynamically, the easier it should be to keep supporting it. And libX11 is.. well, a mess.

For example, these are the dependencies of Cities in Motion (1) and as you can see, no libX* depends, just SDL2 (which already supports wayland and Ubuntu Mir AFAIK). In this case, the libSDL2 so file is shipped with the game in a "lib" directory, and as you can see they added that lib directory as an RPATH so the dynamic loader will load the library from there. It's almost as user-friendly and failsafe as statically linking (unless someone removes the lib/ directory for whatever reason), AFAICT the main difference being that we can swap the library with some modified self-compiled blob if we want to, which is great.

Code: Select all

 0x00000001 (NEEDED)                     Shared library: [libGL.so.1]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libSDL2-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libz.so.1]
 0x00000001 (NEEDED)                     Shared library: [libfmodex-4.36.21.so]
 0x00000001 (NEEDED)                     Shared library: [libsteam_api.so]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000f (RPATH)                      Library rpath: [$ORIGIN/lib]

[doulos05]

I'm going to second that. Dwarf Fortress's not-quite-smooth linux support is disappointing comparatively. I find it ironic that the most "linux-y" looking game of the 21st century is so difficult to install on Linux. I mean, I know, "Just install the 32 bit libraries", but they don't get the package names correct on the webpage and they don't have a .deb which would pull in the missing dependencies automatically. Factorio just worked problem free for me on two different computers.