Re: Linuxconf
On Thu, 9 Jan 1997, Shaya Potter wrote:
> > the biggest problem with linuxconf is that it replaces sysvinit.
> > Linuxconf has some really nice features and seems like a
> > comprehensive configuration system BUT even if it was 10 times as
> > good it still wouldnt be worth losing sysvinit.
>
> What I was proposing on debian-devel would mean you can have both.
> The linuxconf dropins would point toward the /etc/init.d scripts and
> when each package configures itself just like it calls update-rc.d
> now it could call a "configure" program.
that's partly missing the point. init and linuxconf fulfil two separate
functions.
configuration of a system and/or it's applications is an almost
completely separate function to controlling what daemons get started and
when.
I really don't want my system automatically restarting some important
daemon just because i've touched it's config file - if i want it
restarted then it's up to me to take some action which forces it to
happen.
here's a good example of why: squid. when it restarts, it can take
literally hours (depending on the size of the object cache it's
managing) for it to completely read in it's log file and know what
objects are already cached. This isn't a big issue if you're only
caching 50 or 100mb of web traffic, but is a huge issue if your proxy
machine has 4 or 8 or 20 GB of disk space dedicated to the task. I need
to be able to edit squid's conf file at any time and schedule a restart
for a time that suits me and the users dependant on it.
Also, there are other daemons and processes which rely on important
state-dependant information which will be lost when they are terminated
and restarted. Having that happen automatically whenever a config file
is touched strikes me as being not only inflexible, but also potentially
dangerous. i don't want my system second-guessing me.
i'd be a lot more inclined to like linuxconf if it confined itself to
managing configuration information and left init's job to init....and
left my job to me.
A configuration engine's job is to make it easier to configure and
use EXISTING configuration methods, not to force everything into it's
mold. In other words, it has to maintain continuity with established
standards.
craig
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: