xj9 災害の̴女王dreamspace 9 9 9 9 9 9 9 9 9

Out with the old, in with the new from project-beyond

Anyone that has used Linux knows about the rather counter-intuitive Filesystem Hierarchy Standard (FHS), sure it’s useful for programs, but that is because they’re built for that system. For users and developers, I imagine, working with this system is a big hassle. The FHS is outlined below (courtesy of Wikipedia)

Directory Description
/ Primary hierarchy root and root directory of the entire file system hierarchy.
/bin/ Essential command binaries that need to be available in single user mode; for all users (e.g., cat, ls, cp).
/boot/ Boot loader files (e.g., kernels, initrd). Often a separate partition.
/dev/ Essential devices (e.g., /dev/null).
/etc/ Host-specific system-wide configuration files (the name comes from et cetera).
/etc/opt/ Configuration files for /opt/.
/etc/X11/ Configuration files for the X Window System, version 11.
/etc/sgml/ Configuration files for SGML.
/etc/xml/ Configuration files for XML.
/home/ Users’ home directories - containing saved files, personal settings etc. Often a separate partition.
/lib/ Libraries essential for the binaries in /bin/and /sbin/.
/media/ Mount points for removable media such as CD-ROMs (appeared in FHS-2.3).
/mnt/ Temporarily mounted filesystems.
/opt/ Optional application software packages.
/proc/ Virtual filesystem documenting kernel and process status as text files (e.g., uptime, network).
/root/ Home directory for the root user.
/sbin/ Essential system binaries (e.g., init, route, ifup).
/srv/ Site-specific data which is served by the system.
/tmp/ Temporary files (see also /var/tmp). Often not preserved between system reboots.
/usr/ Secondary hierarchy for user data; contains the majority of (multi-)user utilities and applications.
/usr/bin/ Non-essential command binaries (not needed in single user mode); for all users.
/usr/include/ Standard include files.
/usr/lib/ Libraries for the binaries in /usr/bin/and /usr/sbin/.
/usr/sbin/ Non-essential system binaries (e.g. daemons for various network-services).
/usr/share/ Architecture-independent (shared) data.
/usr/src/ Source code (e.g. the kernel source code with its header files).
/usr/X11R6/ X Window System, Version 11, Release 6.
/usr/local/ Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories, eg. bin/, lib/, share/.
/var/ Variable files, such as logs, spool files, and temporary e-mail files.
/var/lib/ State information. Persistent data modified by programs as they run (e.g. databases, packaging system metadata etc.).
/var/lock/ Lock files. Files keeping track of resources currently in use.
/var/log/ Log files. Various logs.
/var/mail/ Users’ mailboxes.
/var/run/ Information about the running system since last boot (e.g. currently logged-in users and running daemons).
/var/spool/ Spool for tasks waiting to be processed (e.g. print queues and unread mail).
/var/spool/mail/ Deprecated location for users’ mailboxes.
/var/tmp/ Temporary files to be preserved between reboots.

A lot of these directories seem redundant. If you notice many of them are depreciated. Why have more than six locations to store programs? It would be more intuitive to simply store all programs in one folder, lets call it Applications or Programs. Then we’d have another folder Called Home or Users, that would store all of the user data in it. The way the home folder works right now. I sounds good to me to keep all the settings in the users home folder, that way when you move to another system you can keep all the settings you worked so hard to get just right. The root user would have its data stored here too, root is a user, a superuser but still a user. Then we’d have another folder called Library that holds all of the libraries for all of the programs on the system. Last but not least we’d have a folder called System that holds everything else. All the system files would be directly in the System folder including mount points and removable devices, the system applications would be in a folder called Applications, or something of that sort. This is what we have:


Sure does look a lot cleaner than the standard FHS. The only problem is that there aren’t any applications written that would work with our tidy new hirearchy. Thats where symbolic links and clever programming come into play. You’d have to make the non-compatible applications think that they where running under FHS. This isn’t exactly good practice, but holding on to an ancient standard isn’t a good idea either. If you’d like to read about Gobolinux, a distro that has a totally revamped file hirearchy, check out this article at OSnews.