A modest hier proposal

John Howie john at thehowies.com
Fri Sep 13 05:34:19 UTC 2019

I am all for merging /bin,  /lib, /etc. with their /usr counterparts. The separation was more about disk speeds, not disk size. You put the most-used executables and files on / which was your fastest disk, and everything else on other, slower disks.

I do not even recall when  /lib, /libexec, etc. made an appearance in *BSD, and /sbin is relatively-speaking new, too, but all are not “original”. That fact alone means we can and should adapt rather than burying ourselves in pseudo-historical orthodoxy.

Sent from my iPhone

> On Sep 12, 2019, at 22:16, Polytropon <freebsd at edvax.de> wrote:
>> On Thu, 12 Sep 2019 23:50:40 -0400, Jim Trigg wrote:
>> I recommend we reframe the directory structure. Since I'm sure I will 
>> get no support for merging the existing / and /usr trees to put all base 
>> items in / (/bin, /etc, /lib, /libexec, /share, /sbin), [...]
> The structure documented in "man 7 hier" covers both historical aspects
> and modern requirements. The status quo is a consensus of rules and
> considerations, as is the naming of things.
>> [...] I'm suggesting 
>> the following:
>> /usr/local -> /pkg
>> Explicitly define /opt for third-party software that is not in 
>> packages/ports.
> Well, /opt is a Linuxism, and historically a Solarism, Solarisism,
> which is explicitely not covered by FreeBSD definitions. Some users
> use it to manage "non-ports 3rd party software" totally independently
> from the rest of the system. Sometimes, /opt/bin exists and is part
> of $PATH, and contains "call wrappers" for /opt/<something>, as there
> is no structure defined for /opt - unlike for /usr/local, which more
> or less replicates the top level structire of the OS, to be used by
> 3rd party software installed from ports, e. g.,
>    /usr/bin    /usr/local/bin        -> program executables
>    /usr/lib    /usr/local/lib        -> libraries
>    /usr/libexec    /usr/local/libexec    -> daemons
>    /usr/share    /usr/local/share    -> shared objects, data
>    /etc        /usr/local/etc        -> configuration
> Programs are encouraged to use those directories. This is a recommendation
> not always followed... ;-)
> The difference between /<something> and /usr/<something> is again a
> historical thing: Things that are required to get single-user mode up
> and running, and things that are required for everything that leads
> to more advanced modes, like multi-user, or graphical. Also partitioning
> (i. e., having parts of the OS on different partitions that were
> actually different disks) originates from a time where disk capacity
> was too low to hold the full OS, so you'd have / on one disk to get
> the OS up and running, and /usr/local on a different disk for all the
> 3rd party software the system runs - so the OS could get into a fully
> functional state without /usr/local being present. You could even
> swap different /usr/local disks (to revert to an older state or to
> experimentally try new software). Of course, disk size is not a
> concern today - as long as you don't enter the embedded space where
> you even want to have things separated by "is read-only" and "can
> be writte to", or "can be slow, is used only once" and "needs to
> be faster, is used all the time".
> Still using partitions (no matter of using ZFS or UFS) can have
> advantages, like preventing /tmp from filling the whole disk from
> some runaway process, or setting specific flags like noexec on a
> partition for user data like /home where you explicitely want to
> prevent the user from executing their own stuff.
>> Explicitly define /local for locally developed software that has not 
>> been packaged as a port/package.
> That's what people tend to use /opt for, as it does basically let
> them do what they want - no rules. :-)
> Of course, it's also possible to use "user-locally developed" software
> from inside a user's home directory, where ~/bin is often present, and
> ~/.config is used by some programs.
>> This leaves us with five areas:
>> /{bin,etc,lib,libexec,share,sbin} - base software
>> /usr/{bin,etc,lib,libexec,share,sbin} - base software
>> /pkg/{bin,etc,lib,libexec,share,sbin} - ports/packages
>> /opt/{bin,etc,lib,libexec,share,sbin} - third-party software that is not 
>> in ports/packages
>> /local {bin,etc,lib,libexec,share,sbin} - locally developed software 
>> that has not yet been formalized into a port/package (with symlink from 
>> /usr/local?)
> Interesting approach, but I think this is not going to happen. I know
> certain Linux distributions tried to suggest a unified layout for to
> be shared by all Linusi, but that didn't come true, likewise /Programs,
> /Data, /ConfigurationAndSettings, and so on.
> The general rule is: Everything under / belongs to the OS. 3rd party
> software that is managed by pkg is entirely in /usr/local, and if
> there should be anything else, it can go to /opt. /home is for users'
> stuff, site rules might apply.
> Do you remember PC-BSD (now TrueOS) and their packaging system? They
> did something comparable: Every program gets its own directory subtree
> with all stuff belonging to that program (plus its dependencies) in
> only that directory subtree, with a "caller script" in a directory
> that is in $PATH? I don't know if they still do that...
> In my opinion, things will stay as they currently are - not entirely
> perfect, but understandable and predictable as soon as you have
> successfully understood the rules and considerations.
> -- 
> Polytropon
> Magdeburg, Germany
> Happy FreeBSD user since 4.0
> Andra moi ennepe, Mousa, ...
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

More information about the freebsd-questions mailing list