On Sun, 2009-08-09 at 00:51 +0100, Graham Lyon wrote: > > > 2009/8/9 Hadmut Danisch <had...@danisch.de> > Graham Lyon wrote: > > > > > > Then documentation should be fixed, not the method itself. > DBus is the > > best approach to do this, it uniffies IPC in unix, which is > a *good* > > thing. > > > Network configuration is such an essential and basic function, > that it > should not depend > on IPC. IPC means that several processes must exist, and > this is error > prone by default. > > IPC may be an addon, but it should work without IPC. > > > I can see what you're saying here and I sympathise. Perhaps the best > solution would be one where there is a single NM daemon on the system > level that manages the interfaces and deal with the system config and > then supplies a (probably the same) DBus API that allows user > processes to manage user-configured connections. A merger of > NetworkManager and nm-system-settings, basicly. This removes the need > for IPC in order to get the core of it working whilst at the same time > still supplying the same funcionality. The more that I think about it > the more I agree with you on this point that NetworkManager shouldn't > be useless without DBus and the nm-settings-daemon running also.
NM master (0.8) already has merged NM + nm-system-settings; there is only one core NetworkManager process now. However, to control NM, you still need D-Bus. It is completely pointless to re-implement IPC via a socket just so you don't depend on D-Bus. So then you've got both (a) a standard, well-understood, type-safe D-Bus interface, and (b) a non-standard, hacked up duplicated socket-based control interface. Fail. There is nothing wrong with D-Bus, period. Or maybe people will finally accept D-Bus when it's a kernel module (as Marcel Holtmann has proposed)? Something Hadmut didn't consider was that maybe the distros *should* start D-Bus in single-user mode. That's what I mean by change; the distros aren't stuck in stone in how they are configured and what software they run by default. > > NM is not interweaved with desktop applications. You're > confusing the > > user settings manager with network manager itself. > > > A plain user will store his network settings under Gnome or > KDE and such > within the Gnome and KDE > configuration methods. This depends on desktop applications. > Without a > desktop network manager will > not find any user specific config. > > I'm not entirely sure what you meant here, but I suspect you mean that > an ordinary user will configure their system using the applets in > gnome/kde and so their settings will not be system settings? They only > need to tick the "make available to all users" ticky box. If I > completely misread what you're saying, please do correct me. > > > And I did not yet see any command line front end. > > > There is cnetworkmanager, apparently (I've never used it) and there > was discussions on this list somewhere about a rewrite of it to make > it more functional. Probably not a rewrite, but another tool in C more suitable to size-constrained installs, or people who just don't want to depend on Python. There is certainly room for both and neither would obsolete the other. Martin does good work. > > It's actually the best way to get the two levels of > configuration that > > I can think of. > > Storing network configuration in Gnome or KDE in a way that > they are not > available if someone uses the other Desktop is a bad idea. > Network > settings are > not desktop settings and thus should not be stored in the > Gnome or KDE > configuration. > > > Fair point, but how often do you switch to using the other desktop > environment as the same user login? It's not a particularly common use > case... I will admit that the network settings are not part of your > desktop settings and the problem here is that there is no unified > settings daemon for all user's applications (something like this is > really lacking in the world of linux and would be great as it would > stop everyone having to roll their own config file reading/writing > mechanism. If you want to use user connections in a different DE, you can make them system connections and they will be available to any DE that you use. That's actually the whole point of system connections; it doesn't matter what user or GUI you're using, they are still there. > > > It doesn't need a running desktop to be configured, and lots > of system > > relevent applications require DBus (it's not a desktop > program). > > > And that's wrong. > > DBus is not started in single user mode. So NetworkManager > could not be > used in single user mode. > > A network configuration that does not work in single user mode > is a flaw. > > See above. I'm not particularly familiar with single user mode (I've > never had the need to use it, rather thankfully) but is it possible > that dbus could be added to the things that are started in single user > mode? Right; there is no reason that NetworkManager cannot be used in single-user mode. Plenty of services get started in single-user mode, and NetworkManager + dbus can be two of those if people need networking there. Alternatively, you can always have your way with ifconfig and iwconfig and wpa_supplicant manually. But if you don't want to screw around with all that, just start NM. In the end, I'm not sure there's much we can say to Hadmut; we're pretty off the original topic of pre-down. Dan > > > Networking must be able to work even in single user mode > in a simple > > terminal > > with a shell session and must not depend on anything > else. > > > > > > Correct me if I'm wrong, but I think it does as long as the > daemon is > > started and the system settings daemon is started. > > > That's one of the problems. Network configuration must not > depend on > that many daemons. > > Network configuration must be able to work on its own, even if > everything else is absent. > > I proposed a possible solution to this a little further up in this > mail. I'm not sure how the devs will feel about it but it actually > makes more sense from a design point of view to me. Though I don't > pretend to know about the network manager internals so it could be > impossible... > > Graham > _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list