I'm running three different architectures off a single disk using NFSroot
and have found that NetBSD's directory layout makes this much simpler and
more elegant than any other OS i've seen.  The pattern it follows is
critical to saving space on my disk and avoiding multiple versions of
stuff:  mount progressively more general filesystems deeper in the tree.

 /           host-specific
 /usr        architecture-specific
 /usr/share  NetBSD-specific

this, i think, is and should be the driving force behind filesystem
layout.  what can and cannot be read-only is a matter of pesky details and
largely a site-specific hack.  conforming to a simple plan like this makes
such site-specific hacks _much_ easier.

if one is clever and lucky enough to treat /etc as generally as
/usr/share/etc, then, to quote Rei Ayanami, ``that's good for you.''  But
I think it's easy to see the OS should not be designed this way--_hosts
differ_.  That's what configuration was invented for.  

For example, the OS should support running xntpd on one machine, while not
on another.  Perhaps at your site you find it more useful to be able to
enable xntpd on 100 lab machines simultaneously by editing a single
file--that's understandable, but it's not a reason for reclassifying /etc
as ``NetBSD-specific.''

We need a place to store host-specific configuration.  We choose /etc as
this place. If you treat /etc as NetBSD-specific at your site, then as
more configuration info gets put into /etc you're going to have to rethink
all the hacks you've developed to permit this useful coincidence.  At some
point you may realize 100 hosts you thought were ``exactly the same'' are
actually subtly different.  No big deal--just pick a place for _real_
host-specific stuff at your site, and symlink into it.

Alternatively, NetBSD defines no place for site-specific configuration
because it's impossible to say what configuration belongs in that class
without knowing how your site is set up.  Make such a space for your site,
and use symlinks to put stuff there.

What's relevant to this discussion is only that:
  The place NetBSD uses for host-specific configuration is /etc.

I think this is a reasonable decision to make now, if it hasn't been made
already.


The difference between /etc and /var that i see:
 a. /var contains state that accumulates as a system runs, so on a
    freshly-installed system it is conserved across hosts and arch's
    and ``mostly empty.''
    /etc is host-specific even on a fresh system, and the state in
    it is tweaked and changed rather than generated out of nothing.
 b. the argument that it's disposable:  although mail inboxes, vi.recover,
    and snake highscores are not ``trash,'' they are (1) likely to 
    dissappear on their own a month or a year from now, and (2) not 
    needed by the system to boot and run completely normally.
 c. /var gets a lot more write activity than /etc.  if one uses a 
    filesystem that corrupts from bugs or power failures, it makes
    good sense to separate such stuff, especially given (b).

Now, crontabs in particular, have properties of both:
  /var:
    users create them.  if i decide to obliterate/``clean'' my /var,
    it has the possibly desireable consequence that all those little 
    random scripts users create to restart their eggdrops, dissappear. 
    cleaning /var eliminates state that i, the sysadmin, did
    not create and supervise.
  /etc:
    o the system depends on them to run.  it actively uses them just by
      being ``up,'' while highscores, mailspools, vi.recover, are merely
      stored, not _used_ until someone logs in.
    o they do not change often, and they do not dissappear on their own.

i'm therefore in favor of /etc/cron

Aside from some discussions of directory-layout philosophy, most of what
i've read sounds like the old ``my site needs'' vs. ``NetBSD needs''
dilemma, which keeps coming up in spite of the fact that i think we all
understand what choice we ought to make, even if it's momentarily
inconvenient.

Most commercial and free OS's are burdened with the perceived or actual
need to compete for users.  I see NetBSD's burden as something far heavier
and more awesome:  to preserve something beautiful and elegant into the
future.  More than code and functionality is at stake here.  We are
talking about a whole way of thinking that was condensed into an OS years
ago, and is now in serious danger of being lost.

-- 
Miles Nordin / 1-888-857-2723
555 Bryant Street #182 / Palo Alto, CA 94301-1700