Canonical have listed what 32bit packages they will continue to support through Ubuntu 20.04

It is a bit "meeh". I can't really tell them, wich 32 Bit libs I need - I don't know how to find out....

So I asked for my printer driver and the spotify client.

In all honesty, 32 bit stuff DOES need to go at some point. I mean, for how long is Linux supposed to carry on that old baggage?

That Steam (which is one of the most important Linux applications there is, and is maintained by a multi-billion dollar business) STILL doesn't have a 64 bit client is quite frankly unforgivable.

I would really think they should agree on a reasonable grace period and then elbow people into finally updating their legacy 32 bit apps. If after that date, people still -really- insist on running decades-old software or even older hardware, they can still maintain and build these packages themselves. It's open source software, after all.

In all honesty, 32 bit stuff DOES need to go at some point. I mean, for how long is Linux supposed to carry on that old baggage?

That Steam (which is one of the most important Linux applications there is, and is maintained by a multi-billion dollar business) STILL doesn't have a 64 bit client is quite frankly unforgivable.

Honestly, how many multi-billion dollar companies offer a great gaming client like steam?
I forgive it easily and with our about 1% marketshare, we should be a little bit cautious with "elbowing out" - it may result in a "we don`t support Linux anymore - sorry".

And playing "old" 32 Bit games is also not that unforgivable, isn't it?


Last edited by einherjar on 17 September 2019 at 4:10 pm UTC

I was waiting for this since they wrote they would create that list and let users request what they need, and was wondering it would be postponed until a later release now with 19.10 so close.

I have a 19.10 installation on my laptop since July and will test games on it in case some need some 32 bit libraries not on the list and not in the steam runtime.

In all honesty, 32 bit stuff DOES need to go at some point. I mean, for how long is Linux supposed to carry on that old baggage?

Okay. Then. Lets just obsolete 32-bit, 64-bit and switch to source only distros like Gentoo then. Because that's the only way we are going to end the cycle of obsoleting 8-bit, 16-bit, 32-bit, 64-bit, 128-bit 256-bit etc...

I disagree. 32bit needs to stay, yet alone for all those 32bit applications/games. How am i supposed to play/use those when they are gone?

Agree. We still have DOSBox to play DOS games and all kinds of containers to keep games working. 32-bit needs to stay -- devs literally no longer have the source code to some games and there is no difference to the average consumer, all they see is "It works" and "It doesn't work".

Steam isn't an idealistic engineer's dream of the perfect system with 0 users, it's a practical middle-ground for all developers will millions of users which delivers games & content to gamers.

In all honesty, 32 bit stuff DOES need to go at some point. I mean, for how long is Linux supposed to carry on that old baggage?

No, thanks. This isn't about clients, but about a ton of games that will be unplayable without it. Until there is another solution (with adequate performance), it shouldn't go, that's very clear.


Last edited by Shmerl on 17 September 2019 at 4:40 pm UTC

The 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.

At least this is public and stated well in advance. Maybe this needs a little bit more publicity ? I hope this time nobody will be taken by surprise.

At least they seem to be learning. :)

That said, Manjaro looks very good.

Migrated from Ubuntu (Kubuntu 16.04) to Manjaro like a month ago and so far I can only recommend it. KDE-wise, under Manjaro there is significantly less bugs related to multi-monitor and multiple audio outputs from GPU. Package-wise - it's brutal that probably everything I need is in official repository or glorious AUR, under Ubuntu I had to install a lot of stuff via PPAs (I had dozens of PPAs) and few manually without package manager (and with a few I failed, because packages in Ubuntu were too old and I was too afraid of breaking something I gave up). Frankly, I was expecting a lot of issues and manual work from Manjaro, but I believe it was actually less work to setup (encryption of all drives including OS, mounting, backups, dev tools and such things) than Ubuntu few years ago.

It is a bit "meeh". I can't really tell them, wich 32 Bit libs I need - I don't know how to find out....

So I asked for my printer driver and the spotify client.

Yes, we need a guide how to find out what 32 bit packages are installed and needed.

I try to start:

Start with looking at which 32bit packages you have installed

apt list --installed|grep i386

seems to work well for that since it does not show the descriptions that

dpkg -l|grep i386

does, which also show uninstalled packages that still have configuration files, and thus gives more.

There is probably also something for snap,

snap list

will give a list of installed snaps, but not tell if they are 32bit or 64bit.

Once you have a list check on the list of 32 packages still maintained for 19.10 and 20.04.
For those not on it check if you actually need it.

If you need it then request it to be kept as 32bit package.

Apple for example doesn't care about gaming, so they can drop 32-bit using the argument that "it has to go", without any thought about providing a replacement. I suppose Linux ecosystem should differentiate, and use this opportunity to welcome Apple refugees, instead of acting the same.

In all honesty, 32 bit stuff DOES need to go at some point. I mean, for how long is Linux supposed to carry on that old baggage?

That Steam (which is one of the most important Linux applications there is, and is maintained by a multi-billion dollar business) STILL doesn't have a 64 bit client is quite frankly unforgivable.

I would really think they should agree on a reasonable grace period and then elbow people into finally updating their legacy 32 bit apps. If after that date, people still -really- insist on running decades-old software or even older hardware, they can still maintain and build these packages themselves. It's open source software, after all.

It's much easier for Valve to release a single 32-bit client that works on every system than having to either support two versions or forcing clients to upgrade to 64-bit hardware. Then there is the technical detail of letting 32-bit games use the steam overlay, not sure if there are some technical details here or not also that could create problems if the steam client was 64-bit (I have no experience with crossing the 32- and 64-bit boundary like this).

In all honesty, 32 bit stuff DOES need to go at some point. I mean, for how long is Linux supposed to carry on that old baggage?

No, thanks. This isn't about clients, but about a ton of games that will be unplayable without it. Until there is another solution (with adequate performance), it shouldn't go, that's very clear.

Seriously, 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? Yes, I get it, there will be SOME that do, like SOME still play C64 games on an emulator - but I'd wager that group relates in about the same way to Linux users as a base group as Linux users relate to Windows users: A tiny minority. I don't think it's too much asked for to tell this group to take over maintenance of needed legacy 32 bit libraries, if they want to keep playing decades old games. I just feel that Canonical's resources could be used more productively than for keeping alive stone-age software. I am pretty sure interested people could come with some creative solutions how to keep these old games running the same way C64 games and Amiga games can still be played. Change isn't the end of the world.

Okay. Then. Lets just obsolete 32-bit, 64-bit and switch to source only distros like Gentoo then. Because that's the only way we are going to end the cycle of obsoleting 8-bit, 16-bit, 32-bit, 64-bit, 128-bit 256-bit etc...

Not that there would be a main-stream use-case for 128 bit processors, or ever will be. There is a reason why they aren't made, you know?

Seriously, 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.


Last edited by Shmerl on 17 September 2019 at 6:31 pm UTC

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 agree with that. But I doubt that there will be serious efforts being made to look for alternative solutions as long as there isn't some...gentle pressure applied. If people are made to believe that legacy support will be a part of mainstream distros for all eternity, it won't happen. Humans don't do anything without a compelling reason. Which is why I suggested a grace period long enough to make it happen, but people should understand that one day this stuff is going to be retired from mainstream distros.

The 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.

That 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

Seriously, 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.

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.

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.

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.

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.