20160330 - Practical Example of Things Linux Supporters Should Fix

Based on a true story ... literally happening right now, it's March 31st and Hyper Light Drifter has just been released. I'd like to play the game, and wow it is supposed to actually have Linux support.

Step 1: I go to www.heart-machine.com and see if I can just pay the developer directly and download a Linux binary of the game. As a fellow developer I'd much rather pay a developer directly for a game that I'm interested in, than purchasing through a third party who takes a cut of the pie.

Fail 1: No ability to buy the game directly, must go through Steam.

Step 2: I go to store.steampowered.com and attempt to download and install Steam on my Linux box.

Fail 2: Clicking the "Download" button takes me here: repo.steampowered.com/steam/archive/precise/steam_latest.deb but with an error message from the server.


You don't have permission to access /steam/archive/precise/steam_latest.deb on this server.
Apache/2.2.22 (Ubuntu) Server at repo.steamstatic.com Port 80

Ok, so for whatever reason the Steam download link for Linux is/was broken. But even if it worked, the download would be useless to me, as it is only a Debian package, and I'm not running Ubuntu, so I have no way to install that package without manually installing something which can unpack DEB files, then attempting to manually install whatever my specific Linux box doesn't have which Steam might depend on.

No easy way to get the game, no easy way to install Steam. This is an example of the typical "Linux experience" today.

I'm still going to get the game, but I'm waiting for the PS4 version. I'd like to support Linux, but quite frankly that is impossible as long "It Just Doesn't Work".

A Better Time
Another story, back when I worked for Wolfram Research ages ago, working on the UNIX part of the Mathematica frontend and also building the UNIX audio support, at the time, Mathematica ran on something on the order of 9 UNIX/BSD platforms: Linux/SunOS/AIX/Solaris/etc. Mathematica was statically linked. It just worked. Period.

Seriously, it just worked.

You got a fantastic experience regardless of what platform you were on, or what Linux distro you had on your machine.

Dependency Nightmare
Between the time when I was writing a fork() based audio engine in Mathematica and now attempting to find a way to just give the developer money and get a working Linux binary of a game I'd like to play, the industry adopted this nightmare policy of dynamic linking to a hairball of rolling release libraries.

Now nothing ever works.

Seriously, a 1TB harddrive is $50. The idea that there is a need to dynamically link to save space is utter insanity.

Problem Practices
If you are "supporting" Linux and falling into one of these cases, you are doing serious damage to any effort to make Linux a viable platform.

(1.) Distributing a {insert a specific Linux distro package} file instead of a tgz file which works on any Linux machine.

(2.) Distributing a binary which dynamically links to a tree sized library dependency chain.

(3.) Requiring a user or developer to manually build your software.

Taking Responsibility
As a Linux developer I strive to link to just one thing, libdl.so. I only use direct syscalls except for {OpenGL/Vulkan, ALSA, Xlib} and those I dlopen() when possible. If syscall mapping changes for a Linux version, I'll just release different binaries. This is about as anti-dependency as is possible, and it best ensures things just work.

For me it was trivial to not use libc and go direct to native system calls. It saves me a tremendous amount of time and pain by NOT depending on other people's broken software libraries and instead writing things directly.

As for the "real world" there are examples of the "right way" to do "libraries". Like STB (stb_howto.txt is a great read). Single file headers with little or no dependencies which a developer includes into a project instead of linking to. Problem solved.