On Fri, 10 Jan 1997, Craig Sanders wrote: > > 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 would personally like that to be the case too, (and if I had the ability to write a program like linuxconf I would have written it that way). However, I didn't write it, but I still think it is the best tool for configuring a linux system and with minimal work can be made to work with debian. > > 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. I agree with that and that is why we don't need to have linuxconf use the monitor lines in the dropins. > > 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. I understand, but even if you wanted it to restart automatically, all it would take is editing a single line in the dropin > > 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. > Again, don't have to have a monitor line. > > 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. I agree with you first point, but we can easily make linuxconf let you do your job. > > 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. > It does mostly, however I do know the init issue is a big issue. I might talk to the linuxconf developer to see if we can get it better intergrated with init. Shaya -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
