Mailinglist Archive: opensuse (3378 mails)

< Previous Next >
Re: [SLE] chaotic file structure ...
  • From: Anders Johansson <andjoh@xxxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 19 Apr 2002 08:00:18 +0200
  • Message-id: <200204190800.18778.andjoh@xxxxxxxxxxxxxxxxxxxxx>
On Friday 19 April 2002 07:18, gahn wrote:
> Hi:
> My suse linux came with the second hand machine. One
> thing I noticed is that the chaotic file structure:

Chaotic compared to what?

> host :# find / -name lib -print
> /lib

System libraries essential to get the system booting.

> /opt/kde/lib
> /opt/kde2/lib

These have been debated. SuSE believes that kde is an "optional extra" and the
Filesystem Hierarchy Standard (FHS) dictates that such software store its
executables and libraries in their own directory under /opt. This is as
opposed to windows where everything under the sun goes into C:\WINDOWS. See
info on the net about the FHS on

Other distributions, notably RedHat and Mandrake, hold that kde and gnome are
essential parts of the system, and store the files in the /usr directory.

Both sides have valid points and only time, and some fiery debates in the LSB
community, will tell who's right.

> /opt/kde2/share/apps/ksgmltools2/docbook/xsl/lib
> /opt/gnome/lib
> /opt/gnome/share/sgml/docbock/xsl-stylesheets-1.29/lib
> /opt/dosemu/freedos/help/lib
> /opt/netscape/plugins/java2/lib
> /var/lib

The /var hierarchy contains files that can vary in size and content. The idea
is that trees like /usr and /etc can, after the initial config, be mounted
read-only, say from a CD-rom for instance, to limit the damage that crackers
can cause. /var/lib, according to the fhs contains data about a system's or
program's state.

> /var/X11R6/lib

/var/X11R6/lib shouldn't exist according to the FHS. It is I believe a SuSE
idea to handle X 3.x, where you had several different X-servers, one for each
graphics card. It shouldn't be necessary anymore with X 4.

> /usr/lib

/usr/lib and its subdirectories hold essential internal libraries the system
needs to run. Some packages create subdirectories for the things they and no
other package use, hence the multitude below.

> /usr/lib/qt/lib
> /usr/lib/perl5/site_perl/5.6.1/i586-linux/Tk/demos/widtrib/lib
> /usr/lib/apache/lib
> /usr/lib/heimdal/lib
> /usr/lib/qt-2.3.2/lib
> /usr/lib/jdk1.1.8/lib
> /usr/lib/jdk1.3.1/jre/lib
> /usr/lib/jdk1.3.1/lib
> /usr/lib/JSDK2.0/lib
> /usr/src/linux-2.4.16.SuSE/lib

/usr/src are source files. The naming of source files varies from developer to
developer. It has no effect at all on the running system.

> /usr/i686-pc-linux-gnu/lib

No idea about this. Presumably it's some hot, optimized version of glibc that
the previous owner compiled.

> /usr/X11R6/lib

libraries relating to the X window system and packages running under X.

> /usr/games/lib

Libraries belonging to games (and educational packages)

> /usr/local/lib

/usr/local is a tree where you put software you install yourself, as opposed
to software you get from the distributor. /usr/local is guaranteed to not be
overwritten by system upgrades. /usr/local/lib are libraries belonging to
such software.

> /usr/share/doc/susehilf/lib
> /usr/share/ssl/lib
> /usr/share/sgml/docbook/docbook-dsssl-stylesheets-1.72/doc/lib
> /usr/share/sgml/docbook/docbook-dsssl-stylesheets-1.72/lib
> /usr/share/sgml/docbook/docbook-xsl-stylesheets-1.42/doc/lib
> /usr/share/sgml/docbook/docbook-xsl-stylesheets-1.42/lib
> /usr/share/sgml/docbook/docbook-xsl-stylesheets-1.42/docsrc/lib
> /usr/share/vtcl/lib
> /usr/share/ghostscript/6.51/lib

/usr/share is for read-only data that isn't architecture dependant.

> /usr/i486-suse-linux/lib
> /usr/i486-linux/lib

These are for compatibility with older systems. They contain libc5 libraries.

> This is just one example. Is this specific for suse
> linux or linux in general? Or it was the work of
> previous owner of the machine?

What you describe as chaotic I would describe as structured and sorted. It's
just a question of knowing what everything means. read up on the FHS I linked
to above. I think you'll come away with a new appreciation of Unix, and
understand why this is better than simply lumping everything in C:\WINNT


< Previous Next >
Follow Ups