Ubuntu 19.10 To Drop 32-bit x86 Packages

[the_scx]

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.

ALSA, AudioFile, CUPS, D-Bus, fontconfig, fontforge, FreeGLUT, freetype, gettext, giflib, glibc, glx-utils, GNOME 3, GnuTLS, gsm, GStreamer, Gtk+2, Gtk+3, gvfs, isdn4k, libatomic, libattr, libcurl, libdbusmenu, libFAudio, libgphoto2, libieee1284, libjpeg, libpcap, libpng, librsvg2, libstdc++, libtiff, libusb, libv4l, libva, libvdpau, libX11, libXcomposite, libXcursor, libXext, libXi, libXinerama, libxml2, libXmu, libXrandr, libXrender, libXScrnSaver, libxslt, libXtst, libXxf86dga, libXxf86vm, LittleCMS, Mesa, mpg123, ncurses, nss, OpenAL, OpenCL, OpenCL ICD Loader, OpenGL, OpenLDAP, Perl, PulseAudio, Python, SANE, SDL2, unixODBC, Vulkan, WebKit2, zlib, etc. are not their libraries. They are system libraries. And they should be provided by the system or at least some kind of runtime, not by individual developers.

Proving such a bunch of libraries on your own will lead into creating a mini-distribution inside Ubuntu. It would be very similar to Freedesktop from Flatpak. And believe me, no one wants to support yet another runtime and infrastructure for building it.

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

How many flatpak packages have you created? I prepared literally a dozen of them. And believe me, in many case it is not so easy. What is worse, multiarch in Flatpak is simple broken.
https://github.com/flatpak/freedeskt...ges/issues/101

Creating package for Lutris in a modern distribution is relatively easy. However, they spent at least 5 months (probably much more, because they have talking about it since 2017, and the Flathub repo was created just two weeks ago) to provide the flatpak package that is still a half-working solution! What is worse, it is hard to maintain.
This is the future of Linux desktop you want? Transferring the burden of work from distribution developers to application developers? It is the worst idea I've ever heard (well, maybe except these nonsense statements provided by oiaohm).

[the_scx]

You skipped a version.

No, I just mentioned the most important ones.

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.

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.

Why should Linux maintain compatibility with old windows software anyway.

It is about current Windows software.

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

64-bit Wine built without 32-bit support will not be able to run ANY 32-bit applications, which most Windows binaries are. Even many 64-bit programs still include 32-bit components!

And Linux should care about it, because it still lack native equivalents. A lot of them. And no, FreeCAD is not a free version of CATIA and ET:Legacy is not a game like Battlefield V. They aren't even close...

On the other hand...
Why does Linux need 3rd party developers? They only complain that they have to rewrite theirs software and recompile theirs packages over and over again.
Why does Linux need users? They only complain that they have to deal with problems that do not occur in other systems.
Just drop both of them and everyone will be happy!

[the_scx]

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

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.

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.

Sorry, I didn't know that WINE is an outdated proprietary crap. Could you write an e-mail to the Fedora maintainers and say them that they should remove this package from the repo?
BTW, where can I download the 64-bit version of PCSX2?

You know right that PipeWire (Pulse successor)has a layer to allow retro-compatibility with Pulse

And you know that there was an ALSA emulation mode in the Linux implementation of OSS (Open Sound System), and ALSA provides an optional OSS emulation mode as well? I remember those times. Unfortunately, neither of these emulation modes work well...

https://www.mameau.com/enemy-territory-on-linux-soundfix/

and that there is a thing called Xwayland to run legacy applications with?

And today we have multiarch/multilib solutions that allow us to run 32-bit software on a 64-bit system. Unfortunately, someone wants to take this away from us because he thinks we do not need it.
A few moths ago, there was a discussion about dropping support for i386 in Ubuntu 20.04 LTS. People calmed that it is only about 32-bit port, and it would not affect multiarch/multilib setup. As we can see now, they were wrong.

https://www.phoronix.com/forums/forum/hardware/processors-memory/1080902-it-s-still-undecided-whether-ubuntu-20-04-lts-will-support-32-bit-x86-i386?p=1080984#post1080984

This discussion about dropping official Ubuntu 32 bit x86 support has never ever been about dropping 32 bit multiarch. I don't know where people are getting that from. It's getting silly to explain it in every thread again.

I bet that still in the next decade there will be a fanatic who postulates the removal of XWayaland, telling people that they do not need it anymore, just because he doesn't use it. And there will be such an idiotic argument: X.Org session is rarely used, so people don't need XWayland on Wayland session. But of course everyone still love open source games on mainframes!

[the_scx]

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.

So you are saying that open source games on mainframes are more important than at least minimal multilib/multiarch support on x86-64 desktops?
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, close issue #1 (Microsoft has a majority market share) as WONTFIX, and tell theirs users to find another distribution.

If they had wisely used SDL (as is the norm I think), PulseAudio API would not concern them.

How many desktop programs do you know that use SDL2 for sound? Even WINE uses PulseAudio directly (or through OpenAL Soft in games).
What is more, SDL2 in games is used mainly for handling windows, managing OpenGL contexts, and for controls. Today, it is a rather replacement for FreeGLUT and GLFW, although initially it was created for something else (let's say that it is more complex than the mentioned solutions). For audio, OpenAL is usually used.

X11 is still supported in Wayland via XWayland.

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

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

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.
And pure 64-bit WINE is completely useless.

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

64-bit Wine built without 32-bit support will not be able to run ANY 32-bit applications, which most Windows binaries are. Even many 64-bit programs still include 32-bit components!

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

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

[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]

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]

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.

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