As an aside, it's really interesting that the word 'Linux' is mentioned only once on this page - and only after the kFreeBSD kernel.
nginx on ubuntu now uses /usr/share/nginx/www
i wonder how long these conventions will continue to be all over the place.
/srv contains site-specific data which is served by this
system.
Unfortunately, /srv/ is often ignored. Good move by Debian to make this change, and hopefully this gets the ball rolling for other distros.
/srv is a bit questionable to me. Basically it's another /var. I always used directories like /var/local and /var/share (sambd and nfs shares). However, I am understanding the FHS crew wants to freeze the /var filesystem because it was getting too crazy with all kinds of stuff being placed under /var, and the likelihood of conflicts was getting high.
But I think /srv actually makes more sense as /var is often on separate disks because /var/lib/ gets very IO heavy.
Especially some commercial and proprietary software that runs on Windows, HP-UX, SCO, AIX, Solaris and Linux tends to go the "easy way" of packaging and just put stuff in one place on every system.
This is merely a convention, not set into the 2.3 standard apart from the naming 'tertiary hierarchy' otherwise implying this, but it's nonetheless a widespread enough convention — notably in use by every single configure/make/make install (and more) source distribution out there, whose default PREFIX is /usr/local — that we can expect it to be standard behavior.
I also prefer having packages with their own hierarchies under /opt, rather than /usr/local/<package> -- in general stuff under /usr/local should put their binaries in /usr/local/bin -- their manpages under /usr/local/share/man, headers and libraries in the corresponding places -- so that I don't have to mess with my PATH settings to be able to run a command, look up a man page or link against a library.
Sometimes software isn't packaged for use on a posix-like system -- and then I might have to do some dancing to get it to work -- I usually prefer having such programs under /opt/<program-version>.
I do have another folder under local: /usr/local/xstow -- so I can easily compile packages and manage different versions under /usr/local/xstow/package-x.y.z.
Most vendor supplied software is by tradition installed in /opt, for which we should be forever thankful because most software vendor wouldn't recognize a properly packaged piece of software even if it jumped up and bit them in their arse.
Oracle was in the early days installed in /u01 with data- and log-files spread out over separate disks with mountpoints normally named /u02,/u03 and so forth. It isn't uncommon that this naming convention still partially is used on oracle installations.
Today oracle published a standard called Optimal Flexible Architecture (OFA) where all oracle products should be installed under a common top-level directory.
The oracle universal installer isn't as horrible as it used to be but it isn't a well behaved rpm/dep installation either, at least it claims to have heard about LSB-directory structure even if it doesn't follow it very well.
Similarly for /srv
Remember: the filesystem hierarchy and your underlying storage don't have to correspond.
There are other tricks which can be accomplished by union mounts or similar foolishness.
At least they didn't locate it on the root directory. Mount points should never be on root. See the sources for stat() for the main reason why not.
/boot is typically located on the same disk as root, so that should be ok. /srv and /home, however, would be problematic root mounts. You can use automount to fix /home but /srv should be mounted under /usr or /var.
Mounting NFS or busy disks on the root dir is not a good idea on any server where filesystem i/o performance is an issue.