On Mon, 10 Jun 2024 at 12:43:27 +0000, Stefano Rivera wrote:
> The point here is that the Debian project is not intending to support
> new hardware on the i386 architecture. The architecture is being kept
> around primarily to support running old i386 binaries.
... and the most appropriate answers to some technical questions are not
going to be the same for "i386 to run legacy 32-bit binaries on 64-bit
CPUs" and "i386 to run on 32-bit CPUs", so we cannot simply support
both equally.
> We didn't bring 64bit time_t to the architecture, because of this goal.
This is a good example of a decision that goes differently for those two
purposes. If we want to run legacy i386 binaries, 64-bit time_t would
be counterproductive, because it will break some of those binaries *now*
(not just in 2038).
Raising the baseline (to i686 or beyond) is another decision that would
go differently for those two purposes. For legacy i386 binaries on an
x86_64 CPU, the baseline could raise as far as i686 + SSE + SSE2 without
losing any 64-bit CPU support, because SSE and SSE2 are part of the
x86_64 baseline; but for genuinely 32-bit CPUs, as discussed in this
thread and elsewhere, even i686 is sometimes too high.
> There isn't a team working on a modern 32 bit x86 port. We're just
> trying to keep the old one going for as long as we can. You're welcome
> to try to form such a team, of course :)
The "i386" name is widely hard-coded in third-party software (e.g. Steam)
as being the appropriate architecture to use to run legacy 32-bit
binaries on a 64-bit CPU, so if we were to fork i386 into two separate
ports (one for legacy binaries on 64-bit CPUs, and one for 32-bit CPUs),
the route that would avoid breaking backwards-compatibility would be for
the i386 name to stay with the port that is intended for legacy binaries,
introducing a new name for the port that is intended for 32-bit CPUs.
(This is because by definition legacy binaries are legacy, and are not
going to change to accommodate new decisions, whereas a new port can
produce new binaries with code changes if enough effort is put into
doing so.)
If people want a distribution to run on 32-bit x86 CPUs badly enough,
one possible route would be to start a new port (perhaps called ia32,
i386t64 or something similar) for that use-case; it would have a baseline
that is as low as its maintainers want it to be (i586?), and a 64-bit
time_t for post-2038 future-proofing.
As far as I'm aware, nobody is yet putting effort into doing this. Also,
several important upstreams no longer consider i386 to be useful (and
especially i386-without-SSE2), so so the burden of supporting 32-bit
CPUs in modern software will fall on the downstream developers who have
chosen that their aim is to support 32-bit CPUs.
And, for several larger packages it is becoming a serious problem
to compile and link the software natively on any 32-bit architecture,
because the working set for the compiler or linker is larger than 4 GiB,
but a 32-bit architecture can't possibly address more than 4 GiB of
virtual memory at a time.
Those are problems that any would-be port maintainer for a "modern"
32-bit x86 port would have to deal with somehow, and telling the wider
Debian project "this is important to me, therefore it should be important
to you" is unlikely to result in those problems going away.
Alternatively...
> The cost of supporting a port of Debian is far more than the cost of the
> machines needed to build it. Never mind the cost of 1 user's machine.
As a point of comparison, a used 64-bit laptop of a well-respected
design from 12-13 years ago (Lenovo X220) seems to be readily available
for around £60 on eBay UK, and that price is enough to pay a software
consultant in the UK for somewhere around 1 hour. Of course, volunteer
effort is not directly interchangeable with consultant effort and not
every country is the UK, but the time-cost of maintaining a 32-bit port
of Debian is going to be lots of hours.
I suspect that many of the used 64-bit laptops of that age on eBay
go unsold and will instead be discarded, entering the e-waste stream,
in which case buying one as a replacement for a 32-bit machine is not
a net increase in e-waste.
(No endorsement of eBay intended, other sources of refurbished computers
are available.)
smcv
