Re: NetworkManager

[Carlos Garnacho <carlosg gnome org>]

Hi Seth :),

On Mon, 2004-08-30 at 00:16 -0400, Seth Nickell wrote:
> > I don't mean to be harsh, but I expect more of a standard, [1] the GST
> > backends are almost in a 1.0 stage, support lots of distros, will be
> > distributed separatedly after gnome 2.8 (and gst 1.0) and will be
> > proposed to fdo. They are thought for this kind of problems, why not
> > using them?
> 
> Hi Carlos, I don't want to give the impression that we've ignored
> g-s-t. I looked at the backends a few months ago (not connected w/
> NM), but didn't really consider them for NM because the aims appeared
> quite different.
> 
> AFAICT, and please correct me if I'm wrong, g-s-t attempts to provide
> a constant interface over distro-specific network setting/policy
> layers.
> 
> In contrast, NetworkManager supplants the distro-specific
> setting/policy layers. It becomes the setting/policy layer. One goal
> of NetworkManager is to (at least in the desktop realm, but hopefully
> more generally in the future) take "networking" out of the realm of
> "distro specific icing".
> 
> I will boldly say that every major distros networking policy layer is
> a hacky script.

I have to agree here :)

> Moreover, the policies are geared toward servers
> rather than desktops & laptops. The g-s-t approach is a good bandaid,
> NetworkManager is more like invasive surgery: its painful, the patient
> might die on the table, but it might be the only way to heal the wound
> ;-)
> 
> I think its reasonably open for debate whether "invasive surgery" is
> called for here, but at least I hope this helps explain why we haven't
> used the g-s-t backends: the goals are quite different. Also, the
> distro specific stuff in NM is pretty small and should only shrink
> with time (for example, I think it would be pretty reasonable to say
> "NM will use such and such a dhcp implementation", or just include
> DHCP support in NM itself). At present its about 200 (very simple, and
> half the lines are comments) lines of C per distro.
> 
> In more concrete terms, the NM backends wrapper very different things
> than g-s-t backends as a result of the differences in goal. For
> example, we don't wrapper "ifup" but directly call "ifconfig", "ip"
> and kin.

the backends wrapper ifup in the distributions that have this kind of
scripts, for others it calls ifconfig, iwconfig, dhclient or whatever is
necessary, with really slight modifications you can get the backends to
read some basic XML with the config you want for a given interface and
configure it without adding extra distro-specific weight to NM (in fact,
this modification is planned for 1.2)

> 
> > This is how autogen.sh ends for me:
> > <output>
> > 
> > checking for /etc/mandrake-release... no
> > checking for /etc/redhat-release... no
> > checking for /etc/fedora-release... no
> > checking for /etc/gentoo-release... no
> > checking for /etc/debian_version... yes
> > Your distribution(debian) is not yet supported!  (patches welcome)
> > </output>
> 
> Oops! Bug in our configure.in, now fixed, thanks. Though, I think the
> point that NetworkManager is very immature is fair. However, being
> facetious I note that g-s-t just got support for WEP keys today, so
> its not like it was sitting ready and waiting exactly what we needed
> *grin*

:), I'm not selling gst as a perfect product neither, I'm only trying to
say that sooner or later, you'll probably need to parse or modify distro
specific files (again, think in static IP networking, PPP users, ...)
and this can be easily done through the GST backends, as the XML
interface is standard across distros [1]

And yes, I think that creating an alternative database for network
config is bad.

	Carlos

[1] For those who haven't looked at the network backend XML, my wireless
interface looks like this:

  <interface>
    <auto>0</auto>
    <bootproto>dhcp</bootproto>
    <dev>eth1</dev>
    <enabled>1</enabled>
    <essid>home essid</essid>
    <file>eth1</file>
    <name>Tarjeta de red inalámbrica</name>
    <update_dns>0</update_dns>
    <user>0</user>
  </interface>