Ubuntu 19.10 To Drop 32-bit x86 Packages

[the_scx]

Well, supporting a 34-year-old architecture on a mainline desktop OS probably doesn't make much sense. And people running 32-bit x86 hardware still have Linux distro options such as Debian/i386. I grew increasingly frustrated trying to keep an old Athlon XP box running in the basement (nice space heater) when "i386" binaries would nevertheless expect SSE2 support (how is that not an i686 binary?!) etc.

Again, it is not about supporting 32-bit hardware. It is about supporting 32-bit software!

[the_scx]

There's a difference between a 32-bit OS and having multilib support. They aren't going to stop shipping 32-bit compatibility libraries, but they are going to stop shipping an operating system that can boot on a Pentium 3.

But this is exactly about dropping support for 32-bit software. And yes, it includes multilib support too.

[the_scx]

I'm all for that, otherwise Steam on Linux will stay 32bit for the next 20 years.

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.

[starshipeleven]

It won't help, because you still need a 32-bit version of at least glibc and OpenGL/Vulkan libs. The Steam Runtime doesn't provide it and never will be, because it is out of the scope of this solution.

The steam runtime does provide glibc afaik and that's one of the cause of issues (you usually need to nuke it manually along with other crap they drop in there). I don't see why they could not drop a full OpenGL or whatever else in there if they feel like it.

The main point here is that Steam's way of delivering software is completely unsustainable and break-prone bullshit and I'm all for sending a strong message about not accepting it anymore (as Ubuntu was the only "officially supported" distro for Steam, apart from SteamOS)

Also I hate Canonical so I always automatically approve any decision that causes them to be flamed.

[the_scx]

What is going to happen is these 32bit apps will be bundling their own "mini distro" with all required 32bit libraries as snap/flatpak/etc with EVERY app ...

As I said, Flatpak has the worst multilib solution ever created. It is impossible to build 32-bit deps in 64-bit packages. The best you can do in such a situation is to provide pre-compiled binaries. But to do this you need a system with support for 32-bit binaries, so you can forget about flatpaking mixed 32-/64-bit software (such as Steam, WINE, PlayOnLinux/Phoenicis, Lutris, etc.) on Ubuntu 19.10+.

https://github.com/flatpak/freedesktop-sdk-images/issues/101

Today, to do this, you can simply use an another distribution. Even Ubuntu 18.04 LTS will be fine. But how will it look like in 5-10 years? Many people think that 32-bit software is just outdated. It's not. WINE and related software (VK9, DXVK, VKD3D) is constantly developed. It will require more recent compilers, OpenGL/Vulkan libraries, Mono, Gecko (maybe Chromium at same point?), etc. Within time, it will be increasingly difficult to build this on the old distribution, just like it is already hard to provide new packages for Ubuntu 14.04 LTS or CentOS 6.

So, in next 10 years, Microsoft will support 32-bit software flawless, while in Ubuntu it will be a pain in the ass. Another chance for the year of Linux (on the desktop) wasted.

[starshipeleven]

It is not about supporting ancient hardware. It is about supporting software like Steam, WINE, Proton, PlayOnLinux/Phoenicis, Lutris, etc. - mainly a lot of games and Windows software.

They just need to ship their own 32bit libraries too. As long as the kernel does indeed still have the 32bit application support (there is a config about that I think, to allow the use of 32bit application with a 64bit kernel) it's going to be fine.

It's just a slight nudge towards modern packaging systems like snap and flatpak that allow you to deal with it

[jpg44]

This is a very stupid decision. The big problem is some commercial programs may need the 32 bit toolchain to run, some drivers still do. It can be a big issue for binaries and driver sort of things that need a supporting toolchain to run still.

Dropping images was a bad thing to considering linux really shines on old hardware that has been dumped by Microsoft so this is a prime market for Linux to allow older hardware to be re-used and rehabilitated.

Netbooks are perfectly fine and many of them just a few years ago with 32 bit. Not everyone has a bunch of cash in their pocket to just run out and buy new hardware whenever these idiots decide at a whim to just drop support for old hardware. Its a very stupid thing because I dont know how many times these people have been told that people using old hardware often want to use Linux. You have some old hardware that works, why not use it?

So its all very stupid and very hostile and arrogant towards the users.

[Weasel]

Also, dropping support for MP3 files really doesn't work at all as analogy as it doesn't cause any duplication of effort, wasted disc space or performance loss.

Duplication of effort? Sure, because the mp3 decoding isn't even duplicated, it's literally extra effort.

Wasted disc space: again, the mp3 decoding is code which requires disk space.

Performance loss: this doesn't apply in either case.

Complaining about dropping i386 is more like the people who complained about VHS cassette players going away, vinyl records and tapes being replaced CDs or when CDs went away in favor of digital music without optical media.

Actually no, this is the dumbest analogy I keep reading online. Software is data, just like movies. The medium it is stored in is irrelevant. I want to watch a movie from 1990s, say Terminator 2. I can do that, on a standard install. Easy. It doesn't have to be on a DVD, I can archive it on a USB stick, hard drive, or whatever is "modern". I don't give a shit about the original CD installers for old games. Those yes, are like VHS or whatever, since they're medium. I talk about the software itself, the data that you archive.

Software is the same thing.

[Weasel]

Actually, archival of documents, movies, etc. is a very hard problem. Not only you need the hardware around that can read the media, but also the software that can decode the formats. This is why long-term archival always relies on vendor neutral open standards.

For software, the programs that are going to work potentially indefinitely are FOSS. Proprietary software will stop working at some point, sooner or later.

I don't think there's a movie format that used to be widespread that ffmpeg can't read, so you're wrong. Either way, patents expire. mp3 is free already. And guess what? It's still "readable".

[Weasel]

Some security problems cannot simply be patched. When the Spectre flaw was disclosed, 32-bit x86 remained vulnerable for a long time until something was worked out.

That was for 32-bit kernels. Facepalm.