.comment: Putting KDE in Its Place - page 2
Why File Locations Matter
Supporters of placement of KDE and similar
/usr say that this is mandated by a document called
the FHS, for Filesystem Hierarchy Standard. This noble and necessary piece of
work seeks to codify the placement of things within the Linux file system.
/opt it says, in part:
/opt is reserved for the installation of add-on application software packages.
A package to be installed in /opt shall locate
its static files in a separate /opt/
Programs to be invoked by users shall be
located in the directory /opt/
. . . Distributions may install software in /opt, but should not modify or delete software installed by the local system administrator without the assent of the local system administrator.
/usr, it says, in part:
No large software packages should use a direct subdirectory under the /usr hierarchy. An exception is made for the X Window System because of considerable precedent and widely-accepted practice. This section of the standard specifies the location for most such packages.
Those who argue for placement of KDE in
/usr invariably latch onto the phrase "add-on" and
refuse to let go. This rapidly becomes laughable: I've seen arguments that
placement depends on whether one compiles the software himself or herself,
whether one got the software from the Linux distributor or from the program's
author, and even whether it came on the first or second CD of the distribution.
(Of course, publishers of RPM-based distributions put the packages where they
damn well please, irrespective of the piece of circular plastic whence it
But there is a more obvious
and--heavens!--sensible distinction to be made: the FHS tells us that
/opt have to stay together, while those in
/usr are splattered all over the place. This means that KDE placed
/opt must be in
/opt/kde (or, say,
/opt/kde2), while if it's placed in
/usr it must be
Now. Let's suppose that the Reddrake/Man Hat
"standard" were to put KDE into
/opt. And let's further
suppose that Mandrake decided, as they have, to overwrite the existing
KDE-1.1.2 with the pre-release KDE2. Let's further suppose a user who is not
eager to blow away a perfectly functional system, perhaps augmented by
applications not yet ported to KDE2, but who is eager to take a look at KDE2
and who does not care to compile it. What would this user do? Easy: Look in
/opt to see what the KDE directory is called. In console mode,
rename that directory and make a symbolic link of the original directory name,
now pointing to the renamed directory. When time came to install the new KDE2
RPMs, erase the symlink. KDE2 would then be installed into a directory of the
name that the KDE-1.1.2 directory once had. Again the user would rename the
directory. Then, by creating a new symbolic link, the user could go to KDE2. To
go back to KDE-1.1.2, all that would be needed would be is a new symbolic link
that pointed to that directory instead. (The same would need to be done for QT
and for the user's home
.kde directory, in that KDE2 configuration
files are incompatible with those from KDE-1.x and from earlier KDE2.) There is
no way to do this if KDE is in
/usr, so Mandrake has decided that
a test drive of KDE2 is a one-way street.
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.