Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 4, 2011 at 11:42 AM, Stefan Lippers-Hollmann <s.L-H@gmx.de> wrote:
[...]
>
> Besides not using netlink internally, ifupdown's biggest drawback in my
> personal opinion is not reacting dynamically to changing connection
> methods, like switching from wlan0 to eth0, if an ethernet cable gets
> temporarily connected - ifplugd can act as a bandaid here, but is not
> overly reliable (and possibly doesn't cover UMTS connections or other
> mobile connections either, but I'm not sure about this).
>
AFAIK from following where I can the development of NM 0.9 upstream,
looks like the issues with interaction with ifconfig, etc. might be on
the way to being resolved. However, I'm just talking from very quickly
glancing at commit messages. I can't even point to a specific entry.
;)
> On the other hand n-m isn't an option for server or (quasi-) headless
> systems at all, be it due to large dependency chains (there is no D-Bus
> or X.org installed on my servers) or simply unreliable operations
> during remote upgrades (restarting the interface upon n-m upgrades).
> While it's certainly a convenient configuration method for notebook
> users, who switch often between different connectivity methods (ADSL/
> PPPoE, ethernet, wlan, PPP over bluetooth/ PAN, UMTS/ 3g, WiMAX/ 4g or
> different VPN profiles). However for me personally, a "simple" and
> dependable ifupdown like solution, which can be configured/ operated
> through the cli, and with minimal dependency chains is more important
> than a pretty GUI.
I tend to agree there: NM somewhat breaks for server setups (and
others purely CLI) for the above generic reasons. However, I do think
some of these can be worked around seeing as upstream is both
responsive and open to changes. X isn't required (nmcli works well,
even though it can't create new connections). Other things like DBus
might be required by other parts of the system. What's left is dealing
with upgrades, but in Ubuntu at least upgrades shouldn't trigger
restarting interfaces, exactly for the reason stated. I'm sure the
same can be done in Debian if it wasn't done already.
This said, I don't think NM can be the magic bullet to fix everything.
Even RedHat while shipping NetworkManager on servers last I checked,
still relies on their simpler command-line setup for interfaces. So
should we. Defaulting to using NM probably takes care of the widest
audience who would use DHCP and such, and others can fall back to
ifupdown or a successor to do the more complicated things like
bridging.
What this gives is a "standard" experience on desktops and servers for
the majority of use cases, with as much room as necessary for the most
complex configurations.
Mathieu Trudel-Lapierre <mathieu.tl@gmail.com>
Freenode: cyphermox, Jabber: mathieu.tl@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93
Reply to: