23 Feb
2021
23 Feb
'21
6:29 p.m.
At Mon, 22 Feb 2021 20:31:49 -0700, Andrew Warkentin <andreww591(a)gmail.com> wrote:
Subject: Re: [TUHS] Abstractions
On 2/21/21, Steve Nickolas <usotsuki(a)buric.co> wrote:
Maybe there isn't any impetus to _create_ a separate /usr these days of
large software but even larger disks.
However I think there are at least two good reasons to _maintain_ a
separate /usr. At least for ostensibly POSIX and Unix compatible
systems, that is.
For one there's a huge amount of deeply embedded lore, human (finger and
brain) memory, actual code, documentation, and widespread practices that
use this separation and rely on it, effectively making it a requirement.
As Steve mentions above there's also the concept of knowing the minimum
requirements for bringing up a system capable of the most basic tasks.
Of course there's likely going to be some variance in what any given
person might define as "most basic tasks", but that's most a separate
issue. However I will give one example of why this might be a good
thing to know and preserved: it is highly useful for those creating
"embedded" systems, or application specific systems. They can start
with just the minimal root filesystem, and then know exactly what they
have to add in order to meet their application's requirements precisely.
(and the reasons for doing that can be much wider than many might assume)
Also the basic idea of having a root filesystem that contains just and
only what's necessary for the system to boot and run, and putting
everything else that makes the system usable to users into /usr, is also
still a worthwhile concept even just on its own.
The maintenance of an illusion of a separate /usr can of course be
easily done with a farm of symlinks, thus preserving any dependencies in
anyone's memory, documentation, or code.
However the reality of maintaining a separate minimal toolset for system
bring-up is that it cannot be reliably done without constant and
pervasive testing; and the very best (and perhaps only) way to achieve
this, especially in any smaller open-source project, is for everyone to
use it that way as much of the time as possible. I say this from
decades long experience of slowly moving systems to having 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
dependencies have crept in on something in /usr for basic booting. (and
that's even when I base my system on a platform that still tries hard to
maintain this separation of root and /usr!)
BTW, I think it was Sun that first did some of this merging of root and
/usr a very long time ago.
--
Greg A. Woods <gwoods(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
While I've been stuck regarding bringing up a kernel, C compiler and libc
all together, (keeping in mind my desire to avoid gcc and glibc for the
project) the conceptual distribution I've been working on for some time
uses more or less the same abstraction as the BSDs, with distinct /bin and
/sbin vs. /usr/bin and /usr/sbin as I personally believe it should be,
that the stuff in /bin should be enough to bring up and/or run diagnostics
on a system, and everything else go in /usr.
I don't see much of a point in maintaining the separation these days.
/bin and /usr/bin were originally separated because it wasn't possible
to fit everything on one disk, and (AFAIK) the separation was mostly
maintained after that to reduce the chance of filesystem corruption
rendering the system unbootable (which is much less of a problem
nowadays because of journalled and log-structured filesystems).