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

Bug#575760: x86 architecture names are confusing



Hi,

[CC the other Bug# against release-notes]

On Mon, Mar 29, 2010 at 02:52:55AM +0100, Ben Hutchings wrote:
> Package: www.debian.org
> Severity: normal
> 
> Various pages use the long architecture names 'AMD64' and 'Intel x86'
> for our architectures 'amd64' and 'i386'.  The name 'AMD64' sometimes
> confuses users with Intel x86-64 chips, who instead download the
> installer or CD images for ia64.  This is a waste of time and
> bandwidth for all concerned.  The name 'Intel x86' is also inaccurate
> in that the i386 architecture runs on 32-bit x86 processors from many
> vendors.
> 
> I recommend the names '32-bit PC' and '64-bit PC' - they are not
> pedantically correct, but people should understand what they mean.

Or: 32-bit PC (i386) | 64-bit PC (amd64)
(in order to keep in mind the official name in the archive).

I fully agree. We received many reports/doubts of users on debian-www.

For the record, the subject has been discussed in November:
http://lists.debian.org/debian-www/2009/11/threads.html#00005
FJP position: http://lists.debian.org/debian-boot/2009/11/msg00515.html

The point of FJP is however to keep consistency between displayed names
and architecture name.
It may be relevant to change amd64 to something else, but may need
much larger changes in Debian..

IMO, it's still better to minimize errors during the first step in
getting to Debian, at the cost of the users doubts when getting
some_package_amd64.deb.

> Whatever you do, please avoid any vendor-specific names (including
> 'IA32' which is almost unknown outside of Intel manuals).
> 
> At least the following pages use these names:
> 
> http://www.debian.org/releases/stable/
> http://www.debian.org/ports/
> http://www.debian.org/mirror/submit
> http://www.debian.org/CD/vendors/adding-form
> 
> Most other pages using these names appear to be part of the
> installation manual or release notes, which can be dealt with
> separately.

-- 
Simon Paillard



Reply to: