While both are designed to contain files not belonging to the operating system, /opt and /usr/local are not intended to contain the same set of files.
/usr/local is a place to install files built by the administrator, typically by using the make command (e.g., ./configure; make; make install). The idea is to avoid clashes with files that are part of the operating system, which would either be overwritten or overwrite the local ones otherwise (e.g., /usr/bin/foo is part of the OS while /usr/local/bin/foo is a local alternative).
All files under /usr are shareable between OS instances, although this is rarely done with Linux. This is a part where the FHS is slightly self-contradictory, as /usr is defined to be read-only, but /usr/local/bin needs to be read-write for local installation of software to succeed. The SVR4 file system standard, which was the FHS' main source of inspiration, is recommending to avoid /usr/local and use /opt/local instead to overcome this issue.
/usr/local is a legacy from the original BSD. At that time, the source code of /usr/bin OS commands were in /usr/src/bin and /usr/src/usr.bin, while the source of locally developed commands was in /usr/local/src, and their binaries in /usr/local/bin. There was no notion of packaging (outside tarballs).
On the other hand, /opt is a directory for installing unbundled packages (i.e. packages not part of the Operating System distribution, but provided by an independent source), each one in its own subdirectory. They are already built whole packages provided by an independent third party software distributor. Unlike /usr/local stuff, these packages follow the directory conventions (or at least they should). For example, someapp would be installed in /opt/someapp, with one of its command being /opt/someapp/bin/foo, its configuration file would be in /etc/opt/someapp/foo.conf, and its log files in /var/opt/someapp/logs/foo.access.
As Noufal Ibrahim says, I think this is a Solaris convention.
IIRC, /export/home is used on the server where the actual files live, and /home is where the other servers mount it.
What does mount | grep home say? I'm guessing that /export/home has a file system type of UFS, and /home has a type of NFS?
/etc/fstab may also have some clues.
Best Answer
Well, there are various considerations.
You don't put anything in
/root. This is for uid 0 and systems administration only; it's often not even traversable by non-root users.Install under
/home/<username>if you're an unprivileged user on the machine and you, personally, need to be able to use the software you're installing. If you're the admin, you usually shouldn't mess around with users' homedirs.Install under
/usr/localfor normal software packages which, for whatever reason, you're installing from source locally (instead of installing through the package manager). This is usually where things get put if you run the standard autoconf./configure && make && make installincantation from a source tarball. I also put little utilities I've developed locally under/usr/local/bin, if I want them to be universally available.Install under
/optfor third-party pre-bundled software (a good example of this is Calibre, if you use their binary installer). This makes a separate directory under/optfor every package you install, and that directory has all the requisites for the package (as opposed to/usror/usr/local, where binaries for all the packages are underbin, libraries for all the packages are underlib, &c.). In general, if you're writing or packaging software yourself that needs a lot of different components, it might be good to put it here, but it's probably suboptimal to try to install someone else's package there, if it's not their recommendation. That can be a matter of opinion, though.If you're creating a package that users or administrators will install manually, you want either
/optor/usr/local. If you're installing someone else's package, follow their recommendation. If you're packaging something for a distribution (which you probably aren't), use/usr.