Ubuntu 19.10 To Drop 32-bit x86 Packages

[the_scx]

Still does not take resources away from the Ubuntu maintainers which is the issue here, or rather the claimed issue.

It consume resources from Canonical because it uses their infrastructure. But this also proves that resources are not a problem for them.

Developers' time may be a problem when it comes to supporting a port. However:
- Ubuntu is largely based on Debian, especially when it comes to basic packages.
- Debian have no plans to drop support for i386.
- All they have to do is just to rebuild existing packages. Problems here are extremely rare. I can believe that there may be some issues when it comes to more complex software like WebKit or Chromium, but it is not the case here.
- The Freedesktop runtime for Flatpak is maintained by a very small company. And they do everything from scratch.

The "gnome" package for the full Gnome desktop is in Universe, all the other packages that you have mentioned including tuxpaint is not in the packages file that you linked so which are the packages that you mentioned earlier that comes from main?

Again, GNOME Shell, GNOME Games, Gnome To Do, Rhythmbox, Totem, Shotwell, Simple Scan, Transmission Gtk+, BlueZ, etc. come from the main repo.

However all that is just one big straw man because Ubuntu have not said that they could maintain i386 if they dropped some packages for s390x and if they have to support s390x, which they have if they want to keep their paying enterprise customers, then they have to support Main for s390x regardless of which "stupid for s390x" packages it might contain.

As I said, they have a lot of money from x86 desktops, so they should support it properly. This means that they should provide multiarch support.

You cannot seriously argue that they should drop s390x because you might find some offensive packages in Main, that have zero to do with the maintenance costs of i386.

I am not saying that dropping support for s390x will help anything. I just don't believe that there are economic reasons behind their decision about dropping i386. Neither resources, nor developers' time are issues here. It's simple. They just have no f**king idea what they are doing. They thought other distributions were dropping i386, but this is not happening. And they just don't understand what WINE needs.

FYI, openSUSE Leap went to 64-bit only releases several versions ago, but still continues to provide all the 32 bit baselibs needed to build and run Wine. I use it myself without any problems. Unfortunately, based on what the Ubuntu article says, I don't have any confidence that they even understand what Wine needs, let alone plan to provide it.

Yes, I agree. From the FAQ it doesn't seem like they understand Wine's needs.

[the_scx]

But they could add that in... they already have libstdc++ in there

Just because something can be done does not mean that it should be done. And this is a perfect example of it.

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1107050-ubuntu-19-10-to-drop-32-bit-x86-packages?p=1107452#post1107452

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.

This is just a terrible idea.

[Niarbeht]

I think the news means Ubuntu is also going to stop shipping 32-bit compatibility libraries starting with 19.10.

Oh. I, uhh, probably didn't read it carefully enough.

[chithanh]

It is not like they are creating Ubuntu on x86 for free. They have a lot money from paid support and ESM (Extended Security Maintenance).
What's more, they also have money from Snap Store.
This wouldn't be possible if they hadn't been so successful on Linux desktop. By successful I mean that Ubuntu is probably major Linux distribution for the average user.

Whatever money they get from ESM, snap store, etc. is not paid directly by customers who want the i386 port I assume. And I agree that what being successful on the consumer desktop made Ubuntu popular for servers, cloud, and enterprise. And still Ubuntu will be the second most successful desktop distro after Chrome OS even if all Wine/Steam users go away.

Also, please keep in mind that the main Linux distribution used by IBM is not Ubuntu LTS but RHEL/CentOS. This also includes Linux on z Systems. Ubuntu is relatively new here. They didn't even exist on this market until 2015.
We have a similar situation with Linux on Power. Red Hat Enterprise Linux is 1st here, and SUSE Linux Enterprise Server is 2nd. Ubuntu is definitely not the most important here.

How popular Ubuntu is on zSeries/Power has nothing to do with the economic decision of supporting s390/ppc64le. Economic decision means, does the company see sufficient ROI from that.

