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
lxc config device add steam X0 proxy listen=unix:@/tmp/.X11-unix/X0 connect=unix:@/tmp/.X11-unix/X0 bind=container security.uid=1000 security.gid=1000
Get a shell into the LXD system container
lxc exec steam -- sudo --user ubuntu --login
Add the NVidia 430 driver to this Ubuntu 18.04 LTS container, using the PPA.
sudo add-apt-repository ppa:graphics-drivers/ppa
Install the NVidia library. Also install utilities to test X11, OpenGL and Vulkan.
sudo apt install -y libnvidia-gl-430 sudo apt install -y x11-apps mesa-utils vulkan-utils
Set the $DISPLAY
Enjoy by testing X11, OpenGL and Vulkan.
xclock glxinfo vulkaninfo
The system is now ready to install Steam, and also Wine!
I’ve put this into a blog post,
What will you do when 18.04 becomes EOL and these libraries are no longer available at all? At that point, this solution will no longer work at all.
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).
And I mentioned this in another thread:
Best of both worlds, right?
Ubuntu 18.04 desktop gets support until 2023. The container image (relevant here) gets support until 2028. Isn’t that enough?
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.
LXD supports container images for several operating systems, including debian, centos, fedora, alpine, opensuse, devuan and more. If any of the other operating systems is fine with 32-bit libraries, you can use those instead.
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.
If you do not have a requirement for hardware acceleration, it is even simpler to use X2Go, as shown at https://blog.simos.info/how-to-use-the-x2go-remote-desktop-with-lxd-containers/
With X2Go, you can launch a full operating system (like Mate) in a container.
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.
That is not even close to the same as me installing Steam and instantly running a 32bit game with no extra work.
I can do that on any distribution that supports multilib. On Ubuntu 19.10+, that will be impossible to do from those version’s repos. In less than 9 years, it will be impossible to do from any version of Ubuntu. I’m willing to bet that in 9 years, I’ll still be able to run my 32bit games in Steam just fine on other distributions that are not making this choice.
With containers, you can create snapshots and even have multiple Steam accounts available in different containers.
Once you create the base Steam container, you can replicate instantly. You can even get a ready-made container image, premade to use at once.
Increasingly, I have the feeling that you are not been running Ubuntu in the first place. What version are you running now?
I have a KDE neon install around here somewhere, but it stopped being my main quite awhile ago. I’m here mostly because Ubuntu is the golden standard for testing games on Linux. Taking that away takes away years of progress that Linux has made. Now there is absolutely no distro that can be easily recommended as being the go to gaming distro. No one wants to rely on containers which will stop working at some point.
I’m also here because I help run a good sized Linux community which frequently recommends Ubuntu flavors + KDE neon to new users. These changes make it so we have literally one distribution which we can recommend after 18.04 goes EOL: openSUSE Leap. There is no other point release distribution out there other than Ubuntu or openSUSE Leap that have shown to provide enough stability to be recommended to people brand new to Linux.