search

AppImage / AppImageKit

Package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives. Join #AppImage on irc.libera.chat
http://appimage.org
Other
8.69k stars 557 forks source link

Drop i386 (x86) entirely #1208

Open TheAssassin opened 2 years ago

TheAssassin commented 2 years ago

This architecture has been deprecated and obsolete for over a decade, and nobody should invest any time into maintaining packaging for it. The maintenance burden has become too large, and most Linux distros have dropped support years ago, too.

(Note: this obviously doesn't include non-x86 32-bit platforms such as AArch32. Arguably, AArch32 is outdated, too.)

probonopd commented 2 years ago

Which maintenance burden specifically? The overhead of building the runtime and helper tools for one additional platform using the https://github.com/probonopd/static-tools/ approach seems to be negligible, and the work has already been done. It's not that long ago that 32-bit only Atom netbooks were sold.

TheAssassin commented 2 years ago

You can imagine that it's just annoying to tweak CI stuff, fix broken scripts, etc. This issue is about the entirety of AppImage, not just this repository. Again, it makes no sense at all to support i386. Distros rightfully have dropped their support. There is no justification for spending time on any of this. Even if it's "just" 10 or 20 minutes, those minutes are wasted.

Edit: obviously in this repository after struggling initially it's been working reasonably well. However, you probably don't see the amount of work going into repositories like AppImageBuild, which are essential to this repository's CI. You just build some helpers, but AppImageBuild

Do you have any good argument for retaining i386 support? I mean, other than "we've always done it" and "it seems to work right now in this moment"?

It's not that long ago that 32-bit only Atom netbooks were sold.

All Atoms had 64-bit support starting with the second generation that was released in 2008. That's 14 years. What's the point of that example? It just proves my point that i386 has been irrelevant for over a decade.

probonopd commented 2 years ago

As you may remember, we want to restructure AppImageKit to hold only the runtime. And I have set up a way to build the static runtime without CMake, AppImageBuild, or other similar tools. So once we do the switch, I don't see why the runtime should not continue to be offered for 32-bit Intel.

I happen to have 2 of those netbooks, which I still want to use.

TheAssassin commented 2 years ago

I find it hard to believe that

a) these notebooks work reasonably well after > 14 years (especially performance wise) b) you use these regularly

This is an extreme edge case and I do not intend to invest time into providing the theoretical ability for you to use hardware laying on your shelf for no good reason...

probonopd commented 2 years ago

You do not need to invest time. I've already invested it.

TheAssassin commented 2 years ago

This discussion is pointless, since you ignore the previous conversation.

probonopd commented 2 years ago

This issue is about the entirety of AppImage, not just this repository.

I was indeed just talking about this repository, which will not hold much code besides the runtime anymore in the future. My tools will continue to support i386 as long as it is not a major hassle for me, and for this to work I need a i386 runtime.

TheAssassin commented 2 years ago

Maintaining the runtime only would be an acceptable trade-off to me. It's relatively easy to cross-compile even.

probonopd commented 1 year ago

Maybe this points to a bigger underlying topic: Possibly we can simplify the whole build process so something like we are doing in https://github.com/AppImage/type2-runtime/? (Using alpine Linux choot, musl libc, and static linking rather than relying on legacy versions of CentOS)