Re: AMD64 Status Update -- And Future Directions
>>>>> "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.
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.
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).
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!!!!
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).
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.
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, ...).
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.
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!!!
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.
Roland
Reply to: