AMD64 Status Update -- And Future Directions
Hello,
At this time, the autobuilder has generated close to 3000 packages, all
of which are present on my repository. It has also nearly exhausted the
list of packages that it can build.
That is for several reasons. One is that there are certain important
packages missing that others build-depend upon (I highlighted these in
my earlier message). Another is that some packages just don't quite
build out of the box.
In any case, the 3000 packages represent a full selection of packages;
everything from games to MySQL and Perl. It is absolutely a working
system and a useful system already.
I have received several offers for help, both public and private,
regarding the pure64 port. I offer my kind thanks to all of you. I do
not really need help with the autobuilder, but any help you have to
offer with things that it fails to build -- especially X -- would be
appreciated. As you work, please remember to save off your patches
somewhere safe; once we become a real port, we will need to submit them
to Debian maintainers so they can be integrated with the Debian
packages.
I feel it is time for us to start thinking about what will come of the
AMD64 port. There is a limit to what we can do without being an
"official" Debian port project. Of course, being an "official" Debian
port project does not obligate us to release with the next version of
Debian, but makes many useful bits of infrastructure available and helps
us coordinate better. In general, it makes our task easier and makes
the tasks of others that must work with us easier as well.
I propose that we build the Debian AMD64 port first as a pure 64-bit
port, perhaps using the existing pure 64-bit packages as a guide. There
will be no 32-bit binaries in it, no capability to run 32-bit binaries
(aside from a chroot that the user can create with existing tools), etc.
We will have a true, working, usable 64-bit version of Debian to use,
*now*.
Then...
When a way forward with the multiarch is finally laid out, and we are
confident that it will work, we can transition to being a multiarch
platform, *while still supporting those that want a pure 64-bit
environment*. I personally see no reason why moving from pure64 to
biarch64 is any more difficult than moving from i386 to biarch64.
This plan has the following benefits, when compared to the existing "do
nothing until multiarch works" plan:
1. We get a head start on fixing the 64-bit bugs. We get things
working in AMD64 first, then make them work with 32-bit stuff too.
2. We get more people using Debian on AMD64... they could help out with
the multiarch effort later.
3. We provide a way for people that use Debian and demand top
performance to get it, rather than turning them away to Gentoo, RedHat,
or NetBSD.
Finally, I should point out that it is by no means a certainty that
multiarch will be a valuable feature in either the short-term or the
long-term. Significant rumblings indicate that lots of major vendors --
including Intel -- are jumping on the AMD64 bandwagon in a major way.
By the time we finish multiarch support, it may be completely obsolete;
then we will have delayed a useful AMD64 port for no good reason.
This is not just a hypothetical. A parallel situation existed on Alpha,
where the em86 system existed to run i386 Linux binaries unmodified on
an Alpha (albeit at a greater performance penalty than running i386
binaries on an AMD64). This was initially important to early adopters
of the Alpha, since there were no web browsers as good as Netscape at
the time, etc. But em86 hasn't really been kept up, and probably
doesn't work in any kernel later than 2.0 or maybe 2.2. There is simply
no need for it anymore.
This could very well happen to us.
Let's prevent that.
-- John
Reply to: