On a serious note, what I'd change about FreeBSD hier(7)

Polytropon freebsd at edvax.de
Wed May 13 14:29:09 UTC 2020

On Wed, 13 May 2020 05:51:26 -0600, @lbutlr wrote:
> On 12 May 2020, at 23:33, Manish Jain <bourne.identity at hotmail.com> wrote:
> > Perhaps you might like to remember another location : /opt
> > 
> > That is entirely unused in the default config in FreeBSD,
> > and I think /opt/bin makes a good location for the user's own software.
> User software goes in ~/bin.

Correct - that is "user-locally installed software", out of the
scope of system administration. In many cases, it's user scripts,
but can also be actual binary programs built from source by
the user.

> Admin user’s software that is used by the system goes in /usr/local/bin.

In my opinion, and following "man 7 hier" and the ideas and
concepts it tries to convey, /usr/local, being a subtree of
/usr, emphasizes that what is contained in there is managed
by the system, i. e., 3rd party software installed via pkg
or from source using the ports collection. This software is
typically installed by the system administrator as it does
require UID 0 permissions.

Additionally, /usr/local is "regulated" - it uses the same
layout as the base system, so there's /usr/local/bin with
the same purpose as /usr/bin, and similarly for lib/, share/,
include/ and so on. The manual page explains this.

So /usr/local emphasizes the fact that stuff located there
is tied to the system, and managed by the system (pkg).

> I see no need for /opt/bin, what would you put there?

The idea behind /opt is that is _out of reach_ of the OS-managed
package system. Here a system administrator (!) can add
programs and scripts that are not part of the ports collection,
but shall be available to all users (unlike his own set of
scripts, to be used by root only, which are in /root/bin).
User can make /opt/bin a part of their $PATH (or there is a
system-wide setting to do so). Software in /opt also has to
be updated and recompiled manually; pkg will not be there
to deal with them.

As /opt is not covered in system layout trees, it can be any
other non-assigned name, like /local or /apps or whatever
you wish.

Another concept is that if /opt is a separate filesystem or
partition, it can be mounted with -o noexec, so for example
during installation or updates, users cannot execute programs
that reside there.

There is no specific layout for /opt. The idea of /opt/bin
is for convenience and central application access. In many
cases, you'll find /opt/<name> for each additionally installed
software package, and what happens inside there is none of
the system's business - any program can decide on its own.
Linking the binary or launcher to /opt/bin is just convenient.

It is also possible to use /opt to install software that is
run by tools like wine, SimH, or Hercules (but managed outside
their local program directories in /usr/local or user directories
such as ~/.wine).

Programs executed by other programs, such as custom print
filters, can go to /opt/libexec. /opt/src can hold sources
for building "non-managed" programs.

That is of course only _one_ possible interpretation of how
to use /opt. The idea is to differentiate /opt as being totally
optional from /usr/local being dealt with by pkg, but _both_
are locations accessible by _all_ users.

Of course, it is technically possible to also maintain stuff
in /opt using pkg, but why should someone do that? ;-)

Please see my earlier reply on this topic for more description.

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list