Page 1 of 4 123 ... LastLast
Results 1 to 10 of 34

Thread: The Linux Folder Structure

  1. #1
    Join Date
    Feb 2007
    Beans
    164
    Distro
    Ubuntu 6.10 Edgy

    The Linux Folder Structure

    I have a long unanswered question that has been refreshed in my mind by a different question in the forum.

    What is the reason behind the continued use of the old unix folder structure?

    When someone installs a package its contents are scattered throughout the folder structure. The executables are installed in /bin, /usr/bin, /usr/local/bin, /usr/share, ~/<program name>, etc. The modules are installed in /usr/lib, /lib/, /usr/local/lib. The man files, the help files, etc, are the same story. God forbid you install a program that doesnt make a menu entry. Most of the time you can execute the programs name in a terminal (not very user friendly) but if it installs in /usr/local or ~/ then you have to search for it. Also, a program like EasyCam installs the executable by the name of lauchcam2 (no thats not a typo). The only way for me to find this program after installation was through exhaustive google searching.

    Furthermore, say I decide to create a program called lauchcam2 (not knowing one exists). We are going to overwrite eachother. It just doesn't make any sense. Why not do like windows and install in a program files directory? This makes everything not only easier to find, but it makes your system (and what's installed on it) easier to navigate.

    Hopefully someone can explain this to me because I just don't see the logic behind the way linux does this.
    I pronounce You-Buntu however I want.

  2. #2
    Join Date
    Apr 2007
    Beans
    Hidden!

    Re: The Linux Folder Structure

    I think it has to do with keeping a set area where files install to, that way new files can look for necessary code modules in /bin, usr/bin, etc. I can kinda understand it, but I find it annoying sometimes, too. You install something, and half the time there's no menu entry. So, you're digging in the CLI & folders for it. And you start typing the CLI name you think works for it, and it turns out to be totally different. (9 times out of 10, I end up having to look at the Synaptic file specs for the package I d/l'ed to figure out what the executable is for these types of things.)

    That's been one of my (very few) annoyances with Linux. In Windows, I liked how I could install a program where ever I wanted, but I didn't like how it tossed all kinds of crap in the registry. Also, sometimes Windows programs end up tossing files in all kinds of other folders, like the System folder and what-not. There were times I would spring-clean my computer, and find folders, files, and registry entries for crap I had uninstalled 6 months ago.

    At least with Linux, there's a semi-set way programs are installed, so programmers / developers can anticipate where certain programs will be that their program may require. In Windows, the System & Program Files folders attempted to do this, but you'd always see programs install with duplicate .dll files and what-not, because the programmer was paranoid that your MS Windows computer didn't have them installed (or path'ed correctly).
    Folding@Home & TeamUbuntu ... the lazy person's charity! Your comp does the work while you get the warm, fuzzy, hello-kitty feeling of helping humanity. That, and we get to trounce other teams in the folding competition! Join today!

  3. #3
    Join Date
    Apr 2007
    Beans
    Hidden!
    Distro
    Hardy Heron (Ubuntu Development)

    Re: The Linux Folder Structure

    Well, one point against having a self-contained package structure: Each and every package will have to have its own copy of the libraries it uses, implying huge waste of disk space. Unix has always had library versioning right in the library name (the developer needs to make use of this properly .

    Now, to your point regarding the difficulty of finding launchcam2, the Ubuntu/Debian packaging scheme maintains the metadata for all installed packages - so an easy way to find out what was installed in a package is in Synaptic Package Manager - just select any package, and right-click, then select Properties menu. One of the tabs in the resulting dialog is Installed Files which shows which files went where.

    Question: One question I have is that is there a way to query this metadata in the reverse ? i.e. given a full path like /usr/bin/smbd, can I find which package installed this file ? That would be very helpful.

    Now regarding your comment about a second launchcam2, this has already been considered in Ubuntu/Debian (please see update-alternatives for a description of how two commands with identical names are handled). Of course, I think this needs some effort on the part of the package creator (does it ? I am not sure of this).

    As an actual example, the git command refers to a source code management tool as well as the GNU Interactive Tools File Manager. When both are installed, the user is warned about the alternatives and a update-alternatives command is shown as part of the warning, so that the user can select the appropriate command for use.

    My $0.02.
    Last edited by PaulFr; July 3rd, 2007 at 11:11 AM. Reason: Additional info

  4. #4
    Join Date
    Feb 2007
    Beans
    164
    Distro
    Ubuntu 6.10 Edgy

    Re: The Linux Folder Structure

    Well, one point against having a self-contained package structure: Each and every package will have to have its own copy of the libraries it uses, implying huge waste of disk space. Unix has always had library versioning right in the library name (the developer needs to make use of this properly .
    Well, just like in windows, modules (dll's) of the standard, or latter added, api need to be in a centralized location... but program files really don't need to be.
    Now, to your point regarding the difficulty of finding launchcam2, the Ubuntu/Debian packaging scheme maintains the metadata for all installed packages - so an easy way to find out what was installed in a package is in Synaptic Package Manager - just select any package, and right-click, then select Properties menu.
    Very, very nice to know. Im instantly glad I asked after learning this very valuable peice of information. One suggestion might be to make this information a little easier to find though. Perhaps putting a "installed files" button on the "install completed" window after a package installs. Maybe i'll make an [IDEA] post re: that.
    ...update-alternatives...
    Good to know as well. I figured something like this had to exist.
    I pronounce You-Buntu however I want.

  5. #5
    Join Date
    Jun 2006
    Location
    vietnam
    Beans
    211

    Re: The Linux Folder Structure

    you might be interested in gobo linux; it has a different filesystem hierarchy. link: gobo linux at a glance.

  6. #6
    Join Date
    Dec 2006
    Beans
    256

    Re: The Linux Folder Structure

    Quote Originally Posted by Praill View Post
    Well, just like in windows, modules (dll's) of the standard, or latter added, api need to be in a centralized location... but program files really don't need to be.
    That's not really true for Linux. Many programs rely on the existence of other programs and need to know where to find them. A GUI CD-burner such GnomeBaker or K3B might work by specifying command-line arguments to 'cdrecord' or other cdrtools (this is how they used to work, I am not sure if they still rely on CLI programs). Many media convertors rely on the FFMPEG, MENCODER, and MPLAYER commands. Under the Unix philosophy of many small programs working together, the distinction between a program and library of shared functions becomes quite gray.

  7. #7
    Join Date
    Feb 2007
    Beans
    164
    Distro
    Ubuntu 6.10 Edgy

    Re: The Linux Folder Structure

    Quote Originally Posted by ynnhoj View Post
    you might be interested in gobo linux; it has a different filesystem hierarchy. link: gobo linux at a glance.
    This looks great. They even maintain the old-school unix directory structure as sym links so that any program can find another program it needs. This is exactly the type of system ubuntu should approach.. for its user friendlyness alone.
    I pronounce You-Buntu however I want.

  8. #8
    Join Date
    Oct 2004
    Location
    Kingston, On
    Beans
    Hidden!

    Re: The Linux Folder Structure

    Quote Originally Posted by Praill View Post
    I have a long unanswered question that has been refreshed in my mind by a different question in the forum.

    What is the reason behind the continued use of the old unix folder structure?

    When someone installs a package its contents are scattered throughout the folder structure. The executables are installed in /bin, /usr/bin, /usr/local/bin, /usr/share, ~/<program name>, etc. The modules are installed in /usr/lib, /lib/, /usr/local/lib. The man files, the help files, etc, are the same story. God forbid you install a program that doesnt make a menu entry. Most of the time you can execute the programs name in a terminal (not very user friendly) but if it installs in /usr/local or ~/ then you have to search for it. Also, a program like EasyCam installs the executable by the name of lauchcam2 (no thats not a typo). The only way for me to find this program after installation was through exhaustive google searching.

    Furthermore, say I decide to create a program called lauchcam2 (not knowing one exists). We are going to overwrite eachother. It just doesn't make any sense. Why not do like windows and install in a program files directory? This makes everything not only easier to find, but it makes your system (and what's installed on it) easier to navigate.

    Hopefully someone can explain this to me because I just don't see the logic behind the way linux does this.
    Obviously, it's not meant to be that way.

    There are a few sets of guidelines. In the linux filesystem hiearchy, certain things go in certain places. In debian and debian derivatives, the package manager is in charge of the filesystem, with the exception of your home folder. There are strict packaging rules that determine where the files go. No official deb package will ever put anything in /usr/local. If you have stuff there, they were put there by a third-party and I would frankly stay away from such third-party binaries if I could.

    Any supported Ubuntu desktop package has a menu entry. Since Debian uses a different menu than Ubuntu, deb packages that are not officially supported by Ubuntu may or may not have the Ubuntu-type menu.

    Also, it is presumed that since the package manager is charged with dealing with the rest of your filesystem, if you want to create your own application, you either keep it in your home drive, or you know what you are doing so that you do not overwrite anything useful.
    I lost a "z". Anyone seen it around here?

  9. #9
    Join Date
    Jan 2006
    Location
    Laguna, Philippines
    Beans
    1,818

    Re: The Linux Folder Structure

    What is the reason behind the continued use of the old unix folder structure?
    Simple answer. Linux is meant to be like UNIX. And in order for it to keep that identity, it needs to comply with certain standards, one of which is the filesystem hierarchy. Now, if Linux stopped using that, even just "under the hood", it wouldn't really be Linux, would it?

    When someone installs a package its contents are scattered throughout the folder structure. The executables are installed in /bin, /usr/bin, /usr/local/bin, /usr/share, ~/<program name>, etc. The modules are installed in /usr/lib, /lib/, /usr/local/lib. The man files, the help files, etc, are the same story.
    UNIX/Linux groups files according to purpose, not according to package/program (like in Windows). This makes it easier to share resources, and also makes it a lot easier to put a certain directory in another partition, without disturbing the whole system. (In fact, Linux only sees one single filesystem. It doesn't know/care whether directories are mounted in other places).

    God forbid you install a program that doesnt make a menu entry. Most of the time you can execute the programs name in a terminal (not very user friendly) but if it installs in /usr/local or ~/ then you have to search for it. Also, a program like EasyCam installs the executable by the name of lauchcam2 (no thats not a typo). The only way for me to find this program after installation was through exhaustive google searching.
    This is what a filesystem standard is for. This is also what distributions are for. The standard locations for an executable will always be in a bin/ directory, and by default, it should be in /usr or /usr/local. At least you'd know where to look. (Some Windows programs don't actually install in the Program Files directory). Distributions also take most of the load off your shoulders, by building packages in a way that the correct files are put in the correct directory. Also, it's the responsibility of the programmer who created the software to install set it up to install in the correct places. If it doesn't you should file it as a bug.

    Also, not all apps have menu entries, most specially command line apps. If a GUI app that should have a menu entry doesn't have one, it's most probably a bug.

    Furthermore, say I decide to create a program called lauchcam2 (not knowing one exists). We are going to overwrite eachother. It just doesn't make any sense. Why not do like windows and install in a program files directory? This makes everything not only easier to find, but it makes your system (and what's installed on it) easier to navigate.
    It depends. Generally, you don't want to install your own programs in, say, the system directories like /usr. You'd install in /usr/local or in /opt. Not only do you lessen the risk of clashing with existing files, you also make it easier to maintain your own program in your own way.

    You have to consider where Linux is coming from and what Linux is to be able to understand why we do things this way. Linux takes its inspiration from UNIX. What this means is that there is a bit of a focus on:
    - multi-user: if I remember correctly, UNIX was the first truly multitasking, multi-user operating system. The directory structure makes it very easy to manage multiple users and resources
    - resource sharing: UNIX is big on this. This is one of the reasons why everything with the same purpose is placed in the same place.
    - flexibility: it is so easy to put different parts of the filesystem in different partitions/disks, without affecting the system. In fact, advanced users probably put /var, /etc and others in different partitions.
    - administration: let's face it. Until recently, Linux has been the realm of geeks, programmers and administrators. dumping all config files in a single directory makes it easier to manage them.

    So why does Linux still use the UNIX filesystem hierarchy? Because it still works.

    Of course, it's not perfect, specially on the end-user end of things (like "migrating" a certain app to another installation). I myself have wrestled with the difficulties brought about by splitting config files and app data. I don't know if Gobolinux presents a good, viable solution to that. Whatever the solution may be, I don't think changing away from the UNIX structure will be beneficial in the long run.

    EDIT: Oops! forgot to give some links:
    Some slightly technical reading:
    http://www.tldp.org/LDP/sag/html/fs-background.html
    http://www.tldp.org/LDP/Linux-Filesy.../foreward.html
    Last edited by Jucato; July 3rd, 2007 at 02:40 PM. Reason: Ooops! Forgot links...

  10. #10
    Join Date
    Apr 2006
    Beans
    1,979
    Distro
    Ubuntu 8.10 Intrepid Ibex

    Re: The Linux Folder Structure

    How about this for an idea?

    A minor alteration to the installation process (and it would even be possible to download a 'converter' so that your current system could benefit):
    When you install a package, the package contains all of the information about where to place the various files. There are certain standards which are usually adhered to, such as binaries in /usr/bin, documentation in /usr/share/doc, and so on. Now, what I propose is that we add a little function to dpkg so that some soft links are created in some other directory (/software for example), while the actual files are stored in the usual place. For example, lets say we have a package which has the following files and their target directories:
    Code:
    convertor ---> /usr/bin/convertor
    conv_lib.so ---> /usr/lib/conv_lib.so
    README ---> /usr/share/doc/convertor/README
    COPYING ---> /usr/share/doc/convertor/COPYING
    convertor-logo.png ---> /usr/share/pixmaps/convertor-logo.png
    Why can't we keep this structure, but ALSO create a software directory which only contains LINKS to files, but uses the package's name? For example, the structure of the software folder would look like this:

    Code:
    /software
    ||||||/convertor (the root of the package's directory would contain a soft-link to the binary)
    ||||||||||/doc (this directory would contain a soft-link to the various documentation files)
    ||||||||||/lib (this directory would contain a soft-link to the various libraries required by the software)
    ||||||||||/data (this directory contains miscellaneous stuff like images, sound files, videos etc)
    Now granted, given the nature of free software, programs tend to share stuff, which is why the current system is so beneficial. Theoretically, this new system is a 'waste of space', even though we wouldn't actually have multiple copies of the files, we'd just have multiple links to the files. Even though we're wasting space, we're wasting a very, very minimal amount. This method also means that compatability isn't an issue. Developers don't need to worry about the new software folder, because everything is sorted out by dpkg.

    At the end of the day, the current system is fine for me, but I think that we should have the CHOICE of a different system. As I've just shown, there's no reason why we need to get rid of the current system, or even why this should be a difficult task to accomplish (because it really isnt, it wouldn't take much work at all). Obviously, the current system is not ideal for some people, and if they've only used Windows in the past, then it's pretty obvious that they may be thrown off by the directory structure which Linux uses. I see no reason why a secondary 'fake' directory structure couldn't be included as an option when first using your new Ubuntu machine. For the hard-core efficiancy junkies, they can just leave the feature turned off, but for those who like a more centralised structure, they can enable it and then be satisfied.

    If something like this were to be adopted, however, we would still need to keep the new directory structure outside of the home folders, otherwise we'd have as many duplicates as there are users, which is just pointless. Anyone wishing to edit stuff inside the new software directories would still need to use root priveleges.

Page 1 of 4 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •