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
smoother.
Shaya
--
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: