FHS 2.3 include important changes like /media, /svr etc. The filesystem standard has been designed to be used by Unix distribution developers, package developers, and system implementors. However, it is primarily intended to be a reference and not a tutorial on how to manage a Unix filesystem or hierarchy.
Filesystem Hierarchy Standard 2.3 was Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
it is more a guild line than a rule.
Maybe I’m just conservative, but what’s the point of /srv? How is it different from /var? I also strongly dislike the idea of /media What’s wrong with /mnt? More importantly, what’s the point of the duplication? Plus, “media” is a crappy name — it suggests to me audio/video, not removable drives.
According to the author(s?), /mnt was historically only for temporary mounting points. Okay, you can say that you usually use floppys and CDs that way but I guess they wanted some separation. I don’t know why they proposed /srv. Perhaps it was to clean up /var… Then again, it almost make /var useless.
Anyway, I’m not too keen either with these new changes.
How can FHS be used to create software that works with distributions which are FHS compliant? (Chapter 1, Purpose.) That is to say, how will software detect whether or not the distribution it is being installed on is FHS compliant, and how will it work any differently than on one which is not?
It seems that software would have to become even more complicated to detect and work with a FHS-compliant OS, if it is to also work with non-FHS OSes. So from a software perspective, I don’t see an advantage.
But from a system usability perspective, I can see the good in a standard like FHS.
I can see the good in a standard like FHS.
Well, as long as it makes sense. I agree with Rayiner and Wrawrat, /mnt vs. /media and /srv vs. /var don’t seem to make any sense.
Have to disagree on that.
From http://dictionary.reference.com/search?q=medium
“2. An intervening substance through which something else is transmitted or carried on.”
A CDROM, a floppy, a UTP cable and a CDROM drive, FDC, NIC. They’re all “media”; the multiple of “medium”. I suppose even a motherboard is a medium from a technical point of view.
Therefore the new term is actually more clear imo.
As for duplication that’s what you get when you’re moving from one standard to another. A simple link would make sure nothing will get broken.
I’m rather wondering wether *NIX vendors will change at all, and if so, which and how fast these migrations go since a (new) standard is only in practice a standard if it’s actually widely acknowledged, resulting in being implemented.
/mnt looks like a hold-over from early unix days when every character counted, but that no longer fits into our world and we can afford a few more letters to make less cryptic names.
When somebody sees the directory “/media” which definition do you think they think of first? Its confusing for newbies (they think MP3s) and its confusing for experienced users (they think “what happened to /mnt?”)
Beyond that, what’s the logic of seperating it from /mnt? By the definition of media, hard drives are media too. So /mnt has no purpose at all. If its just a name change, shouldn’t “/mnt” be officially depreciated or something?
Bah. “less cryptic names” like “Documents and Settings” are what make Windows completely unnavigable from the command line. In the UNIX model, the user keeps mostly to his home directory. It doesn’t matter whether its called “/media” or “/mnt.’ Experienced users like the one thats shorter to type, and inexperienced users should just expect an icon on their desktop.
The difference is that /media is for removable media, such as cdroms, floppies, etc.:
/media/cdrom
/media/floppy
/media/dvd
/mnt returns to its historical assignment as a temporary mountpoint for other filesystems. Meaning that /mnt should actually have no subdirectories under it. Need to mount /dev/hdc7 real quick to grab something? It mounts as /mnt, not as a subdirectory under /mnt.
/srv is for data files served by that system. HTTP, FTP, CVS, etc.
/var is for temporary data files used by the system.
There’s a clear-cut difference.
XML specs say terseness is no longer important. This is more and more true with new technologies. Why is /media good? Mainly because /mnt sucks. Anyone who disagrees is carrying baggage from existing structure. Why /mnt then and not /mount? And /var? Don’t even get me started! /srv is much more descriptive, although I’d rather just see /services. I don’t get why the hierachy has to be shortened. With tab completion it’s irrelavent. I’ve long maintained it’s time for a complete overhaul:
/boot, /temp, /apps, /home, /services, /system, /devices. Maybe one or two more. Much more user friendly. And no, I don’t think there should be a scripted emulation layer. True progress will come when someone has the balls to shed it all and go for it with something truly useful. Just imagine the ease of administration with a file system like this:
/system/logs
/system/fonts
/services/httpd
/apps/gaim
/devices/dvdrom
I so agree with Adam on this one. I am all for /apps/gaim. The fact that you can still create icons for stuff hardly makes the current mess better.
Hi
No it wont become any easy to administrate with descriptive names. tab completion wont solve all your typing problems in the command line. compatibility with other unix like systems is also necessary for linux.
Joel:
/var is used for variable data files. /tmp is for temporary files. Big difference.
Adam:
…and then you break all backward compatibility and POSIX compliance. [sarcasm]Big UNIX players will surely like that.[/sarcasm]
There’s also a problem with a setup like you described: people will start making their own directories everywhere. If they see /apps, they’ll want /games, /documentation, /configuration… Then FHS might adopt these standards and the root will become a mess.
Honestly, if you don’t know what the shortened names means, you shouldn’t mess with them. It’s the same thing with Windows, anyway. Like Rayiner said, experienced users expect short, cryptic names while inexperienced ones expect icons. We should bother to improve that interaction with Joe Average User rather than doing an overhaul of a filesystem hierarchy that should be hidden from him, anyway.
Then again, I might be only too conservative…
XML specs say terseness is no longer important.
—–
XML sucks too. Its fine for a limited set of uses, but the current “XML for everything!” fad is disgusting. XML tries to merge human readability with machine readability, and ends up not being very good for either. Beyond that, XSLT is an abomination of a transformation language that should be put out of its misery and replaced with a propery general-purpose programming language. If merely interacting with my system required me to type shit like “<change-to-directory><dir>/</dir><dir><hom e></dir><dir>docs</dir>
</change-to-directory>” I’d shoot myself…
Why is /media good? Mainly because /mnt sucks.
—–
Brilliant and insightful argument there, Adam! Just stunning in its eloquence…
Anyone who disagrees is carrying baggage from existing structure.
—-
Again, a brilliant way to address any possible objection to your original argument! Its so simple, yet so solid! I mean, why can’t everyone produce arguments of such sheer clarity and power?
/srv is much more descriptive
——
:: blinks ::
I say we take a poll. Honestly, neither are descriptive. If you’re admining a web-server, you sure as hell know where to put the HTML files. The main difference is that /srv makes no sense to either new users, nor existing users. At least /var makes sense to existing users.
I’d rather just see /services.
—–
Now, would that directory store the actual service binaries, like its name implies, or the data for services? The top-level directories are a way they are for a reason. Its not a structural organization (media files here, documents over there, etc) but an organization based on access properties. /var is for data files and temp files that need to be quickly accessible. Hence, you can put them on a nice fast drive. /usr is for files that can stand being loaded over the network. /bin is for critical files that need to be placed on the main disk. Making groups like “/services” really doesn’t fit into that model.
I don’t get why the hierachy has to be shortened. With tab completion it’s irrelavent.
—–
Tab completion isn’t always available, for example in one-off shell scripts, etc. In any case, its a bunch of extra typing, especially because the tab key requires taking your fingers off the home keys.
Maybe one or two more. Much more user friendly.
—–
Only to the category of users who both understand the concept of a filesystem hierarchy, but aren’t familiar with the specific UNIX hierarchy. Filesystem hierarchies in general are *not friendly*. People don’t understand them. That’s why both OS X and Windows have moved to a “home directory” model. Windows even goes to the length of hiding the root drive in Explorer! This is a good step for usability.
Anybody who knows enough to be mucking about in those directories should know enough to quickly pick up the UNIX conventions. We shouldn’t cause massive problems moving things over just to please the small contingent that would actually care about such a change.
(I don’t have an opinion about srv)
First of all i agree with you regarding Windows choice of “Documents and Settings” vs. the simplicity of the name “home”; a map with (such) a description as the Windows’ one comes with a price but matters not much for Windows is mostly used from a GUI point of view. If used in CLI i found it to be dramatic …
not all *nices admins use a tab-completion capable shell either. The difference between “home” and “Documents and Settings” is quite more regarding quantity than say “mnt” and “media”.
“When somebody sees the directory “/media” which definition do you think they think of first? Its confusing for newbies (they think MP3s) and its confusing for experienced users (they think “what happened to /mnt?”)”
When i understood correctly, i agree with Joel. Permanent partitions, permanent NFS, etc would just be mounted fine (“correctly”) under /media instead of ie. /mnt or /vol.
But why would one think specifically as if there are MP3’s over there while these don’t magically (in massive amounts, or illegally) come with an OS? I mean, why would one think even think that happens??? If these would come with the OS (legally), these would reside in /usr/share. The user would “just have to know” that, but how is that different from the current system?
When a newbie goes to /media or /etc/fstab to find out about the directory “/media” (ie. search for MP3 or audio/video), s/he finds “floppy”, “cdrom” and what more. Then if s/he thinks for a second s/he got the point of it, i guess. Even when not, there’s the manuel.
When your rationale about how newbies think is true and /media is not descriptive, do you think /mnt is descriptive (for them)? Or the names of “/usr” and “/etc” do you find these names descriptive? For a newbie *NIX administrator i recommend to read a book about the filesystem hierarchy and/or to use an Explorer-like program (ie. Ncurses, X) which explains somehow what the directories in / stand for. That function makes a distribution more newbie-friendly. I don’t see how _that_ simplicity (or whatever one would want to define that) hugely got changed, or became much more complex. So there’s room for such, even in *NIX.
No, when there’s still no uniformity regarding this in the future, then i think it’ll be a lot more confusing than in the case we have either one of these 2 standards. Such diversity which is currently the case with ie. Apache, plain sucks imo (though that isn’t solved with “/media” .. but with “/srv”). Another example is SFS using “/sfs” … why not like /mnt/sfs or in the future /media/sfs?
The reality is that the filesystem hierarchy doesn’t matter to those who doesn’t know how a system works. If he/she does, he/she will understand cryptic names.
If it weren’t that the case, the filesystem should be i18n ready, and that is impossible. The GUI should provide the flexibility to show it (the parts necesary from a user point) with different names depending on the language selected by the user. As a user I don’t care where a program ends up while it works. In windows, I put all my programs under de programs directory and I keep all my personal information under another partition so if something breaks I can reinstall everthing without loosing my files.
What I want is to find my hard drive or “disco rigido” (in spanish) in an easy way. Do you look at the programs directory in windows when you are doing something useful with your computer and not playing?. If you do so is because you understand the system and can administer it. If that’s the case, you don’t need to have “nice names”.
If you think you have the right to see nice names, all the other people that don’t speak english should have the same right and, as I said before, that’s impossible.
Permanent partitions, permanent NFS, etc would just be mounted fine (“correctly”) under /media instead of ie. /mnt or /vol.
—–
Eh. I don’t see the distinction. Why is there a need to seperate temporary and permanent mounts? Further, is the gain from seperating temporary and permanent mounts really worth requiring a migration away from /mnt? How often do you use a temporary mount anyway? To have two top-level directories, one of which is almost never used seems just a little odd to me. I’m not fundementally opposed to putting stuff under /media instead of /mnt, but I don’t like the idea of having both, and see no reason to move to the former when we already have the latter.
But why would one think specifically as if there are MP3’s over there while these don’t magically (in massive amounts, or illegally) come with an OS?
—–
Its not so much that they could think that media files should come with the OS, but that they could think that’s where media files should be put. Kinda like “My Music” in Windows.
The user would “just have to know” that, but how is that different from the current system?
—–
In both cases the user would “just have to know” but with the current model you already have lots of users who already know. Nobody “just knows” the new model.
When your rationale about how newbies think is true and /media is not descriptive, do you think /mnt is descriptive (for them)?
——
Neither is very descriptive. And that’s my point. If this new name isn’t any more descriptive than the old one, what’s the point of switching?
Or the names of “/usr” and “/etc” do you find these names descriptive?
——
Of course not. But lots of people already know what these names mean. Those who don’t aren’t likely to find “/srv” or “/media” any more descriptive. Even something like “/devices” which makes perfect sense to you and me, isn’t very descriptive to newbies who don’t use that terminology. The whole idea of “/devices” particularly irkes me. You’d think that once a person has an understanding of what “devices” are (most don’t even know about the various parts inside a computer!) and then has an understanding of a “device filesystem,” that they’d easily pick on on the mount point being called “/dev” rather than “/devices”!
I agree so much with Rayiner. /media and /svr is just adding to number of directories on root without serving any distinct purpose. A file hierarchy should be short to keep it maintainable. /mnt made perfect sense to mount various media. I always mount all removable storage, either windows drives, cdrom or floppy diskette because its easy for me to see what all i have mounted. There is no use of media and frankly when i first read, i thought its for audio/video.
/svr huh what is that and why is that? I think FSH others need KISS aka Keep It Simple, Stupid.
And Lastly “Documents and Settings” ha ha ha hahahahaha
– Wolf
people would think there may be media files like MP3, avi, mpg and etc in /media directory. I don’t think that they would think it’s the mounting point of removable media. It is simple to guess that!
/srv ? Is it server, services or what? People should be confused. at first I thought it is ‘server’. (I haven’t read the reference on that site) And isn’t /srv a cryptic name as well anyway??
How about /floppy0, /floppy1, /zip0, /cd0, /cdr0, and so on? This list isn’t likely to get very long, so putting them right off the root directory shouldn’t be a problem.
Or maybe put them under /drives, of you really want to. (Quick semantics question, do you mount drives or media? Is fd0 the drive or the floppy?)
What’s the purpose of defining /mnt in the spec? Nobody but the user should be mounting anything here, and the user should be able to name it anything he/she wants.
Debian does it this way, but doing it that way generally might be a problem on a machine with hundreds of disk drives
The FHS is not an admin guide. You can mount your cdroms on /boot, /home, “/`date`”, or any other place you want.
Quoting from the purpose section of the standard:
The FHS document has a limited scope:
* Local placement of local files is a local issue, so FHS does not attempt to usurp system administrators.
* FHS addresses issues where file placements need to be coordinated between multiple parties such as local sites, distributions, applications, documentation, etc.
“I don’t see the distinction. Why is there a need to seperate temporary and permanent mounts?”
Because one has static content in which the mountpoint which resides in /media always means the same; /mnt not, it’s dynamic. The point is i don’t want permanent/static data to be interfered with a dynamic mountpoint / dynamic data. As little as possible. I’ll give some other examples of this later. Second the name like /media is possibly more descriptive than /mnt because /media refers to media which it all is (to me it is more descriptive). Those are 2 advantages i see.
I’m wondering though, would you rather put that dynamic data in /media/? If so, how would you suggest to name it? Or, would you rather put it in /mnt/, and if so, how would you suggest to name it?
“Further, is the gain from seperating temporary and permanent mounts really worth requiring a migration away from /mnt?”
Wow, good question, hard to answer, because how could one in theory can proof such? It would be most easy when the people who make these / hierarchies for OSes will 1) agree with the change 2) will implement and document the change.
In order for 1/2 to succeed, these people should have been asked for feedback first. A discussion first. How can one define something as standard when those who are going to implement that standard have not been asked for the opinion? The very same is true for those who are gonna work with it: developers, users, etc. I haven’t looked into the organisational parts…
Then the following will be minimized:
“[…] But lots of people already know what these names mean. […]”
I find the argument that it is currently like this and that people need to relearn this small part of change in hierarchy weak because that itself doesn’t justify anything. I know that’s not your only argument, we just disagree on the importance of the change, because you don’t see it as a progression or we disagree on the benefits.
“How often do you use a temporary mount anyway?”
Can’t speak for others; i use it quite a lot. I can think of a lot examples too. For example a Windows computer in the network behaves weird, but SMB does work. Mount it at /mnt, do the fix, unmount. I’d rather use that than say smbclient. Do you suggest to make /mnt/smb/computername for each computer and let these reside over there while they aren’t used (think about udev and devfs for a sec!)? Or /mnt/smb? Not descriptive. And why add something like that when it’s only temp anyway. So imo it needs one name or more names for such a dynamic mountpoint(s).
Why would i want such a temp directory together with directories which have permanent entries? Would you like to put a temporary program in your permanent program space or would you rather keep that apart from all which is permanent? What about /usr vs /usr/local? What is your opinion about the *BSD’s Ports Collection of which all is put in /usr/local rather than say Debian GNU/Linux and Gentoo Linux put all their package data into /usr? Another example: what’s your opinion about C:Windows mp and C:WindowsTemporary Internet Files in such an _important_ map as C:Windows which is permanent data and should not be deleted? Would you rather have /tmp in say /usr/tmp?
“Its not so much that they could think that media files should come with the OS, but that they could think that’s where media files should be put. Kinda like “My Music” in Windows.”
“My Music” and all that blabla resides in the user’s “home directory” and such isn’t different under *NIX; the user could create their own “music” map in ~. Under a NT, a user shouldn’t even been able to make or alter some map in the root, ie. C:, so in that way it isn’t different either. XP and on just makes the user think that C:My Music resides on C: while it in fact resides in C:Document and Settings (actually rather confusing imo since it isn’t obvious at first glance). Either way, in both situations residing in the Profile/Home directory since it’s personal data, is a clean way.
Well, gtg now. I’m interested in your views to some of the questions i asked, perhaps that makes me undersatand your opinion better
especially the permanent vs. temporary part.
Why, and why not but /etc/* in / too? What about ie. NFS/SMB and such? /nfs0 /nfs1 aren’t descriptive …
Sure, but what’s the point of developing a standard if nobody is going to follow it?
As much as I hate /media and /srv, I’ll have to live with them once my distro switches to FHS 2.3. However, I think I’ll ask some explainations to the author(s) of that document…
Firstly, I dislike /media and /srv, just a personal opinion, but I don’t care about them because I can continue using old /mnt and /var.
But what I would really see are dotfiles removed,
I think ~/etc/*_file_without_the_dot_ is a much better aproach, the directory could be overridden with the environment: $DOTFILES for example.
Advantages:
-> The ex-dotfiles can be easily kept in cvs and updated from every host, I already have my .bash_profile et al symbolically linked to ~/etc/bash_profile and under cvs management.
-> When openning a graphic file selector is not such a mess, and although files can be hidden, it’s not so easy to edit them.
-> The system is coherent, we have: /etc/ (global configs), /usr/local/etc/ (local configs) and now ~home/etc/ (user configs).
-> Avoid having a $HOME dir with ~300 files, I have even more, which is slow (mainly over nfs).
disadvantages:
-> backward compatibility: it would be done smoothly, and if this break any script (for a binary program for example), it’s just a matter of linking from the old location or keep the old dotfile till a new version, no hurry.
-> disliking: if somebody dislikes the new aproach, the environment can be used to move the files to any other location, even, it should be possible do something like: DOTFILES=$HOME and have them like before, without the dot in front of course.
PS: forgive my poor english.
Just to re-iterate (and slightly correct) what Joel Konkle-Parker said
/srv is for data files served by that system. HTTP, FTP, CVS, etc.
/var is for variable program data
/tmp is for temporary data files used by the system
There is a very clear difference between /var and /srv. I would go so far as to say that /var and /tmp are more similar than /var and /srv. All the data under /var is system generated (except for that which has been moved to /srv), it never made sense for htdocs and such like to be under /var.
BTW SUSE have been using /srv and /media for a long time now (they must have been working from a draft specification).
With regard to /media, I’m not sure about that one. I do feel it is more intuitive, but it does lead to clutter. If /mnt is only for temporary mounts, then you need a different directory (directories) for all you permanent mounts. You end up with a situation like you have in SUSE where /mnt is empty (left blank for you user to temporarily mount stuff) and you have lots of folders in root
e.g. /windows/* for MS-Windows partitions,
/data* for partitons which aren’t part of you Linux system or MS-Windows (e.g. other distros)
/media/* for removable media
Having said that, I don’t mind the clutter too much, the first thing I usually do when I install a system is create /cdrom and /floppy so I can mount removable media with less typing.
BTW Jose, ~/etc/ sounds like a brilliant idea
I second that. ~/etc really is a logical and much-needed extension to the FHS.
I will change ~/etc for ~/.etc or ~/.config or ~/cfg
now we have:
~/.gnome
with this we will have:
~/.etc/gnome
because the config files are not too often used, and you can avoid an erase.
Ah!, and don’t forget you can install locally a program in your home directory (e.g. university account), so there are persons who have in their home dir:
~/usr
~/opt
~/etc
~/bin
~/usr/bin
~/usr/doc
~/usr/share
then you modify your path, and you can even install kde locally, if a person don’t have a root permission in the system.
So, ~/etc is for config files of programs installed locally (by an user).
~/.etc for user config files.
I can’t believe that they created /media for removable media and declared /mnt to be a once off for temporary mounting. There is now no defined place to mount hard disk partitions formatted and laid out for use by a different operating system (e.g. Windows). How could they publish something with such a gaping hole?!
Similary, while I can agree with the rationale for /srv, I don’t think it’ll go very far until they define how to place things inside it. (I’d got with /srv/<service-type/[<user-category/]/<data directory>)
Personally I’d go for
/mnt/tmp for temporary mounting
/mnt/media/?? for removable media
/mnt/fixed/?? for non-removable media
Saying mount should only be used for temporary mount-points as that was the norm historically is ridiculous. Historically /usr was for user’s (USeR) home directories and files, but as users starting cluttering it up with their own programs, the /home directory was created and /usr was retained for software.
I also think they should create
/usr/kde
/etc/kde
/var/kde
and
/usr/gnome
/etc/gnome
/var/gnome
When X11 came with all it’s own apps and data files, this is exactly how they handled it. I don’t see why they shouldn’t bite the bullet and do the same for KDE and Gnome which have huge amounts of binaries, config files, data files etc. The current situation, with KDE & Gnome being in /opt in some cases, or everything thrown into /usr in the other is insane.
Also I think Anonymous’s idea for a ~/.etc/ directory is pretty good – the amount of dot directories on systems is huge.
The last thing any Unix system needs, is uncertainty as to where things are mounted. Maybe they’re in /mnt and maybe in /media?
That just makes it hard for users to be sure where mounted filesystems will be. It makes it murder to program and script with, and it requires every application ever using a filesystem entry to have to initiate checks to see if the filesystem is where it thinks it is.
Moreover! The entire principle of Unix filesystems, is that it removes the distinction of local files and mounted filesystems. They’re all merged into the same tree, so the system doesn’t have to worry about temporal systems and provide special cases for different FSs like you have to in Windows, detecting the use of a drive rather than a mounted network share.
Look at modern developments in computing systems… We have KDE’s KIO Slaves and Gnome’s VFS plugins, aiming to make remote sites and other facilities integrate with the standard file system structure in a smooth way, so that users have access to data, without them or their programs having to provide special case code. The entire objective of the last ten years of filesystem development has been to attempt to abstract filesystem implementation and show the user a harmonised data landscape.
As such, this spec is basically destroying many years of everyone’s hard work, and ultimately putting itself at odds with the flow of modern FS development.
If anyone really wants to help systems through filesystem arrangement, lay down a sensible standard that declares the final positions of given components, such as Gnome, KDE and Apache. Let me know when I use a machine, that Apache’s documents will always be in a given place, httpd.conf will always be in a given place, and that these will never change. That’d make me happy.
I agree with those that say /media in this context suggests mp3s etc. I also use “media” to describe cdroms, disks etc, but more often I use “media” to describe tv news and newspapers. Obviously, the context is important.
/mnt is a bit vague nowadays without coming from a background where drives are mounted. Certainly, saying to someone with only Windows experience “mount the drive” is going to come across as a rather surreal request.
I thought /storage might make more sense, but then again, one could reasonably assume that /storage is for “storing stuff”. So…
How about /drives
/drives/floppy
/drives/cdrom
/drives/hard
and so on…?
The counter-argument, of course, is that basic desktop users stick to /home, and the desktop (KDE, Gnome etc.) should hide everything and they need never know what lurks beneath. Simple applications could be dropped into /home and whatever “folder” the user is comfortable with.
It amounts to whoever the “guidelines” are supposed to help. I can’t help but wonder whether the effort put into “cleaning up” the hierarchy may better be applied to explaining and documenting it to those who need to know.
…but I have to add that migrating to /media is stupid. It makes no sense and buys nothing. If I need to mount something on a temp basis, I have several questions. One, why must I mount it to /mnt? Two, what if I need to mount two things at the same time? FHS breaks now. It’s worthless. Three, if I’m using automount, doesn’t that give the appearance that temp mounts are persistent anyways? The use of media is stupid and without thought by it’s creaters. It serves no purpose and is redundant. If I really need to mount something, on a temp basis, why wouldn’t I use /tmp/mnt? It’s not ambigious, it’s meaning is very clear, it leverages the implied used of /tmp, and even allows me to create additional mount points, /tmp/mnt2, /tmp/disktmp, etc., etc., etc.. Now then, let’s take a step back. If I’m mounting something that obviously is supposed to distinctly stand aside from the rest of the OS (something temp), why would I even both to a, use something on the root fs, and b, make it persistent? The use of media is just stupid and wrong. I refuse to use it. The author needs a swift, hard kick by everyone that objects to it. And soon! Then, he needs a swift, hard kick by everyone that realizes how stupid it is.
Now then, let’s talks about /svr. I like it. I love it. It makes sense. I’ve always though the overloaded use of /var was a crime. Having /svr makes sense at so many levels. What is /var for? No one sees to be able to decide? Is it for games? Logging? Mail spools? Data caches? Man pages? Web pages? Printer spools? what is it for? And the list goes on? By adding /svr and keeping /var, it allows us to move all of the stuff that doesn’t belong in /var, in the first place. Now, I don’t have to create a fs for /var/log and for /var/spool and for /var/til-the-cows-come-home. Now, I can serve data from /svr (great name too, intent is clear, though I will it were /srv, as in “serve” data). Now, I can let /var stand for what the name implies…variable system data (logs and other transient data). Does this mean that /var/spool/mail will become /svr/spool/mail?
Well, I’m done with my rant for now.
Summary? /media, kick creator, hard and often, just to remind him how stupid it is. /svr, excellent. Long been needed.
/usr does not mean USeR. It stands for Unix System Resources. This is a very confusing abbreviation, and apparently you were confused too
The unix file system is an old pile of cruft.
(was also going to say /usr stood for “Unix System Resources”)
/media: I don’t mind the name, but I do feel that they should put all mounts (temporary and otherwise) in either /media or /mnt. As a debian user, one of the first things I do is move /floppy and /cdrom to /mnt.
I do think there needs to be a place for mounted volumes, especially these days with udev’s “let’s find the volume label of the CD and mount it as such” -system (I think udev can even use cddb for cdaudio).
As for “media” as a name – the word media has been abused in computer circles to represent audio and video. But it’s still the plural of medium -> tape, (news)paper, cd, harddrive, etc.
/srv: I like it. As a sysadmin it was always problematic to figure out where to put these files. /var/www/domain1.com/ ….? /home/vhosts/…? /exports ? /var/samba/shareXXX/…?
You get the drift. If you think of it in terms of “what files do I backup” -> you don’t backup /var. So the compromise I made for myself was putting everything in /home/vhosts and backing up that – but I didn’t like the mix of user’s files, and general data to be shared. with /srv/ I can seperate these, and only need to backup /srv and /home.
So, keep /srv, dump either /mnt or /media (choose one) – and one final thing I always wondered about: why is “/usr/local” under “/usr” instead of in the root?
…/svr makes sense. Since we already have /mnt, just stick with /mnt. Adding in /media is redundant and meaningless change for the sake of change. It has no real value. As you pointed out, moving the stuff, as I said above, out of /var, into /svr, makes so much sense. It makes sense from an organizational perspective. It makes sense from an administrative perspective. It just makes sense.
Be sure to let them know that /media has got to go. It needs to be immediately dropped from the specification. I refuse to use it.
i too have been dreaming about having a ~/.etc for user settings instead of all dotfiles. by the way why are so few things going into /usr/etc and instead filling upp /usr/share?
It looks like most of the changes in this release were badly influenced by a few peoples (bad) taste rather than being based on some kind of well know approach/de-facto standard.
I’ve never seen a system using /media or /srv, and I don’t think I ever will. With additions like these people and distributions will just loose interest in FHS and FHS will make itself irrelevant.
nisse.bredband.skanova where exactly is all the cruft in the unix file system? i find it rather smart especially compared to dos/win.
/usr does not mean USeR. It stands for Unix System Resources. This is a very confusing abbreviation, and apparently you were confused too
The unix file system is an old pile of cruft.
No. Wrong.
http://lists.freebsd.org/pipermail/freebsd-chat/2003-December/00171…
http://www.raycomm.com/techwhirl/archives/0303/techwhirl-0303-00381…
here’s what I like cuz I know you’re dying to hear it…
/var is good for storing logs
/www or something like that for storing html and cgi scripts
/data for storing, you guessed it, data! Media like A/V, text, iso images, graphics, etc. /data should realisticly be symbolicly linked to something like /mnt/md0 where md0 is a RAID array with several hundred GB of storage space.
/video or ~video could be a symbolic link to /data/video
same goes for audio (mp3, ogg, wav subdirs, or genres), images, isos, docs (separate pdf, html, text subdirs, etc), games, etc.
/usr, /etc, /tmp, /mnt, /proc, /dev, etc. should remain unchanged unless you want to call /usr /app or something.
/usr/local doesn’t make any sense. Perhaps /home/username/local or /home/username/bin,tmp,var,sbin,doc, whatever
/doc would be good. No /usr/doc or whatever. Put all documentation in the same place so its easy to copy it between systems.
Then write the glue, a bunch of scripts to handle moving important data between systems automaticly when necessary.
For example you could have an icon in your Applications menu that execs a script that installs the app and launches. That way the system can be preinstalled with a minimal set of applications and dynamicly expand itself to support its users as required. This sharing of binaries could be done over a P2P to save bandwidth and disk space for all systems.
/data/doc and /data/share or a more organized version of /usr/share in /data. That way any systems on your net can share a portion of /data and share things like systems sounds, fonts, background images, etc. between themselves.
…between posting the message and seeing all three YOU’RE WRONG replies – the whole thing had gotten me looking at http://everything2.com for more info. But thanks anyway 😉
Oh wait no, I’m right! Sweet…
/srv makes sense, var is for variable data that almost always created and edited without user interaction (logs, save game data, …). htdocs/html directories, anonymous directories, and so on, clearly don’t belong in /var.
/media doesn’t make quite so much sense. SUSE have used /media (and /srv) for quite some time, however they leave /mnt completely empty. SUSE use /windows/* for MS-Windows partitions, /media/* for removable media and /data* for other partitions which aren’t part running system (e.g. partitions from other Linux distros). /media/* makes little sense without /windows/* and /data*, even with them I think it would be neater to put them all under /mnt.
~/etc sounds like a very good idea, I have seen some references to it on the FHS website, maybe they will implement it someday.
Hi again, I really don’t care about ~/.etc, ~/etc or ~/my_personal_configuration_goes_here, I can simlink to my needs, but _please_ don’t make use of both, that would really be a mess.
A good (but complex solution) for ~/.etc stuff would be to have files splitted into 3 categories:
– configuration files, ~/.etc
– cached files, ~/.var (for mozilla cache, thumbnails, …)
– other files, ~/.other_good_name (for mailboxes, irc logs, etc.), that is, like var but files one would like to keep.
Just my 2c