OpenMandriva Is Also Making Plans To Move Away From 32-Bit Support

[skeevy420]

Yeah, let's also destroy all modern weapons and go back to sword fighting, worked fine back then, so according to you it should work fine still. And go back to treating people with herbs instead of medicine. And ...

"Herbs" have just recently became available in my state as a legal treatment.

[berolinux]

I do.
Gamers mostly need latest drivers so they want the latest distro, and dropping 32bit means no Wine (mostly used for games) and no Steam (again, games), and no other third party games for Linux (GOG or something).
LTS is NOT an option, unless you are using NVIDIA drivers, at which point wtf are you using Linux for anyway.

Then of course there is a ton of trolls and people that believe that their own ideology is what drives Linux developers.

Unlike Ubuntu, OpenMandriva is most definitely not dropping 32bit libraries needed for Wine and Steam.
The only think we're thinking of dropping is running the whole OS on 32bit x86 hardware. As you can see in the meeting logs, nobody is suggesting to drop i686 libraries (which will at some point be built with -m32 in a 64bit environment). That will keep everything people are actually using going, and will save us a LOT of time and headaches (try maintaining something like Libreoffice on an ancient architecture -- frequently barfs because the linker can't allocate enough memory in one piece etc).

The QA team has issues with testing 32bit builds because nobody has 32bit hardware anymore (of course it's always possible to install an i686 images on 64bit hardware or in VirtualBox or qemu -- but that will not catch things like instructions that don't exist on ancient CPUs being used anyway, and certainly drivers for GPUs that were common around the time 32bit x86 boxes were built won't get any testing).

I have yet to see anyone who is seriously using a modern Plasma 5 based system on any hardware incapable of running a 64bit OS (with or without 32bit compat libraries).

If anyone has a valid reason to keep putting time and efforts into building the entire OS (which, due to RAM requirements of the desktop and all, won't run on an average box from the 1990s anyway -- this isn't OpenEmbedded or something similar expected to run with 64 MB RAM), including all applications - instead of just keeping libraries needed for compatibility - for ancient architectures, now would be a good time to share it.

[Vistaus]

"Herbs" have just recently became available in my state as a legal treatment.

But I said "instead of", not optional like in your state.

[berolinux]

Yeah, let's also destroy all modern weapons and go back to sword fighting, worked fine back then, so according to you it should work fine still. And go back to treating people with herbs instead of medicine. And ...

That's actually a great idea -- I'd much rather be beaten with a stick than nuked...
But it's a less great idea if we want to go back to analog cameras, or crossing oceans with rowboats...
And OpenMandriva isn't designed to kill people, so...

[berolinux]

I also think it's funny that OpenMandriva is going to switch some i686 libraries to rolling release, enough for Wine/Steam.

Out of context.
Nobody is talking about switching i686 libraries to rolling release.
i686 libraries will continue to be part of 64bit releases, no changes whatsoever except at some point we'll drop support for running the entire OS in 32bit mode.

There will be no more stable releases of the entire OS for 32bit x86 machines. For the time being, we'll still build all packages for i686, so people can update to the rolling release branch and get something similar to future releases even on 32bit machines.
The main reason not to make any more stable 32bit install images is that QA has no way of testing them properly (no more 32bit x86 machines, no more machines with GPUs that are common in 32bit x86 machines, etc.).

Are these distributions trying to force people switch to Manjaro, Fedora, Suse, or Debian?

Only people who are serious about running an entire OS including a memory hungry desktop on 32bit x86 machines. Nothing changes for anyone else.

[M@GOid]

Yeah, but is mixing and matching PPAs* really the best option when they can just use a distribution that has what they need in the default repositories?

*Because we're talking kernels, Mesa, Vulkan implementations, LLVM, GCC, and more. At some point it becomes more hassle than it's worth to maintain a system like that and it's also the debianxfce method (and then some because of LTS). Most of us here are in agreement that the debianxfce method is just retarded when distributions like Manjaro, Tumbleweed, and Fedora contain all that's necessary up-to-date and compiled together, two of those have LTS versions with AMDGPU-Pro support, and the most an end user might have to do is use the AMD kernel and run some stuff from git for a month or so if they buy bleeding edge hardware (and if they do need that, PPA-like methods exist for all those distributions...yeah, Manjaro can be set up to use Arch Testing for mesa-git and whatnot).

Indeed there is this burden. But this situation will not last forever (or at last this is my hope), since solutions will appear in the future. But like in any change of paradigm, there will be inconveniences. All you can do is choose where to be to have the least headaches.

The way I see it, this Canonical move will encourage other big distros to do the same, and in a couple years developers and users on the bleeding edge will have no choice but to fully embrace 64 bit. Some old software and hardware will be abandoned, but that is nothing that didn't happen before in the 8 > 16 > 32 bit transitions. And guess what, all that old software eventually became available again, because the people that wanted it (and obliviously had the skills) made it happen.

Of course, as the messenger, Canonical will take all the flak, but the truth is, if their real customers did not demand 32 bit support, they will not spend money on it just for us freeloaders. Is not pretty, but is the way the world works.

[skeevy420]

Out of context.
Nobody is talking about switching i686 libraries to rolling release.
i686 libraries will continue to be part of 64bit releases, no changes whatsoever except at some point we'll drop support for running the entire OS in 32bit mode.

Yeah, I misread ACTION: 2 to mean the i686 part of multilib and not the i686 version of the distribution. As long as multilib isn't dropped y'all should be just fine (unless something better and easier to maintain like a Wine for Linux32 emerges).

I honestly can't think of a good reason to keep x86_32 outside of the usual "some business has some odd application that doesn't work on newer stuff" argument and the proper solution to that is create a job or three, hire a programmer or three, and get your stuff updated you shitty company or the other usual argument of "people from the third world" (but ARM and smartphones changes that 2010 idea).

[Raka555]

I386 regardless it's flaws almost lasting since 40 years providing us industrial grade systems to run our economies on. There are PC104s embedded from space stations to scada lines to hospitals. Why on earth do you have to screw with something which was reliable for 40 years. If a ZX 80 calculator can do the job why don't you just let it do the job.

Dropping i386 is a terrible idea just like SystemD, 64bit was required, I agree but reverse compatibility should be kept forever especially if it's not a large amount of extra work to crossbuild since many of the i386 systems will be continued to be produced just like floppy disks for replacements.

And just some warm words to systemD creators: go f yourselves!

I love you man!

[berolinux]

Yeah, I misread ACTION: 2 to mean the i686 part of multilib and not the i686 version of the distribution. As long as multilib isn't dropped y'all should be just fine (unless something better and easier to maintain like a Wine for Linux32 emerges).

Multilib essentially is wine for linux32 -- a set of libraries that are binary compatible with something being emulated (Windows/Linux32). On top of it, there's the setarch tool in util-linux (which in this context is comparable to the wine launcher).

I honestly can't think of a good reason to keep x86_32 outside of the usual "some business has some odd application that doesn't work on newer stuff" argument and the proper solution to that is create a job or three, hire a programmer or three, and get your stuff updated you shitty company or the other usual argument of "people from the third world" (but ARM and smartphones changes that 2010 idea).

Agreed -- and unless that old application is REALLY REALLY REALLY broken (e.g. relying on a binary-only kernel module that exists only as an x86_32 binary -- but in that case it'll already depend on a prehistoric kernel version that no sane distribution would ship), it will run in multilib or at least in a chroot environment launched with setarch.

And while I'm not a fan of the likes of flatpak, appimage or snap (way too much duplication -- bundled libraries waste space and cause security problems [e.g. zlib security problem found, system zlib updated, but there's still a broken zlib inside the flatpak --> application still vulnerable even though the user thought he fixed his system]), this sort of stuff is where that sort of tool can be useful (just build an appimage/flatpak/whatever from the existing x86_32 system to get all the libraries).
But that's not even necessary given multilib is there to stay (at least as far as OpenMandriva is concerned).
It's 2019. DOS hasn't really been used for 30+ years. Yet people still play games in dosbox. The C64 pretty much went out of the mainstream some 40 years ago -- yet we still include a C64 emulator. Given that and similar use cases, I predict we'll still have x86_32 multilib libraries in 2050 (30 years from now that most distributions are starting to phase out x86_32 and Microsoft starts getting serious about 64-bit applications to make wine32 obsolete).
Even if if x86 is obsolete by 2050 and we're all on RISC-V, ARM, Loongson, Elbrus or OpenPOWER boxes (or yet another architecture that doesn't even exist yet, maybe RISC-VI), I expect we'll have some form of x86_32 multilibs combined with qemu or another CPU emulator (just for fun, I've tried -- running win32 applications on ARM with wine32 run through qemu with binfmt-misc is slow but possible. It'll likely work out of the box in a future OpenMandriva version).

As for people from the third world, most people who think they're on prehistoric boxes have never been there. I've been to Ethiopia in 2007. Outside of the first-generation OLPC boxes that were being tried in a few schools, I didn't spot any x86_32 machines there even then. People either had no computers (sometimes no electricity to run them with), or halfway modern computers. Not a lot in between.

And of course we can already run on lower end ARM boards that are cheaper than x86_32 boxes these days.

[skeevy420]

Multilib essentially is wine for linux32 -- a set of libraries that are binary compatible with something being emulated (Windows/Linux32). On top of it, there's the setarch tool in util-linux (which in this context is comparable to the wine launcher).

I just mean something more standardized than distributions shipping 32bit versions of their software. Something able to emulate older kernel versions and what was used in previous generations. Like how in winecfg or with Windows compatibility mode we can pick from 3.1 to 10, some sort of "emulator" that did Debian 1 to 10 in the same manner so that we can preserve historical Linux like Wine helps preserve historical Windows as well as accommodate various legacy business and proprietary programs. I say Debian, but any old distribution like Debian or Slackware would work if they've been there from the beginning (or real close to it) and have clear and defined versions for a "Line" project to target like how Wine has clear and defined Windows versions to target.

People in general like their older stuff for whatever reasons. It's why we have projects like Wine, Haiku, React, Retroarch, and a whole lot more. A topic like this wouldn't generate so much commotion if that weren't the case.

Even if if x86 is obsolete by 2050 and we're all on RISC-V, ARM, Loongson, Elbrus or OpenPOWER boxes (or yet another architecture that doesn't even exist yet, maybe RISC-VI), I expect we'll have some form of x86_32 multilibs combined with qemu or another CPU emulator (just for fun, I've tried -- running win32 applications on ARM with wine32 run through qemu with binfmt-misc is slow but possible. It'll likely work out of the box in a future OpenMandriva version).

They'll call it RISC-III in America.

But, yeah, I agree with all of that. It's going to be really interesting when Linux distributions on random architectures are able to offer just as well or better (legacy) Windows support than Windows itself.