Re: design decissions in nm ?
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
Re: design decissions in nm ?
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. > >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. 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'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. 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 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. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: design decissions in nm ?
On Wed, 2006-01-18 at 10:47 +0100, Soeren Sonnenburg wrote:
> I am and might even
> want to run additional scripts to start applications etc...
As far as I understand, this can be achieved using the
NetworkManagerDispatcher service. It calls scripts
in /etc/NetworkManager/dispatcher.d with arguments
{ up | down }
after the interface has been brought up. Have a poke around in
dispatcher-daemon/NetworkManagerDispatcher.c for more information.
Hope this helps,
James
--
James Ettle[EMAIL PROTECTED]
Southampton High Energy Physics
School of Physics and Astronomy
University of Southampton, SO17 1BJ
PGP key: http://www.hep.phys.soton.ac.uk/~jhe/pgp-public/jhe-shep.asc
---
signature.asc
Description: This is a digitally signed message part
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
design decissions in nm ?
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... >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 :) So why is NM as it is ? where can I read more about this ? Thanks Soeren ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