And I would say that most desktop users or at least a very significant group will come across such software.

In no way that you can look at it that is supported by facts.

Steam (all platforms) has 1 billion accounts, but most of them inactive or one of multiple accounts that belong to a single user. Monthly active users are at 90 million. Linux is around 1% of Steam survey respondents, so let's say 900k.
Global installed base of PCs is 2.2 billion. Installed base of Ubuntu desktop was estimated at 40 million in 2015 (haven't found anything more recent).

So no way that Steam users on PC or Ubuntu exceed 5%.

You don't need to install Ubuntu on bare metal at all. You can run Linux software using WSL on Windows 10. Or you can install a Linux distribution on VirtualBox. It is "just less convenient" method, but no one should complain, right?

I don't see the analogy. Depending on what is the reason why you run Ubuntu, and whether you have a Windows license, running it inside WSL or inside a virtual machine on Windows is an option or not.
But how will the reason for you to run Wine determine whether you use e.g. a Snap or a native package?

What if it will be the vendor developer who lost interest in supporting XWayland? Red Hat can do it on its own, but what about Canonical? Will they do the same or will they not care?
What is worse, no XWayland package in the main repo is much worst than you think. It could lead into dropping support for it from other software, i.e. Gtk+, Qt, SDL, etc. I can't even imagine how the community can handle such a situation. If you already have Gtk+ in the main repo, you wouldn't put an improved version in the contrib repo.

Eh, the whole point of XWayland is to continue running X11 applications in Wayland. There needs not be special XWayland support in GTK+/Qt/... that is the whole point.
And it is not that XWayland is one heavily developed package. The only time it sees major activity is around adding support for new APIs as I already mentioned.

Like it or not, but games are driving the development of WINE. I am not saying that it is focused on games, but they have significant impact on it. Without games, WINE would never gain good support for DirectX. And today, DX is important not only in games, but also in many other software.
Anyway, compatibility with Windows 9x isn't too good, and probably won't be much better, because main development is focused on Windows 7+ now.

No. Neither Wine nor its sister project ReactOS (which whom significant code sharing happens) development is "driven" by games.
What is true that major parts of getting games to work has already been done, and the work of Valve/Proton is just pushing particular fixes that prevent games from running, not implement entirely new functionality (with few exceptions).

It isn't entirely true. Win16 software is still well supported in Windows 10. You just need to run Windows 3.11 inside virtual machine. Right?
But to be honest, almost no one care about Win16 software anymore, so there is no reason to support it. And if you want to run some DOS games, you can use DOSBox. End of story.

When Linux was dropping modify_ldt() syscall which Wine depends on for running Win16 protected mode software on x86_64, it was Wine developers and users who objected. Precisely because running Win16 software on 64-bit Linux is still a major use case for Wine users.

And yes, running Win16 protected mode software through emulation (as already happens for v86 mode software) or in a VM has been suggested in that very LKML thread, but such talk was quickly shut down by Linus.

[chithanh]

- Ubuntu is largely based on Debian, especially when it comes to basic packages.

Ok, I think this reveals a major misunderstanding what Ubuntu is and does on top of Debian.

Ubuntu does maintain their own complete infrastructure and does their own QA on the packages, expending considerable resources. Yes, these packages originally come from Debian. But Ubuntu is not like LMDE/Siduction/Aptosid/etc. which are basically lightly repackaged+reskinned Debian.

[oiaohm]

This is just a terrible idea.

No its not as bad of idea as you are making out. Mesa/open source graphics drivers newest versions of libraries work perfectly with older versions of drivers so flatpak only need to ship 1 version of those being the current version per runtime at worst. The host can be using what ever open source graphics drivers it likes and it makes absolutely no issue because open source graphics driver also support programs using different versions of the userspace at the same time. This all comes from obeying Linux kernel policy to never break user space. Please note this policy does cover 2 programs attempting to use 2 different versions of a userspace interface library at the same time.

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.

VIA, S3G and Zhaoxin is like Mesa open source drivers. You only need the userspace new enough to support the card you have. If your kernel is running older kernel space driver the newer userspace libraries work anyhow. If 2 programs are running at the same time using two different userspace versions it works anyhow as well. Yes AMDPRO drivers are the same. So this lot is also only need to ship current version just like the open source drivers.

Heck even the arm gpus closed stuff support using multi versions of the userspace libraries at the same time. Notice a trend yet.

NVidia is the bastard party by self that you must use userspace libraries matching the kernel space drivers or it has major trouble. Don't even consider with Nvidia running two programs using two different versions of it userspace.

NVidia is truly the odd vendor out on Linux native graphics support. Nvidia the only one where flatpak have to provide basically every single version of the userspace libraries to be sure that you have a userspace libraries that match the host kernel driver. Yes Nvidia is the only one I know of where the userspace and the kernel mode driver version have to match in the Linux graphics landscape. Everyone else making graphics drivers obeys the Linux rule of maintain api compatibility at the kernel boundary. It would be great if Nvidia came into line on this point.

Please note NVidia license is also a ass. NVidia binary license allows you to install Nvidia drivers but it does not exactly allow you to copy. So legally flatpak in some countries cannot go copy the host installed NVidia libraries either so has to ship flatpaks of them. In this case with Ubuntu this is a good thing since this means Flatpak runtime are totally independent to host. As long as Ubuntu does not kill off Linux kernel 32 bit syscalls flatpak will work for 32 bit applications. Snap packages containign32 bit would die as well.

Nvidia is not in conformance with Linux kernel policy this is why flatpak has to provide as many flatpaks for Nvidia. All the other GPU drivers I know made for Linux are made in conformance with Linux kernel policy.

In some ways Ubuntu should just make it possible to make 32 bit snap packages using debian or flatpak runtimes as base. Lets be truthful a lot of the older 32 bit game binaries are not being updated for security faults so being sandboxed would not be a bad thing.

[oiaohm]

So, running win16 on Wine is a major use case there, but we should drop win32 on Wine now? Aren't you going against your own position?

What you said just contributes to the position that backward compatibility is important, therefore Ubuntu shouldn't drop i386 libs.

modify_ldt() looking at returning to qemu/vm was considered serous-ally by the wine project if the problem would not be fixed. Hangover is another wine usage developed depending on qemu. Completely out hangover should run 16 and 32 windows applications.

v86 mode software is what wine puts out to dosbox. Wine project is not past using emulators where it suits so it keeps on working. Loss of vm86/v86 caused wine about year and a half of disruptions until dos applications windows applications called were working perfectly again. My problem with Ubuntu going 64 bit only is short notice wine project has to change. This normally needs about 2 years for a big change like this for the wine project to get everything in order.

[F.Ultra]

The point of the example packages given, like 'cheese', is that Ubuntu cared for the desktop users, even when their users' needs were frivolous, at least in the past. Ubuntu is not intended to be a serious server-only distribution, despite those customers' deep pockets.

It's a rebuttal to this argument, which was lingering through:

Ok, I can get behind that. And just to clarify, I am against this decision 100% just as you and the_scx are , couldn't just compute the logic about complaining about some desktop packages :-)

[bridgman]

Something seems really wierd here... Steve's post is mostly about dropping support for i386 (which seems OK at first glance) but it's not clear how that translates into dropping support for 32-bit userspace on x64 CPUs.

Wondering if this is more of a typo/thinko that is getting out of control than an actual Canonical decision to drop 32-bit userspace ?

[Weasel]

Something seems really wierd here... Steve's post is mostly about dropping support for i386 (which seems OK at first glance) but it's not clear how that translates into dropping support for 32-bit userspace on x64 CPUs.

It's simple. No i386 libraries = 32-bit apps won't load.