Helio/usr
From FBSD_tips
/usr, as both a separate filesystem, and as a 'vital' part of the hierarchy, should be removed.
[edit] History
/usr started life as the root of users working directories. For instance, there was a /bin, /lib, and a /usr, which contained /usr/ken, /usr/dmr, and a /usr/adm (for the 'root' user). This was all there was to it, and life was good.
When Bell Labs purchased a new disk, it was decided to be mounted under /usr, as this was where most of the data was stored anyway (remember, at the time the convention for most users was to have programs they wrote exist under their working directory, ie /usr/ken/awk; or for the more organized, /usr/ken/bin/awk). This made alot of sense, so the convention of having /usr a separate disk was more then acceptable.
At this time, the original / was small, and read off a tape; the /usr disk was a larger fixed head disk, that didn't take up precious ram . So, when things such as troff where written, they decided (wisely) to just create a directory under /usr, called /usr/bin, and store these programs there. (There even was a bin 'user' to match...).
This convention, of having users under /usr, was used by Research UNIX (and subsequent system releases) until the tenth edition, where it was carried over into Plan 9, where it still exists.
When Sun created NFS, they decided to mount the NFS server directories for each user under a separate mountpoint, while keeping their working directories under /usr; they named it /home, the user's 'Home' on the NFS server.
Over the years, the original meaning of /usr was lost, and was replaced by laughable explanations (the backronym 'UNIX System Resources' is hilarious). Most people assumed /home had always been where user's working directories were stored, and even the notion of having a working directory under /usr surprises (and even scares!) them.
[edit] Why hasn't it gone away yet?
It seems simple, just remove /usr and put all binaries under /bin. Unfortunately, a few programs still hard code paths into binaries (a bad, bad practice). The worst offender has to be perl scripts, where /usr/bin/perl is always present, and most people have to work in a special case handling specifically for it.
[edit] Why change it?
Organizational purposes, the same reason why we have multiple directories in the first place.
It really makes very little sense to have, all things considered. Segregating files based on what they /are/ (having binaries in /bin only, having platform specific 'libraries' in /lib, having platform independent files in /share) makes more sense from an administrative standpoint. Let's borrow a style from Plan 9:
/ -> mount_nfs
/bin -> mount -t nullfs -o ro,union,noatime /.${ARCH}/bin /bin && mount -t nullfs -o ro,union,noatime /share/bin /bin
/lib -> mount -t nullfs -o ro,union,noatime /.${ARCH}/lib /lib && mount -t nullfs -o ro,union,noatime /share/lib /lib
/home
/share/bin
/share/lib
/.i386/bin
/.i386/lib
/.amd64/bin
/.amd64/lib
/.powerpc/bin
/.powerpc/lib
/.sun4v/bin
/.sun4v/lib
Now you have an (albeit naively simple) architecture independent multisystem layout, with an organizationally sound hierarchy. It's alot simpler to handle these special cases if you have a hierarchy where each directory has a certain meaning attached, rather then a frankly arbitrary one as is the case with /usr.
Personally I see /usr as a blemish on UNIX's history; the sheer amount of hard coded paths (when they could have been easily solved the way PATH was, via environment variable) sickens me. So, naturally, whenever I can get away with it, /usr compeletely disappears, replaced with a flat /bin, /share, /lib, /home hierarchy.
