Re: 64-bit time_t transition for 32-bit archs: a proposal
On Tue, 6 Jun 2023 at 11:46, Simon McVittie <smcv@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
Reply to: