NetworkManager: How to set caching nameserver?

[Matthew Saltzman]

On Sat, 2008-07-12 at 15:56 -0400, Michael H. Warfield wrote:
> Hello,
> 
> On Fri, 2008-07-11 at 15:34 -0400, Matthew Saltzman wrote:
> > On Fri, 2008-07-11 at 09:48 -0700, Rick Stevens wrote:
> > > Michael H. Warfield wrote:
> > > > 
> > > > 	I have a longer rant that I'm strongly tempted to send.
> > > 
> > > I'd wouldn't necessarily post your rant here, as most of us here agree
> > > that NM is a bad idea gone wrong.  
> 
> > Speak for yourself (unless you have hard data to back up your
> > assertion).
> 
> 	Which assertion?  That NM is a bad idea gone wrong or that most of us
> agree on it?  I think I have some hard data on the former but not the
> later.

The former is strictly an opinion, and you are welcome to it.  The
latter is an assertion of fact that I don't think you could back up.

> 
> > > You should, rather, post your rant as
> > > a nice big, fat bugzilla report on the NM and/or Gnome bugzillas.
> 
> > Better would be a handful of focused, reproducible error reports, so
> > that the problems can be fixed and the tool improved.  Rants aren't
> > really helpful as Bugzilla reports.  They are, however, great ways to
> > generate traffic on mailing lists.
> 
> > > 
> > > It'd also be nice if there was a decent how-to on the various aspects of
> > > the configuraton of wpa_supplicant (what the various "key_mgmt",
> > > "pairwise" and other parameters mean and how to find out what to use,
> > > etc.) so normal non-geeks can sort it out.  As far as I can see, people
> > > submit to NM nastiness because they can't sort those out themselves.
> 
> > I agree with the need for more and better documentation for
> > wpa_supplicant and for NM.  But I mostly "submit" to NM because it
> > mostly works for me.
> 
> 	There in lies the real problem.  I agree with you 100%.  NM "mostly
> works" for me as well.  I just got back from a conference in Vancouver
> where it managed the WiFi connectivity issues beautifully.  The problem
> isn't when it works.  The problem is when it doesn't.  And it doesn't
> all to often.  It's not most of the time, just a minority of the time,
> but way too often when you have to deal with a diverse changing set of
> environments (which is what I THOUGHT it was suppose to be designed for)
> as I do.
> 
> 	When and where it doesn't work, "the gods that be" can not help you
> solve it.  It's a closed box which doesn't allow for tinkering and
> tuning and scripting to fix things.  Yeah, it "mostly works", but the
> times it doesn't are an unfixable abomination and a plague upon
> civilization.  When it doesn't, the only solution is to drive a stake
> through its heart.
> 
> 	"Mostly works" doesn't work, when you close your system and don't allow
> people to tune it and you refuse to acknowledge the parameters, and
> hooks, and scripts which the users have specified (and that does NOT
> mean forcing the user only through your myopic gui dialogs) and used
> successfully in the past.

I won't presume to speak for the developers, but my belief is that what
we have is a system that is (a) pretty useful in many
circumstances--useful enough to deploy, even though it's (b) unfinished
and (c) undergoing rapid changes in order to improve it, and is (d)
poorly documented as a result of that instability.

That happens often enough in Linux and open-source development to be
pretty frustrating, but I don't ascribe malicious motives to the
developers (most of the time).

Meanwhile, I use it when it works, and I when it doesn't, I try to
troubleshoot it and file bugs or turn it off and use the individual
tools that it tries to tie together.  And I try very hard to be
patient...
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs