Re: Concerns about AMD64 port
The following is the closest to actual overview of the
state of the project I have seen so far in documentation
or list. Cheers!
On Sat, 7 Feb 2004, Roland Fehrenbacher wrote:
> Date: Sat, 7 Feb 2004 02:17:04 +0100
> From: Roland Fehrenbacher <firstname.lastname@example.org>
> To: email@example.com
> Subject: Re: Concerns about AMD64 port
> Resent-Date: Fri, 6 Feb 2004 19:17:12 -0600 (CST)
> Resent-From: firstname.lastname@example.org
> Sorry, but I've seen too many messages filling up my mailbox with this stuff
> 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.