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 327812
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: what is wrong with FHS?
by sorpigal on Sun 24th Aug 2008 11:48 UTC in reply to "RE[2]: what is wrong with FHS?"
sorpigal
Member since:
2005-11-02

You're bringing up valid questions.

These are not questions; they're rhetorical or, rather, they're designed to make you think of the answers and wonder whether they are truly correct. I already know the answers to them, as far as I'm concerned, it's just that the answers vary depending on who you ask.

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.

I knew some BSD user would mention this. I hate that in BSD some configuration goes under /usr/local/--this makes no sense! Why isn't it under /etc/local/? That would be much better.

And no, you can't always be sure (as a layman) whether something is part of the "base OS" or not.

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.
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).

Defining "additional" is hard. For the BSD guys it's ports, fine. For Linux distributions it's either things not managed by the package manager or things not packaged by the distribution vendor, or it's a mess. Usually it's a mess even if one of the other rules was supposed to apply. If you make a strict distinction between local and base, why is there no /var/local? /etc/local? For that matter, why isn't base stuff under /base/ and local stuff under /local/? That would really make it all clearly different.

Games should obey this rule.

But why are games a special class of binary? Why do I have /usr/games/? Supposing on BSD there are no base-system games (I really don't know) why are games in /usr/local/games and not /usr/local/bin? On Linux some games are in games, some are in bin. Some game-related binaries (like wesnothd) are in games when they're not really games at all. If games are a special class of binary, why not development-related binaries like gcc or bison? Why not make database utilities special too?

And /opt/... I think it has initially 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.


/opt typically has this structure:
/opt/appname/etc/
/opt/appname/bin/
/opt/appname/lib/
/opt/appname/share/
Unless it has some other structure or none at all.
But even if you were right, why should there be any exception to the rules officially allowed? I despise "standards" that say "You must do it this way to conform, unless you don't feel like it in which case we'll say you conform anyway." So useless.

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

/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).

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.


You say this and the standard says this, but do the users know this? Do distributions obey? I see frequent violations.

What's more, defining "temporary" is hard. Is a flash drive temporary? I certainly think so: It is not part of the system and it may come and go. But you just placed stick/ under /media/, which makes sense in a lot of ways, too. I would have defined dvd and cdrom drives as temporary, had you asked me. What about an external USB cdrom drive? Why should it be in /media/?

"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. :-)
"

It's easy to say no, because that's what always has been. But *shouldn't* there be a structure? Some kind of convention for temporary files that an application t relies on during run vs. ones it just throws out and does not care if it sees again. Maybe distinguish tmp files created by "the OS" and "the user's applications". Do lock files go in /tmp? Lock files tend to matter, yet I see e.g. /tmp/.X0-lock. Many applications now create a subdirectory in /tmp to hold their files. Is there any documentation on when this should be done or how to name the directories?

If e.g. lock files are violations, why is it so common? I tend to blame the standard when it gets ignored.

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


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

This is your opinion. I agree, but since I see /usr/doc/ frequently it appears we are in a minority.

"What directories can I expect to find in /var?


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

Forgive me if I desire a more precise answer. Does each app make its own subdirectory in /var/? In /var/lib/? Or do you first make a subdirectory for purpose, then for app, like /var/run/appname/ or /var/lock/appname/? I see all of these things being done without agreement, rhyme or reason.

Is there any restriction on creating more directories directly in /var/? Or, if you believe each app should make its own anyway, what is the naming convention and are there any restrictions on creating diretcortories not obeying that convention?

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


Correction: If it's okay to lose it between reboots /tmp, otherwise /var. Some things in /tmp are *not* good to lose while an app is executing.

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


In ~/public_html? :-)
"

In whose home directory? I'm not trying to be difficult, it's not as if I can't answer these questions, it's just that nobody agrees on the answers. You can always give one, and I can always give one, but that doesn't make it correct and it doesn't make it likely that someone else will think the same thing and do it the same way.

"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.
" [/q]

I know why these things are the way they are, I know most of why they got that way and I know most of the differences that will be found. Your explanations are just that: yours. If there were right answers that everyone agreed on and conventions that most people followed correctly then there would be no problem.

Reply Parent Score: 4

Doc Pain Member since:
2006-10-08

These are not questions; they're rhetorical or, rather, they're designed to make you think of the answers and wonder whether they are truly correct. I already know the answers to them, as far as I'm concerned, it's just that the answers vary depending on who you ask.


That's why they are valid. And you are right, many answers depend on the concepts the person you ask is aware of.

I knew some BSD user would mention this. I hate that in BSD some configuration goes under /usr/local/--this makes no sense! Why isn't it under /etc/local/? That would be much better.


Why? The concent in /usr/local/ is structured exactly the same way the system's directories are structured. So if you know what something is, you can simply conclude where it is.

And no, you can't always be sure (as a layman) whether something is part of the "base OS" or not.


This is correct. While BSD has a strict concept how to define "the OS" and "anything else", other OSes don't. This is due to their nature. If you understood the BSD system, you will know what's "the OS" and what's not.

Defining "additional" is hard. For the BSD guys it's ports, fine. For Linux distributions it's either things not managed by the package manager or things not packaged by the distribution vendor, or it's a mess.


That's the situation, exactly.

Usually it's a mess even if one of the other rules was supposed to apply. If you make a strict distinction between local and base, why is there no /var/local? /etc/local?


Or /usr/local/var, just as /usr/local/etc. As far as I know, the content of /var is managed through system services (such as the system logger or system database tools), or at least special users and groups have to be created on the system to put things in /var (for example "CUPS Owner" or "MySQL Deamon").

For that matter, why isn't base stuff under /base/ and local stuff under /local/? That would really make it all clearly different.


Yes, if you could exactly differ between both.


But why are games a special class of binary? Why do I have /usr/games/? Supposing on BSD there are no base-system games (I really don't know) [...]


There are the basic system games, but most people won't call them games. The programs bcd, factor, grdc, number, ppt, random, strfile, caesar, fortune, morse, pom, primes, rot13 and unstr are... toys?

why are games in /usr/local/games and not /usr/local/bin?


I've never heared of /usr/local/games. Installed games go to /usr/local/bin (and their components to lib, share respectively).

/opt typically has this structure:
/opt/appname/etc/
/opt/appname/bin/
/opt/appname/lib/
/opt/appname/share/
Unless it has some other structure or none at all.
But even if you were right, why should there be any exception to the rules officially allowed? I despise "standards" that say "You must do it this way to conform, unless you don't feel like it in which case we'll say you conform anyway." So useless.


Thanks for giving the layout of /opt, I haven't seen /opt for years, I still do remember something like /opt/kde/share...

So /opt does seem to contain structures like those created by the PC-BSD's PBI system: one entry per program name, bin and libs beneath; for compatibility, symlinks from /usr/local subtrees.

You say this and the standard says this, but do the users know this? Do distributions obey? I see frequent violations.


In Linux, yes. In BSD, no. See "man hier", everything is explained. Of course, the question "Why?" remains.

What's more, defining "temporary" is hard. Is a flash drive temporary? I certainly think so: It is not part of the system and it may come and go. But you just placed stick/ under /media/, which makes sense in a lot of ways, too. I would have defined dvd and cdrom drives as temporary, had you asked me. What about an external USB cdrom drive? Why should it be in /media/?


You're completely right: The definition of "temporary" depends a lot on how you use a media. Plug in, plug out, use today, not tomorrow, well, that would be temporary. An external USB disk that is mounted all the time, okay, not temporary.

But *shouldn't* there be a structure [in /tmp]? Some kind of convention for temporary files that an application t relies on during run vs. ones it just throws out and does not care if it sees again. Maybe distinguish tmp files created by "the OS" and "the user's applications".


That would be helpful if your system would not clean /tmp automatically. You would have a better idea, for example, who (which program) placed files there, you you could see from their name if it's okay to remove them.

Anyway, at system shutdown, /tmp usually disappears.

Do lock files go in /tmp? Lock files tend to matter, yet I see e.g. /tmp/.X0-lock.


I've seen lock files for programs inside "dot dirs" inside the user's home directory, ~/.netscape/lock for example. And there's /var/spool/lock, too.

Many applications now create a subdirectory in /tmp to hold their files. Is there any documentation on when this should be done or how to name the directories?


That would be a matter of the maintainers of this particular software. As far as I remember, KDE creates own subtrees in /tmp, but for documentation... it's not that you can "man kdehier"... :-)

If e.g. lock files are violations, why is it so common? I tend to blame the standard when it gets ignored.


Not blame those who do ignore it? If I don't obey the traffic rules, it it the rules' fault?

This is your opinion. I agree, but since I see /usr/doc/ frequently it appears we are in a minority.


I think this is Linux-specific again.

Forgive me if I desire a more precise answer. Does each app make its own subdirectory in /var/? In /var/lib/? Or do you first make a subdirectory for purpose, then for app, like /var/run/appname/ or /var/lock/appname/? I see all of these things being done without agreement, rhyme or reason.


At least in BSD, theres some kind of standardization (see section "var" in "man hier": "multi-purpose log, temporary, transient, and spool file". And sadly, I don't have a more precise answer because often, applications do things on their own.

Correction: If it's okay to lose it between reboots /tmp, otherwise /var. Some things in /tmp are *not* good to lose while an app is executing.


Yes, I intended it to be understood this way. :-) The content of /var should be present without any disappearings while the system is running. Anything else would be a catastrophe.

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


In ~/public_html? :-)
"

In whose home directory? I'm not trying to be difficult, it's not as if I can't answer these questions, it's just that nobody agrees on the answers. You can always give one, and I can always give one, but that doesn't make it correct and it doesn't make it likely that someone else will think the same thing and do it the same way. [/q]

A common way is to use the home directory of the user to which's name the HTML content is registrated. But this doesn't have to be, for example, if an automated system is running that's not registrated to any user on the system. Another concept is to symlink files from a user's home directory into a directory belonging to the HTTP server application, so you could place "un-registrated" content there directly.

I know why these things are the way they are, I know most of why they got that way and I know most of the differences that will be found. Your explanations are just that: yours. If there were right answers that everyone agreed on and conventions that most people followed correctly then there would be no problem.


As you introduced, the knowlegde of existing standards and concepts, their interpretation and their de-facto use are very individual. Just imagine what happens when people start questioning and interpreting the traffic rules. Just a general consensus helps he

Reply Parent Score: 3

sorpigal Member since:
2005-11-02

"And no, you can't always be sure (as a layman) whether something is part of the "base OS" or not.


This is correct. While BSD has a strict concept how to define "the OS" and "anything else", other OSes don't. This is due to their nature. If you understood the BSD system, you will know what's "the OS" and what's not.
"

I meant to say that *even in BSD* it's hard to be sure, as a user, whether something came with the base or was part of an add-on. "User" here is both system admins and regular users.

As far as I know, the content of /var is managed through system services (such as the system logger or system database tools), or at least special users and groups have to be created on the system to put things in /var (for example "CUPS Owner" or "MySQL Deamon").

An interesting definition. OK, so how does the author of a system service know how to answer the questions about what structure /var/ has?

"why are games in /usr/local/games and not /usr/local/bin?


I've never heared of /usr/local/games. Installed games go to /usr/local/bin (and their components to lib, share respectively).
"

Perhaps in BSD this might be true, but on my system there's /usr/games and /usr/local/games. Some games don't put their binaries there, most do. This is part of the FHS, see here: http://www.pathname.com/fhs/pub/fhs-2.3.html

So /opt does seem to contain structures like those created by the PC-BSD's PBI system: one entry per program name, bin and libs beneath; for compatibility, symlinks from /usr/local subtrees.


/opt only *sometimes* contains this structure. Each program has a subdirectory, after that it's up to the whim of the author.

"You say this and the standard says this, but do the users know this? Do distributions obey? I see frequent violations.


In Linux, yes. In BSD, no. See "man hier", everything is explained. Of course, the question "Why?" remains.
"

I'd like to believe that no violations exist, but I just don't. Nobody is that perfect.

"But *shouldn't* there be a structure [in /tmp]? Some kind of convention for temporary files that an application relies on during run vs. ones it just throws out and does not care if it sees again. Maybe distinguish tmp files created by "the OS" and "the user's applications".


That would be helpful if your system would not clean /tmp automatically. You would have a better idea, for example, who (which program) placed files there, you you could see from their name if it's okay to remove them.

Anyway, at system shutdown, /tmp usually disappears.
"

All *nix systems clean /tmp on start. This is not a workaround for a broken system that doesn't clean /tmp. Systems rarely clean /tmp while the system is up. I don't know about you but I very rarely reboot my computers, except to patch the kernel and upgrade hardware. Can we really rely on boot-time cleaning?

Secondly, even if we're not worried about crufty junk accumulating it seems to me that it would be useful to provide more clarity. Don't tell me "just don't ever look in /tmp" because sometimes you have to... and sometimes you're writing a program that has to work with temporary files. Isn't it better to have a clear place to put things?

I've seen lock files for programs inside "dot dirs" inside the user's home directory, ~/.netscape/lock for example. And there's /var/spool/lock, too.


This is a perfect example of the problem: The correct behavior is not known so a developer makes something up. I'd like to avoid this kind of thing,

"I tend to blame the standard when it gets ignored.


Not blame those who do ignore it? If I don't obey the traffic rules, it it the rules' fault?
"
There are two problems with that analogy: (1) Laws are enforced, standards aren't. (2) When you have a rule no one obeys you have a bad rule, not bad people.

(concerning /var structure)
At least in BSD, theres some kind of standardization (see section "var" in "man hier": "multi-purpose log, temporary, transient, and spool file". And sadly, I don't have a more precise answer because often, applications do things on their own.

And each application doing its own thing is a problem because then there's no consistency. This is why I say the FHS has problems.

"[q][q]If I have a web site where should the files for it be stored?


In ~/public_html? :-)
"

In whose home directory? ... [/q]

A common way is to use the home directory of the user to which's name the HTML content is registrated. But this doesn't have to be, for example, if an automated system is running that's not registrated to any user on the system. Another concept is to symlink files from a user's home directory into a directory belonging to the HTTP server application, so you could place "un-registrated" content there directly. [/q]

But in the FHS there is no place for a directory belonging to the HTTP server except for /usr/lib/httpd (or under local as you choose) and somewhere in /var. Yet a web sites files are not exactly run-time modified and clearly should be under /home, but no user in /home owns them, so...

The best answer I have apart from /var is /home/www on a system where a user named www executes the httpd.

This once again goes back to my point: The FHS has problems, mostly that it doesn't answer questions it should and partly that it's terribly, arbitrarily inconsistent. People who want to radically overhaul it are usually misguided, but they frustration springs from very real issues.

BTW, your reply looks truncated. Was it?

Reply Parent Score: 2