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

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

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

View this comment - View article - View full comments

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 [External Link]
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.

View this comment - View article - View full comments

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

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

Quoting: ArdjeNice, then I might need an upgrade of my NVidia hardware too on my laptop. Oh wait...
But are they seriously going to support 3 or 4 revisions of NVidia drivers on LTS? (Mostly depends on which generation NVidia decided to stop supporting your hardware).
Or is this only for the latest generation?

They already done that for years, the latest driver that made it into the release and some of the legacy drivers for older cards.
I do not think all legacy drivers, but at least one. The new thing is that you get the newest without needing a PPA, but some of the legacy drivers will be there too still. My guess is that they keep 340 and 390 in 18.04 when 430 lands. And then when a newer version comes that it will replace 430, but 340 and 390 will stay for users with really old cards.

View this comment - View article - View full comments

Congratulations with the 10 years!

View this comment - View article - View full comments

Quoting: dibzRegarding Mint's wording about 32bit support in their announcement (which wasn't quoted here), I find the mixed reporting on all of that to be interesting. I'm pretty sure many of the writers out there are either ignorant of, or willfully ignorant of, the original posting/news about 32bit support removal where Canonical was quite clear about the complete drop of 32bit support -- not just for the kernel/distro release. They backtracked regarding multilib support only after Valve had some words for them.

They certainly tried to spin it like that was always the case in that updated "clarification", but it's plain for the world to see -- and read given five to ten minutes -- that there was no miscommunication.

There clearly was miscommunication and misunderstandings, else there would not be so many that thought that the change would mean that it would be impossible to run 32 bit programs after the announcement on the 18th June. Or that the clarification meant some for for backtracking. https://lists.ubuntu.com/archives/ubuntu-announce/2019-June/000245.html [External Link]

Maybe start by reading the forum thread here that came before this blow up with in the press and forums: https://www.gamingonlinux.com/forum/topic/3938 especially what Samsai wrote https://www.gamingonlinux.com/forum/topic/3938/post_id=23713

If that is not enough read what Valve employee plagman wrote https://old.reddit.com/r/linux_gaming/comments/c24gpk/i386_architecture_will_be_dropped_starting_with/eri4vy2/ [External Link]

Steam and thousands of its games rely on a 32-bit glibc from the host system, as well as OpenGL and Vulkan userland graphics driver libraries for Mesa and the NVIDIA driver. Steam as it currently exists will be broken on 19.10 unless more work is done on our end. That work seems tractable, but fairly involved; what's unfortunate is that it will take away resources that would otherwise be spent on improving performance and functionality.

and this was later when Valve wrote they will again support Ubuntu 19.10 and forward : https://steamcommunity.com/app/221410/discussions/0/1640915206447625383/ [External Link]

To that effect, Steam already bundles a lot of the dependencies needed by 32-bit games, but it currently relies on some key components being available on the host system: a 32-bit glibc, ELF loader, Mesa and NVIDIA graphics driver libraries, to name a few. We've been investigating ways to avoid these system dependencies for a while now, by looking into light containerization and other approaches. The announced change by Ubuntu would have required us to fully complete such a system in the 19.10 release time frame, as it would be required there to maintain functionality without requiring users to reinstall Steam through another method. A significant portion of our Linux users are on the latest version of Ubuntu and upgrade as new versions become available. Requiring such a fundamental change in Steam's runtime environment in that time frame would have been very risky for these users, and would likely not have resulted in a seamless experience.

So that is consistent with that it still will be possible to run 32 bit programs but it will require quite some effort from Valve (and wine and other developers) and most likely be at least a hassle if not too complicated for many users.

Yet when they wrote the clarification that it would still be possible to run 32 bit programs just in another way many that believed 32 bot programs would not run any more thought they where backtracking. They where in fact still on that plan fleshing more details out. I had a recent discussion on reddit about this arguing for that that was no backtracking but consistent with the first announcement: https://old.reddit.com/r/linux_gaming/comments/c7e2ik/about_to_give_linux_a_real_shot_again_with_all/eseygql/ [External Link] also about that this not after Valve had a word with them, but after, and that It was a lot of users and even Canonical employees and developers including Valve that convinced them to change the decision.

View this comment - View article - View full comments