Linked by Thom Holwerda on Sat 23rd Aug 2008 15:37 UTC
Editorial Earlier this week, we ran a story on GoboLinux, and the distribution's effort to replace the Filesystem Hierarchy Standard with a more pleasant, human-readable, and logical design. A lot of people liked the idea of modernising/replacing the FHS, but just as many people were against doing so. Valid arguments were presented both ways, but in this article, I would like to focus on a common sentiment that came forward in that discussion: normal users shouldn't see the FHS, and advanced users are smart enough to figure out how the FHS works.
Thread beginning with comment 327745
To read all comments associated with this story, please click here.
what is wrong with FHS?
by dgoemans on Sat 23rd Aug 2008 17:33 UTC
dgoemans
Member since:
2008-08-23

Other than the odd folder names, i really dont see anything wrong with FHS. Maybe making the names slightly more human readable, like kristoph suggested would be good, but i _really_ like having all executable files in a single folder, and all libraries in a single folder.
In windows it can be a challenge to find your application, since Program Files often contains names of companies, and when you do find its folder, it often contains other junk with it, like dll's that mean nothing to an average end user.
i prefer having all libraries in their own place, so that as a programmer i know what i have access to. stuff like /etc and /dev could be nicer, but the structure is still very sound to me.
my only gripe would be that some programs use weird directories, like /usr/local/firefox, and /opt/gnome. I agree in setting a standard, but I think GoboLinux's way is trying to be like Windows in a way that isn't really relevant to end users.

Reply Score: 1

RE: what is wrong with FHS?
by Don Grayson on Sat 23rd Aug 2008 18:01 in reply to "what is wrong with FHS?"
Don Grayson Member since:
2006-01-01

Other than the odd folder names, i really dont see anything wrong with FHS. Maybe making the names slightly more human readable, like kristoph suggested would be good, but i _really_ like having all executable files in a single folder, and all libraries in a single folder.

The problem with this, as Gobo pointed out, is that in the FHS all your executables are NOT in the same folder. There's /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, /opt, etc. It doesn't get any better for the libraries, documentation or anything else really and the only standardization across the various Distributions is that they can use those folders, not what must go where.

Gobo's effort does seem to accomplish a great deal for both developer and user. Developers can still use /etc, /bin, /lib but the end user never sees them! Their ability to install and run different versions of the same libraries would be a great help in a lot of situations. For instance, I installed OpenSuSE's official releases for TCL 8.5.2 and VTCL 1.6.0. VTCL won't run on TCL 8.5.2 and hasn't been updated yet, how does your average computer user figure that one out?

These sorts of problems are not isolated in Linux, and forward looking ideas like Gobo might work or might not, but at least it puts a spotlight on the problem and gets people thinking about it.

Reply Parent Score: 7

RE: what is wrong with FHS?
by google_ninja on Sat 23rd Aug 2008 18:24 in reply to "what is wrong with FHS?"
google_ninja Member since:
2006-02-05

Other than the odd folder names, i really dont see anything wrong with FHS. Maybe making the names slightly more human readable, like kristoph suggested would be good, but i _really_ like having all executable files in a single folder, and all libraries in a single folder.


Thats the problem though, they aren't. You have /sbin because you dont want super user apps in the normal users path variables. you have /bin which has the basic apps required to use bash, because years ago /bin and /usr were always on seperate partitions (if not drives), and people wanted the system to be usable even if /usr failed to load. /usr/bin is where things installed with the os go, and /usr/local/bin is where stuff compiled on that machine goes.

In reality, if /usr isn't loading properly, 99% of the time having access to sh and vi aren't going to do it for the person, and they are just going to end up rebuilding the machine. /usr/bin now has plenty of apps that require super user creds, so at this point its a pretty arbitrary line between what goes in sbin and what doesn't. Now that we have package managers, /usr/local/bin is also a pretty silly convention, since 95%+ of what is on your machine is going to come from the package manager, and if you dont package up the stuff you compile yourself, you are really asking for the pain you are going to be inflicting on yourself.

And that is just when it comes one thing getting spread all over the place for reasons that are now irrelevant, or at least irrelevant for most installations. I mean, with the advent of tab completion, is it really worth dropping the e in user? Most of the system folders are gibberish words, and there is no reason for that any more. Sure, you would still need to learn that /applications is where your executables live, but at least it is a proper word.

I agree in setting a standard, but I think GoboLinux's way is trying to be like Windows in a way that isn't really relevant to end users.


First of all, I would say it is alot closer to OSX then it is to windows. Secondly, /usr/bin has stopped being relevent to anyone for at least a decade. Being archaic for the sake of being archaic is only really helpful for the people who have been using it since the time there were reasons for these things.

Reply Parent Score: 6

RE[2]: what is wrong with FHS?
by Nalle on Sun 24th Aug 2008 07:54 in reply to "RE: what is wrong with FHS?"
Nalle Member since:
2005-07-06

I mean, with the advent of tab completion, is it really worth dropping the e in user?


Either I've misunderstood or you have!
user without e would be usr and that is not short for user, but for unix shared recources.

But then again I might have misunderstood your post, making the quote in the top here being out out of context?

Nalle Berg
/.nalle.

Reply Parent Score: 3

RE: what is wrong with FHS?
by sorpigal on Sat 23rd Aug 2008 23:18 in reply to "what is wrong with FHS?"
sorpigal Member since:
2005-11-02

Quite apart from this article's somewhat demented rantings, there really are problems with the FHS. None of them have anything to do with being cryptic or unfriendly to average users.

Here are a few:

