Weekly Edition
Return to the Development page
| |||||||||||||
Updates to the File Hierarchy Standard
A new revision of the
Filesystem Hierarchy Standard (FHS) (PDF) has been published by
the Filesystem Hierarchy Group.
This standard consists of a set of requirements and guidelines for
file and directory placement under UNIX-like operating systems.
The guidelines are intended to support interoperability of applications,
system administration tools, development tools, and scripts
as well as greater uniformity of documentation for these systems.
Through its history, those who built the various flavors of Unix have placed standard files in varying, system-specific locations. To a lesser degree, the same problem has also occurred with the numerous Linux distributions. Adherence to the FHS by Linux distribution architects has made life much easier for system administrators, end users, and software developers. The FHS categorizes of files with two attributes, shareable/unshareable and static/variable. Standard directories are then categorized according to the attributes of the files within. In traditional UNIX implementations, directories often contained files and subdirectories with all of these attribute combinations. By strictly grouping the directory contents according to attributes, the sharing of common directories between systems, and the protection of site-specific data, is simplified. This version of the standard proposes the creation of two new top-level directories, /srv and /media. The proposal for /srv defines the top-level directory as being used for data generated by users for the services the system offers. This would include, for example, ftp, www, and CVS repositories. The /media proposal suggests the creation of a top-level directory which contains mount points for removable media such as: /media/cdrom /media/cdrecorder /media/floppy /media/zip The commonly used directory /mnt would then be restricted to use by the systems administrator for temporary mount points. While the hammering out of such standards is likely to cause a lot of lively discussion, the benefits of filesystem standardization by the majority of Linux distributions is indeed great. (Log in to post comments)
Updates to the File Hierarchy Standard Posted Nov 13, 2003 9:17 UTC (Thu) by tomsi (subscriber, #2306) [Link] Hmm.This looks like the way SUSE already does it. It feels strange compared to the "good old days" way of doing things, but it does clean up things and is easy to get used to. One thing that I have never been comfortable with, is placing the data files for mysql/postgresql in /var/lib. Shouldn't they also be placed in /srv ? Tom
Updates to the File Hierarchy Standard Posted Nov 13, 2003 9:20 UTC (Thu) by cdamian (subscriber, #1271) [Link] I don't like it, I don't think its neccessary to put more stuff into /I don't understand why they didn't use /mnt/media seems cleaner to me. But then this is all just about taste.
Updates to the File Hierarchy Standard Posted Nov 13, 2003 11:25 UTC (Thu) by amtota (guest, #4012) [Link] I agree.Enough mess in / already. If we ever want to have linux on the desktop, we need to have a readable root filesystem for basic users, at the moment it isn't. Either we have a gui wrapper that hides all the details, or we need to move things around (Gobelinux does this?) I have been using linux for over 9 years, and I am sorry to say that I still hate the filesystem layout combined with the average X gui, how many times have I had to go .., .., ./mnt, ./cdrom, ./XXX , ./YYY to get to some file through some very ugly file selector: think all non-kde non-gnome apps (that's quite a few) and the old gnome file selector is hell too.. Not to mention all those apps with their own crap fileselectors...
Updates to the File Hierarchy Standard Posted Nov 13, 2003 12:32 UTC (Thu) by gallir (guest, #5735) [Link] Not to mention all those apps with their own crap fileselectors...OpenOffice.org among them. You cannot go directly to your home directory, which is a pain in the ass, for example, if you opened a remote file from the browser (which often put the temporary files in /tmp/). You have to walk up to the root and then walk down to you home dir just to save the file.
Open Office file selector Posted Nov 14, 2003 13:33 UTC (Fri) by shane (subscriber, #3335) [Link] Not to mention all those apps with their own crap fileselectors..OpenOffice.org among them. You cannot go directly to your home directory, which is a pain in the ass, for example, if you opened a remote file from the browser (which often put the temporary files in /tmp/). You have to walk up to the root and then walk down to you home dir just to save the file. Huh? I just clicked "File" then "Open" and on the upper right is an icon that takes you to your "Default Directory", which is my home directory. Don't rant about Open Office - it's a fantastic piece of software. It keeps me sane at my work, where about 1/3 of the company uses Windows and is obsessed with doing everything in Microsoft Office. :-/
Updates to the File Hierarchy Standard Posted Nov 13, 2003 12:44 UTC (Thu) by eru (subscriber, #2753) [Link] If we ever want to have linux on the desktop, we need to have a readable root filesystem for basic users, at the moment it isn't.That can be argued both ways. My gut feeling is that for an unsophisticated user, avoiding deep hierarchy for such common things as removable media is easier. Besides the /mnt/media/floppy may look too "complex" and long ("/mnt? what does that come from. Mountain?") I used to have root directories /a and /b for mounting the first and second floppies. "Heretical", but very convenient. But eventually I got tired of re-creating them and the fstab entries after each Linux update, and my usage of floppies decreased anyway. .. Not to mention all those apps with their own crap fileselectors... Agree about the file selectors. Most have the basic errors of not remembering the directory you last used (which quite often is where you want to go again), and not providing a LRU list of recent directories and/or files. I wonder how much it would help if there was for all file selectors a global easily selectable list of 4...8 recently used directories (per user of course). It would make it simple to save a file with one app to some directory, then open it from there with another app. It would also be a big help when alternating between working on files in some typically narrow set of directories. I commonly do that. I really should test this concept myself, unfortunately I have very little experience with GUI coding.
Updates to the File Hierarchy Standard Posted Nov 13, 2003 14:22 UTC (Thu) by vegge (subscriber, #6926) [Link] > Agree about the file selectors. Most have the basic errors of not> remembering the directory you last used (which quite often is where you > want to go again), and not providing a LRU list of recent directories > and/or files. Please! Are there technical barriers to implementing this? I think it would be a big improvement in terms of usability.
Updates to the File Hierarchy Standard Posted Nov 13, 2003 20:13 UTC (Thu) by NAR (subscriber, #1313) [Link] [...missing list of recently used directories...]When I first started to use the mplayer GUI, it was already implemented there - about two years ago, I think.
Updates to the File Hierarchy Standard Posted Nov 14, 2003 8:17 UTC (Fri) by eru (subscriber, #2753) [Link] The actual challenge is not implementing it in some single program like mplayer, or even in some single GUI toolkit, but getting all GUI apps to do it in a consistent way. I think the way to go would be to freedesktop.org to agree to a standard about this, and getting it to both GNOME and KDE toolkits.
Updates to the File Hierarchy Standard Posted Nov 13, 2003 18:41 UTC (Thu) by guardian (guest, #16832) [Link] Think Aqua!Okay, Okay... I know it's not nice to suggest that other OSes are ahead of Linux on the desktop, but let's face it, if you want to see a huge step in the right direction for simple usability on UNIX, take a look at OS X. When doing normal end-user work on my PowerBook, I never have to deal with most of the crap in /. It's still there... and if I'm setting up a UNIX service, I can do it right, but the whole user interface is consistent and easy to use.
Linux != MacOS X Posted Nov 14, 2003 15:12 UTC (Fri) by pflugstad (subscriber, #224) [Link] One thing to keep in mind when comparing Linux to MacOS or Windows - Linux is literally a collection of largely independent programs, GUIs, file selectors, shells, etc. There is no one person or corporation in charge of all of them that can mandate: thou shalt do file selection like this. This is both a blessing and a curse of open source software. Trying to get everyone to agree on "the one true GUI" is like trying to herd cats. It's quite chaotic, but it means choice.I too wish that there would be a consistent GUI for Linux - it would go a long way towards making it much more usable, especially as a Desktop. But it's rather like comparing apples to oranges in trying to compare Linux to MacOS.
Linux != MacOS X Posted Nov 14, 2003 19:41 UTC (Fri) by guardian (guest, #16832) [Link] You can't say "we want to build the best desktop workstation ever" and then turn around and say "but Linux can't be it because the availability of choice makes it impossible." Choice is a wonderful feature to have for power users. The majority of people using computers for productive work, besides developers, aren't power users. For them, you have to give them the choices they want and not clutter up their minds. A well designed interface is one that allows the user to do what they want to do without having to learn the inner workings of the operating system. This is the obstacle before every OS... and it's the obstacle that keeps Linux in the power-user-only market. MacOS X is a great model... yeah Apple is a commercial entity, and as you said it's easier for them to do it because of that. MacOS X is still further than anyone else has gone down that road. It's a great model for a user interface. I'm not suggesting duplicating it... but it could be an inspiration to gnome and kde. And for what it's worth, MacOS X is still UNIX... it too is still very much a collection of a bunch of single-purpose tools, and it still has to deal with the basic rules of UNIX.
Updates to the File Hierarchy Standard Posted Nov 14, 2003 5:51 UTC (Fri) by komarek (guest, #7295) [Link] I don't think any UNIX filesystem will be "easy" for "basic" users. But then, maybe I don't know what you mean by "basic". Understanding UNIX(-like) filesystems requires understanding1) files (this is hard for many people) At some point after those concepts are settled, one can talk about conventions for how to arrange the directories and files. And with this level of sophistication, it probably doesn't matter too much where things are as long as there is some non-trivial amount of consistency. -Paul Komarek
Updates to the File Hierarchy Standard Posted Nov 13, 2003 18:28 UTC (Thu) by hazelsct (guest, #3659) [Link] Even better, why not just /mnt? What's the difference between a persistent device and a pluggable device? Is a hard drive (USB, SCSI or IDE) persistent or pluggable? It can be either one, as can anything else.It seems foolish to create a new root entry for /media based on some arbitrary distinction which is losing its relevance fast.
Updates to the File Hierarchy Standard Posted Nov 14, 2003 5:48 UTC (Fri) by komarek (guest, #7295) [Link] I believe it was about permissions, not so much persistance. Only root for /mnt, regular users get /media.-Paul Komarek
Updates to the File Hierarchy Standard Posted Nov 13, 2003 14:14 UTC (Thu) by pixelbeat (guest, #7440) [Link] why not have/a: etc. :-) Seriously though I think a /media/ is very good.
Windows complexity Posted Nov 13, 2003 18:29 UTC (Thu) by alspnost (guest, #2763) [Link] Damn right there!! Windows is "simple" because:* Most people run as password-less "root" and can do anything But try _administering_ Windows in a network environment, and it's a terrifying nightmare. If I want to tweak something on a user's box, I can't just bring up a root shell and do something; I have to log them out and log in as administrator. And don't even get me started on the registry, group policy, and management tools. What I find really amusing is that to do some of the really low-level stuff, you need to use ... the DOS command line. At that point, you realise that Windows is *not* a nice friendly fully graphical integrated world, but more of an over-complex, hideous mess with a clean-looking familiar interface glued on top. Anyway, getting back to the topic, I think that /media is good, but I'm not sure about /srv. It's getting messy up there in that root fold^H^H^Hdirectory ;-)
FHS rant Posted Nov 13, 2003 17:29 UTC (Thu) by LogicG8 (guest, #11076) [Link] I remember when I first started using linuxthere was /cdrom and /floppy and /mnt was empty, I liked it that way. Then /mnt got populated with a bunch of stuff. It cleaned up / a bit but having to mount a temporary FS to /mnt/mnt/ ugh. So I like the idea of this change. Forgive me for this but... Configurations... Try having personalized Upgraded your computer? Shell out a bunch of Windows has broken? Reboot. That didn't work? Here's a fun game for all the users with windows. Having to remember that there are files that The FHS gives me the sanity desire. It's not
FHS rant Posted Nov 14, 2003 16:51 UTC (Fri) by tjc (subscriber, #137) [Link] I remember when I first started using linux there was /cdrom and /floppy and /mnt was empty, I liked it that way. Then /mnt got populated with a bunch of stuff. It cleaned up / a bit but having to mount a temporary FS to /mnt/mnt/ ugh. So I like the idea of this change.I do too. Having /media/floppy, /media/cdrom, etc. is a nice compromise between having all the mount points in /mnt (Red Hat), making /mnt unusable as a "quick and dirty" mount point, and having all the mount points in / (Debian), which gets messy. In this scheme /mnt is most likely to be used from a terminal, so the short pathname is nice, whereas /media/whatever is more likely to be accessed from some sort of menu, so the longer pathname doesn't really matter. This seems ideal.
FHS rant Posted Nov 17, 2003 8:43 UTC (Mon) by mwilck (guest, #1966) [Link] Bless ypu, LogicG8 - I agree 100%. I am sick and tired of reading those "'My Documents' is good because people are used to it" statements.
/srv Posted Nov 13, 2003 18:47 UTC (Thu) by Ross (subscriber, #4065) [Link] That definition seems a bit fuzzy for a standard. User generated dataonly or data exported by programs but not needs for the program? Also, there are quite a few kinds of data besides web pages and source What about DNS and DHCP tables? Using /var/servicename would have matched traditional usage more closely.
/srv definition fuzzy Posted Nov 15, 2003 17:57 UTC (Sat) by giraffedata (subscriber, #1954) [Link] I agree it's not a standard-quality definition. On any useful system, all data is generated by users -- i.e. as a consequence of the system being used. I think what they meant was "production data," as opposed to system overhead data. In other words, files that contain the information the system is intended to store, not just data that controls the system infrastructure. Since they like to distinguish between read/write and read only data, they might also have meant to restrict this to data that gets created as the system runs, as opposed to production information installed by a system administrator as part of building the system. Using /var/servicename would have matched traditional usage more closely I assume they intend /var/srv/servicename, which is better than /var/servicename because it gives the services their own namespace.
Updates to the File Hierarchy Standard Posted Nov 14, 2003 11:05 UTC (Fri) by markc (subscriber, #4419) [Link] Damn, I've been using a /home/media to store "media" content like mp3s,images and movies so to see /media used for removable devices is dissapointing for me. Now I'm stuck as I'm not happy with the FHS using yet another top level directory so I propbably won't adopt it for my systems, therefor I'll be forever non-standard, and I have to change my usage of /home/media to something else now that they've "hijacked" the meaning of "media" for devices rather than content. I don't understand the persmissions issue of /mnt vs /media. If /mnt has wider perms than just root to allow users to un/mount devices then surely that could apply to directories inside /mnt just as easily. If another reason is to get away from the cryptic menaing of /mnt then what about /etc ?.. I defy anyone to come up with the original and plausible defininion of what "etc" originally meant ? I can't see what config files and etcetera could possibly have in common but then we don't know what the original unix people were smoking in those days. It's too late now but I would have voted against any extra root directories. To me, the FHS folks should be looking at a completely new overhaul of the directory structure to suit the rest of the 21st century and not tinker around the edges of the old standard... either work within the original directories or come up with a completely new and more rationally named system from scratch, building on the wealth of experience of the old system and taking on board the needs of this and the next generation. -1 for /media and -1 for /srv. --markc
Updates to the File Hierarchy Standard Posted Nov 15, 2003 6:37 UTC (Sat) by bronson (subscriber, #4806) [Link] Let me see if I can summarize your message, markc. "Somebody else should make the Linux filesystem more consistent!" Is that about right?However, you indicate that you will fight any such proposal that disagrees with how you currently do things. I must say, sir, your message is quite strange.
Updates to the File Hierarchy Standard Posted Nov 17, 2003 5:49 UTC (Mon) by rfunk (subscriber, #4054) [Link] Nice to see some "official" repudiation of Red Hat's horrible disruptionof /mnt/. Those who defend such abominations as /mnt/cdrom don't understand the purpose of /mnt in Unix. I like the /srv idea too; I've often wondered about the best place to put things like web pages and cvs repositories, since /var always felt like more of a place for system files than production files. Sometimes that stuff ends up in /home because it's more user data than system data, but that's not right either. And if you don't like these, just remember: symlinks are your friend.
|
|||||||||||||