Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Debian

Debian Votes on AMD64 in Sarge 55

Posted by michael from the vote-the-party-line dept.
JayBonci writes "According to a message sent to debian-vote, there is now a GR on the table as to whether or not to include AMD64 into the upcoming sarge release, even though it violates part of the LSB (Linux Standards Base). The debian-vote list has more discussion on it. Does this best meet the needs of the users?"
This discussion has been archived. No new comments can be posted.

Debian Votes on AMD64 in Sarge More

Debian Votes on AMD64 in Sarge

Comments Filter:

  • Outdated already. (Score:4, Informative)

    by Sesse ( 5616 ) <sgunderson@bi g f o o t . com> on Tuesday July 20, 2004 @02:46PM (#9752184) Homepage

    The GR is rescinded -- Chris Cheney rescinded his backing of the GR, so it doesn't have enough sponsors.

    Of course, if another Debian developer would sponsor it, it would be re-added and the whole process would start anew.

    /* Steinar */

  • If LSB can't support AMD64... (Score:3, Insightful)

    by croddy ( 659025 ) on Tuesday July 20, 2004 @02:47PM (#9752206)
    If LSB can't support AMD64, then it's probably time to start putting together a new specification for the LSB. within the next few years, many (if not most) IA32 machines will give way to newer IA64 machines, and for the 'standard platform' project to support only legacy code would be a serious mistake.

    • Re:If LSB can't support AMD64... (Score:4, Informative)

      by Goyuix ( 698012 ) on Tuesday July 20, 2004 @03:01PM (#9752404) Homepage
      Not to troll here, but I doubt we will see many machines giving way to IA64. The more likely route would be x86_64 - AMD's extension to the IA32 architecture allowing for 64 bit operations. IA64 is basically what powers the Itanium line, and well, it has been a collosal underwhelmer....

      Personally I just got my hands on an Athlon 64 and have been toying with it. 64 bits aside, the integrated memory controller really makes it fly for a lot of number crunching goodness. I also read an article just today reviewing the 3800+ socket 939 chip - and it beat the highest end Prescott chip (on the newest 925x motherboards) in every benchmark. When Intel decides to get all its ducks in a row we might see more interesting performance from the chips coming down the pipe.

      Back on topic. I don't think Debian necessarily needs to include AMD64 support in Sarge. Granted, it would be nice and many people would appreciate it being there. It will most certainly be showing up in the future unstable branches as well as many people will have patches, how to, and other reference material. There are plenty of choices for true AMD64 support out in the Linux world. It isn't a matter of Debian supporting it (or LSB for that matter), but more a matter of when.

    • Re:If LSB can't support AMD64... (Score:5, Informative)

      by Cecil ( 37810 ) on Tuesday July 20, 2004 @03:09PM (#9752518) Homepage
      No, IA32 machines will give way to AMD64 machines. IA64 died with Itanium.

      Additionally, LSB 2.0 sets out specifications for AMD64 ports. However, it is still in public review, and is not the current standard. This is a problem for Debian, which has (up until now) always gone out of their way to do things "by the book".
      • I'm hoping the Debian guys make an exception this time... I have no problem resorting to the testing or even unstable tree for a desktop machine (in fact, I'm using testing right now... it's VERY stable). For a server, however, I much prefer to use stable, if for no other reason, it doesn't change much. I know I could put "apt-get update && apt-get upgrade" in my cron.daily and not have anything break, and still have the latest security patches.
    • The article was misleading. LSB is quite compatible with amd64. The incompatibility alluded to in debian is incompatibility of the ia32 subsystem with the LSB for ia32. It's like saying that debian ppc is incompatible with the LSB because when you run an ia32 emulator that imports the filesystem from the host, the resulting system image is not LSB conformant.

      • As I understand it, what you said is not true. The LSB requires that amd64 have the 64 bit libs in /lib64 and the 32 bit ones in /lib ... mainly because that's what AMD wanted (the intention being poeple could/would buy/use AMD64 as a fast 32bit CPU and then at some point "upgrade" to 64bit). Debian has refused to do this, thus the amd64 "port" of debian isn't LSB compliant.

        • The LSB requires that amd64 have the 64 bit libs in /lib64 and the 32 bit ones in /lib

          So is there no support for fat binaries in linux (ELF)? I guess that does make things messy. I wonder how apple will do this...
        • LSB (Linux Standard Base) is a misnomer, it should be RNSB (Redhat and Novell Standard Base).

          It is lead by its members wallets, the AMD64 Pure64 port does not run 32bit binaries (except in a chroot), it has no need for a 32 bit lib directory, same as IA64 and Alpha.

          The multiarch solution is the technically superior one, the LSB should be push that design rather than a broken (lets make some MONEY!!) design.

          • LSB (Linux Standard Base) is a misnomer, it should be RNSB (Redhat and Novell Standard Base).

            Grow up.

            the AMD64 Pure64 port does not run 32bit binaries (except in a chroot)

            ...which is why it's incompatible to everyone else. Look sparc64 had (has?) a 32 userspace for a long time. 32 bit apps. can run faster (I think they often do, actually), with a 64bit kernel ... and they are a hell of a lot smaller, on disk and in memory. And AMD explicitly wanted the layout so you could just use the AMD64 as

            • > Grow up.

              I don't think it was a particularly childish comment, the LSB has done nothing but document how the Redhat and SuSE (now Novell) distributions do things.

              > [multiarch is] not backwards compatible ... and it's not compliant with the LSB. For instance it's not hard to create an new x86 ABI that's faster (technically superior) than the current one, but the fact that it's not compatible with the one everyone else is using would be a pretty big reason to ignore it, if someone did one.

              The libc5

              • I don't think it was a particularly childish comment, the LSB has done nothing but document how the Redhat and SuSE (now Novell) distributions do things.

                I don't think that's true. Possibly more weight was given to RH/SuSe ... but then they have more users. There are Debian users/maintainers on the LSB.

                Yes, third party packaging was defined as a very old version of RPM ... but then you have to take into account it is debian with deb's on one side and RH, SuSe, mandrake, caldera, turbo Linux, etc. et

  • What is the Violation? (Score:5, Insightful)

    by Neon Spiral Injector ( 21234 ) on Tuesday July 20, 2004 @03:10PM (#9752541)
    I'm guessing the violation of the LSB deals with the default system libs. Where does Debian put the 64-bit libs? Where does the LSB say to put them?

    I think the LSB says to put them in /lib64, which I find totally broken. Sure it allows for a 64-bit install to be built on top of an already existing 32-bit install. But what about when 128-bit processors come out? Will we have a /lib, /lib64, and /lib128? How about when there is no longer need for 32-bit support? The /lib directory would be deprecated, so the /lib64 would exist alone?

    What should have been done is on 64-bit distros which wish to offer 32-bit backward compatiblity, the default 64-bit libs should be in /lib and the compatibility libs should have been moved to /lib32. The dynamic linker shouldn't have any problem figuring out what libs are needed, and load the right ones.

    So what road did Debian take? If they have the default system libs in /lib, hear's to them, forget the LSB, it is broken.

    • Re:What is the Violation? (Score:5, Interesting)

      by Sesse ( 5616 ) <sgunderson@bi g f o o t . com> on Tuesday July 20, 2004 @03:27PM (#9752771) Homepage

      The solution that probably will be taken, after sarge, is multiarch [raw.no]; forget /usr/lib32 and /usr/lib64, think /usr/i486-linux/lib and /usr/x64_64-linux/lib. Solves the problem of both two and more (remember, the IA64 can both emulate IA32 and stuff like HPPA, for instance) architectures, but requires some work that most people probably won't let delay sarge.

      /* Steinar */

      • There's no good reason to do that for Sarge, though.
        The architecture (amd64) is compatible with the LSB,
        just like alpha, or ppc.

        It would be good to have the prevalent modern architecture represented in Sarge.

    • Comment removed (Score:4, Interesting)

      by account_deleted ( 4530225 ) on Tuesday July 20, 2004 @04:38PM (#9753631)
      Comment removed based on user account deletion
      • What they need to do is in the compat directory tree that the BSDs use: /usr/compat/ with the needed directory like lib, bin, and so on underneath.

        When you load a 32-bit x86 binary supported via compat libs, you do some nifty loader / linker tricks to make it think /usr/compat/x86/lib is actually /lib.

        Keep all the directories under / for the main architecture of the OS. Put everything else under /usr/compat. It's been working great for many, many yeasr over in BSDland to support Linux, IBCS2, and other

    • Re:What is the Violation? (Score:1, Interesting)

      by Anonymous Coward
      I think the LSB says to put them in /lib64, which I find totally broken.

      Well, it's only like Microsoft did - C:\WINDOWS\SYSTEM (for 16-bit libraries) and C:\WINDOWS\SYSTEM32 (for 32-bit libraries). Of course, in practice everyone put their libraries wherever the hell they liked, but it was a nice idea.
      • But what Microsoft *should* have done is simply provided a through and through 32 bit system with sensible directory names and supplied 32 bit versions of the legacy windows programs to people, like Debian will do.

        The problem is all those third party commercial people that are slow and incompetent and shouldn't be supplying software in the first place.
    • The problem is that existing software installs 32-bit libraries into /lib. You can't go and break all that existing software; backwards compatibility the entire reason we have AMD64 being able to run IA32 binaries. If you want to upgrade a platform and require everything to be rebuilt and repackaged, switch to PPC64. ;-)

      Also, "forgetting the LSB" is a blatantly stupid thing to do. The LSB exists for a very special reason, and that's to make sure libs and apps work everywhere. If Debian does things diff
  • What exactly is the problem with LSB compliance? Isn't AMD-64 backwards-compatible with ordinary x86 code?

    • Re:What's wrong with the LSB? (Score:4, Informative)

      by Jahf ( 21968 ) on Tuesday July 20, 2004 @04:36PM (#9753605) Journal
      Yes and no.

      Yes, the AMD64 chips can run 32bit code even when the kernel is 64bit. But to run an app in 64bit mode you must have 64bit compiled libraries.

      Example ... 64bit kernel wants to run 32bit XFree86 binaries ... it must use 32bit versions of all the Xfree libraries. On the other hand, 64bit kernel wants to run 64bit Xfree86 binaries ... the XFree libraries must be compiled for 64bit usage.

      Therefore you have to have 64bit libraries and 32bit libraries. You can't run a 32bit application with the 64bit libraries and you most definitely can't run 64bit applications with 32bit libraries.

      The 64bit kernel in all the above cases would still be a 64bit kernel, but there are app dependencies.
    • Yes, and that is the problem. An ia32 executable running on debian-amd64 does not see an LSB-conformant ia32 world. Personally, I think it is silly to call that an incompatibility, since ia32 is an emulation layer. Neither does a PPC executable running in emulation on debian-ia32 see an LSB-conformant PPC world, but we don't claim that ia32 falls short of LSB compliance on those grounds.
    • What exactly is the problem with LSB compliance?

      If I compile a program as a 64 bit executable I'm going to need 64 bit libraries to run it. One can imagine creating some sort of shim to allow my 64 bit binary to work with 32 bit libraries. Microsoft did a lot of this during the transition from 16 bits to 32 bits; you may remember the term "thunking" and the mess of DLLs with "32" embedded somewhere in the file name. That's what all that was about; making old apps (16 bit) work with new libs (32 bit) an

  • Choose Debian!!! (Score:2, Funny)

    by Anonymous Coward
    85% more squabbling than any other Linux distribution!

    (Aren't they going to first have the usual debate about whther to use Condorcet or Dweebmatic vote counting?)

    • Re:Choose Debian!!! (Score:5, Insightful)

      by magnum3065 ( 410727 ) on Tuesday July 20, 2004 @06:10PM (#9754565)
      Well, you're just looking at what's public. Most distros the debate is going to be kept within the company. So, you could look at the debates over Debian as a bad thing, or you could realize that this is just indicative of the fact that the community gets more say in the direction of their distribution.

  • disaster (Score:2)

    by jpc ( 33615 )

    They are therefor talking about 2007 before there is a supported stable version for amd64, just for reasons of (basically) the LSB's strange arguments about backwards compatibility. The multiarch stuff is a bit of a red herring, its a nice idea but not that important. Running 64 bit code on what will be the dominant architecture (probably) well before 2007 is. I dont expect to have many 32 bit machines after the middle of next year, except a few still running.

    Lots of people are moving to Gentoo. I am using

Slashdot Top Deals

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Close