Interest of software developers in the use of their product on 32bit Operating Systems has been declining for years. Build tests are only done on 64bit OS’es nowadays. For obvious reasons: there are not so many computers left in the Western world that only support 32bit software.
The thing is, there’s still a lot of old computer hardware in use outside of the wealthy West. Slackware is one of the few remaining Linux distros where the 32bit flavor is just as relevant as the 64bit variant. Yes, you may question the value of running really new software on really old hardware, but I think that is the users’ choice and if you happen to live in a country where a 2025 computer amounts to a year of salary, then I would want also those people to enjoy modern software and security patches.
I can’t recall how many patches have been needed to make source code compile on 32bit Slackware for instance, but in most cases there would be a way to patch the source or circumvent the error. Patrick Volkerding does this for the distro core and I do something similar for the packages in my own repository. And we sigh and complain to each other when compilations fail due to the restrictive 32bit address space, the inability to specify either “lib” or “lib64” as the LIBDIR, the use of architecture-specific assembly code and CPU instructions, etcetera.
But like with everything that’s left to rot in a corner, it’s getting increasingly difficult to keep 32bit Linux alive. I am running into huge time-sucks when packaging complex pieces of software. Specifically, I have not been able to compile 32bit Chromium since the 132 release despite all of my attempts. And now LibreOffice joins that list: I have been unable to compile the 25.2.0 release on 32bit Slackware 15 and -current.
So.
I will give up my attempts to create 32bit packages for future Chromium and LibreOffice releases. It has already taken way too much of the little time I have left after my regular day-time job. If I run into more of these programs that won’t allow me to compile 32bit binaries, those will quickly be added to that list as well.
I will ask again: if there are people among you (readers) who really need their 32bit programs, I need you to come up with the patches to make that work.
As long as there is a 32bit Slackware, I will keep maintaining my multilib repository of course: there’s nothing for me to actually compile there now that gcc and glibc packages in 64bit Slackware support multilib; the work is reduced to simple re-packaging. But once Patrick decides that 32bit Slackware goes the way of the dodo, then also multilib for Slackware will disappear. It would really be a shame though, but there’s simply no longer any kind of movement that is sufficiently influential to be able to sway software developers and keep 32bit Linux instances running to do their unit testing.
Looking at the Wine emulator, that one can be built so that it no longer needs 32bit libraries, but it would lose the capability to run 16bit Windows programs. I guess that’s where DOSbox would come in to save the day.
But be forewarned: the 32bit OS has become an endangered species.
Eric
A salute for you, building those packages as long as you did. It took skills beyond my skillset. 🙂 One thing that was eye-opening about LQN (warts and all) was that even when I was in grad school and Frankensteining computers from Boeing Surplus together to get them to work…I was dealing with more modern hardware than some other parts of the world. Does put a lot of things into perspective.
Hi Eric,
Eric,
There are only so many hours in the day and only one Eric and Patrick so it is completely understandable that you guys need to prioritize. As I do in many of these blog replies I want to thank you both for all the hard work that nobody but you and your families see. It is truly appreciated by many people. In the end tough decisions have to be made and they should be made by the guys shouldering the burden. You are doing a fantastic job. I personally thank you both for your hard work and I am sure there are many people reading this shaking their head in agreement. Have a great weekend and enjoy yourself!
Chris e g
As software becomes a major project for 32-bit, why not just freeze that package? Continue including the last version that was 32-bit friendly, just no more version upgrades for that package. Before 64-bit, all slackware packages were 32-bit. As long as there are folks who still need 32-bit, you are still providing a valuable service. They cannot expect the latest version with more features. They certainly don’t need the latest firmware, or even a recent kernel. In the mid-late nineties, I installed slackware in computer labs for Linux classes. Those 32-bit packages are still viable. Of course, security holes must be patched, but those distributions have been made secure over the decades, so why not use them? I have had my share of hassles with 10-yr-old laptops, so I understand the hassles. Keep Slackware Alive! Even if it is 32-bit. Abandon not ye olde customers.
It’s not that simple.
To stale a package in its ‘last working version’ also meas to freeze vulnerabilities, including 0-day stuff. Eric can be held responsible for distributing vulnerable software.
Unfortunately, pull the plug of 32 bit stuff is the way to go. He did it for way more time than expected.
Exactly. You cannot expect that I keep finding and patching zero-days for software versions that no developer still cares about.
Suppose Chromium moves on to version 140 and I kept a 32bit version 131 in my repository… who will create the patches to fix vulnerabilities in that 131 release? None of what’s in future Chromium source code can be back-ported to older versions. The software simply moves at too fast a pace.
I will remove 32bit Chromium-ungoogled soon (the 32bit version of regular Chromium has already been removed from my repository a while ago).
Again, if you find 32bit software really valuable, help me with finding the patches for the *current* versions, do not linger with old releases please.
It isn’t even just the security issue. Big complex packages, are going to have a lot of library and other types of runtime dependancies on other things. While a given package or set of packages if frozen at specific versions will probably continue to work on the same Slackware version as long as it is maintained, it would be likely to break on -current at again given time and probably not work on the next release version.
You 90% of that already really, just grab the version for the prior Slackware relase from either slackbuilds or Alien’s tree and see if builds on your current install. If it does great if not it is probably a big lift.
I never said keep flawed packages. Just drop them. They weren’t included decades ago, just revert to software that did the same thing. Does anyone have a package list from 2000? The people who are still using 32-bit packages on obsolete hardware can do just fine without packages with design flaws that need frequent security patches. Drop the chaff and keep it simple. Focus on the basic needs of those customers, not the latest whistles and bells. If it needs patches, they can probably do just fine without it. If they want the latest and greatest, a couple hundred dollars for an obsolete 64-bit box on eBay presents itself.
Some people in countries where 100 dollars amounts to months of income, are unable to buy even our obsoleted hardware on eBay.
Yes, older versions of Slackware are forever available on many Internet mirrors, but that software will never meet the requirements of what people today expect. Even in poor countries.
There will be a moment where the latest Chromium or LibreOffice refuses to load because of insufficient RAM on old hardware… that too is a fact of life. But I reject the suggestion that poor people should be content with 25-year old software. A few years old software, I can agree to.
The solution, as always, would be for the rich countries to make available at low prices towards the poor countries the bare necessities for living. Today, that does not only include food, clothes and shelter, but also access to compute and information.
I concur! Slackware 32-bit begone. I do have compassion for those living in countries where a cheap decades-old computer costs an annual wage. However, I believe they have greater things with which to concern themselves. There are charity organizations that could help, but food, clean water, and housing, not to mention safety, should be of more concern that providing 64-bit laptops.
I withdraw my support for 32-bit Slackware.
You do what you need to do, don’t bother me with your rationale. And whenever you write another post about me, spell my fucking last name correctly.
Mr Eric What was Spocks saying “The need of the many outweighs the need of the few” and it is resonating so much as not only is the technology that we witnessed getting old, so are we. It is commendable that you keep it alive, but the world is slowly moving faster than I am and I’m getting to the point to where my memories are way outdated. Thank you both for keeping what is the oldest operating system going and am looking forward to the next full release. Thank you again…..
While I do not use 32 bit software anymore, I still have a legacy motherboard. It won’t be long and this computer will need replacing. I’m going to have to forget the past and move to the future…..
Don’t forget the past! That’s preventing you from learning from your mistakes. Remember the past fondly.
PCLinux is also a pure x64 distribution, but it has the Wine package (with full 32-bit support).
I think the maintainer has also an accompanying package, with 32-bit libraries).
This specific package, is also useful for Steam (if you have need for this) and VirtualBox.
Other than that, 32-bit is dead in the water. 🙂
(And Linux was proud to adopt x64, before anyone else). 😉
I fully understand that the costs of new and modern hardware are the main reason for keep running old 32bit machines (the e-waste is also a fair reason mentioned by some people that still using 32bit machines). On the other hand, the arm64 architecture evolved a lot in the last years and they are much cheaper than x86_64 hardware. Thus, in my opinion, a move from 32bit/x86 to arm64 could be an option for getting new hardware with fair prices. As an example, a good Raspberry Pi 4 machine can be better than the latest mass-produced 32bit hardware – and it costs less than $100 (even in Brazil) – $35 is the starting price in the official website.
I know that there are some (maybe many) limitations for the use of arm64. Among such limitations there is a lack of software/OSs for this platform, specially on the desktop. Regarding this topic, my question is: why to spend time on a platform that will surely disappear instead of investing that same time on a platform that lacks support?
A Raspberry Pi is no substitute for a proper desktop or laptop. Also, ARM is a nightmare of a hardware platform to build a distro for.
I like my pi. It’s fun to goof around with, and I use it to monitor twitch chat while streaming. I would not want to use it as a development desktop, though. (Not even a pi 5.) The reason they didn’t suggest using a 64-bit OS on the 4B was because they didn’t have the 64-bit version of the OS ready when the 4B came out. People were slow to switch. 64-bit is suggested now.
Good to listen to podcasts on, surf, look up things while I’ve got something fullscreen on my desktop, sure. It would probably be useful on a vacation, if I had to check email or some other light social media usage. But it definitely lacks some things on my desktop I can’t live without on a day-to-day basis.
I’m a bit late to comment, but, reflecting on the OpenBSD approach to supporting what they term ‘i386’ vs amd64. Base is same (as Mr Volkerding is doing for 32 bit Slackware) but packages are different.
In i386 arch package repository there is no firefox or chromium but there is seamonkey and dillo. No libreoffice but abiword and gnumeric. You get the picture. I’m guessing this selection of packages is related to compilation issues.
Thanks for your work and take care.
What in the UK we used to call ‘managed decline’ or in Web page terms ‘graceful degradation’. The there is
R.I.P. 32 bits ;_;