Re: Release status of i386 for Bullseye and long term support for 3 years?
(Please cc me, I'm not subscribed.)
Andrew M.A. Cater wrote:
> Having participated in the current discussion about 32 bit releases and
> lifetimes in Linux Weekly News (lwn.net) - what's the status of i386 for the
> lifetime of Bullseye?
>
> There seems to be only one maintainer.
>
> Is i386 going to be supportable for the next 3 1/2 years and buildable for
> that long (given that almost all machines are now 64 bit capable and we're
> having to build some packages on amd64 for i386 - per ballombe)?
I think it's necessary to consider what the purpose of the i386 port is,
and set expectations and an appropriate baseline based on that.
I see two possible use-cases for i386:
1. It's a compatibility layer for legacy 32-bit binaries on x86_64 CPUs:
in particular, proprietary 32-bit binaries that we cannot recompile,
32-bit builds of Wine, and the dependency stacks for those
2. It's something you can genuinely run on older (or more-embedded)
32-bit x86 CPUs that do not support x86_64 (down to some arbitrary
baseline, currently i686 without MMX or SSE)
Ubuntu have chosen to support the first use-case, and only the first
use-case. They longer ship a complete, bootable i386 operating system;
instead, they have an i386 second-class-citizen architecture that
is sufficient to provide graphics drivers and other shared libraries
for legacy 32-bit proprietary binaries. Debian infrastructure doesn't
currently support second-class-citizen, multiarch-only architectures that
are not independently bootable, but until we do, we could approximate
this by booting an i686 bootloader, kernel and library stack on x86_64
bare metal (as long as it supports BIOS boot), or more likely in practice,
on x86_64 virtual machines - which in practice is how we do i386 buildds
and other infrastructure already. The next step towards what Ubuntu do
would be to require 32-bit i386 user-space to be run on an x86_64 kernel,
similar to the way the s390 port used to work (if I remember correctly).
If it's only the first use-case that is supported, then our current
baseline for i386 is unnecessarily pessimistic, and indeed harmful to
performance and consistency with other architectures: all x86_64 CPUs are
required to offer MMX, SSE and other nice things, so we could raise the
baseline to include those and stop patching packages to avoid using them,
which would remove i386's major oddity when compared with other
architectures (i387 extended-precision floating point).
Also, if we are only supporting i386 for my first use-case, then I think
we should seriously consider waiving the archive-completeness metric
for i386: if big packages like web browsers and Libreoffice can't be
compiled on 32-bit, then so be it. We only need to be able to compile
a library stack, plus enough programs to be able to build and test that
library stack on virtual or real hardware.
If the second use-case is supported, then we are going to need an i386
porter team analogous to any other architecture porting team, that can
take responsibility for choosing an achievable baseline for the oldest
i386 CPU that they intend to test and support, triaging i386-specific
bugs, and providing patches where necessary to keep packages below that
baseline (which will require an increasing amount of work over time if
they choose a baseline that is suitable for historical x86 CPUs, since
increasingly many upstreams refuse to support the i387 FPU). I don't
think it's reasonable any more to expect individual package maintainers
to understand the finer points of the historical x86 instruction set.
One factor that makes the second use-case difficult to support is
that even if developers still have old 32-bit x86 hardware, it's very
likely to be considerably newer than our current baseline. For example,
mainstream Intel and AMD 32-bit CPUs gained SSE support around 20 years
ago (Pentium III and Athlon XP). I know there are somewhat newer x86
embedded CPUs with lesser capabilities, but most developers would have
to have deliberately chosen to obtain those, rather than having access
to old machines just because they haven't disposed of them yet.
I don't think it's realistic to drop i386 completely, and I want to
be able to continue to run legacy 32-bit games; so if an i386 porter
team doesn't materialize otherwise, I'd be willing to help to maintain a
version of i386 that is intended to be a compatibility library stack for
x86_64 machines (similar in scope to what Ubuntu does). However, I am not
willing to spend my time on making packages use i387 in preference to SSE.
smcv
Reply to: