* John Goerzen (jgoerzen@complete.org) wrote: > On the AMD64 Ports page[1], it says "a pure 64bit port seems to be > academical and of little use." I am totally shocked by that statement. You're not the only one, believe me. I was too, and still don't agree with it. > The information I've seen suggests that the AMD64 is faster by no small > margin when running 64-bit apps than 32-bit apps (on Linux). Debian has In general it is, there are specific cases where 32bit apps are faster but there's corner cases for everything. > The only reason I can see for even bothering to support 32-bit > applications at all is for binary-only proprietary software. And that > is not such a concern; it takes all of about 10 minutes to set up a > 32-bit chroot with debootstrap to run those things in. I tend to agree but so far the people who have been doing much of the amd64 work have such binary-only proprietary software that they want to see supported directly. > So it seems to me that the great benefit to many people of having a > native 64-bit userland has been sacrificed for the questionable benefit > of being able to run proprietary software without making a chroot. I am > still a little shocked about that. Supporting a 64bit userland is one of the goals, of course. > Can someone explain what is going on here? I'll give it a shot, here's a list of some facts that may help you understand the reasoning some have used: 1) RH/SuSe have a /lib with 32bit libraries and a /lib64 with 64bit libraries on their amd64 systems. 2) The FHS (I think?) and/or other standards groups are putting in their standards that the 32bit loader is to be at /lib/ld-linux.so and the 64bit loader at /lib64/ld-linux-amd64.so (or whatever the specific names are). 3) Debian wants to be standards compliant, of course. 4) Installing 64bit libraries to /lib64 is pretty difficult just to begin with and have everything work under Debian with the automated build systems and whatnot. 5) RH/SuSe are (at least trying to) supporting mixed 32/64bit amd64 systems, doing it on Debian would be good too. 6) Doing a 64bit-only port *now* and a mixed 32bit/64bit port *later* would make for a very difficult upgrade path (personally I'm inclined to say forget the upgrade path, make a 64bit only port *now* so people have a *useful* 64bit system and do the mixed stuff and tell people they need to reinstall if they want to go to the mixed system, and make it clear up front that if they do use the 64bit only port that they'll have to reinstall later if they want to move to the 32/64bit mixed system). 7) There's been claims that the RM or the ftp-master or someone wouldn't create the amd64 directory for a 64bit only port. No clue how reliable these are, people couldn't point me to specific messages in archives or anything, or give any better wording/reasoning than what I've said above. If you've got the time/resources to do a 64bit-only port and maintain it and can convince whomever to give you wanna-build access so that you can keep it up with the rest of unstable I'd say go for it. I'd even be willing to help but I don't think I've got room to host it on a fast connection (though others might be willing to). I've got at least one dual-proc amd64 system I'd be willing to help compile things for a 64bit-only amd64 port with. I'd be happy to hear from others if my list of reasons above is incomplete or not accurate. Stephen
Attachment:
signature.asc
Description: Digital signature