Don't want to see articles from a certain category? When logged in, go to your User Settings and adjust your feed in the Content Preferences section where you can block tags!
We do often include affiliate links to earn us some pennies. See more here.

Canonical planning to drop 32bit support with Ubuntu 19.10 onwards

By - | Views: 75,055

As you might have heard by now, Canonical has made the decision to drop 32bit support from Ubuntu 19.10 onwards.

Writing on the mailing list, as well as this post on Ubuntu's Community Hub, Canonical gave a reminder that the decision isn't coming without warning. It was proposed last year and it was followed up with another post detailing a final decision to be made in the middle of 2019. So here we are, the decision seems to have been made.

The problem isn't hardware, as likely around 99% of people nowadays have a 64bit capable computer. Going by our own statistics, from what 2,254 users told us only 4 are using a 32bit Linux distribution. The issue then, is mainly software and libraries needed to actually run 32bit applications. This is where it sounds like there's going to be plenty of teething issues, with a number of people not too happy about the decision.

Steam, for example, is one such application along with plenty of 32bit games that will likely never get updated, although Canonical did say they're "in discussions" with Valve about it. There's also GOG, Humble Store and itch.io which all provide a number of direct-download 32bit games, which do not supply the required 32bit libraries to run. It doesn't sound like they have been given any thought (at least they haven't been mentioned).

Another of the major problems being Wine, with a discussion now happening on their mailing list. The discussion doesn't seem to be too positive, with developer Henri Verbeet even saying "I think not building packages for Ubuntu 19.10 would be the only practical option.", although Andrew Eikum's idea of using the Steam Runtime could be an interesting way around it.

What are your thoughts?

Article taken from GamingOnLinux.com.
Tags: Distro News, Misc
21 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.
164 comments
Page: «16/17»
  Go to:

Eike Jun 23, 2019
View PC info
  • Supporter Plus
Quoting: TheSyldatI mean will those things changing really break much of anything in how those libraries are functionning ?

That's not a troll but a real honest question here . Them freezing up those libraires in their current state would really break shit ?

I had the impression that the x86 libs must match the amd64 ones, so freezing the former would freeze the later - and thus your graphics driver. But I'm not sure either.
elmapul Jun 23, 2019
Quoting: slaapliedje
Quoting: elmapul" The issue then, is mainly software and libraries needed to actually run 32bit applications. This is where it sounds like there's going to be plenty of teething issues, with a number of people not too happy about the decision.'

in the mean time, you can run windows 1.0 applications on windows 10...
what is the point of the system being open source, if we cant even run the apps we want? where is the freedom on it?

yes i can use other distro, but what if all the major ones does the same (the ones which are base for the rest) i'm not planning to support my self.
windows never looked so good.
Ha, that's a STRONG maybe for running older Windows stuff in Windows 10. I mean I've seen many older applications run better with Wine than in Windows 10.

But the point here is, imagine if Windows 10 dropped 32bit support. I'd guess roughly 80% of things would stop working entirely. In the Windows world 64bit native applications were never that wide spread.

that is why microsoft would never do that, because they have something to lose by doing that, and that thing is $$ and marketshare.

companies like canonical who the main source of income comes from servers and support have nothing to lose in droping support for 32 bits applications, hell they may even gain money from doing it since their users WILL NEED support, paid support in some cases.


also you forgot to mention that linux break support with itself with an regular base, its a shame but if you want to install an old version of an software or an software made for an different distro, some times its easier to run the windows version on wine thant the linux version on linux.
and some times you absolutelly need the old version of such software because you need an plugin that only run in and old version and you dont have enough know how or time to port it to newer versions of the software (or its an proprietary plugin)


Last edited by elmapul on 23 June 2019 at 11:41 am UTC
Redface Jun 23, 2019
Quoting: Shmerl
QuoteWhat we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions.

That's not a good thing either. Given how fast mesa, dxvk and the rest are progressing. It totally should not be frozen.

That was partly/shortly adressed too: https://discourse.ubuntu.com/t/i386-architecture-will-be-dropped-starting-with-eoan-ubuntu-19-10/11263/88

Quote32-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.
and later
QuoteWe can and should make the 32-bit nvidia drivers available as part of the amd64 packages. These would then be exposed into the 32-bit containers, ensuring that the 32-bit userspace libraries matched the version of the kernel driver, regardless of what other library versions were available as packages within the container.
I see a problem with that the HWE always is some months behind of the regular releases they come from, so someone upgrading to 19.10 when its released with not have the kernel, mesa and xorg from 19.10 available in the 18.04 container right away, unless one uses the same PPA for both.

And why not doing the same with the AMD drivers they plan to do with nvidia, shipping the 32bit along with the 64bit drivers and libraries?


Last edited by Redface on 23 June 2019 at 1:35 pm UTC
vector Jun 23, 2019
Quoting: EikeI had the impression that the x86 libs must match the amd64 ones, so freezing the former would freeze the later - and thus your graphics driver. But I'm not sure either.
https://www.winehq.org/pipermail/wine-devel/2019-June/147869.html
"The suggestion from Ubuntu is to use the 32 bit libraries from 18.04, which will be supported until 2023. It's theoretically possible for me to build the 32 bit side on the OBS using the libraries from 18.04, but that would lead to a mismatch in library versions the 32 and 64 bit sides were built against. Apt requires the i386 and amd64 versions of packages match or it will refuse to install them, so unless that changes, users of 19.10 and up will be unable to install the 32 bit libraries they need to run Wine, unless they downgrade a significant part of their system to the 18.04 versions."

https://www.winehq.org/pipermail/wine-devel/2019-June/147881.html
"Reading more carefully: their suggestion is to use a containerized 18.04 environment (snaps) to run Wine on a 19.10 system. This would use the 18.04 packages. But since there's no expectation of long term support for the environment containing 32-bit packages, I can't see any point in putting much effort into this temporary solution.

Nor do I see much point in packaging a 64-bit-only Wine on our end. It's such a niche case for 64-bit-only Wine to be useful at all. If those few people for whom it's useful need the latest development version, they can build it themselves."

https://www.winehq.org/pipermail/wine-devel/2019-June/147882.html
"As I understand it, it would still be possible to run 32-bit executables on the Ubuntu 19.10 kernel, but we'd have to build and ship all our dependencies ourselves. I don't think we want to go there just yet."

https://www.winehq.org/pipermail/wine-devel/2019-June/147985.html
"I can't use PPAs to satisfy build dependencies on the OBS. Packages have to either be in the Ubuntu standard, update, or universe repositories, or on the OBS itself. The latter is what we're doing for FAudio. That works fine, other than the whining from Ubuntu users about the tremendous difficulty of copying and pasting the command to add another repository. So if Ubuntu users do decide to go the PPA route, they should also plan on building their own Wine packages."


Last edited by vector on 23 June 2019 at 2:22 pm UTC
elmapul Jun 23, 2019
Quoting: legluondunetDon't panic, I'm sure there will be soon a solution like a "steam runtime" package containing all old needed 32 bits libraries or another solution like "VM". I just hope it will be a simpler solution as installing 32 bits software is hell for a newbie that just want to play his old 32 bits game on Linux.

wich reminds me that steam runtime is proprietary...
Redface Jun 23, 2019
Quoting: elmapul
Quoting: legluondunetDon't panic, I'm sure there will be soon a solution like a "steam runtime" package containing all old needed 32 bits libraries or another solution like "VM". I just hope it will be a simpler solution as installing 32 bits software is hell for a newbie that just want to play his old 32 bits game on Linux.

wich reminds me that steam runtime is proprietary...
Quoting: elmapul
Quoting: legluondunetDon't panic, I'm sure there will be soon a solution like a "steam runtime" package containing all old needed 32 bits libraries or another solution like "VM". I just hope it will be a simpler solution as installing 32 bits software is hell for a newbie that just want to play his old 32 bits game on Linux.

wich reminds me that steam runtime is proprietary...

No, it consists of open source libraries, and the scripts for the runtime itself is also very permissive: https://github.com/ValveSoftware/steam-runtime/blob/master/COPYING

It is possible for GOG and others to bundle those as well.
elmapul Jun 23, 2019
Quoting: BeamboomIf y'alls problem with this is old 32bit games, why can't you just keep a partition with current Ubuntu installed, and run the games on that one? I mean, times change. One can't expect an old binary to run forever, that's just not how it works.

I mean, getting rid of old technology is always a pain for some. Look at Adobe Flash, the entire world worked hard for a decade to get rid of that nightmare. It will hurt some to rip it out but sometimes we need to clean out the closet.

yeah, i dont mind rebooting the system every time i want to play an different game.
want to play a little bit of an <brand new game> for a few minutes, then a little bit of <inser old game here> for a few minutes then <another brand new game> again? just reboot! you will waste more time rebooting that playing, but who cares!
Shmerl Jun 23, 2019
Quote32-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.

That doesn't sound reassuring. Why create a problem that needs to be "addressed on case by case basis"? It will horrendously complicate things for those who want to build things themselves.

I so far don't see Ubuntu remaining a good option for gamers.


Last edited by Shmerl on 23 June 2019 at 5:10 pm UTC
Redface Jun 23, 2019
Quoting: Shmerl
Quote32-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.

That doesn't sound reassuring. Why create a problem that needs to be "addressed on case by case basis"? It will horrendously complicate things for those who want to build things themselves.

I so far don't see Ubuntu remaining a good option for gamers.

Yeah, they should do the same for 32bit Mesa as for the proprietary Nvidia driver, make them available in the AMD64 repository (or keep the needed packages in i386 and just drop the rest, no one needs a 32bit vim in a 64bit system after all)

And if they go through with removing the i386 repositories then package the libraries needed by Steam and Wine in AMD64, this should cover a lot more programs like GOG games too then.

The LXD containers can then be used by Enterprises to deliver legacy programs to their users
Purple Library Guy Jun 23, 2019
Quoting: Schattenspiegelhttps://twitter.com/Plagman2/status/1142262103106973698
Oh dear... this will get interesting
I think people haven't noticed this comment or it would be seeing a bit more discussion.
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.