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.
/usr/local is usually for applications built from source. i.e. I install most of my packages using something like apt, but if I download a newer version of something or a piece of software not part of my distribution, I would build it from source and put everything into the `/usr/local' hierarchy.
This allows for separation from the rest of the distribution.
If you're developing a piece of software for others, you should design it so that it can be installed anywhere people want, but it should default to the regular FHS specified system directories when they specify the prefix to be /usr (/etc, /usr/bin, etc.)
i.e. /usr/local is for your personal use, it shouldn't be the only place to install your software.
Have a good read of the FHS, and use the standard Linux tools to allow your source to be built and installed anywhere so that package builders for the various distributions can configure them as required for their distribution, and users can put it into /usr/local if they desire or the regular system directories if they wish.
Best Answer
FHSv2.3 was released ten years ago. Some things have changed since then (including the introduction of/run1). About three years ago, the Linux Foundation decided to update the standard and invited all interested parties to participate.You can view the v. 3.0 drafts here and the section that describes
/runhere.The distinction between
/mediaand/mntis pretty clear in theFHS(see Purpose and Rationale), so I won't go over it again. Same for the purpose of/run- see links.The Gnome story is yet another thing. Gnome uses underneath an application called
udisks(replaced later byudisks2) to automount drives/devices. For quite a long time,udisksdefault mounts were under/media. In 2012 the devs decide to move the mounts to/run/media(i.e. a private directory). So the different behaviour you're experiencing there is caused by the different versions ofudisksthat each DE is using.1: see
What's this /run directory doing on my system and where does it come from ?
What is this new /run filesystem ?