From owner-freebsd-questions@freebsd.org Fri Sep 13 05:34:19 2019 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 57BFFE5E14 for ; Fri, 13 Sep 2019 05:34:19 +0000 (UTC) (envelope-from john@thehowies.com) Received: from remote.thehowies.com (remote.thehowies.com [50.197.91.218]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "remote.thehowies.com", Issuer "USERTrust RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46V47s6cH3z49Z0 for ; Fri, 13 Sep 2019 05:34:17 +0000 (UTC) (envelope-from john@thehowies.com) Received: from PRIMARY.thehowies.local ([fe80::6437:d031:7477:6451]) by PRIMARY.thehowies.local ([fe80::6437:d031:7477:6451%10]) with mapi id 14.03.0439.000; Thu, 12 Sep 2019 22:32:55 -0700 From: John Howie To: Polytropon CC: Jim Trigg , "freebsd-questions@freebsd.org" Subject: Re: A modest hier proposal Thread-Topic: A modest hier proposal Thread-Index: AQHVaeZ4JPAaUNVk00GKGtZ6q2IvsacphjwA//+PVic= Date: Fri, 13 Sep 2019 05:32:54 +0000 Message-ID: <0B94A4D1-F767-4C1F-A1AA-DF37FCF1BEE3@thehowies.com> References: , <20190913071606.00aa3d63.freebsd@edvax.de> In-Reply-To: <20190913071606.00aa3d63.freebsd@edvax.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Queue-Id: 46V47s6cH3z49Z0 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of john@thehowies.com has no SPF policy when checking 50.197.91.218) smtp.mailfrom=john@thehowies.com X-Spamd-Result: default: False [3.24 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[thehowies.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.83)[0.832,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.95)[0.954,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:50.128.0.0/9, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.56)[ipnet: 50.128.0.0/9(3.85), asn: 7922(-1.01), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2019 05:34:19 -0000 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 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/, 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 / and /usr/ 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"