Re: Defaulting to i686 for the Debian i386 architecture

[Lars Wirzenius]

On Tue, Oct 06, 2015 at 04:45:08PM +0300, Konstantin Khomoutov wrote:
> A minor heads-up: your script incorrectly uses "tac" instead of "tsc".

If anyone wants to put this into a package, please fix that. :)

Would it be useful to have something like that script in a package? If
so, which package?

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh

Re: Defaulting to i686 for the Debian i386 architecture

[Philip Hands]

Philip Hands  writes:
> For those wanting to check their systems, this may help:
>
>   sed -ne '/^flags /{s/\b\(fpu\|tsc\|cx8\|cmov\)\b/%/g;s/[^%]*//g;s//i686 
> SUPPORTED/p}' /proc/cpuinfo

Oops - that's meant to be a TAB.  Make that:

  sed -ne '/^flags\t/{s/\b\(fpu\|tsc\|cx8\|cmov\)\b/%/g;s/[^%]*//g;s//i686 
SUPPORTED/p}' /proc/cpuinfo

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Defaulting to i686 for the Debian i386 architecture

[Lars Wirzenius]

On Tue, Oct 06, 2015 at 10:47:43AM +0200, Jakub Wilk wrote:
> * Philip Hands , 2015-10-06, 09:35:
> > sed -ne 
> > '/^flags\t/{s/\b\(fpu\|tsc\|cx8\|cmov\)\b/%/g;s/[^%]*//g;s//i686 
> > SUPPORTED/p}' /proc/cpuinfo
> 
> Or a more readable version:
> 
> [ $(lscpu | grep ^Flags: | grep -owE 'fpu|tsc|cx8|cmov' | wc -l) = 4 ] && 
> echo i686 SUPPORTED

Phil's second one works for me, yours does not, on a CPU identified as
"Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz" in /proc/cpuinfo. I don't
really know what the right test is (I don't keep of CPU changes), but
I changed Phil's sed into a shell script that I find more readable.
Attached. Hopefully that's helpful to someone and not too badly wrong.
#!/bin/sh

set -eu

# Get CPU feature flags from /proc/cpuinfo.

get_flags()
{
sed -ne '/^flags\t*: /s///p' /proc/cpuinfo | tr ' ' '\n'
}


# Do we have the right flags for an i686?

if get_flags | grep -Ee 'fpu|tac|cx8|cmov' > /dev/null
then
echo "i686 is supported" 
else
echo "i686 is NOT SUPPORTED" 1>&2
exit 1
fi

Re: Defaulting to i686 for the Debian i386 architecture

[Jakub Wilk]

* Philip Hands , 2015-10-06, 09:35:

 sed -ne '/^flags\t/{s/\b\(fpu\|tsc\|cx8\|cmov\)\b/%/g;s/[^%]*//g;s//i686 
SUPPORTED/p}' /proc/cpuinfo


Or a more readable version:

[ $(lscpu | grep ^Flags: | grep -owE 'fpu|tsc|cx8|cmov' | wc -l) = 4 ] && echo 
i686 SUPPORTED

--
Jakub Wilk

Re: Defaulting to i686 for the Debian i386 architecture

[Philip Hands]

Ben Hutchings  writes:

> On Mon, 2015-10-05 at 20:43 +0200, Christoph Biedl wrote:
>> 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).
>> 
>> Could please provide information that helps to identify systems
>> affected by this? Probably that is absence of certain flags in
>> /proc/cpuinfo. FWIW, I suspect none of my remaining i386 installations
>> will have issues from that switch but I'd like to know in advance.
>
> So far as I know the required feature flags are: fpu tsc cx8 cmov;

For those wanting to check their systems, this may help:

  sed -ne '/^flags /{s/\b\(fpu\|tsc\|cx8\|cmov\)\b/%/g;s/[^%]*//g;s//i686 
SUPPORTED/p}' /proc/cpuinfo

which will output 'i686 SUPPORTED' only when those four flags are set
(assuming that '%' never normally appears in the flags line).

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Defaulting to i686 for the Debian i386 architecture

[Jakub Wilk]

* Lars Wirzenius , 2015-10-06, 12:04:

sed -ne '/^flags\t/{s/\b\(fpu\|tsc\|cx8\|cmov\)\b/%/g;s/[^%]*//g;s//i686 
SUPPORTED/p}' /proc/cpuinfo

Or a more readable version:

[ $(lscpu | grep ^Flags: | grep -owE 'fpu|tsc|cx8|cmov' | wc -l) = 4 ] && echo 
i686 SUPPORTED


Phil's second one works for me, yours does not,


Oops. You need util-linux (>= 2.27). Previous versions of lscpu didn't 
output CPU flags.


--
Jakub Wilk

Re: Defaulting to i686 for the Debian i386 architecture

[Konstantin Khomoutov]

On Tue, 6 Oct 2015 12:04:29 +0300
Lars Wirzenius  wrote:

> On Tue, Oct 06, 2015 at 10:47:43AM +0200, Jakub Wilk wrote:
> > * Philip Hands , 2015-10-06, 09:35:
> > > sed -ne '/^flags\t/{s/\b\(fpu\|tsc\|cx8\|cmov\)\b/%/g;s/[^%
> > > ]*//g;s//i686 SUPPORTED/p}' /proc/cpuinfo
> > 
> > Or a more readable version:
> > 
> > [ $(lscpu | grep ^Flags: | grep -owE 'fpu|tsc|cx8|cmov' | wc -l) =
> > 4 ] && echo i686 SUPPORTED
> 
> Phil's second one works for me, yours does not, on a CPU identified as
> "Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz" in /proc/cpuinfo. I don't
> really know what the right test is (I don't keep of CPU changes), but
> I changed Phil's sed into a shell script that I find more readable.
> Attached. Hopefully that's helpful to someone and not too badly wrong.

Hi!

A minor heads-up: your script incorrectly uses "tac" instead of "tsc".

Re: Defaulting to i686 for the Debian i386 architecture

[Konstantin Khomoutov]

On Tue, 6 Oct 2015 18:52:28 +0300
Lars Wirzenius  wrote:

> > A minor heads-up: your script incorrectly uses "tac" instead of
> > "tsc".
> 
> If anyone wants to put this into a package, please fix that. :)
> 
> Would it be useful to have something like that script in a package? If
> so, which package?

To me, this is something to probably put into the release notes for the
next release if the original proposition will have been implemented
for it.  The package will probably be a too heavy-weight solution for
this problem IMO: those affected will supposedly be able to perform the
"/bin/sh + copy-and-paste + ^D combo" to check their systems.

Re: Defaulting to i686 for the Debian i386 architecture

[Christoph Biedl]

Konstantin Khomoutov wrote...

> On Tue, 6 Oct 2015 18:52:28 +0300
> Lars Wirzenius  wrote:
> 
> > Would it be useful to have something like that script in a package? If
> > so, which package?
> 
> To me, this is something to probably put into the release notes for the
> next release if the original proposition will have been implemented
> for it.

That was too late, assuming too many people will miss that
announcement in the release notes (if they read them at all). Usually,
the punishment for such laziness is broken dependencies or
configurations that need extra handwork to fix. In this case
however, people will find themselves with a completely broken system
once the first essential binaries have been updated and crash for
illegal instructions. This is too harsh.

Therefore there should be an extra safeguard against that situation.

A simple solution was to use base-files in all upcoming jessie point
release as the messenger "It appears your system will no longer be
supported in stretch, do not update".

The sane solution was to bootstrap a new architecture "i686" and use
multiarch cross-upgrade to switch, something that will hopefully be
almost as simple as a regular dist-upgrade by then. Using the "dpkg
--add-architecture" invocation for a CPU capability check and warning
sounds a bit strange, though. There might be better places, as long as
this happens before the first i686-only executable hits the file
system.

Those users who ignore the instructions in the release notes will stay
on stretch until they realize their fault, and no harm done.
Additionally, this leaves the "i386" architecture name for any
volunteers who'd like to continue it as a debian-port.

Indeed I'd prefer the latter, but I'm probably not the one who will
have to implement it :)

Christoph

Re: Defaulting to i686 for the Debian i386 architecture

[Christoph Biedl]

Ben Hutchings wrote...

> So far as I know the required feature flags are: fpu tsc cx8 cmov;
> and the CPUs that have them are:

Thanks for that. So for the records, VIA C3 Ezra and AMD-K6 lack
cmov and therefore will fall out of support. I see no reason why 
there should be an exception for these, in other words: This is not a
complaint.

Christoph

Re: Defaulting to i686 for the Debian i386 architecture

[Christoph Biedl]

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).

Could please provide information that helps to identify systems
affected by this? Probably that is absence of certain flags in
/proc/cpuinfo. FWIW, I suspect none of my remaining i386 installations
will have issues from that switch but I'd like to know in advance.

Christoph

Re: Defaulting to i686 for the Debian i386 architecture

[Ben Hutchings]

On Mon, 2015-10-05 at 20:43 +0200, Christoph Biedl wrote:
> 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).
> 
> Could please provide information that helps to identify systems
> affected by this? Probably that is absence of certain flags in
> /proc/cpuinfo. FWIW, I suspect none of my remaining i386 installations
> will have issues from that switch but I'd like to know in advance.

So far as I know the required feature flags are: fpu tsc cx8 cmov;
and the CPUs that have them are:

* AMD Geode GX, LX, SC1200
* Cyrix MII
* Intel Pentium M 'Banias'
* NSC Geode GXLV(?), GX1, GX/GX2, GXm, SC1100
* Transmeta Crusoe
* VIA C3-2 'Nehemiah'

These CPUs additionally have pae and can run the 686-pae flavour:

* AMD Geode NX, Athlon (K7), Athlon 64, Duron, Opteron, Sempron,
  Turion, Phenom, etc.
* Intel Pentium Pro/II/III/4/4M/D, Xeon, Core, Atom, Pentium M 'Dothan',
  Celeron, etc.
* Transmeta Efficeon
* VIA C7, Nano

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source

signature.asc
Description: This is a digitally signed message part

Re: Defaulting to i686 for the Debian i386 architecture

[Axel Beckert]

Hi,

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).

Please don't. It already hurt that i486 support was dropped with
Jessie and i468SX (Vortex86 SX, http://www.vortex86.com/?p=145) with
IIRC Wheezy.

> 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 Vortex86 family, Intel
> Quark and Xeon Phi, of which we currently only support the Vortex86.

I own several of Vortex86 based machines and we also have some at work
as backend for some 40" displays which show upcoming events running
iceweasel in fullscreen mode and ratpoison as invisible window
manager, running Debian:
https://people.phys.ethz.ch/~abe/MicroClientJr/ (texts in German)

I also have a Thinkpad 760ED (Pentium 1) running Debian 8 Jessie. With
self-compiled X driver (xserver-xorg-video-trident), because it was
unfortunately RM'ed for no real reason (no RC bugs, nothing, the new
upstream releases still compile and work fine on Jessie) and I noticed
it only after the Jessie release.

> Indeed, the likely reasons for users to choose i386 over amd64 today
> are to reduce memory consumption or to run i386 binaries for which the
> source is not available - not because they're using 32-bit processors.

That's what x32 is meant for. Please keep i386 for legacy hardware and
propagate x32 for such purposes.

> * Can require user intervention to install optimised library packages
>   e.g. debootstrap does not install libc6-i686

That's a debootstrap issue then IMHO.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Re: Defaulting to i686 for the Debian i386 architecture

[Steven Chamberlain]

Hi,

Matthias Klose wrote:
> question to the Hurd and KFreeBSD maintainers ... change that on
> these platforms too?

I have a fanatical preference for compatibility over performance.  So
I prefer not to lose support for 586, but I don't know how practical
it would be for libc maintainers to do that only for kfreebsd.

kfreebsd-i386 has 686 (with SMP) and 486 kernel flavours.

If maybe package libc0.1-i686 had to go away, then I'd still prefer we
target 586 by default.  (For some reason, the kfreebsd installer is
failing to install that package when it should;  I forgot to install it
on all my 686s).

I'd be curious to see numbers showing the performance impact, though.

I have some of these around for testing on;  I think this device was
manufactured as 'recently' as 2006.  It is similar to the Soekris which
can still be purchased new:

cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC" 
586-class) 333 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,PGE,CMOV,MMX,MMXX,3DNOW2,3DNOW

kfreebsd-i386's particular niche is supporting ancient platforms like
these and making them still useful.  And that would be especially
important to me, if Debian GNU/Linux (and Ubuntu, Fedora etc.) no longer
worked on them.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Defaulting to i686 for the Debian i386 architecture

[Mats Erik Andersson]

Söndag den 4:e october 2015, klockan 11:55, skrev Steven Chamberlain:
> 
> I have a fanatical preference for compatibility over performance.  So
> I prefer not to lose support for 586, but I don't know how practical
> it would be for libc maintainers to do that only for kfreebsd.
> 
> kfreebsd-i386 has 686 (with SMP) and 486 kernel flavours.
> 
> cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC" 
> 586-class) 333 MHz
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,PGE,CMOV,MMX,MMXX,3DNOW2,3DNOW
> 
> kfreebsd-i386's particular niche is supporting ancient platforms like
> these and making them still useful.  And that would be especially
> important to me, if Debian GNU/Linux (and Ubuntu, Fedora etc.) no longer
> worked on them.

The PC Engines ALIX systems (http://www.pcengines.ch/alix.htm) are
still very much commercial. One system, presently running FreeBSD
in a very reliable manner, reports

  CPU: Geode(TM) Integrated Processor by AMD PCS (498.06-MHz 586-class CPU)
  Origin = "AuthenticAMD"  Id = 0x5a2  Family = 0x5  Model = 0xa  Stepping = 2
  Features=0x88a93d
  AMD Features=0xc040
  real memory  = 268435456 (256 MB)
  avail memory = 235163648 (224 MB)

It would be a sad thing to loose the possibility for running
contemporary Debian on such a system!

Best regards,
  Mats Erik Andersson

Re: Defaulting to i686 for the Debian i386 architecture

[Guillem Jover]

On Thu, 2015-10-01 at 19:15:54 +0200, Matthias Klose wrote:
> question to the Hurd and KFreeBSD maintainers ... change that on these
> platforms too?

As it currently stands, this is not a question when it comes to
dpkg, that specific change is all or nothing. The Debian ←→ GNU
cpu mapping is global for all architectures.

But as I've mentioned several times now, I think changing the GNU
triplet (only on i386) every time we bump the ISA is the wrong way
around this, and the above is another reason of why, but this has
been ignored in the past so… you'll have to sort this out.

Thanks,
Guillem

Re: Defaulting to i686 for the Debian i386 architecture

[Ben Hutchings]

On Sun, 2015-10-04 at 15:03 +0200, Axel Beckert wrote:
> Hi,
> 
> 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).
> 
> Please don't. It already hurt that i486 support was dropped with
> Jessie and i468SX (Vortex86 SX, http://www.vortex86.com/?p=145) with
> IIRC Wheezy.
[...]

I stopped reading here because this is incorrect (by 2 releases).

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.

signature.asc
Description: This is a digitally signed message part

Re: Defaulting to i686 for the Debian i386 architecture

[Andrew Kanaber]

Dimitri John Ledkov wrote:
> On 28 September 2015 at 22:44, Paul Wise  wrote:
> > Data point: I recently heard of at least one person who will need to
> > buy new hardware as a result of this change.
> Which hopefully is (a) cheap and (b) pay-off via electricity bill due
> to improved power-efficiency ?!

Not for the Via Eden ESP 533 (TDP 5W, not a 686 for lack of CMOV) I'm still
using in my TV box, and probably not in general since the non-686 processors
still in use are likely to be low-power embedded chips. Ben mentioned
Vortex86, and AMD Geode can also be problematic not supporting NOPL (and
returns CPUID family 5, i.e 586).

Andrew

Re: Defaulting to i686 for the Debian i386 architecture

[Ben Hutchings]

On Sat, 2015-10-03 at 22:06 +0100, Andrew Kanaber wrote:
> Dimitri John Ledkov wrote:
> > On 28 September 2015 at 22:44, Paul Wise  wrote:
> > > Data point: I recently heard of at least one person who will need to
> > > buy new hardware as a result of this change.
> > Which hopefully is (a) cheap and (b) pay-off via electricity bill due
> > to improved power-efficiency ?!
> 
> Not for the Via Eden ESP 533 (TDP 5W, not a 686 for lack of CMOV) I'm still
> using in my TV box, and probably not in general since the non-686 processors
> still in use are likely to be low-power embedded chips.

There are several Atom models with lower TDP than that.

> Ben mentioned
> Vortex86, and AMD Geode can also be problematic not supporting NOPL (and
> returns CPUID family 5, i.e 586).

The Linux kernel doesn't use it in any 32-bit configuration:
https://git.kernel.org/linus/ba0593bf553c450a03dbc5f8c1f0ff58b778a0c8

gas was also changed to not generate long-NOPs when the target is the
generic 'i686' rather than a specific core:
https://sourceware.org/ml/binutils-cvs/2010-08/msg00057.html

So the Geode processors should remain supported.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.

signature.asc
Description: This is a digitally signed message part

Re: partial architectures -- was: Re: Defaulting to i686 for the Debian i386 architecture

[Wookey]

+++ Manuel A. Fernandez Montecelo [2015-09-29 22:14 +0100]:
> 2015-09-29 17:38 Wookey:
> >+++ Manuel A. Fernandez Montecelo [2015-09-29 12:27 +0100]:
> >>
> >>Maybe it would be a good idea to split the architectures, and have one
> >>port for legacy-but-still-sold-or-useful i386 and move the current i386
> >>to only support newer, common-use i686 hardware.
> >
> >It seems to me that this relates to a similar issue with armel, and
> >previous consideration of 'partial architectures' for mips (and arm).
> >
> >[...]
> >Having a mechanism for 'partial architectures' to keep only the
> >relevant subset of the archive available for these machines seems like
> >a good plan, useful for at least i386 and armel, and probably
> >others. Because a debian arch refers to an ABI, not an ISA-variant,
> >you can't easily use our existing architectures mechanism to have both
> >'i386' and 'i686' without breaking some fairly fundamental assumptions.
> >
> >Being able to have 'partial achitectures' which are actually different
> >baseline ISAs (586, 686) (armv6, armv7) for one ABI is something that
> >has been discussed many times, but no-one has ever cared enough to
> >actually implement it.
> >
> >This is particularly relevant on mips, where inconsistent ISA changes
> >over the years mean that make picking one 'base ISA' is very
> >unsatisfactory, and they would like a way of having alternative ISA
> >(not ABI) builds of a significant set of packages (anthing where speed
> >actually matters, so libc, some core things and anything
> >codec-related, at least). (The rasbian port could have done things
> >this way and stayed within Debian for example, but it was easier to
> >derive).
> >
> >Some details of a proposal for implemnting this are covered in section
> >2 of https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results
> >It would need fleshing out some more to actually be complete.
> 
>  (These ideas could also be applied for packages compiled with special
>  characteristics, like optimised for multimedia instructions; or
>  compiled with address sanitiser, undefined behaviour sanitiser, etc --
>  somebody was talking about this in DebConf, I think that it was
>  Bálint).
> 
> Honest question, not a snarky one; but after reading your e-mail and the
> proposal it is still not very clear to me what's the fundamental
> underlying difference (or the advantage, in terms of which problems
> solves better, and how) between a partial architecture, a full
> architecture which possibly doesn't build a [large?] subset of packages
> (there are mechanisms like "not-for-us" and "package-arch-specific",
> which you probably know better than me), and an "overlay"-like
> repository such as experimental or security-updates (although I am aware
> that overlays don't get packages to build in the same way as arches, one
> has to target them).

Right, to some degree the same effects can be achieved in various
ways. And there are various pros/cons.

> If I understand correctly what I read from partial arches, there has to
> be a common baseline and baseline has to be the lowest common
> denominator, in the case of i386/i686 (or armel/armhf),

Some confusion here:

i386 is a Debian arch and thus an ABI. The
baseline ISA can be 486, 586, 686.

armel and armhf are _different_ ABIs (and thus debian architectures),
whose respective baseline ISAs are armv4t and armv7 respectively.

Nevertheless, I think you have understood the concept of each ABI
having a 'lowest common denominator' ISA. I'll just ignore the
confused use of 'armel' as an example of an ISA, not an ABI, below.

> the baseline has
> to be i386 or armel (so you can boot in the baseline, and then enable
> the "flavour"/partial-arch more suited to your hardware).  And since in
> the example of Intel it is widely used and capable hardware, people
> could want almost every package.  If armel cannot cope with some
> packages (e.g. 32-bit arches already having real trouble
> compiling/linking some packages), the packages would be put in some
> "not-for-us", or simply let to fail, as it probably happens already.
> 
> In that case, the amount of compiled packages would be about the same,
> the storage about the same, etc.  The only thing that we would reuse is
> a small set of packages that allow users to start the machine and enable
> the "flavour".  I don't think that there would be much difference with
> having two full architectures?

Possibly. The main thing is that debian architectures define an ABI,
and lots of basic tools reply on this. Various things could break, or
at least not do what you expect if we had two arches called 'i386' and
'i686', which were the same ABI. e.g ask dpkg which 'architecture' you
are running on after installing 'i686' and it would return 'i386'.

This is why the proposal for a different mechanism based on HWCAPS and
a dpkg field to distinguish between different baselines/instructions
builds of an arch/ABI, exists.

And in practice (for x86/i386) you 

Re: Defaulting to i686 for the Debian i386 architecture

[Samuel Thibault]

Hello,

Matthias Klose, le Thu 01 Oct 2015 19:15:54 +0200, a écrit :
> question to the Hurd and KFreeBSD maintainers ... change that on these
> platforms too?

I don't see a reason not to. i686 libc works fine on hurd-i386 at least.
I haven't tried on kfreebsd.

Samuel

Re: Defaulting to i686 for the Debian i386 architecture

[Matthias Klose]

question to the Hurd and KFreeBSD maintainers ... change that on these platforms 
too?


On 28.09.2015 23:14, 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 Vortex86 family, Intel
Quark and Xeon Phi, of which we currently only support the Vortex86.
Indeed, the likely reasons for users to choose i386 over amd64 today
are to reduce memory consumption or to run i386 binaries for which the
source is not available - not because they're using 32-bit processors.

The older processors would of course continue to be supported in jessie
until at least 2018, and until 2020 if i386 is included in jessie LTS.

Maintaining support for these older processors hurts the Debian i386
architecture in several ways:
* Prevents optimisation for 686-class without run-time checks or
   multiple library builds
* Divergence from upstream code in various packages which often assume
   at least 686-class processors
* Can require user intervention to install optimised library packages
   e.g. debootstrap does not install libc6-i686

- Ben Hutchings
- Aurelien Jarno
- Matthias Klose

Re: Defaulting to i686 for the Debian i386 architecture

[Raphael Hertzog]

On Wed, 30 Sep 2015, Iustin Pop wrote:
> Anyway, what I mean to say: thanks for finally motivating me to upgrade.
> This move definitely makes sense, but I wouldn't be so sure that there
> are no actual production systems running on a 586-only CPU.

As another data point, I have a customer which uses Debian on Vortex86
based CPU and they are actually selling small embedded computers based on
this CPU to various manufacturers (for production monitoring purpose).

So there are current use cases where 586 support is still required. That
said I'm not opposing the change as we have 5 years of jessie lifetime
left and in this kind of usage, it's really stable that matters. And in 5
years, DM (the vortex cpu manufacturer) will probably have upgraded
its CPU.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Defaulting to i686 for the Debian i386 architecture

[Paul Wise]

On Thu, Oct 1, 2015 at 8:52 AM, Raphael Hertzog wrote:

> As another data point, I have a customer which uses Debian on Vortex86
> based CPU and they are actually selling small embedded computers based on
> this CPU to various manufacturers (for production monitoring purpose).
>
> So there are current use cases where 586 support is still required. That
> said I'm not opposing the change as we have 5 years of jessie lifetime
> left and in this kind of usage, it's really stable that matters. And in 5
> years, DM (the vortex cpu manufacturer) will probably have upgraded
> its CPU.

I wonder if contacting DM about that upgrade is feasible and a good idea.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Defaulting to i686 for the Debian i386 architecture

[Jakub Wilk]

* Iustin Pop , 2015-09-30, 00:04:
My trusty soekris 5501 has an AMD Geode LX, which (AFAIK) is still only 
i586. It seems it is missing one instruction (NOPL) from being a full 
686 chip :)


gas won't emit NOPLs for 686, so you should be safe:
https://gcc.gnu.org/ml/gcc/2010-08/msg00194.html
"6. Don't generate multi-byte nops for i686.  PR 6957."

--
Jakub Wilk

Re: Defaulting to i686 for the Debian i386 architecture

[Riku Voipio]

On Mon, Sep 28, 2015 at 09:31:03PM -0700, Josh Triplett wrote:
> [Please CC me; not subscribed to -devel.]
> Ben Hutchings wrote:
> > So far as I know, all current Quark processors have errata that make
> > them unstable, not to mention totally insecure, when running ordinary
> > i386 binaries.

> News to me.  Link please?  Because I don't know what they'd run if *not*
> ordinary x86 binaries, and everyone I know targeting them builds
> ordinary x86 binaries. :)

I don't have a quark, but apparently LOCK prefix is broken:

https://sourceware.org/ml/libc-alpha/2015-05/msg00144.html

and the related debian bug with link to actual errata:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575

Riku

Re: Defaulting to i686 for the Debian i386 architecture

[Josselin Mouette]

Ben Hutchings  wrote: 
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 Vortex86 family, Intel
Quark and Xeon Phi, of which we currently only support the Vortex86.

I don’t know whether we currently have the ability to run standard x86
binaries on the Xeon Phi coprocessors, but it definitely sounds like
something we should try to obtain, not to prevent. Otherwise we’ll end
up with yet another half-assed, unmaintainable way to build specific
binaries for HPC. 

-- 
Joss

Re: Defaulting to i686 for the Debian i386 architecture

[Josh Triplett]

On Tue, Sep 29, 2015 at 06:48:26AM +, Riku Voipio wrote:
> On Mon, Sep 28, 2015 at 09:31:03PM -0700, Josh Triplett wrote:
> > [Please CC me; not subscribed to -devel.]
> > Ben Hutchings wrote:
> > > So far as I know, all current Quark processors have errata that make
> > > them unstable, not to mention totally insecure, when running ordinary
> > > i386 binaries.
> 
> > News to me.  Link please?  Because I don't know what they'd run if *not*
> > ordinary x86 binaries, and everyone I know targeting them builds
> > ordinary x86 binaries. :)
> 
> I don't have a quark, but apparently LOCK prefix is broken:
> 
> https://sourceware.org/ml/libc-alpha/2015-05/msg00144.html
> 
> and the related debian bug with link to actual errata:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575

Gah.  Thanks for the info; that's all kinds of awful.

I find myself rather astounded that stock Debian worked for me, then.
And I retract the objection; go ahead and remove i586 support.

- Josh Triplett

Re: Defaulting to i686 for the Debian i386 architecture

[Manuel A. Fernandez Montecelo]

2015-09-28 23:34 Josh Triplett:

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 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.


Maybe it would be a good idea to split the architectures, and have one
port for legacy-but-still-sold-or-useful i386 and move the current i386
to only support newer, common-use i686 hardware.  If Xeon Phi can be
accomodated in the legacy architecture as well, great.

Maybe there are not enough volunteers for the port, or none at all; but
at least getting machines shouldn't be a big problem compared to other
arches if current i686/amd64 systems can be used to compile targetting
those older instruction sets.

(I am not volunteering by the way, I have no interest in these ports,
just proposing it as a possible solution).


In a way, most people using i386 in the desktop nowadays could use x32,
but I seem to remember that in practice it still has many problems and
out-of-date or missing packages (I don't know if just because of being
understaffed, or deeper problems like many packages needing upstream
support).  Or these people also could move to amd64, but well... if they
haven't moved yet...



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.)


This is probably easier to achive with a port as well, excluding
undesided packages.


Cheers.
--
Manuel A. Fernandez Montecelo 

Re: Defaulting to i686 for the Debian i386 architecture

[Alastair McKinstry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Enigmail
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWCnjpAAoJEMvmu05dmtOlhhAP/jrONPeihYKvvXYr34m6e47B
aw3MoFNkhT3NOSMujd3mfqPIejrDwbuV3aC7puvS9DCLZDPpxqbXaUnEOj9fe/dW
MJvTn9A1vNitJNKt7cJ+OYkl+EP+dV2BIXy29+C1mId3SozbBWbFRjWBgTfVpUjb
pSnEM/h8jQM9TZC2tvvkab1BPrwpGRZBWJpSm7F8eNsqUASPcPA4KPTjOvbgcQRA
DnVwTss85qdgMKBm6V/50yLgVeAv5wOTxtDmHT+Ejdqu47s4aFp/RpGSjAVkUK0x
MkHYx1WjbTWkRs4vbd6dHn86+OM4JQGQ1rN6H1ffBtWBTMaIBLoz85o9koJhk+bs
Mmuq7UCuOqImyqj/kDHHxOBwZ9c1dxbvnlGJxzewb5p9sjucPI2JGvILzgF5wA3r
/G3KbkDg0sDnpmuxNgxbvcppfgcFh7oslfZYRE0d5Iz+rjfk7MgmVeaF7nIVdB6l
MWxyYpLOn3yQ43BVgu5xg5eY/Ow4ogHbgBXWGtHAMRn35Huf6Hw3eZt6FnSgbVr3
PtMBnZp8/ZEt8018oSD/bZf8X2U49TrleLYHCYwcebhYxe5zF8Yd8f5eha5yPSQf
+GrKkLb9qZU9zw4vTKRbTJ96PLJvmOjSWEwNRrz6hbL4qVOWnazj4xw93CiuaM9X
PIkC8uBceqfJtAbSAv6V
=9zdU
-END PGP SIGNATURE-

Re: Defaulting to i686 for the Debian i386 architecture

[Ben Hutchings]

On Tue, 2015-09-29 at 10:02 +0200, Josselin Mouette wrote:
> Ben Hutchings  wrote: 
> 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 Vortex86 family, 
> Intel
> Quark and Xeon Phi, of which we currently only support the Vortex86.
> 
> I don’t know whether we currently have the ability to run standard x86
> binaries on the Xeon Phi coprocessors, but it definitely sounds like
> something we should try to obtain, not to prevent. Otherwise we’ll end
> up with yet another half-assed, unmaintainable way to build specific
> binaries for HPC. 

Contrary to what I thought, the Xeon Phi processors are actually 64-bit
.  However I think they're a little too weird to support with the same
binaries - no CMOV, no MMX and no SSE.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates

signature.asc
Description: This is a digitally signed message part

Re: Defaulting to i686 for the Debian i386 architecture

[Josselin Mouette]

Ben Hutchings  wrote: 
Contrary to what I thought, the Xeon Phi processors are actually 64-bit
.  However I think they're a little too weird to support with the same
binaries - no CMOV, no MMX and no SSE.

I think we’ve both been mistaken by Intel documents describing Xeon Phi
as being based on the P54C microarchitecture. But this was only for the
early, mostly experimental designs. As of Knights Landing, it is based
on Airmont Atom cores which indeed support x86_64. 

-- 
Joss

Re: Defaulting to i686 for the Debian i386 architecture

[Wookey]

+++ Manuel A. Fernandez Montecelo [2015-09-29 12:27 +0100]:
> 2015-09-28 23:34 Josh Triplett:
> >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.
> 
> Maybe it would be a good idea to split the architectures, and have one
> port for legacy-but-still-sold-or-useful i386 and move the current i386
> to only support newer, common-use i686 hardware. 

It seems to me that this relates to a similar issue with armel, and
previous consideration of 'partial architectures' for mips (and arm). 

like '586-ISA i386', armel is now a port used only on low-end
hardware, but that hardware can still be bought new, primarily as NAS
boxes. Debian is one of the last distros supporting this, which makes
dropping it quite hard on those still using it.

However there is a large fraction of the archive that is not very
useful on such machines, and a part of the archive that is starting to
need major work to keep building for such hardware at all.

The main disadvantage of keeping around old arches is the effort
involved in keeping software building/working on it when the rest of
the world no longer cares.

Having a mechanism for 'partial architectures' to keep only the
relevant subset of the archive available for these machines seems like
a good plan, useful for at least i386 and armel, and probably
others. Because a debian arch refers to an ABI, not an ISA-variant,
you can't easily use our existing architectures mechanism to have both
'i386' and 'i686' without breaking some fairly fundamental assumptions.

Being able to have 'partial achitectures' which are actually different
baseline ISAs (586, 686) (armv6, armv7) for one ABI is something that
has been discussed many times, but no-one has ever cared enough to
actually implement it.

This is particularly relevant on mips, where inconsistent ISA changes
over the years mean that make picking one 'base ISA' is very
unsatisfactory, and they would like a way of having alternative ISA
(not ABI) builds of a significant set of packages (anthing where speed
actually matters, so libc, some core things and anything
codec-related, at least). (The rasbian port could have done things
this way and stayed within Debian for example, but it was easier to
derive).

Some details of a proposal for implemnting this are covered in section
2 of https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results
It would need fleshing out some more to actually be complete.

Nevertheless, if we implemented that, the question of how the
subsetting is done remains (i.e which packages are/are-not available
in the other 'flavour'). I wonder if we could re-use sections or
components for some kind of suitable classification? Such a mechanism
could perhaps also be used for the 'set of things that won't build on
32-bit arches any more' for example, which is closely related to the
'set of stuff that is useless on a NAS box'.

I hope that wasn't too rambling to be useful...

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

Re: Defaulting to i686 for the Debian i386 architecture

[Iustin Pop]

On 2015-09-28 22:14:44, 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.

Not true! My trusty soekris 5501 has an AMD Geode LX, which (AFAIK) is
still only i586. It seems it is missing one instruction (NOPL) from
being a full 686 chip :)

Anyway, what I mean to say: thanks for finally motivating me to upgrade.
This move definitely makes sense, but I wouldn't be so sure that there
are no actual production systems running on a 586-only CPU.

And thanks for your work!

iustin


signature.asc
Description: Digital signature

Re: Defaulting to i686 for the Debian i386 architecture

[Dimitri John Ledkov]

On 29 September 2015 at 17:24, Josselin Mouette  wrote:
>
> As of Knights Landing, it is based on Airmont Atom cores which indeed support 
> x86_64.
>

Correct.

-- 
Regards,

Dimitri.

partial architectures -- was: Re: Defaulting to i686 for the Debian i386 architecture

[Manuel A. Fernandez Montecelo]

2015-09-29 17:38 Wookey:

+++ Manuel A. Fernandez Montecelo [2015-09-29 12:27 +0100]:


Maybe it would be a good idea to split the architectures, and have one
port for legacy-but-still-sold-or-useful i386 and move the current i386
to only support newer, common-use i686 hardware.


It seems to me that this relates to a similar issue with armel, and
previous consideration of 'partial architectures' for mips (and arm).

[...]
Having a mechanism for 'partial architectures' to keep only the
relevant subset of the archive available for these machines seems like
a good plan, useful for at least i386 and armel, and probably
others. Because a debian arch refers to an ABI, not an ISA-variant,
you can't easily use our existing architectures mechanism to have both
'i386' and 'i686' without breaking some fairly fundamental assumptions.

Being able to have 'partial achitectures' which are actually different
baseline ISAs (586, 686) (armv6, armv7) for one ABI is something that
has been discussed many times, but no-one has ever cared enough to
actually implement it.

This is particularly relevant on mips, where inconsistent ISA changes
over the years mean that make picking one 'base ISA' is very
unsatisfactory, and they would like a way of having alternative ISA
(not ABI) builds of a significant set of packages (anthing where speed
actually matters, so libc, some core things and anything
codec-related, at least). (The rasbian port could have done things
this way and stayed within Debian for example, but it was easier to
derive).

Some details of a proposal for implemnting this are covered in section
2 of https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results
It would need fleshing out some more to actually be complete.


 (These ideas could also be applied for packages compiled with special
 characteristics, like optimised for multimedia instructions; or
 compiled with address sanitiser, undefined behaviour sanitiser, etc --
 somebody was talking about this in DebConf, I think that it was
 Bálint).

Honest question, not a snarky one; but after reading your e-mail and the
proposal it is still not very clear to me what's the fundamental
underlying difference (or the advantage, in terms of which problems
solves better, and how) between a partial architecture, a full
architecture which possibly doesn't build a [large?] subset of packages
(there are mechanisms like "not-for-us" and "package-arch-specific",
which you probably know better than me), and an "overlay"-like
repository such as experimental or security-updates (although I am aware
that overlays don't get packages to build in the same way as arches, one
has to target them).


If I understand correctly what I read from partial arches, there has to
be a common baseline and baseline has to be the lowest common
denominator, in the case of i386/i686 (or armel/armhf), the baseline has
to be i386 or armel (so you can boot in the baseline, and then enable
the "flavour"/partial-arch more suited to your hardware).  And since in
the example of Intel it is widely used and capable hardware, people
could want almost every package.  If armel cannot cope with some
packages (e.g. 32-bit arches already having real trouble
compiling/linking some packages), the packages would be put in some
"not-for-us", or simply let to fail, as it probably happens already.

In that case, the amount of compiled packages would be about the same,
the storage about the same, etc.  The only thing that we would reuse is
a small set of packages that allow users to start the machine and enable
the "flavour".  I don't think that there would be much difference with
having two full architectures?


In the case that it works like an overlay-like repository
("jessie+i686", "jessie/i686" or whatever the convention), one could pin
this repository to take precedence and so install packages from it.  It
doesn't work very well if one thinks of unstable/experimental (packages
not being available at the same time), but it does if you imagine using
multiarch already today with stable releases -- you have all packages
there on both arches at the same time.  (Ubuntu PPAs and Debian
I-hesitate-to-call-Bikesheds are also supposed to work in this way).

If the amount of packages available is again "almost all", it doesn't
gain much over full ports in terms of CPU usage and storage.

In all cases, I assume that humanpower needed to tend the ports is about
the same.


So, in summary, I don't see these mechanisms as very different in terms
of resources compared to what I learn from partial architectures so far.

The main difference that I see among them is that full ports and overlay
repositories already work and don't need modification to existing
tools/practices; multiarch with compatible ports in the same machine and
overlay repositories and apt-pinning already work today.  (Overlays are
probably a less elegant solution for this, but also potentially less
problematic on a day-to-day basis than multiarch -- only one 

Re: Defaulting to i686 for the Debian i386 architecture

[Josh Triplett]

[Please CC me; not subscribed to -devel.]

Ben Hutchings wrote:
> On Mon, 2015-09-28 at 15:34 -0700, Josh Triplett wrote:
> > 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 Vortex86 family, Intel
> > > Quark and Xeon Phi, of which we currently only support the Vortex86.
> > 
> > Debian i386 currently works just fine on Quark processors;
> [...]
> 
> So far as I know, all current Quark processors have errata that make
> them unstable, not to mention totally insecure, when running ordinary
> i386 binaries.

News to me.  Link please?  Because I don't know what they'd run if *not*
ordinary x86 binaries, and everyone I know targeting them builds
ordinary x86 binaries. :)

- Josh Triplett

Re: Defaulting to i686 for the Debian i386 architecture

[Paul Wise]

On Mon, Sep 28, 2015 at 11:14 PM, 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).

Data point: I recently heard of at least one person who will need to
buy new hardware as a result of this change.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Defaulting to i686 for the Debian i386 architecture

[Dimitri John Ledkov]

Hello,

On 28 September 2015 at 22:44, Paul Wise  wrote:
>
> On Mon, Sep 28, 2015 at 11:14 PM, 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).
>
> Data point: I recently heard of at least one person who will need to
> buy new hardware as a result of this change.
>

Which hopefully is (a) cheap and (b) pay-off via electricity bill due
to improved power-efficiency ?!

-- 
Regards,

Dimitri.

Re: Defaulting to i686 for the Debian i386 architecture

[Josh Triplett]

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 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

Re: Defaulting to i686 for the Debian i386 architecture

[Ben Hutchings]

On Mon, 2015-09-28 at 15:34 -0700, Josh Triplett wrote:
> 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 Vortex86 family, Intel
> > Quark and Xeon Phi, of which we currently only support the Vortex86.
> 
> Debian i386 currently works just fine on Quark processors;
[...]

So far as I know, all current Quark processors have errata that make
them unstable, not to mention totally insecure, when running ordinary
i386 binaries.

Ben.

-- 
Ben Hutchings
All extremists should be taken out and shot.

signature.asc
Description: This is a digitally signed message part

Re: Defaulting to i686 for the Debian i386 architecture

[Marco d'Itri]

On Sep 28, Ben Hutchings  wrote:

> We propose to drop support for i386 processors older than 686-class in
> the current release cycle.
Yes please.

> Indeed, the likely reasons for users to choose i386 over amd64 today
> are to reduce memory consumption or to run i386 binaries for which the
> source is not available - not because they're using 32-bit processors.
FWIW, my laptop is still running i386 because until at least a couple of 
years ago the Java remote console applets used by major hardware vendors 
(definitely IBM, possibly HP as well) were broken on 64 bit systems.

-- 
ciao,
Marco


pgpexVp1FvdJI.pgp
Description: PGP signature

Re: Defaulting to i686 for the Debian i386 architecture

[Michael Biebl]

Am 28.09.2015 um 23:14 schrieb Ben Hutchings:
> 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 Vortex86 family, Intel
> Quark and Xeon Phi, of which we currently only support the Vortex86.
> Indeed, the likely reasons for users to choose i386 over amd64 today
> are to reduce memory consumption or to run i386 binaries for which the
> source is not available - not because they're using 32-bit processors.
> 
> The older processors would of course continue to be supported in jessie
> until at least 2018, and until 2020 if i386 is included in jessie LTS.
> 
> Maintaining support for these older processors hurts the Debian i386
> architecture in several ways:
> * Prevents optimisation for 686-class without run-time checks or
>   multiple library builds
> * Divergence from upstream code in various packages which often assume
>   at least 686-class processors
> * Can require user intervention to install optimised library packages
>   e.g. debootstrap does not install libc6-i686
> 
> - Ben Hutchings
> - Aurelien Jarno
> - Matthias Klose

Your reasoning is sound. Please go ahead with your plan.
We should not optimise for the least common denominator for eternity.


Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature