-
-
Notifications
You must be signed in to change notification settings - Fork 559
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop i386 (x86) entirely #1208
Comments
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. |
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"?
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. |
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. |
I find it hard to believe that a) these notebooks work reasonably well after > 14 years (especially performance wise) 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... |
You do not need to invest time. I've already invested it. |
This discussion is pointless, since you ignore the previous conversation. |
I was indeed just talking about this repository, which will not hold much code besides the runtime anymore in the future. |
Maintaining the runtime only would be an acceptable trade-off to me. It's relatively easy to cross-compile even. |
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) |
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.)
The text was updated successfully, but these errors were encountered: