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

Re: RFC: A method to use Admin tools, like linuxconf

On 20 Feb 1997, Manoj Srivastava wrote:

> Hi,
> 	I think that most people would not disagree with you about the
>  usefulness of a GUI based site configuration tool, what we are
>  objecting to is designing the system to cater to the needs of a
>  utility like this.

To design and develop a tool as good as Linuxconf would be almost 
impossible, if not a foolish idea.  Linuxconf is here and now, we have 
three options , IMO, in regard to the use of Linuxconf. 
1. Not use it.
2. Make Linuxconf conform to Debian.
3. Try to change Linuxconf a little, and change Debian a little, so the 
structure for Linuxconf to be put in is there.  In other words meeting it 
half way, that was the idea I was trying to put forth in the RFC.

> 	We have a standard, accepted, and stable init facility, and I
>  thik that should not be dismissed easily. By all means, let us have
>  the GUI utility: but let use choose/design one that works with the
>  system.

Just b/c it is standard, stable and accepted does not mean irreplacable.  
By saying we want Linuxconf in the distribution doesn't mean we have to 
replace it either.  Linuxconf needs some of its services anyway to 
operate.  A GUI tool isn't totally good either, what happens if you log 
in on a termianl that Linux doesn't supprt and you have to use cmd line 
tools, Linuxconf supports the cmd line.

> 	Of course, if there is a technical reason why the alternate
>  init method is better (and compellingly better, to offset the cost of
>  radically changing the installed base, and compatibility with other,
>  umm, linices).

I will forward a e-mail I got from the author, and you can look at 
http://www.solucorp.qc.ca/linuxconf/Welcome.html for more info.

> 	I think we should not have multitudinous init packages just
>  for the sake of multiplicity, because of the incresed difficulty in
>  diagnosing problems, and the confusion that may cause. (IMHO, of
>  course) 

We don't have to make it a standard part of the distribution, but it 
could be labeled as extra, (at least to start, until we determine its 
stableness) or even put into contrib.

However, there is another reason that my idea for abstraction might be 
good.  Lets say Plan 9, or another research OS, comes up with a great, 
ingenius, stupendous, new way to look at init.  It might be more 
difficult to change everything to it, if we stick with the system we have 
now.  The abstraction layer I am proposing should make it so that if we 
do ever decide to officialy change to a new init, the change will be much 


TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com

Reply to: