We do often include affiliate links to earn us some pennies. See more here.

As an update to the situation around Canonical planning to drop 32bit support (and Valve saying bye-bye to Ubuntu 19.10+ support), apparently they're not. Instead, the 32bit libraries will be frozen. Are you confused yet? I sure am.

Canonical's Steve Langasek has attempted to clarify the situation. Here's what they said:

I’m sorry that we’ve given anyone the impression that we are “dropping support for i386 applications”. That’s simply not the case. What we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions. But there is every intention to ensure that there is a clear story for how i386 applications (including games) can be run on versions of Ubuntu later than 19.10.

That's at least a little better, isn't it? They also said a little further:

[…] since the vast majority of i386-only software is also legacy (closed-source, will never be rebuilt), it also does not generally benefit from newer libraries […]

There's a pretty big difference from not being "included as an architecture", to having them available but frozen and still possible to use, isn't there? It's confusing, since that's not how it was originally explained. This is something that should have been said very clearly from the start.

Perhaps this might not be the epic disaster many people (myself included) thought it might turn out to be. We still have to wait and see how exactly they implement all this, and how it will affect gaming.

There's still going to be confusion and issues though, like upgrading drivers. Touching on that, Langasek said:

32-bit mesa will be available in the Ubuntu 18.04 repository. Note that mesa already gets updates in 18.04 which track the versions from later Ubuntu releases, as part of hardware enablement. If incompatibilities are introduced beyond 20.04 (which is the cutoff for hardware enablement backports for 18.04), we will need to address them on a case-by-case basis.

So it sounds like you're still going to be stuck in some ways. Seems like the proposal is still no good for Wine either (and so Steam Play too).

Article taken from GamingOnLinux.com.
Tags: Distro News, Misc
29 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
123 comments
Page: «8/13»
  Go to:

Nevertheless Jun 24, 2019
Quoting: gurv
Quoting: abelthorneThey said don't want Arch nor Debian.
Source?
They did say they're fed up with Debian tooling but they've not stated they don't want Debian itself.

In my opinion:
  • OpenSuse: tumbleweed is a rolling distro and you don't want that for mainstream. Leap is only supported for 18 months that's way too short

  • Arch based distro: come on, be serious, we're talking mainstream here

  • Clear Linux: nope, rolling and controlled by a company that could shut it down without warning

  • Centos or derived distro: with'ppas', why not. Still controlled by Redhat but Redhat has a good track record unlike Canonical. I still doubt Valve would want to be at the mercy of a company though

  • Debian: most logical choice. Stable and with a really good track record, not vendor-controlled. Main problem is indeed some tooling is really showing its age. Apt was awesome back in the days but it's lackluster nowadays. Maybe Valve can contribute improvements?

  • Ubuntu: Canonical has showed once again they can't be trusted. Going with a derived distro (like PopOs) would still be vulnerable to Canonical nonsense


I repeat myself.. I think they should aim to officially support the Flathub Steam flatpak on at least a set of distros, or provide one themselves. It runs 32bit games on pure 64bit distros without problems.


Last edited by Nevertheless on 24 June 2019 at 12:52 am UTC
Shmerl Jun 24, 2019
Quoting: chancho_zombiecome on Debian?? haven't tried it recently but does it still use a ncurses installer?? sorry but it's not user friendly

Debian has graphical installer for years already.
Shmerl Jun 24, 2019
Quoting: x_wing
Quoting: Shmerl2. Come up with solution to run 32-bit programs, using 64-bit libraries with good performance, no 32-bit libs involved at all.

That's not a solution for graphic intensive applications, and probably every library in your system because in order to map a 32 bit library into the 64 bit version you will have to start a new process that handles the library calls through an IPC with a big impact in the performance.

Using processor emulation like with Qemu would be indeed too much of performance hit. But hardware gets better, solutions get better and etc. Eventually this might work with acceptable performance. 32-bit games will remain old, so their level of performance requirements will be easier and easier to crunch. But not today, and besides no one implemented that yet.


Last edited by Shmerl on 24 June 2019 at 12:49 am UTC
Luke_Nukem Jun 24, 2019
I just purged all *386 libs from my install, including Steam. Then installed Steam via flatpak...

No. Issues. At. All.

But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?
x_wing Jun 24, 2019
Quoting: Shmerl
Quoting: x_wing
Quoting: Shmerl2. Come up with solution to run 32-bit programs, using 64-bit libraries with good performance, no 32-bit libs involved at all.

That's not a solution for graphic intensive applications, and probably every library in your system because in order to map a 32 bit library into the 64 bit version you will have to start a new process that handles the library calls through an IPC with a big impact in the performance.

Using processor emulation like with Qemu would be indeed too much of performance hit. But hardware gets better, solutions get better and etc. Eventually this might work with acceptable performance. 32-bit games will remain old, so their level of performance requirements will be easier and easier to crunch. But not today, and besides no one implemented that yet.

And will never be an option having the retro compability at hardware level. Also, creating such emulation layer stills requires to have the 32 bit libraries to run, so not a solution for the current problem.


Last edited by x_wing on 24 June 2019 at 12:57 am UTC
Nevertheless Jun 24, 2019
Quoting: Luke_NukemI just purged all *386 libs from my install, including Steam. Then installed Steam via flatpak...

No. Issues. At. All.

But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?

True! Though it is possible to install and play GOG games via "Install non Steam game" function in flatpak Steam - even Windows GOG games via Proton. Not the perfect solution, but works!
x_wing Jun 24, 2019
Quoting: Luke_NukemI just purged all *386 libs from my install, including Steam. Then installed Steam via flatpak...

No. Issues. At. All.

But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?

And what about proton games? Do they work without problems?
Nevertheless Jun 24, 2019
Quoting: x_wing
Quoting: Luke_NukemI just purged all *386 libs from my install, including Steam. Then installed Steam via flatpak...

No. Issues. At. All.

But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?

And what about proton games? Do they work without problems?

I have no problems at all.
Shmerl Jun 24, 2019
Quoting: x_wingAnd will never be an option having the retro compability at hardware level. Also, creating such emulation layer stills requires to have the 32 bit libraries to run, so not a solution for the current problem.

32-bit libraries can be completely bypassed, by modifying 32-bit code on the fly in some way, into 64-bit one. Something like thunking idea: https://en.wikipedia.org/wiki/Thunk

Not sure how well that would work, but hard to say until someone tries.


Last edited by Shmerl on 24 June 2019 at 1:13 am UTC
x_wing Jun 24, 2019
Quoting: Shmerl
Quoting: x_wingAnd will never be an option having the retro compability at hardware level. Also, creating such emulation layer stills requires to have the 32 bit libraries to run, so not a solution for the current problem.

32-bit libraries can be completely bypassed, by modifying 32-bit code on the fly in some way, into 64-bit one. Something like thunking idea: https://en.wikipedia.org/wiki/Thunk

Not sure how well that would work, but hard to say until someone tries.

But what if you have a code that plays around with pointer size values? Is a call for disaster that. Also, you have to support all the code required to translate your 32 bit app to 64 bit just to avoid building the required deps in 32 bits. Having the support at hardware level and libraries that can be compiled for 32 bit is a no brainer decision.

In short, all the suggested workarounds are by far more expensive than simply compiling the base deps for x86.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.