Re: [patch] Support Debian's resolvconf

[Tomislav Vujec <tvujec redhat com>]

On Mon, 2005-08-01 at 11:50 -0400, Colin Walters wrote:
> I think a big component of the design thought behind NetworkManager is
> to make the "common" case work really, really well, even if that comes
> at the expense of some of the less-common cases.  
> 
> For example, making 802.11 work really well, and not including ppp and
> idsn.  I know ppp/isdn are probably very important to some people, but
> in good design you have to make some trade-offs.  I don't think it's
> impossible to "support" these things in NetworkManager, be that some
> basic integration with and awareness of existing distro tools for these
> connection types, or implementing it all in NetworkManager if that
> proves necessary.

What might be a common case today, doesn't mean that it will be a common
case tomorrow. For example, UMTS networking is more and more common this
days in Europe. I can be online wherever I am in Germany, I don't have
to go to a nearby Starbucks for wireless, I have UMTS on every park
bench.

I don't like the idea of configuring/using my common case using other
tools, which would just disable NM. NM should be a networking king, and
the one in control.

> Now the first item, I guess my thought would be - there's probably about
> 50 networking nerds out there who have hardcoded static IP addresses for
> their wireless networks; are they really important?  It's really weird
> to use static IP for wifi in general anyways since you have to also do
> things like hardcode the MAC address of the access point etc, or you
> don't support roaming basically.  Maybe in specialized situations the
> static IP makes sense, but we should sit down and talk about what those
> situations are and think about the problem rather than just deciding
> that since it was supported before, it has to be in the future.

I agree that the static IP on wireless is a broken design. Static IPs
are required by servers, and since they are not mobile in most cases,
they should be connected by cables, if for nothing else, then at least
to free up radio bandwidth for the clients.

However, If you treat NM as a networking king on DBUS equipped linux
system, I can see it helping in the server configurations too. In my
point of view, all of the networking should be handled through NM.
Server cases probably don't make sense in the desktop applet, but they
definitely do in the NM daemon, and its DBUS API.

> The second item has some importance I understand - but we could discuss
> how to get some basic integration of NM and the existing ppp/isdn
> configuration; this might be basically just sending NetworkManager a
> dbus signal from the isdn script to say "i'm on isdn, don't do
> wired/wireless".  Maybe it's harder than that, I don't know, but again
> we should discuss it.

Right now, I have to start up my ppp on UMTS manually, which means that
I can stop the NM at the same time. I don't see a need for this disable
API at all.

-- 
Tomislav Vujec
Manager, Client Development
Red Hat  Otto-Hahn-Stra� 20  85609 M�-Dornach
Tel +49 89 205071 212 Fax +49 89 205071 111 Cell. +49 172 623 1214