Re: AMD64 Status Update -- And Future Directions
On Thu, Feb 12, 2004 at 11:29:23PM +0100, Roland Fehrenbacher wrote:
> 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.
The problem with this premise is that 64-bit support is needed *more*
now than 32-bit support is! That is the angle I take here. I agree
that 32-bit support is needed more now than later, but I advance that
working 64-bit support is needed more than working 32-bit support.
After all, someone that needs a lot of 32-bit apps could just install
Debian i386 today and be done with 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
Fortunately, Debian is an operating system build from source. A pure
64-bit AMD64 distribution will be just as useful as PowerPC, Alpha,
Sparc, or any of the many other distributions we have that work without
being binary-compatible with anything else.
Look at PowerPC as an example. You can not run binaries from any other
platform or operating system on a Linux PowerPC machine. Yet Linux on
PowerPC is very successful, enjoying not just good support in Debian,
but also fostering whole distributions dedicated to Linux on PowerPC.
All this without being binary-compatible with even a single architecture
anywhere.
I do not accept that binary compatibility is required in order for a
Debian port to be successful. In fact, what makes a CPU or an
architecture successful can be a far different question from what makes
a Debian port successful.
For example, in PowerPC, one could argue that the architecture was
popularized far more by Apple's computers, sporting m68k emulation, than
by IBM's servers.
> 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).
This barrier is no higher than the barrier present in every single other
of our many successful non-i386 architectures. I believe that it is not
only surmountable, but insignificant.
> 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!!!!
That is completely false.
I have installed and played with the multiarch system from Alioth. Do
you think I'd be doing this if it worked well?
It does not. Let me list a few of the problems:
* gcc and binutils are in a terrible state. gcc sometimes generates
64-bit assembler which it tells gas is 32-bit code, and vice versa.
It sometimes generates 32-bit code and tries to link it in with
64-bit code (yes I have tried the wrapper).
* dpkg and apt are terribly confused, and it is not at all easy to
tell apt to get a package from a particular architecture.
* Few packages are available for the platform and many libraries do not
build at all due to changes made that shake fundamental Debian
assumptions.
I have no opposition to doing multiarch. I just think it is folly to
put off a useful system that *really* works today to satisfy the whims
of a very small subset of people, especially when it seems trivial to
take the work on a real 64-bit port and enhance it to support multiarch.
AND since all the work done to do the real 64-bit port must be done
*anyway* for the multiarch port.
> 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).
That is why I said that after the final product is known we can do the
integration. However, I have yet to see anybody advance a scenario in
which the change would really be difficult. And there's no need to
actually make amd64 be a released stable Debian port until this is
sorted out.
> 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.
I'm talking about AMD64-specific things; a lot of broken autoconf
scripts, dependency loops such as X... things that can't be done in an
automated fashion.
> 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.
Or perhaps they want something that works *now* and then will work to
improve it.
> 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, ...).
Debian does not use the Intel compiler, so I fail to grasp what
relevance this has to a *Debian* distribution.
> 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.
No, I am saying that the need for 32-bit compatibility on Linux will.
There is a very limited set of 32-bit software on Linux that cannot be
quickly recompiled for a 64-bit platform.
> 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
No it was not. DEC never supported em86 in any way. Heck, they never
even promoted *Linux* until after em86 was virtually dead anyway. It
was solely an effort from Linux hackers.
> 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!!!
There is little practical difference on the ground; Alpha could have
been biarch back in 1997 if anybody had cared. The only real difference
is in performance; em86 was in-kernel.
> 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 think you are the one making flawed arguments here.
But in any case, I think there is something deeply troubling about the
multiarch supporters shouting at me:
Stop!!! Stop!!! You'll make people want to join you!!!
Let's let people have their own free will. If they want to join the
pure64 project, they will; if it sucks, they won't; and I don't see the
too as being exclusive clubs.
Again, I repeat: if, because of pure64, enough people leave multiarch to
make it wither and die, that means that multiarch was never popular
enough to stand on its own, and the only reason those people supported
it was because it was the only option to get to what they wanted.
And that is NOT a Bad Thing.
-- John
Reply to: