Announcing ConnMan.net [LWN.net]

Announcing ConnMan.net

Posted Jun 23, 2009 19:45 UTC (Tue) by mitchskin (subscriber, #32405)
In reply to: Announcing ConnMan.net by Cyberax
Parent article: Announcing ConnMan.net

I had this same question. I think part of the rationale for ConnMan is that it can be used earlier in the boot process than NetworkManager, but beyond that I don't understand the details.

I've been hoping for a ConnMan-NetworkManager controversy so that we can all follow it and understand the arguments a bit better. Maybe this is fertile ground for a LWN article?

to post comments

Announcing ConnMan.net

Posted Jun 23, 2009 21:36 UTC (Tue) by leoc (guest, #39773) [Link] (9 responses)

Seconded! It is not clear to me from the available information what exactly precluded the projects from working together.

Announcing ConnMan.net

Posted Jun 23, 2009 22:44 UTC (Tue) by njs (subscriber, #40338) [Link] (8 responses)

These slides explicitly contrast ConnMan and Network Manager:
http://moblin.org/sites/all/files/lfcs2009-connman.pdf

Their direct critique of Network Manager isn't very convincing. Apparently NM has a "large dependency list", which in practice just seems to mean that ConnMan wrote their own glib/dbus integration instead of using libdbus-glib? I dunno. There's "too much GNOME like source code". If you say so, I guess? The diagram on slide 6 looks scary on first glance, but then compare to slide 14 (interesting example of how to use diagram layout to make a rhetorical point, though)... Basically it looks like they hadn't thought about this very hard so they just wrote a list of the standard complaints people make about every project, and some of them may be valid but they don't really justify rewriting things from scratch.

Which is fine -- they do a much better job of talking about what they actually do want to do, and they have some interesting and new ideas about how to architect a connection manager. The main points seem to be: 1) general cleanup and cruft removal, 2) move all logic into the daemon and make the UI just a trivial "thin client" display layer, 3) be "heavier-weight" (contrary to their earlier rhetoric!) in the sense of unifying more aspects of network management (DNS, HTTP proxy, Zeroconf, etc.) into a single address space so that they can be done more intelligently.

They definitely have some potentially good ideas; it'll be interesting to see which ones work out, and whether they survive as a project or just force Network Manager to implement the good parts themselves :-).

Announcing ConnMan.net

Posted Jun 24, 2009 8:55 UTC (Wed) by danpb (subscriber, #4831) [Link] (7 responses)

The points the ConnMan PDF raises against NetworkManager were all valid criticisms of the 0.6.x release series of NM, but none of them were fundamentally unfixable flaws. Indeed this is highlighted by the fact that a great many of the 'problems' were addressed in the 0.7.0 series of NM. So I can't help thinking the decision to start writing from scratch was not the most effective use of resources.

Announcing ConnMan.net

Posted Jun 24, 2009 14:44 UTC (Wed) by wstephenson (guest, #14795) [Link] (6 responses)

Try implementing a NetworkManager 0.7 client then. There is still a lot of boring work every client has to do to make the objects NM exposes on the bus into something that the user can interact with.

Announcing ConnMan.net

Posted Jun 24, 2009 16:11 UTC (Wed) by nirik (subscriber, #71) [Link] (4 responses)

cnetworkmanager?

http://vidner.net/martin/software/cnetworkmanager/

Announcing ConnMan.net

Posted Jun 24, 2009 16:20 UTC (Wed) by wstephenson (guest, #14795) [Link] (3 responses)

Martin's client is great for what it does, for example if you just want to connect to a WPA-PSK network from the command line, but it's very limited.
I meant a full-featured client that starts with the desktop session, saves configuration to disk (and securely where appropriate) and has a UI.

Announcing ConnMan.net

Posted Jun 24, 2009 16:28 UTC (Wed) by dcbw (guest, #50562) [Link] (2 responses)

Of course this takes some code, just like for example writing a usable display configuration applet that handles monitor hotplug and removal, configuration-on-the-fly, saved settings, etc. When you're dealing with hardware and configuration, you need to write the code to deal with that hardware and all the configuration options.

But since you've implemented the plasma stuff, I'm curious what your suggestions would be for making it easer. How can the D-Bus interface be improved? What can be made simpler, ensuring that the flexibility of the configuration system is retained?

It would be a lot simpler if we could get rid of ActiveConnection and just use the Device object, but unfortunately, we're just about to add bridging support, and that's going to make the ActiveConnection class have more than one device in the "Devices" property.

Networking is a complex problem, and if you want to solve users' needs, you often need to write non-trivial amounts of code to make sure it's possible and easy for the user. Often that means it's harder for the develoepr.

Announcing ConnMan.net

Posted Jun 24, 2009 16:47 UTC (Wed) by wstephenson (guest, #14795) [Link] (1 responses)

The simplifying approach I've taken for KDE, to make it possible for non-NM specialists to work on the GUI, is to produce a high level flat list of "things that the user might want to click"

1) Wireless networks (as the NM dbus api only gives a list of access points)
2) Connection on an Interface.

This list is pre-filtered on appropriateness (a fuzzy definition but you know what I mean - don't list any connections where a matching AP is not visible - don't list wired connections when there is no cable inserted, don't show anything wireless when in flight mode, etc).

From what I've read of the ConnMan docs so far, they have taken a similar approach in what is presented to the client, giving up some correctness and flexibility in the model (at that layer) for ease of use.

Announcing ConnMan.net

Posted Jun 24, 2009 18:27 UTC (Wed) by dcbw (guest, #50562) [Link]

You'll probably remember that NM 0.6 did group "networks" together for you. That turned out to be a huge mistake in the daemon, because you need to separate networks based on SSID, capabilities, and band. Unfortunately, trying to over-simplify things is exactly what caused problems with NetworkManager 0.6, since you simply cannot trust people to actually name their access points reliably. Thus you end up with situations where you have two APs called 'linksys' with different security settings, and the user wants to connect to the higher-security one, but not the lower-security one. Or, their linksys AP is on the A-band, but their neighbors is on the B/G band.

Similarly, we found that *not* showing interfaces that were disabled or not managed by NM caused *huge* numbers of bug reports, mostly from Ubuntu users asking "where's my wifi card" when Ubuntu set their wifi card unmanaged by default and it disappeared from the applet.

So the gnome applet tries to give you an informed view of your machine, including why you can't do some things you may want to, instead of just hiding those items completely. The same reason why menu items get disabled rather than hidden outright.

Announcing ConnMan.net

Posted Jun 24, 2009 16:24 UTC (Wed) by dcbw (guest, #50562) [Link]

That's only if you want to implement user-specific connections like the applet does, which are completely optional. If you simply want to use system connections, which are handled entirely by NetworkManager, then you don't need to be a service on the bus at all. That's 66% of what nm-applet is doing; if you strip that out, it's really just some dbus calls and a GtkMenu. I should really write a minimal client just to dispel this sort of FUD.

I'm curious about the "boring work" you refer to. Using a library that makes it easy for you like libnm-glib, or by using python, it's pretty darn easy. But for a UI to be usable, you still need to ensure that you don't show the user things which aren't applicable to their situation, do proper error checking and notification, handle device removal and insertion, device status changes, etc.

I think you're expecting the problem to be simple, but it's not, and that's not NetworkManager's fault.