Poll: Will dropping the i386 repos affect your use of the amd64 port?

  • I’m happy with 64-bit only
  • Dropping i386 will hurt my 64-bit experience

0 voters

For my part, losing i386 libraries will affect games and my printer drivers. Do you foresee any consequences for your workflow?


Thanks for the topic. When you mention games, is that Steam or some other games? We do plan to provide a solution for Steam before 19.10 so that shouldn’t be an issue.

Could you give some details about what’s the issue with the printer drivers? What printer/drive do you have, how did you install them before and what is not working in a world without an i386 archive?

I’m afraid this may affect me as well, as I still run a lot of Win32 (and even Win16) programs via WINE for which I’ve found no suitable Linux replacements…

1 Like

Hi Sebastien.

From a games point of view, my GOG library holds about 200 titles. Some of those are amd64 but many are not. See, for example, the system requirements for https://www.gog.com/game/neverwinter_nights_enhanced_edition_pack which was released last year.

A solution for Steam will work for a subset of titles on there, but many games don’t use the Steam runtime. Will there be a solution for those? Bear in mind that many of these games don’t play nicely with confinement, having hard-coded paths to configuration dot files which don’t fit in with generic solutions.

I have 2 laser printers. My Samsung has 64 bit drivers but my Brother doesn’t. Up until now, it has made more sense for manufacturers to provide i386 binaries rather than amd64, as a single blob would run anywhere.

I know enough about containers and chroots that I will be able to find a way around these issues, but I’m fairly technically adept an even I find them messy. My worry is that a lot of users will end up with Debian/Ubuntu Frankensystems which will break in horrible and unpredictable ways. I really wish i386 compatibility didn’t have to be a thing (and I agree we’re in a much better place than when the Java and Flash web plugins were king) but we’re not there yet.

1 Like

Dropping the i386 base libraries will break the ability to use my two Brother MFC printers/scanners.

Even for their newest devices they only provide i386 debs/rpms.


@ccheney, @mcphail
Would your Brother printers work all right with Windows 10? That is if you are dual booting. Just asking, as Windows 10 has System32 and SysWoW64 folders.

It’s useful to have this information, thanks.

In terms of whether this should be a consideration, I think this would be circular. I can imagine someone at Brother saying “we only need to release i386 since Ubuntu supports that”. The circle has to be broken somewhere eventually.

You should petition Brother for amd64 support. If they don’t provide it, then the risk of buying hardware that comes only with non-free drivers will have come true in your case - you knew at the time of purchase that you’d only have working hardware for as long as the manufacturer supported you, rather than indefinitely.

My point is that it doesn’t make sense to hold back progress on this basis - since they are almost certainly using Ubuntu’s existing support as a baseline to decide what to support in Linux at all, we’d end up completely stagnating if we did that.

1 Like

I’ve started a new topic about the printer 32 bits driver

1 Like

It will affect to a lot of users, for example, those who want to play a non-Steam 32-bit game and those who want to run propietary software necessary for their life or job that still is 32-bit.

The only real solution is to maintain in the 64-bit repos some multilib 32-bit packages (and symlink them to the expected places), this would not require maintaining an entire i386 repo which is a lot of work and people only care about the 32-bit libraries not the apps in the repo. The container solution only works for some people and it’s not that simple and seamless, if I’m not mistaken you need two GPUs, only a small percent of users have two GPUs and know how to do GPU passthrough (also think about theming).

If Canonical is not going to do it, at least let the community do the work and integrate that in a seamless way for users, other distros have community maintained 32-bit multilib repos and it works well. Something like the Lutris Runtime would be enough (https://github.com/lutris/lutris/wiki/Lutris-Runtime) except that it cannot do anything about GPU libraries which are as essential as a 32-bit glibc.


i run a lot of windows VSTs using Wine and this’ll affect my music production


I also play games from Origin, and the client itself is still 32-bit. In addition, my favorite games from Origin are mostly 32-bit, such as Mass Effect trilogy.

1 Like

This will negatively affect Ubuntu Studio


Valve has officially announced they will no longer support nor recommend Ubuntu after 19.10. Unless Canonical pulls an about-face, there is no way I’ll be upgrading to 20.04 next Spring either.

You can add Pop!_OS repository. I really hope Valve choose either Pop!_OS or Manjaro.

Yes, it very much does. The solution of using 18.04 libraries in snaps is a temprorary band-aid. What happens when 18.04 is EOL? 32bit support goes away.

Now we have users all over the place recommending distros that are not nearly as well maintained as Ubuntu and its flavors for use over Ubuntu so that users can continue to game and use 32bit applications easily…

This has sent shockwaves all over the Linux userbase. Even people who would never consider using Ubuntu have their minds blown when hearing this. It would have been nice to have a public discussion on this before making these choices.


Since the original information that led to this poll has been superseded by newer information, I’m going to close this thread to prevent confusion.

Thanks to everybody for participating.

If anybody wants to keep talking about i386, there are a couple open threads on the topic, or feel free to start a new one.

If you feel that any of the issues or side-conversations should continue to be explored, just let me know and I’ll move those posts to a new thread.

1 Like