There is a plan to drop support for 32-bit packages in Ubuntu, starting from Ubuntu 19.10.
I see lots of misinformation, so let’s try to put all this in order.
This change affects Ubuntu 19.10 (non-LTS) and newer versions. Older versions are unaffected. Unaffected versions are Ubuntu 16.04 LTS (desktop support up to 2021, containers up to 2026) and Ubuntu 18.04 LTS (desktop support up to 2023, containers up to 2028).
32-bit libraries are a mess on 64-bit systems. They are an indication that things will start getting bad on your system. I do not install 32-bit libraries on my desktop. If I need an application that comes with 32-bit libraries, I install it in a container.
I believe that it is possible to get rid of the 32-bit legacy by using container, whether those are Docker or LXD or something else.
LXD is a good candidate, and by creating a GUI LXD manager to create containers, it should make it easy for everyone to confine 32-bit legacy applications inside containers. And not mess our desktops!
Here is an ironic article about Steam not supporting 32-bit Linux distributions.
You heard this right, this happened in 2016. Valve decided to switch to the Chromium browser for the Steam Web Browser, therefore if a user had a 32-bit Linux distribution, they were unable to use the Steam client.
Why? That’s a purely subjective opinion with no rational argument behind it.
But then you still need to support the NVidia drivers. Which means you’ll have to maintain the NVidia drivers for 18.04 forever if you don’t want people to lose their old games at some point in the future. And with that, we’re back to Canonical supporting 32-bit installations.
And there’s another problem with that: Steam is meant as a universal game launcher, but if you want to both run 32-bit games and take advantage of the latest 64-bit libraries in the host system, you’ll need to switch back and forth between two different Steam client installations depending on the game. That’s not a good UX.
If there’s a good solution for seamlessly supporting legacy 32-bit applications and 32-bit Wine via containers, I’m all for it. But I don’t see how such a solution would be less work for Canonical than simply continuing to maintain the most important 32-bit libraries.
Since 2016, Steam requires a mixed 32-bit/64-bit Linux system. You cannot run Steam anymore on a pure 32-bit Linux distribution because the Steam Web Browser is a 64-bit application only (because Chromium, etc).
Therefore, you would still get a single container, a mixed 32-bit/64-bit Linux container, to run Steam.
My point was that if we now have to run Steam in a 18.04 container forever, it won’t be able to take advantage of the updates in newer releases of Ubuntu. Unless you also install it on the 64-bit-only host system, but then you’ll have to deal with two different installations on the same PC.
Let’s run Steam in Ubuntu 19.10 (no 32-bit support on the host)!
We show how to do this with an NVidia GPU, which is a bit more complicated than AMD/Intel.
We do not show how to setup audio, for simplicity.
We are going to show the actual steps. The steps can get even shorter by using profiles.
Someone will probably make some nice GUI for this.
Install LXD on Ubuntu 19.10.
sudo snap install lxd
Setup LXD. Keep the defaults on all questions.
sudo lxd init
usermod -G lxd -a myusername
newgrp lxd
Launch a container.
lxc launch ubuntu:18.04 steam
Add the GPU to the container (GPU Passthrough)
lxc config device add steam gt2060 gpu
Share the X11 Unix socket of the host to the container
Also, they will not update the NVIDIA drivers for 18.04 forever. At some point, you will be stuck with an old NVIDIA driver and unable to update to anything newer. When 18.04 becomes EOL, those NVIDIA drivers will most likely go away entirely.
You, and everyone at Canonical, seem to be assuming that we’re mad about not having 32-bit applications anymore. That isn’t the case at all. We already moved on from not being able to install Ubuntu on a 32-bit system (and I personally don’t care since barely anyone uses 32-bit desktops and laptops these days).
But removing 32-bit libraries that are essential for Steam, Wine, etc. is pure madness. Arch, & Fedora don’t offer 32-bit distributions, but they still support multiarch.
The Wine maintainer in Debian even mentioned that Wine64 is useless without Wine32 because most Windows installers use 32-bit (even if the application themselves is 64-bit).
No. I still play games from 20 years ago. Some of my games will never stop being 32bit. There is no reason to stop me from playing them as long as we are using processors which can run them.
Also, that would mean that, at best, in less than 9 years Steam is no longer usable on Ubuntu. Steam will most likely not stop selling 32bit games as long as we are using processors that support them which means they will continue to require 32bit libraries.
It is disingenuous to pull a you all and we.
There was similar drama when Ubuntu dropped the i386 ISOs and now noone is concerned. Even Steam does not run on a i386 ISO since 2016.
Software gets better and craft is reduced.
That is not even close to the same thing. The need to support 32bit hardware is dying and almost dead (you can get the same computing power of most 32bit machines out of a cheap Raspberry Pi). The need to support 32bit software still exists for many users every day.
I believe that in 2028 you will be able to get a computer that is powerful enough to run multiple VMs and you will not be concerned at all about package compatibility. You would install the old distro ISO of your preference and then your favorite game.
No, I’ll just install a distribution that still supports 32bit libraries (there are quite a few that show no signs of dropping multilib support). Suggesting LXD in the first place is kind of crazy if you really think about it. Ubuntu is supposed to be one of the most user friendly distros out there… not something that requires users to run many things in a terminal to get their programs working.
Wait, the issue we are discussing is not 32-per se, the issue is Intel 32-bit (i386). The RPi has the architectures armhf and arm64, which are both fine (and not relevant to the discussion).
I am explaining with the command line how these work because it is not some black box. It is simple enough that it is possible to create a GUI manager that creates the prepared containers for you.
And your solution is still a temporary band-aid just as any other solution offered for this problem. Sorry, but removing 32bit support entirely is not an acceptable thing to do at this point in time.
When you have to run legacy software, you either go for a virtual machine (full OS virtualisation), or you use a runtime (containers, Docker or LXD). It is a bit too much to expect software compatibility with running libraries from decades ago.
Here is an example. retdec is some Tcl/Tk program from a decade ago. There is a package for retdec in Ubuntu 12.04 (universe repository) but that package has not been updated to work with newer versions of Ubuntu or Debian. It just does not work on newer distributions. You would need to use a VM (takes resources on current computers), or you can use a runtime of Ubuntu 12.04 (container image) and run the application with minimal affect to performance.
That’s what I demonstrate at https://blog.simos.info/how-to-easily-run-graphics-accelerated-gui-apps-in-lxd-containers-on-your-ubuntu-desktop/ running retdec on Ubuntu 18.04 inside an Ubuntu 12.04 container, with no performance penatly.