Sign in to follow this  
laconic75

Linux Support

Recommended Posts

I was reading the Programming Update #2 and there was a quote from DF Nathan talking about Linux support.

I know Hare Brained Schemes was talking about Linux support not there for Moai yet, will this affect DFA's linux status? Or will you guys help with the Moai to linux porting?

It's not there yet, but it's not so far away, either. We definitely considered this in the evaluation. Many of the sub-systems already work on Linux or can be made to work with pretty little effort. The main challenge will actually be determining how to support the one-zillion-and-three different distro of Linux. Do we just release all the source? Do we just do precompiled binaries for the most popular distro? All that is still very TBD. Fortunately, we don't have to figure that out for a while yet.

In short, no, it doesn't change our plans for DFA Linux at all, and we will definitely contribute work to the Linux port as appropriate.

This got me to thinking. What is reasonable to expect for Linux support. So I decided to write out what I think would be the best way to support Linux and hopefully others can give there opinion as well

I think it would be best to limit officially supported distro to probably 3 or 4 at most. If I were the developer I think I would choose Fedora, OpenSuse and Ubuntu. If you make a deb and rpm to cover these and a unsupported tar.gz for everyone else I think everyone should find something for their system. If you officially support these 3 that also means you probably have covered Mint, Debian(if you have the right drivers), Mageia, CentOS, and PCLinuxOS. So out of the top 10 distro at DistroWatch the only ones left out would be Arch Linux and Puppy LInux. I use Arch linux for my work and home computer, so I'd love to see Arch officially supported but I also feel sure that if a tar.gz version is released someone will make an Arch package within hours. That only leaves Puppy and while I love Puppy Linux and use it a lot at work, I can't imagine anyone using it for games.

That just leaves driver issues. Intel has open sourced their drivers, but as of now Nvidia and AMD only have proprietary drivers available. I think its reasonable only to support the official drivers for the graphics card your using. One of the reasons I didn't list Debian as an officially supported distro is because there is no easy way to install proprietary drivers.

I really don't think officialy supporting 3 distro is as drastic as it sounds. So many distro are releated in one way or another to these three( four is you inclued arch;) that you will end up releasing a binaries that can be used by 90% of the linux users out there. With the tar.gz you will probably cover the other 10%.

Just my thoughts. I'd be very interested in any other Linux users opinions on the matter.

Share this post


Link to post
Share on other sites
That just leaves driver issues. Intel has open sourced their drivers, but as of now Nvidia and AMD only have proprietary drivers available. I think its reasonable only to support the official drivers for the graphics card your using. One of the reasons I didn't list Debian as an officially supported distro is because there is no easy way to install proprietary drivers.

I believe they're using OpenGL so they won't write for individual drivers -- it should work regardless of which drivers are being used (even if software rendering is being used). The drivers and the capability of the hardware may affect how *well* it runs but that's beyond DF's scope.

I don't really care if they support any specific distros as long as they ship both 32-bit and *true* 64-bit binaries in well-crafted tar.gz files with relocatable libraries. If they allow compiling from source (the actual data files can be obscured as long as the engine and libraries are open source) then even better. The community will certainly step forward and produce packages and/or build scripts for every distro known to man so I'm not worried about that. I've seen too many products that pretend to support 64-bit distros when in fact they're just shipping 32-bit binaries in 64-bit locations with the expectation that you have multilib capability installed and I really hope DF is smart enough not to do that.

Share this post


Link to post
Share on other sites

One of the reasons I didn't list Debian as an officially supported distro is because there is no easy way to install proprietary drivers.

This is no longer true. As of latest Debian release (Squeeze), you can install the NVIDIA drivers from apt if you enable the non-free repository.

As for the other suggestions: .deb, .rpm and .tar.gz will cover pretty much all bases, if they come in both 32-bit and 64-bit versions, probably 99%. With the source available, they would cover 100%. Otherwise, they could do a static binary release that's been tested on a few Linux distros, but this may pose a problem in the future (think a few years from now).

So they have a few options, but having the source code is always nice for guaranteeing its continued support for many many years to come.

Share this post


Link to post
Share on other sites
pretend to support 64-bit distros when in fact they’re just shipping 32-bit binaries in 64-bit locations with the expectation that you have multilib capability installed and I really hope DF is smart enough not to do that.

Hey there! For a second, pretend I'm actually not all that smart (I know, just bear with me). Can you explain whence comes the desire for 64-bit libraries and executables? Is it a convenience thing for the end-user? Is it an absolute necessity (eg, the OS will flat-out not be able to execute 32-bit code)? Something in-between?

Share this post


Link to post
Share on other sites
pretend to support 64-bit distros when in fact they’re just shipping 32-bit binaries in 64-bit locations with the expectation that you have multilib capability installed and I really hope DF is smart enough not to do that.

Hey there! For a second, pretend I'm actually not all that smart (I know, just bear with me). Can you explain whence comes the desire for 64-bit libraries and executables? Is it a convenience thing for the end-user? Is it an absolute necessity (eg, the OS will flat-out not be able to execute 32-bit code)? Something in-between?

It's more towards convenience than necessity in most cases. In order to use the 32-bit binaries, you need to install multilib capabilities as mentioned above. Many distros support and install this relatively easily but it is an annoyance when the only programs that you ever really need to install them for are the closed source programs you want to run.

Share this post


Link to post
Share on other sites

I'm not an expert, but here are my thoughts. I think it's common practice to only provide 32-bit versions of GNU/Linux ports of commercial games. That'll probably be fine for this project as well, since 64-bit GNU/Linux users are aware of their situation and should be capable of configuring their machines to run 32-bit software (with ia32-libs libraries or whatever). Given what I just wrote, I fail to see why a 64-bit version is a must. Also, if there's some kind of installer that asks for the install path (and whether startup menu entries should be created), then a single .run file for all distros should be fine. In time it will be useful to know some system requirements, like Linux kernel version x or later, CPU x or better, glibc x or later, minimum of x MB RAM, x video card, things like that.

Share this post


Link to post
Share on other sites
Hey there! For a second, pretend I'm actually not all that smart (I know, just bear with me). Can you explain whence comes the desire for 64-bit libraries and executables? Is it a convenience thing for the end-user? Is it an absolute necessity (eg, the OS will flat-out not be able to execute 32-bit code)? Something in-between?

64-bit CPUs have the ability to run both 64-bit and 32-bit binaries but in order to do so the userland must also be able to run both. Windows developers don't bother shipping 64-bit binaries because every version of 64-bit Windows includes the ability to run 32-bit binaries as well. 32-bit Linux installed on a 64-bit-capable CPU acts normal and would run 32-bit (but not 64-bit) binaries. Unlike Windows, not all 64-bit Linux distributions include multilibrary capability by default, so they can only run 64-bit binaries -- 32-bit binaries just won't run (and trying to run them generates confusing error messages, such as "file not found" even though it's right there). Most (all?) 64-bit Linux distributions include, by default or optionally, the ability to run 32-bit binaries/libraries by including a multilib glibc and also include most 32-bit libraries that may be required by 32-bit binaries to run. This often means having two complete sets of libraries running side-by-side just to be able to run a relatively rare 32-bit-only application. They take up disk space and it means running two sets of libraries in RAM. Proprietary video drivers (like nVidia's driver or AMD's fglrx) often need to be recompiled/reinstalled to include both 32-bit and 64-bit versions of the driver to get hardware acceleration working for 32-bit libraries.

Basically, it's a very messy situation and anyone who runs a pure 64-bit distro needs to jump through hoops to get a 32-bit application running, and since there are so few applications in the Linux world that are binary-only and even fewer that are 32-bit binary-only it is frustrating to have to clutter up the system just for one or two apps. It also means having to manage two sets of packages when updating packages (eg. for security vulnerabilities).

I actively avoid multilib because of the headaches it creates (when compiling applications, sometimes a configure script will accidentally find the 32-bit library instead of the desired 64-bit library and fail to compile, and it may be difficult to get it to locate the right library). In the worst case scenario I am capable of installing it just for DFA and uninstalling it afterwards (I did so for Machinarium and Botanicula) but it means I will probably only play it once or very, very rarely since I don't want multilib packages on my system permanently. That being said, I've been using Linux for several years so I know what I'm doing; if a less technically savvy user installs a distro without multilib capability out of the box, they may not be able to figure out what to do.

Every piece of open source software, graphical or otherwise, that I have ever come across, with the possible exception of some emulators (which I haven't encountered but know they exist), has been compilable for both 32-bit and 64-bit flavours of Linux. I fail to understand why any reasonably coded piece of software should, in 2012, be architecture-specific, especially with great cross-platform cross-architecture technologies like OpenGL that remove the necessity of addressing hardware directly.

Of course, in the end I won't die if only a 32-bit binary is provided -- but it would be an unfortunate occurrence that would frustrate the 64-bit purists out there.

Share this post


Link to post
Share on other sites
Unlike Windows, not all 64-bit Linux distributions include multilibrary capability by default, so they can only run 64-bit binaries -- 32-bit binaries just won't run (and trying to run them generates confusing error messages, such as "file not found" even though it's right there).

This cracked me up. This is exactly what happened when I tried to run Machinarium. I finally gave up and found a script to install it for me. I figured I'd give the link for it to give some enlightenment on what needs to be done to support 32-bit games on 64-bit Linux architectures.

One other suggestion, I'd like to add, would be to set up a wiki so that people from different distros can explain what fine tuning needs to be done(if any) to get the game working on their particular distro.

Share this post


Link to post
Share on other sites

I agree - simple DEB, RPM, and tar.gz packages would be good enough. Given the .tar.gz (maybe containing engine source and proprietary game files?), anyone can make a package to work with their favourite distro, without DF needing to worry too much about distro support.

It would be nice if it was submitted to the Ubuntu Software Centre as well.

Differentiating between 64-bit and 32-bit is probably not necessary, unless it's trivial for the developers to compile as a 64-bit executable.

The driver thing will depend on how well your graphics card is supported in a given driver. But my guess is that because 3D isn't involved, it probably wont be an issue.

Share this post


Link to post
Share on other sites
...unless it's trivial for the developers to compile as a 64-bit executable.

It should be; lots and lots of open source projects are doing this, so why not DF?

Share this post


Link to post
Share on other sites
...unless it's trivial for the developers to compile as a 64-bit executable.

It should be; lots and lots of open source projects are doing this, so why not DF?

Depending on the development platform, it can be either trivial or very difficult.

Share this post


Link to post
Share on other sites

I think different distros don't have to be a huge issue. The easiest solution that will be both convenient for users and will also make sure things don't brake in the future, would be to release the engine code (including the modifications) so it can be included in the distros by the distributors themselves. All the art, sound, script and so on could then be a separate package (for sale of course, and also proprietary) that can be dropped in a certain directory.

Another option that is used by other software developers is to include all the libraries and not use the system ones. In this case the distro doesn't matter much either. I think the first option is preferable, though.

Share this post


Link to post
Share on other sites

I would definitely like to see 64-bit binaries (for reasons given already above, e.g. by T3slider)!

Alternatively all the required libraries should be included (as suggested by Soong).

Please do consider these options, DF!

Share this post


Link to post
Share on other sites

I think (officially) supporting few distributions is not a huge issue because everybody has access to virtually all distributions anyways so everybody will be able to play the game that way or another. Of course, it would be inconvenient to install an operating system just for a single game but it's already much better than being forced to pay for a Windows licence or to buy a Mac.

Also most people run Ubuntu or a Ubuntu derivative so double fine should make sure that it runs on Ubuntu and then see how much recources it has to make sure that it will also run on the other distributions and make packages. I agree with your selection, that probably besides Ubuntu, Fedora and OpenSuse would be probably the most important ones. It might also make sense to support Debian, because that would also cover Ubuntu.

Share this post


Link to post
Share on other sites

I, for one, don't give a damn about 64bits builds - although I use 64bit linux on many machines.

I don't think spending time to get 64bits binaries has much value over using the same time to get, say, a few extra puzzles in the game. Or more polished 32bits version (one which doesn't crash in 4 years when some library decides to change some undocumented behaviour).

If 32 bits environment is hard to set up, blame your distro.

If you are so tight in disk space to care about the whopping 100MB-ballpark the 32bits counterpart of libraries take, you should probably consider moving to a new hard disk.

There are really only two fields where 64bits becomes essential: high performances making good use of the extra registers, and high non-pointer memory usage (>2GB). I think DFA fits in neither (of course, it needs to run decently... but I can't imagine a 2d game really needing extra registers to make a difference).

Take a look at Debian's popularity contest results: there are recently just as many i386 as amd64 submissions (first graph, "submissions per architecture", mind the logarithmic scale).

Heck, I would even welcome using wine to run DFA, as long as it was written with wine compatibility in mind (OpenGL, checking if the game runs fine there) and maybe some fixes get contributed to wine. I would get a working DFA and better-working other windows apps. The only reason I see to not use wine would be from developer point of view: I'm not sure I would enjoy tracking down a crash when I have an extra layer to trace through. Native binaries + gdb + valgrind should be more debug-friendly (disclaimer: no developer-side experience in working with wine, although I use it often and contribute to it occasionally).

What really matters for Linux as a market audience is that people decide to pay for something when Linux is a supported environment. This says nothing about how binaries look like nor their dependencies.

Share this post


Link to post
Share on other sites

I just installed Bastion from HumbleBundle and one the things I noticed was I that I really liked the installer. Its called nixstaller. It installed the game to my /usr/local directory put the shortcut on on my start menu and registered the install with my package manager. The FAQ says it supports rpm, dpkg, slackware's installpkg and pacman, and can be scripted using lua.

Share this post


Link to post
Share on other sites
Sign in to follow this