[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: System Configure tool
From:       Andreas Pour <pour () mieterra ! com>
Date:       2001-05-04 20:58:49
[Download RAW message or body]

Matthias Elter wrote:
> 
> On Friday 04 May 2001 20:26, Charles Samuels wrote:
> > Upon reading the latest article at The Dot, I've come to the conclusion
> > that we need to write a Generic System Configuration tool.
> 
> I feared somebody would.
> 
> > Isn't this the responsibility of the vendors?  Yes, and no.  Yes, because
> 
> YES! Definitely!
> 
> > they're the jerkwads that can't decide on the standard for configuring
> > these things, but no, because they're a) incompetent and can never do it
> > right and b) we want the best for our users and ourselves.  Or at least I
> > think we do on point b... ;)
> 
> a) bullshit

IMHO there is a lot of substance to what Charles said, not b/c
distributors are incompetent but b/c they have their self-interests to
consider.  Whereas UNIX of old was severely hampered by API differences,
the same will happen to Linux of new with GUI differences, unless this
problem is nipped in the bud.

The situation is:  distributors want their own configuration utilities
so they can get good reviews and sell more distros.  This in and of
itself is good:  a number of different configuration utilities, let the
best one win.

But wait:  will the best one win?  No.  If SuSE's tool ends up being the
best, for example, I don't see Caldera or RedHat dropping their's in
favor of SuSE's.  So now there are a number of different config
utilities to do the same thing.

Why is this bad?  This *really sucks*.  Now you can have a user go from
one KDE computer to another and it's like it's not even KDE anymore. 
How do I configure the network card?  No idea; words differently.

And what about tech support?  How can an ISP support KDE/Linux if they
have not only to worry about KDE or GNOME or AfterStep, but even within
KDE there are 6 different ways to configure a network card (not to
mention that each distribution may do it differently in each version
they ship).

The upshot:  for some configuration things it is *imperative* to have
standards, and the distributor approach will not lead to standards.  If
you look at all the standards in Linux, I can't think of one that came
from the distributors.  They are always trying to set themselves apart
by doing effectively "proprietary" stuff.

> b) they know their distribution specifics and changes better than we could
> ever keep up with

There are better ways to deal with this.  For example, consider a
network configuration.  KPPP did that for modems.  With network cards
you can do something similar; each distribution will need to get the
same information to configure a network card, but each will do it a
different way.  Why can't a KDE control module get the IP address, DNS
stuff, masks, etc., set environment variables for each of the values and
call an arbitrary program (say a shell script) that the distros can
implement which effects the change?  The nice thing about this approach
is you now have a system-independent API for changing network settings
that any other program can make use of too (so e.g. your firewall
program may allow you to change network settings to tinker with things).

This doesn't have to happen with each and every configuration thing, but
at a minimum it needs to happen for network cards.  For other areas it
can happen too, particularly the areas where technical support is
important (since when someone talks with you over the phone they really
can't help you if they don't know where a module is located and how you
effect changes in it).

You want to support splintering at the long-term expense of KDE and
Linux, let the distros handle all this stuff; you want a standard way of
doing things that will make Linux/KDE much more user-friendly and
promote the long-term success of KDE, use a standard configuration
utility for these things.

> 
> > How do I indend to acheive this?  We'll be abstracting both the configure
> > system, and the user-interface. and both of these components will be
> > dlopened.  This is to make it possible to have a console version, and a KDE
> > version, with the same configuration backend.  You want a console version
> > for only a few specific modules, particularly stuff to configure the X
> > server ;) Welcome is the other tools, however.
> 
> Sounds like a linuxconf rewrite. Better forget this, SuSE, Caldera and
> Mandrake, Redhat are all working on configuration tools. SuSE and Caldera
> implement them as kcontrol modules. Both do a pretty good job at it, just
> wait for the new versions.

Right, so we can learn 20 new ways to do the same thing.  Real progress
:-((.

Ciao,

Dre

[prev in list] [next in list] [prev in thread] [next in thread]