.comment: Can Linux Grow Up? - page 2

A Muddled Mess

I would bet that most users' home directories are better organized and more sensible than is the confused disaster living under /usr. This needn't be the case, but it is the case and will remain so until it is fixed.

Let's take a look. Well, here's /X11R6. This is the only package that under the FHS--the Filesystem Hierarchy Standard--is allowed to be in its own directory under /usr. But what's this? Why, it's /usr/LessTif!

And let's look in /usr/X11R6. Its /bin directory contains binaries essential to the functioning of the X Window System. It also contains gimp, grok, gv, nedit, xearth, xeyes, xman, xedit, xv, and a multitude of other things, fine applications all, that have nothing to do with making X work and that belong elsewhere. Its /lib directory contains a similar amount of foolishness, including duplicates or other versions of libraries that are found in /usr/lib--and one needn't do much to make them conflict, about which more in due course. Where is X's documentation? Would you guess /usr/X11r6/doc? You would if you hadn't looked. And you'd be wrong. It's not in the second, third, or fourth place you'd guess, either. It's in /usr/X11R6/lib/X11/doc. Why of course! (For a snappy test of your ability to withstand urges to rend your garments and run down the street screaming, explore the XFree86 source tree sometime, looking for, say, the tdfx.o module. Without directions, you will need a backpack full of food and candles, for the descent is deep, dark, and lengthy, and your safe and timely return is by no means assured.)

But don't think I'm picking on XFree86. Pop in to /usr/lib and be amused or frightened, depending on whether you rely on its contents to do useful work. It is in a lot of ways a house of cards. In mine, to which I've done very little modification, there are 177 symbolic links. One of these is my responsibility: in order to switch between KDE-1.1.2 and KDE2 at will, I have directories /usr/lib/qt-1.44 and /usr/lib/qt-2-whatever-it-is-today. And, I confess, I have made a symlink that points to the one appropriate to the KDE version I hope to be running. Often in /usr/lib, though, the links are to other symlinks, which are to other symlinks, and somewhere (before you find tdfx.o--keep looking) there will be an actual library. Change it and the whole chain collapses. More than that, it would not be impossible to produce new versions that are backward compatible, in which case they should carry the same name and programmers should write to them directly, and not to the cloud of symlinks surrounding them like publicists around a rock star. Backward-compatible yet improved versions? Dates have been very effective for many years in determining the relative age of two similar things.

Headers are in as sorry a condition as libraries are. In /usr/include we find directories symlinked all over the place, to X11, to LessTif, to, unbelievably, Linux itself--specifically, to /usr/src/linux, which is often itself a symlink to /usr/src/linux-2.x.xx.

Why is this a Bad Thing? Because it is customary to build new kernels from source in /usr/src/linux, a symlink to the new code just downloaded. (To gain a sense of the opinion of this held by the powers that be, if you download the kernel source for linux-2.2.16, say, and open the tarball in /usr/src, it will go into /usr/src/linux. If you have a symlink of that name, the new code will be dumped atop the old source, and it will not be a good day.) If you put new code into the space previously occupied by something else, and that something else was linked way up among the headers, things are not working as they ought to work, and sooner or later unexpected behavior and instability will result. It falls upon the appropriate installation routine to put not a symlink but the actual headers themselves where they ought to go. This is not a difficult notion. No doubt back when the symlink idea was dreamt up for cases like this, storage was at a premium. It isn't anymore, and hasn't been for years.

I could go on and on, page after page, and not run out of examples. The miracle is that the thing works at all, which, to its credit, it does, and well. For now.