Debian Votes on AMD64 in Sarge

← Back to Stories (view on slashdot.org)

Debian Votes on AMD64 in Sarge

Posted by michael on Tuesday July 20, 2004 @07:40AM 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?"

37 of 55 comments (clear)

Min score:

Reason:

Sort:

Outdated already. by Sesse · 2004-07-20 07:46 · 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 · 2004-07-20 08:14 · 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
If LSB can't support AMD64... by croddy · 2004-07-20 07:47 · 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 · 2004-07-20 08:01 · 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 · 2004-07-20 08:09 · 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 Paladin128 · 2004-07-20 08:56 · Score: 1
  
  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.
  
  --
  Lex orandi, lex credendi.
4. Re:If LSB can't support AMD64... by aminorex · 2004-07-20 13:25 · 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-
5. Re:If LSB can't support AMD64... by jguthrie · 2004-07-20 16:00 · Score: 1
  
  If you're security-minded at all, you might want to re-think using Debian's testing. Security patches are made to Stable and Unstable, but their integration into testing depends on what other defects may be outstanding for the patched packages.
6. Re:If LSB can't support AMD64... by Nevyn · 2004-07-20 19:15 · Score: 1
  
  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.
  
  --
  ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
7. Re:If LSB can't support AMD64... by pldms · 2004-07-20 21:41 · Score: 1
  
  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...
  
  --
  Slashdot looked deep within my soul and assigned
  me a number based on the order in which I joined
8. Re:If LSB can't support AMD64... by Paladin128 · 2004-07-20 23:49 · Score: 1
  
  I don't care about security too much on my desktop machine; it's behind a firewall (running stable) and not visible to the outside world.
  
  --
  Lex orandi, lex credendi.
9. Re:If LSB can't support AMD64... by turgid · 2004-07-21 03:27 · Score: 1
  
  IA64's dead? Better get on the phone to SGI and let them know!
  It's only them and HP in it now. HP is going to intel's Opteron clone, and SGI revived MIPS development. I've no doubt we'll see Opteron/Linux machines from SGI sooner or later.
  
  --
  Stick Men
10. Re:If LSB can't support AMD64... by Bloater · 2004-07-21 08:53 · Score: 1
  
  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.
11. Re:If LSB can't support AMD64... by Nevyn · 2004-07-21 18:21 · Score: 1
  
  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 a faster x86 for a while, if you wanted to ... then upgrade at some later point (but still run your 32bit oracle etc. ... just as you did before).
  
  The multiarch solution is the technically superior one
  
  Possibly, but it's 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.
  
  In another way I, personally, probably would prefer all the 64 bit stuff in /lib /usr/lib etc. and have some /usr/i386-chroot directory tree that I run all my old 32 bit apps under ... but, again, the fact that it's not what everyone else would have is a big reason for me not to do that.
  
  --
  ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
12. Re:If LSB can't support AMD64... by Bloater · 2004-07-22 05:04 · Score: 1
  
  > 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 to libc6 transition was done to improve the technical position, and it was not backwards compatible either, some software had to be recompiled just to co-exist, packaging methods had to be rethought. Similarly for gcc 3.2 and C++.
  
  If you did the same loader magic as was done for libc5 support, only a few peices of software would need altering; and uniarch -> biarch is a far more significant change than libc -> libc6.
  
  > AMD explicitly wanted the layout so you could just use the AMD64 as a faster x86 for a while
  
  AMD can want sugarlumps supplied in boxed Debian sets, but AMD design Microprocessors - they have never even attempted to demonstrate their O/S design abilities.
  
  Debian is not very compatible with other Distros anyway, the packages have to be transformed via alien, and I see no reason why Debian can't translate file operations to /lib depending on arch anyway. It may be a bit more work writing the kernel modules or libc/loader changes, but (and here's the great thing about Debian) they don't have to make money, so they don't have to release crap software just to release in time to get your money.
