If I install an application in Linux for example Debian/Gnu Linux, the files of the applications are copied to many different directories in the file system.
Some scripts goes into /usr/share .. /usr/local some other files into /var .. /log .. etc/ and so on.
For me this is o.k because I learned something about the file system and most of the directories are there to hold files for a specific purpose.
This fits very nice in the Unix philosophy “do one thing and do it well”
But my question is what are the advantages of such a directory structure? Or is it simply the heritage of the old unix days.
(e.g in comparison with the one windows use, where all files for an application are in one specific “folder”)
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
No matter which organization is chosen, it will make some things easier and some things more difficult.
Organizing files by types, the Unix way (into bin, man, lib/python, …), makes it easier to use files. If you want to run a command, you know where to find it, no matter which package provides it. If you want to search through documentation, it’s all in one place. If some program provides a Vim syntax highlighting module, a zsh completion function, or Python bindings, the relevant file will be in a place where vim/zsh/python can find it.
Unix also organizes files by usage patterns. Configuration files go in /etc, files that don’t change in normal operation go in /usr, and files that change automatically go in /var. User data goes under /home. This is very useful for configuration management (manage what’s in /etc plus the list of installed packages). It’s also useful to define backup strategies: what’s in /etc and /home is critically important, whereas what’s in /usr can easily be downloaded again.
The main cost of the Unix way is that installing a piece of software is spread across many directories. However, modern unix systems have package managers anyway; managing files in many directories is by far not the most complex thing they do (tracking dependencies is very useful and harder).
Contrast that with Windows. Windows started out with no package management, and each application created its own directory somewhere. All files would normally be inside that directory: programs, static data, user data, … Except sometimes for libraries which programs would drop into a common system directory with no regard for conflicts (“DLL hell”). Over time, Windows became multi-user, requiring the separation of user directories from system directories. Windows also created a central place for configuration files (Unix’s /etc) and some system data (Unix’s /var), the registry. This is more of a historical artifact largely due to the lack of package management and the early history as a single-user system. The Windows approach has a lot of limitations: it doesn’t let software packages interact easily. For example, most installed software doesn’t end up on the default command search path, so it interacts badly with any form of scripting. Installers typically provide a menu icon as a special case — dropped into a separate system directory (à la Unix!).
A limitation of the Unix approach is that it doesn’t easily permit the coexistence of multiple versions of a package, which is especially problematic while the package is being upgraded. A way to get the best of both worlds would be to unpack each package in its own directory (an /opt structure), and create forests of symbolic links from package directories to a /usr structure. This is what software like stow does.
In summary, the Unix approach makes it easier to use files, to manage files, and to allow packages to interact; it requires package management software, but that’s desirable anyway. The Windows approach makes it easier to manage packages manually, but has to veer towards the Unix model to get useful functionality.
Method 2
What seems to me the easiest-to-think-of advantage is that similar files live in the same directory tree. Configuration files live in /etc, log files and/or run-time trace files live in /var/log, executables live in /usr/bin, run-time information like PID files lives in /var/run. You want to know what’s in the NTP configuration file? Change directory to /etc and do ls ntp*. You want to have some program watch executable files so that some traditional file system virus doesn’t infect them? Everything in /usr/bin and /usr/local/bin needs watching.
The second advantage I can think of is that the Unix style of organization promotes a separation of data and executable. Executables live in a directory that’s well away from where templates live (/usr/share, probably), and well away from where data lives. That separation might be a reason why Unix/Linux/*BSD have more resistance to file system viruses than Windows does, or the old Pre-OSX Mac had.
Method 3
A primary benefit not mentioned above, and one of the historical reasons for the structure, is physical separation on multiple volumes/disks available at different stages in the boot process.
Another benefit is that the various directories can be mounted on volumes/filesystems that are optimized for the directory’s data. For example, tmpfs for /run; and /sbin on read-only media/ROM.
Also, the volumes can be local or remote, personal or shared.
Finally, see Application Directory for an alternative approach (mentioned by @fluffy) used in UNIX (OS X .app), Linux (ROX Desktop) and Windows (PortableApps.com).
Method 4
There aren’t really any advantages to this layout, aside from it being easy to guess where shared and configuration files are for an application. UNIX has a long legacy of this sort of layout, and to break it would be pretty difficult. However, some UNIX distributions have changed their model – they only provide the old locations for legacy purposes, and other apps are bundled into its own little directory/package. Mac OS X is the most prominent example of this, and there are a few obscure Linux distributions which do the same thing (and Android does something similar, only takes it a bit further and installs and launches every application under its own user ID as well).
The main thing that a filesystem convention provides is just that – a convention, so that people know where to look for files (be it manually or in code). There is no real technical reason for it to be one way over another.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0