Linked by Thom Holwerda on Mon 29th Jun 2009 08:51 UTC
"Intel has created a new network management and configuration system for Linux called ConnMan - but not everyone is pleased to see it challenge NetworkManager. Ars looks at the pros and "conns" of the decision to create the new software."
Thread beginning with comment 370714
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Here we go again...
by darknexus on Mon 29th Jun 2009 14:20
in reply to "RE: Here we go again..."
Member since:2008-07-15
I did read it, and I'm not impressed with his reasoning for a whole new subsystem. Reworking the parts of networkmanager that are a pain, sure. Making it more extensible, definitely, extensibility is never a bad thing. But to create a whole new, and incompatible I might add, system is just overkill but oh so typical of the Linux community.
RE[2]: Here we go again...
by madcrow on Mon 29th Jun 2009 16:04
in reply to "RE: Here we go again..."
Member since:2006-03-13
Sounds like ConnMan may be just what the doctor ordered for Linux networking. The current NetworkManager-based mess does all sorts of things wrong: it's bloated, has lots of dependencies, doesn't intergrate at all with traditional Unix configuration files and AFAIK, doesn't work from either the CLI or WMs other than KDE and GNOME. If ConnMan can fix even some of those problems, I'd be happy.
RE[3]: Here we go again...
by Delgarde on Mon 29th Jun 2009 21:20
in reply to "RE[2]: Here we go again..."
Member since:2008-08-19
Sounds like ConnMan may be just what the doctor ordered for Linux networking. The current NetworkManager-based mess does all sorts of things wrong: it's bloated, has lots of dependencies, doesn't intergrate at all with traditional Unix configuration files and AFAIK, doesn't work from either the CLI or WMs other than KDE and GNOME. If ConnMan can fix even some of those problems, I'd be happy.
Oh, in that case, you can expect to be very unhappy indeed. Because NM *does* integrate with traditional Unix configuration files - not perfectly, but supporting old and new configuration styles is part of what you call bloat. ConnMan doesn't. It's designed for embedded systems, which means it doesn't have any need for compatibility with anything else.
You don't like that NM doesn't work from command line or environments other than Gnome and KDE? Well, according to their website, ConnMan supports Gnome. You could presumably write other UIs, but that's also true of NM.
You want to talk dependencies? They're a little smaller, but not much. ConnMan uses most of the same components as NM - wpa_supplicant, dbus, PolicyKit. Glancing at the code, it uses the ModemManager project that spun off NM. Seems to use libudev to find devices, just like NM does now that HAL is being retired.
In fact, looking at the code base, it seems to me that the most significant difference between the two is that ConnMan appears much more modular - it can be built without wifi, or without ethernet, or bluetooth, etc. Probably useful in an embedded system with known targeted hardware, but as a compile-time option, of no real benefit in a general-purpose desktop.
If you don't like NM, chances are ConnMan isn't for you either...
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2005-07-06
Did you even read the article or are you just trolling? He tried to use NetworkManager and it turned out that it does not fit environments that consists of more than WLAN and Ethernet.
"One problem was the difficulty of extending NetworkManager to support additional kinds of connectivity; Holtmann says that significant portions of NetworkManager's code base would have to be rewritten to facilitate support for WiMAX, for instance. He faced similar challenges when he attempted to overhaul NetworkManager to enable tight Bluetooth integration. (...) ConnMan is lighter and has fewer mandatory dependencies. PolicyKit and the udev device management system are optional dependencies, meaning that ConnMan can work without them in environments where they aren't needed."