On 30/04/2015 15:58, Joerg Reisenweber wrote:
> I beg to differ on that, to me it seems it has all the sound rationale it
> needs, to for example understand why /bin should have commands that are needed
> during early boot, before /usr gets mounted.
>
> Thus FHS is not only a summary of current practice but also a guide to
> understand why that practice got adopted, what been the rationale, and what
> are the impacts when you deliberately ignore and deviate from such practice

As Didier says, FHS is mostly an officialization of historical practices -
with a little bit added about current practices. It addresses some problems
correctly, addresses other problems incorrectly (that's what you get when
you try to cram modern uses into a historical frame that's ill-adapted to
them), and ignores yet other problems completely.

Some of the original design decisions for the Unix directory structure,
that you still find in the FHS today, never made sense. Most of them made
sense at the time, but are obsoleted by today's needs. And some of them
still make sense today.

Here are a few examples:

- Never made sense: /var/mail. User mailboxes in a separate location, shared
between all users, are a horrible design. User mailboxes should reside in
users' home directory, it's the only sensible choice - for instance, it makes
quota management natural. Modern MTAs all deliver mail to mailboxes in the
user's home directory, and /var/mail should be relegated to the museum of
horrors, not be officialized in
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARMAILUSERMAILBOXFILES
with a weak-willed "(optional)" instead of the necessary "(for the sake of
all that's holy, NEVER FUCKING USE THIS)"

- Made sense at the time, doesn't make sense today: the separation between
administrator commands (/sbin, /usr/sbin) and user commands (/bin, /usr/bin).
Back then, filesystems were slow and scaled badly, caches were small, and it
was costly (time-wise for lookups) to have too many binaries in a single
location. Segregating admin-only binaries in a separate location avoided
clogging /bin and /usr/bin, and was a simple solution to gain a factor of 2
or so, which apparently was enough. There certainly were other reasons for
that choice, but this is the only one that stands examination.

Today, we have filesystems that can instantly lookup an entry in a directory
that has a million of entries. There's no more reason to separate /sbin from
/bin, except historical practice. /sbin/route is not inherently better than
/bin/route; we are just used to /sbin/route and inertia does the rest - but
it would actually be *simpler* to just move everything to /bin and /usr/bin
and be rid of /sbin and /usr/sbin altogether. It would also shorten PATHs,
which would be a definite blessing on some systems.

What if we don't want users to run /bin/route ? Well, system calls is
where Unix security is at. route will make system calls that non-root
users cannot make, and that will fail, and report EPERM errors. There's no
reason to forbid a user to run "route", it just won't work. But if we
absolutely want to enforce the interdiction, it's possible to set 0700 rights
at installation, so that non-root users can't run the binary. (Note that
binaries in /sbin usually don't do that, and non-root users can run them.)

- Made sense at the time, and still does today: the separation between /
and /usr.
/ was a base system that was guaranteed to boot and make a console usable.
/usr was the big, full-fledged system. In some installations, /usr was a
NFS mount. It was a perfectly reasonable way of setting up a machine.

Today, the reasons for keeping the separation have changed, but the
separation is still useful. No matter what a few dim-witted so-called
engineers may say, it is *always* useful to have a guaranteed bootable
minimal system that at least gives access to a console, that does not
depend on the main filesystem (which is often big, mounted read-write,
and exposed to various corruptions).

My point is that the FHS is not good per se. It's insufficient, and
very little work has been put into it; it's not the result of long
design discussions with top-of-the-cream Unix engineers, it's just a
mixed bag description of what's out there with the word "standard"
stamped onto it. (Like Single Unix, in a way, but at least Single Unix
is slowly evolving and is trying to weed out brainless legacy and
standardize good APIs.)

I haven't even mentioned the things that FHS does not standardize or is
bad at, and there are a lot of those.

However, what is happening here is that the systemd people, in all
their short-sighted hubris, are rejecting one of the few parts of the FHS
that are *actually good*.

Beats me how those people can be so wrong and still managed to make it
to the grown-up stage and even get a diploma. That's some serious parenting
and school system fail.


> Poettering clearly understood the implications and outright rejected the
> rationale, by claiming nowadays it wasn't modern anymore to have a small root-
> fs and a separate partition for /usr

Poettering didn't even think that his system could ever crash. Or that a
Unix directory structure could be used on something else than a desktop PC
or a server PC, such as an embedded system that needs absolute bootability
guarantees. But please, enough OOT, let's go back to real engineering talk.

--
Laurent