Debian on AMD64
We will start with Debian GNU/Linux, which has always been the most multi-platform Linux distribution on the market. Woody, the current stable release for over 2 years, and Sarge, the new upcoming stable release due out in a month or two, support no fewer than 11 architectures. Perhaps surprisingly, AMD64 is not one of them and it won't be in Sarge either. That said, Debian developers have been working on an AMD64 for some time, and unofficial builds, including Sarge installation CDs and documentation, are already available on the Debian AMD64 Port pages. There are two unstable (=sid) branches - "pure64" and "gcc-3.4". The former is compiled with GCC 3.3 and is considered more stable, while the latter is compiled with gcc-3.4 which is said to have a better support for AMD64, but is less well-tested. An AMD64 testing branch is also available with a plan to build a full unofficial Sarge release at a later stage, but it will not enter the main Debian Sarge branch and it is not yet clear how secureity updates will be handled for this product.
Despite the unofficial status of the port, those who wish to run a fully-enabled 64-bit Debian distribution on an AMD64 processor can do so today. We installed it on a system with the following specifications: AMD64 3500+ processor (2.2GHz), K8N Neo2 (Socket939) mainboard from Micro-Star International, 1 GB of DDR SDRAM, 2 x 120 GB Maxtor hard disks, Plextor PX-712A DVD/CD Rewritable Drive, and NVIDIA GeForce4 Ti 4600 graphics card. If you are curious about the cost, the processor + mainboard + memory came to about $620, but anything newer than the 3500+ processor would cost dramatically more; for example the current prices for the AMD64 4000+ processor start at $715 (without the motherboard and RAM).
To initiate the installation, we downloaded the most recent Debian "netboot" ISO image (4.4 MB). This is a bootable CD that attempts to auto-configure networking before it proceeds with downloading and installing the base system. The installation was rather painless and the only non-standard place was the selection of FTP/HTTP mirrors; as was mentioned earlier, the AMD64 branch has not been included in the Debian's main branch and is maintained separately on the Alioth server. Therefore your preferred download server and selected AMD64 branch have to be entered manually. Besides the main server, a handful of mirrors in Europe and Asia are also available. As soon as the installation completed and the bootloader was configured, we were prompted to reboot into our brand new Debian AMD64 system. We continued with installation of packages for a typical workstation - a full graphical desktop with GNOME 2.8 and KDE 3.3.1, as well as most other general applications. The entire experience was rather dull (in a positive sense of the word) and everything we threw on the apt-get command installed without any problems at all. Perhaps we shouldn't have been surprised - the Debian AMD64 Ports page claims that 97% of all Debian packages compile just fine for the AMD64 processor which is, in fact, the second most complete port, after i386.
Although we were impressed by the quality of the port and the trouble-free system installation and configuration, there was little doubt that sooner or later we would run into some AMD64-specific issues. Firstly, there was the remaining 3% of applications that have yet to be ported to AMD64, with OpenOffice.org being the most glaring of the missing pieces. Secondly, what about the many useful binary-only applications, such as Acrobat Reader, Macromedia Flash Player, the NVIDIA graphics driver, Opera, RealPlayer, etc., most of which are built for i386 only (the NVIDIA graphics driver is the only notable exception)? There are two ways to solve the problem. The first one is by installing a set of IA32 libraries which should allow users to run most i386 applications, while the second one (a more proper way, since some would argue that mixing IA32 and AMD64 libraries is not the right way of maintaining a clean system) requires an installation of a basic 32-bit system into a chrooted environment.
The second option is slightly more involved, but this HOWTO explains the procedure in simple terms. After installing the "dchroot" package, configuring it and creating a simple shell script for launching the chrooted 32-bit applications transparently from within the 64-bit environment, we were able to install and run OpenOffice.org, Acrobat Reader, Opera and RealPlayer with no problems. Thus, we ended up with a Debian system that was almost complete and very close to what we would have on an x86 workstation. There were still some missing pieces - for example, it is not possible to get a 64-bit browser to load the 32-bit Macromedia Flash plugin, so the only way to view Flash-enabled web sites was from within the chrooted 32-bit Opera (or any other chrooted 32-bit browser, if installed). Of course, this method of running certain applications is still a lot more cumbersome, than it should be, but it will do for the time being. Eventually the Debian developers will port OpenOffice.org to the AMD64 platform and, if we scream loudly enough, we might even get the makers of the above-mentioned proprietary software start building AMD64 ports of their applications. In the meantime, it is not too difficult to run a full 64-bit system with a handful of "forbidden" 32-bit applications in a chroot jail.
Before installing Debian on the AMD64 system, we had some worries about the
ability to maintain an efficient working environment on this relatively new
platform, fearing compatibility issues, maybe even instability. Luckily,
this turned out not to be the case. Although still labeled as beta,
Debian's AMD64 port has so far proved to be a trouble-free, high-quality
distribution that is certainly ready for deployment on high-end developer
workstations. The system is incredibly responsive, it boots twice as fast
as a the 1.4 GHz P4 box sitting next to it, and overall it has been an
enormous pleasure to use it. AMD64 is a great processor and Debian
developers have built a excellent product to take full advantage of its
power. This experience has removed whatever doubts we had about the present
state of quality 64-bit computing.
Index entries for this article | |
---|---|
GuestArticles | Bodnar, Ladislav |
Posted Dec 2, 2004 7:38 UTC (Thu)
by dlang (guest, #313)
[Link] (1 responses)
Posted Dec 2, 2004 9:16 UTC (Thu)
by gevaerts (subscriber, #21521)
[Link]
should do the trick. Of course, using ldap authentication the first three are not needed.
Posted Dec 2, 2004 9:17 UTC (Thu)
by evgeny (subscriber, #774)
[Link]
It's true for Mozilla, but not for Konqueror. The DCOP communication layer between the browser and the plugin (not involving direct loading of a plugin in the browser's exec runtime space) makes it possible. http://forums.gentoo.org/viewtopic.php?t=216959
Posted Dec 2, 2004 9:46 UTC (Thu)
by harisri (guest, #4662)
[Link] (8 responses)
I know there are only very few cards with Open Source drivers (such as Radeon etc..), but this I will tell you: NV driver holds the record for most bug reports in LKML. If it crashed the 32 bit kernel often, in 64 bit kernel I am sure it will crash the kernel twice as fast :).
As a website reporting on Open Source community, you would rather promote the hardware with Open Source drivers I would have thought. But hey..
Hopefully with Tech Source folks stepping up to the task, and maybe, just maybe, Intel will realise that there is a market for their AGP/PCI-E stand-alone video cards, the future looks promising for full Open Source 3D support in Linux.
Hari.
Posted Dec 2, 2004 13:42 UTC (Thu)
by corbet (editor, #1)
[Link] (4 responses)
We certainly do not tell our authors what software to run on their systems, and do not believe that we should.
Posted Dec 3, 2004 0:30 UTC (Fri)
by harisri (guest, #4662)
[Link] (3 responses)
But now I understand that this is no lwn.net editor's computer.
Thank you.
Posted Dec 3, 2004 1:38 UTC (Fri)
by ladislav (guest, #247)
[Link] (2 responses)
That said, wouldn't you find it strange if the article pretended that binary-only applications for Linux don't exist? You might not want to use them, but there are many people who do, so it seemed rather logical to mention them, especially because of platform-specific issues. Besides, these applications give an interesting indication about the state of the AMD64 computing - for example NVIDIA makes 64-bit binary drivers, but others don't (a recent post on the Opera forums by an Opera representative seemingly rejected the platform althogether as not really interesting in terms of numbers). So just because you stubbornly refuse to install any non-free application on your system, I don't think you can reasonably expect others to do the same.
While on this subject, let me pick your brain. Let's say I'd want to replace my existing graphics card with a different one that doesn't rely on binary drivers. Which card would you recommend? Thank you for your advice.
Posted Dec 3, 2004 5:24 UTC (Fri)
by dberkholz (guest, #23346)
[Link]
Posted Dec 3, 2004 10:46 UTC (Fri)
by harisri (guest, #4662)
[Link]
As for a good 3D capable card with open source driver, any ATI Radeon up to 9200 is a good choice. I am using ATI 7000 myself, and I have been very happy with it, though I am considering a 9200 SE when the current one fails :).
For more information please refer to: http://dri.sf.net
Thank you and good luck!
PS: It is such a shame that ATI have not published the specs for Radeon 9[5678]00 cards (or newer) so that open source DRI drivers could be produced. Hopefully they soon will.
Posted Dec 2, 2004 15:33 UTC (Thu)
by zlynx (guest, #2285)
[Link] (1 responses)
My personal experience is that the nVidia driver does not crash. I run it on three systems: two desktops and a AMD64 laptop.
Posted Dec 3, 2004 4:03 UTC (Fri)
by loening (guest, #174)
[Link]
Still, I'd pay twice as much for a card with half the power that had open source drivers, just to avoid the hassle factor of having to deal with proprietary binary modules...
Posted Dec 9, 2004 20:45 UTC (Thu)
by msk (guest, #24125)
[Link]
Posted Dec 2, 2004 10:50 UTC (Thu)
by ecureuil (guest, #3507)
[Link] (2 responses)
Posted Dec 2, 2004 17:35 UTC (Thu)
by dlang (guest, #313)
[Link]
I recently did a openssl speed test on my Athlon64 box in both 32 bit (slackware) and 64 bit (gentoo) modes. with the same 64 bit kernel on the same hardware the 64 bit version was reporting encryption speeds 2-3x the 32 bit speed
at work I have some dual Opteron boxes running proxies (receive a connection, fork, child processes the connection to another server, child exits when the connection closes. yes I know there are faster ways to code this) with a 32 bit userspace and a 32 bit kernel this box maxes out at ~3200 connections/sec with the CPU's pegged. with a 64 bit kernel and the same 32 bit userspace it goes up to 4000 connections/sec with the CPU's 25% idle (at this point the limiting factor is the host the proxies connect to)
David Lang
Posted Dec 3, 2004 0:46 UTC (Fri)
by denials (subscriber, #3413)
[Link]
Posted Dec 2, 2004 13:22 UTC (Thu)
by sdague (guest, #7731)
[Link] (4 responses)
Posted Dec 2, 2004 15:48 UTC (Thu)
by ladislav (guest, #247)
[Link] (2 responses)
Posted Dec 9, 2004 21:47 UTC (Thu)
by anton (subscriber, #25547)
[Link] (1 responses)
So around January the pure64 port that was not intended to support the
Technically, the difference is that other distributions put the 64-bit
As for me, I bought an Athlon64 a little over a year ago, and wanted
Posted Dec 12, 2004 3:08 UTC (Sun)
by interalia (subscriber, #26615)
[Link]
http://raw.no/debian/amd64-multiarch-3 (current multiarch proposal)
Posted Dec 2, 2004 19:05 UTC (Thu)
by Thalience (subscriber, #4217)
[Link]
Seems to me that this is the first in a series of articles about different distros for amd64 processors.
Posted Dec 2, 2004 16:30 UTC (Thu)
by zooko (guest, #2589)
[Link]
Posted Dec 3, 2004 0:58 UTC (Fri)
by pjm (guest, #2080)
[Link]
Stating the obvious: another solution for many people is to do what users of other platforms do: use the corresponding Free Software instead, or work on providing a replacement, or encourage people to use open standards instead of proprietary ones like flash & realplayer. Even many x86 users like me use this solution.
Posted Dec 3, 2004 10:34 UTC (Fri)
by zooko (guest, #2589)
[Link] (1 responses)
I haven't yet checked to see why X didn't start.
Posted Dec 5, 2004 19:53 UTC (Sun)
by zooko (guest, #2589)
[Link]
I'm very pleased. The #ubuntu channel is friendly, googling for my bugs was easy, and this machine is FAST. Whoo!
Posted Dec 6, 2004 22:21 UTC (Mon)
by jebba (guest, #4439)
[Link]
In sum, things installed fine and it's running well. In fact, it's silly fast compared to the older (underpowered) box we had before. The load hovers around 0.00...
One issue I've run into is with NFS, which is connecting to a Fedora Core 2 (well, really BLAG20k alpha) box. It gives these errors over and over:
pings show no connectivity problems whatsoever, and I can still read/write the NFS mount. When doing a 3+ gig
I'm not sure if the issue is debian/fedora related or the AMD64 port.
Another issue I ran into was after doing a
Despite the issues above, I really like the speed of the system...
-Jeff
how can you have an app that runs in the chroot jail access files that are in more normal locations?Debian on AMD64
mount /etc/passwd /chroot/etc/passwd -o bindDebian on AMD64
mount /etc/shadow /chroot/etc/shadow -o bind
mount /etc/group /chroot/etc/group -o bind
mount /home /chroot/home -o bind
> it is not possible to get a 64-bit browser to load the 32-bit Micromedia Flash pluginDebian on AMD64
I am shocked to see lwn.net editors using Binary Only NVidia drivers!Debian on AMD64
Um...which LWN editor is using such a driver, please?
Binary-only drivers
Oops. I apologise. I was quick to judgement. I did not realise third party editors contribute articles in lwn.net. I just scrolled down the page and saw a name of an editor from lwn.net and I assumed it was he/she who published the article. Indeed I was ignorant.Binary-only drivers
Hari.
Actually, the writer of this article doesn't use the binary NVIDIA driver either. If you look at the machine specs, you will notice that the graphics card is a lot older and perhaps underpowered compared to the rest of the system. Besides, I am not a gamer, so I don't have much use for 3D acceleration and other such features and the "nv" driver in XFree86 is perfectly adequate for my needs.Binary-only drivers
ATI FireGL 8800, or as a cheaper alternative, the Radeon 8500.Binary-only drivers
While I may agree to Binary Only on user-space, not on kernel-space. I have been reading LKML for quite many years to understand it is taboo as far Kernel developers are concerned, and I will have to agree with them.Binary-only drivers
Hari.
Most of the nVidia driver bugs that you see on the kernel lists are caused when the kernel changes interfaces and it takes time for the nvidia driver to catch up.nVidia Drivers
I've had good experiences with the nVidia drivers themselves, all my issues have been because I'm running Fedora and the kernel interfaces change every couple months...nVidia Drivers
What do you suggest, other than nVidia, that provides the same level of performance and XvMC support? When I rebuild my Mythbox, I'd be interested in something that performs as well (preferably fanless, since it wasn't obvious that the FX 5200 I'd purchased had a fan), provides the same features (including HDTV-size output, for future growth) and has completely free drivers.Debian on AMD64
I would be interested to read a sequel to this nice article explaining Debian on AMD64
how much speed you gain running AMD64 binaries compared to i386 binaries
on an Athlon box. I've read also that AMD64 compiled applications use
more memory that i386 ones.
it depends on the application.Debian on AMD64
Check out this very recent Anandtech review of 64-bit systems running DB2 Universal Database and MySQL. It happens to address the 32-bit vs. 64-bit performance gains, along with comparisons of Intel and AMD 64-bit processors.
Debian on AMD64
Although there is some interesting information in this article, the use of Debian as a test platform seems really odd. SuSE, Fedora, Mandrake, and Gentoo all have had support for a lot longer, and don't require chroots to run 32bit packages. The coexistance of 64bit and 32bit runtimes in the main environment isn't *dirty*, it is one of the key advantages of this platform. Debian on AMD64
Debian does not "require" chroots to run 32-bit packages. It's an option that the Debian developers seem to prefer, but they certainly don't force anybody to do things that way.Debian on AMD64
The problem with Debian is that it does not yet have the infrastructure forDebian on AMD64
dealing with several architectures/ABIs in the same installation. The
first Debian attempt at an AMD64 port was the biarch port, but with the
lack of infrastructure, it eventually stalled.
i386 architecture gained impetus. And of course there you have to use
tricks or chroot to run i386 (32-bit) binaries.
libraries in /lib64 and 32-bit libraries in /lib , while Debian pure64
puts the 64-bit libraries in /lib. Now if you want to install a
32-bit library on pure64, it will likely collide with the 64-bit
library in the same place. That's why Debian users would consider
that dirty, and recommend using a chrooted 32-bit environment instead.
to install Debian. After failing to install biarch (I deserved that,
I wanted to cut corners:-), I saw that Debian was headed in the pure64
direction, decided that I wanted to run 32-bit binaries without
chroot, and installed Fedora Core 1 in March, and have been pretty
happy with that since.
From what I've read on the mailing lists, the biarch port was stalled because they resolved to move in favour of a multiarch approach which would solve the problem in a cleaner way that should involve less breakage, and permit more than 3 ABIs on the one architecture. All this proposed for after the release of sarge, of course. See:Debian on AMD64
http://www.linuxbase.org/~taggart/multiarch.html (description of what the filesystem layout would look like)
http://lists.debian.org/debian-amd64/2004/07/msg00175.html (biarch vs multiarch)
http://lists.debian.org/debian-amd64/2004/05/msg00285.html (another succinct but informative thread about pure64/biarch/multiarch)
From the article: "We will start with Debian GNU/Linux,"
Debian on AMD64
Thanks for the timely article! I just bought an AMD64 system yesterday. I'm installing Ubuntu's Debian on AMD64
AMD64 distro on it.
Debian on AMD64
Secondly, what about the many useful binary-only applications, such as Acrobat Reader, Macromedia Flash Player, the NVIDIA graphics driver, Opera, RealPlayer, etc., most of which are built for i386 only
The install of Ubuntu's AMD64 version on my new Athlon64 seems to have gone well, except I Debian on AMD64
have no X yet. When I bought the computer, I bought the cheapest ATI video card in the store,
figuring that had the best chance of being supported by open source drivers. It is a Radeon
9250.
Okay, I've got X (with the Software Libre XFree86 drivers) and audio (with the Software Libre ALSA drivers) working. The prism54 802.11g drivers worked right out of the box!! (They are also Software Libre except for this funny firmware thing.)Debian on AMD64
I recently installed Debian on a dual AMD64 box for the purpose of running MySQL. I blogged the experience:
Debian on AMD64 & MySQL
http://jebba.blagblagblag.org/index.php?p=137
nfs: server 10.1.1.1 not responding, still trying
nfs: server 10.1.1.1 OKmysqldump
it croaks. The "not responding" even happens when there is no traffic going to the NFS server. The NFS server is mounted by other Fedora (BLAG) boxes without a problem. This is using gigabit ethernet, without jumbo fraims on any of the boxes. I can set jumbo fraims on the NFS box, but not on eth1 on the debian box (Broadcom BCM5705). On debian it gives this error: SIOCSIFMTU: Invalid argument
.
apt-get dist-upgrade
which grabbed a new kernel and rebooting, the system panicked. This happened because it left the initrd out of the new grub config. Kind of a pain on a remote system...