The Steam Trade-off as a Linux User

With the excitement around Epic launching their own store and the advent of fresh competition for Valve’s Steam, here are some thoughts from a Linux gamer perspective.

First, what is the meaning of Steam or any storefront? They are a middleman, providing a marketplace for games to be bought and sold. But they are also a steward of that market, providing a common tissue for the delivery of the games, for the discussion and discovery, and all these other features. Some have more popular off-platform competitors. Others are too ingrained in the platform to be competed on without an alternative platform.

But one of the thing that Valve is doing with Steam, which it seems unlikely that Epic or any of the newcomers will do, is to spend resources in the interest of Linux-based gaming. They have supported Linux for several years now, including for their own games. They are doubling-down on this support with the SteamPlay/Proton integration that allows for Windows games to be run on Linux through an implementation of the Windows APIs.

Part of what you pay for when you pay the “Steam tax” (or the “Epic tax” or any other share of a sale that goes to an intermediary) is for the other activities a platform or marketplace delivers. Whether that’s Linux support or community forums or ARGs, the business decides what to deliver and thereby justify their fee.

The option of going to Epic’s store, or to other stores, is weaker for Linux due to lack of support. Steam deciding to make Proton such a first-class offering only makes that proposition weaker. For Linux gaming at the moment, Steam is the most attractive option, and there are no signs of that changing soon.

Steam currently supports gaming for Linux, but if they didn’t, Linux gamers would keep using WINE directly, as we did before 2013. As long as Valve is investing in Linux, though, their tax seems like a fair deal for Linux users, when the alternative is Epic’s lower tax but nothing for Linux.

Steamworks’ Announced Changes for 2019

Steam: Steamworks Development: 14 January 2019: “2018 Year in Review” announced some expected changes in 2019, including:

  • Steam Library Update—A refresh of the Steam client akin to the refresh of the Steam Chat that occurred in 2018.
  • New Events System—A way for games (and groups?) to announce non-release events to their followers.
  • Steam Chat for Mobile—Apparently a separate app that includes the upgrades to Steam Chat on the client.
  • Steam Trust—A provider-side reputation system that helps games moderate their players better.

Valve-time being a thing, we’ll see if these rollout this year (there were others, but these were the ones that interested me).

Library update

The Library refresh has been pending for several years and is long-expected and desired (though undoubtedly subject to backlash by a vocal minority). Games have changed a lot over the years, but the Steam Library view has stayed the same, so it will be interesting to see what this ends up looking like. It will also be interesting to see if there’s any visual-crossover between the refresh of the Library and Big Picture Mode.

At least some of the facilities mentioned in my recent post about instrumenting games for streaming could be useful for a future version of the Steam Library. For example, logging capabilities in games could easily populate the game-view in the library with details from your last game session.

Events system update

The events system is primarily an opportunity to let developers remind players about their game over time, in ways they largely already do on Twitter, but where many players may not see them. It’s not clear if the event system will apply to groups as well. Groups have been able to announce events for awhile, but if they’re granted the same abilities under the new system, it could be a shot in the arm for social-on-Steam, particularly when many gamers are far more reliant on Discord.

A full-featured event system could even let non-group events happen in the vein of “bowling night” among friends. If a group of friends likes to play together at a set time every week, Steam could enable that without them needing to create a full-on group. If game makers wanted to encourage that among players, they could also be empowered to do so.

Steam chat for mobile

The advent of a separate app for chat seems unwise (the language in the announcement is: “We’re going to ship a new Steam Chat mobile app…”). Hopefully they mean that they’ll ship a new version of the Steam app that includes chat upgrades. If not, oy. There’s a new contender to replace the old law that all applications expand to encompass e-mail: all providers expand to release a mobile chat application.

Steam Trust as a service

And Steam Trust will be welcome to the extent it helps reduce griefing and cheating in multiplayer games.


The Steam Client Beta for Linux added a force-Proton option on 17 January 2019, which is great news and shows that Valve is hitting the ground running this year. The option allows Linux gamers to choose to run the Windows version even when a Linux version exists, which may help in some circumstances:

  1. Bad ports—Not all Linux ports of games are up to snuff.
  2. Upstream bugs—Whether in the game’s engine or a video driver, sometimes bugs in other places break the native version, but not the Proton version.
  3. Missing features—Some ports are great, but for whatever reason miss a feature or two. Being able to use the native version for just those cases is a great option to have.

There are arguments about whether Proton diminishes the desire of developers to write Linux-native games or to invest in ports to Linux, but Valve’s strategy is two-fold:

  1. Get people playing on Linux, especially those who already love Linux but feel bound to Windows for a few games.
  2. Invest in Vulkan and other technologies that lower the cost of writing cross-platform games.

The latter is especially important, as games that aren’t written for Windows-specific APIs are much easier to port to Linux. It’s a longer-term strategy, but it should pay off both in better game performance generally and in portability.

Why Valve is Doing SteamOS

Lots of people question why Valve wants to make SteamOS, Steam Machines, Steam Link, Steam Controllers. But Valve has been pretty open about their reasons. They are in several businesses:

  1. Making games
  2. Making game engines
  3. Selling games

They probably make the most off the third, but they still do the first two. But the third is a driver of decisions for them. They surely ask, as any business, “how do we expand?” To sell more games requires more people buying games. And as the PC declines a bit, that means other platforms.

Mobile, although increasing in power and certainly ubiquitous, is not currently a prime target. The living room is. The living room is a proven gaming environment. The living room has the big screen and the comfy couch. It makes a lot of sense for a gaming company to want to be there.

This same logic is driving decisions about engine design, not just for Valve but across the industry. Making content easier to create means a larger market with more lottery tickets to win consumer dollars. It makes the platform broader and expands what gaming means. So does game streaming, which is becoming more popular.

Other businesses could learn a lot from Valve and the gaming industry in this regard. Building out transport and lowering the friction to relocate to new opportunities would do wonders for the economy. Valve is doing both of those, in their own way, in their own market, with SteamOS.

By making a living room PC platform, they’re bridging a divide between two long-isolated groups: console gamers and PC gamers. With SteamOS in the living room, people will actually be able to play against mouse-and-keyboard gamers (either with a Steam Controller or with a mouse and keyboard).

At the same time, the console makers are pushing their own initiatives to do the same. But at present it’s not clear if you will be able to buy a game for a console and play it on a PC. And even if you can, how widespread will that option be?

Valve has some challenges. They have to make sure the SteamOS platform has feature parity with consoles. That means video streaming and music. It means actively courting games to be on Linux and making sure drivers are up to the job. It even means working on better APIs like Vulkan to ensure a cleaner development-to-market process.

But they have advantages as well. The Steam Machine market is a market, not a single offering from one company. Consumers can decide when to upgrade, how much to spend, and so on. They’re delivering competition and choice to consumers and betting the consumers will make the right choices for them.

At the end of the day, Valve is working to expand their market. They are doing that to make more money, but they seem to be doing it in a way that is smart enough to mean more money for others too. And that’s what good capitalism should focus on.

Debian’s init Options

The Debian Project will choose a new default init system for its next major release (codename Jessie). The debate details (Debian Wiki: Debates: initsystem) include the following proposals:

  1. sysvinit (status quo)
  2. systemd
  3. upstart
  4. openrc
  5. One of the above for Linux, other(s) on non-Linux
  6. Multiple on Linux, at least one for every other kernel

The chief goal in switching? Bring modern boot functionality (speed and lower resource use). Others include lowering the bar for packaging and maintenance, and taking advantage of newer kernel features.

The matter of choosing an init system mainly deals with the amount of work and amount of benefit available. Unfortunately, some aspects of this debate must focus on other things.

The main contenders, systemd and upstart, both have at least one strike against them:

  • systemd looks technologically superior, but that superiority makes it a non-option for at least some non-Linux kernels (owing to using Linux-specific features), and support for other kernels would require much effort. It also takes a different approach to being pid 1, namely rolling in some functionality that has long been outside of init‘s domain.
  • upstart can be supported more readily, but similar if slightly less effort would be required for non-Linux. Worse, Ubuntu’s stewardship of upstart hampers it with the Canonical Contributor License Agreement problem.

A Contributor License Agreement basically states that by signing it, you grant rights of your contributions to the project maintainer. But the Canonical CLA goes a step beyond, in claiming for Canonical the right to relicense the contributions in a non-free manner.

In the Free/Open Source world that makes it as attractive as poison ivy. Also important, some who contribute as part of their work may actively be barred from participation. A company that sees benefit in open source will probably see hostility in their employee’s work being tied into a CLA of this sort (or any sort).

It all adds up to one difficult decision. The fact that both major contenders do not reduce Debian’s workload means the decision will boil down to technical merits. That makes systemd more likely.

What of non-Linux, then? openrc or sticking with sysvinit both seem plausible. Debian likely will not abandon their work with other kernels, so they will likely bite their tongues. Debian will put up with the extra work of dual systems for now. That will also mean that their Linux decision will remain a technical hybrid for the time being.

But not forever. Post-Jessie, I expect Debian will re-evaluate and hopefully find a more useful option to shed some of the extra weight they will take on in the short-term, whether that means configuration conversion tools, or something else.

The main reason that upstart seems unlikely, Ubuntu and Canonical never took the time to lead the way on non-Linux and while some Debian packages might have easier times adopting upstart configurations, the feature set of systemd seems to be a bit more powerful.

Canonical’s Place

Canonical: the main commercial force behind the Ubuntu Linux Operating System. Lately some bad blood flowed in the greater free/open source community over decisions and directions in Ubuntu; these decisions fell from the sky like bombs, in that the larger community received no communiques indicating the missions or their timing.

Mir fell out of the clear blue just recently. The project aims to replace the X Window System, one of the longest running projects and biggest workhorses of desktop UNIX systems. The age and legacy support of X mean some of its design blocks progress for free desktops and other free computing devices.

But Wayland already staked their claim to be the replacement. A lot of positive effort continues to go into Wayland and supporting it on existing Linux applications. The existing contributors wear boots with the mud of X encrusted on them. The community knows the project by name, much like the Compiz put X compositing on the tip of our tongues some years back.

This development comes as one of several incidents in which Canonical failed to work with the community, or at least clue the community into its plans. The inclusion of Ubuntu Shopping Lens, searching commercial websites directly from Ubuntu raised the question of Ubuntu’s commitment to privacy. Ubuntu One, a cloud storage service among other features, raised questions about Ubuntu’s approach to markets more generally. Other projects like Unity and Upstart (the main Ubuntu UI and a replacement initialization system, respectively) made the community feel like Ubuntu decided to go it alone on key parts of their system.

Mir’s announcement again raises questions about whether Ubuntu and Canonical want to be part of the community, or a parallel entity. They once again failed to engage with the community, and instead the community finds out about the direction Ubuntu moves after the fact. But maybe Mir will be different.

The best difference to hope for: a driver specification that allows competition. If the next generation of display server for Linux keeps its driver specification short and sweet, avoiding the possibility for the proprietary drivers to become bloated messes that do too much, they truly bless us with their presence.

For too long a performant driver meant a proprietary one. That meant ceding too much control of the system to said driver. In short, it grew into letting lobbyists write the laws. A tainted system. More importantly, it meant X entrenchment. The driver worked for X and only X. Writing a replacement for X would either require being too X-like or relying solely on free drivers (missing out on performance). The latter stands as the current state for Wayland and Mir.

But if Mir (or Wayland, or both) provides new driver models that leave us with a small driver with minimal-yet-performant capability, and the rest of the code can be open, that will place the whole system on much firmer ground. We would face a day where we could write a non-X, non-Mir, non-Wayland system and still be able to fall back on proprietary drivers for their performance. It might also encourage the (partial or complete) opening of the proprietary drivers, with far less code for lawyers to worry over.

At present the prospect remains dim. But as both newcomers continue to mature (assuming that Mir gets the resources needed from Canonical), there will inevitably be compatibility layers between them, and some convergence may occur around the driver space. It remains possible that better free software can come of this. I hope it does.

Canonical ought to lead the larger community, rather than stalk it as prey. That leadership means working with the community, contributing to it where possible, and where the community and Canonical must diverge, they should diverge only to the least possible distance. That would make Mir a fork of Wayland, or maybe Wayland plus some special extensions.

But even if it couldn’t be, the least possible distance would still require some feedback to the Wayland developers. Where and why does their model fail? And why couldn’t those details come out months ago, at least when Mir started? If valid concerns exist, give them voice. As it stands, from my reading on the situation, misunderstandings brought the concerns. That’s lamentable.

We need more companies doing Linux hands-on. Canonical deserves stewardship that grows it and the software community. Times like these allow companies like Canonical to define themselves, and I hope they will learn the lesson and move forward with the community.