13. Re:If LSB can't support AMD64... by Nevyn · 2004-07-23 18:21 · Score: 1
  
  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. etc. on the other side with rpms. And most of the differences at that level are aimed at proprietary third parties, everyone in the Open Source world just makes two versions a deb for debian and an RPM for everyone else.
  
  Everything else, like ABIs etc. are mainly lowest common denominator and hence tend to favour Debian, if anything.
  
  The libc5 to libc6 transition was done to improve the technical position, and it was not backwards compatible either, some software had to be recompiled just to co-exist, packaging methods had to be rethought. Similarly for gcc 3.2 and C++.
  
  When the libc5 -> glibc move happened I was still compiling my own kernel and libc. I think I had a copy of the Applix suite ... but I can't remember. And even then, it wasn't too bad you could have old and new apps. running in the same places ... you just had problems with shared libraries (but even then, there was much less shared library usage ... everyone used libc, X stuff used libX* and libc and some other stuff used a couple of others, like zlib) -- you could do new version of 99% the shared libraries by compiling less than 10 tarballs.
  
  That's very different to today. C++ didn't even come close, mainly because not as much stuff used it ... and also because vendors did recompiles as groups (and the older versions in the same place as before continued working).
  
  Trashing ABI compat., at this point, would be orders of magnitude more painful. Every app/lib would need to move, with copious hacking/wrappers to the binaries and even then it would fail randomly for years IMO.
  
  AMD can want sugarlumps supplied in boxed Debian sets, but AMD design Microprocessors - they have never even attempted to demonstrate their O/S design abilities.
  
  However they have demonstrated backwards compatability, a great deal more than the Linux community has had to do. And they paid everyone, thus invoking the golden rule. Certainly large companies buying AMD64 boxes will be buying them so they can run their x86 Oracle etc. better than before.
  
  Debian is not very compatible with other Distros anyway, the packages have to be transformed via alien, and I see no reason why Debian can't translate file operations to /lib depending on arch anyway.
  
  That's fine, they can do whatever they want ... they can just say fuck everyone else we'll do it our way. And everyone else will ignore them.
  
  (and here's the great thing about Debian) they don't have to make money, so they don't have to release crap software just to release in time to get your money.
  
  Define "crap software" certainly compiling anything on Debian that just used libc and the kernel can be a crap experience ... I've found/reported compiler bugs over 18 months ago, that were just responded with "sorry, no man power ... don't do that".
  
  No Open Source product "has to release" to make money. Most of the good ones realize that releasing more than once every three years is a good thing though. And more than a few think that having newer, faster tech. like a decent compiler, threading, LVM, GUIs etc. isn't such a terrible thing either.
  
  --
  ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
What is the Violation? by Neon+Spiral+Injector · 2004-07-20 08:10 · 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 · 2004-07-20 08:27 · 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 · 2004-07-20 09:38 · 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
3. Re:What is the Violation? by Anonymous Coward · 2004-07-20 10:02 · Score: 1, Interesting
  
  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.
4. Re:What is the Violation? by aminorex · 2004-07-20 13:28 · Score: 1
  
  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.
  
  --
  -I like my women like I like my tea: green-
5. Re:What is the Violation? by phoenix_rizzen · 2004-07-21 02:48 · Score: 1
  
  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 binary programs running on top of the BSD OS.
6. Re:What is the Violation? by Bloater · 2004-07-21 08:59 · Score: 1
  
  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.
What's wrong with the LSB? by avalys · 2004-07-20 08:11 · Score: 1

What exactly is the problem with LSB compliance? Isn't AMD-64 backwards-compatible with ordinary x86 code?

--
This space intentionally left blank.
1. Re:What's wrong with the LSB? by Jahf · 2004-07-20 09:36 · 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.
2. Re:What's wrong with the LSB? by aminorex · 2004-07-20 13:30 · Score: 1
  
  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.
  
  --
  -I like my women like I like my tea: green-
3. Re:What's wrong with the LSB? by Tailhook · 2004-07-21 11:22 · Score: 1
  
  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) and vise versa.
  
  So the problem you're left with if you want to run both 32 and 64 bit software (sans a "shim") is; where to put two versions of almost every library. The LSB specifies where to put stuff in the file system. It does not account for the need to handle alternate compiled libs, so Debian (and others,) have to invent things non-LSB compliant to make it work. Thus the debate.
  
  It is ironic that Debian isn't trumpeting this; If your platform is 100% open software you should be able to recompile everything 64 bit and move on. However, you will be stuck if you try to run someone's closed binary 32 bit only stuff. Doesn't that validate their whole agenda?
  
  Isn't AMD-64 backwards-compatible with ordinary x86 code?
  
  Yes, but 32 bit software isn't forward compatible with 64 bit software and vise versa. AMD-64 does not implement a magic thunking feature to provide this (and it shouldn't.)
  
  Ultimately our linkers will need the brains added to know how to select the correct libraries to suit the executable (which must already be the case since it is possible now.) Where the alternate compiled objects live on the filesystem will also have to be figured out. When the LSB gets around to figuring this out our little Debian drama will end.
  
  This whole stupid process has occurred on every platform that has been around long enough to have had to transition from one word length to another. "Linux" probably won't suffer the hell of magic "thunking" crap that Microsoft has and will foist on the world (I wonder if the long beta period for 64 bit Windows is the result of some form of unspoken collective shame, because whatever solution they come up with this time around is likely to be just as butt ugly as the last time.) But in the mean time Windows will "just work" and you won't ever hear about the difference between 32 and 64 bit binary objects, unless you're a coder...
  
  --
  Maw! Fire up the karma burner!
Choose Debian!!! by Anonymous Coward · 2004-07-20 08:45 · 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 · 2004-07-20 11:10 · 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.
2. Re:Choose Debian!!! by ninejaguar · 2004-07-26 13:08 · Score: 1
  
  A corporate debate would either be technical or territorial. This Debian thing seems to be primarily bureaucratic.
  Really? I would have said democratic.
  = 9J =
Re:Eh? by 7-Vodka · 2004-07-20 12:24 · 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.
Re:Debian: idealism vs. just make it work by nbmorgan · 2004-07-20 20:21 · Score: 1
If you want to "just make things work":
1. Make sure you have pleny of duct tape on hand
2. Do not be suprized or complain when two years from now you realize that "Just making it work" created a tar baby instead of a gem.
Yes, but by mr_tenor · 2004-07-20 20:24 · Score: 1

2nd most popular machine running the popcon reporting program. But this was due to a cluster being installed.
1. Re:Yes, but by 7-Vodka · 2004-07-21 09:58 · Score: 1
  
  what are you saying? that there are no clusters for the other arches?
  Give me a break.
  
  --
  Liberty.
disaster by jpc · 2004-07-20 21:18 · Score: 1

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 Fedora at the moment, as my main machine is amd64.
The problem by DreadSpoon · 2004-07-21 11:18 · Score: 1

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 differently than the LSB 2.0 specifies, then *Debian* is broken, because nothing will work on it except apps and libs made specifically for Debian.
1. Re:The problem by JamesKPolk · 2004-07-24 15:49 · Score: 1
  
  You left out a word, which I include here in caps: "...that's to make sure PROPRIETARY libs and apps work everywhere."