.comment: Putting KDE in Its Place
Why File Locations Matter
Here we are, a few weeks away from the release of a new version of KDE, and once again there's a virtual Trevi Fountain of urination tournaments over where in the Linux file system KDE belongs.
Unlike a lot of the just-for-the-sake-of-arguing disputes that take place in the Linux world, this one actually matters to a lot of people for real, demonstrable reasons. It is also one place where a single distribution has dictated a standard--out of sheer, brute force, not because that standard is the best answer.
For the first year or so of its existence, KDE
was typically placed in
/opt/kde (though some users put it in
/usr/local/kde). This made sense for a number of reasons, chief
among them that if one wanted to build an incremental upgrade from source,
backing up the old, working version was a simple thing, as was restoring it if
the compilation didn't go as planned, but waited until, say, kdebase before
blowing up. Everyone was happy with the arrangement.
In due course, Red Hat included KDE in its Linux
distribution, alongside Gnome, which was developed largely under the aegis of
Red Hat. The inclusion of KDE is to Red Hat's credit; the placement of it is
not. Red Hat put KDE in
/usr, where its binaries are intermingled
with all the others in
/usr/bin, its libraries with the
/usr/lib contributions of other system programs, and so on. Now,
if you got halfway through the compile of an upgrade aimed at
/usr, you were victim of a threaded conical device. In effect,
this meant that you were limited to RPM packages produced by, or at least for,
Red Hat distributions. There were many programs developed for KDE-1.x that were
not included in the KDE distribution and that were often placed in
/opt/kde/bin; with this system they would go into
/usr/bin when a user compiled them or (rarely) found an RPM. If a
new KDE version's libraries were different from those against which the program
had been compiled, one could end up with a
/usr spattered with
Mandrake and other Red Hat derivative distributions followed Red Hat's example. This led to a considerable forking, especially among binary RPMs.
A week or so ago, the new KDE2 beta RPMs for
Mandrake Linux no longer would run alongside a KDE-1.x installation in
/usr. Now they overwrite KDE-1.x. Whether the KDE developers, who
usually like to decide themselves when a new version is ready, are happy with
this is unknown. But as of now, one very popular Linux distribution has RPMs
that make the pre-release KDE2 the only KDE on the system, without any very
easy way to backup the original. (Yeah, there are the original distribution
RPMs--I've heard it all before; but there's not much way using Mandrake RPMs to
keep both a working production installation of KDE-1.1.2 and a testdrive
version of KDE2 on the same machine. Besides, there are individual programs
within KDE, notably KMail, that have been upgraded outside of the
distributional RPM system.)
Understand: I think KDE2 is just great. I use it exclusively, as I have since last November. But I'm also willing to accept little shortcomings in developmental software that many users would find objectionable and that I suspect the KDE developers would not wish to have speak for the quality of their work. Example: I compiled new source code a couple of days ago from the KDE CVS tree (a system, in case you don't know, whereby you can get code that is just hours, in some cases minutes, old). In the two weeks since last I built KDE there had been much progress, but as is inevitable during development new problems had appeared. I discovered this when I tried to save an email address to the KMail addressbook and instead of saving the address erased the entire addressbook. I expect this kind of thing. Many users, especially those who only install that which they can get on binary RPM, might not.
And that is why putting KDE into
/usr is just plain inconsiderate and unwise. Let me explain
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.