On Sun, Apr 3, 2011 at 7:23 PM, Josselin Mouette <j...@debian.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 > handle. > > 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 > vaporware? 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. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=zh7k2vq2qgegblxk0z_yqqoj...@mail.gmail.com
