Re: [TUHS] /usr separation (was: Abstractions)

[Andrew Warkentin <andreww591@gmail.com>]

On 2/23/21, Greg A. Woods <woods@robohack.ca> wrote:
>
> 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.
>

That is only a justification for keeping the /usr hierarchy around
(and using symlinks/binding to make stuff appear in both places), not
for arbitrarily separating programs and libraries between the two.

>
> 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!)
>

With a system-wide package manger a set of basic packages can be
maintained without having an arbitrary separation into root and usr.

The reference distribution of UX/RT will have several nested sets of
packages rather than a separation of binaries between root and usr.
The smallest will be what is included in the supervisor image (the
equivalent of a kernel image and initramfs combined into one), which
will be what is required to mount the system volume. Above that will
be the minimal system, which will be the set of packages required to
boot to a multi-user login. All of this will be in the base system
repository, along with a few other optional groups of packages
(including a full desktop
environment). Most optional third-party application packages will be
in a separate repository (like ports or pkgsrc under BSD, but using
the same package manager as the base system and available by default
without any special configuration).

On 2/23/21, Theodore Ts'o <tytso@mit.edu> wrote:
>
> /boot needs to exist due to limitations to the firmware and/or boot
> loader being used.  If the boot loader is using the legacy PC Bios
> interfaces to read the kernel and initial ramdisk/file system, then
> those files need to be in a low-numbered LBA disk space, due to legacy
> BIOS/firmware limitations.  It could also be a concern if you are
> using some exotic file system (say, ZFS), and the bootloader doesn't
> support that file system due to copyright licensing incompatibilities,
> or the boot loader just not supporting that bleeding-edge file system.
> In that case, you might have to keep /boot as an ext4 file system.
>

The BIOS addressing limitations only happen with CHS-only BIOSes,
which haven't really been a thing since the mid-to-late 90s. The only
reason to have a separate /boot partition for anything newer than that
is because of bootloader limitations.


On 2/23/21, Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
>
> I have a different conundrum regarding */bin.  Why do I need nine
> different (s)bin directories in my path?  I -- possibly naively --
> believe that we have the technology to have all commands in /one/
> 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.
> Which usually ends up with sym-links that reference variables or custom
> mounts (possibly via auto-mount applying some logic).
>

UX/RT will solve the issue of different sets of programs in the path
in different user or application contexts with per-process and
per-user namespaces (since fine-grained security will be deeply
integrated into the system and neither on-disk device files nor setuid
binaries will exist, there shouldn't be any security concerns with
letting regular users bind and mount stuff for themselves). $PATH will
just be set to "/bin" in the vast majority of cases.