Steam for Linux: The Port Report

This article is mostly written with Windows users in mind, as such it explains some of the obvious differences between Unix¹ and Windows.

This article was inspired by TotalBiscuit's "Port Report" series which discusses the quality of console-to-PC ports. I decided to treat Steam for Linux as such: A Windows-to-Linux² port. Some people say I am entitled and expect too much, I feel I only expect as much as TB expects from a PC-port of a Console game. A game that actually runs like a PC game and doesn't obviously show it came from console and is a shoddy port. This is currently what Steam for Linux is, a shoddy program that clearly shows its ancestry as a Windows program that does not work well. I attempt to narrate in this article some of the reasons why.

This article is also long and thorough, so I'll give you a tl;dr at the start of every point. The tl;dr for the entire article is that Steam for Linux has a shoddy port.

1. Steam for Linux possibly fights with your window manager

tl:dr: If you use a UI or even UI settings Valve didn't test for, it's possible the Steam window will misbehave

On Unix, there's a concept called the window manager. This is a central application that manages the placements of windows. This is essential on Unix because there are many different UI's and UI paradigms around. For instance a friend of mine has a setup where one window at all times has "focus" and is enlarged to fill almost the entire screen, the unfocussed windows sit at the left as small thumbnails, only 50-by-50 pixels so he can easily select which window has focus, if need be, he can split the screen easily between two windows which have focus. All these customizable UI paradigms require that a central application manages the placement and behaviour of windows.

Steam essentially goes behind the Window manager and tries to control its own placement. There is no reason to do this ever, in fact, for an application like Steam there is no reason to even build in any special code to control its placement, the window manager itself can handle a simple normal window like that just fine (read the next issue on decoration issues).

Valve justifies this with "We don't support your window manager at this moment". This is ridiculous and unacceptable, especially because what they did here costs them more effort than just not including any code for window placement and letting the WM figure it out. The analogy I like to use to illustrate this is a console game which hardcodes mouse drivers into itself directly rather than relying on the OS abstraction and when your mouse or keyboard don't work with it they say "We don't support your mouse, only this list here" No, that's stupid, rely on the OS abstraction layer. Hardcoding controller support might work fine on consoles because everyone has the same controller, but it doesn't on PC. And likewise, on Unix, hardcoding window placement doesn't work, it's stupid and dumb and shouldn't have been done. They would've supported every window manager if they just didn't code any window placement into their application and let the window manager figure it out.

So apart from the publicly reported ones, here are some of the other issues I personally experience with Steam using the Fluxbox window manager:

resizing and moving steam via the normal window manager methods is a disaster, however resizing it and moving it via steam itself goes fine here.
If I close one steam Window via the normal window manager ways, Steam closes itself. This is annoying because my reflex when I see an ad pop up is to hold caps+x³ down for longer than 250 ms which ordinarily closes a window, in this case I have to restart Steam
Steam's window does not show up normally in my Window Manager's window list if I elect to display the window titles, if I elect to dispay the window classes it does show up, but this means that sometimes two different windows show up as Steam who share the Steam class and I have no idea which is the main one. One tool wmctrl always lists a window called N/A when Steam is running, I assume that is the Steam window not properly setting its title.

The funny part is that all those problems go away if you run Steam through Wine because Wine does properly translate the calls Steam thinks it's making to Windows to accepted communication with your WM.

2. Steam for Linux doesn't use a toolkit

tl;dr: applications on Unix do not try to control their own look and feel as to not break your desktop

On Unix, there are so called toolkits for drawing the look and feel of Windows, virtually all applications delegate the graphical side for the most part to such toolkits giving them only basic instructions. This means that all the applications on your desktop look and feel consistently with consistent scrollbars and icons and hotkeys and tabs and everything because those settings are all controlled in one central place with per-application overrides if you need them. Steam as a result stands out like a sore thumb. here is a screenshot of my destop with Steam in the middle of a partition manager, torrent client and terminal to demonstrate how one does not look like the other. My text editor, file manager, IRC client everything matches the same theme, except Steam.

Furthermore, because Steam doesn't use a toolkit, this ties into the issue above of window management. Specifically the difference between what is called client-side, and server-side decorations in Unix. Basically, a "decoration" is that nice little toolbar that is typically drawn around a window with a close button and what not. If you look closely my own decorations are nothing more than a single 1 pixel line that goes from grey to red when a window has focus. Steam implements client-side decorations. As in the close button and titlebar are part of the window itself, not something the OS draws around the window. But because a lot of people like to move the window by dragging the toolbar, Steam needs to some-how inform the window manager of that it wants to be moved when it does that, so that's why Steam currently includes code to resize and move its own window. If Steam had just used a toolkit, the toolkit would've either drawn the CSD if the user configured it as much, and thus handled talking to the window manager in the proper way for Valve. Or it would be SSD and the decoration would not be part of the window and the window manager which draws the toolbar would itself be immediately responsible for dragging the window.

As it stands, as my 1 pixel border which is impossible to click and resize might indicate. I don't resize windows by dragging the toolbar. 99% of the time I resize and move windows purely with the keyboard. The few times I use the mouse I move windows by holding down caps+MMB and resize with caps+ctrl+MMB. Steam obviously breaks like hell with either of these approaches, since the WM then tries to move the window, and steam fights with the WM over it and tries to put it back at its old position resulting into two seconds of massive flicker before eventually one of both, seemingly at random, is the winner and gets to keep the old position as the other gives up.

Now, some people might argue that Valve draws its own window rather than delegating it to a toolkit out of some artistic vision. Yes, great, that's the problem. The point of Unix is a philosophy of user-centricity. No one cares here about your goddamn artistic vision, the point is not to create an application the way you like it and let others use it but let the user control the interface according to his or her own subjective wishes and needs.

3. Steam for Linux ignores signals

tl;dr: Steam for Linux doesn't properly shut itself down and can freeze your shutdown unduly.

Signals on a Unix-like operating system are the most basic ways to communicate with a process. In its simplest use they tell a process to quit running or pause it. As such the two most important signals to send to a process are typically called SIGTERM and SIGKILL, both tell the application to stop, the former just gives an application a chance to perform some quick cleanup, the latter, only to be used when an application has become unresponsive or misbehaves gives it no such choice and immediately exits the application in the middle of whatever it is doing.

Standard runtimes already have built in functionality for SIGTERM, they close the open files and close the application, this is typically insufficient for an application of the complexity of Steam which must perform more advanced cleanup in order to not constantly corrupt its own data when you close it. To this end, Steam has decided to trap the SIGTERM signal, and then ignore it. It does nothing when it receives this signal. This is considered a supremely bad practice. Upon receiving SIGTERM an application should immediately clean itself up and exit without asking for any further confirmation, opening a GUI popup with "Are you sure?" is already unacceptable, it should close instantly which is what most applications do.

So much so in fact that a lot of Unix systems upon shutdown send SIGTERM to all running processes, they then collectively give them 1 second to clean up, if they failed to do that within a second the system treats them as unresponsive and sends SIGKILL which as said is a bad idea because it can lead to corrupted data. A program that takes longer than 1 second to exit upon receiving SIGTERM is considered to misbehave, ignoring the signal alltogether simply breaks how Unix works. Various things in Unix are built upon the idea that a process quits gracefully if being sent SIGTERM, a lot of shutdown sequences freeze if this is not the case, a process not responding to SIGTERM might as well be treated like a frozen and unresponsive software. An automated program that needs to close other programs during a shutdown sequence cannot press an x with a cursor. That it works like this is probably also one of the reasons that when I give the shutdown command to my computer it shuts down within half a second from a full desktop which would take longer on Windows.

In the end, Unix is in fact far more fragile to this kind of stuff than Windows because it had a longer history of applications "behaving properly", Windows has a lot more catching mechanisms for improperly behaving applications.

4. Steam for Linux has an interface that is out of place.

tl:dr: Steam has the interface of a Windows application, it does not obey the typical conventions and interface laws common to Unix applications

Even ignoring that it doesn't use toolkits, its interface feels like a Windows application. Unix has traditionally had a different interface, I for instance can't remember the last time I double clicked⁴ on anything and probably never did on Unix. Apart from that, I seldom click. Unix is a keyboard-driven world. Hotkeys and terminals are the name of the game, hotkeys are everywhere and customizable, virtually all applications are controllable purely with customizable keyboard shortcuts. As of writing this I haven't touched the mouse in little under two hours. The interface Steam comes with is a Windows one, it does not appeal to normal Unix conventions. A couple of things:

