Slamd64 uses /lib64 and /usr/lib64 for 64-bit libraries, and /lib and /usr/lib for 32-bit binaries. There are several reasons for this (in no particular order) 1) It is what the relevant standard, the FHS, says (http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64) 2) It increases compatibility with 32-bit binaries - it is fairly common for programs to have hardcoded library paths, especially /lib/ld-linux.so.2 (which must be 32-bit for 32-bit binaries to run unaltered). 3) It increases compatibility with 64-bit binaries, such as the NVidia driver installer, in a similar manner; these are frequently made with deference to the standards, with a fixed reference to /lib64/ld-linux-x86-64.so.2. 4) It increases compatability with 32-bit Slackware packages - in many cases, a 32-bit Slackware package can be installed with no modifications on Slamd64, and it will work. Additionally, there is a "cleanliness" argument, which is subjective. My reasons for believing this is the cleanest practical method are: - No chroot, LD_PRELOAD, or similar hacks are needed to run 32-bit binaries; they `just work' - Due to 2 and 3 above, there must be at least one 32-bit binary in /lib, and at least one 64-bit binary in /lib64. Keeping 32-bit and 64-bit libraries entirely separate, as opposed to having a mix in each directory, seems much cleaner to me. Symlinks are sometimes used to make it so that the actual binaries are separate, however, this seems more like telling yourself that there's not a problem, as opposed to actually addressing the problem.