5 ms·
/srv will continue to be ignored just as /opt and other one-offs are ignored. Reason being that they duplicate existing functionality, in this case under /var,
by pconf 13y ago
/srv will continue to be ignored just as /opt and other one-offs are ignored. Reason being that they duplicate existing functionality, in this case under /var, /usr, or /usr/local. What /srv/ really stands for is NIH.
- moe 13y ago/opt is justified. /srv is indeed NIH (redundant with /var/whatever).
- jmomo 13y ago/opt is basically for 3rd parties to install software, because they can't be trusted to behave and integrate with the regular filesystem. The last thing you want is Oracle farking around with anything under /usr or /var, because they will fuck up your entire OS for their benefit alone. That is why /opt exists, in my understanding. /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.
- ra 13y agoYeah, they could have gone down the /var/srv direction, which would have been OK. But I think /srv actually makes more sense as /var is often on separate disks because /var/lib/ gets very IO heavy.
- gaius 13y agoIn the days of SAN, all assumptions about separate filesystems should be revisited. They might be, in fact probably are, on the same spindles.
- FooBarWidget 13y agoBecause Oracle cannot install to /usr/local/oracle? I don't see the value of /opt.
- claudius 13y ago/usr/local is meant to replicate /usr in the way that binaries go into /usr/local/bin, libraries into /usr/local/lib etc., but for software that isn’t managed by the package manager – at least that’s what it is used for nowadays. So a well-behaving software would happily go into /usr/local, whereas the ugly software things that want their own folder somewhere better go into /opt.
- FooBarWidget 13y agoAnd why is that distinction important? It seems a fairly arbitrary rule to me. What's the problem with dropping stuff in /usr/local/foo?
- e12e 13y agoIt's not set in stone. 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. http://xstow.sourceforge.net/ http://xstow.sourceforge.net/
- buster 13y agoBecause, maybe, but only maybe, there might be software that is not split up into lib, bin, doc directories and that doesn't log into /var/log?! There actually is quite some software like that and sometimes it even has a technical reason. 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.
- nuclear_eclipse 13y agoKeeping all user/site data under /srv makes it superbly easy to back up everything on a server from a single base directory.
- deleted 13y ago[deleted]
- scott_karana 13y agoYour wildcard "whatever" says it all.