Ubuntu 19.10 To Drop 32-bit x86 Packages

[the_scx]

They know very well, and came to the conclusion that their limited resources and developer time are better spent improving the distro elsewhere, rather than maintaining i386 support.

They have time and resources for supporting PPC64LE and s390x on desktop, but they are unable to provide backward compatibility with 32-bit software on x86-64? Sorry, but this is bullshit.

This should never have happened, instead Steam should have shipped a 64-bit client and insisted on all Linux games being 64-bit right from the start.

Reading this, I come to the conclusion that they should not start it at all, because Linux users do not care about backward compatibility at all.
In a few years there will be the same problem with PulseAudio or X11, while Windows users will still be able to use software for Windows 95 or XP... on the current Windows version.

[the_scx]

A lot of complaining about this, but no suggestions as to how to phase out i386 in a better way.

The solution is very simple: just keep support for multiarch/multilib. That's it. They have time and resources to support PPC64LE and s390x on desktop, so they must have time for this too.

The reality is that i386 needed to be phased out sooner or later and the only thing achieved by putting it off is to increase the amount of i386 and i386-reliant software out there to cause issues when the inevitable architecture drop has to be gone trough with.

The reality is that they never have to drop it.
IBM System i for minicomputers can provide several decades of compatibility.
Windows 10 provides excellent compatibility with Windows 7, very good with Windows XP and good enough with Windows 95. Why Linux can't?
As long as Windows will be the dominant system on the desktop and the software for Windows 95-10 will be in use, no one should even think about dropping support for 32-bit software in Linux.

[starshipeleven]

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

Enlighten us on how are we supposed to run random old console and DOS or OS/2 software then. You don't convert shit, you need to get some form of emulator (or full OS, like FreeDOS) going that simulates the original environment the software was supposed to run in.

Just as to read an old VHS tape you need a suitable reader, which is a complex piece of machinery in its own right to build without a factory. That's the analogy you tool.

[starshipeleven]

Windows 10 provides excellent compatibility with Windows 7, very good with Windows XP and good enough with Windows 95.

You skipped a version.

A LOT of software for XP runs like shit if at all on Win10, most of Win95 software does not run at all because 16bit or other reasons, Windows 7 is not really that close but "very good" is ok for it.

The only OS that has excellent compatibility with Win10 is Win8.1, as Win10 is basically a reskin of 8.1 anyway.

Why Linux can't?

Why should Linux maintain compatibility with old windows software anyway.

[starshipeleven]

They have time and resources for supporting PPC64LE and s390x on desktop,

Their Ubuntu Server has to run on IBM mainframes. Just saying.

Reading this, I come to the conclusion that they should not start it at all, because Linux users do not care about backward compatibility at all.

You are mixing retrocompatibility with "support for old Windows crap".

Opensource software did not come in 32bit-only form since a long time, the only reason you might want 32bit is for old Windows crap.

In a few years there will be the same problem with PulseAudio or X11,

You know right that PipeWire (Pulse successor)has a layer to allow retro-compatibility with Pulse, and that there is a thing called Xwayland to run legacy applications with?

[chithanh]

They have time and resources for supporting PPC64LE and s390x on desktop, but they are unable to provide backward compatibility with 32-bit software on x86-64? Sorry, but this is bullshit.

It is an economic decision. I imagine that there are big paying customers who want those ports. For x86, you would be hard pressed to find paying customers.

In a few years there will be the same problem with PulseAudio or X11,

If they had wisely used SDL (as is the norm I think), PulseAudio API would not concern them. X11 is still supported in Wayland via XWayland.

while Windows users will still be able to use software for Windows 95 or XP... on the current Windows version.

Actually, Wine offers even compatibility going back much further than Windows 10. You can run 16-bit protected mode Windows 3.x software on 64-bit Wine (through modify_ldt syscall). That is not possible on Windows x64 (though it might become if WSL starts supporting modify_ldt).

[Dedale]

Why should Linux maintain compatibility with old windows software anyway.

Because some users care. That's why stuff like WINE exists in the first place.

[starshipeleven]

Because some users care. That's why stuff like WINE exists in the first place.

Apparently those users aren't paying the bills for Canonical.

Also no, Wine exists because there is a commercial software called CrossOver that is mostly funding the development. It is also mostly used by MacOS users, which is one of the reasons why they did refuse to merge some contributions that would have been good for Linux but bad or useless for MacOS.

[starshipeleven]

I just checked the libraries in my Linux Mint 19 install.

They are talking of packages in the whole repo, not just in your own specific install.

[the_scx]

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

No, you are wrong, they don't provide glibc or any other libc library.

https://pastebin.com/raw/F7RVqBbx

I don't see why they could not drop a full OpenGL or whatever else in there if they feel like it.

Because it would be the same mess that is already in Flatpak. They will have to support every single GPU driver. By that I mean every single version of the GPU driver, e.g. NVIDIA 304.134 (32-bit), NVIDIA 304.134 (64-bit), NVIDIA 304.135 (32-bit), NVIDIA 304.135 (64-bit), NVIDIA 340.101 (32-bit), NVIDIA 340.101 (64-bit), NVIDIA 340.102 (32-bit), NVIDIA 340.102 (64-bit), NVIDIA 340.104 (32-bit), NVIDIA 340.104 (64-bit), NVIDIA 340.106 (32-bit), NVIDIA 340.106 (64-bit), NVIDIA 367.57 (32-bit), NVIDIA 367.57 (64-bit), NVIDIA 370.28 (32-bit), NVIDIA 370.28 (64-bit), NVIDIA 375.26 (32-bit), NVIDIA 375.26 (64-bit), NVIDIA 375.39 (32-bit), NVIDIA 375.39 (64-bit), NVIDIA 375.66 (32-bit), NVIDIA 375.66 (64-bit), NVIDIA 375.82 (32-bit), NVIDIA 375.82 (64-bit), NVIDIA 378.13 (32-bit), NVIDIA 378.13 (64-bit), NVIDIA 381.09 (32-bit), NVIDIA 381.09 (64-bit), NVIDIA 381.22 (32-bit), NVIDIA 381.22 (64-bit), NVIDIA 384.47 (32-bit), NVIDIA 384.47 (64-bit), NVIDIA 384.59 (32-bit), NVIDIA 384.59 (64-bit), NVIDIA 384.69 (32-bit), NVIDIA 384.69 (64-bit), NVIDIA 384.90 (32-bit), NVIDIA 384.90 (64-bit), NVIDIA 384.98 (32-bit), NVIDIA 384.98 (64-bit), NVIDIA 384.111 (32-bit), NVIDIA 384.111 (64-bit), NVIDIA 384.130 (32-bit), NVIDIA 384.130 (64-bit), NVIDIA 387.12 (32-bit), NVIDIA 387.12 (64-bit), NVIDIA 387.22 (32-bit), NVIDIA 387.22 (64-bit), NVIDIA 387.34 (32-bit), NVIDIA 387.34 (64-bit), NVIDIA 390.12 (32-bit), NVIDIA 390.12 (64-bit), NVIDIA 390.25 (32-bit), NVIDIA 390.25 (64-bit), NVIDIA 390.42 (32-bit), NVIDIA 390.42 (64-bit), NVIDIA 390.48 (32-bit), NVIDIA 390.48 (64-bit), NVIDIA 390.59 (32-bit), NVIDIA 390.59 (64-bit), NVIDIA 396.24 (32-bit), NVIDIA 396.24 (64-bit), ..., NVIDIA 430.26 (32-bit), NVIDIA 430.26 (64-bit). The userspace driver version have to match the kernel driver version. Multiply it by every GPU vendor, including less known ones, such as VIA/S3G/Zhaoxin.

And they will also have to care about glibc. Maybe at some point they will develop a solution similar to Flatpak or Snap, with their own runtime.

https://www.gamingonlinux.com/articles/valve-are-looking-towards-flatpak-functionality-for-steam.8582

Not quite; we're looking at some of the underlying technology to see if it would be a good fit to improve the Steam runtime environment interactions with the host system. If we went forward with it, we would be using some of the same kernel functionality Flatpak/bubblewrap is, and hopefully reusing some core code, but we have no plans to change the cross-platform distribution and packaging method at the core of Steam.

BTW, see also:

https://git.collabora.com/cgit/user/vivek/libcapsule.git/tree/README

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)

It is not perfect, but it is the best solution for Linux ever created. It is a lot better than GOG, not even mention Humble Bundle and others.

https://github.com/flathub/flathub/pull/486#issuecomment-405826821

GOG clearly states on their website that only Ubuntu is supported and even the release differs between particular games. Humble Bundle is even more trigger happy and I had even less luck with few games I bought there. Not to mention that some are 32-bit only, making it even harder to make everything work. All this results in bad user experience, especially for players with no technical Linux background and I can't see Gamehub being any different.

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

No need to hate every decision they have made. At least Snap is a superior solution compared to Flatpak. And Ubuntu Core for IoT looks promising.