In its October 15 Steam Client Beta update (October 16 in Japan), Valve moved the Linux Steam client to a 64-bit build that runs inside a Steam Runtime container. The feature had been offered as an experimental option since March, and it has now been folded into the regular beta. The change is meant to reduce the Steam client's dependence on library environments that differ between Linux distributions, so that it runs more reliably. However, a 64-bit client does not mean 32-bit libraries are no longer needed. To understand the change correctly, you have to distinguish between the libraries needed to run the Steam client itself and those needed to run games.
From the March experimental build to the regular beta
Valve's update notes describe the move to a 64-bit Linux Steam client running inside the Steam Runtime container. The update also fixes an issue in which some users did not see the update screen. Valve explains that by using the same technology already used for games, it becomes easier to ensure consistent behavior across different Linux distributions.
This is not the first time a 64-bit Linux Steam client has appeared. A beta update dated March 19 had already announced 64-bit support and container-based execution as an experimental "SteamRT3" build. At the time it was offered separately from the regular beta client, and users had to enable the experimental build in the settings. The new update moves that experimental implementation into the regular beta. Valve has not announced when it will reach the stable release.
Users had long asked for a 64-bit Linux Steam. On September 30, 2014, a request was posted to Valve's GitHub repository for a 64-bit-only client that would not need 32-bit libraries. In Valve's reply at the time, the company said the Steam client was a 32-bit application and therefore required 32-bit libraries, and that it had no plans to develop a 64-bit version. About 12 years later, the client itself has been moved to 64-bit, but the wish to run Steam in an environment with no 32-bit libraries at all has not been fulfilled.
Containers reduce differences between Linux distributions
The previous Linux Steam client ran by combining the shared libraries of an older Steam Runtime called "scout" with libraries from the host OS. Libraries are bundles of common functionality, such as graphics and basic processing, that multiple programs share. According to Valve's Steam Runtime documentation, the old approach used an environment variable, LD_LIBRARY_PATH, to add Steam's own libraries to the search path.
This mechanism helped support a wide range of Linux environments, but it could not unify every library Steam used at the same version. According to Valve's design comparison document, the old approach took the core library glibc and the graphics drivers from the host OS, and chose between the host and scout for other libraries. As a result, changes in the specification or behavior of host libraries could break older games. Differences in the libraries each distribution adopts and how often they are updated also complicated compatibility.
Even with the same Steam client installed, the combination of libraries actually loaded can vary with the OS and its update status. A game that works on one distribution may then fail on another. For Valve, reproducing bugs meant accounting for environmental differences between operating systems, which increased the development and support burden.
The container approach adopted here uses a Linux feature called namespaces to isolate the execution environment seen by an application from the host OS. By using the common library environment provided by Steam Runtime, it reduces the parts that depend on distribution-specific configurations. Valve already uses this technology for the game execution environment, and this update extends it to the Steam client itself. That makes the combination of libraries easier to manage across different Linux environments and is expected to improve consistency.
However, the Steam client moving to SteamRT3 does not mean all games will use the same generation of Steam Runtime. Steam Runtime comes in several generations, and the runtime used by games and by Proton, the Windows game compatibility layer, differs for each. What changed here is mainly how the Steam client itself runs. Executables of games already distributed are not suddenly becoming 64-bit, and the runtime environments of all games are not being replaced.
Why 32-bit libraries are still needed
Although the Steam client itself is now 64-bit, Valve continues to require 32-bit library support. The beta's system requirements call for a "multilib" setup on x86_64, with both 32-bit and 64-bit libraries installed, and state explicitly that both versions of the graphics drivers must be installed as well as the core libraries. An x86_64 environment made up only of 64-bit libraries is currently unsupported.
In other words, under Valve's policy, making the Steam client 64-bit and maintaining an environment that can run 32-bit games are compatible goals. Based on the update notes, the beta's requirements as of October 17, and an explanation by a Valve developer on GitHub, the changes can be summarized as follows.
| Target | Change or condition kept | What it means for users |
|---|---|---|
| Steam client itself | Moved to a 64-bit application | The client's executable format changes |
| Client's common runtime environment | Runs inside a Steam Runtime container | Reduces problems caused by library differences between OSes |
| Host OS libraries and graphics drivers | Still requires both 32-bit and 64-bit versions where needed | You cannot remove all 32-bit libraries |
| Existing 32-bit native Linux games | Still need a 32-bit graphics environment | Updating Steam itself does not make games 64-bit |
This table summarizes the client's changes and compatibility requirements; it does not compare performance or the number of required packages. Steam itself running as a 64-bit application is a separate matter from the capabilities the OS must provide to run games. Also, because the Steam Runtime container pulls in graphics drivers from the host OS, GPU-related dependencies are not entirely self-contained within the container.
In a GitHub reply on October 16 (Japan time), Valve developer lostgoat explained that a set of 32-bit graphics drivers is needed to run 32-bit games properly. He also pointed out that, even though Proton supports WoW64, there are many 32-bit native Linux games that would stop working on a 64-bit-only host environment. Making the Steam client 64-bit alone cannot preserve compatibility with such games.
WoW64 is a compatibility mechanism for running 32-bit Windows programs in a 64-bit environment; it does not convert 32-bit native Linux applications to 64-bit. Even if Windows games can run through Proton, that is not the same as being able to run existing Linux games as they are. WoW64 support therefore does not make all 32-bit libraries for Linux unnecessary. Lostgoat also explained that completely eliminating 32-bit libraries from the host OS is not a goal of this change; the aim is to reduce the kinds of libraries required.
The 32-bit compatibility issue that dates back to Ubuntu's 2019 controversy
How far to maintain 32-bit libraries on Linux cannot be settled by the Steam client alone. In 2019, Canonical, the developer of Ubuntu, faced strong backlash from gaming-related communities over its policy on providing 32-bit packages. According to the statement the company issued on June 24, 2019, after hearing from gamers, Ubuntu Studio, and the WINE community, it changed course and decided to select and build the necessary 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS.
In the statement, Canonical said it would work with the community to identify the packages needed to run older software, and that missing ones could be added even after release. It also outlined a longer-term idea of using container technology so that older applications could run on newer Ubuntu environments. The need to keep compatibility with 32-bit applications, and the burden of continuing to maintain little-used older libraries, were recognized as problems even then.
The latest change to Steam for Linux can be seen as one effort to address this long-standing issue. While moving the client itself to 64-bit, the plan is to keep compatibility with older games and shift management of common libraries to the Steam Runtime side. If the libraries required on the host OS can be reduced, it may become easier for Linux distribution developers to narrow down the dependencies they have to maintain. However, this change alone does not let distributions drop 32-bit support; dependencies will have to be sorted out gradually while ensuring compatibility with existing games.
OS and graphics requirements to check before trying the beta
The system requirements Valve has published for the new beta call for glibc 2.31 or later and Linux kernel 5.6 or later. It also requires that user namespaces and mount namespaces can be created without special privileges. This is needed to run the Steam Runtime container, and meeting the kernel version requirement is not necessarily enough, since some distributions' security settings may restrict namespace creation.
On the desktop side, a D-Bus session bus and an X11 server are required. X11 can be a regular X11 session or Xwayland, which runs X11 applications in a Wayland environment. This 64-bit change therefore does not mean the Steam client now supports Wayland natively. PulseAudio or pipewire-pulse is needed for audio, and OpenGL and Vulkan drivers are needed for graphics. The requirement to provide both 32-bit and 64-bit versions of libraries and graphics drivers also remains.
What Valve emphasizes in this update is consistent behavior across Linux distributions. The update notes include no performance measurements, such as percentage improvements in Steam's startup time or in game frame rates. Moving to 64-bit and to containers changes how the runtime environment is managed, but there is no basis for concluding that this alone makes games run faster.
The key questions going forward are when the new execution method will reach the stable release and how well compatibility with existing games can be maintained. Anyone trying the beta should check not only that the Steam client starts properly, but also that their older 32-bit games run without problems, including graphics. If Valve can reduce the libraries it requires of the host OS while maintaining that compatibility, Linux users should be able to keep enjoying older games while finding it easier to move to newer distributions.