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")

4 Answers 4


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.

  • 1
    Awesome. In my opinion, though, it only used to be easier to manage packages individually. The advent of the windows registry changed all of that and then some. Not only is it gigantic and labyrinthine - it is also intentionally so - with some values in byte code while others aren't and no true rhyme or reason to the structure. I guess that's the way it has to be if you want to develop a managed os and protect trade secrets and proprietary methods: confusing.
    – mikeserv
    Jun 10, 2014 at 2:13

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.

  • That are good points. Why is the separation of executable and data-, template-, config-files a reason for more protection against viruses? Jan 17, 2013 at 19:33
  • 3
    A lot (but not all) of the viruses and worms in the world propagate due to the ability to change data to executable: stack overflows and SQL injection and code injection all work this way. "Word" macro viruses propagated at least partly because "Word" macros are included in .doc files. Separation of data from executable by file is one level of protection, putting data in one directory, executable in a second, templates in a 3rd, config in a 4th puts even more barriers to confusing data and executable into place.
    – user732
    Jan 17, 2013 at 20:31
  • 2
    The data-and-executable separation argument is complete nonsense. File system organization is for a human's benefit; it's not like there's some physical separation between the bits that prevents them from giving cooties to each other or anything. UNIX's security is historically better because of a stronger, more-tightly-enforced permissions model in general.
    – fluffy
    Jan 17, 2013 at 20:54
  • @fluffy Separate filesystems offer slightly stronger separation, but that point is partially moot as it is not possible to separate /bin, /etc, from /.
    – jw013
    Jan 17, 2013 at 21:47
  • @fluffy - agreed, no "physical" separation exists, or is possible. But it's a separation-by-name. Malware has to look in some other directory (rather than "." or dirname $0 or something) to find templates or other data. It's not absolute security, any more than closing a glass window is absolute security. Security is an economic good, with marginal value for each additional unit of work. Every little bit helps.
    – user732
    Jan 17, 2013 at 22:01

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).


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .