23 Feb
2021
23 Feb
'21
4:31 a.m.
On 2/21/21, Steve Nickolas <usotsuki(a)buric.co> 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).
Under UX/RT, the OS I'm writing, all commands (administrative or
otherwise) will appear to be in /bin, and all daemons will appear to
be in /sbin (with corresponding symlinks in /usr). The separation into
administrative and regular commands will be meaningless since the
traditional root/non-root security model will be completely eliminated
in favor of role-based access control. The / and /usr separation will
be useless since it will be impossible to have a separate /usr
partition (the contents of the root will be dynamically bound from a
collection of individual package directories, and won't correspond to
the root of the system volume).