Re: 2 questions...

[Dan Williams <dcbw redhat com>]

On Tue, 2005-07-26 at 10:14 -0400, warlord wrote:
> Quoting Dan Williams <dcbw redhat com>:
> 
> > On Mon, 2005-07-25 at 20:27 -0400, Derek Atkins wrote:
> >> Colin Walters <walters verbum org> writes:
> >>
> >> > Seriously, what's the difference to the end user?
> >>
> >> Having to type their password first?
> >> Having to restart gaim or psi or other apps because there's a
> >> race condition between login and network startup?
> >
> > Again, this is a problem with the _apps_.  They need to be aware of
> > network changes.
> 
> Dan, you keep conflating two issues which are not the same.  You seem to be
> confusing "network exists at startup" from "network changes from under 
> you". I'm concerned about the former, you seem to talking about the 
> latter.

No, they are actually the same thing.  Remember, a network change can be
from having a network connection to having _no_ network connection.
Apps need to be able to deal with that, things like Evolution and
Mozilla have offline modes for this sort of thing.  Its a fairly simple
patch to Mozilla/Firefox to flip to "offline" mode when NM tells Firefox
that there's no network connection.  So apps need to start up assuming
there's no network connection, then doing whatever it is that they do
when they find out there is one.

Note that I'm really only considering user/desktop apps here.  We
shouldn't expect server stuff like Apache to assume no network, since
the whole point of Apache is that there _is_ a network to serve stuff
to.  But if somebody has a laptop that's always plugged in, why are they
using NetworkManager at all right now?

If they use NetworkManager, they must reasonably expect their network
not to be around at various points, and therefore the applications have
to deal with that case.  NetworkManager can't babysit every application,
and the way things get fixed is, in some cases, to cause their
assumptions to be invalid and have people yell a lot.

> Most applications fail harder if there's no network when they start, but will
> deal much better if the network changes from under them.  Asking every
> application writer of every application to deal better with starting without
> network just because you don't want to make a "global network configuration"
> seems a little, I don't know, egocentric?  "The world must work THIS way"?

The way it is right now isn't necessarily the best way.  Its a
historical artifact that stuff on Unix/Linux _assumes_ a network is
always present, and now that people run laptops we get to lobotomize all
sorts of stupid desktop applications that don't expect stuff to drop out
from underneath them.  Which is perfectly valid situation if you've got
a laptop and are using wireless.  I don't think it's egocentric at all,
given the way things are going and the way people are now using
computers compared to 5 years ago.

> Why should wireless networks be treated differently than wired networks 
> in terms of when they are started?

Arguably they shouldn't, but it just happens that NetworkManager does
start wired networks right now.  But that's not intentional, just an
oversight.  When we get a sane system services and configuration
framework, then we can start stuff like wireless earlier too.
NetworkManager breaks horribly for the "network mounted /usr" case right
now too, but do you reasonably suspect people that have network mounted
critical partitions to be running NetworkManager?  (note that you
physically can't, because dbus, hal, and glib reside on /usr)

> Why should NM work differently than the original network scripts in terms of
> when networks are started?  Sure, NM gives you the ability to connect to
> different wireless networks.  This is a good thing..  But it still starts too
> late.

Frankly, because the network scripts suck for mobile users.  They are
not automatic, which was the whole point of NetworkManager.  Part of it
was also that there was no use-case we could think of that required an
early start for the mobile user.  Now that you've found one, we have to
go through and think of how to deal with it in a useable manner.  But
that doesn't automatically mean falling back to exactly the way things
were done before...

Dan