Re: Bits from the Release Team - Kicking off Wheezy
On Sun, Apr 3, 2011 at 7:23 PM, Josselin Mouette <firstname.lastname@example.org> wrote:
> And that’s because… ?
Good question, the only answer I have is that we probably don't want
to add too much bloat to base.
> This is not a design issue, this is what can make it work. If you have
> one single, extensible daemon being able to manage all your connections,
> you don’t need anything more. The problem here is that it is, currently,
> not being able to handle all the network connection types we want to
> My question remains: is it better to add support for them to existing
> software that already does a good job, or to continue masturbating over
The problem with that design is that it isn't based in *fact*. The
fact is that the kernel is where the current networking status is
held, controlled and modified. AFAICT the NM authors ignored that fact
in their designs and are resistant to changing the design. That leads
me to think that NM is not the way forward. Waiting for someone to
re-implement netconf in C seems to be the only way forward.
>> The netconf design was much better here.
> Vaporware with good design is still vaporware, unfortunately.
Sadly yes :(
Someone kidnap Martin and convince him to rewrite the python prototype in C.
> These are all valid issues that would of course need fixing - although
> for manual ip/route/… I don’t know how this could be implemented in a
> correct way.
IIRC netconf communicates with the kernel to know what the current situation is.