Re: AMD64 Status Update -- And Future Directions
>>>>> "John" == John Goerzen <jgoerzen@complete.org> writes:
John> 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.
John> The problem with this premise is that 64-bit support is needed *more*
John> now than 32-bit support is! That is the angle I take here. I agree
John> that 32-bit support is needed more now than later, but I advance that
John> working 64-bit support is needed more than working 32-bit support.
John> After all, someone that needs a lot of 32-bit apps could just install
John> Debian i386 today and be done with it.
John, your arguments might make more sense in a Debian centric world, but a lot
of, if not most users (rather than maybe some developers) don't live in such a
world, and still want to use and love Debian. So maybe it boils down to the
question: is Debian for their developers only or does it also listen to their
users. I think the latter is the case. As I said, it is your time you invest,
and there are certainly worse ways of where to put it. But please don't try to
influence people with in my opinion simplistic and (sorry for the repetition)
Debian centric arguments.
>> 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
John> Fortunately, Debian is an operating system build from source. A pure
John> 64-bit AMD64 distribution will be just as useful as PowerPC, Alpha,
John> Sparc, or any of the many other distributions we have that work
John> without being binary-compatible with anything else.
Comparing niche architectures like that to x86 is not valid. Backwards
compatibilty is a major issue (just in terms of number of users) for x86 but
not for the platforms you listed.
John> Look at PowerPC as an example. You can not run binaries from any
John> other platform or operating system on a Linux PowerPC machine. Yet
John> Linux on PowerPC is very successful, enjoying not just good support
John> in Debian, but also fostering whole distributions dedicated to Linux
John> on PowerPC.
John> All this without being binary-compatible with even a single
John> architecture anywhere.
John> I do not accept that binary compatibility is required in order for a
John> Debian port to be successful. In fact, what makes a CPU or an
John> architecture successful can be a far different question from what
John> makes a Debian port successful.
John> For example, in PowerPC, one could argue that the architecture was
John> popularized far more by Apple's computers, sporting m68k emulation,
John> 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).
John> This barrier is no higher than the barrier present in every single
John> other of our many successful non-i386 architectures. I believe that
John> 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!!!!
John> That is completely false.
Please reread my e-mail from Monday. A little cleanup (which should be done
soon if possible) will fix those problems.
John> I have installed and played with the multiarch system from Alioth.
John> Do you think I'd be doing this if it worked well?
John> It does not. Let me list a few of the problems:
John> * gcc and binutils are in a terrible state. gcc sometimes generates
John> 64-bit assembler which it tells gas is 32-bit code, and vice versa.
John> It sometimes generates 32-bit code and tries to link it in with
John> 64-bit code (yes I have tried the wrapper).
John> * dpkg and apt are terribly confused, and it is not at all easy to
John> tell apt to get a package from a particular architecture.
John> * Few packages are available for the platform and many libraries do
John> not build at all due to changes made that shake fundamental Debian
John> assumptions.
John> I have no opposition to doing multiarch. I just think it is folly to
John> put off a useful system that *really* works today to satisfy the
John> whims of a very small subset of people, especially when it seems
John> trivial to take the work on a real 64-bit port and enhance it to
John> support multiarch. AND since all the work done to do the real 64-bit
John> 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).
John> That is why I said that after the final product is known we can do
John> the integration. However, I have yet to see anybody advance a
John> scenario in which the change would really be difficult. And there's
John> no need to actually make amd64 be a released stable Debian port until
John> 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.
John> I'm talking about AMD64-specific things; a lot of broken autoconf
John> scripts, dependency loops such as X... things that can't be done in
John> 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.
John> Or perhaps they want something that works *now* and then will work to
John> 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, ...).
John> Debian does not use the Intel compiler, so I fail to grasp what
John> relevance this has to a *Debian* distribution.
Well, you mentioned performance right. Some people actually really need it,
and they require the Intel compiler whether it is part of Debian or not.
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> No, I am saying that the need for 32-bit compatibility on Linux will.
John> There is a very limited set of 32-bit software on Linux that cannot
John> 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
John> No it was not. DEC never supported em86 in any way.
Well, they certainly touted it's existence.
John> Heck, they never even promoted *Linux* until after em86 was
John> virtually dead anyway. It was solely an effort from Linux hackers.
There was a relevance to this from the Microsoft port as well.
>> 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> There is little practical difference on the ground; Alpha could have
John> been biarch back in 1997 if anybody had cared. The only real
John> difference is in performance; em86 was in-kernel.
Emulation in the kernel, and actually having the instruction set in the
processor is still a big difference performancewise.
>> 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.
John> I think you are the one making flawed arguments here.
John> But in any case, I think there is something deeply troubling about
John> the multiarch supporters shouting at me:
John> Stop!!! Stop!!! You'll make people want to join you!!!
John> Let's let people have their own free will. If they want to join the
John> pure64 project, they will; if it sucks, they won't; and I don't see
John> the too as being exclusive clubs.
Well sometimes it is better to use one's brain before running in some direction
and later finding out it was wrong. Who is talking about people not having
their free will? I think it must be allowed to give arguments for both
sides and everyone can decide what he wants to do. I believe that multiarch is
the better way, and I try to convince others about this, just like you do for
your proposal.
John> Again, I repeat: if, because of pure64, enough people leave multiarch
John> to make it wither and die, that means that multiarch was never
John> popular enough to stand on its own, and the only reason those people
John> supported it was because it was the only option to get to what they
John> wanted.
John> And that is NOT a Bad Thing.
Short term popularity is not always the best indicator.
Reply to: