Today's Steam Beta Makes The Linux Client A 64-bit App

kac77

2[H]4U
2FA
Joined
Dec 13, 2008
Messages
3,939

Today's Steam Beta Makes The Linux Client A 64-bit App​

Written by Michael Larabel in Valve on 15 October 2026 at 06:08 PM EDT.

Valve just dropped a new Steam client beta and it's a big one for Linux gamers.

Today's Steam client beta for Linux makes the client binary a 64-bit application. At long last! The Steam Linux client is finally a 64-bit application. The Steam Linux client was one of the few remaining holdouts for many Linux enthusiasts/gamers to still be relying on i686 libraries on their system.
 
For those that run 32 bit games, like Black Mesa that uses the 32 bit Source engine, be sure to add PROTON_USE_WOW64=1 %command% to your Steam launch options - Failure to do so may result in instability, or the game not launching at all.
 
Steam (and by extension, some games) has long been the primary reason many desktop users have maintained a multilib install over the past 5 years or so; many beginning or intermediate desktop users have been sticking to solely 64-bit utils by defaults sourced from official repos. I know they've been working on this for quite some time and I'll be pleased to see it merged with the release channel eventually.

The necessity to have 32-bit libraries installed properly even on a 64-bit system has long been one of those factors that made gaming on Linux more complicated. Even prior to the last decade, "beginner" desktop use on Linux had reached a point of relative ease; the less technically aware person who had a relative configure their desktop with a browser, word processor, and other basic utilities had about as easy a time with Linux as they did with Windows. Conversely, the sysadmin, programmer, media creator or other advanced user found Linux viable in most cases and had the knowledge to fix problems themselves or know where to find solutions.. The problem was the intermediate group with gamers specifically a good metric here- those who typically needed higher performance recent hardware, a significant variety of software (some/perhaps most not intended for this OS) and, often specialized tools to be compatible and supported. This, atop requiring knowledge and troubleshooting that differed from what a gamer may have learned to do on Windows, made it a more difficult progression but conversely this is why it became a good metric of Linux's advance towards the "year of the desktop".

While Valve is not the only developer helping to ease this progression, they're by far the largest and most impactful overall. Steam for Linux would only be the start of it and even after the issues of the first Steam Machines (poorly shepherded by large OEMs like Dell or Lenovo uninterestd in the minutia of Valve's intent and work put into the project), Valve has kept a steady focus on sanding down the rough edges and friction points that impede gaming on Linux both directly and indirectly. While some elements just took consistent work (especially when requiring other companies to be willing to contribute, such as getting Nvidia and AMD alike to fix issues with their drivers on Wayland , to convincing Epic to allow Easy AntiCheat to grant devs the chance to support Linux with ease, and more) they had some major force multipliers both technical such as the unified development of Proton and its contribution upstream to WINE and DXVK and otherwise like the Steam (OS, Deck, Machine, Frame) Verified system making Deck and therefore Linux support easily visible raising the desirability and profile of the OS. Where years ago during the Debian/Ubuntu era of SteamOS users had to often either merge a random PPA or research how to acquire and configure 32-bit libraries without borking anything else (I remember reading many users mess up their OS by getting Steam from the 'wrong' place) , as time continued and thenew Arch based iteration made it simpler but still something that needs to be attended.

The requests fo modernize Steam itself into a 64-bit application have been present for ages and this beta, when its finally merged into the release channel, will be the culimination checking a box off a long standing issue of complexity. Much like how Proton outmoded the need for every Linux gamer on Steam to manually install and configure Wine, DXVK / D9VK, and other supporting software to work together, having Steam itself as 64-bit means that for many users there's no need to mess around with multilib configurations for their system at all - it "just works". While I am sure some more niche uses with older games / mods / utilities may still need some manner of 32-bit support, this won't be an issue to complicate the "average" potential Linux gamer's user experience thus smoothing any attempt to switch to Linux. This long term thinking on Valve's part has borne fruit time and time again and when this hits the release channel it would be a great step forward for Linux gaming.
 
Last edited:
Where years ago during the Debian/Ubuntu era of SteamOS users had to often either merge a random PPA or research how to acquire and configure 32-bit libraries without borking anything else (I remember reading many users mess up their OS by getting Steam from the 'wrong' place) , as time continued and thenew Arch based iteration made it simpler but still something that needs to be attended.

While I can't specifically comment on early iterations of SteamOS based on Debian/Ubuntu, I can state that during the same period you definitely did not need to acquire and configure 32 bit libs via some random PPA regarding desktop Ubuntu and most of it's derivatives. In relation to the desktop, Ubuntu LTS has always been the only officially supported platform regarding Steam under Linux, in fact every time I've installed Steam I've done so by downloading the official .deb directly from Valves site and I've never had a problem - I certainly never manually installed 32 bit libs via some random PPA.

Realistically, the only idiot I ever saw mess up their PopOS based Linux install by ignoring very, very verbose warnings telling them exactly what would happen should they proceed and replying with a full and very verbose sentence before the process would complete (resulting in total disaster), was Linus from that ageing channel Linus Tech Tips. Anyone stupid enough to ignore such verbose warnings under the GUI installer (which actually refused to complete the procedure) and then go a step further to totally mess up their install via terminal deserved everything coming for them.
 
