[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Defaulting to i686 for the Debian i386 architecture

Ben Hutchings wrote:
> We propose to drop support for i386 processors older than 686-class in
> the current release cycle.  This would include folding libc6-i686 into
> libc6, changing the default target for gcc, and changing the 586 kernel
> flavour to 686 (non-PAE).
> Since the 686-class, introduced with the Pentium Pro, is now almost 20
> years old, we believe there are few Debian systems still running that
> have 586-class or hybrid processors.  The only such processors
> apparently still available for sale are the DM&P Vortex86 family, Intel
> Quark and Xeon Phi, of which we currently only support the Vortex86.

Debian i386 currently works just fine on Quark processors; the only
special support required for Quark lives in the kernel (e.g. handling an
MSR that the Pentium had but Quark doesn't), and the Linux kernel
already has that support.  Please don't break that.  While people
building a production system for Quark may well build a custom embedded
installation image, it's extremely useful to be able to boot a "stock"
Debian installation or live distribution on a Quark board.

Many distributions have already dropped that support, making it all the
more valuable that Debian hasn't.  I can certainly understand dropping
i386 and i486, but i586 remains useful today precisely because of Quark.
Deprecating old systems that don't get built anymore would seem
perfectly reasonable; however, people buy these systems new today, and
will continue to do so in the future.

Now, that said, I do think it makes sense to fold the libc6-i686 package
into libc6, while keeping the library separate; the extra disk usage
seems worth it to provide a better experience for many 32-bit
distribution users.

It also seems reasonable for certain classes of packages to not bother
with i586 support, such as office suites, desktop environments,
graphical web browsers, media libraries, and anything depending on a
GUI.  (Ideally, some obvious mechanism would exist to distinguish those
packages, so that the package manager would prevent the installation of
packages that will SIGILL.)

- Josh Triplett

Reply to: