DISCLAIMER: This site is a mirror of original one that was once available at http://iki.fi/~tuomov/b/
The *nix directory hierarchy is a mess. It's not wise to put all your eggs in one basket, and this is how the *nix directory hierarchy is organised. Almost all libraries go in /usr/bin/, their header files in /usr/include/ and so on. It's practically impossible to compile a program against a specific version of a library if the author(s) of that library haven't included the version as part of the name of the library – which is not desirable with minor changes, although it is with major API changes.
It is also not easy to manually remove a package from the hierarchy, as its files are spread all over the place. Yes, package managers do take care of that for packages in the distribution, and apt-get is a wonderful tool. And, yes, stow can be used to manage source packages in /usr/local/. That doesn't change the fact that the hierarchy is a mess with the files of every package interspresed among others'.
A much simpler directory hierarchy is possible. It is called application directories. Now, there are distros that try to do that. Unfortunately /They Have Been/Corrupted By The/Marketdroid Naming Convention/. What's wrong with simple /usr/pkg/ or /usr/app/? These supposed "idiot users" that need /Long Names With Spaces And Capital Letters/So That They Can Understand It/ probably use some lame file manager that hides all system directories anyway.
And besides, I want to take it much further. Even GoboLinux has symlinked equivalents of /usr/lib/ and /usr/include/ and so on under /Some/Very/HardToType/Path/. I want to remove these altogether due to the reasons mentioned above. Only the equivalent of /usr/bin/ should remain for reasons of efficiency, and be hard-linked as well for that reason. It should be necessary to explicitly specify the version of a library to compile a program against, instead of having the compiler allot some random version it chooses to find. For example,
gcc -I/usr/pkg/libfoo-2.0/include \ -L/usr/pkg/libfoo-2.0/lib -lfooor even directly
gcc -I/usr/pkg/libfoo-2.0/include \ /usr/pkg/libfoo-2.0/lib/libfoo.soThere can, of course, be a symlink from libfoo-2.0 to libfoo-2.0.123 if 2.0.123 has the "2.0 API".
While we're at it, I want to remove /usr/ and /usr/local/ and so on as well. You see, it would sometimes be convenient to be able to use packages from multiple distributions simultaneously. So why not install distribution stuff in /debian-sarge/, /debian-etch/, /gentoo-whatever/ and so on, and manually compiled stuff in /local/?
If I, for example, preferred using the stable Debian distribution, but needed some package from unstable, I could simply install those packages from unstable that are needed in the respective hierarchy, and not have worry about them removing the stable versions and eventually having to install everything from unstable. This scheme does, of course, presuppose that the packages in the newer distributions can work with the daemons and so on of a minimal base system (installed in e.g. /sys/) of the preferred distribution.