On Tue, 6 Jun 2023 at 11:46, Simon McVittie <s...@debian.org> wrote: > > On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote: > > Judging from the conversation, killing i386 quite obviously is desired > > by some participants, but evidently not by all. How quickly we want to > > kill it is not obvious to me. > > When considering the future of i386, a factor that we need to bear in > mind is that there are two major use-cases for i386, with requirements > that sometimes conflict: > > 1. i386 as a fully-featured architecture that you can run independently > on 32-bit x86 systems from roughly the 2000-2010 era > > 2. i386 as a multiarch foreign architecture to run legacy binaries on > modern x86_64 systems > 2a. legacy native Linux i386 binaries > 2b. legacy Windows i386 binaries via Wine (which requires a somewhat > complete i386 Linux library stack) > > For example, Ubuntu has ceased to support i386 for the first use-case, > and only supports the second use-case. I personally think that Ubuntu > has made a good pragmatic decision here, which Debian should seriously > consider adopting.
+1 Given native 32-bit x86 hardware is no longer produced (and has not been produced for a good while), so it has a de-facto limited life, as consumer-grade electronics are what they are. Let's say hypothetically that Trixie is the last full-i386 release, going out in 2025 plus 10 years of LTS+ELTS support that gives a supported OS till 2035, just shy of the Y2038 deadline and with ~25 years of full support for the most recent piece of hardware that was produced. And it's not like those OSes versions are going to evaporate into thin air at that point - they can still be used. Probably should not be connected to the open internet and used to browse the web, but realistically already today I doubt browsing the modern web is a good experience on 32bit hardware from 2010, I can't imagine it would much better be in 2035... On the other hand, i386 binaries that can run on x86_64 are realistically going to be around for much, much longer as you pointed out, so to me prioritizing this use case seems more prudent and future-proof between the two alternatives. Kind regards, Luca Boccassi
