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 327848
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: what is wrong with FHS?
by sorpigal on Sun 24th Aug 2008 20:26 UTC in reply to "RE[4]: what is wrong with FHS?"
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

Doc Pain Member since:
2006-10-08

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.


A means to determine it is by looking at the path of an installed program:

% which lpq
/usr/bin/lpq

Ah, this one belongs to the OS.

% which lpstat
/usr/local/bin/lpstat

This has been installed afterwards. (Now it's possible to use the tools provided by the package management system to find out which application had installed it.)

Furthermore, you can read from the creators of the BSD which things they provide (with their OS) and which they don't. For example, the default installation of FreeBSD and OpenBSD differ in regards of what does belong to the base system.

Other questions coming into mind could be: Why is a name server part of the base system? Why is a DHCP server not part of the base system? I'm sure you can imagine similar considerations.

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


Usually from "man hier" or the respective description - if one is available. If not, well, I think the author starts guessing and finally implements something on his own.

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


I won't claim there is no exception. Often, I find applications using share/ and lib/ directories in a similar way (e. g. to put icons there). There are recommendations, but not everyone uses them. So it's completely possible in the BSDs, as it is in Linux.


All *nix systems clean /tmp on start.


No. For example, if you set clear_tmp_enable="NO" in /etc/rc.conf in FreeBSD, the content of /tmp will be kept between reboots.

I don't know about you but I very rarely reboot my computers, except to patch the kernel and upgrade hardware.


At home, my computers run just as long as I use them or as long as they've got something to do. At work... well, who reboots servers? :-)

Can we really rely on boot-time cleaning?


It's a system setting, the maintainer of the system should know. And it's the standard behaviour to start with an empty /tmp, as far as I know.

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?


Definitely. Maybe you know the term "file disposition" from IBM mainframe OS architectures / JCL. You can define how a file will be handled during a job, e. g. it's deleted after the job has finished (often welcome solution), or it should be kept for further use (sometimes useful, mostly for diagnostics).

But I still think the term "temporary" indicates that something is not very useful to the user, but maybe to other programs.

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,


Exactly. But when we suggest a "correct behaviour", it should be documented in an understandable way. I'm not sure who would be responsible for this, maybe the creators or maintainers of an OS? But then, what about cross-platform applications? And when we're talking about Linux, who should develop a common standard there? And would the different distributors follow it?

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.


Interesting look at the nature of rules, but understandable.

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.
[...]
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.


Other arguments could be "never touch a running system" or "don't ask why it works, it just works". Sooner or later, this can lead into real problems. I see the problems simply by following your questions: Many of them cannot be answered completely, and answers sometimes lead to the inconsistencies you mentioned. Concepts leading to such answers are far away from a mandatory standard.

BTW, your reply looks truncated. Was it?


Maybe I exceeded the char[8000] limit, but the preview was complete. "Just a general consensus helps here." should be the last line, it's possible that I didn't press the keys strong enough. :-)

Reply Parent Score: 2

sorpigal Member since:
2005-11-02

Other questions coming into mind could be: Why is a name server part of the base system? Why is a DHCP server not part of the base system? I'm sure you can imagine similar considerations.


Yes, it is these kinds of things to which I was referring.

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


Usually from "man hier" or the respective description - if one is available. If not, well, I think the author starts guessing and finally implements something on his own.
"

I did just look up the hier(7). It is nice in that it does specify some directories that exist under /var/, but it does not say what application authors should do with their own apps. I do like that there's a /var/tmp/--this suggests that someone is thinking about these issues.

The BSD systems are certainly less schizophrenic then Linux distributions. It's probably because of the more cohesive base on which things are built and the lesser variation due to there being many fewer bases (like... one, each).

"All *nix systems clean /tmp on start.


No. For example, if you set clear_tmp_enable="NO" in /etc/rc.conf in FreeBSD, the content of /tmp will be kept between reboots.
"
I should be more careful what I say. All *nix systems of which I am aware have as a default or common behavior to clean /tmp between shutdown and start. That is, none are missing this feature.

who reboots servers? :-)


Windows admins (-;

[drumroll]


"Can we really rely on boot-time cleaning?


It's a system setting, the maintainer of the system should know.
"

I am imagining an all-too-likely real world scenario in which root doesn't really understand how the system works and is supposed to work and where application authors don't take time to understand the system but just write as quickly as possible. This is the mainstream "Windows"-style world of server administration that I see. I don't expect the useless people of the world to become less worthless and more expert just because they start using a better OS. I don't want to exclude these people for a lack of knowledge. So I try to think how we can, without giving up any actual power or control, create a system that will be nicer to people who really *don't* know what they're doing, are not going to learn it if they can help it and feel that they are far too busy to be concerned about details. Having a system which is consistent, logical and predictable in as many ways as possible would help.

Maybe you know the term "file disposition" from IBM mainframe OS architectures / JCL. You can define how a file will be handled during a job, e. g. it's deleted after the job has finished (often welcome solution), or it should be kept for further use (sometimes useful, mostly for diagnostics).


I did not know about this. IBM mainframes are before me, or above me, depending how you look at it. Thanks for mentioning it.

But I still think the term "temporary" indicates that something is not very useful to the user, but maybe to other programs.


I would treat a ~/tmp/ very differently from /tmp/, to be sure. That said, I remember a story about a MacOS user who stored all his files in the trash can and was very upset when he found one day someone had emptied it...

[...] when we suggest a "correct behaviour", it should be documented in an understandable way. I'm not sure who would be responsible for this, maybe the creators or maintainers of an OS? But then, what about cross-platform applications? And when we're talking about Linux, who should develop a common standard there? And would the different distributors follow it?


This is an important point. I don't think any answer which originated from a single Linux distribution is ever likely to gain wide adoption (too much NIH syndrome). If several people who together do not represent a single vendor were to get together, preferably in an open fashion (e.g. a mailing list, a conference) and hammer out some agreements, that would be good. If they could then produce some documentation as you describe (clear, understandable, preferably with rationalizations in the footnotes) and release it as a recommendation then I think this might have some potential.

I am a believer in success on merits. The reason no FHS revision has gained traction is because they all have large deficiencies vs. the present way of doing things, or are equally arbitrary. If some good, clear approach were designed carefully it could avoid serious harm to any major workloads. If it also provided some clear advantages to distributions, packagers, and developers then I think it might gain acceptance. Good documentation will naturally be followed if it is known to the people who might need it. That is my belief.



Other arguments could be "never touch a running system" or "don't ask why it works, it just works". Sooner or later, this can lead into real problems. I see the problems simply by following your questions: Many of them cannot be answered completely, and answers sometimes lead to the inconsistencies you mentioned. Concepts leading to such answers are far away from a mandatory standard.


Well as long as you see my point I think that is as much as I can ask. I'd prefer more concrete standards (mandatory is such an ugly word!) and not just concepts. Concepts are fine, but some concrete recommendations would be better.

"BTW, your reply looks truncated. Was it?


Maybe I exceeded the char[8000] limit, but the preview was complete. "Just a general consensus helps here." should be the last line, it's possible that I didn't press the keys strong enough. :-)
" [/q]

Ah, yes. It was definitely truncated.. by three characters. It ended: "Just a general consensus helps he"

Reply Parent Score: 2