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.
Thread beginning with comment 505283
To read all comments associated with this story, please click here.
Filesystem Hierarchy Standard
by jabjoe on Tue 31st Jan 2012 12:14 UTC
jabjoe
Member since:
2009-05-06

http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

From the first time I read that, it seemed simple enough to me.

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.

http://wiki.gobolinux.org/index.php?title=The_GoboLinux_Way#The_.22...

That's not simplifying things, it's just sweeping things under the carpet. Hiding complexity is not the same as removing complexity (though of course it has its place). If you actually want to understand the system you still have to understand it, and with a second system as well, now there is more to understand.

The Unix Filesystem Hierarchy Standard comes from a tangled history, it may be true, but it's been morphed into something sensible and more importantly, standard. Yes, usages have evolved, but that's only right and proper to put things to good use.

You try and reinvent a standard, you often just end up with two systems because you have to support the legacy. Which is only worse if not everyone sees it as "legacy".
(Wayland is wonderful, I love it, but it won't ever kill X, but with X running on top, it makes X actually better!)

This Fedora change is small, but to me pointless (or worse), not even a carpet sweeping exercise.

The Debian multi-arch change, now there is a file hierarchy change I can get behind. In fact, as someone who has done a bit of cross compiling for ARM, and runs a x64 system (thus i386 too), it's very exciting. I hope it gets pushed out to not just other Linux distros, but to other *nix distros. Maybe even an addition to the standard, you never know!

Reply Score: 4

Alfman Member since:
2011-01-28

jabjoe,

"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

jabjoe Member since:
2009-05-06

Or Solution C, KISS, just stick with the standard as you are going to have to anyway.

It's not unreasonable things have hard coded paths to the standard location. The problem isn't those following the standard, it's those breaking it. Bend the standard, maybe campaign for revision. Evolution not revolution.

Reply Parent Score: 2