Fedora inches closer to dropping x86-32 support Following discussion on the mailing list, the Fedora team is taking another small step away from x86-32 support, with developers urged to stop building i686 versions of "leaf packages" – in other words, packages that nothing else depends upon. This means building applications for 32-bit chips, not the Linux distribution itself …
[Article author here]
I am intrigued by this.
You had x86-32 Xubuntu, you say? That means no later than 18.10, as that was the last release. 19.04 and onwards were x86-64 only:
https://lists.ubuntu.com/archives/ubuntu-release/2018-December/004647.html
There was nothing to upgrade *to,* from 18.10.
Therefore, I am guessing you meant 18.04? That was the last LTS release of Xubuntu on x86-32.
So, I guess you mean you had Xubuntu 18.04 and you upgraded to the next LTS, 20.04? Is that right?
And it installed a VM _on its own_?
What, VirtualBox? KVM?
This sounds very odd and I would love to know more.
[Author here]
Well, FWIW, that's the position Mac owners were in. OS X 10.14 was the last release to run 32-bit code. 10.15 and newer (11, 12) only run 64-bit code.
Which is why I haven't upgraded my iMac past Mojave yet. I have some 32-bit apps for which no updates are available.
At some point, it is more or less bound to happen.
I wonder if there are more 32-bit Intel machines running Fedora Linux in the wild compared to ARM(64) (i.e Raspberry Pi, Jetson Nano, Pcduino, etc) running Fedora Linux.
I rekon there is so it seems a bit strange to drop that and focus on a more niche platform. Raspberry Pi isn't necessarily niche, but Raspberry Pi running Fedora is.
That said, part of my reason to use older hardware is to also use the older operating systems (and lighter software) so I am not exactly affected by it.
There almost certainly aren't, because - as the article says - it hasn't been possible to do this for several releases. We stopped shipping i686 images years ago. We still build packages for i686 in order to allow 32-bit only third-party applications to run on 64-bit installs. This proposal is essentially about trying to strip that set of packages down to only the ones that are necessary for widely-popular 32-bit only third-party apps (like wine).
> anything running a 32bit processor is landfill
They're not landfill. There are always collectors of old PCs, running old operating systems.
The last 32-bit only x86 CPUs introduced were Atoms back in 2010. The rest of Intel's line-up supported x86-64 at least 4 years before that, and for AMD you can go back to 2003 for the first x86-64 CPUs. That's just shy of 20 years, so rather old systems are still alive and well.
Something that old is not worth keeping alive for normal uses, though. Their electric bill will quickly pay for a much newer and higher-end system that's much more energy efficient. Of course there are legacy applications, but those don't often handle an OS upgrade gracefully, either, so they're virtual time machines which won't benefit from continued OS support anyhow.
There's a 10-year window after x86-64 was introduced, before AMD PSP came along. Not quite as long between Intel adopting x86-64 and introducing the IME, but you've got options there as well. Plenty of options.
Not to mention, you can buy a cheap RPi without those, which is likely to outperform any i686 processor.
> This will in time have knock-on effects on Red Hat Enterprise Linux (RHEL),
Doubtful. RHEL7 dropped support for booting i686 systems years ago. Fortunately CentOS made its own spin-off, relying on the i686 RHEL7 packages (compiled for compatibility). Having installed it on an old laptop, I can speak from experience that a tremendous amount of software is missing i686 versions, requiring compiling from the SRPM. Not pleasant at all on an old CPU. Pretty clear it's the end-of-the-line for i686 CPUs.
The last 32-bit only x86 CPUs were Atoms back in 2010, and most x86 CPUs 5+ years old than that supported x86-64. You can go back to 2003 for the first x86-64 CPUs, so you can keep rather old systems alive.
It's a shame, though. The 32-bit version of Firefox has minimum RAM requirements of 512K, while the 64-bit version requires a minimum of 2GB. I run the 32-bit version just for that reason.
"Following discussion on the mailing list, the Fedora team is taking another small step away from x86-32 support, with developers urged to stop building i686 versions of "leaf packages" – in other words, packages that nothing else depends upon."
This is not quite right, due to a misunderstanding of the Change process. Fedora is a very open project, so major proposals like this have to be publicly proposed and discussed. That's the point this Change is at. It has been proposed, and now is under discussion. That's why the mailing list thread title has "proposal" in it. It has not yet been approved by FESCo (which is the body that approves or rejects Changes). Nobody is actually being "urged" to do this as of yet; they only would be if the Change is approved.
Say goodbye to running old games. Except those that can be resold to nostalgia customers as "Enhanced Editions", that is.
Oh well, most proprietary applications can at least be recompiled to be 64-bit, at a cost of a bit of developer time (or, possibly, a LOT of developer time untangling old build system horrors) and the sudden appearance of hard to debug bugs in the new versions. Unless the dependent libraries don't exist in 64-bit form (non open source or abandoned)... you'd think that at this point, those applications that are painless to port to 64 bit have already been ported.
Doesn't really do *too* much to help with Y2038 either, the ugly casts etc. hidden under the hood will still be there, waiting.
Yeah, I'm running Ubuntu 18.04 32-bit on one system. Effectively, they didn't ship a graphical CD installer but had everything else. I think I upgraded it from 16.04, but you could also run that "netboot" CD (or actually network boot it with PXE.. it's about a 50MB CD), pick "Ubuntu desktop" in the text installer and end up with a Ubuntu desktop install. Not sure why they bothered not building the install CD considering they still built literally everything else.
As for any newer hardware -- Ubuntu and other modern Linux distros truly have no need for 32-bit libs whatsoever, there is not any "legacy code" lurking in there that uses them or anything. But, Steam itself, Steam's Proton (for running windows games) and Wine, those need it. Steam needs 32-bit libs I think primarily for running the older Linux games that are 32-bit (of course, you'd also need those 32-bit libs running the same games outside Steam, it's nice to keep enough 32-bit libs available for doing so.) Proton and Wine, technically you can install only amd64 build of wine, it only needs 64-bit Linux libraries then but also only runs 64-bit Windows apps. But this would be annoying, even if you have 64-bit apps, they may have a 32-bit "setup.exe" for instance. So typically the 32-bit wine package is also installed, uses 32-bit Linux libs and used for running 32-bit (as well as 16-bit and some DOS) applications.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