While I can't specifically comment on early iterations of SteamOS based on Debian/Ubuntu, I can state that during the same period you definitely did not need to acquire and configure 32 bit libs via some random PPA regarding desktop Ubuntu and most of it's derivatives. In relation to the desktop, Ubuntu LTS has always been the only officially supported platform regarding Steam under Linux, in fact every time I've installed Steam I've done so by downloading the official .deb directly from Valves site and I've never had a problem - I certainly never manually installed 32 bit libs via some random PPA.

Realistically, the only idiot I ever saw mess up their PopOS based Linux install by ignoring very, very verbose warnings telling them exactly what would happen should they proceed and replying with a full and very verbose sentence before the process would complete (resulting in total disaster), was Linus from that ageing channel Linus Tech Tips. Anyone stupid enough to ignore such verbose warnings under the GUI installer (which actually refused to complete the procedure) and then go a step further to totally mess up their install via terminal deserved everything coming for them.
I'm not sure if we're talking about the same era, but I can recall talking to enough people who were used to doing things like adding a new PPA to get up to date Nvidia drivers, certain codecs for legal reasons, or some Wine / Cedega version, that they were conditioned to think that was the way to go about it for Steam to avoid problems. I can't remember if it was that they got the Steam package from the default distro supplied repo, some additonal PPA, some sort of Flatpak/Snap/AppImage or "app store" listing etc.. but when they pulled the "wrong" one (or worse, uninstalled when it didn't work) it could mess up dependencies and otherwise foul up your system.

While paying attention to the packages affected and other parameters listed could prevent the worst of it, there were always some users who were new to gaming on Linux and/or got too comfortable pasting random commands from forums when troubleshooting without really understanding their function. This became less of an issue as time went on and was near nearly entirely gone by the time Valve moved to Arch, but I can vaguely remember helping a few people who ended up with issues after giving Linux gaming a try yet didn't really follow the instructions carefully or pay enough attention to what Synaptic and/or Steam was doing or asking. While some of the issues were definitely user error or lack of familiarity with the OS, the additional complexity of having to deal with both the default 64-bit and 32-bit libs for Steam and their associations could add a layer of that many new players were not familiar with coming from Windows
 
Last edited:
Surprising that it took this long, considering how many distributions are moving away from their 32bit compatibility libraries.

I mean, the steam client itself isn't a heavy memory user (or at least shouldn't be) so maybe they just never had a good enough reason to refactor the code until now.

It makes me wonder how the Wine base supporting Proton works for 32bit Windows titles if the 32bit libraries are missing on the host system though.
 
Surprising that it took this long, considering how many distributions are moving away from their 32bit compatibility libraries.

I mean, the steam client itself isn't a heavy memory user (or at least shouldn't be) so maybe they just never had a good enough reason to refactor the code until now.

It makes me wonder how the Wine base supporting Proton works for 32bit Windows titles if the 32bit libraries are missing on the host system though.

From the Wine page on Arch wiki:
New WoW64". which runs Wine as a 64-bit Linux application in a 64-bit prefix. 32-bit Windows applications are supported via thunking to 64-bit Wine code. This is most similar to WoW64 on Windows.
 
I'm not sure if we're talking about the same era, but I can recall talking to enough people who were used to doing things like adding a new PPA to get up to date Nvidia drivers, certain codecs for legal reasons, or some Wine / Cedega version, that they were conditioned to think that was the way to go about it for Steam to avoid problems. I can't remember if it was that they got the Steam package from the default distro supplied repo, some additonal PPA, some sort of Flatpak/Snap/AppImage or "app store" listing etc.. but when they pulled the "wrong" one (or worse, uninstalled when it didn't work) it could mess up dependencies and otherwise foul up your system.

While paying attention to the packages affected and other parameters listed could prevent the worst of it, there were always some users who were new to gaming on Linux and/or got too comfortable pasting random commands from forums when troubleshooting without really understanding their function. This became less of an issue as time went on and was near nearly entirely gone by the time Valve moved to Arch, but I can vaguely remember helping a few people who ended up with issues after giving Linux gaming a try yet didn't really follow the instructions carefully or pay enough attention to what Synaptic and/or Steam was doing or asking. While some of the issues were definitely user error or lack of familiarity with the OS, the additional complexity of having to deal with both the default 64-bit and 32-bit libs for Steam and their associations could add a layer of that many new players were not familiar with coming from Windows

Ubuntu is the only desktop distro officially supported by Steam, there was no era where you had to add a PPA to install 32bit libs as they've always been supplied with the official .deb as downloaded direct from Valve. As for PPA's to add up to date Nvidia drivers: yes there was a Launchpad PPA that provided up to date drivers for Ubuntu based distro's; I used it for many, many years and never had a single problem running it, these days it's not necessary as Canonical release drivers under their own repo's in a fairly timely manner. Ubuntu have always provided all necessary codecs assuming you ticked the little box on install. Understand, there's nothing wrong with PPA's when used only where needed. A smaller curated repository is far better than the AUR, which isn't curated at all, keeps suffering from malware infections, and something best used as a last resort while staring at PKGBUILD scripts and hoping there's no 'typo's' you missed.

For the record: I also run a CachyOS system, and Arch is still not officially supported by Steam on the desktop.

https://wiki.archlinux.org/title/Steam

Steam for Linux only supports the latest Ubuntu or Ubuntu LTS.[1][2] Thus, do not turn to Valve for support for issues with Steam on Arch Linux.

...

The days, when I hit 4Ghz long enough to run benchmarks, my self proclaimed fastest Intel P4 in all of Costa Rica when I lived there...god those things got HOT!

The Prescott ran so hot that I actually went back to a P4 Northwood @ 3.8Ghz...
 
Last edited:
Back
Top