Skip to content
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

Open
TheAssassin opened this issue Aug 28, 2022 · 9 comments
Open

Drop i386 (x86) entirely #1208

TheAssassin opened this issue Aug 28, 2022 · 9 comments

Comments

@TheAssassin
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

TheAssassin commented Sep 14, 2022

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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

@TheAssassin
Copy link
Member Author

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

@probonopd
Copy link
Member

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
Copy link
Member Author

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

@probonopd
Copy link
Member

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants