On Tue, Mar 11, 2003 at 02:26:27PM +0100, Emile van Bergen wrote: > On Tue, Mar 11, 2003 at 12:20:27PM +0000, Colin Watson wrote: > > On Tue, Mar 11, 2003 at 12:49:32PM +0100, Emile van Bergen wrote: > > > On Tue, Mar 11, 2003 at 10:21:33PM +1100, Glenn McGrath wrote: > > > > /run is more obvious than /mem to me as its intended use is similar to > > > > /var/run which is clearly defined. > > > That's true, but /mem can be just as clearly defined, as shown earlier. > > I'd prefer to name things based on their intended purpose than on their > > intended implementation. The former allows you more flexibility when you > > come up with a better implementation later, or when it turns out that > > your intended implementation isn't possible due to local constraints. > True, that's the general rule. > However, as /mem refers more to properties more than implementation, I > don't think it's much of a problem, especially because the most > prominent properties that /mem refers to by association, are > hard requirements to fulfill the intended purpose. > Another rule in my book is that if you can either solve a problem with > something very specific or just as elegantly with something generic, you > shouldn't limit the creativity of the people that come after you, and > choose the more general solution. > /mem can both be used for the things we're finding a solution for, the > /early-writable-and-always-cleared-but-more-general-variant-of-var-run, > and for things that we cannot forsee yet. > If you always want to name things after their purpose instead of > their properties, you make it more awkward to use those things to be > used for other purposes, even if they turn out to be a perfect fit. Except that it's *NOT* a perfect fit; you're already trying to overload the meaning of this proposed directory by adding a subdirectory used for state that's persistent across reboots. Having subdirectories with different semantics than the parent directories is part of what got us into the current mess. The FHS already has a place for persistent state -- /var/lib. I don't see any reason why ntp can't use /var/lib/ntp/ (which it currently does); AFAIK, all of the init scripts that need persistent storage are run after NFS shares are mounted. If you want to use shared memory for this so you don't spin up your disks, that's fine -- on *your* systems -- but it has nothing to do with the issue at hand, namely, that the FHS does not give us a usable location for the non-persistent, non-config files currently being stored under /etc. -- Steve Langasek postmodern programmer
Attachment:
pgp_Bndddq4Ut.pgp
Description: PGP signature