Weekly Edition
Return to the Development page
| |||||||||||||
ConnMan 1.0 released
Marcel Holtmann has announced the 1.0 release of ConnMan, an internet connection manager targeted at embedded systems. It is designed to be small, require few resources, and handle a wide array of connection types (wired, wireless, cellular) with IPv4 and IPv6 support, along with proxy handling, tethering support, statistics gathering, and more.
"The ConnMan 1.0 release means that we from now on provide a stable D-Bus
API. From now on, the API will only be extended and we will keep
backward compatibility going forward. [...]
ConnMan is a monolithic system that includes many features right out of
the box without requirement of any external daemons or programs." (Thanks to Gustavo Padovan and Daniel Wagner.)
(Log in to post comments)
ConnMan 1.0 released Posted May 11, 2012 7:29 UTC (Fri) by pbaum (subscriber, #4514) [Link]
Is there any up-to-date comparison of ConnMan and NetworkManager?
ConnMan 1.0 released Posted May 11, 2012 15:25 UTC (Fri) by ajross (subscriber, #4563) [Link]
To the user they're broadly equivalent. For a few versions ConnMan was vastly faster than NM at IPv4 address resolution (for reasons I never bothered to puzzle out -- all I know is that MeeGo development boards would come up on the same network 4x faster than my laptop). ConnMan is smaller. It has a much (!) cleaner D-Bus API, though it integrates poorly with all the legacy scripting in existing distros (whether that's a feature or not is a flame war I'd rather not get into).
ConnMan 1.0 released Posted May 11, 2012 10:16 UTC (Fri) by hadess (guest, #24252) [Link]
"ConnMan, because I like my object type systems home-made"
ConnMan 1.0 released Posted May 11, 2012 10:54 UTC (Fri) by jpw (guest, #84580) [Link] Indeed. How dare they not use
ConnMan 1.0 released Posted May 11, 2012 11:01 UTC (Fri) by alexl (subscriber, #19068) [Link]
Oh, but they do. It uses glib and dbus, but not gobject, which NetworkManager does. So obviously it had to be replaced.
ConnMan 1.0 released Posted May 11, 2012 12:35 UTC (Fri) by nix (subscriber, #2304) [Link]
Because gobject is such a pleasant and C-like system to use.
(Seriously. I like most of glib, though it is a bit memory-inefficient for some uses -- but gobject is a classic example of overgeneralization yielding a system that, while quite general, is terrifically difficult to use for almost all practical use cases. This is a fairly common trap to fall into, so I'm not *blaming* anyone, or I'd have to blame myself for several even more baroque systems I've perpetrated in the past which thankfully have not got into the wide world. But still.)
ConnMan 1.0 released Posted May 12, 2012 21:25 UTC (Sat) by speedster1 (subscriber, #8143) [Link]
> Because gobject is such a pleasant and C-like system to use.
> (Seriously. I like most of glib, though it is a bit memory-inefficient for
Thanks, this is a much more civil explanation of the issue than I could manage at this point, with deadlines looming for producing a couple custom plugins for the heavily-glib-based gstreamer framework. Straight-forward generation of language bindings is a wonderful feature of glib, but coding in the glibc based C code itself... I'd better stop there, before I get uncivil
ConnMan 1.0 released Posted May 17, 2012 19:38 UTC (Thu) by zlynx (subscriber, #2285) [Link]
If I recall correctly from when I looked at some code 5 years ago...
Isn't gobject that abomination that contains 5 or 6 pointers to mostly useless information and causes any data structure that uses it to immediately bloat to over 100 MB in size?
5 64-bit pointers is 40 bytes before even including any information.
That is how I remember it anyway. I was trying to figure out how some new version of software went from 5 MB of resident set to over 100 MB back when my laptop had only 1 GB RAM.
ConnMan 1.0 released Posted May 22, 2012 10:20 UTC (Tue) by jamesh (guest, #1159) [Link]
Try 2 pointers and an int. One of those pointers is a reference to the class and the integer holds the reference count for the object, which you'd expect if you're using reference count based memory management and virtual methods.
The other pointer can point to a GData structure that will be allocated if you use various GObject features (e.g. weak references).
I won't deny that it adds some memory overhead over a bare structure, but it is for features people generally use.
ConnMan 1.0 released Posted May 22, 2012 16:04 UTC (Tue) by zlynx (subscriber, #2285) [Link]
I must have been thinking of GObjects stored in a GTree or a GList.
ConnMan 1.0 released Posted May 23, 2012 1:42 UTC (Wed) by jamesh (guest, #1159) [Link]
I agree that in some cases something like Linux's linked list implementation that embeds in the parent structure would save memory.
But the point is moot in the context of ConnMan: while they aren't using GObject, they are using glibs ADTs such as GSList.
ConnMan 1.0 released Posted May 12, 2012 4:46 UTC (Sat) by cmccabe (guest, #60281) [Link]
How about using the object type system supplied by the programming language?
ConnMan 1.0 released Posted May 14, 2012 4:27 UTC (Mon) by johnny (guest, #10110) [Link]
Why are some people still afraid of OO languages? Apple provides Objective-C, Android offers Java, but the Linux community still produces libraries where you have to use long ugly boilerplate C code just to create a class.
I don't mean to be offensive or anything, I'm just curious. At one point, it used to be that C++ compilers were buggy and/or didn't produce goode enough code, but surely that's not true nowadays...?
ConnMan 1.0 released Posted May 14, 2012 10:38 UTC (Mon) by gnb (subscriber, #5132) [Link]
I think part of the answer is that writing libraries in an OO language tends to involve making it the single officially blessed language for that system (as in your examples of Apple and Android) due to the difficulties of making cross-language calls, whereas practically everyone supplies some means of calling into a C library, making it a useful lowest common denominator.
ConnMan 1.0 released Posted May 14, 2012 20:25 UTC (Mon) by cmccabe (guest, #60281) [Link]
Object-orientation isn't a language feature, it's a programmer feature.
C is a useful lowest-common-denominator language which can be accessed from anywhere. It also tends to be more efficient than the alternatives. That makes it useful for writing truly common libraries.
Now, having said that... I don't know whether C is the best language to write a network-manager-like program. I'm partial to wicd myself, which is written in Python. As long as the DBUS bindings can be accessed from any language, the choice of implementation language seems irrelevant.
And now it's time for a language flamewar, where all the usual points will be brought up exactly as usual. Move along, nothing to see here.
...and right they are Posted May 12, 2012 17:57 UTC (Sat) by HelloWorld (guest, #56129) [Link]
Building an object system for a language like C without language extensions is stupid beyond words, and I can't blame anyone for not using it.
...and right they are Posted May 12, 2012 23:51 UTC (Sat) by nix (subscriber, #2304) [Link]
What? Hasn't everyone written their own home-grown object system for C? You have to use *something* to write generic data structures, and despite some Unix programmers' fetish for reimplementing new half-baked versions of such things whenever they need them, not all of us work like that. :)
...and right they are Posted May 14, 2012 8:00 UTC (Mon) by HelloWorld (guest, #56129) [Link]
The alternative to using GObject isn't to build your own object system for C but simply to use a decent language that supports OOP. And if you really, really want to use GObject, at least use Vala.
...and right they are Posted May 17, 2012 20:51 UTC (Thu) by nix (subscriber, #2304) [Link]
All I can say is that in many previous jobs if I had tried to force everyone to use C++ they would have killed me -- but a few simple ADTs they were quite happy with. That the data structures happen to use structures containing function pointers and up-pointers to ancestor structures internally, just like C++ classes, is something they didn't need to know or care about unless they were adding a new descendant ADT. They had their happy C still. (Also, we had a lot of pre- and post-processors involved which could parse C -- just -- but had no chance of parsing C++. One of them claimed to parse C++, but it couldn't handle templates at all, so it barfed on the G++ headers. Most impressive. Not.)
...and right they are Posted May 17, 2012 22:01 UTC (Thu) by HelloWorld (guest, #56129) [Link]
I don't see the connection to the topic at hand. The discussion was about object systems and GObject specifically, and ADTs have nothing to do with those.
Also, I think that ADTs in C invariably suck. It's simply not possible to write generic, type-safe ADTs in a sane way (the C preprocessor isn't sane).
ConnMan 1.0 released Posted May 11, 2012 12:33 UTC (Fri) by job (guest, #670) [Link]
NetworkManager, ConnMan. What's up with the CamelCasing?
ConnMan 1.0 released Posted May 11, 2012 12:47 UTC (Fri) by ovitters (subscriber, #27950) [Link]
It used to be popular unfortunately (together with *Kit).
A few years ago I changed the svn/git gnome repository creation script to only allow lower case characters. :P (only exception is perl stuff; those are created manually)
At the moment you see a lot of *d (systemd, printerd, colord, etc).
ConnMan 1.0 released Posted May 11, 2012 15:01 UTC (Fri) by SEJeff (subscriber, #51588) [Link]
Still seems like serious NIH to me. Even their original announcement[1] was "we don't want to make NM better, so we're going to write our own thing."
Color me unimpressed. However... the fact that this thing is used in robotics and that absolutely beautiful nest.com thermostat is quite nifty.
|
|||||||||||||