Configuration goes in /etc/. Which files go in /etc/ and which go in their own subdirectory of /etc/? If /etc/ is for settings, why does /etc/init.d/ contain scripts? (Set aside for a moment a debate about the fine line between a config file and a script.) Under what circumstances is configuration stored in /usr/lib/appname/ and/or /opt/appname/etc?

Libraries go in /lib. Or is it /usr/lib? Which libraries go in which directories? Why does some libraries get stuck in /usr/lib/appname/? Why are some, sometimes, under /opt? Why do I sometimes see a /lib/firmware--is a firmware blob a library? Where does the FHS say firmware goes?

Does each program get installed into /usr/lib/appame? If so, do you symlink from /usr/bin to the binary or place the binary directly in /usr/bin? If I'm using /opt do I symlink or adjust the system PATH? What's the difference between /opt, /usr and /usr/local? What about games, where do they go?

What is /mnt for and what directories will you find under it? What is /media for? Where should /floppy and /cdrom really? be located?

Is there any structure to /tmp? What is the structure of /usr/local and what determines which programs are installed there? What's the difference between /usr/doc and /usr/share/doc?

What directories can I expect to find in /var? How do I decide whether a file should be created in /var or /tmp? If I have a web site where should the files for it be stored?

If you think you know the answers to some of these questions I have a surprise for you: *every unix does some of them differently and even distributions of Linux can't all agree*. The FHS does not even attempt to answer some of these questions except in mostly useless ways.

Reply Parent Score: 7

RE[2]: what is wrong with FHS?
by Doc Pain on Sun 24th Aug 2008 00:52 in reply to "RE: what is wrong with FHS?"
Doc Pain Member since:
2006-10-08

You're bringing up valid questions.

Configuration goes in /etc/. Which files go in /etc/ and which go in their own subdirectory of /etc/? If /etc/ is for settings, why does /etc/init.d/ contain scripts? (Set aside for a moment a debate about the fine line between a config file and a script.) Under what circumstances is configuration stored in /usr/lib/appname/ and/or /opt/appname/etc?


This is really something (along with the lib/ problem) that I find a bit strange in Linux. In BSD, there's a differnce between "the OS" and "installed packages", while Linux does not have this kind of separation. BSD puts system's stuff in /etc/, and local (not to the system belonging) parts in the respective /usr/local/etc/ directories. You can conclude the nature of a file from its name and it place within the file hierarchy.

Libraries go in /lib. Or is it /usr/lib? Which libraries go in which directories? Why does some libraries get stuck in /usr/lib/appname/? Why are some, sometimes, under /opt? Why do I sometimes see a /lib/firmware--is a firmware blob a library? Where does the FHS say firmware goes?


This one continues the aspect mentioned before. Some Linux distributions have /opt/, others don't. In some cases, the purpose of lib/ and share/ subtrees is merged, too.

Does each program get installed into /usr/lib/appame? If so, do you symlink from /usr/bin to the binary or place the binary directly in /usr/bin? If I'm using /opt do I symlink or adjust the system PATH? What's the difference between /opt, /usr and /usr/local? What about games, where do they go?


In general, additional software should go into /usr/local/ where the basic subtrees of the system (etc/, lib/, include/, bin/, share/) are replicated with the respective purpose. Games should obey this rule. But as I mentioned before, it's hard to say which things do not belong to the system because Linux distributions do not differ between OS and installed packages; in fact, the "OS part" is a set of packages chosen by the creator of the distribution. Rule: Everythin within /usr/local/ is extra stuff, everything outside is the system (mountpoints and home directories not mentioned here).

And /opt/... I think it has initally been intended as a directory that contains extra stuff that does not obay the subtree rule, i. e. no etc/, lib/ or bin/ separation, instead a name of the application with its own subtree.

Following the rule:

/usr/local/bin/foo
/usr/local/lib/libfoo.so.2
/usr/local/share/doc/foo/readme.txt

Not following the rule

/opt/foo/foo
/opt/foo/libfoo.so.2
/opt/foo/readme.txt


What is /mnt for and what directories will you find under it?


/mnt is intended as a temporary mount point for the system administrator (according to man hier).

What is /media for?


/media is intended for (usually auto)mounted media, it contains a subtree for the devices (e. g. /media/cdrom, /media/dvd, /media/stick) or mountpoints are created from a label provided by the media itself or by the class of the drive (man geom).

Where should /floppy and /cdrom really? be located?


Allthough the access to /floppy and /cdrom is much easier than their successors within /media (due to less typing), these mountpoints may already be deprecated.

Is there any structure to /tmp?


No, because programs or users that use /tmp should keep an eye on the stuff they do on their own. This is because /tmp may disappear at system shutdown, or, may be empty after system startup, for example when /tmp leads to a RAM disk or some system setting clears /tmp at startup. It's the system's waste dump. :-)

What is the structure of /usr/local and what determines which programs are installed there?


I mentioned this before, it's complicated in Linux because it's hard to determine what's local and what's not. In BSD, it's obvious.

What's the difference between /usr/doc and /usr/share/doc?


Only the last one should exist, an assumption from priority and precedence considerations.

What directories can I expect to find in /var?


Usually databases and logs that are created and managed by programs, not by the user.

How do I decide whether a file should be created in /var or /tmp?


If it's okay to lose it - /tmp. If it should be kept - /var.

If I have a web site where should the files for it be stored?


In ~/public_html? :-)

If you think you know the answers to some of these questions I have a surprise for you: *every unix does some of them differently and even distributions of Linux can't all agree*.


You see this from my explainations, and some reasons why it is so. Alltough much of the stuff is well intended, there are inconvenient uses of the existing structures, maybe due to sloppyness, or due to general problems of interpretation. There are many differences between the many Linux distributions and among the UNIXes, too.

Reply Parent Score: 5