Quoting John Morris (jmorris@???):

> Dunno, that one actually makes a lot of sense.

At minimum, it's definitely not something to get religious over, so
nobody should be hyperventilating over it.


> The original reason no longer applies, we should all agree on that
> point, right?

Sure. Rob Landley's historical recounting should be sufficient
refutation of any claim that the /usr split was originally for
well-thought-out and persistently important reasons.
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html


> We don't NEED to install on a small volume and then mount
> the large stuff on a different media, even when we install /usr on a
> different filesystem it is almost always a partition on the same
> physical device.

Nope, we don't _need_ to.

However, even in case of the rootfs and a separate /usr filesystem being
on the same physical device, that doesn't mean there cannot be reasons
for separate /usr that the local admin considers compelling.


> The arguments they advance for snapshotting, using a read-only mount
> or network share of pretty much the entire non-host specific portion
> of the OS is a pretty good reason to pick putting everything down
> /usr.

Those goofballs talk about 'sharing the operating system over the
network' and 'a read-only export of the vendor supplied OS to the
network, which will contain almost the entire operating system
resources' because they have absolutely no clue about security -- one of
the several individually compelling reasons to be suspicious of their
advice. And there's nothing about separate /usr that prevents use of
lvcreate or similar snapshotting if you wish to use that: Their
allegation to the contrary seems... unexplained. I might be missing
something, so, if you know what they're referring to, I'd appreciate
hearing what.


> If you don't want to use an initrd, just avoid making /usr a mountpoint.

Can certainly be done, but suppose you want the functional advantages of
separate /usr? ;-> (Oh, you assumed there aren't any. Well, there's
your problem, then.)

Separate /usr is one of several measures I take to help guard against a
variety of mishap. For one thing, it then becomes possible to give /usr
custom mount options, including the one that makes it normally
read-only.[1] (I have hooks to apt/dpkg to automatically remount as
required for apt operations. See this Anthony Towns post for details:
https://lists.debian.org/debian-devel/2001/11/msg00212.html )

The aims of my partitioning strategy include getting everything feasible
off the root filesystem to keep it small and fairly static. This in
general terms keeps it far less likely to suffer mishap that includes
but is not limited to hitting 100% full or getting filesystem damage in
various ways. The rootfs having this passive protection against most
forms of damage means that crucial tools needed for recovery or restore
operations _or_ filesytem repair of other filesystems are highly likely
to be available without needing to resort to CD/DVD images, USB key
drives, or PXE-booting a recovery image. That's not everything, but
it's certainly a great deal more than nothing.

As a point of possible tangential interest, I use custom mount options
on several filesystems as a belt-and-suspenders security assist in some
cases, and to gain small performance advantages in others:

/usr      nodev,ro
/var/lib  nodev
/var      noatime,nodev,nosuid
/var/www  nodev,nosuid

What I mean by 'belt-and-suspenders security assist' is: Suppose some
process is somehow caused to run that attempts to do system harm.
Almost all such attack tools are automated and tend to be a bit brittle,
and it's conceivable that disallowing special files ('nodev') in a file
tree where they should never be present might cause the attack script to
fail. Likewise nosuid in trees where there should never legitimately be
an executable with the SUID property.

The 'noatime' on /var is of course for performance. (As always, one
must make sure nothing in that filesystem is going to need atime
time-stamping.

Anyway, I have no problem with the Freedesktop.org kiddies deciding that
my sysadmin use-case doesn't exist or should be ignored, because I can
work around their opinions and set my own local policy and practices.
So, we both get to be happy.


[1] This helps prevent accidental sysadmin-caused damage to the sytem
trees. It's proverbial that the biggest threat to the typical Unix
system is the root user.