Re: design decissions in nm ?

[Soeren Sonnenburg <networkmanager-ml nn7 de>]

On Wed, 2006-01-18 at 12:40 -0500, Dan Williams wrote: 
> On Wed, 2006-01-18 at 10:47 +0100, Soeren Sonnenburg wrote:
> > Hi list,
> > 
> > I (for the first time) tried out nm and well it partly works nice.
> > 
> > Now comes the unavoidable but:
> > 
> > For me it is completely unclear how I can have customized network
> > settings, i.e. custom ip address/netmask/gateway/dns's and also I'd like
> > to use different MAC addresses depending on where I am and might even
> > want to run additional scripts to start applications etc...
> 
> As was mentioned, NetworkManagerDispatcher can do that for you.  Or,
> anything that's dbus-aware can quite easily figure out the state of the
> network or be aware of network changes.

Ok, scripting is quite nice for potential power users and necessary for
distributions.

I don't see the static stuff covered yet but lets discuss this more
below. For now just a question, could I change my MAC address on demand
depending on the network I want to join, i.e.
could I using dbus write an application that e.g. finds that network
profile XYZ is to be activated and so set the MAC address of my network
card to some value ?

Or where can I find which dbus messages are generated ? In
NetworkManagerDbus.{cpp,h} ?

> > >From what I understand from the website is that nm is a standalone
> > application that tries to du everything. Well I don't understand why it
> > is not done the unix way, i.e. I can do all of the above and more using
> > standard ifupdown w/ ifplugd, waproamd, ifupdownroaming, resolvconf,
> > guessnet, wpasupplicant. I can even have vpn stuff... and that all is
> > around for years... So all that GUI users are missing is a a GUI :)
> 
> Because the "Unix way" sucks for the people we were designing for.  The
> Unix way is to edit 50 config files, one for each of the daemons you
> list there (of which there are about 5 or so).  And none of the programs
> give you reliable status information about what the heck they are doing,
> and they all require terminal access at some time.  When you increase
> the number of interactions/daemons, you increase (a) the complexity, and
> (b) the changes for errors to fall through the cracks between daemons.

I agree that status information is the K.O. reason why it won't work
elsewise. However this means NM conflicts with *any* networking tool as
it has to assume that it is the only program changing things. That is
why - to be successful - it must include quite a large part of the
options that other programs provide...

> NetworkManager was initially designed for the following type of person:
> 
> a) Laptop as the primary computer
> b) Is mostly corporate user, where security is (arguably) more important
> c) May have a company system administrator (who can setup up GConf
> defaults for the corporate network, etc)
> d) Moves frequently between access points at work, home, in hotels, in
> airports, coffee shops, etc
> e) Doesn't necessarily know how to "configure" the whole networking
> situation, wants stuff to "Just Work"

I would say b & c don't matter and a) more or less implies d), and yes
everyone wants things to just work, just sometimes it does not and then
one has to do things manually. However one has to be able to do it
somehow.

> I'd argue we hit that general goal pretty well, even if there were
> corner cases that simply didn't work at all (static IP, starting NM the
> first time, etc).  This person is still a central design target for NM,
> but by no longer the _only_ one.  The important thing is to start with a
> small, nail the original goal convincingly, then evaluate what to do
> next.  Don't bit off more than you can chew, and don't try to please
> everyone right from the start.  That's a recipe for failure, or at least
> an unworkable program for the people you should try to target in the
> first place.

>From what I've read, you already have solved cable connectivity,
wireless (as far as the drivers support it) and also some vpn clients
but all only for dhcp... Well I can hardly believe your argument above
as the importance ranking should also do the simplest thing first so
IMHO it should be

1) static IPs on cable
2) dhcp on cable
3) wlan
4) vpn

> NM has moved on in some fundamental ways, but the central goal is always
> "Just Works."  Profiles suck, which is why we don't make them a central
> part of NetworkManager like other tools try to do.  NM _should_ support

Well even my Playstation Portable has wlan-profiles and I see no reasons
why these profiles should suck. I would even call them intuitive: I (as
a person) switch between profiles... I am at work or home or wherever
and I thus in a different operating mode (dressing, behaviour,...). Well
profiles suck in a way that one has to manually switch between them (I
would really like my X resolution to adjust to the monitor that is
connected), but hey one could recall the gateways MAC addr (as one could
recall the Monitors type) and this way automagically activate a certain
profile (this btw is what guessnet does). So you don't necessarily have
to expose profiles, all one would have to do is to present the current
network settings and allow for editing them and then save this 'profile'
internally. If autodetection fails (but I cannot imagine why) then the
user has to have access to profiles and really manually choose among
them.

> more advanced features, but only in ways that don't take away from the
> "Just Works" aspects.  ie, if it does support "profiles" at all, you, as
> the user who wants them, will have to accept that quite a few things
> won't be as automatic and painless as they were before you made a
> profile.  Maybe that's a fair tradeoff, maybe that makes people mad, I
> don't know.

see above.

Soeren