This document is a quick overview of how my personal practices differ from the commonly followed practices. Some day, when my ideals are more thought out and refined, I might actually write a more complete document on how to set up such a system, but for now, a little reasoning of opinion will have to do. The truly curious can always feel free to E-mail me for more information.
Please be aware that I make no claim that my ways are "right" or "better" for everyone - they're just the way I prefer to do things when going through the trouble of creating my own system. My favorite part about linux is the flexibility for the end user to set things up in any way they prefer.
Many might wonder why I bother coming up with such crazy ideas. One reason is the challenge of implementing such ideas and testing how well they work in real-life scenarios. Another reason is to better understand the logic and reasoning behind existing standards, and to challenge it where I don't fully agree. Mostly it is a collection of what has turned out to be the most useful, in a practical sense, over years of experience. Hopefully this page will grant a bit of insight into why I have the preferences I do.
Also please note that while I have in the past adhered strongly to the following ideals by implementing them on my own linux-from-scratch systems, I don't actually use them any more. The reason for this is simply convenience: Using Gentoo Linux's Portage system, I can easily keep my packages updated to the latest well-tested versions, with great ease, and without the horrors of lousy package management systems (i.e. Red Hat's RPM and Debian's Apt). This means I have to set my own ideals aside. They've been proven to be feasible and workable in production environments, however to make them useful, they need to be made available in a form that's easy to adapt. Please see the end note at the bottom for more on this.
I like using package users/groups. Every package is installed as a user, so there's no chance of a trojaned Makefile destroying my system during the installation process, since it's not done as root. It also means basic UNIX commands can be used for package management functions - 'ls -l [file]' shows what package any given file came from. 'find / -group [packagename] | grep -v "/share/src" | xargs rm' deletes all files installed by a package. Adding ' && userdel -r [packagename] && groupdel [packagename]' removes the source files and the user & group from the system as well. Take out the ' | xargs rm' and I have a list of all files installed by a package. And so on and so forth: fairly complete package management using only standard UNIX commands. As you can guess, these are easily wrapped in simple shell scripts named friendly things like package_uninstall, package_list_files, package_remove, and so on, for convenience. 'package_install' creates a new user & group in the specified range, sets up their home directory based on /etc/skel-package, and su's to that user. Originally based on this document, with a number of changes over time.
Most importantly, I used a group for each package with the same name and ID as the user. This allowed me to 'chown 0 && chmod u+s' a file where necessary without forgetting what package it came from. I also skip the wrapper scripts in favor of repairing broken packages individually.
I hate /sbin. Why? Well ages ago in UNIX history there was just /bin, and /sbin was added to hold statically-compiled binaries, as opposed to the usual dynamically compiled binaries. Over time, the trend changed to using /sbin for superuser-accessible binaries, but I have yet to see any system which prohibits any normal user from typing '/sbin/blah', or any good reason to create this separation (things like /sbin/ifconfig are often very handy to plain users for determining the IP or MAC addresses). Security in what a binary is able to do is handled by the kernel, and this separation adds nothing but confusion. So, everything in /bin for me :).
I don't use /root. It is useful to have /root instead of /home/root in the case that /home is a separate partition, so that root can still have a home directory in the case that the /home disk is destroyed. But I personally see little value in this, and since I have 'DEFAULT_HOME yes' in /etc/login.defs, a login is permitted even if the home directory does not exist ('DEFAULT HOME no' is another measure that I view as silly and useless as the /sbin vs. /bin separation).
I really hate /usr a lot. Long ago when /usr came to exist, / represented the root filesystem containing just what was needed to boot the system (typically existing from a network boot), /usr was created for an NFS mount from a file server, and /usr/local was, in turn, for a disk local to the terminal. So it came to be that /usr/local was where the end user installed things by default, and so it is today. Almost nobody uses NFS application servers like that anymore, but the same logical separation exists to this day. There is some small value in it if /usr is a separate hard disk, since the system will still boot without it. However, as a practical matter, a system that boots but can provide no services (because of /usr missing) is no better than a completely dead system, and I just use a single partition anyways. I find things a lot cleaner when there's only one installation prefix (/), and one given path for anything (every binary is in /bin, every library is in /lib, etc.), so no /usr for me.
Moreover, a lot of people claim that the separation of / as system files and /usr as program files is logical, but then the question arises - what makes a "system file" such as 'ls' any different from a "program file" such as 'xterm'? One might argue that 'ls' is critical to basic system usage, but what if I prefer 'mc' or some other file browser that is not classified as a system file to do the same thing? What if I use a perl script version of 'ls'? Perl gets installed in /usr - what makes it any less critical than 'bash'? A single installation prefix means opinion doesn't influence the decision.
It might also interest you to know that on typical GNU Hurd systems, /usr is a symbolic link to / - an easier way to attain the same goal without fixing the various packages that demand /usr/something to be present.
I don't use /opt. It seems a copy of Windows' 'Program Files', and while it can offer a small amount of organizational sanity (i.e. I know anything in /opt/kde is part of kde), I deem the cost of increased path confusion too high. Any reasonable method of package management makes it straightforward enough to know what package any given file belongs to anyways. It's better than /usr/programname hierarchies though...
Of course, things like the Filesystem Hierarchy Standard disagree with me, but I in turn argue that the FHS is a bit silly because one of the strengths of UNIX is having the flexibility I mentioned above, including the ability to have files put wherever you want. By properly designing programs to not use hardcoded paths, one can easily making everything work regardless of differences (MacOS X, for instance, has it's own names for many of the basic directories such as /Applications and /System. Solaris uses /devices instead of /dev). The FHS encourages scripts to use hardcoded paths for everything, which I don't advocate.
Yes, there are others with crazy ideas too. I obviously did not come up with the package users idea, and many other filesystem hierarchy standards have been conceived and implemented over time. Daniel J. Bernstein (author of qmail, djbdns, and other quality software) demonstrates a number of shortcomings of the FHS on his site. He also has his own extensions to the filesystem hierarchy, including /service, /package and /command directories. David McQuigg wrote a proposal on a simpler more logical layout, essentially a compromise between the UNIX and Windows ways of organization. Jean Pierre Rupp wrote a more user-friendly version, based largely on David's ideals. Individual madmen aren't the only culprits of such blasphemous thoughts - nearly every commercial UNIX vendor does things their own way, at least to some extent. Anyone who has gotten comfortable with a linux distribution and sat down at a Sun Solaris machine knows what I mean. Apple has drastically changed the standard for UNIX filesystem hierarchies in it's MacOS X system, with directories like /System, /Users and /Trash. The infamous Filesystem Hierarchy Standard, which claims to be a reference rather than a tutorial, invents it's own directories as it pleases, for instance /media and /srv in the 2.3 release.
But I don't think any one standard should be viewed as the one right and true way of doing things. Rather I think packages should be built correctly as most are, so that they may be built to conform to any hierarchy, and that the administrator of any system should endeavor to fully understand the logic behind the filesystem hierarchies on their systems.
When I initially wrote this page in 2001, my biggest disgruntlement with UNIX/Linux filesystem hierarchies was with where various things were located on a single system. For instance, I couldn't run ifconfig to check my IP address as a user without typing /sbin/ifconfig. Why was it in /sbin if I could run it with useful results as a user? Or perhaps, I've just installed a new version of some program, but it's still showing the old version, because the new version is in /usr/local instead of /usr. Or, kmail doesn't start when I type it in, because it's in /usr/kde/2.1/bin and that's not in my path. These are all still big issues, but this is magnified when we consider that what comes "standard" fram distributers varies greatly between them. Daniel Bernstein wrote of his frustration with it on http://cr.yp.to/compatibility.html, and the number of cases of end user confusion, misconfigurations, and problems that can be found without much effort is simply staggering. Where to find a file on a system is a problem. Where find a file on 2 different systems with completely different filesystem arrangements is another. How to start and stop programs varies greatly as well, and is yet another problem.
These problems are not without solution, but the proper solution is difficult to design and time-consuming to implement. Some issues to consider: