Hacker News Reader

Comment by jmomo | Hacker News Reader

/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.

View on HN

Yeah, 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.

In the days of SAN, all assumptions about separate filesystems should be revisited. They might be, in fact probably are, on the same spindles.

Because Oracle cannot install to /usr/local/oracle? I don't see the value of /opt.

Because, 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.

And how does your point lead to the conclusion that installing such third-party software to /usr/local/whatever is a bad idea? I can just run 'ls /usr/local' to see a list of non-conforming software.

/usr/local is the tertiary hierarchy per the FHS, by this naming, there should be no whatever there other than bin/lib/shared/... just like on the primary and secondary hierarchies, whereas /opt is the wild wild west, often organised by software package (/opt/android-sdk), even with side by side versions (/opt/ree-2012.02), or by vendor (e.g /opt/oracle/java-7-sdk).

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 didn't say it's a bad idea, i said it's a matter of fact that software exists that runs in /opt/ and that sometimes there are reasons to do so. For example, a particular usecase is to have a specific mountpoint that holds shared binary and configuration in a cluster environment that can't be mixed with native applications and configuration files. Also sometimes you don't have the user rights to install in /usr or policy forbids to install 3rd party software in /usr. /opt is the usual way to go then.

/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.

And why is that distinction important? It seems a fairly arbitrary rule to me. What's the problem with dropping stuff in /usr/local/foo?

It'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/

/opt is a tradition inherited from older commercial unixes like SCO, AT-T et al. Made popular in the later days mainly by solaris 2 heavy usage of /opt.

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.

You can effect pretty much the same thing by symlinking /opt to /usr/local/opt/ Which is how I manage my systems.

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.

IIRC Unix systems were using "/opt" way before Linux was using "/usr/local". Cue the XKCD comic on competing standards: http://xkcd.com/927/

Reply on news.ycombinator.com