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

Re: Consesus on Linuxconf?



Shaya Potter <spotter@kby.netmedia.net.il> writes:

> >> --This might mean that Linuxconf will error out if it can't parse the file,
> >> if you've made private changes to it.  That's the tradeoff, you take a risk
> >> that you won't be able to use linuxconf if you privately edit the file.  We
> >> will work to improve the parser though to minimize that risk.
> >
> >This will be the case with any interactive config-program build on top
> >of existing configuration languages (even the samba configuration
> >"language" is complex enough for this to be true).
> 
> I wouldn't say that, last year when I was playing with linuxconf, I took my
> debian sendmail setup, and the first time I ran linuxconf, linuxconf parsed
> it perfectly.  I didn't have a complex setup, so it doesn't prove much, cept
> that linuxconf can parse things that it hasn't created.

No, i meant you can't prevent the parser to error out on some edited
config files, not that it will happen with every edited config file.

[...]
> >most configuration files can be complex; take a look at the files in
> >your /etc. How many simple and how many potentially complex files did
> >you find?
> 
> well, I don't have a debian system running right now here in .il, <blush> as
> I only came for the year, though as I'm returning to the states in a week,
> I'll have my debian box[s] up and running soon after, especially with those
> nice multiple OC-3s at work. <big smile>

was a rhetoric question :-)), IMHO most of them are potentially complex.

> >Additional points I would consider important:
> >
> >- how difficult is it to write a module for linuxconf for some
> >  package; can some scripting language be used?
> 
> Writing simple modules shouldn't be too difficult right now, if you
> know C++

better if writing simple modules was simple ;-)

[...]
> >- how well does linuxconf scale (what if i have 50 configuration
> >  modules?)
> 
> hehe, I don't think their have been any tests, as there aren't that many
> modules yet, so I can't answer, if we come to that point, it shouldn't be
> too difficult to subdivide the modules, though even without it, you'd
> probably just have to scroll threw a longer list to find what you want to
> configure.

maybe there are other issues too like load time, especially when
started in batch mode.

[...]
> >- on which platforms could it run or made to work? (administrating a
> >  bunch of machines with the same tool would be a plus; i think it's
> >  one goal of coas)
> 
> What do you mean?  right now linuxconf includes some of the "modules" in the
> linuxconf core code, and not as modules, the author is working on seperating
> them all out, I hope to get just a linuxconf-base. with linuxconf-[modules].
> It seems to be pretty flexible, has remote managment, remote control from
> one linuxconf "server" to multiple clients....

I meant if it can be easily ported to other os's. Maybe sometime in
the future it becomes important.

> 
> >
> >These are general questions relating to any such program. Perhaps it
> >would be a good idea to discuss the interfaces to packages. If one
> >could standardize that (how to put additional information into
> >sysv-initscripts, and which information, or the module api, etc.),
> >perhaps we could get less dependent on a specific program like
> >linuxconf.
> 
> Well, for Linuxconf it's pretty standard right now, there's a document on
> Linuxconf's web site, that was written up for Red Hat, though it confused me
> a little as their were no examples.

haven't looked there for some time. My point was, will we get really
clean interfaces/api's? In the long run the api might be more
important than the program implementing it. A related question is,
will it integrate well with the debian way of doing things (whatever
that is, but we are discussing some configuration issues in another
thread, and some things seem to be related).

[...]
> I'll package linuxconf up soon after I get back to the states.

great :-)

ciao

Andreas


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


Reply to: