As a followup to this SN story, we have a ruling!
decathorpe (Fabio Valentini) posted:
Given feedback in this thread (and to a lesser extent, also on the mailing list) I have decided to withdraw this proposal.
- It is clear that the Fedora 44 target for this Change was too early. To some degree, I expected this to be the case, and was prepared to move the proposed implementation of the Change to a later release. Fedora 44 was just the earliest "reasonable" target. However, I think this also shows an inherent conflict in the current Changes process - if a big Change (like this one) is submitted quite early (out of caution!), that also front-loads the discussion and decision process instead of giving things more time. For example, I don't think the discussion would have been meaningfully different if the targeted release had been Fedora 46 instead of 44 - which is one of the reasons why I decided to withdraw the change instead of just re-targeting it at a later Fedora release.
- I don't think the problem that was attempted to be addressed with this proposal will go away. With more and more projects dropping official support for building / running their software on 32-bit architectures, it's just going to get worse over the next few years. Dealing with widely used software falling out from under our feet won't be fun. To some degree, always pushing the latest and greatest :tm: software in Fedora is also working against us here - if we just stuck with foo 1.0 LTS for 10 years, we just wouldn't need to care that foo 3.0 dropped support for running on 32-bit systems ...
- I am disappointed in some of the reactions this :double_exclamation_mark: proposal :double_exclamation_mark: has received, with some people apparently reading it in the most uncharitable way. It was a proposal that tried to address technical problems package maintainers and release engineering is facing, not some conspiracy to break the "gaming use case". That said, I was expecting a lot of feedback feedback on this one, but not hundreds of people shouting "DON'T DO THIS WHY DON'T YOU CARE ABOUT YOUR USERS I WILL SWITCH DISTROS IMMEDIATELY levels of feedback (though to some degree, I also blame clickbait "tech press" or YouTubers for that ...)
I am now looking forward to seeing actual (and actionable) counter-proposals.
— Fabio
« Are Brother's Insecure Printers Illegal in the UK? | Bruce Schneier on How Cybersecurity Fears Affect Confidence in Voting Systems »
Related Stories
The Fedora project is planning to reduce its package maintenance burden by dropping support for 32-bit x86 (i686) packages from the distribution's repositories. The plan detailed in the (mislabelled) change proposal is to drop 32-bit packages for Fedora 44. "By dropping completely the i686 architecture, Fedora will decrease the burden on package maintainers, release engineering, infrastructure, and users. Building and maintaining packages for i686 (and 32-bit architectures in general, but i686 is the last 32-bit architecture - partially - supported by Fedora) has been requiring more and more effort.
Many projects have already been officially dropping support for building and / or running on 32-bit architectures, requiring either adding back support for this architecture downstream in Fedora, or requiring packaging changes in a significant number of packages to adapt to this dropped support." The discussion under the proposal points out some of the situations where users will be unable to run software, such as the Steam gaming portal, under the current plan.
- - https://distrowatch.com/dwres.php?resource=showheadline&story=20014
(Score: 4, Insightful) by aafcac on Thursday July 03, @12:17AM (8 children)
There really isn't much reason for this when other operating systems can figure out how to have more than one set of libraries to cover this situation and processors can as well. You're not ever really sure who needs this sort of thing and if people are coding correctly, this should be a non-issue to have 32bit libraries at least available for installation.
(Score: 4, Interesting) by turgid on Thursday July 03, @08:21AM (5 children)
I've got a laser printer from 2009 which is still going strong. Unfortunately, it has closed-source drivers which were compiled for 32-bit Linux x86. I used to have a 32-bit Slackware server just for the printer. When multilib came along, I got one of my 64-bit machines to serve the printer. If 32-bit support went away, I'd have to throw away my printer or maybe try something cunning with a VM or emulator running an older distro. However, the rate at which Slackware changes, I think that printer will see me out and I don't plan on going soon.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 5, Touché) by Ingar on Thursday July 03, @08:59AM
There's a story about GNU, Stallman and printer drivers.
Love is a three-edged sword: heart, mind, and reality.
(Score: 2) by janrinok on Thursday July 03, @09:06AM (1 child)
I recently replace an HP 4030 which I bought second-hand in 2001. It was probably made around 1998. I've replaced it with a Brother which I am very happy with. It does what I want, when I want it to, looks like it will last for another 20 years!
[nostyle RIP 06 May 2025]
(Score: 3, Interesting) by turgid on Thursday July 03, @09:18AM
I once got an A4 LaserJet II and a Postscript cartridge from the local recycling centre for £4. I put a new toner cartridge in it and got about four years out of it before it died.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2, Interesting) by shrewdsheep on Thursday July 03, @02:13PM (1 child)
I have good experience using a raspberry pi to turn a USB-printer into a network printer. This would future-proof your printer. However, you would have to emulate x86 on ARM which I haven't tried myself. Should be feasible though.
(Score: 3, Interesting) by turgid on Thursday July 03, @07:54PM
I dare say a modern ARM (aarch64) should be more than capable of emulating a 32-bit x86 at a good enough speed for something like a printer driver.
We lose sight of how fast computers are now, and that emulation is not only feasible but very usable.
I'm showing my age here, but in the 1990s I had a self-build Pentium 100 running Slackware with plenty of RAM (32MB). I ran FUSE on it (the Free Unix Spectrum Emulator) and played some old games from my childhood. To give you an idea, the Spectrum had a 3.54MHz Z80 CPU. The Pentium 100 was way more than enough to emulate the Z80 with many clock cycles to spare and the emulation could run many times faster than the original machine. Then I upgraded to 400MHz, 500MHz, 1GHz... 64-bit...
I'm now running a 12-core Ryzen with a mere 32GB of RAM. I ran the Byte Unix benchmarks on it and it's (wait for it) 1000 times the power of my Pentium 100.
Even ~20 years ago, I compiled and ran bochs [sourceforge.io] (x86 PC emulator) on Solaris/UltraSPARC (2x450MHz, 512MB RAM) and booted Slackware in it.
I am currently running a 64-bit ARM build of Ubuntu in qemu on my Ryzen system. There's the odd bit of lag now and then but it's good enough.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by sjames on Friday July 04, @08:24PM (1 child)
It *IS* a truly dumb idea. The 32 but libraries already exist, this is just pointless vandalism masquerading as a step forward.
As time goes on, interest in 32 bit will surely wane. At some point the packages can be deprecated and then on life support. Just build them the way they have been built before and stick them where they have been stuck before. It's not even worthy of being called effort since it's done by automation anyway. Then drop them after nobody cares.
That isn't today.
(Score: 2) by aafcac on Monday July 07, @04:29AM
Clearly they'll need to come out eventually, 32bit computers are becoming a rarity, but I think the 7ish years that FreeBSD is going with is far more reasonable and chances are that anything that genuinely needs the libs will run well under emulation by then, assuming it doesn't now. Plus in the case of FreeBSD, I don't think there's as much 32bit code that can't be recompiled.
(Score: 5, Interesting) by Subsentient on Thursday July 03, @01:22AM (4 children)
Good, I was looking into switching to Void Linux, now I don't have to, for now.
I don't see a lot of packages that demand a specific CPU architecture. The ones that do have assembly or intrinsics based optimizations, if they're written well, as in, portably, they'll fall back to a slower C only version.
The only projects I can imagine to be arrogant and foolish enough to reject architectures they don't like from their build system are things like GNOME and systemd.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 1, Informative) by Anonymous Coward on Thursday July 03, @11:38AM (2 children)
You'd think that, experience dictates that, however the muppets who write the SPEC files for these packages apparently disagree...
(Guess who had to maintain, for close on two years, a local set of 32bit RPM packages built from modified SPECs from the SRPMs of the updates to a distro that had dropped 32bit support?)
(Score: 2) by turgid on Thursday July 03, @09:08PM (1 child)
Muppets write SPEC files too? Muppets wrote RPM as far as I can tell. It's nothing but another layer of boiler plate which could be done simpler in the shell.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Touché) by aafcac on Thursday July 03, @09:43PM
I tried RedHat and the inability to recursively download the dependencies at the time made me abandon it pretty quickly. And that wasn't even in the '90s either.
(Score: 2) by bart9h on Saturday July 05, @03:17PM
You don't have to, but let me add my two cents by saying Void is very nice.
I have tried a lot of distros, and was running Debian for a long time when it got infected by systemd, which forced me back to distro hopping again. After a few tries (which included Devuan and Gentoo, for instance) I discovered Void, and it was love at first sight.
I feels like it is what Arch should be. Arch concept is nice: a minimal opinionated rolling distro, but it's just too unstable. Void seems to choose the right balance for updating the packages. Sometimes it takes a few weeks or more to get the new version of some software, but I never had any problem doing full updates since I started using Void in 2022.
(Score: 3, Informative) by hendrikboom on Thursday July 03, @05:20AM (1 child)
I'm glad I won't have to junk my 15-year-old netbook in the immediate future. It's running reliably 24 hours a day, even during short power failures.
(Score: 2) by turgid on Thursday July 03, @07:55PM
There will always be Slackware, and probably NetBSD.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by ElizabethGreene on Thursday July 03, @09:46PM (2 children)
Could someone help me understand what the 686 target is? My intuition is 286 = 80286=16 bit linear cpu, 80386=32-bit linear cpu, 80486=faster 386 with integrated math coprocessor so you don't need the 387 chip, ?586? = pentium 1, the first generation 32-bit with parallel execution.
Does that make 686 = The Pentium 2s? The ones that look like video game cartridges (and the AMD processors that liked to explode if you peeled off the heatsync while it's running?)
(Score: 3, Informative) by hopdevil on Thursday July 03, @11:26PM
Pentium Pro (circa 1995) or better CPUs, Pentium M (2003 celeron, eg)
Wikipedia https://en.wikipedia.org/wiki/P6_(microarchitecture) [wikipedia.org]
(Score: 3, Informative) by turgid on Friday July 04, @09:55PM
There were some slight instruction set improvements between i586 (Pentium) and i686 (Pentium Pro/Pentium II). The most significant, I think, was the CMOV instruction which was conditional move, which saved some compares and conditional jumps, saving many bytes and clock cycles in some situations. For some reason, in later years, things like CMOV went out of fashion. Perhaps some of our superior IQ commentators could explain why?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].