Intel 32bit packages on Ubuntu from 19.10 onwards

[vorlon]

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.

[jorgetech]

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.

[xnox]

Brother has full support for their printers/MFC devices but even their newest devices only have 32bit driver packages.

I am looking at i386 debs published at https://support.brother.com/g/s/id/linux/en/download_prn.html

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.

[jorgetech]

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).

[liamdawe]

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.

[YamiYukiSenpai]

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.

[jorgetech]

And let’s not forget that packaging propietary software n Flatpack and Snap would be impossible due to their licenses.

[popey]

@jorgetech

And let’s not forget that packaging propietary software n Flatpack and Snap would be impossible due to their licenses.

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”.

[jorgetech]

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.

[popey]

@jorgetech

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.

Results of testing 3rd party applications on 64-bit only eoan (19.10)

Further to the recent announcement and subsequent discussion, I did a little testing over lunch on eoan 19.10 with all i386 packages removed and the i386 part of the repo disabled. I did this because there’s been a couple of assertions made: That games ship their own required libs and will likely work That WINE64 is sufficient for playing Windows games These don’t seem to be true for the limited testing I did. I would urge more testing and feedback. I’m also keen to hear if my testing strate…

[jorgetech]

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.

[dhollinger]

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.

[codemonkey]

@willcooke

Here’s a good post which describes how to set up a LXD container for Steam from @simosx:

https://blog.simos.info/running-steam-in-a-lxd-system-container/

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.

[YamiYukiSenpai]

@popey

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.

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

[tov]

OK, so now Valve will no longer support Steam on Ubuntu from 19.10 and onward:
https://twitter.com/Plagman2/status/1142262103106973698

… will also switch our focus to a different distribution, currently TBD.

[ian-weisser]

Folks,

Gentle reminder that “I don’t like this decision” and “You are destroying Ubuntu” and “I’m taking my marbles and going to another distro” posts are not constructive or useful, and will be promptly removed.

Real data on consequences is constructive.
New issues discovered are constructive.
Options to move forward are constructive.
Forming community working groups to overcome blockers is constructive

Gamers, there are already other game-related and steam-related threads on this topic. Your accurate testing results are welcome there.

[bigbruno]

Why not maintain just a necessary to run almost all games and apps?

Maybe more os less 100 packages with i386 architeture, that not the same of maintain all i386 repository, just help lot users, and dramatically reduce the job needed to maintain Ubuntu repositories.

Make users happy, make devs happy, make Ubuntu filosophy. More humanity and less autority.

[popey]

I think it’s not unreasonable for people to express frustration here. Given the potential impact of the change being mooted. Obviously we’d rather people were respectful in their interactions here.

I would imagine volunteers such as yourself don’t fancy spending the entire weekend moderating comments on this site, either. It’s a hot topic though and I suspect people feel the need to vent a little. I do hope they appreciate we are reading all of this, and do appreciate the constructive suggestions and feedback.

Bear in mind the change being outlined hasn’t happened yet, and we’re still gathering feedback.

[mcphail]

Hi. I really appreciate your efforts to keep the discussion clear and civil. Passions are going to run a bit high about this, though, so it might be sensible to allow a bit of discussion to play out for a while. The Linux world is watching, and I think it is important the community forum doesn’t show a deaf ear.

[jorgetech]

I’m glad that the devs are listening to the community, I hope the feedback and testing is useful to make a good decision.

I also want to remind that it’s good to follow the Ubuntu philosophy, we can all benefit from different points of view.