Ubuntu 19.10 To Drop 32-bit x86 Packages

[oiaohm]

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.

As you said performance has improved a lot since then. https://www.phoronix.com/scan.php?pa...Transfer-Queue

Virgl is working on vulkan support and it should have lower overhead.

[chithanh]

So you are saying that open source games on mainframes are more important than at least minimal multilib/multiarch support on x86-64 desktops?

What, where did you get that "more important" from? Certainly not me. What I'm saying why there is s390/ppc64le support is summarized best as:

the amount of extra work going from 0 to 1 i386 libraries is much more than for going from 1 to 100.

Their Ubuntu Server has to run on IBM mainframes.

there are big paying customers

So the brunt of the work has already been done for the paying customers. Flipping on ppc64le support for more packages isn't hard once the port exists.

If they don't have time to support Linux desktop properly (that includes support for multiarch/multilib) because they are currently focuses on servers, clouds and IoT solution, it is fine. They can say that they are not interested in Linux desktop anymore

I'd say that running 32-bit proprietary applications on a desktop really is a small minority use case. And there are ways to still make them work, just less convenient. I don't see how you can reach from "drop support for i386 from system libraries" to "not interested in Linux desktop anymore".

As I said, what now happens to multiarch/multilib, in a few years can also affect XWayland.

Maintaining XWayland, which is a single package, is not at all comparable work to maintaining an entire architecture port. It would need an update if Wayland protocol or related APIs change in an incompatible way (next opportunity would be the GBM/EGLStreams/UNIX device memory allocator thing). And even if Ubuntu developers lose interest, they can still move the package to universe and let the community do that work.

The reality is that WINE support for Windows 9x software and DirectX 1-8 is crap. You have a better chance to run patched game for Windows XP while using dgVoodoo 2 on a DVXK setup, than trying to run the original game in Windows 98 mode.

You have to distinguish here between general software, and the special breed of software that is games. Before Proton, even modern games were much more of a hit-and-miss with Wine. After Valve started pouring development resources into making those work the situation started improving considerably.

When it comes to general Win16 and early Win32 software, the support is actually pretty good. In case of Win16, infinitely better than Windows itself, which does not support those at all in x64.

[the_scx]

The only resource that Universe consumes for Canonical is the hosting of the files. That is all Canonical offers for Universe; storage and bandwith.

It is simple not true. They are sharing the whole infrastructure, including build servers.

And btw Gnome is also part of Universe and so is probably every single piece of software that you are upset that they "support" on s390x.

No, it is not. All packages I mentioned earlier comes from the main repository.

http://ftp.tu-chemnitz.de/pub/linux/ubuntu-ports/dists/bionic/main/binary-s390x/Packages.xz

https://pastebin.com/raw/MdYYg7A9

Yes that might be difficult to accept but packages such as Gnome is not officially supported by Canonical.

This might be difficult to accept, but you are wrong.

[F.Ultra]

But it still consumes some resources.

The only resource that Universe consumes for Canonical is the hosting of the files. That is all Canonical offers for Universe; storage and bandwith. And btw Gnome is also part of Universe and so is probably every single piece of software that you are upset that they "support" on s390x.

Yes that might be difficult to accept but packages such as Gnome is not officially supported by Canonical. This means that they can offer some support for say amd64 where people are using Gnome extensively while they can just ignore it for s390x but still have the package available on a "don't call us if it breaks" kind of support.

[the_scx]

All the packages that you link to are from the Universe repository which are "Community-maintained free and open-source software" so that is not packages that any Ubuntu developer put time and resources into. It's just that since they already have Main for s390x they might as well let the community at large maintain a Universe repository for the arch.

But it still consumes some resources. Anyway, the point is that they claim they don't have time and resources for even minimal support for x86-32 multiarch on x86-64, but on the other hand they fully support PPC64LE and s390s when it comes to desktop software, where the first one is extremely unpopular in such applications and the second one doesn't exist here at all.
Why the hell admins would need GNOME Shell, GNOME Games, Gnome To Do, Rhythmbox, Totem, Shotwell, Simple Scan, Transmission Gtk+, BlueZ, etc. on the f**king mainframes? All this software is maintained by Ubuntu developers. And it doesn't have any sense. But they support it, and at the same time they say that they are unable to properly support x86 desktops (x86-64 with multiarch). It is ridiculous!

While Windows 95 was a 32-bit operating system there was a shit ton of 16-bit software for it, I know because I worked on some of them. Yes they where 16-bit due to them being originally Windows 3.1 software that where just redressed but they did exist and they did exist in droves.

So today we have "a shit ton" of 32-bit software for Ubuntu 18.04/19.04 (thousands of games and applications), and Ubuntu 19.10 is going to drop support for it for literally no reason.

Regarding your multimedia card driver however I have to ask how exactly you accomplished that feat? Windows 10 contains a 100% different driver model than prior versions so none of the API:s used by a Windows XP driver exists in Windows 10 (aka Windows 10 is not ABI compatible with older drivers).

The only issue I came across here was with the driver signing enforcement, but it is easy to disable it.
It seems to me that the main changes were introduced in the graphic driver architecture. WDDM (Windows Display Driver Model) was introduced in Windows Vista and WDDM 2 was introduced in Windows 10. However, it didn't affect other drivers so much.
Of course, I am not saying that all drivers for Windows 2k/XP/2k3 or Vista/7 will work on Windows 10 (especially the first ones, because a lot of them were 32-bit only), but there are chances that some of them will be fine with the new system.

[F.Ultra]

I read this answer as: it is actually possible for Universe to provide full i386 libraries support, but it is a lot of work (so, unlikely to happen).

Well so far we have 141 comments in this thread and not a single one with "hey I'll maintain a complete i386 environment for Ubuntu 19.10". But then we are not 100% sure that they will drop i386 support completely yet, AFAIK this is still just one dev from Ubuntu voicing that this is their plan. This is how things are done, plans are shown, comments are collected and plans are revised. Of course there is no guarantee that the plans will be revised, only time will tell.

I don't think that Canonical are planing to loose every Steam and Wine user though so I'm still confident that we will see some form of solution here.

[F.Ultra]

Interesting...
I don't quite get it... why can't Universe provide x86-32 mode libraries? Why would it matter whether they were provided by Main or Universe?

Perhaps Universe would then have to sync the x86-32 libs with the kernel releases, so if a user selects an x86-32 package, he would be prevented from updating the kernel untill appropriate x86-32 libs were available? So the latest kernel would be unavailable for users of x86-32, perhaps? Ok, but this won't happen with all x86-32 packages, just those that require problematic libraries, like drivers. So I guess at least the userspace driver libs for x86-32 have to be provided by the Main alongside the kernel.

Also about Windows compatibility: Generally, backwards compatibility is good. Also, newest Windows still ships with x86-32 libs, and even the ARM version ships with x86-32 libs and an emulator, for perfect application integration.
https://docs.microsoft.com/en-us/win...ng/apps-on-arm

Because Main supplies everything that you need like a libc, gcc, complete toolchain and so on, so without a Main you cannot even start to build software for a Universe. What they would have to do then is to let the community take over Main as well for i386 (aka turn Main i386 into a 100% Universe) and AFAIK there is nothing stopping anyone from taking up that responsibility right now and create their own i386 repository for Ubuntu 19.10 and let people add it just like a PPA.

That is a hell of a lot of work though.

[F.Ultra]

No, I just mentioned the most important ones.


I had no problem with any program for Windows 7 on Windows 10. I didn't say that Win10 is 100% compatible with Win7, but the fact is that it is extremely hard to find something that doesn't work.
I have some tools for Windows NT 5.x and they work perfectly on Windows Vista-10. What is more, on Windows 10 I was able to install a multimedia card driver that was created for Windows XP. In the Linux world, such a situation would be impossible. Even a minor release can brake kABI compatibility and the major release will do this for sure.
Windows 95 was a 32-bit operating system so native apps for it were 32-bit too. You probably meant applications for Windows 3.11, which could be used in Windows 95, but this is something completely different. And yes, I was able to run some of Win9x-era GUI apps on Windows Vista-10.

While Windows 95 was a 32-bit operating system there was a shit ton of 16-bit software for it, I know because I worked on some of them. Yes they where 16-bit due to them being originally Windows 3.1 software that where just redressed but they did exist and they did exist in droves.

Regarding your multimedia card driver however I have to ask how exactly you accomplished that feat? Windows 10 contains a 100% different driver model than prior versions so none of the API:s used by a Windows XP driver exists in Windows 10 (aka Windows 10 is not ABI compatible with older drivers).

[F.Ultra]

And that's why they need the full GNOME environment with GNOME games, right? Just saying...

https://packages.ubuntu.com/bionic/gnome-mines

DOSBox and Widelands have to be extremely useful on mainframes!

https://packages.ubuntu.com/bionic/dosbox

Oh, we even have Tux Paint here!

https://packages.ubuntu.com/bionic/tuxpaint

OMG, Linux admins are such noobs...

But of course, Canonical maintainers don't have time and resources for providing at least minimal setup for 32-bit libs in 64-bit systems. Software for kids and games on mainframes are definitely more important. That's what people pay for them!
That's why Linux on desktop will always fail. Because it doesn't care about what people really need and want.

All the packages that you link to are from the Universe repository which are "Community-maintained free and open-source software" so that is not packages that any Ubuntu developer put time and resources into. It's just that since they already have Main for s390x they might as well let the community at large maintain a Universe repository for the arch.

It's only Main that Ubuntu devs maintain and that is what they are talking about dropping for i386, and since they drop Main there is no way to also provide things like Universe so they go as well.

[Weasel]

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.

Of course you don't convert the data, only the storage medium. An emulator doesn't convert anything. And yes, an emulator is a valid solution to this problem. However, that's for DOS, because DOS was full screen and single-task OS. For most 32-bit software other than games, we want flawless desktop integration.

As for games, good luck emulating more complex games at acceptable performance (60 FPS minimum), like Deus Ex Human Revolution.