If you work on Windows etc. you might easily run into a one way, os specific street sooner or later

You forget that this is the choice of the developer / team. If someone picked Windows Server over Linux, it is very unlikely they will be shocked that things like powershell / IIS are windows only, my point is the developer / team likely is aware of what is os dependant and what isn't and would likely have picked an os dependant solution for many reasons but it would always be obvious to them what's cross platform and what isn't

Any yes supporting Linux is also recommended, because the upcoming Steam Box will be running Linux.

This assumes that a) it ever in fact appears and b) that it captures significant market share to be worth while.

Yeah, doesn't seem like it may be coming out any time soon, if at all (especially not after they did that mass firing).

That said, Linux is still worth supporting, the amount of users is surprisingly sizable (and since they're mostly tech savvy that means they're more likely to want games) and the platform is still starved of games (i.e. it isn't saturated yet). If you're an indie (thereby low costs) and you plan in advance to make the game portable it's probably worth the try. Just don't treat Linux players like lesser beigns (I'm still annoyed by many games that have demos on Windows but not Linux - c'mon?)

I evaluated the option of supporting linux for gfxapi earlier this year. I supported Mac OSX already before that. I ended up realizing that

- naturally OSX -> linux transition is easier than Windows -> linux transition, but there are multiple OSX-specific platform (e.g. Cocoa) code that need to be rewritten for linux (e.g. X11), so cannot naively assume "osx == linux since both are unix-based".

- There is no single linux, but there are hundreds of them. This is the big problem. Testing is a BIG pain. System distro, 3D drivers, exact OS version, HW setups, user's custom installed packages, creates a huge combinatiorial explosion of targets to test on. In practice, even big companies simplify this and e.g. Valve goes "linux == ubuntu" to avoid having to test on everything.

- There is no way to build a binary app and have a guarantee it will run on any other linux than what you built it on. You need to be aware of the exact dylib and runtime dependenices your app has for it to be portable across linuxes that have chosen to host different system runtimes. Different distros have different file system directory hierarchies, different packaging managers, and different sets of dylibs. This is much worse than the "DLL hell" on Windows, due to the previous bullet point. Trying to go the route of "I'll make a single installer exe for my game that linux people can run to install/launch/run the game" just is not possible, because there are no standards that are guaranteed across linuxes. In practice if you invest the time and effort to become knowledgeable of all the distros and distro versions that you are interested in, you will most likely be able to solve this, but you can already see that it will take a lot of time and effort to accumulate all that distro-wide knowledge.

- The OSS people say that none of the above should be a problem, since "if you make a project that is interesting enough, then people will come and port your game on their distro", but that's a very utopistic attitude, and assumes that you are releasing your game and assets free as open source.

In the end, I set up a single Ubuntu 12.04 box, and implemented gfxapi for linux against that, and I'm now running unit tests on that system to check that it works. For deployment, I build a single executable file that has all the required assets built-in. As far as other distros than Ubuntu 12.04 go, I just assume they don't exist. In the end, I think porting from OSX to linux took about a week for the actual "meat", i.e. the platform-specific code, and about three weeks with testing, GL driver debugging, deployment, X11 woes, and build system, a lot of which are this kind of "invisible" issues that are not in the code itself.

There was one surprising benefit to making the linux port, which is valgrind. I now run that as part of my automated unit test suite, and it is very helpful in finding certain types of errors, and has helped me to fix bugs for other platforms as well. Valgrind alone is perhaps a good enough reason to port a C++ codebase to linux (or OSX <= 10.7), even if the game will not be published on that platform.

The 'distro hell' is a sizable reason as to why I wouldn't bother doing a Linux version personally - as much as I dislike Apple I'd rather make an iOS port of something than a Linux one because at least their eco-system is sane. The fact that chunks of the 'Linux community' seem to enjoy shooting their platform in the foot (over binary drivers and GPL-API interfaces) is just the icing on the cake.

And don't get me started on the "if it isn't GPL you are the devil crowd..", I mean, I support open source by releasing my stuff under zlib/mit, but those 'gpl or death' guys... man, fuck those guys...

- There is no way to build a binary app and have a guarantee it will run on any other linux than what you built it on. You need to be aware of the exact dylib and runtime dependenices your app has for it to be portable across linuxes that have chosen to host different system runtimes. Different distros have different file system directory hierarchies, different packaging managers, and different sets of dylibs. This is much worse than the "DLL hell" on Windows, due to the previous bullet point. Trying to go the route of "I'll make a single installer exe for my game that linux people can run to install/launch/run the game" just is not possible, because there are no standards that are guaranteed across linuxes. In practice if you invest the time and effort to become knowledgeable of all the distros and distro versions that you are interested in, you will most likely be able to solve this, but you can already see that it will take a lot of time and effort to accumulate all that distro-wide knowledge.

The 90s called, they want their complaints back, There is a standard and all big distros are fully compliant.

If you build strictly against a LSB version (preferably using the LSB SDK since it ensures you don't break compatibility by accident) the install package and binaries will work on all compliant distros. (If you need to use non standardized libraries you can link them statically to avoid compatibility issues)

- naturally OSX -> linux transition is easier than Windows -> linux transition, but there are multiple OSX-specific platform (e.g. Cocoa) code that need to be rewritten for linux (e.g. X11), so cannot naively assume "osx == linux since both are unix-based".

Honestly, the only thing in common is that they have full implementations of POSIX (which is usually more helpful than the C standard library - heck, it was a competitor for it), along with any tools that rely on POSIX. Otherwise they're so different from each other that claiming that supporting one eases the effort for the other is just plain stupid (except maybe that since you have to use OpenGL on both you avoid the problem of porting Direct3D code, but that assumes you were using Direct3D for starters).

There was one surprising benefit to making the linux port, which is valgrind. I now run that as part of my automated unit test suite, and it is very helpful in finding certain types of errors, and has helped me to fix bugs for other platforms as well. Valgrind alone is perhaps a good enough reason to port a C++ codebase to linux (or OSX <= 10.7), even if the game will not be published on that platform.

This. In the end I find it being more useful than the debugger for me =/ (especially since whenever something goes wrong with my code it tends to be something the debugger doesn't like either) It's way more helpful at telling which piece of code did something bad that later results in a crash or something.

And don't get me started on the "if it isn't GPL you are the devil crowd..", I mean, I support open source by releasing my stuff under zlib/mit, but those 'gpl or death' guys... man, fuck those guys...

They're a minority these days (and there are just as many "BSD or go to hell" guys who hate the GPL).

You probably won't want to bother with them anyway. They don't just want GPL, they want everything to be an open community project, something that really doesn't get along well with the idea of paying for something at all (except maybe for donations). Don't say services, that's a completely separate thing and can't be applied to everything either.

The #1 reason I gave up attempting to adapt code to Linux was compatibility issues.

Each Linux distro isn't quite the same, and as such something that works on one version, won't work on another version.

I really was tired of making 6 versions of the same thing, just for Linux.

If you Linux port needs more than X11, libGL, and libAL, send us a postcard from hell.

Or uses something other than SDL (trying to use any system API directly is the worst idea you could ever have), though I must say, PhysicsFS works pretty well on Linux.

In fact, if you make a port then try to switch to portable libraries only directly. There will be so many issues when porting that you will probably just want to leave the job to somebody else (i.e. exactly what happens with third-party libraries). This doesn't just go for Linux, this suggestion goes for porting to any platform in general.

I've compiled a X-Plane plugin on Ubuntu. Now I tell the users to install with the software Manager: sdl, sdl_image and curl.

The very last thing I'd do is to test it on other Linuxes. 32/64bit also with Osx and Win8 is enough... I'd rather drop 32bit soon.

You need to be aware of the exact dylib and runtime dependenices your app has for it to be portable across linuxes that have chosen to host different system runtimes.

Only for very few alike libpng. Most libs are backward compatible, hence work on almost any distro out of the box. Any users with problems are asked to update their libs, but

I had none with problems so far...but I use sdl_image and not libpng etc. If you want to use libpng etc., static linking is your friend.