Originally published at: https://boingboing.net/2019/06/25/valve-killing-steam-support-fo.html
…
That sucks. But the fact is the game industry was really slow to move to to 64 bit support so it makes sense why this would happen. Its honestly way to early for any major OS TO entirely drop x86 support.
And here I was all ready to be pissed off at Valve, when it turns out it’s Canonical that’s the problem.
They clarified that they’re just going to stop updating the 32-bit libraries, but they’ll still be included, which buys some time at least.
Ubuntu killing Steam support for some users.
This thread seems to be leaning toward support for Valve over Canonical. This is… misplaced. 32 bit libraries on Linux have been on their way out for a long time.
If you use the nvidia-supplied graphics drivers (not the ubuntu / debian tree dpkg versions) you can’t even run steam as they don’t include 32 bit drivers anymore, unless you add the entire i386 subsystems in to allow the dependencies for the 32 bit packages to resolve.
This is Steam not moving with the times, not Ubuntu being dicks.
Steam cant “move with the times” without ditching a huge chunk of thier library. Thats a pretty serious problem.
Steam itself is a 32 bit application. It doesn’t run if you don’t have 32 bit GFX drivers installed. That is Valve being behind the times. Even if a game is totally 64 bit (Which for more modern titles they will be, for the most part) you need a chunk of the 32 bit system to launch the fucker, which is plain wrong.
It’s unreasonable to assume 32 bit libraries were going to live forever and unreasonable to assume indefinite support for an obsolete ecosystem. Even if moving to a different distro is an option I suspect it won’t be long before they all follow suit.
If Proton can run windows-only games I don’t see why they can’t put in a 32 bit compatibility mode (a la dosbox) into Steam itself. Anything running 32 bits is going to be older and not suffer from increase emulation overhead.
This has been an issue for a long time and it smells like Valve trying to cover for not wanting to do the dev work.
Looks like the crisis has been averted.
Honestly, that pisses me off. You update software to accommodate changes in the OS, you don’t change the OS to accommodate truculent application developers. That’s how windows’s 16/32bit systems go all kinds of fucked up.
I’m scanning the executables in my Steam library, but so far I’m turning up only a few 64-bit executables. Most of them are VR games (so Unity or Unreal engines), with Fallout 4 and Skyrim Special Edition being other exceptions. But Skyrim and Dragon Age II are some of the “older” games you think won’t suffer from being emulated… Even newer games like Cuphead, Bridge Constructor, Antichamber, Secret of Mana (PC), and Secrets of Grindea are 32-bit.
The problem is the userspace side of your graphics drivers. Unfortunately for anyone sane, modern graphics drivers essentially run the most complex parts inside a library linked into each app/game at run time. This basically means that however old your game binary is, when you run it you have to load some late-model version of the NVidia, ATI, Intel etc. GL drivers and hope they’re binary compatible with the version the game shipped with many years ago.
These drivers need to be tightly matched to the kernel side of the driver and your actual video hardware, so just including a few relatively recent GL libraries (and note they’re copyrighted) doesn’t cut it: it has to actually be the 32-bit version of the 64-bit library you have installed.
This works fine as long as the distribution is keeping this all up to date (and for proprietary drivers, the vendor keeps providing 32 bit driver libs). However, it really wouldn’t work for Valve to just throw in a few 32 bit graphics libraries and hope it matches.
What’s actually needed here would be to either develop some kind of split-mode userspace which allows 32-bit apps to link against 64-bit libraries, or (probably more sane), an entire GL translation layer which provides a consistent ABI (binary interface) to the game and then redirects rendering through the system’s installed graphics drivers.
Either one of these projects would be pretty major undertakings, closer to the “write wine from scratch” level than just keeping some library packages up to date. Especially given that so far, the chosen Linux method for 32-bit support is to just install 32-bit libraries, like everyone has done until now.
Fundamentally, the way graphics drivers work is nuts, but that’s where we are.
32bit-64bit linker. No thank you. The GL (Or probably vulkan now?) interface with a sensible interface was more what I was thinking.
This has happened before - the move to 16 bit, the move away from real-mode DOS, blah blah blah. The complete shift over to x64 is due - I don’t think resource should be spent on maintaining obsolete software.
I mean, there is a whole retro-pc scene springing up to play 8086 games, CGA, EGA, DOS, Windows 95, Windows XP - each is different enough from the others that even though on paper they are the same machines they are not. Nominating a machine as 19.04 and not upgrading because old games? I can dig it.
I’ve never really understood the fascination for supporting Ubuntu over standard Debian but lots of software seems to do it (although at least ROS seems to have corrected that).
I think it’s largely due to Debian’s policy of refusing any proprietary software, which makes a lot of hardware manufacturers and closed source software writers a little shy of it.
Just a few days ago, I read from one of the Wine devs:
If they don’t, then I have a suggestion for our packages: use the
Steam runtime. I see a lot of upsides: They’ve already solved this
problem;
https://www.winehq.org/pipermail/wine-devel/2019-June/147898.html
So, I thought Steam would “help” Wine to overcome the problem. Now I wonder what the flaw in that plan was?!
Jokes on them. I moved over to Nintendo Switch. I haven’t bought a steam game in ages because I hate windows and they refuse to support Linux. F**k Gabe Newell.
Given that Steam is also 32-bit on macOS, this bodes ill for Steam’s continued presence on the Mac after Catalina comes out this fall…
Well, I won’t be installing Catalina on my Macs because it too will be dropping 32 bit support. I still like playing DeathSpank, darn it!