[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linuxconf

I've met the author, a couple time and spoken to him about linuxconf quite a
bit, but i have the advantage of living in the same city.

I think there's a lot of promise here, but it'll be some work to integrate it
into Debian. What I'm most worried about is the direction it's headed in of
having one package with modules to control everything under the sun. It is
modular, and it looks well-designed. But many of the modules span multiple
systems (like editting /etc/hosts and bind configuration at the same time).

For Debian I think what we need is to have each module correspond to a
specific package. Sort of like what we do with menus or for that matter, man
pages. He has different ideas. One nice implication of his ideas is a user
could go into linuxconf see "DHCP setup" and when he goes to turn it on
linuxconf would inform automatically offer to fetch and install the required
packages. This is sort of the way Win95 works, it has the nice effect of
making the package maintenance system a lot less obtrusive.

He has a few peeves about the way linuxconf and he has been treated in the
past, because of a variety of misconceptions. I've seen a couple pieces of FUD
go by here, so I want to speak up now to clarify some things.

1) Linuxconf depends on X

No it doesn't. It's client-server, there are a number of clients including a
tty client and an httpd client. The modules are written independently of the
client used. Writing one module immediately defines the X as well as the tty
and http interfaces.

This was actually one of the motivations for RedHat to abandon their existing
X dependent configuration tools.

> 1. it replaces sysvinit with it's own bizarre startup script system.
>    apparently the author has done some work on this so that it is more
>    compatible with the existing sysvinit standard.

This is sort of true, but sort of not true. It takes advantage of sysvinit
style scripts to start and stop the daemons. It does expect to be in control
of the system startup and shutdown, but RedHat immasculated that section of
code precisely because they thought it would be too surprising. He added
features specifically so it could use the existing sysvinit setup for RedHat.

> 2. like all similar configuration tools that i have looked at and had the
>    misfortune of using, it makes it very dangerous to edit the text file
>    configuration with a text editor as nature intended :-)

One of the design goals is that it be "vi-compatible". With the exception of
sendmail.cf he parses every configuration file and retains all comments and

> see the archives of the debian-admintool mailing list from last year.

I checked these archives earlier when he told me Debian had decided against
using Linuxconf based on misconceptions. I skimmed through all the archives
back to the beginning and found no such discussion. I also asked people to
send me what they remembered, but nobody responded. I'm a bit confused about
where and when this discussion could have happened.


To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: