Re: not pending anymore
Hi,
you seem to be one more voice falling into the
"I don't like the name Amd wants us to use but I have nothing better"
group. If you can't suggest a workable alternative to amd64 thats
meaningless. Neither x86-64 nor x86_64 are workable with the tools at
hand and a dislike for marketing guys is absolutely no reason for us
to change the name to something else.
ebiederm@xmission.com (Eric W. Biederman) writes:
> on Thu, Jun 03, 2004 at 10:52:22PM -0400, Stephen Frost wrote:
>> * Matt Zimmerman (mdz@debian.org) wrote:
>> > I'm reverting the existing patch in CVS due to the controversy on
>> > -amd64/-devel about the arch name. A new patch is welcome when the
>> > issue is resolved.
>>
>> Right, we're working it out, but I havn't heard any real dissenters from
>> amd64 yet. Those who don't like it should speak up please. If no one
>> does then I guess we're all in agreement...
>
> A couple of points.
> 1) I currently have a cpu made by intel that runs this arch.
Many people have a cpu not made by intel that runs i386. Whats your point?
> 2) I would like to see x86-64 or some variant of it that the tools don't
> choke on be the official architecture name. It really describes what
> is going on. The reason x86_64 is used is because various tools
> choke on the x86-64.
Tools choke on both x86_64 and x86-64.
> 3) I would like it if packages can use amd64 and possibly some of the aliases
> from intel, the way i486/i586/i686 are used today on x86. That would
> prevent the current set of packages from breaking, and allow for
> flexibility in the future.
There is only one cpu type in the set: The amd64 architecture
implemented by Althon64 and Opterons. You are the first claiming to
have an intel CPU but if pure64 runs thats amd64 architecture too.
So what aliases should there be?
If you want compatibility to i486/i586/i686/k6/... you have to wait
for multiarch support. Without multiarch there can only be exactly one
architecture on your system, dpkg won't handle more.
> 4) RPM at least as of 4.2 from rpm.org does not recognize amd64 at
> all. So even if some distro packages can recognize this name it
> is not LSB
Since we are talking about the arch exclusivley used within debian and
nothing else it is inconsequential what rpm does or doesn't.
> <rant>
> All of the amd64/em64t and other names are marketing departments
> playing games. They will doubtless have other names in the future.
> For marketing departments confusion can be a good thing. Notice that
> Intel does not even officially admit they em64t == amd64. So choosing
> the name at marking department requests is just silly, and will likely
> to create more maintenance in the future.
> </rant>
Workable names so far have been amd64 and opteron (as in i386, the
first cpu that implemented the arch). Do you think the confusing
opteron would be better? If we have to pick something we might as well
stick with what the marketing department uses.
> As for interpretation there are subtle differences between amd64,
> em64t, and x86-64.
That would be x86_64. Nothing is using x86-64 and for good reasons and
we can't use x86_64 for similar reasons.
> x86-64 is the common subset. amd64 includes 3DNow instructions, and
> the NX bit. em64T includes sse3.
>
> At least that is what I would expect from packages tagged with those
> labels to indicate.
As mentioned before by someone intel declined to sign up for a common
subset. That prompted amd to drop the supposed common subset of x86_64
and name their own product amd64.
Who knows if intels em64t will be compatible with amd64? Is your cpu
showing any differences? Is pure64 working on it? Is you CPU a final
product or some beta test that might differ from the release CPUs?
MfG
Goswin
Reply to: