Slashdot Mirror

← Back to Stories (view on slashdot.org)

Debian Votes on AMD64 in Sarge

Posted by michael on 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?"

13 of 55 comments (clear)

  1. Outdated already. by Sesse · · Score: 3, Informative

    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 */

    --
    (This comment is of course GPLed.)
    1. Re:Outdated already. by MarsDefenseMinister · · Score: 5, Funny

      I'll get it sponsored, if Chris won't do it.

      But first, I've got to ask a couple questions: how do I become a Debian developer? And what is Debian? And finally, what is Linux? Thanks.

      --
      No weapon in the arsenals of the world is so formidable as the will and moral courage of free men.-Ronald Reagan
  2. If LSB can't support AMD64... by croddy · · Score: 2, Insightful

    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.

    1. Re:If LSB can't support AMD64... by Goyuix · · Score: 3, Informative

      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.

    2. Re:If LSB can't support AMD64... by Cecil · · Score: 5, Informative

      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".

      --
      Random and weird software I've written.
    3. Re:If LSB can't support AMD64... by aminorex · · Score: 2, Informative

      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.

      --
      -I like my women like I like my tea: green-
  3. What is the Violation? by Neon+Spiral+Injector · · Score: 4, Insightful

    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.

    1. Re:What is the Violation? by Sesse · · Score: 4, Interesting

      The solution that probably will be taken, after sarge, is multiarch; 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 */

      --
      (This comment is of course GPLed.)
    2. Re:What is the Violation? by Stephen+Williams · · Score: 4, Interesting

      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.

      I agree, it's hideous, for all the reasons you state. I'd go as far as saying that I don't think that "upgrading" an IA-32 installation to an AMD64 installation should even be supported. Backwards compatibility aside, they're separate architectures, and should thus require reinstallation. It's a small amount of short-term pain to avoid masses of legacy cruft building up afterwards.

      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.

      Absolutely Right(tm). The 64-bit distro is in charge, so it gets dibs on /lib. 32-bit legacy compatibility is just that -- legacy compatibility, and can fit in wherever. Maybe not even /lib32; perhaps demote it to /usr/lib32: no legacy binaries should be required to bring the system up, especially before /usr has been mounted.

      I'm also pleased that Debian has decided to call the architecture "amd64". "x86-64" looks and sounds ugly, IMHO.

      -Stephen

  4. Choose Debian!!! by Anonymous Coward · · Score: 2, Funny
    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?)

    1. Re:Choose Debian!!! by magnum3065 · · Score: 4, Insightful

      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.

  5. Re:What's wrong with the LSB? by Jahf · · Score: 4, Informative

    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.

    --
    It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
  6. Re:Eh? by 7-Vodka · · Score: 2, Interesting
    Don't be ridiculous.
    First of all the performance benefit from compiling things as 686 as opposed to 386 is marginal at best.
    Second, in the 386 debian distribution, packages which *may* have better performance if compiled for 686 are available as such. You can choose them instead of the 386 version.
    Third, the performance benefits from compiling for amd64 as opposed to 386 are somewhere in the region of 15%, compounded, for average apps to astronomical for certain apps.
    Fourth, without a huge change in the fundamental debian architecture ie. multiarch, it's not as simple as mixing and matching amd64 and 386 packages as it is between 686 and 386 packages.

    You're not even in the right ballpark.
    Now, coming back to the topic, is it necessary for me personally to have sarge include amd64? No, but it would be nice. Especially since the unnoficial amd64 distribution has just become the 2nd most popular arch of the debian archs.

    --

    Liberty.