Intel 32bit packages on Ubuntu from 19.10 onwards

With LXD, you can run other operating systems as well, including Debian, Centos, Fedora, OpenSUSE, Devuan and more. 2028 is really a long time, but still you can run other distributions as well.

I suppose the computing power in 2028 will be more than enough to run easily proper virtual machines on anything for any i386 ISO image.

Are we really discussing concerns about the year 2028?

1 Like

That is not that far away, really. Rather than emulating distributions that have not chosen to take this route, I think I’d rather just switch to one of those and make my life more simple all around. All of these containers are much more of a headache to deal with than just switching to a distro that has no signs of dropping multilib support.

I understand that there is need for some handholding to get to know about containers. I am writing posts about this.
Mixed 32-bit and 64-bit systems are messy. If you find such a distro, good for you. Note that it is increasingly too much work to maintain 32-bit Intel packages, even so watching for security updates.

1 Like

They are not at all messy. The libraries live in separate directories and work just fine. We have been doing this for many, many years without any major issues.

I follow the Steam github Issues and I see many weird and hard to debug problems.
Many people just end up reformatting and installing from scratch. But doing so is an indication that things have gone terribly bad.

Correlation != causation.

How are you going to handle not very standard /etc/nsswitch.conf?

For example, the machine is a member of a FreeIPA or Samba AD or Windows AD domain. Name Switch Service (glibc) plugins sss or winbind are added to /etc/nsswitch.conf. When a program calls libc’s functions to get information about users or groups, glibc uses those plugins to prepare an answer. sss NSS plugins interacts with SSS daemon (SSSD), winbind interacts with winbindd (part of samba).

The same situation is with hostnames resolutions. For example, this line from /etc/nsswitch.conf
hosts: files dns myhostname mdns4_minimal
means that when glibc receives a request to resolve a domain name, let it be xxx.loc, it will first look for a matching record in /etc/hosts, if it finds nothing, tries DNS resolution which is configured in /etc/resolv.conf, after that tries to use nss-myhostname, then tries Avahi daemon which implements mDNS/Zeroconf protocol.

Avahi libraries copied from 18.04 will be different than the Avahi daemon running on the host, how will that work? Avahi is a rather simple case, let;s take winbind (Samba). 32 bit winbind and samba libraries will be completely different from the daemon and libraries on the 64 bit host, how will this combination work?

According to this, plus Wine requiring the same runtime in 64 bit and 32 bit modes as @jre-phoenix noticed, plus the necessity to use proprietary drivers for printers and scanners, I would suggest to just build i386 repository as it was always done. Kernel, Chromium, Firefox, Thunderbird, Java etc. should be dropped, because they require many-many resources to test properly and ofthen regress on 32 bit.

2 Likes

I oppose the idea of dropping 32 bit binaries. There is no good technical argument for it, but many against it. It will break printer drivers and break many 32 bit binaries for other programs for which there is no 64-bit alternative (could be commercial programs where a company or individual only has a license for a 32 bit program). Brother, the printer maker, may be discouraged by the effort it will take to redo all of these drivers. It will also damage other systems such as Valve/Steam which depend on 32 bit binaries and run many programs for which there is no sources for at all. Many Windows programs have no 64 bit alternative and no source code, and we want to be able to run them.

The work needed to fix these problems is far greater than the work needed to simply continue making 32 bit binaries. The building of 32 bit binaries should be an automated process and simply runs parallel to building the 64 bit binaries and should consume very, very little of developer resources. Thus there is no real benefit to no longer building 32 bit.

The idea of trying to figure out which 32 bit binaries are not a dependency for something else, and remove those but not other items from the build process does not make sense. This is because trying to figure out which programs are not a dependency and which ones are would take more time and resources than simply leaving things as they are now and building everything for 32 bit. Plus something which is a dependency would be accidentally removed which would end up consuming more developer resources to have to fix that problem. This is as opposed to just continuing to build everything for 32 bit which consumes very little or no developer resources and will be most likely to not break anything.

So it is very clear just leaving things as they are now, building everything for 32 bit, consumes the least developer resources and carries the least risk of breaking anything, thus the least risk of unnecessarily consuming time resources to fix something that didn’t need to be broken in the first place.

5 Likes

@RussianNeuroMancer on the subject of pcsx2, I see that the upstream build system says that 64-bit x86 support is “not ready yet”. Do you know what exactly that means or where I might find out?
I’m able to get the software to build on amd64 with a few minor changes to the build system, but I have no way to test the result; is it worth some empirical testing here to see how close to “done” the amd64 support is? https://launchpad.net/~vorlon/+archive/ubuntu/ppa/+packages

Not sure what this could mean; I thought they never ever going to implement amd64 support due to reasons explained here.

Tried to run couple of games, it just crash as soon as it tries to run any emulation.

People thus far have mentioned Bother and Cannon Printers as a potential issue. Let me add another one. Lexmark uses 32bit drivers for some of their higher end enterprise printers. For example there are many use cases to need a Lexmark 3950 and it’s derivatives. The drivers provided by Lexmark not only are 32bit but depend on 32bit java as well for the proprietary print manager. It was no IceTea or OpenJDK compatible so one needed the 32bit Oracle Java packages to be installed. This just adds one more non-game to the mix that will effect the enterprise and business end.

1 Like

2 posts were merged into an existing topic: Dropping 32 bit support (i.e. games support) will hurt Ubuntu. Big time

2 posts were merged into an existing topic: Dropping 32 bit support (i.e. games support) will hurt Ubuntu. Big time

Thanks, not particularly surprising but good to have it confirmed. In principle it would be possible to use the 32-bit emulator implementation on amd64 without having to completely port everything to 64-bit, but that would still be a significant amount of work and evidently hasn’t been done here.

1 Like

To be a little more specific, if you compile it as 64 bit, you would also need to turn change four different settings to interpreter from recompiler. At that point, you may be able to run some games, but at slow enough speeds not to be particularly playable. (And it will crash if built as a debug build, and hasn’t been extensively tested when compiled as 64 bits, as the recompilers not working is enough of an issue for it not to be supported.)

The trouble is that it uses dynamic recompilation in several places to speed things up, and porting a JIT over between architectures is not the easiest task, especially when large portions of it were written by people no longer with the project.

1 Like

I’ve been working on a script to automatically create a LXD container with Steam inside. I’ll post details later. It uses nvidia.driver.capabilities: to expose the required GPU capabilities.

I see you’re installing the nvidia userspace inside the container, this shouldn’t be required because that is what nvidia.runtime and nvidia.driver.capabilities in the LXD profile is taking care of by exposing the hosts nvidia userspace inside the container. Bundling the nvidia userspace inside the container has the drawback that it make the container brittle; any nvidia update on the host will break the container.

However, there appears to be a bug in LXD where it does not currently expose the nvidia Vulkan driver to the container. I’ll file a bug later If I’m right about that.

I haven’t been able to expose the PulseAudio socket from the host to the container yet either and haven’t started looking into how to expose controller/joysticks, which for Steam will also need to be able to update their firmware.

1 Like

Thanks for working on this.

With Pulseaudio, if you share the Unix socket to the container, the socket contains the machineid of the host, which is different to that of the container. Therefore, it is not accepted. You would either replace the machineid, or clear it.

Edit: the X11 socket passes many environment variables to the container. You can view them with xprop -root. In there is the Pulseaudio variable with the machineid.

1 Like

The snaps we are currently using are done by Canonical, made by the same person that work on the deb and tested the same way the equivalents are. Said differently those holding that hard line are not doing it based on reasonable facts but are mostly showing resistance to change (which often seem based on old facts/problems for earlier snap days/misinformation, so there might be a need for more communication around those topics)

“It will run but it will run like s*”
-conanichal

We’re running Ubuntu MATE 18.04 32 bit in 1000+ Greek schools, as 40% of them still have Pentium 4’s, and it’s easier to have the same environment in all of them.
Additionally, we’re using around fifty 32 bit Windows-based educational apps via Wine.

I’m not sure when the percentage of Pentium 4’s will be low enough to switch to 64 bit, but dropping the 32 bit arch won’t really make schools buy new hardware sooner; they do know the hardware is old but many just don’t have enough money to replace it yet.

Of course it’s Canonical’s decision since they pay for everything; the schools that still need 32 bit can switch to Debian (the 5/10 year support of 18.04 means old applications, libreoffice, kde-edu etc, so Debian will be preferred over an old 18.04).

I’m just not sure how much effort is actually involved for maintaining 32 bit (I haven’t seen that many bugs that are specific to 32 bit) or for the bandwidth (if only 1% is using 32bit, then that’s not much bandwidth). I do understand the server space argument though.
So what I wanted to say is, sure, this needs to happen at some point, but if it’s not a lot of cost/effort, then now might be a bit soon; less people will need 32bit after a few years.

4 Likes