Virtually nothing is accessible with keyboard-only.
Some of the drop-down menus activate when you hover over them, I have never seen this in Unix, menus don't drop down when you hover, you have to click
weird help popups in general show if you hover over things with your mouse. This is a Windows-ism that is mostly considered annoying, I'm sure toolkits have an option to turn this on but it isn't by default, the general design sensibility is that a cursor shouldn't do anything by just being at some place and stuff should be clicked before an action is taken, otherwise the cursor just becomes annoying and has to be put to the side all the time. Since a lot of Unix desktops have "edge bindings" where things happen if the cursor is placed against the edge of the screen, it's annoying if it can accidentally do stuff if it's in the middle of it.
The scrollbar works weirdly in that clicking outside of the bar scrolls to a position which is counter-intuitive to where it should scroll to on Unix, basically it goes way too far.
Simply the entire interface and placement of things
Drop-down menus automatically collapse when your mouse moves outside of their boundaries. Not sure if this is normal Windows behaviour but on Unix they only collapse if you click somewhere else. It´s kind of annoying that they constantly disappear.
The cursor changes for various texts to indicate it is selectable, yet, it is not selectable, I haven't found a way to select it anyway.

5. Steam for Linux ignores common command line options

tl;dr: Steam does not respect common conventions for command line arguments that everything supports

Like any Unix application, the Steam for Linux client is an executable which can be be started like any other. While on Windows the most common way to start an executable is double-clicking on it. A lot of Unix users don't even use a graphical file manager and the tradition of simply starting something by typing the command in the terminal still very much lives. Terminals are everywhere on Unix, it is the to-go way to do most things because it's generally considered faster than using a GUI albeit requiring the memorization of sometimes complex commands.

There is a long standing tradition for any application to support the --help and --version arguments, so much so that the true program whose only purpose is to do nothing and exit immediately, at least on my system (GNU true) still supports --help and --version:

The /usr/bin/steam⁵ executable ignores any and all command line arguments given to it seems to be the case from inspection. If you type steam --help into your terminal, it starts steam and opens a GUI. That is supreme bad practice to actually start a GUI window. Even if it didn't support the --help flag argument, it should at the very least raise an error of being given an unsupported flag. Arguments starting with a - are considered flags with a special meaning and flags entered which are not supported should raise an error or warning. A lot of tools generate help documentation by trying what executable --help does and capturing its output and running one of those on steam results in a random GUI window starting for no reason.

6. Steam for Linux is 32 bit

tl;dr: Unix doesn't use 32 bit any more, it's much, much rarer than on Windows

32 bit is old, outdated, for some reason many Windows applications still use 32 bit. Sometimes an application doesn't actually need 64 bit for anything, and that's a valid reason to not switch but it means you need 32 bit libraries on your system.

In order to install Steam for Linux I had to install a bunch of 32 bit shared libraries which exist purely for Steam. They weren't on my system before that because everything is 64 bit. Unix has moved on from 32 bit a long time ago. I essentially need these libraries duplicated for 32 and 64 bit for one program a lot of the time. Given its closed-source nature, 32 bit is common on Windows but on Unix it is highly exceptional to still be serving applications 32-bit only, some have even stopped altogether supporting 32 bit, it's outdated technology.

7. Steam for Linux' install strategy is silly

tl;dr: the traditional placement of installed program files on Unix is very complicated for very good reasons, Steam breaks this and installs things in a simple single folder the Windows way

How Steam on Linux is installed is inane. How it works is that the actual package you actually install is a launcher which when ran will then proceed to fully install all program data in your home directory the first time you run it. That's 1.3 GB for me.

On Unix a distinction between various forms of program data are typically made, the most important part is sharable data. It's the part of programs that can be shared between multiple users, as such it should be shared between multiple users and it typically goes in the root directory which is shared between all users, not the home directory which belongs to only one user. Steam's install method means that data massively has to be reduplicated for multiple users, on top of that it means that removing Steam on an OS level doesn't actually remove it. You then have to clean that folder out where Steam dumps its stuff and know where it is.

Unix is traditionally built upon the idea, unlike Windows, that file paths of data actually aren't that relevant. On Windows when you install software you typically choose where to, on Unix, you really don't, you let the installer figure that out and it doesn't matter, in fact, software has a tendency to stop working if you move it. You don't start applications by navigating to the folder and clicking an executable on Unix, that's just not how it works, there are desktop application entries which keep track of all that for you. This typically means that unlike in Windows, program installation is scattered, not monolithic, the files belonging to one program are typically scattered across multiple directories. This might seem silly but this is done for a good reason. The different files have different properties. For instance files inside /usr/share and /usr/lib are sharable and do not need to ever be written to or modified during normal program execution.

This is important because on Unix there are many different options for so called "file systems" which is the low level implementation of how files are stored inside bits on your drive. Some filesystems are optimized for fast reads, but as a consequence their writes are slower. Some people thus elect to put /usr/share on such a filesystem which may make installation of new software more lengthily but means software is more performant when it runs. This is a bad idea to do with /var and /tmp where files of a program which are constantly modified during program execution are put. In fact, since /tmp can only contain files which do not need to survive a reboot ever. A lot of people put /tmp on a ramdisk for this purpose instead of an actual drive.

Putting stuff all inside a user's home directoy not only duplicates the size of installed files for no real reason, but it also negates those possible advantages. My /usr/share maps to an SSD while my home directory, which is traditionally used to store personal data files like pictures, documents, music, etc. is mapped to an old fashioned spinning disk and my /tmp is indeed mapped to a ramdisk.

8. Steam for Linux implements no form of Unix IPC

tl;dr: Steam lacks the powerful remote-control interfaces that Unix applications are typically accompanied with

IPC or "inter process communication" are basically ways for programs to communicate with each other, the simplest form, signals, I already gave. Unix is all about IPC. Processes communicate with each other and you can write simple processes that communicate with other processes. Most of the functions programs export via their GUI they also export via IPC so that you can write other programs which communicate with it. I can go onto the command line right now and dive into the DBus IPC layer to instruct the text editor by which I am writing this article to save the current file or to open a new one or to change whatever setting. This is very common on Unix, it's a culture where people like to write scripts to automate stuff and the applications accomodate that.

Steam doesn't implement any of this. If Steam was a working Unix application that felt like one there would probably be DBus IPC exported to retrieve the list of games inside the library, to start a download of a particular game, to start a game, to uninstall a given game. If I want to write a script that automatically starts Steam downloads at sleeping hours and stops them again when I wake up or automatically pauses steam downloads when my system detects high internet ping because I'm using the bandwidth for a multi-player game, that sounds like a real use case to me. This isn't some esoteric thing, yes, I understand Windows users don't often do this but this is why people use Unix and why it became so popular with researchers, companies and programmers. The entire point of the so called "Unix Philosophy" is user-centricity and enabling you to automate and customize your computer to your specific needs and wishes.

I have many scripts with functionality like that running. My cat kept shutting my computer down by pressing the off button so so I made a simple script which ensured that the off button only works if there has been keyboard activity within the last 10 seconds but not as the button is being pressed to avoid that. Being able to do that is "The Unix Way", all applications here support being able to write scripts that enable you to do that, and Steam stands out like a sore thumb.

9. Steam for Linux does many things, not so well.

tl;dr: Steam's individual functionality is not decoupled from each other like proper Unix software design entails

The core part of the "Unix philosophy" has always been the immortal sentence "It should do one thing, and do it well". This has been how Unix applications have always been designed, with a small, limited scope, as small as possible. Unlike in Windows "many features" is not seen as a good thing but as a bad thing. It should focus on a small set of features and implement them properly. And if you want other features, well, then you get another application for that? And yes, this all works together seamlessly because of the aforementioned Unix IPC that allows programs to communicate with each other. This means that you have choice and can pick whatever you want. Steam is:

A shop
A social network
A chat client
A DRM product
An application launcher

And more ancillary functions. These things should all be separated. You should really just be able to get your own chat client and if possible link it up to Steam via IPC. This leads to fragmentation, you now need you own actual chat client like pidgin and steam on top of that to communicate with friends leaving stuff disorganized. The "Unix Way" of doing this wss for Steam not to implement its own chat client but interface with another one to be able mark contacts there as steam friends and link them together. Having to first launch steam via your own application launcher, and then via Steam again the game is also annoying. There are many different application launchers on Unix, each for people all with different needs.

10. Steam for Linux is not open source

Yap, I'm just going to say it. I can get people keeping games closed source and other software that costs money. But Steam is gratis, it doesn't cost any money. What's the harm in letting people see the source code and modify it to their own needs? It's not going to lead to piracy because it's all tied to your account anyway which you can't modify because it's stored on a service.

If DRM is the issue, just isolate the core DRM component of Steam and keep that closed source and implement a public-key system to ensure that games can't launch without the DRM component, but everything else can and should be open source. Are they afraid peope wil pirate the Steam client?

Conclusion

Steam for Linux feels like a windows application outside of its natural habitat. It takes advantage of none of the things Linux has over Windows, and it simply drops support for any of the advantages Windows has over Linux giving nothing to replace it. You can effectively approach Steam for Linux as the equivalent of a console game coming to Windows that:

is locked at 30 FPS where 60 FPS is the norm (32 bit)
for some reason does not work with you deluxe gaming mouse (fights with you window manager)
looks and feels like a console application that asks you to "press start" to continue at startup while you try to figure out what random key they choose to map "start" to (does not respect your toolkit and global hotkey configuration)
blocks and then ignores your alt-tab (blocks and ignores SIGTERM)
requires you to insert the DVD every time to play it (bizarre windows-like install strategy that feels out of place on Unix)
has next to no options menu where you are acustomed to a great deal of customization to tune the game to your specific needs

So is this normal for ports?

No, not as far as I can tell, there are a lot of Windows-to-Linux ports which have been done in a far better way. Ironically for how much flake Skype for Linux gets, it's actually a much better port that doesn't suffer from a lot of the issues. It does not ignore signals, it properly uses a toolkit and doesn't fight with your window manager accordingly, its install strategy respects the Unix conventions, It implements a lot of Unix IPC and it even gives a nice help printout on --help as well. Hell, it's a bit buggy at times, but it's clear they made more of an effort than Valve has.

footnotes

You will often see me say "Unix" in this article. For those that don't know, what is commonly called "Linux" is in fact a gratis and open sour clone of the original Unix OS from the 1970's. This OS is often imitated by a variety of people. While the term "Unix" is technically trademarked, most people believe the trademark to be genericized at this point, as such the term "Unix" in this article is used to refer to the various modifications and re-implementations of the original AT&T Unix® around today.
The term "Linux" is nowadays used to refer to a variety of operating systems which use Linux. Technically speaking. Linux™ is only a re-implementation of the Unix® Kernel which is a part of an operating system. If an operating system is a car and the hardware the road it drives on, then the kernel is the engine and its wheels. Not even the mechanism that connects the engine to the wheels, not a chassis that keeps it from falling apart, not a driver's seat nor a steering wheel nor a clutch. For historical reasons, the short term to refer to a family of operating systems which all use Linux™ (typically called "The Linux Kernel" in this context) has simply become "Linux". This term is inaccurate and causes confusion as well as in the eyes of many people improperly disrespectful the GNU project and its ideals which actually contributed significantly more to most "Linux" operating systems than the Linux project has. But it's here to stay all the same.
It is very common on Unix to repurpose the caps lock key to other functionality. Escape tends to be a common favourite since it's often used and far away. For me caps lock functions as just another modifier though
The reason many web-sensibilities like single-clicking and forward slashes (/) rather than backslashes (\) are used is because the web started on Unix. As a bit of trivia it was originally developed on the NeXTSTEP Unix variant which is actually the ancestor of Mac OS X which while retaining the user interface sensibilities of Mac OS 9 at its operational core is fundamentally a form of Unix and has much in common with Linux if you look under the hood.
I'm usually not one to criticize software on simple bugs that get fixed quickly, especially when they are caused by small oversights but this bug had such disastous consequences that it deserves a mention in the footnotes. There was a bug in Steam which caused it to delete all files on the OS owned by the use it was run as. All your music and data and documents nad work gone basically.

Brottweiler/Steam for Linux: The Port Report.md