I upgraded my desktop PC to an AMD Athlon64 3000+ last week. I got an ASUS k8v SE Deluxe mainboard rather cheap, and also upgraded my hard disk to a SATA disk (a lot of new technology to get involved with ;-) ) As always with unknown technology, there was some trouble at the beginning. The mainboard contains two SATA controllers, one Promise and one VIA. The Promise controller did not work very well, but the hard drive was not detected when connected to the VIA controller, only the Promise controller detected it at all. I made an BIOS upgrade, which did not help much. Finally I found a poorly documented jumper on the hard drive ("Use SATA-150 only", whatever this means for a SATA-150 drive (non-SATA-II)). After I plugged in this jumper, the drive was also recognized by the VIA controller.
Of course I installed the AMD64 port of Debian, which was much less troublesome as the installation I tried on an EM64 Intel Pentium some months ago, probably because I did not need to install on a RAID this time. Nevertheless I decided to put the complete installation on a LVM managed partition, basically to get more familiar with LVM concepts.
The installation runs quite well, the AMD64 KDE 3.5.0 packages in unstable seem to be broken, but the somewhat older packages from pkg-kde.alioth.debian.org work well. However, one issue is that not all software is available as AMD64 binary. For example, OpenOffice.org 2.0 is still being worked on, and it seems that porting it to AMD64 is a bunch of work. Also, some more closed software like Acrobat Reader or Macromedia Flashplayer is not available. Especially OpenOffice.org is sad, but it is almost trivial to setup a chroot environment with ia32 binaries, so that all those applications can still be used. The drawback is of course that all libraries need to be installed both as 64 bit and as 32 bit versions (and also be loaded in memory when a 32 bit application is launched). The chroot environment took about 550 MB after installing OpenOffice.org; but, hey, this is almost as much as MS-Office takes, with the difference that the chroot contains an almost complete operating system installation ;-)
I have written a very simple script which transforms all Packages files in a debian archive into an xml file. This xml file can then be transformed into an html file through an xslt file. The result for my Debian archive can be viewed here.
Yesterday I replaced my personal debian archive at www.littletux.net/debian (which used a simple, flat structure) with a pool based archive. The archive is handled by debpool, a debian archive management tool which is quite simple to set up. It is available from the Debian experimental archive. The main advantages from this tool are that I can use the standard dupload tool to upload packages to the archive, and that it allows to manage packages for various distributions like stable and unstable.
To access the archive, it is sufficient to add lines like
deb littletux.homelinux.net/debian unstable main contrib non-free
deb-src littletux.homelinux.net/debian unstable main contrib non-free
to /etc/apt/sources.list. Note that www.littletux.net does not work.
Yesterday, I spontaneously decided to replace the XFree86 X server with the new X.org X server on my desktop computer. A simple "apt-get install xserver-xorg discover1 mdetect xresprobe" was sufficient to migrate the server. I already heard that migration is quite simple and problem-free, so I was strained what would happen after I restarted the X server. I was excited that the server indeed started up and displayed the window manager, so at least the basic setup worked. I only had to make two additional refinements:
Of course, I also tried some of the new features, especially transparency. To enable these features, the "Composite" extension must be activated with an entry like
Option "Composite" "true"
in the xorg.conf configuration file. However, for NVidia cards, this has the effect that the "glx" extension can not be used anymore. This can be changed by adding "Option "AllowGLXWithComposite" "true"" to the "Device" section in the xorg.conf file. Then, applications which use glx (like glxgears) work again.
I then activated transparency in the KDE control center. However, the "nvidia" driver seems to be really unstable when activating this feature, the X server crashed several times. So I switched back to the "nv" driver, which seems to be more stable. In either case, moving transparent windows was very slow, and also adding "Option "RenderAccel" "true"" as sometimes suggested did not help. For now, I deactivated the transparency feature again, but I look forward to this being more stable, because it looks really cool!