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

Quoting: KimyrielleIn 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).

Quoting: Shmerl

Quoting: KimyrielleIn 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.

Quoting: ElectricPrismOkay. 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?

Quoting: 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.


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

Quoting: ShmerlSo 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.

Quoting: 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.

Quoting: GuestThat 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

Quoting: Shmerl

Quoting: 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.

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.

Quoting: 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.