Re: A comment on NetworkManager

["Peter Roediger" <p roediger gmail com>]

On 5/12/06, Dan Williams <dcbw redhat com> wrote:

On Thu, 2006-05-11 at 02:48 +0200, Peter Roediger wrote:
> 1.) Wireless networks list.
> There is no "Search for wireless networks" or "Refresh wireless
> networks list" button/option in the applet. While this seems to be
> convenient in the first place it turns out to be not in some cases.
> Consider this: Many laptops nowadays feature an LED that shows the
> status of the wireless connection ( e.g. flashing when it's not
> connected, etc.). Thus people will naturally switch the wireless
> network off when it's not needed. Then, they might disconnect their
> wired LAN at one point and go to some place that is supplied by a
> wireless network. Now, they turn on their wireless network card by a
> hardware switch and...they have to wait. They have to wait until NM
> will update the list. Which will take some time. The average user will
> not understand this behavior. But the average user would understand an
> option mentioned above. It's easy. Easier than a WEP key.
> Or something else: You walk around in a foreign city in order to find
> a hotspot to logon to. There is a desperate need to update the list
> immediately. It's simply crucial.

This isn't quite as cut & dried as you appear to assume.  Wireless, by
it's nature, is a fairly unreliable medium.  Not every network shows up
in every wireless scan.  This is true of all operating systems, even Mac
OS X and Windows.  On other OSs, the drivers to mitigate the problem
because the drivers are much better.  But you are still never going to
get all the wireless networks 100% of the time.

Which means; even on Linux if you had a "Scan now" menu option, you may
or may not get the network you are looking for.  NetworkManager's
wireless network list is a composite of scans of the past 6 minutes,
with scans taken every 20 seconds to every 2 minutes, depending on when
you last touched the menu.  Even so, over time wireless networks drop
off the list because they didn't show up in the last 3 scans.

Partly this is a driver issue, though there's not too much that can be
done there.  But Linux drivers are quite inconsistent right now WRT
active & passive scanning, and how they age and cull scan results.  But
the other part is that it's just wireless, and 802.11 b/g isn't really
set up to have as robust an OTA protocol as something like Bluetooth,
for example.

So I think your problem will improve, but recognize that there's an
upper limit for _everyone_, not just Linux, on the behavior of the
technology.

I'm aware that wireless networking is not fully reliable, no question about that. But when the nm-applet still doesn't show anything, "iwlist eth1 scannning" will provide a list already. It's interesting to know, how often nm-applet updates the list. Thus, to have an extra refresh option might be superfluous...i don't know. 20 seconds to 2 minutes is still a long time, if you're are really waiting to logon. I think, too long.

> 2.) The configuration issue.
> In my view NetworkManager is one of the most intransparent linux
> applications out there. There's no Documentation (correct me if I'm
> wrong), there is no configuration file easily accessible and there are
> weird things going on with resolv.conf. How is it configured? How can
> I change the DNS server without violating "# generated by
> NetworkManager, do not edit!"? Do I have to use a special program to
> set this up? If so, then just write it down at some place. I've been
> using Linux for 5 years now and having problems to set up basic things
> with an application that is supposed to be a snap to use.

Partly this is an artifact of the original target users we designed
early versions of NM for.  NM is now being pulled in a few different
directions, and our configuration story here needs to be better.  I
don't think anyone disagrees with me here.

NM is no different that dhclient here WRT to /etc/resolv.conf.  If the
DHCP server is sending your computer the information, then obviously
either NM or dhclient must write out resolv.conf.  That means either (a)
blowing away the existing resolv.conf and reconstructing it from _other_
files, or (b) trying to merge DHCP information with the
existing /etc/resolv.conf.  Guess which one _actually_ works?  (a).  NM
does need to do a better job of pulling in that custom information from
your /etc/sysconfig directory, or gconf, or whererever, and
reconstructing your /etc/resolv.conf.

I recently installed the resolvconf package (I'm using Debian unstable). Apparantely, NM does not overwrite the resolv.conf created by resolvconf. No idea if this is coincidence or on purpose. Anyway, you should still provide some _detailed_ information which configuration files NM actually uses to write resolv.conf.

In case of dhcp, it works as expected. Even now for the static networks with the resolvconf-package installed

> 3.) Profiles.
> I know, you don't like them. You think, they are an inconvenient user
> experience. Well, while I understand your pursuit of simplicity i
> don't really get what is so bad about profiles. You could present the
> user with some sort of a default profile. No further setting up is
> required. It just uses the settings specified
> in /etc/network/interfaces as usual. On the other hand, there are A
> LOT of people who use their laptop at home and at work or at the uni
> or wherever. And in those places there is no dhcp available in many
> cases. So what is so evil about letting the user create profiles so he
> can easily switch to the appropriate one? That is something so many
> criticize about Windows: They always have to change their network
> settings. Every day. That is not even close to "user-friendly". And
> again: With a bit of explaining the average user will indeed be able
> to set up profiles. If he is capable of changing the network settings
> every day, he'll be capable of creating profiles. For sure.
> And it's just so useful.

As much as I'd like to not do profiles, we likely need to implement some
bits here.  I'm against doing it for wireless networks entirely, but
there are some considerations where you simply cannot get away from
them: PPP and Static IPs.  Profiles might not appear as you think of
them, because I think they are quite "heavyweight" and we don't need
complete context switches.  But some features of profiles will appear in
0.7 later this year to deal with these two cases.

Side point:  Apple's Mac OS 7/8/9 Location Manager is what most people
think of when they think of "profiles".  On startup, you chose a
location like "Home" or "Office", and your dialup settings, your
printers, your file servers, your AppleTalk settings, etc, would be
switched.  This is DAMN HEAVY.  And ZeroConf/Rendezvous/Bonjour actually
eliminates the need for much of this pre-set configuration.  I think we
can do better here, but of course as long as there's PPP and static IP,
we'll never be able to do away with all manual configuration.

A key point here is to make sure that profiles are never exposed by
default, since most users will never have to use them.  But if your
network requires static IP, then you'll be able to set it and make it
work.

I fully agree here.
 

> To summarize this, NetworkManager works very well in many cases. But
> as this whole program is designed to work on a laptop there are
> important features missing. As this is still version 0.6.x I of course
> cannot expect a perfectly working, full-featured application. But by
> looking at your design goals, my concern is that you will not be
> implementing essential things just for the sake of (over-)simplicity.
> As Einstein said: "Everything should be made as simply as possible,
> but not simpler".
> This is going to be a great application, but it should be
> feature-complete. It's relatively easy to hide more complicated things
> in an "Advanced..." menu or something like that. But dropping features
> just because the 85-year old grandma will not understand what it is,
> is not the right way out.

I think the right approach here is to make things like the applet
simple, but provide (a) complex configuration in another application,
and (b) a rich (and well documented!) DBUS interface.  The applet then
becomes the simple interface, but if you want to tinker with the details
then you are certainly able to.

Dan

Thanks for the reply,

Peter