At Mon, 22 Feb 2021 20:31:49 -0700, Andrew Warkentin wrote: Subject: Re: [TUHS] Abstractions > > On 2/21/21, Steve Nickolas wrote: > > > > 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). 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms