Date: Fri, 13 Sep 2019 05:32:54 +0000 From: John Howie <john@thehowies.com> To: Polytropon <freebsd@edvax.de> Cc: Jim Trigg <jtrigg@huiekin.org>, "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: A modest hier proposal Message-ID: <0B94A4D1-F767-4C1F-A1AA-DF37FCF1BEE3@thehowies.com> In-Reply-To: <20190913071606.00aa3d63.freebsd@edvax.de> References: <ff67e062-a559-388c-cf91-edd83a278232@huiekin.org>, <20190913071606.00aa3d63.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
I am all for merging /bin, /lib, /etc. with their /usr counterparts. The s=
eparation 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 =93original=94.=
That fact alone means we can and should adapt rather than burying ourselve=
s in pseudo-historical orthodoxy.
Sent from my iPhone
> On Sep 12, 2019, at 22:16, Polytropon <freebsd@edvax.de> wrote:
>=20
>> 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=20
>> get no support for merging the existing / and /usr trees to put all base=
=20
>> items in / (/bin, /etc, /lib, /libexec, /share, /sbin), [...]
>=20
> 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.
>=20
>=20
>=20
>> [...] I'm suggesting=20
>> the following:
>>=20
>> /usr/local -> /pkg
>=20
>=20
>> Explicitly define /opt for third-party software that is not in=20
>> packages/ports.
>=20
> 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.,
>=20
> /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
>=20
> Programs are encouraged to use those directories. This is a recommendatio=
n
> not always followed... ;-)
>=20
> 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".
>=20
> 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.
>=20
>=20
>=20
>> Explicitly define /local for locally developed software that has not=20
>> been packaged as a port/package.
>=20
> That's what people tend to use /opt for, as it does basically let
> them do what they want - no rules. :-)
>=20
> 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.
>=20
>=20
>=20
>> 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=
=20
>> in ports/packages
>> /local {bin,etc,lib,libexec,share,sbin} - locally developed software=20
>> that has not yet been formalized into a port/package (with symlink from=
=20
>> /usr/local?)
>=20
> 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.
>=20
> 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.
>=20
> 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...
>=20
> 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.
>=20
>=20
>=20
>=20
> --=20
> Polytropon
> Magdeburg, Germany
> Happy FreeBSD user since 4.0
> Andra moi ennepe, Mousa, ...
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.o=
rg"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0B94A4D1-F767-4C1F-A1AA-DF37FCF1BEE3>