From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9964 invoked from network); 23 Feb 2021 18:28:44 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 23 Feb 2021 18:28:44 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 48FD89C81C; Wed, 24 Feb 2021 04:28:39 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 438B89C6D0; Wed, 24 Feb 2021 04:28:12 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=tnetconsulting.net header.i=@tnetconsulting.net header.b="OIAFKYn4"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 96EB29C6D0; Wed, 24 Feb 2021 04:28:09 +1000 (AEST) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [45.33.28.24]) by minnie.tuhs.org (Postfix) with ESMTPS id D2A369C6CE for ; Wed, 24 Feb 2021 04:28:07 +1000 (AEST) Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id 11NIS6cE010173 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 23 Feb 2021 12:28:06 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2019; t=1614104887; bh=xBfMKVzJjnhqyUvcELxd88H8JphrTwLVlN7u0fWl8VM=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=OIAFKYn4dCcoG+wIL3wUPlxE4tmzqKplFgqjE6v2eVqG+y09Tq8QISuGL9+fS8FTz fSL/G8RhsaEkehm0kfUVP7Kx/oWXunux2FUavGBFfkRK1pH2/nLdo5T669lFosx67o CK4Uo+C041uKVZRFrdkoTGsmLNTn7NPYpFQDiq10= To: tuhs@minnie.tuhs.org References: Organization: TNet Consulting Message-ID: <78fede43-bf9b-5a56-5e59-e6ee5a0ee23d@spamtrap.tnetconsulting.net> Date: Tue, 23 Feb 2021 11:28:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000102060307080600010601" Subject: Re: [TUHS] /usr separation X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Grant Taylor via TUHS Reply-To: Grant Taylor Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a cryptographically signed message in MIME format. --------------ms000102060307080600010601 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2/23/21 10:29 AM, Greg A. Woods wrote: > Maybe there isn't any impetus to _create_ a separate /usr these days=20 > of large software but even larger disks. I'm undecided. Part of me likes the / (root) and /usr split. But=20 another part of me questions /if/ and (if so) /why/ it is (still) /needed= /. > However I think there are at least two good reasons to _maintain_=20 > a separate /usr. At least for ostensibly POSIX and Unix compatible=20 > systems, that is. Does /usr actually /need/ to be a /separate/ file system? Or would a=20 wholesale link from /usr to / (root) suffice? Or perhaps a collection=20 of sym-links from /usr/ to / suffice? > For one there's a huge amount of deeply embedded lore, human=20 > (finger and brain) memory, actual code, documentation, and widespread=20 > practices that use this separation and rely on it, effectively making=20 > it a requirement. Are they relying on the /separation/ of separate file systems? Or are=20 they simply relying on wrote memory for the path? Ergo sym-links could=20 fulfill the perceived need? > As Steve mentions above there's also the concept of knowing the=20 > minimum requirements for bringing up a system capable of the most=20 > basic tasks. The pat response to this in the Linux community is "That's what the=20 initrd / initramfs is for!" What that fails to take into account is if the system actually uses an=20 initrd / initramfs or not. Many of the systems I maintain do /not/ use=20 an initrd / initramfs. Thus the systems have /some/ actual /need/ to be = able to bring up a minimal system to repair file system problems. Even=20 if the so called problem is simply that the extent file system needs an=20 fsck with human interaction (time since last check and / or maximum=20 number of mounts). If you do use an initrd / initramfs, then you can reasonably safely lump = everything* in the / (root) file system. */boot still tends to be it's own file system on Linux, mostly because=20 that's where the initrd / initramfs image live which contain drivers for = more fancy things (software RAID, LVM, ZFS, SAN, etc.) which are needed=20 to bring up / (root). > Of course there's likely going to be some variance in what any=20 > given person might define as "most basic tasks", but that's most a=20 > separate issue. Agreed. However, I posit that "most basic tasks" be what is necessary to=20 transition from single user mode to multi-user mode. Including any and=20 all utilities required to fix file systems, work with logical volumes,=20 SAN, etc. > However I will give one example of why this might be a good thing to=20 > know and preserved: it is highly useful for those creating "embedded" = > systems, or application specific systems. They can start with just the= =20 > minimal root filesystem, and then know exactly what they have to add=20 > in order to meet their application's requirements precisely. (and the = > reasons for doing that can be much wider than many might assume) Please elaborate on what that has to do with the / (root) vs /usr split? I feel like you're differentiating between a minimal install vs a=20 kitchen sink install. Which seems to me to be independent of how the=20 underlying file system(s) is (are) arranged. > Also the basic idea of having a root filesystem that contains just=20 > and only what's necessary for the system to boot and run, and putting=20 > everything else that makes the system usable to users into /usr,=20 > is also still a worthwhile concept even just on its own. Many in the Linux community think this is the job of the initrd /=20 initramfs. I personally believe that this is the job of the / (root)=20 file system. Aside: In the event that /usr is on the / (root) file system, then the=20 system should still be able to come up as if /usr didn't exist b/c it=20 had been renamed or was on a separate file system. > The maintenance of an illusion of a separate /usr can of course be=20 > easily done with a farm of symlinks, thus preserving any dependencies=20 > in anyone's memory, documentation, or code. Agreed. With things like bind mounts, we don't even need to use=20 sym-links. }:-) Though, one potential danger is that people see duplication between=20 /bin/ and /usr/bin/ and decide to remove one of them. Doing=20 so will ultimately remove both and cause someone to have a not good day. Aside: Perhaps these not good days are not something to be avoided, but = instead something to be treated as a learning opportunity. Much like=20 young kids need to learn that fire is hot for themselves. > However the reality of maintaining a separate minimal toolset for=20 > system bring-up is that it cannot be reliably done without constant=20 > and pervasive testing; and the very best (and perhaps only) way to=20 > achieve this, especially in any smaller open-source project, is for=20 > everyone to use it that way as much of the time as possible. I say=20 > this from decades long experience of slowly moving systems to having=20 > just one partition for both root and /usr and then on occasion testing = > with separate root and /usr, and every time I do this testing I find=20 > dependencies have crept in on something in /usr for basic booting.=20 > (and that's even when I base my system on a platform that still tries=20 > hard to maintain this separation of root and /usr!) I have a different conundrum regarding */bin. Why do I need nine=20 different (s)bin directories in my path? I -- possibly naively --=20 believe that we have the technology to have all commands in /one/=20 directory, namely /bin. Quickly after that thought, I realize that I want different things in my = path than other people do. So I end up with custom /bin directories.=20 Which usually ends up with sym-links that reference variables or custom=20 mounts (possibly via auto-mount applying some logic). > BTW, I think it was Sun that first did some of this merging of root=20 > and /usr a very long time ago. Agreed. Though I'm far from authoritative. --=20 Grant. . . . unix || die --------------ms000102060307080600010601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzkwggUhMIIECaADAgECAhA/wgXwQl9mDHSg5enGHBeSMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTIwMTExNjAwMDAw MFoXDTIxMTExNjIzNTk1OVowKzEpMCcGCSqGSIb3DQEJARYaZ3RheWxvckB0bmV0Y29uc3Vs dGluZy5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM6cGNMlSUFPM3zVw+ VgSslz2QRtMj+FerQ0DpmgbhUzqm5hMRe0hMA2OBf41HDAeOV0RKcLx2+HozHlyQST2xagOX xiv91aEXezh8bEBfnOI564Ej/JfusomfoM7ByVXcLp3K3fOssHos6IXiAD6WT+jcRs7Cg+Gl bYyoDLDLXw4i/N+YRcp3JrwT+4g/i//wAea1qTEd+ZnfcqtvCHaiJrr16xEpzuraLcmH5qtN /c+5kkRN3zpJvQvPX7fMBdxiSjb/cb070DC1RIO+THkhQqJ4bxHhrwcvC5RME0iwnSo52a/i FSNzciw/SM37F5tMTjDs+F6iUT85K2IWyGkpAgMBAAGjggHTMIIBzzAfBgNVHSMEGDAWgBQJ wPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU9SQ1EWwdWU0yBrPcbiR81rwNThUwDgYD VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUF BwMCMEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8v c2VjdGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5j b20vU2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmww gYoGCCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggr BgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wJQYDVR0RBB4wHIEaZ3RheWxvckB0 bmV0Y29uc3VsdGluZy5uZXQwDQYJKoZIhvcNAQELBQADggEBABWLZrz0NricNKP3jS03B7lH KNfBetFHWlaarCghIjhyA3yoXizPMP1wsY+ARMT22BKNVmLlP1CvDoLuEQbThvT5hRa7HPc2 2yVX6MkgSZByW2xrkhKGAIdtl+mELX27GZM+xe+k84OO1hA0Egyha2gg0UWlAiTGkIYjNLg0 6zg1QP7Bj4P/19hbi8Z9FFu38CztkgKZPSKMV3kPxZopa/mOWOQXxHcs03Ph/qnwj5HfkeWI WE7TARmmU7w8AoxEONC1tB6bsdX3M+4YVbgwgiihhiVGflHfGI4bgKkuN4sqesRnX8C9mvv5 o7dYJe4kKuv0ZeIj8x1Hh2PGvn7GuRgwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZP MA0GCSqGSIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEU MBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEu MCwGA1UEAxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODEx MDIwMDAwMDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExp bWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB /975Rrno1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMa XqcESJuK8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpG EGFUUd0kN+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YB rf24k5Ee1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0 PewDch/8kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0j BBgwFoAUU3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J 4K0AMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/ aHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRo b3JpdHkuY3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2Vy dHJ1c3QuY29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRw Oi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVt MnFojADdF9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1G wmIPgou74TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrN xP6Ys7U0sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ 2hWQNDkJJIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb5 33JlfeUHxvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7 crItNkZeroXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq 4hOf/Z85F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0 ZSLwrymUE0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR 87myx5uYdBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5Zgt wCLXgAIe5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhA/wgXwQl9mDHSg5enGHBeSMA0GCWCGSAFlAwQCAQUAoIIC VzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMjMxODI4 MTNaMC8GCSqGSIb3DQEJBDEiBCB5CszAF61k/i8RWWmpLkeZU3UwLw8jU6c1ihSwzrKLEjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG8BgkrBgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRl ZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECED/CBfBCX2YMdKDl6cYcF5Iwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGW MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNB IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhA/wgXwQl9mDHSg 5enGHBeSMA0GCSqGSIb3DQEBAQUABIIBACS2V5F3z4zTPweWOyhxgebcIWmPDjpHxKbpItuD xZ1gTMrbxTT+bwpaP/5g1IusINLCS3I2Dqqs3mX2MSV9qIF+TIR5JYhfFroeqogfFdGnDUr3 1PSvNTkNEytnYsAQ7eM4wxYCnQSnj1rdLty/coeNqX6HRQD0429ArFdSaD/ojs6n57ApQsI1 A0wuXZvfwWMBrZE3hRF6/RHphA1LgM3dCcDOq85BESVZ/xjqSc5t5dWxJJhW93Ia+cOxJL9U 48ZC+zQTu+OHliSfRjRBUiQ+ytnvvfIEhaEhW7GDEBAu7ImNiCl1i/eCUbWN+KKJ9I3BJ+mc UqF+Y3JpUMWu4Z4AAAAAAAA= --------------ms000102060307080600010601--