Debian Developers - Re: Debian AMD64 Port Ready

Author

Re: Debian AMD64 Port Ready

Martin Schulze

2004-06-12, 2:49 am

Chris Cheney wrote:
> We are proud to announce the Debian AMD64 port is ready for inclusion in
^^^

I've heard that there were two ports, a pure and a mixed one. So,
which one is yours and how can it be "the" Debian AMD64 port?

> Sid. The port is currently at 97% compiled with most of the remaining
> packages having FTBFS RC bugs filed for unrelated reasons. We have also
> finished debian-installer for the AMD64 port and generate daily builds.
> All that still remains to be done is for dpkg to include the amd64
> patch, for archive space be given to the port, and for an official
> buildd to be setup.

I also thought that the pure AMD64 port is technically ok, but
worthless from a usability point of view since it is not compatible
with AMD64 ports of other distributions. If that's the case indeed,
and if you are talking about the pure amd64 port, I don't believe
Debian should include it in sid.

Regards,

Joey

--
Given enough thrust pigs will fly, but it's not necessarily a good idea.

Please always Cc to me when replying to me on the lists.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Chris Cheney

2004-06-12, 2:49 am

On Sat, Jun 12, 2004 at 06:39:58AM +0200, Martin Schulze wrote:
> Chris Cheney wrote:
> ^^^
>
> I've heard that there were two ports, a pure and a mixed one. So,
> which one is yours and how can it be "the" Debian AMD64 port?

There is only one AMD64 port. There is also the multiarch effort which
is separate and not really part of the amd64 port. It may be ready in a
year or so, it is expected that it will require modifications to all
library packages which is well over 1000 sources. Multiarch is of
primary interest to the other 64bit capable archs that are currently
limited to 32bit userspace, such as mips, powerpc, and sparc.

>
> I also thought that the pure AMD64 port is technically ok, but
> worthless from a usability point of view since it is not compatible
> with AMD64 ports of other distributions. If that's the case indeed,
> and if you are talking about the pure amd64 port, I don't believe
> Debian should include it in sid.

I have not heard of any compatibility issues, there is a lib64 dir just
as there is on the other distributions. It just happens to be a symlink.
Also, Multiarch is expected to be adopted by FHS/LSB and makes the
current distributions obsolete wrt their library placement in any case.
And since when is compatibility with other dists more important that
having support for an arch at all? How is not being compatible with
other distributions useless usability wise? I have never had the reason
to install another distributions rpm package on my system and have not
heard of anyone else needing to either, on amd64 or even i386 for that
matter. Of course Debian will be useless usability wise if sarge does
not ship with AMD64 arch support since by 2007 (sarge+1) all desktop
systems will be AMD64/EM64T/IA32E based. BTW Intel is expected to enable
the 64bit extensions on the P4 3.2GHz+ chips by the end of August 2004.

Chris

Martin Schulze

2004-06-12, 11:51 pm

Chris Cheney wrote:
>
> I have not heard of any compatibility issues, there is a lib64 dir just
> as there is on the other distributions. It just happens to be a symlink.
> Also, Multiarch is expected to be adopted by FHS/LSB and makes the
> current distributions obsolete wrt their library placement in any case.
> And since when is compatibility with other dists more important that
> having support for an arch at all? How is not being compatible with

It has always been an issue. Since AMD64 will probably be adopted
commercially, there will be third party applications, that will only
run on other distributions and not on Debian, which would make the
Debian port pretty useless if you want to run only one other third
party application which was compiled for another distribution.

We've always tried very hard to keep our glibc compatible with the one
from other distributions.

> other distributions useless usability wise? I have never had the reason
> to install another distributions rpm package on my system and have not
> heard of anyone else needing to either, on amd64 or even i386 for that
> matter. Of course Debian will be useless usability wise if sarge does

I acknowledge that this is your personal experience. It does not mean
that it is everybody's experience. Especially, it does not have to
imply that no user will ever want to run third party software.

> not ship with AMD64 arch support since by 2007 (sarge+1) all desktop
> systems will be AMD64/EM64T/IA32E based. BTW Intel is expected to enable
> the 64bit extensions on the P4 3.2GHz+ chips by the end of August 2004.

Since the amd64 CPU is fine running i386 code, how could the i386 port
be useless?

Regards,

Joey

--
Given enough thrust pigs will fly, but it's not necessarily a good idea.

Please always Cc to me when replying to me on the lists.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Johannes Resch

2004-06-12, 11:51 pm

On 2004-06-12 10:28, Martin Schulze wrote:
> Chris Cheney wrote:
>
>
> Since the amd64 CPU is fine running i386 code, how could the i386 port
> be useless?

Because people may want to use extended hardware features they paid for?

This discussion has been held a couple of times already - and in the
meantime, Debian loses users to Gentoo, SuSE or others.

--jr

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Joerg Jaspert

2004-06-12, 11:51 pm

Martin Schulze

2004-06-12, 11:51 pm

Joerg Jaspert wrote:
> Martin Schulze <joey@infodrom.org> writes:
>
>
> Because one paid for the 64bit stuff and wants to use it?

So you consider it useless only because the CPU could do something
else?

Bogus argument.

Regards,

Joey

--
Given enough thrust pigs will fly, but it's not necessarily a good idea.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Joerg Jaspert

2004-06-12, 11:51 pm

Goswin von Brederlow

2004-06-12, 11:51 pm

Martin Schulze <joey@infodrom.org> writes:

> Chris Cheney wrote:
> ^^^
>
> I've heard that there were two ports, a pure and a mixed one. So,
> which one is yours and how can it be "the" Debian AMD64 port?

There was an attempt atdoing a mixed port but the resistance by the
dpkg developers and the community in general was too big to get it
under way, esspecially with the sarge release looming over our
heads. A full mixed port means changing every single library package
and affects probably all packages. That's nothing one wants to do
before sarge.

So instead of going full 32/64 bit mixed mode amd64 in one big step
pure64 was started to get 64 bit support fully available with minimum
impact to sarge. Merging is multiarch support for mixed 32/64 bit is
now step 2 planed for after sarge at the earliest.

>
> I also thought that the pure AMD64 port is technically ok, but
> worthless from a usability point of view since it is not compatible
> with AMD64 ports of other distributions. If that's the case indeed,
> and if you are talking about the pure amd64 port, I don't believe
> Debian should include it in sid.

Actually the oposite is true. The pure64 port resembles what other
archs have pobably as closely as we will ever be. The multiarch (stepo
2 after sarge) will introduce layout changes to the FHS and move every
library on the system around to a new location. After that you can
kiss every software with rpath set goodby.

The good news is that a lot of the commercial linux apps one wants the
multiarch for (like loki games

are static so no worry there.

> Regards,
>
> Joey

I hope that made thinks clearer.

MfG
Goswin

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

viro@parcelfarce.linux.theplanet.co.uk

2004-06-12, 11:51 pm

On Sat, Jun 12, 2004 at 12:53:13PM +0200, Martin Schulze wrote:
> Joerg Jaspert wrote:
>
> So you consider it useless only because the CPU could do something
> else?
>
> Bogus argument.

The hell it is. We have
i386 port: doesn't allow doing amd64 development, including the
kernel work on the box; has quite a few problems when used with amd64 kernel
(mostly usable, but there is breakage and it's not easy to fix).
amd64 port: works
biarch effort: MIA, but if someday resurrected and brought to the
working state, it might be more or less nice thing to have if you care about
mixing distributions.

And transition from i386 to biarch, should the latter ever materialize as
a working port, is no easier than amd64 -> biarch. Care to explain how in
Cthulhu name the use of i386 port is preferable to use of amd64 one on the
same boxen?

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Chris Cheney

2004-06-12, 11:51 pm

On Sat, Jun 12, 2004 at 10:28:51AM +0200, Martin Schulze wrote:
> Chris Cheney wrote:
>
> It has always been an issue. Since AMD64 will probably be adopted
> commercially, there will be third party applications, that will only
> run on other distributions and not on Debian, which would make the
> Debian port pretty useless if you want to run only one other third
> party application which was compiled for another distribution.
>
> We've always tried very hard to keep our glibc compatible with the one
> from other distributions.

The /lib64/ld-linux-x86-64.so.2 is in the correct location and the glibc
is not modified in any major way that I know of so it should be
compatible with the LSB. Debian has never been more than trivially
compatible with other dists since our regular libraries have never been
in sync with the other dists. A lot of that has to do with the fact that
we release every 2-3 years when other dists release every 6 months.

>
> I acknowledge that this is your personal experience. It does not mean
> that it is everybody's experience. Especially, it does not have to
> imply that no user will ever want to run third party software.

True, and since our ld is located in the right spot for AMD64 LSB
compatibility and we have ia32-libs like ia64 we can support i386
binaries just like everyone else as well. Of course if someone needs
extreme compatibility with another dist and not just LSB compatibility
they will need to use that other dist as they do today instead of using
Debian i386.

>
> Since the amd64 CPU is fine running i386 code, how could the i386 port
> be useless?

The i386 port is much slower than running amd64 code, on average 20-30%
slower and yes this has been tested and proved. Some people also
actually need the 64bit support that the arch provides. Debian has
already lost a lot of users since AMD64 was released in March 2003
because every other major dist supports it now, some for over a year. So
it is totally unacceptable for Debian to suggest to users to use the
i386 port instead and Debian will continue to lose many more users if it
sticks to that line. Also, since Debian already has a fully working
AMD64 port it would be very stupid not to release Sarge with it.

Chris

Goswin von Brederlow

2004-06-12, 11:51 pm

viro@parcelfarce.linux.theplanet.co.uk writes:

> On Sat, Jun 12, 2004 at 12:53:13PM +0200, Martin Schulze wrote:
>
> The hell it is. We have
> i386 port: doesn't allow doing amd64 development, including the
> kernel work on the box; has quite a few problems when used with amd64 kernel
> (mostly usable, but there is breakage and it's not easy to fix).
> amd64 port: works
> biarch effort: MIA, but if someday resurrected and brought to the
> working state, it might be more or less nice thing to have if you care about
> mixing distributions.

Biarch is obsolete and abandoned. Multiarch has taken over.

The difference is that mutliarch doesn't adhere to the borken FHS but
introduces some further changes to clean things up and do it right[tm].

> And transition from i386 to biarch, should the latter ever materialize as
> a working port, is no easier than amd64 -> biarch. Care to explain how in
> Cthulhu name the use of i386 port is preferable to use of amd64 one on the
> same boxen?

Uhm, *joey mask*, stable i386 exists and amd64 not.

MfG
Goswin

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Mark Brown

2004-06-12, 11:51 pm

On Sat, Jun 12, 2004 at 12:08:44PM -0500, Chris Cheney wrote:
> On Sat, Jun 12, 2004 at 10:28:51AM +0200, Martin Schulze wrote:

[vbcol=seagreen]
> compatible with the LSB. Debian has never been more than trivially
> compatible with other dists since our regular libraries have never been
> in sync with the other dists. A lot of that has to do with the fact that
> we release every 2-3 years when other dists release every 6 months.

When people are using the LSB you'll frequently find that they'll
deliberately target older versions of libraries anyway. With this sort
of software you're at times dealing with environments where people are
reluctant to upgrade their base distribution - even security fixes can
be an effort to deploy.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Daniel J. Priem

2004-06-12, 11:51 pm

Am Sa, den 12.06.2004 schrieb Joerg Jaspert um 13:09:
> Martin Schulze <joey@infodrom.org> writes:
>
>
> So you buy a $insertbigthinghere and only use one half of it?
> (bigthing = maybe a car with 300ps, and you only use 10, a fast
> processor with >3.2GHz and you let it run only with 500MhZ).
>
>
> No, that is what counts - in Debian you can only use it in a degraded
> mode - so you use another Distri which can use it full.
> If we accept this and release without "the full mode" - we are simply
> useless for a wide range of people in the future.
Full ack.

Daniel

Darren Salt

2004-06-12, 11:51 pm

I demand that Chris Cheney may or may not have written...

[snip]
> Of course Debian will be useless usability wise if sarge does not ship with
> AMD64 arch support since by 2007 (sarge+1) all desktop systems will be
> AMD64/EM64T/IA32E based.

(Assuming that you mean "all _new_ desktop systems".)

So you're saying that production of (say) XScale-based desktop boxes will
*definitely* cease within 2.5 years or so?

--
| Darren Salt | nr. Ashington, | linux (or ds) at
| woody, sarge, | Northumberland | youmustbejoking
| RISC OS | Toon Army | demon co uk
| This space reserved for future expansion

The days of the digital watch are numbered.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Chris Cheney

2004-06-12, 11:51 pm

On Sat, Jun 12, 2004 at 11:11:50PM +0100, Darren Salt wrote:
> I demand that Chris Cheney may or may not have written...
>
> [snip]
>
> (Assuming that you mean "all _new_ desktop systems".)
>
> So you're saying that production of (say) XScale-based desktop boxes will
> *definitely* cease within 2.5 years or so?

Hmm, XScale-based desktops, never heard of them, I have seen plenty of
XScale-based pda's but then thats not a desktop. What I meant to say was
effectively all new desktop systems shipped by 2007 will be amd64 based,
of course apple will still be alive shipping their 2% of the market ppc
based systems. Of course there will likely be developer systems for
large sums of money running other archs like XScale as there is today,
but that can't really be considered a normal desktop system. ;)

Chris

Darren Salt

2004-06-12, 11:51 pm

I demand that Chris Cheney may or may not have written...

> On Sat, Jun 12, 2004 at 11:11:50PM +0100, Darren Salt wrote:
[vbcol=seagreen]
> Hmm, XScale-based desktops, never heard of them, I have seen plenty of
> XScale-based pda's but then thats not a desktop.

Look at <URL:http://www.iyonix.com/>...

> What I meant to say was effectively all new desktop systems shipped by 2007
> will be amd64 based, of course apple will still be alive shipping their 2%
> of the market ppc based systems.

Could be...

> Of course there will likely be developer systems for large sums of money
> running other archs like XScale as there is today, but that can't really be
> considered a normal desktop system. ;)

Maybe they can't, but the normal desktop systems which happen to be based on
XScale (or older ARMs, for that matter) certainly can be :-)

--
| Darren Salt | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking | Northumberland
| RISC OS | demon co uk | Toon Army
| <URL:http://www.youmustbejoking.demon.co.uk/progs.linux.html>

4 Out of memory, 0:1

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Chris Cheney

2004-06-12, 11:51 pm

On Sun, Jun 13, 2004 at 01:25:12AM +0100, Darren Salt wrote:
-snip-
> Maybe they can't, but the normal desktop systems which happen to be based on
> XScale (or older ARMs, for that matter) certainly can be :-)

It might be useful to get one of those for our arm buildd, it would
probably be much faster than the StrongARM 110 (Netwinder?) Debian
currently has.

Chris

Mattias Wadenstein

2004-06-14, 5:53 pm

Stephen Frost

2004-06-14, 5:54 pm

* Martin Schulze (joey@infodrom.org) wrote:
> It has always been an issue. Since AMD64 will probably be adopted
> commercially, there will be third party applications, that will only
> run on other distributions and not on Debian, which would make the
> Debian port pretty useless if you want to run only one other third
> party application which was compiled for another distribution.

Have you actually tried running a 64bit application from another
distribution on pure64? Do you have a specific technical reason why it
wouldn't work? I don't. I'd love to hear of any that exist. 32bit
applications won't work on pure64, but you could install i386 on an
amd64 system and use those 32bit applications there if you want. The
only place I'm aware of a possible compatibility problem is if you want
to install a third party application that has both 32bit and 64bit
applications in it and you want to use them both at the same time and
under the same system. That seems like it'd be a pretty small number of
cases. Oracle, for example, has seperate CDs for their 64bit version
from their 32bit one (at least on Solaris).

Stephen

Stephen Frost

2004-06-14, 5:54 pm

* Mattias Wadenstein (maswan@acc.umu.se) wrote:
> As a data point to this, I have successfully run the Portland Group
> compiler on debian-amd64 [pure64] producing non-trivial programs
> with both fortran77, fortran95, C, and C++ (spec cpu2000, which also
> checks that the programs produce the correct result).
>
> The install procedure grumbles a bit, but no deep magic is needed to
> make it work. I have not tested more software, but this indicates that
> the "pure64" effort is not useless for commercial software.

Wow, very cool! I hadn't heard of a successful test yet (didn't know
anyone who had access to commercial software that's shipping for amd64).
Awesome, many thanks for testing.

Stephen

Martin Schulze

2004-06-15, 5:54 pm

Stephen Frost wrote:
> * Martin Schulze (joey@infodrom.org) wrote:
>
> Have you actually tried running a 64bit application from another
> distribution on pure64? Do you have a specific technical reason why it
> wouldn't work? I don't. I'd love to hear of any that exist. 32bit

No. That's just what I remembered from the early days of debian-amd64.
I thought that programs could expect parts of the libraries to be 64 bit
and parts to be 32 bit which won't work, of course, if the 32 bit version
would not be around.

Regards,

Joey

--
MIME - broken solution for a broken design. -- Ralf Baechle

Please always Cc to me when replying to me on the lists.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Wouter Verhelst

2004-06-15, 5:55 pm

On Tue, Jun 15, 2004 at 07:54:18AM +0200, Martin Schulze wrote:
> Stephen Frost wrote:
>
> No. That's just what I remembered from the early days of debian-amd64.
> I thought that programs could expect parts of the libraries to be 64 bit
> and parts to be 32 bit which won't work, of course, if the 32 bit version
> would not be around.

AIUI, that's not how AMD64 works. If I understood things right, 64bit
applications can only use 64 libraries; you can't mix them in one
program.

--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune

Martin Schulze

2004-06-15, 5:55 pm

Wouter Verhelst wrote:
> On Tue, Jun 15, 2004 at 07:54:18AM +0200, Martin Schulze wrote:
>
> AIUI, that's not how AMD64 works. If I understood things right, 64bit
> applications can only use 64 libraries; you can't mix them in one
> program.

What's the benefit of a mixed environment then?

Regards,

Joey

--
MIME - broken solution for a broken design. -- Ralf Baechle

Please always Cc to me when replying to me on the lists.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Wouter Verhelst

2004-06-15, 5:55 pm

On Tue, Jun 15, 2004 at 09:43:58AM +0200, Martin Schulze wrote:
> Wouter Verhelst wrote:
>
> What's the benefit of a mixed environment then?

The ability to run both 32bit and 64bit applications without having to
mess with chroots?

--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune

Stephen Frost

2004-06-15, 5:55 pm

* Martin Schulze (joey@infodrom.org) wrote:
> Wouter Verhelst wrote:

I'm quite confident this is the case. There are methods out there which
will let you do this kind of nasty library mixing (used in Winbloze and
OS/2 I believe) but as far as I know Linux doesn't support it. It's
called 'trunking' or something along those lines, iirc. Basically you
have to mangle the pointers and whatnot to make it work, at the very
least, and it's *really* ugly.
[vbcol=seagreen]
> What's the benefit of a mixed environment then?

Some applications run faster as 32bit binaries, especially on systems
like Sparc64. Some run faster as 64bit binaries due to lots of 64bit
operations and less pointer work. Practical examples include:

Sparc64 system:
Most applications 32bit since it's faster and they don't need 64bit.
PostgreSQL, Oracle, home-grown stuff 64bit for additional memory
space and increased speed of 64bit operations.

AMD64 system:
Most applications 64bit since it's generally faster and they get the
benefit of 64bit for 'free' due to the additional registers and whatnot.
Home-grown stuff, non-64bit-clean stuff 32bit for speed of smaller
pointers and so they don't segfault if not 64bit clean. Also the
ability to run commercial 32bit applications that havn't been ported to
amd64 proper yet.

Hope that helps.

Stephen

Mark Ferlatte

2004-06-15, 5:55 pm

Stephen Frost said on Tue, Jun 15, 2004 at 09:53:52AM -0400:
> I'm quite confident this is the case. There are methods out there which
> will let you do this kind of nasty library mixing (used in Winbloze and
> OS/2 I believe) but as far as I know Linux doesn't support it. It's
> called 'trunking' or something along those lines, iirc. Basically you
> have to mangle the pointers and whatnot to make it work, at the very
> least, and it's *really* ugly.

It's called "thunking", and is how Windows 9x/Me allowed 16 bit code to talk to
32 bit libraries.

M

Clint Adams

2004-06-15, 5:55 pm

> It's called "thunking", and is how Windows 9x/Me allowed 16 bit code to talk to
> 32 bit libraries.

Yes, though it predates Windows 95.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Marcelo E. Magallon

2004-06-16, 5:56 pm

On Tue, Jun 15, 2004 at 07:54:18AM +0200, Martin Schulze wrote:

> No. That's just what I remembered from the early days of
> debian-amd64. I thought that programs could expect parts of the
> libraries to be 64 bit and parts to be 32 bit which won't work, of
> course, if the 32 bit version would not be around.

Linux doesn't do thrunking. You run either 64 bit or 32 bit code, not
a mix.

Marcelo

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org