Ubuntu 19.10 To Drop 32-bit x86 Packages

[Weasel]

Enlighten me, how can I play a movie from 1922 using the original tape it was recorded on on my laptop? Do I just open up the casing of my laptop and jam the movie in it or...?

Nobody cares about the hardware storage medium. Convert it to digital and archive the data. Software is data not a storage medium.

[Weasel]

You want to sacrifice most of the Linux games just because you would like to use a 64-bit version of the Steam client?! Why do you even need this?! Does it consume more than 2 GB of RAM? Does it extensively use 64-bit integers? Just tell me why?!
Valve could provide a 64-bit client a long time ago. They didn't do it because they couldn't, but because they knew how it would end - dropping support for 32-bit software in a various Linux distributions. Unfortunately, even Steam and WINE didn't stop Ubuntu developers from making an extremely idiotic decision.

You are one of the few sane people in this thread (and xfcemint).

Other morons who keep mixing up hardware with software make me cringe.

[chroma]

Other morons who keep mixing up hardware with software make me cringe.

I would suppose most people in the FOSS OS community assume software is code you compile for your architecture. But yes, in cases where you want to run binaries compiled for another architecture, you'll need to find ways to accommodate that legacy object code.

"While this means we will not provide 32-bit builds of new upstream versions of libraries, there are a number of ways that 32-bit applications can continue to be made available to users of later Ubuntu releases ... We will be working to polish the 32-bit support story over the course of the 19.10 development cycle."

I think people should probably take a wait-and-see approach given this suggestion 32-bit support may still exist in a form suitable for certain niche cases.

[Dedale]

Now i am confused. So i must understand it is not only the 32 bits CPUs they are dropping but the 32 bits software !? That is beyond insane. That make me think they are slowly abandoning the desktop by reducing the dev resources allocated to it.

Casual Linux users and in particular gamers will have to find another reasonably user friendly distro (i.e. not debian). If this is true it is going to cause a mess and boost fragmentation. There are commercial softs that run only on ubuntu. For a casual user it will be a nightmare.

What are going to do GOG, steam, humble and itch.io. ? How will the legacy soft work on modern computers !?

[calc]

Canonical appears to have been under the mistaken impression that they aren't the first to drop 32-bit support.

From the discourse QA:

Many other Linux distributions have already moved to 64-bit only.

However when asked which distributions they didn't respond.

I suspect they thought that RHEL had dropped 32-bit entirely, without actually bothering to check, which is not the case. RHEL 7 dropped installing on 32-bit hardware but still ships a full set of 32-bit libraries even on RHEL 8.

[the_scx]

Modern games are mostly 64-bit.. Valve even recommends it https://partner.steamgames.com/doc/s...tion/platforms

This is not true for Windows indie games. We still have a lot of PE32 executables here. However, I can agree that a lot of modern non-indie Linux games are 64-bit.
Anyway, tell me why people should forget about games from 5-10 years ago? How would you react if someone on a movie forum said that all films that were not created in at least native 4K@60Hz should be forgotten? Let's say that Citizen Kane (1941), Ivan the Terrible (1944), 2001: A Space Odyssey (1968), The Godfather (1972), Alien (1979), Back To The Future (1985), Terminator 2: Judgment Day (1991), Jurassic Park (1993), Léon: The Professional (1994), Stargate (1994), Contact (1997), The Matrix (1999), Donnie Darko (2001) are outdated craps. Insane, right? So why the hell we need to already drop a support for games from the middle of this decade?! They are goods of culture too. It doesn't make any sense!

Nvidia ended support for 32-bit - https://nvidia.custhelp.com/app/answ...ail/a_id/4604/

It is about dropping support for 32-bit systems. The 32-bit OpenGL driver are still supported on 64-bit systems. The same applies to the Vulkan driver.

https://pastebin.com/raw/kP17jqA1

# yum -q --disableplugin='priorities' --enablerepo='elrepo' info nvidia-x11-drv-libs.i686 2>/dev/null
Available Packages
Name        : nvidia-x11-drv-libs
Arch        : i686
Version     : 430.26
Release     : 1.el7_6.elrepo
Size        : 44 M
Repo        : elrepo
Summary     : Libraries for the Proprietary NVIDIA driver
URL         : http://www.nvidia.com/
License     : Distributable
Description : This package provides libraries for the Proprietary NVIDIA driver.

https://pastebin.com/raw/7KA2cJEK

# rpm -ql nvidia-x11-drv-libs.i686
/usr/lib/libEGL_nvidia.so.0
/usr/lib/libEGL_nvidia.so.418.74
/usr/lib/libGLESv1_CM_nvidia.so.1
/usr/lib/libGLESv1_CM_nvidia.so.418.74
/usr/lib/libGLESv2_nvidia.so.2
/usr/lib/libGLESv2_nvidia.so.418.74
/usr/lib/libGLX_indirect.so.0
/usr/lib/libGLX_nvidia.so.0
/usr/lib/libGLX_nvidia.so.418.74
/usr/lib/libOpenCL.so
/usr/lib/libOpenCL.so.1
/usr/lib/libOpenCL.so.1.0.0
/usr/lib/libcuda.so
/usr/lib/libcuda.so.1
/usr/lib/libcuda.so.418.74
/usr/lib/libnvcuvid.so
/usr/lib/libnvcuvid.so.1
/usr/lib/libnvcuvid.so.418.74
/usr/lib/libnvidia-compiler.so.418.74
/usr/lib/libnvidia-eglcore.so.418.74
/usr/lib/libnvidia-encode.so
/usr/lib/libnvidia-encode.so.1
/usr/lib/libnvidia-encode.so.418.74
/usr/lib/libnvidia-fatbinaryloader.so.418.74
/usr/lib/libnvidia-fbc.so
/usr/lib/libnvidia-fbc.so.1
/usr/lib/libnvidia-fbc.so.418.74
/usr/lib/libnvidia-glcore.so.418.74
/usr/lib/libnvidia-glsi.so.418.74
/usr/lib/libnvidia-glvkspirv.so.418.74
/usr/lib/libnvidia-ifr.so
/usr/lib/libnvidia-ifr.so.1
/usr/lib/libnvidia-ifr.so.418.74
/usr/lib/libnvidia-ml.so
/usr/lib/libnvidia-ml.so.1
/usr/lib/libnvidia-ml.so.418.74
/usr/lib/libnvidia-opencl.so.1
/usr/lib/libnvidia-opencl.so.418.74
/usr/lib/libnvidia-opticalflow.so
/usr/lib/libnvidia-opticalflow.so.1
/usr/lib/libnvidia-opticalflow.so.418.74
/usr/lib/libnvidia-ptxjitcompiler.so.1
/usr/lib/libnvidia-ptxjitcompiler.so.418.74
/usr/lib/libnvidia-tls.so.418.74
/usr/lib/vdpau/libvdpau_nvidia.so.1
/usr/lib/vdpau/libvdpau_nvidia.so.418.74

Regardless what we did for Ubuntu, we'd be running into these issues. IMHO Valve should have only supported 64-bit when they launched for Ubuntu in 2012. That would have been a much better long-term play.

That would mean not support for Proton at all. I doubt if this is a better way. Moreover, it would prevent some Windows ports from being created.

[the_scx]

This is less required than you would think. emugl from android and virtgl work both don't care if you only have 64 bit opengl hardware support.

They doesn't care either about driver quality and performance...
It doesn't support Vulkan at all (although they are trying to get it), and OpenGL is supported only up to 4.3. The overall driver quality is even worse than Nouveau.

https://web.archive.org/web/20190619191659/https://mesamatrix.net/

And performance is just terrible.

https://www.phoronix.com/scan.php?page=news_item&px=Virgil-3D-F24-Beta-Tests

To be honest, they have made significant progress since that time, but it is still not suitable from gamers.

So, could you just stop trolling and publishing nonsense? Thanks in advance.

[the_scx]

Also, don't confuse Ubuntu dropping 32 bit support with Wine dropping 32 bit support. Wine builds Ubuntu packages (https://wiki.winehq.org/Ubuntu), not Ubuntu.

Canonical creates WINE packages for Ubuntu. And to create them properly, they need 32-bit versions of at least glibc and GPU drivers (OpenGL, Vulkan, etc.).

See also:

https://www.phoronix.com/forums/forum/software/distributions/1023893-ubuntu-developers-once-again-debate-dropping-i386-images-then-discontinuing-i386-port?p=1024120#post1024120

[starshipeleven]

Actually no, this is the dumbest analogy I keep reading online. Software is data, just like movies.

No it is not. Yes it is data but the issue is the amount of stuff you need to actually run it.

A movie or a media is more or less self-sufficient with minimal dependencies, as the software interface you use to read it (the decoders) never change. MPEG2 encoding remains the same and any MPEG2 decoder will be able to deal with any MPEG2-encoded file.


Any remotely complex software on the other hand relies on A LOT of other random shit to work. Libraries, OS API, CPU architecture, instructions or endianness (for ASM optimizations for example).

To run a software you need to re-create and maintain a much more complex environment than just find a suitable decoder for a binary media format.

Which is why we had a bunch of fads about Java, then webapps, then crossplatform frameworks. They all promise(d) a stable and more manageable environment and dependencies, with varying levels of actual capability of delivering on their promises of course (Java for example failed spectacularly).

[the_scx]

Keeping i686 around has just made things way harder than they needed to be. Just look at this thread, this is what happens when you ship 32bit software way past its time.

No, removing support for 32-bit software (multiarch/multilib) is making things harder than they needed to be.

Steam really screwed the pooch by shipping as 32bit. Now we are stuck with 32bit game binaries that well never be changed or updated. Who even at the time it released was using a 32bit OS? and if you were, I bet the CPU was still 64bit anyway. Before steam the only real holdback was Wine and printers, thanks Valve.

You have no idea what you're talking about. They have provided 64-bit SDK and Steam Runtime for years! Giving up of the 32-bit version at the beginning would only result in fewer Windows ports, because they were 32-bit only at that time.

There will always be someone in Linux who says that something is outdated and you should drop it. In a few years, we may have such a problem with applications using Gtk+2, OpenGL, PulseAudio or X11. That's why the year of Linux (on the desktop) will never happen.