Alexey Dokuchaev writes:
> > Well, we *already* have over a dozen /etc/rc.* files on -current.  And
> > we *don't* have the advantage of a consistent interface to control all
> > the functions in /etc/rc. If you break things up, then if you need to
> > restart the mail server, just go "/etc/rc.d/sendmail restart". dhcpd?
> > "/etc/rc.d/sendmail/dhcpd restart". Etc.
> Actually, the point is that writing TONS of scripts to get your work
> done (that's what Linux world does) always pissed me off.  You have a
> shell script that is in fact a wrapper for another shell script, and like
> this in turn it goes on and on and on again.  Icky! :-)  I don't like
> how Linux smells.

Well, I don't like Linux much either. On the other hand, I hate
dealing with a lots of little things all of which are just slightly
different from each other even more - and the latter is what you get
from /etc/rc.

> Why can't I simply write kill -1 `cat /var/run/`?  I don't
> consider it being sagnificantly longer than writing /etc/rc.d/sendmail
> restart.  After all, if your typing speed is good enough, it doesn't
> really matter whether you type in 30 or 20 chars.

You can still do that. However, do you know how to get everything
listed in /etc/defaults/rc.conf to reread it's config file? With the
approach being advocated, the answer is "yes" - even if you don't know
whether or not the daemon in question *has* a config file. That's the
thing I like about all those scripts (SysV, linux, whatever) - I
didn't have to deal with cruft like that.

Yeah, for some things, this means you wind up running a script that's
a wrapper for the vendor-provided script to make it meet your
standards. If you really hate that, ignore the vendors script and talk
directly to the application - but they get little enough use that I'd
rather use the vendor's API and let it be wasteful. After all, if they
got a lot of use, having different interface wouldn't be a problem.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to