Linked by Thom Holwerda on Mon 30th Jan 2012 20:39 UTC
General Unix Finally something really interesting to talk about. If you've used UNIX or any of its derivatives, you've probably wondered why there's /bin, /sbin, /usr/bin, /usr/sbin in the file system. You may even have a rationalisation for the existence of each and every one of these directories. The thing is, though - all these rationalisations were thought up after these directories were created. As it turns out, the real reasoning is pretty damn straightforward.
Permalink for comment 505332
To read all comments associated with this story, please click here.
RE: Filesystem Hierarchy Standard
by Alfman on Tue 31st Jan 2012 21:19 UTC in reply to "Filesystem Hierarchy Standard"
Member since:


"You might think Gobo Linux brings order, but you aren't taking into account that it carries the 'legacy' structure too, it just hides it."

Of course you are correct, but solving that is a real conundrum. Unfortunately one is required to maintain legacy paths whenever compatibility is required since the old paths are hard coded in binaries and libraries throughout the linux software codebase. The *inability* to change them makes the status quo ideologically imperfect, even those who don't mind the legacy paths should recognize this.

In my personal distro, I've given it some thought and came up with two possible compatibility solutions. Keep in mind, a motivating goal is to keep application specific files together so that, as with GoboLinux, applications can be installed by untarring a single directory. A list of commands can be built using symlinks pointing to their applicaiton directories.

Solution A. Remove the dependency upon legacy paths by modifying the kernel and/or libc to treat file requests as "named resources" instead of absolute file system paths. This mapping could be stored in either a system wide or application specific named resource map. This way, when an application requests "/etc/resolv.conf" or "/usr/bin/perl" or "/dev/ttyS0", it could be mapped to the actual file where-ever it is located. The mapping could be optional and revert to previous behavior as needed.

This would provide two immediate benefits:
1. The dependency on fixed legacy fs paths is eliminated (or rather it's internalized to the binaries/libraries).

2. It could provide excellent documentation about what the external dependencies are for any given application, and makes it trivial for administrators to change them per application without recompiling a thing.

Solution B. Run applications inside an automatic CHROOT environment to mimic the environment they expect.
Basically, the chroot contains a fake root directory layout which symlinks to the actual directory layout and can do so without polluting the actual directory layout with legacy paths.

chroot/hostfs -- mount --move of /
chroot/bin/ -> hostfs/app/bin
chroot/sbin/ -> hostfs/app/bin
chroot/usr/bin/ -> hostfs/app/bin
chroot/etc/ -> hostfs/config

The problem with solution B, is that while it works in a compatible way, users of these apps will see the legacy paths instead of the hostfs paths.

Reply Parent Score: 2