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
