Just drop i386 already! #1302
IA-32 is dead. Rightfully so. We're running out of build environments that still support it, most distributions like Ubuntu and Fedora dropped support for it years ago. CentOS 7 is not really maintained anymore and even if you believe in the 10-year LTS lifespan of a product whose successor release was dropped already, it's going to be end-of-life in just four months.
There is no reason to invest any time or effort into building binaries for this platform any longer. It didn't make a lot of sense a couple of years ago when I first proposed this, but by now, anybody should understand this.
I will begin to drop i386 builds from my own tools in December. For zsync2 and AppImageUpdate, given the fact that the previous build platform Ubuntu 18.04 has become EOL 8 months ago and the successor 20.04 (currently the oldest still-supported Ubuntu LTS release) does not provide such builds any more, I will also drop it there.
I recommend this to the entire community: don't waste time on IA-32. Those users should have changed to a 64-bit build already. And they know so. Some hardware is just not worth supporting. We need to make the best of our time. Maintaining dead technology is far from the best.
All reactions
Replies: 2 comments 14 replies
For the record, for 32-bit ARMv7, the situation is drastically different. Almost all distributions still support it officially. We have hardware around that depends on this, and after all, it's much more recent than IA-32. The moment platforms like Raspberry Pi 1 are no longer supported by distributions (and, honestly, they are so much slower than all the 64-bit ARMv8 successors), we should be dropping these as well. At this point, building the binaries is easily possible with QEMU and Docker and usually doesn't require any additional effort (and the builds are just as fast as 64-bit ARM in QEMU).
All reactions
Let's look at this from two perspectives: Philosophically and pragmatically.
- Philosophically, I am strictly against dropping something that we already have working, ever. I am against "forced obsolescence" and I don't want to contribute to it. I have 2 1-st gen 32-bit Atom netbooks that still run perfectly fine, until people "drop i386". Heck, this whole forced software/hardware update sprial is what drove me away from the Mac toward open source in the first place. And let's not even begin to talk about "environmentally friendly".
- Pragmatially, I can fully understand that not everyone will want to build everything for 32-bit Intel anymore, just like not everyone has even started to do ARM builds (something that will probably become more relevant in the future). Personally, I like the Go language (golang) for how trivially easy it is to cross-compile for the various architectures, making this a complete non-issue there. Unfortunately it's not quite as easy with C/C++, although tools like the zig compiler might help there.
So what should we do?
My 2 cents:
- We should ensure that the AppImage runtime and "core" tools can work on all architectures, and provide builds for 32-bit and 64-bit Intel and ARM
- It is up to the maintainer(s) of tools in AppImageCommunity to decide which architectures to build for. AppImageCommunity is a "do-ocracy": The one who does decides (so, this would apply for AppImageUpdate as is in AppImageCommunity)
All reactions
-
👎 1 -
❤️ 4
Oh, why didn't I think of that? Think of the people using 30 year old hardware!
All reactions
Oh, why didn't I think of that? Think of the people using 30 year old hardware!
Ahhhh kids these days.
I work in the world of medical devices. Once we go through FDA 510K approval process, nothing can change in the development system. There is a drug manufacturer in California that has a PDP 11/70 running RSTS/E controlling a manufacturing line. The have lots of spare parts, and hold their breath. They are sole source so I pray I never get whatever disease it's for. Yes, I get a call because I've worked on RSTS/E on a PDP 11/70
Every couple of years I get a phone call from Harman (sp?) to go on-site to work on some heart device using OS/2 and Qt/3.
The sheer cost and effort of going through 510K means you never touch it.
As to the third world countries running 30 year old systems, they are providing the low-cost/free developers keeping the 32-bit support working in the distros previously listed. If they aren't coming here in droves it would be:
- Your stuff won't run on their systems
- They don't know about you.
Both situations can be fixed.
All reactions
-
👀 1
I am still running computers from 1984. So no worries.
All reactions
How sad. The medical device maintainers can do it themselves then.
All reactions
I am still running computers from 1984. So no worries.
Wow! Do you have my NCR PC4 dual floppy computer? I built a wood enclosure for it so I could have an extra power supply and 20MEG hard drive!
First machine I ever bought. I see people in the retro markets bringing them back to life.
There are days I miss that ole thing. The ghosting green phosphorus monitor where you could hear the text display like tiny paint brushes on the glass. That and the chirping Seagate 20Meg made for calming sounds while debugging.