On Tue, 26 Jan 1999, H.J. Lu wrote:
> Can you tell me how you start/stop/restart a service on Slackware,
> which may require a series of commands in the correct order? On RedHat,
> you can do
>
> # cd /etc/rc.d/init.d
> # ./service start|stop|restart
>
> It is that easy. Also I can start/stop a network interface with
>
> # ifup/ifdown eth0
>
> Everything is automatic. My ifup even knows Linux 2.0/2.1/2.2 since
> some network commands are changed. Try that in Slackware.
I've never had any difficulty starting or stopping services in slackware
(or any BSD-ish Unix). I just don't usually use scripts to do it.
However, I agree that there is nothing wrong with encapsulating network
startup/shutdown (or anything else) in scripts as long as it is one
doesn't go mad with it. There are a lot of services where if you want
it to stop, you kill the daemon. I can kill daemons. Or send them a
HUP to restart the service without killing them.
Again, you miss my point. I am AGREEING that Red Hat and SysV has some
agreeable features and encapsulations. I'm also pointing out that it
might take years for one to learn that ifup/ifdown eth0 starts/stops the
network, using parameters predefined and stored SOMEPLACE for the
interface, since ordinary Unix humans of course expect to do that with
ifconfig followed by a route command with explicit control over the
parameters. There is no law prohibiting one from adding "simplifying"
commands or scripts to Unix, but it is already rather command rich and
you must remember that you are adding more to learn (as one cannot
really forget that ifconfig is being run SOMEWHERE, in the not unlikely
to my experience event that it fails...).
So YES, let's all agree that SysV init is good, that encapsulating
scripts are good, that sourcing variable data is good. Can we also
agree that most of these pieces ought to be colocated instead of all
over the filesystem, that there ought to be a fairly rigorous and
locally documented (so neophytes have a CHANCE of learning without
buying books or bugging people or working incredibly hard) way of
scalably extending the layout, and that the layout should be simple
enough that people actually want to learn it instead of utter
imprecations against the ancestry of the layout's creators?
Peace.
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
