Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] GIT changes to master grimoire by Eric Sandall (3af8bc174a00c8fdb3bf52bbb46185a710129c8f)

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] GIT changes to master grimoire by Eric Sandall (3af8bc174a00c8fdb3bf52bbb46185a710129c8f)
  • Date: Fri, 27 Apr 2007 15:44:47 -0500

On Apr 27, Thomas Orgis [thomas-forum AT orgis.org] wrote:
> Am Fri, 27 Apr 2007 12:05:09 -0700
> schrieb Eric Sandall <eric AT sandall.us>:
>
> > I have never used the tools installed by this spell, so they could
> > safely go into /usr/sbin. I'll make the change later today if no one
> > objects.
>
> Well, you don't need them for the default setup of your box connecting
> to an access point, which would be a reasonable config if you really
> mount /usr over wlan. I use wlanconfig for specifically configuring
> ad-hoc mode or ap mode... one can do quite fancy stuff there with
> multiple virtual interfaces.
>
> Perhaps too fancy for /sbin.

The measure isn't "fancy", it's "need them for system recovery", and to a
lesser (but completely valid) extent, "need them to get to /usr".

http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES:

"/sbin contains binaries essential for booting, restoring, recovering,
and/or repairing the system in addition to the binaries in /bin. [18]
Programs executed after /usr is known to be mounted (when there are no
problems) are generally placed into /usr/sbin."

> But Jeremy:
> >> The majority of people don't likely have networked
> >> /usr partitions, no need to crowd everyone's /.
>
> Why does that /usr separation exist at all, then?
> A friend of mine (long-time CS student, even;-) asked me that question
> some time ago.
> I tried to explain it with the system installation being distributed
> over the network, many machines sharing a common /usr .
> That he understood.
...
> Well, I see reason to separate /var, /tmp and /etc (specific to each
> host or read-write)... but not /bin and /usr/bin (essentially
> read-only, common). We enter deep personal taste territory there, I
> guess, and /usr will stay just for the legacy if not for something
> real...

Because /usr gets big, and that raises the risk(probability) of it getting
trashed by admin or disk error. In that scenario, "recovery" is the name,
and you want /{sbin,bin} not affected by whatever took out /usr to lower
the risk(impact) of the crash so that you *can* repair.

This is not personal preference, this is the primary reason to segerate
/usr out. Network-shared /usr is secondary. You will note in the above
FHS justification that they do not mention "getting to nfs shares", they
mention "restoring, recovering, and/or repairing". "Booting" is part of
"getting to the other partitions", but as you noted it's essentially
tautological in this context: if you don't have another reason to
segregate, /usr may as well become /.

> Hm, I could make /usr a symlink to / and have a nice, flat directory
> structure;-)

Have fun with that the first time your real partition holding /usr explodes
on itself and ends up taking / too.

Attachment: pgpEpEs6p5jTI.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page