Re: Release status of i386 for Bullseye and long term support for 3 years?
On Tue, Dec 08, 2020 at 05:46:26PM +0000, Simon McVittie wrote:
>...
> 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)
There are at least two more:
3. Computers that do support MMX and SSE2, but do not support 64bit.
AFAIR the last 32bit-only CPU from Intel was released in 2007.[1]
Then there was the short netbook boom, but AFAIR some early ones
had 64bit CPUs but 32bit-only firmware.
Surprisingly many netbooks are still in use even in first-world
countries.[2]
4. People who wrongly installed i386 on amd64-capable hardware.
The existing userbase with this setup is large, and even though
crossgrades are now finally possible it is better to wait until
there are fewer users in this setup and more potential crossgrade
issues resolved.
> 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.
>...
Ubuntu has a business-minded focus, which is fair enough.
But Debian should not blindly follow whatever Canonical
does with Ubuntu for business reasons.[3]
It does make sense for Debian to differenciate by providing support for
communities whose hardware is not or no longer supported by Ubuntu.
>...
> 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).
While this specific oddity is unique to the i386 port,
it is worth mentioning that every port has its own oddities.
> 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.
There is also a cost associated with having to modify packages for
handling such port-specific omissions.
One current example for missing archive-completeness would be s390x,
and I guess you are aware how much pain its headless nature has caused
in some places.
> 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.
This is correct.
This is exactly porter work, and this is what I have already been doing
for years for i386.
A large part of porter work is being a one-trick pony, often submitting
the same fix for many packages. For i386 this is usually some variant of
ifneq (,$(filter $(DEB_HOST_ARCH), i386))
export DEB_CXXFLAGS_MAINT_APPEND += -ffloat-store
endif
> 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.
It is not realistic to expect porters to have hardware matching exactly
the port baseline.
How many people do have hardware matching exactly our amd64 baseline?
Does hardware matching exactly our amd64 baseline even exist?
> 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.
Note that the latter is only a problem for use-case 2,
use-case 3 is still a full port but does not have this problem.
I have volunteered as an i386 porter exactly for helping to keep the
port alive on older hardware, and the FPU issues/workarounds in
packages are where I have been working on mostly.
i386 hardware is so numerous and widely spread, that every tiny fraction
of i386 users might be more users than half of our release architectures
combined. It is not even clear whether this is just an exaggeration or
might be literally true:
There are users running unstable on non-SSE i386 hardware reporting bugs
when code wrongly uses SSE, on another buster release architecture it
was discovered only a year after the release that the buster installer
was nonfunctional.
There were surprisingly many users complaining that their hardware was
no longer supported after the i386 baseline was raised from 586 to 686
in stretch.
> smcv
cu
Adrian
[1] ignoring the Quark, that is anyway not supported by the i386 port
[2] often for financial reasons - most people in IT are so affluent that
they don't even realize how unaffordable 100 Euro investments are
for many people
in some countries there was also a rush to refurbish ancient
hardware for school children this spring
[3] neither should Debian blindly do the opposite
Reply to: