all 99 comments

sorted by: hot top controversial new old
[–] 127 points 3 weeks ago
[–] 58 points 3 weeks ago (19 children)

Anyone know why it took so long? Wasn't important?

  • source
  • hideshow 19 child comments
  • [–] 114 points 3 weeks ago (15 children)

    Wine couldn't run 32 bit games without 32 bit libraries. They added experimental support for WoW64 a few years ago and now it's considered stable. There was probably just no rush to make Steam 64 bit if it still needed 32 bit libraries for older games.

  • source
  • parent
  • hideshow 15 child comments
  • [–] 64 points 3 weeks ago (11 children)

    Distros have been pushing really hard for this since Ubuntu in 2019, then fedora in 2025 because it's very hard to keep maintaining multilib and i686 for basically only wine and steam. So with this change we can finally get rid of that baggage.

  • source
  • parent
  • hideshow 11 child comments
  • [–] 48 points 3 weeks ago (6 children)
  • [–] 2 points 3 weeks ago (3 children)

    Yeah, and what happens with users of older hardware (because they can't or don't want to pay for newer software, or because they maintain it as a secondary hardware)? Multilib/32 bit is still important today because of inclusivity and democratisation.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 0 points 3 weeks ago

    Do you have an actual use case for this? Consumer hardware has had 64 bit support for about 20 years now. If anyone's still rocking 32 bit only its probably a specialized situation that already needs a custom solution. I'm really only thinking of retro computing enthusiasts and industrial applications, neither of which necessarily need to be running mainline Fedora.

  • source
  • parent
  • [–] -3 points 3 weeks ago (1 child)

    Then those people can start bearing the cost of maintenance. TANSTAAFL.

  • source
  • parent
  • hideshow 1 child comment
  • Yeah, and most of these people can't because they don't have sufficient resources. Most people who only owns a legacy piece of hardware does that not out of will, but because they can't pay anything better. Now, these people works 8 to 10 hours a day and the time they spend moving from home to work and from work to home is, let's put an intermediate value, 2 to 3 hours. That's 10 to 13 hours out of work and travel. Now take into account they have to do things as cook, clean their house, take care of their children if they have, etc., and after all of that, they only have a few hours of rest, and they're so fucking burned and broken by their routine that they won't have the time or energy to do so. And it's not better when you're unemployed, it's worst.

    Maintaining software, self-hosting and all that, is not for poors, is exclusionary towards them as is elitist and expensive. Not only of money, but of energy, time and computational resources... That with legacy hardware and such a routine nobody can ever have. Don't defend that "just make it yourself bro" because that makes you a fucking asshole. Period.

  • source
  • parent
  • [–] 18 points 3 weeks ago

    The advantage to Steam going 64-bit is that most people can now remove all their 32-bit libraries.

    Previously you needed 32-bit libraries for most of the actual games you ran through Steam, so it didn't really matter if Steam used them too.

  • source
  • parent
  • [–] 3 points 3 weeks ago

    Back when the very first Linux port of Steam was released, there were a couple of Atom CPUs still 32 bit and Valve is relatively slow to change the fundamentals of the Steam client.

    IMO one of be bigger mistakes Valve made and also the reason why I switched to the Steam Flatpak early.

  • source
  • parent
  • [–] 104 points 3 weeks ago (1 child)

    Linux gaming is on fire 🔥, 2026 ♥️

  • source
  • hideshow 1 child comment
  • [–] 40 points 3 weeks ago (12 children)

    Kinda funny to think that I won't be living through any more migrations to the next power of 2. They happened so rapidly at first.

  • source
  • hideshow 12 child comments
  • [–] 35 points 3 weeks ago* (3 children)

    Moore's Law finally caught up with our ability to make rocks calculate for us. It was going to happen eventually, I find it somewhat comforting that hardware has finally plateaued, and will only get incremental changes for a while. It means that the next computer I build, I can expect it to last for multiple decades, rather than just one.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 15 points 3 weeks ago (1 child)

    The thing is though that now build quality is going to matter WAY more. Like you need that laptop chassis built like a tank. Which is harder to find in new devices these days.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 13 points 3 weeks ago

    Yeah, and power supplies and such that aren't limited by silicon but capacitor cycling are going to matter more and be limiting factors. Replaceable batteries and power management in phones, laptops, etc are going to be crucial

  • source
  • parent
  • [–] 7 points 3 weeks ago

    Ohh fear not! Hardware didn't plateau. Our current architectural needs plateaued. We're still doing everything on 2d layers layers in a way that makes things organized. I'm sure they'll shove AI in there and the next gen stuff will be unsupportable chaotic 3D tetris stuff and the memory/bus sizes will be old hat.

  • source
  • parent
  • [–] 13 points 3 weeks ago* (last edited 3 weeks ago) (5 children)

    Each "bit" in the architecture is mainly related to how many different memory positions you can address with a CPU opcode (i.e. an assembly command) that needs to access memory or with a CPU register that holds an memory address (so an 8 bit register can only address 256 memory positions, a 16 bit one 65,538 memory positions, a 32 bit one 4,294,967,296 memory positions and so on) - basically every additional bit in the register size of a CPU that addresses memory roughly doubles the memory that CPU can access and thus use (not considering hacks to go around those limits, such as the Spectrum 128K had).

    Meanwhile Moore's Law predicts that "the number of transistors in an integrated circuit doubles about every two years" which for integrated circuits roughly means that every two years the amount of memory that can be in the same integrated circuit area doubles.

    So if Moore's Law kept working, each architecture bit roughly gives you two more years until the availability of memory catches up- This means that the transition from 32-bit to 64-bit architectures per Moore's Law gave us 64 years until we have to move to an architecture with more bits because memory available is so big that CPUs are unable to use so much memory.

    Were we are now, 64 bits is enough to address 8 Exabytes of memory.

    That said, extrapolating from the current trend in growth of memory in PCs, we will reach the point when we will start hitting the constraints of that in ... NEVER - thanks to the AI bubble the newer PCs are coming out with the same or less memory than the previous generation, so the trend of available memory is not upwards but downwards.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 3 weeks ago (4 children)

    the only good thing to come out of the ai bubble

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 2 weeks ago (3 children)
  • [–] 2 points 2 weeks ago (2 children)

    same or less memory than the previous generation

    means less room for bloatware

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 2 weeks ago (1 child)

    The apps are going to be vibecoded and consume even more memory.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 2 weeks ago

    Not while all of the memory is going to the datacenters. Commercial applications may be built on some Raizen 407000, which sucks, but hobbyist projects will all be made on regular computer, during the shortage. Unfortunately, Linux isn't really a hobbyist project... Was thinking NetBSD.

  • source
  • parent
  • [–] 1 point 3 weeks ago

    Fwiw, CPUs/GPUs use 128bit wide buses (eg 4060, I think) and wider. So you're kinda there already.

    64-bit here refers to the size of the general purpose registers; but wider (larger) registers are common too in chips that are still referred to as x86_64.

  • source
  • parent
  • [–] 36 points 3 weeks ago (21 children)

    Noob question here, but what’s the benefit of moving an application like Steam to 64bit? I understand for memory intensive applications it allows for more memory usage (it was a big deal when Stellaris made the change) but does Steam often use more than 4 GB of memory?

  • source
  • hideshow 21 child comments
  • [–] 107 points 3 weeks ago (14 children)

    The benefit to/for Steam itself is marginal. The benefit to the entire community is significant, because there's now an entire metric shitload of obsolete 32-bit shit that can be safely deleted and forgotten for 95% of the Linux world and efforts can be focused on things that actually matter in the 64-bit world. The entire 32-bit ecosystem of libraries and system layers still had to be maintained and supported basically only for Steam's sake, Steam was the only thing still using them for the vast majority of people. It's not that Steam needs 64-bit, it's that 64-bit is the standard now and has been for a long time, and Steam was the only thing that had no 64-bit version.

    It's kind of like cutting loose the anchor that the community has been dragging around everywhere for years for no purpose. It was a totally unnecessary effort that just caused suffering and added no value.

  • source
  • parent
  • hideshow 14 child comments
  • [–] 26 points 3 weeks ago (13 children)

    I can probably disable multilib repo soon, which is nice.

  • source
  • parent
  • hideshow 13 child comments
  • [–] 7 points 3 weeks ago (12 children)

    I just installed from Flatpak for years now. No multilib headache.

  • source
  • parent
  • hideshow 12 child comments
  • [–] 5 points 3 weeks ago (11 children)

    Unfortunately, SteamVR with Flatpak is busted unless you use something like WiVRn. If you try to use something like the Steam Link app on an Android-based VR headset to do direct SteamVR streaming, it won't work on the Flatpak because of permissions.

    Source: Been wishing I could use SteamVR on my gaming PC for a while without a third party solution.

  • source
  • parent
  • hideshow 11 child comments
  • [–] 2 points 3 weeks ago (3 children)

    Did you try and app like Flatseal for customising Flatpak permissions?

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 3 weeks ago (2 children)

    Yeah that fixes some things, but there is a sudo command it tries to run that has some sort of pathing issue in the Flatpak version.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 3 weeks ago (6 children)

    Can you not just allow those permissions?

  • source
  • parent
  • hideshow 6 child comments
  • [–] 1 point 3 weeks ago (5 children)

    It's deeper than that. It tries to run a function with sudi that fails every time, but the prompt for a password never appears.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 3 weeks ago (4 children)

    Ah, I see. So it must need some library installed via Flatpak as well, that provides that prompt, right?

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 3 weeks ago* (last edited 2 weeks ago) (3 children)

    Probably. It tries to run a .sh script on first launch as sudo, but fails. Even if you run it manually, it still didn't seem to fix it. There is a bug report for it somewhere that's been open for 2 years. Valve officially only supports the package version of Steam for SteamVR, not Flatpak, so it's unlikely to get fixed.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 21 points 3 weeks ago

    One of the benefits is only needing to have 64 bit libraries. With this change most people can drop their 32 bit stuff.

    Bits are literally "binary digits". So more bits means bigger numbers. The reason you get more memory, is because when the code says "put this data in memory spot (number bigger than 32 bits)" .. you cant with only 32 bits. How do you represent that number.

    Imagine that you want to put something in memory spot 150, but you only have 2 digits. You cant. Bumping it up to 4 digits, you can say "put this data in memory address 0150" and its fine. "bigger numbers == more addresses == more places to put stuff"

    So anywhere you need a number bigger than 32 bit represents, you can either just use a 64 bit number, or do a bunch of shenanigans. Those shenanigans require extra calculations inevitably. https://en.wikipedia.org/wiki/2,147,483,647 If youve ever seen this number before, it's probably because of a 32 bit limitation. It shows up all sorts of weird ways.

    Bigger numbers here aren't about taking up more space, just representing literally bigger numbers. "9999" only takes up 2x as much "space" as "99" but it repesents a number ~100x bigger.

    Sorry, I'm tired and rambling.

  • source
  • parent
  • [–] 4 points 3 weeks ago (3 children)

    One of the reasons Steam held out for so long was that a lot of the games they host are 32-bit only. Games are built by a company, many of which have gone belly-up, so rebuilding the game from scratch is impossible. Making Steam 32 bit even though it could be 64 bit is a really effective way to guarantee a large chunk of their legacy products will still run. In a lot of ways, because of the nature of the gaming industry, Steam has it worse than most package managers/app stores.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 9 points 3 weeks ago (1 child)

    I'm not sure as that's about Steam the client though not on Proton thus Wine, which I bet will keep on supporting 32bit apps.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 3 weeks ago

    Remember that the portion of Steam users that use Proton regularly is less than 10%, if you include Deck users. That number is rising and is probably a major factor in the decision to switch, but it's still a minority.

  • source
  • parent
  • [–] 28 points 3 weeks ago (3 children)

    Does anyone know what the average delay is between a beta update and the update landing in stable?

  • source
  • hideshow 3 child comments
  • [–] 22 points 3 weeks ago (1 child)

    It really depends on how many bugs their are. But I'd expect it in a couple of months at the most

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 3 weeks ago

    This has been in beta-beta for a year at least. I tried using it last year I think.
    It's also still not quite complete. The reaper binary (which to be fair is a tiny piece of software) still depends on 32bit libraries, so on a 64bit only system you currenrly can't actually start any games, only use the launcher.
    With some trickery this can be circumvented, I am using steam natively without 32bit libraries, but it's definitely not nearly done yet.

  • source
  • parent
  • [–] 23 points 3 weeks ago (5 children)

    Does this mean I won't need the multilib Arch repo anymore? Or at-least after it has matured enough to not need 32bit stuff?

  • source
  • hideshow 5 child comments
  • [–] 9 points 3 weeks ago (2 children)

    I'm also on Arch btw, btw. 😆

    This was basically one of the big reasons I opted to install Steam via Flatpak.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 5 points 3 weeks ago (1 child)

    I tend to avoid Flatpaks if the package is directly available in official Repos or even in an unofficial repo. If I have to download it from the AUR then I will check if a Flatpak version exists or not and install it from there.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 23 points 3 weeks ago (3 children)

    are we now supposed to update or uninstall and reinstall?

  • source
  • hideshow 3 child comments
  • [–] 28 points 3 weeks ago (3 children)

    Great news, no more headache with 32bit libraries. Now we need wayland support to get rid of xwayland and anything xorg as well.

  • source
  • hideshow 3 child comments
  • [–] 3 points 2 weeks ago (1 child)

    I assume we'll still need the 32 bit libraries to play 32 bit games, which at this point is probably just older games that will never be updated. I guess it depends on what you like to play, but I'll be stuck with them for some time yet.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 2 weeks ago

    I always thought that whatever games need is containerized in proton, but that for windows games. For old linux games i think repackaging them as flatpaks is an option.

  • source
  • parent
  • [–] 11 points 3 weeks ago*

    That's actually pretty impactful. Nice

  • source
  • [–] 17 points 3 weeks ago (1 child)
  • [+] 12 points 3 weeks ago (3 children)
  • [–] 6 points 3 weeks ago (2 children)

    And running inside the same steam runtime used for games. Oh well.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 21 points 3 weeks ago
    [–] 6 points 3 weeks ago

    Hopefully one day the steam library and store will be separate.

  • source
  • [–] 5 points 3 weeks ago (1 child)
  • [–] 9 points 3 weeks ago (5 children)

    wrong, instead it is still 32 bit, but now it is running under steam's own runtimw which has 32bit libs, just like the games

  • source
  • hideshow 5 child comments
  • [–] 9 points 3 weeks ago (4 children)

    wrong, instead it is still 32 bit

    With this first part of your sentence you are directly contradicting the words in the primary source, so do you have good evidence for this?

    For reference here's the relevant part from the primary source:

    Linux

    • The Steam client is now a 64bit application.
    • The Steam client now runs inside a Steam Runtime container.
      • This will help the Steam client provide a more consistent experience across multiple distributions. This is the same technology used by Steam games.
  • source
  • parent
  • hideshow 4 child comments
  • [–] 6 points 3 weeks ago (1 child)
  • [–] 4 points 3 weeks ago* (last edited 3 weeks ago)

    Thank you. That's interesting and actually supports the assertion that some executables are still built in 32bit, this reaper thing in particular.

    It also lead me to a requirements list explicitly containing the following:

    Architectures:

    • x86_64 systems must support multilib and have both 32-bit (x86, i386, lib32) and 64-bit (x86_64, amd64) versions of required libraries and graphics drivers installed
    • 64-bit-only x86_64 systems are not supported
    • 32-bit-only x86 systems are not supported

    It's here: https://github.com/ValveSoftware/steam-for-linux/blob/master/README.beta.md

    Found via this comment from what seems like a valve employee: https://github.com/ValveSoftware/steam-for-linux/issues/13015#issuecomment-6204720307

  • source
  • parent
  • [–] 3 points 3 weeks ago (1 child)

    I feel like it's kinda the same thing, their application is now 64 bit in a sense that they don't need 32-bit dependencies, not in a sense that they changed anything in the real application

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 3 weeks ago

    That sounds a little too made up. An application being a 64bit application ordinarily means that it uses 64bit executables and libraries.

    Additionally Valve have been on this journey to drop 32bit for a while. Last November they published a 64bit beta for Windows, in December they switched the Windows version to 64bit, in January they dropped support for 32bit Windows.

    At the moment I have no reason to believe they didn't compile the Linux version for 64bit architectures as well now. That's why I asked if furry toaster had any evidence. Maybe there is something to change my mind.

  • source
  • parent
  • [–] 5 points 2 weeks ago

    Don't care. When will it obey window manager hints like every well mannered software does?

  • source
  • [–] -1 points 3 weeks ago (4 children)

    What does this mean for GOG games? I have some old games that I'm running through Lutris.

  • source
  • hideshow 4 child comments
  • [–] 21 points 3 weeks ago (3 children)

    Well given that GOG games have nothing to do with Steam I'd imagine it means nothing for them.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 5 points 3 weeks ago (2 children)

    I meant in the sense that will distros as a whole drop support for games that use 32bit packages? Will proton and wine stop supporting 32bit games, etc etc

    My question was predicated upon the fact that Steam is a market mover, and what are the downstream ramifications of this transition.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 3 weeks ago

    If your game currently runs on your hardware with your distro then it is very unlikely it will stop running unless you change your handware or your software (like a major update). Can I promise 32 bit will be supported forever? No. But it's certainly not going to suddenly stop working because of this.

  • source
  • parent