First, note that 32-bit software does not work today on Ubuntu amd64 without installing additional dependencies. While Ubuntu ships with the 32-bit archive enabled, there are no compatibility libraries installed by default. There is no reason in principle that the solutions provided going forward can’t be equally as usable as what exists today.
Second, nothing in the solution described in https://blog.simos.info/running-steam-in-a-lxd-system-container/ is specific to steam except the name. This profile exposes the standard set of interfaces into the container that are needed to run graphical games, regardless of their source. And with a bit of effort this cycle, we can expect the instructions to be greatly simplified vs what is currently shown there.
I think the best road is to create a library loader that translate from x86 calls to x86-64 library.
Disclaimer: I don’t know that the idea work with my limit knowledge of loading Linux librarys.
EDIT: i think this idea is good idea for loading 32bit Steam/GOG games
Dropping support for i386 hardware and installation: Fine!
Dropping support for i386 applications: Likely going to be a mess!
And no, requiring people to run containers and VMs with old OS’s does not count as “supported”. That is exactly why we have DOSbox, WINE etc; to be able to run decades old software on our fresh OS’s.
Hopefully a smoother solution is found than LXD. It might be OK to encapsulate i386 to using an older subset of libraries. However this should be supported way beyond the support period of 18.04.
Maybe using Debian i386 libraries is a solution?
But prodding developers to getting their apps to 64-bit now(!) is a good thing
You mention “containers and VMs” in the same breath here, but these are VERY different technologies, especially as pertains to access to graphics hardware. VMs are not part of the plan for supporting 32-bit games. Containers will be used to enable users to install a 32-bit runtime environment efficiently (prebuilt i386 lxd images are provided by Ubuntu) that will enjoy security support as long as 18.04 LTS is supported. If we’ve done this right, it will be virtually transparent in 19.10.
And if support beyond the end of life of 18.04 LTS is a concern, then lxd containers of 32-bit Debian are certainly an option as well.
I also think that 32-bit should be phased out, but a solution that should satisfy all parties would be to maintain a set of core libraries to make those older 32-bit apps and games work in newer versions.
And no, the LXD approach is not the best solution. Ubuntu has always been designed as a distro for the new user and the common user does not know at all what LXD and/or a container is. I think gamers coming to Ubuntu are going to be more affected because not all games are distributed on Steam (that would be a monopoly) and you would be surprised on the amount of games that rely on 32-bit libraries (and let’s not forget about older ones which people might still be interested on playing).
I hope a solution for those cases is thought from the point of view of a common user because Ubuntu is supposed to be “Linux for human beings” and I still want it to be like that since it’s the distro I reccommend for new-comers.
They appear to be trivial to convert to amd64 packages (or even all) given that on amd64 they can run if one also installs lib32gcc1:amd64 and libc6-i386:amd64 dependencies.
I’ll try to work on a coverter script that would be able to repackage those _i386.deb as universal _all.deb or at least _amd64.deb and be directly usable on amd64-only Ubuntu installations.
Thinking more about my previous comment I came to a conclusion on what the perfect solution for all users would be.
It would basically be to migrate multiarch to the main 64-bit repo in the way it seems to be already done with GCC and libc, that would be to have basic library packages (openssl, libstdc++, Mesa, etc.) available with 32-bit counterparts (with “lib32” prefix maybe), those would be installed/symlinked to the usual places (like “/usr/lib/i386-linux-gnu”) and the software using those basic libraries would be unaffected. A lot of proprietary software/games already ship a lot of libraries on their own (we would only have to worry about things like libstdc++ and Mesa which have always been a problem anyways) and we also have the Steam and Lutris runtime which ship the rest of the libs.
I also think shipping the Wine 32-bit libraries would be wise but there could be more options for that.
This solution has the clear advantage of not having to maintain the gigantic i386 repo with all the apps while still maintaining compatibility with older/proprietary software and it is less cumbersome than the container approach (specially with games that require hardware acceleration).
Actually, no games for Linux on GOG bundle their dependencies. This will cause an issue for all games outside of Steam, the chances of all these developers going back and updating their older games just for Linux is very slim.
There’s going to need to be a solution that’s simple for users, setting up containers is not and should not be expected of average users to do.
There are many who still depend on legacy software, especially through Wine. IIRC, you need 32-bit libraries to use 32-bit Windows applications, right?
As a gamer, I play a decent amount of legacy games. One example is Origin (EA’s game client), which is still a 32-bit application if I remember correctly, and legacy games, like the first Mass Effect trilogy, are 32-bit applications.
Please don’t make blanket statements like this. Licenses generally don’t preclude the way a piece of software is packaged. e.g. there are a ton of proprietary licensed software in both the Snap Store and flathub. There may be restrictions on distribution of some software, for sure, but it’s not “impossible”.
What about games requiring 32-bit libraries? And I mean games outside Steam. This is just a question since I am curious how that would be managed with all the restrictions on redistribution games usually have.
A game can be snapped even if it requires 32-bit libraries, as they can be bundled inside the snap. If built on 18.04, that archive can be used to source 32-bit libraries from.
However. Nobody is going to go through all the games in Steam, GOG and Itch.io (and whatever sources) and package them all up as snaps or flatpaks. Game developers have a well known process of putting out a game, and moving on to the next one. They often don’t re-visit a game to rebuild / patch / update it unless it’s financially profitable to do so. For example repackaging an old title for a new system such as the Nintendo Switch. As a result there is an expectation that games continue to work forever, without needing to be rebuild / repackaged.
So. With that in mind, I did some testing over lunch today. I took a few games from GOG and tested them on a 64-bit only system - eoan with 32-bit support removed. You can find the results at the thread below. It’s not pretty.
Thanks for providing valuable testing. According to those results my fears have been confirmed. I seems quite clear that some basic multiarch should be supported in the 64-bit main repo for some time, it is too soon to completely drop off multiarch (maybe for 22.04 but time will tell).
I do agree with dropping i386 as a supported architecture since we only care about basic multiarch libs the rest of the i386 repo is not useful.
Q. What happens for derivative distributions such as Linux Mint, Pop_OS and Zorin?
Many other Linux distributions have already moved to 64-bit only. Ubuntu derivatives can continue to build upon the Ubuntu 18.04 archive which provides i386 packages. We anticipate derivative distributions will also stop providing 32-bit installation media in line with other mainstream distributions, and in most cases they already have.
Pop!_OS maintainers have already stated that they will maintain 32-bit library support as their users still rely on it, even if that means they adopt maintainership of Xorg and Mesa in their OS.
Q. Doesn’t Steam use 32 bit libraries? How can I play my games?
Steam itself bundles a runtime containing necessary 32-bit libraries required to run the Steam client. In addition each game installed via Steam may ship 32-bit libraries they require. We’re in discussions with Valve about the best way to provide support from 19.10 onwards.
It may be possible to run 32 bit only games inside a lxd container running a 32 bit version of 18.04 LTS. You can pass through the graphics card to the container and run your games from that 32bit environment.
I’m wary of running games in any virtualized/container level state. Games can get pretty performance heavy and any abstraction (snap, flatpak, LXC/Docker/rkt, and LXD) will add some loss to performance there. And no, many 32-bit Windows applications don’t always “just work” in 64-bit WINE. It’s really app dependent.
Note that this solution requires installing the proprietary NVidia libraries in the container. Will that still work when the next Ubuntu LTS ships with updated NVidia drivers, but you can still only install the old NVidia libraries in the 18.04 container?
I strongly suspect that the answer is no and that this proposed solution therefore isn’t actually viable.
So with that test, will Ubuntu consider reversing their decision to drop support for 32-bit libraries, or will Wine be Snapped? What’s gonna happen now? @willcooke
