You can sign up to get a daily email of our articles, see the Mailing List page!

After Canonical announced they would be ending 32bit support earlier this year and then adjusting their plans after the backlash, they've now posted what packages they will look to continue supporting.

Canonical's Steve Langasek posted on their Discourse forum a list which they "have been able to determine there is user demand based on the feedback up to this point" and they will "carry forward to 20.04" and that includes other packages not directly in the list that they may depend on.

Additionally, their methodology for picking the packages included ensuring some well-known apps continue working like Unity, Godot, printer drivers and more. The list includes some noteworthy items like SDL 2, Wine, DXVK, Steam, some Mesa packages, a few open source games and so on.

See the full post here, where Langasek did mention to give feedback if you feel essential 32bit packages are missing from their list. It's good to see some clarity surrounding it, hopefully this won't cause any issues now.

Article taken from GamingOnLinux.com.
25 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more information here.
About the author -
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.
See more from me
41 comments
Page: «3/5»
  Go to:

Redface 17 September 2019 at 6:45 pm UTC
slaapliedjeThe ones in the camp of '32 bit has to go anyhow' must not be seeing the big picture. There are tons of binary only software out there that are stuck in perpetuity in 32-bit. Also, you can VERY easily just install 64-bit programs only on your system. Hell Debian doesn't even have 32bit support enabled by default, you have to enable it yourself. So just install a distribution like that, and you can leave us that enjoy having 32 bit compatibility alone.

That said, I have to eliminate Ubuntu from my list of distributions for my '10 Thinkpad' project for LAN games due to their intention to remove 32bit libraries. Might stick with either Solus or Sparky Linux, they seem pretty decent for the task.
They will only stop building 32 bit libraries that no one needs, as they announced back in June, https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
This is the community process they wrote about then how to determine what 32 bit packages still are needed. And they will add more if needed after release.

But good luck with your project what ever distribution you choose.
Redface 17 September 2019 at 7:04 pm UTC
DedaleThat said, if i can actually contribute concretely to the conservation of 32 bit libs and legacy software i value. I would be happy to do so.

For example, to donate money to a maintainer. The sole problem is my means are very limited now and for the next coming years. So my donations would be very small.

We gamers cannot always contribute code or meaningful knowledge. But we can donate. The problem i foresee is the total amount donated would probably be very small.

On my Ubuntu 19.04 there are more than 30000 i386 packages available, Ubuntu for now has 200 on the list to still be maintained, which will grow, but surely not that much.
So this will help all, also other distributions, to get a list of still needed 32bit packages which will be much more manageable than all we have now.

So your idea will be more feasible then, also having old distributions with only minimal number of packages available for lxc containers or similar. This can also help for old closed source 64 bit packages that do not work any more with current and future libraries.

I got to the number with

apt list --all-versions|grep i386|wc -l

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

33365
Redface 17 September 2019 at 7:11 pm UTC
Shmerl
KimyrielleSeriously, in say 5 years from now on, who'd still want to play 32 bit games when most gamers consider a 5 year old game a museum piece?

Anyone who values good games. I play and replay old games. GOG has a whole store with focus on old classics. The idea that games should be disposable is wrong. So if not 32-bit libraries, there must be another way to play them, before dropping such support. And a way that doesn't perform like garbage.

I tried setting up a 18.04 lxc container with full GPU access when the original plans got known in June.
GPU speed looked the same as on the "host" but the setup was a bit involved with a lot of commands to run, so far from transparent to the users.

Containers are advanced chroots and not virtual machines, and so have full access to anything that is configured for that container, including sound, 3D graphics and whatever.

I then run into that kernel bug back then that made it impossible to login to steam and removed it again before reading about that bug. And have not got back to test that more since.

So that really needs more work than there was from June to the 19.10 and even the 20.04 release, but now with more time I can see that this should be possible to be an automatic setup in the background when installing old legacy programs.
Using an even older distribution for old closed source games from the 90ies or 00ies might be a way for this too.
Shmerl 17 September 2019 at 7:18 pm UTC
Using containers with frozen libraries isn't a good solution either. You want to benefit from all the innovation that goes into Mesa, Wine and the rest of the gaming stack. So either 32-bit libraries need to be maintained, or there must be some architecture translation of x86_32 into x86_64.
slaapliedje 17 September 2019 at 7:27 pm UTC
View PC info
  • Supporter
  • Top Supporter
The dumb thing is these packages are mostly handled by the build system. So there isn't actually a person who manually builds these, they just hit a build server, and you know Debian isn't going to drop 32bit support anytime soon, Ubuntu is just trying to be like Apple.
Redface 17 September 2019 at 7:39 pm UTC
ShmerlUsing containers with frozen libraries isn't a good solution either. You want to benefit from all the innovation that goes into Mesa, Wine and the rest of the gaming stack. So either 32-bit libraries need to be maintained, or there must be some architecture translation of x86_32 into x86_64.
As far as I remember then libraries that interface with drivers will have to be the same version, so nvidia and mesa will have to be a current version in the container. The programs in the container run on the same kernel.
And in the Ubuntu world frozen does not mean unmaintained, even if it sometimes seems like it or even is. Security and other bugfixes will be backported to the "frozen" version.
Shmerl 17 September 2019 at 7:43 pm UTC
slaapliedjeThe dumb thing is these packages are mostly handled by the build system. So there isn't actually a person who manually builds these, they just hit a build server, and you know Debian isn't going to drop 32bit support anytime soon, Ubuntu is just trying to be like Apple.

Problems might start creeping in, when upstream (i.e. library developers) will decide, that supporting 32-bit is too much of a burden. It's not as simple as "just build it" usually.


Last edited by Shmerl at 17 September 2019 at 7:46 pm UTC
Shmerl 17 September 2019 at 7:44 pm UTC
RedfaceAs far as I remember then libraries that interface with drivers will have to be the same version, so nvidia and mesa will have to be a current version in the container. The programs in the container run on the same kernel.
And in the Ubuntu world frozen does not mean unmaintained, even if it sometimes seems like it or even is. Security and other bugfixes will be backported to the "frozen" version.

Why do you need containers then, if libraries there will be recent? Multiarch already works fine for that. Containers make sense for frozen case, when there are no more upstream updates coming.


Last edited by Shmerl at 17 September 2019 at 7:45 pm UTC
Redface 17 September 2019 at 8:00 pm UTC
slaapliedjeThe dumb thing is these packages are mostly handled by the build system. So there isn't actually a person who manually builds these, they just hit a build server, and you know Debian isn't going to drop 32bit support anytime soon, Ubuntu is just trying to be like Apple.

The build system is set up to support 32 bit installs on 32bit i386 processors which Debian supports for all distributions, and Ubuntu still for LTS 16.04 and LTS 18.04. But since there is no 32 bit installer for 18.04 or newer and no upgrade path for those on 32 bit processors most 32 bit packages since 18.10 will never be installed by a user.

But they still can fail to build and a maintainer has to look into why.

There are also really many of those. Ubuntu has for now 200 packages on the list, lets say that grows to 500.
I earlier counted 33365 available 32 bit packages on 19.04, so lets say 28000 wasted effort and resources. And Ubuntu always has always around 5 different releases supported or under development, so we now are around 100000 packages build that no one uses.

Apart from maintainer time this uses electricity, storage and bandwidth, which all could be used for something useful instead.

Apple is AFAIK completely disabling running 32 bit programs except from inside virtual machines, and soon there will be no MacOS version left with 32 bit support that still is supported. Ubuntu wants to stop building packages no one uses, and in the future finding another solution for the few hundred packages left that are needed to run all kind of 32 bit programs. But already in the first plan they wanted to make sure users still can run 32 bit programs, the solution for that was still not ready though, so they came up with this plan.
So really not like Apple.
How is that similar?
Redface 17 September 2019 at 8:15 pm UTC
ShmerlWhy do you need containers then, if libraries there will be recent? Multiarch already works fine for that. Containers make sense for frozen case, when there are no more upstream updates coming.

Mixed cases, some libraries do not always stay backward compatible, while the kernel tries to never break userspace.

So the games might work with current graphics drivers but not with some network library or whatever.

Did you never encounter games or other programs that have problems with newer libraries?

I am not convinced that this is the way forward to run old games, but it is better than virtual machines since containers can get access to the all parts of the system you want.

And containers where the original plan, for now until at least 20.04 Ubuntu will built all requested packages for 32 bit, and who knows for the next distribution after that maybe too, but I understand they do not want to commit to that now. 20.04 will be supported until April 2025 that is already a long time they will stick to this new scheme for that release at least.


Last edited by Redface at 17 September 2019 at 8:16 pm UTC
  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon, Liberapay or Paypal. We have no adverts, no paywalls, no timed exclusive articles. Just 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!

You need to Register and Login to comment, submit articles and more.


Or login with...

Livestreams & Videos
None currently, submit yours here!
See more!
Popular this week
View by Category
Contact
Latest Comments
Latest Forum Posts