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.

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"