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
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
