This month Canonical announced it would not include 32-bit packages in future versions of Ubuntu — and that led Valve to announced that the popular Steam game client would drop support for Ubuntu moving forward.
The move wasn’t out of spite — Valve says that not only does Steam itself rely on a number of 32-bit binaries, but so do thousands of games designed to work with Steam (as well as thousand of non-Steam titles).
Due to pushback from the community, Canonical backtracked a bit and announced plans to include some 32-bit binaries in Ubuntu 19:10 and Ubuntu 20.04 LTS. So it’s unsurprising that Valve says Steam will work on those upcoming operating systems. But as for the future of Steam on Linux? That’s a little less clear.
In a nutshell, Valve says it already includes many of the dependencies that 32-bit games need in order to run properly. But it relies on the host operating system for some things including 32-bit glibc, Mesa and NVIDIA graphics drivers, and more.
While it could be possible to put some of those things into a container so that they’d work even if they aren’t officially supported by the operating system, Valve had originally designed to drop support for Ubuntu when it became clear that it wouldn’t be possible to find workaround by the time Ubuntu 19.10 is scheduled to launch in October.
But now that Canonical seems set to offer at least 5-6 years of support for key 32-bit binaries, (Ubuntu 20.04 LTS, which is set to launch next April, will be a long-term support release), it make sense for Valve to continue supporting the operating system.
That said, in Valve’s statement, the company makes it pretty clear that it’s exploring other options “that offer a great gaming desktop experience such as Arch Linux, Manjaro, Pop!_OS” and Fedora. I wouldn’t be surprised if one of those other Linux distributions became a recommended OS in the future.
My guess is 1% or less of users play those games and a few more percent bought the games on sale and have zero playing time.
The question is not about games, though, the question is will Ubuntu continue to bear non-zero costs of maintaining multilib for everyone Ubuntu-based?
It’s a bit of game of chicken and Valve happened to have a large enough stake to seemingly make Ubuntu cave in.
Ubuntu will definitely try to wiggle out again next year though.
Why can’t the games be updated to work on 64-bit?
You’d be amazed at just how often it turns out there’s nobody left with both the permission and ability/time/motivation to update, let alone rewrite, a proprietary game.
And sometimes the source code just gets lost.
I don’t even think blizzard has the OG World of Warcraft code.
Source code archival is a relatively recent concept for games.
You want to track down developers of a few thousand games and ask them to update software they might have coded years ago and then moved on from?
This issue is more than just about games. Although, it probably should be mentioned…that you wouldn’t be able to open Steam to play those 64 bit games without the 32 bit libraries…Steam requires them to run.
Every single piece of essential software that runs my home and business, most of which are custom(one off) programs…run in 32 bit. I’d like to see Windows just drop 32 bit for a weekend? Every hospital and power plant would shut down? My hospital is still on Windows XP. I have a friend who is a therapist, his office is still on Windows 2000.
I don’t think you’ve thought through exactly how belligerent and irresponsible even commenting about tossing these 32 bit libs is. We’ve been spending the last three days moving our servers over to a different distribution that has zero to do with Canonical/Ubuntu and will never trust them again…that is how serious we take the matter.
I think you need to relax Mike, I do enjoy the “WE” bit heh
Lost or unavailable source, little to no documentation, no devs familiar with the codebase (forgot, dead, preoccupied, retired, sworn off of games), rightholders who can grant the permission to modify hard to track or non-cooperative, antiquated toolchains and many more reasons.
The best case is to reimplement the engine in such a way that it just happens to work seamlessly with the original resource files. Successful projects of this kind are rare and few between, though.
Comments are closed.