On Thu, Feb 12, 2004 at 11:29:23PM +0100, Roland Fehrenbacher wrote: > >>>>> "John" == John Goerzen <jgoerzen@complete.org> writes: > > .......... > > John> I feel it is time for us to start thinking about what will come of > John> the AMD64 port. There is a limit to what we can do without being an > John> "official" Debian port project. Of course, being an "official" > John> Debian port project does not obligate us to release with the next > John> version of Debian, but makes many useful bits of infrastructure > John> available and helps us coordinate better. In general, it makes our > John> task easier and makes the tasks of others that must work with us > John> easier as well. > > John> I propose that we build the Debian AMD64 port first as a pure 64-bit > John> port, perhaps using the existing pure 64-bit packages as a guide. > John> There will be no 32-bit binaries in it, no capability to run 32-bit > John> binaries (aside from a chroot that the user can create with existing > John> tools), etc. We will have a true, working, usable 64-bit version of > John> Debian to use, *now*. > > John, > > I agree with Joseph that you should just go ahead and do your 64bit only port > (if you really think you have to) and the multiarch project should continue on > a separate path. The most we can hope for is that both projects can profit from > each other. Please try wrapping at a little less than 79 chars ;) (Maybe around 70 to allow quotation). > The problem with your approach of doing 64bit first and then multiarch is that > it is has just the wrong timing. 32 bit compatibility is needed most now and > not sometime in the future when you care thinking about it. This has already been discussed many times... there apparently are some 32bit only software that someone uses other than games, which won't work regardless. What keeps them from just using the i386 port, multiarch won't be ready anytime soon, while amd64 port will probably be ready in the next week or two. > Your 64bit only suggestion breaks with a very important rule that makes > architectures successful: Good (meaning performant and simple) backwards > compatibility to a widely used architecture (being x86 in this > case). Unfortunately a 64bit only port doesn't satisfy that criterion. And > architectures that don't satisfy that criterion have a hard life (see > e.g. Itanium ...) becoming widely accepted even if they are great otherwise > (the Alpha also belongs to that group in some loose way). So my prediction is > that a Debian 64bit port will certainly find some users, but it will present a > quite tough barrier for people to use Debian on this platform in general > (especially in the business world). It will provide a tougher barrier for people than NO PORT AT ALL? HAH! Once multiarch is ready to be used I'm sure the amd64 port will make the minor changes necessary to support it. > One other problem: Your port is going to be of no use for somebody who needs 32 > bit packages (unless you go for the crappy solution of a 32bit chroot, which > means maintaining 2 systems instead of one) or maybe just thinks he might need > it at some point (ever thought of the Intel compiler e.g., or people who like > to work on a 64 bit system but need to develop for the 95% share of the market > that still uses x86 right now). On the other hand, a multiarch system serves > all of us. So I guess it's fair to say that a 64bit only port is the egoistic, > unpatient way of doing it. And heck, I am repeating myself: Multiarch is > actually working now!!!! True but as has been said multiple times they can run i386 until multiarch is ready if they need i386 so badly. Or they can use the chroot idea, whichever appeals to them more. "Multiarch is actually working now!!!" since when? Last I heard glibc still didn't even work right. If multiarch was working right now then we could migrate amd64 to it, I seriously doubt your claims that it is working though. > John> Then... > > John> When a way forward with the multiarch is finally laid out, and we are > John> confident that it will work, we can transition to being a multiarch > John> platform, *while still supporting those that want a pure 64-bit > John> environment*. I personally see no reason why moving from pure64 to > John> biarch64 is any more difficult than moving from i386 to biarch64. > > Well I think it is more difficult for the simple fact that making radical > changes on an existing and used platform (the proposed 64 bit port) is much > more painful than on an experimental platform (like multiarch is currently). It shouldn't be that hard since he already has the symlinks for lib64 in there. Of course it would require a recompile at minimum of all libraries to move them into another directory. > John> This plan has the following benefits, when compared to the existing > John> "do nothing until multiarch works" plan: > > John> 1. We get a head start on fixing the 64-bit bugs. We get things > John> working in AMD64 first, then make them work with 32-bit stuff too. > > Pure 64 bit problems is certainly the easiest part of the whole story, since > there are a couple of 64 bit ports already. > > John> 2. We get more people using Debian on AMD64... they could help out > John> with the multiarch effort later. > > Those peolple who will be using this port obviously haven't cared about 32 > bit. So I don't think there is much hope in that. There is very little reason to care about 32bit emulation on amd64 since games don't work anyway. The only thing left are 3rd party proprietary apps that should work anyway since they are in most cases statically compiled... > John> 3. We provide a way for people that use Debian and demand top > John> performance to get it, rather than turning them away to Gentoo, > John> RedHat, or NetBSD. > > For most people, the opposite will be true. Concerning performance: A lot of > performance is actually compiler dependent. And many benchmarks have shown that > 32 bit code using the intel compiler is still faster than the corresponding 64 > bit versions compiled with gcc or other compilers (Portland, ...). And Debian uses the Intel/Portland compilers for what? Also note it was recently revealed that the Intel compiler doesn't enable certain optimizations on AMD chips on purpose and thus slows it down. > John> Finally, I should point out that it is by no means a certainty that > John> multiarch will be a valuable feature in either the short-term or the > John> long-term. Significant rumblings indicate that lots of major vendors > John> -- including Intel -- are jumping on the AMD64 bandwagon in a major > John> way. By the time we finish multiarch support, it may be completely > John> obsolete; then we will have delayed a useful AMD64 port for no good > John> reason. > > There is still a big market for VMS software and old style IBM mainframe stuff, > so you are saying that x86 code will disappear soon? Sorry, but I think you > hadn't thought very well before writing this statement. Legacy stuff will always exist but in very small amounts. Just look at the stats for non x86 usage for Debian for example. By the time sarge+1 (2007-2008 timeframe) is released and if Intel uses amd64 ISA I would imagine it will be by far the most used arch, perhaps even close to the 97%+ usage of i386 today. > John> This is not just a hypothetical. A parallel situation existed on > John> Alpha, where the em86 system existed to run i386 Linux binaries > John> unmodified on an Alpha (albeit at a greater performance penalty than > John> running i386 binaries on an AMD64). This was initially important to > John> early adopters of the Alpha, since there were no web browsers as good > John> as Netscape at the time, etc. But em86 hasn't really been kept up, > John> and probably doesn't work in any kernel later than 2.0 or maybe 2.2. > John> There is simply no need for it anymore. > > This is really a flawed comparison. x86 emulation on the Alpha was just a > marketing gag, and Alpha certainly wasn't out to replace i386. Anybody who > would have believed in that must be called ignorant at best. But amd64 is a > natural succesor of i386. And please remember: amd64 doesn't emulate x86 but > has an instruction set on top of it. A big difference!!! To some the i386 emulation on amd64 is a gag, it has been said that performace of native amd64 code with a properly optimized compiler can be 30% faster than i386 code. Thats not a minor speed difference. Try finding out the price of a 4.5GHz CPU today. > John> This could very well happen to us. > > John> Let's prevent that. > > Anyway, nobody can stop you doing of what you are planning or already have > started to do ... But please don't drag people away from the multiarch port by > making flawed arguments. I agree multiarch should continue, its just not very important for amd64. It is still extremely important for the other arches: mips, powerpc, s390, etc. Chris
Attachment:
signature.asc
Description: Digital signature