Re: system-config-dns?

["Chester R. Hosey" <Chester Hosey gianteagle com>]

On Tue, 2005-07-26 at 21:40 +0800, John Summerfied wrote:
> Chester R. Hosey wrote:
> > On Tue, 2005-07-26 at 10:07 +0800, John Summerfied wrote:
> > 
> >>
> >>As to what's actually stored there and its format, I don't care a lot. 
> >>_I_'d not use XML because I don't understand it and it looks too 
> >>complicated to me. However, XML seems the be the current fad.
> > 
> > 
> > I'm not talking about the base format, but what is the structure and
> > type of the actual information to be stored.
> 
> I do not understand.

Documents have formatting and content. I'm saying I don't care whether
it's in XML, plain text, RTF, LDAP, or even Microsoft Word format -- the
question is what _kind_ of information you're trying to store.

The solution you suggest assumes an elegant way of expressing to anyone
who might care exactly how to configure a given program, including
configuration file format, what options are available, what values are
legal, etc.

The lack of such a mechanism is exactly the problem!

> > So it's a matter of merely launching an external program for
> > configuration purposes, perhaps with some extra scripts for
> > starting/stopping/restarting? Sounds... not very robust.
> 
> ??
> I'd not thought xinetd. kde, /etc/init.d etc particularly frail. 
> However, feel free to suggest improvements.

I meant that in terms of power. The level of integration is bound to be
fairly low if you're launching completely dissimilar configuration
mechanisms. Xinetd doesn't attempt to integrate with the application --
it merely performs a few very well-defined operations. General
configuration is not a well-defined operation.

> That is why I propose the configuration management tool handle the user 
> communication. There's no reason it can't have a text-based UI, a 
> web-based UI (maybe good for my linksys wireless router which, it 
> happens, run Linux), Gnome, GTK, KDE etc frontends too.

You mentioned launching elinks to interact with SWAT -- that isn't quite
the same thing as having a configuration tool present a UI itself.

> > A menu calling vendor-supplied configuration tools is papering over the
> > problem to some extent. Does it solve it? To some degree. Does it offer
> > many advantages over the current situation? That's debatable. You'll
> > still have differing configuration mechanisms unless you declare that
> > the world *must* use some well-defined mechanism which provides front-
> > ends for a terminal, X, Windows, etc. Unless you can pull that off you
> > *still* haven't solved the initial problem of having completely
> > different systems. You have, however, given it a pretty menu interface.
> 
> That is why it needs at least one vendor (or a big user) to get behind 
> it. My influence is very limited.
> 
> atm I look after various Debian & RH-derivatives. Where tools (other 
> than vi) exist, they have different names and different abilities.

To get behind what? If app vendors wrote individual configuration tools
that wouldn't really suit your idea of a generalized configuration
management tool. It's not solving the problem, and handwaving about lack
of influence doesn't change that fact.

> >>>In fact, debconf retains its own repository of options you've selected;
> >>
> >>Indeed. I think it's a bad idea, and I quickly decided not to use esmith 
> >>because it does just that.
> > 
> > 
> > It's not a bad idea for a tool that isn't intended for generic
> > configuration.
> 
> atm the "standard" way to configure stuff is a text editor. Anything 
> that automatically breaks manual changes is broken.

It doesn't break manual changes often, because there's a very limited
subset of configuration items shared by the both configuration file and
debconf. Only where *absolutely necessary* should debconf be configuring
anything that might be changed elsewhere -- which is why maintainers
don't (and shouldn't!) use it for general configuration. It's more
appropriate for system-level configuration the application doesn't need
to care much about.

> > I keep wanting to say something about how I don't understand why Red Hat
> > doesn't attempt to do more to address this and other problems, but Ed
> > Wilts has already addressed that in an earlier response in which he
> > reminded me that Red Hat doesn't sell applications, only the packaging
> > and support services.
> 
> RH hs certainly tried to sell what seemed to me applications. There was 
> the RH Database thing; unlike AS/ES etc I never saw the source for that.

And I keep wondering what became of RH Portal.

> > I suppose Red Hat and I differ regarding the extent to which I think
> > that "packaging" should include a commitment towards integration into a
> > coherent whole. They do make efforts in certain areas, but in the area
> > this thread originally tried to address they don't seem to be committed
> > at this point (I submit as proof the lack of update to the documentation
> > and the suggestion that one not expect the GUI tools to serve all
> > configuration needs for even simpler tasks).
> 
> Red Hat, I understand, has put a fair bit of money into Gnome. There 
> are, I guess, times when the GPL works against us: if RH adopted this 
> idea and sank a squillion dollars into it then gave the results away, 
> the shareholders might have some difficult questions.

But why, is the question? Why GNOME, when they aren't really going after
the Windows desktop market? What's the point of a set of widgets if you
don't have useful programs working with them? Why aren't they more
concerned with integrating the apps they do package than working on a
project that isn't in directly the path of their core focus?

As I understand it, GNOME is pretty enamored with Mono, which RH won't
even touch. I don't understand Red Hat's decisions. That isn't to say
that I think that they're wrong; only that I don't know about the
situation to make an assessment. I do wish they were more transparent.

> OTOH when it does provide configuration tools, it would be nice if the 
> worked properly and sensibly.

I think that this whole thread could be replaced with that statement.
"When [Red Hat] does provide configuration tools, it would be nice if
[they] worked properly and sensibly."

Chet