Re: Concerns about AMD64 port
Sorry, but I've seen too many messages filling up my mailbox with this stuff
now!!!
There are a couple of points I really don't understand about you guys whining
"we are not having an AMD64 port", especially some of them not even having
worked on the actual hardware:
a) Instead of keeping people on this list busy with a discussion that has
already been gone through more than twice in depth here, why don't you just sit
down, go through the available docs (which I admit are not perfect, and well
organized) and try to get a 64bit machine running with the currently available
packages? If you're so brilliant that you believe you can get a pure amd64 port
ready in a couple of months, it shouldn't take you more than a couple of hours
to get this done.
What I mean is: We have a port already!!!! I actually have 3 customers for
which I have installed 64/32 bit HPC clusters on dual opterons including
Infiniband networking with the alioth packages, a custom kernel + some 20
packages I ported myself. So don't say, we need to wait for years to get
something running as multiarch without having tried it. It's not
straightforward right now, but possible.
b) Saying that 32 bit applications could be run in a chroot environment is of
course right. But one should also admit that this is a crappy approach in
general, and can hardly be justified for anything else than personal
use. Especially when other distributions show that a multiarch port is
possible. There are often quite a few ugly hacks necessary to get a chroot
working seemlessly with more than just a simple app. I don't think we would
live up to the Debian standards with such a solution.
c) Legacy 32bit applications are going to be around for a long time. I don't
mean games here, but applications real businesses rely upon. A lot of third
party software companies simply don't have the resources to port their stuff to
a new plattform unless they really have to, especially when there is a way to
run it on AMD64 hardware without investing any time at all by simply choosing a
Suse or Red Hat / Fedora installation (and continue to run 32 bit).
There are 2 big winning points about the x86_64 hardware: 1) It's a cheap 64
bit architecture allowing you to go beyond 4GB, and 2) it's fully backward
compatible. Both points are equally important right now (and also in the
midterm). The latter will of course eventually fade away (sooner or later, but
not within a year or even two). The only clean way to take advantage of both
features is a multiarch port.
d) I wish I would see some technical discussions on this list again that would
bring us forward. I fully agree that a big issue for the multiarch stuff (apart
from dpkg/apt for which there are patched versions on alioth that get you quite
far) is getting the libc package ready. Maybe the guy working on this could
give us an update of what the main issues are (or you Goswin?). I have been
able to build the older versions of the libc packages (the ones on alioth), but
the more recent ones in unstable have too many changes, so the patches of the
alioth packages won't apply anymore at all.
Also, it would be good, if the alioth archive would actually be cleaned up so
one has valid Packages files, and also the source of each package (it's missing
for quite a few of them).
So again, my point is: Before talking about a pure amd64 port in thin air, try
to get a system with the current stuff up and running, and then let's discuss
from there. It's not such a big thing to do this, especially for a Debian
developer. And then you could put your time and effort into a common project
not into duplication. I think this way we'll see a reasonably complete (and
even multiarch) port in the shortest possible time. We're not as far from
having a decent base installation as it seems. And I would argue that porting
the rest will not be that much slower for a multiarch port compared to a pure
64bit one. Actually I would say one could get a reasonable first version of the
port by just porting about 500 packages, and taking the rest from i386. This
could be done in half a year with a couple of developers. We just need to
actually do some porting instead of posting flames.
Ok, enough of this.
Roland
Reply to: