24 Feb
2021
24 Feb
'21
4:12 a.m.
On 2/23/21, Greg A. Woods <woods(a)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(a)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(a)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.