Ok, to start with, you *really* have to fix your e-mail addresses.
The ones I saw, even after removing `no-spam', are totally bogus.

On Wed, 21 Apr 1999, it was written:

> This is a goal, but is not the only goal, and for many it is
> not the most important goal.  For sites that back up /var for
> other reasons it is not a goal at all.  In addition, your choice
> of what is in your "Transient loss" category vs what is in your
> "Permanent loss" category is not shared by all sysadmins or users.

Fair enough. But you have to show something else that's at least
equally important that this is in conflict with.

> 	1 - To reduce writes to the root and usr filesystems,
> 	    thus reducing the chance that they will get corrupted.
> 	    Perhaps allowing them to be mounted read-only.
> 	    (I currently mount /usr read-only and would love
> 	    to be able to mount root read-only.)

This is, in the current scheme, without question a lower priority
than what I talked about in backups. /etc is designed to be written
on ocassion; this is why things like the password and skey databases
are in there by default.

> 	/ needs to be bigger (for some sites a LOT bigger)

I'd be interested to know which sites those are. In more than a
decade and a half of using Unix systems, I've never seen a system
with more than 20K of crontabs.

> 	More writes to the root filesystem, increasing the chances
> 	that it will get corrupted.  A corrupted root filesystem
> 	*really* hurts availability.

True. But, on not just many, but most systems, crontabs get written
far less often than /etc/passwd and /etc/skeykeys. This does not
add significantly to writes on the vast majority of configurations.

> 	One more roadblock in the way of making root read-only.

Not really. If you're making a read-only root, you may *want*
read-only crontabs. If not, you can symlink them out of root, the
same way you do with anything else in root that shouldn't be
read-only.

Again, read-only root is *extremely* site-dependent; we simply
can't support somthing that's done so differently from site to site
any more than we do already.

> 	Things that are not needed in single-user mode do not belong
> 	in the root filesystem.

In that case, much of /etc doesn't belong in the root filesystem.
For example, all of the following files should be moved elsewhere:

    aliases aliases.db bootparams bootptab changelist cron daily
    daily.conf dm.conf ethers exports ftpchroot ftpusers ftpwelcome
    group hosts.equiv hosts.lpd inetd.conf ipf.conf ipnat.conf kerberosIV
    mail.rc mailer.conf man.conf mk.conf monthly monthly.confmotd
    mrouted.conf mtree namedb newsyslog.conf ntp.conf phones postfix
    printcap protocols rbootd.conf remote rmt rpc security security.conf
    sendmail.cf services shells skeykeys sliphome ssh_config ssh_host_key
    ssh_host_key.pub ssh_random_seed sshd_config syslog.conf ttys uucp
    weekly

So where do all of these go?

> 	Things that generate disk writes should not be moved
> 	into the root filesystem.

I'd agree. But if we moved passwd out of the root filesystem and
crontab in, we'd still have a large net saving of writes on the
majority of systems.

> Crontabs also contain user data, and so don't belong in /etc.

But other things that contain user data are in /etc. Again, this
is why I want to see a full plan, rather than just arguments about
crontab.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   604 801 5335   De gustibus, aut bene aut nihil.
The most widely ported operating system in the world: http://www.netbsd.org