Patrick Schoenfeld <schoenf...@debian.org> writes: > On Fri, Apr 15, 2011 at 02:01:06PM +0200, Bjørn Mork wrote: >> Josselin Mouette <j...@debian.org> writes: >> >> > Since it was completely redesigned, almost from scratch, this doesn’t >> > apply for 0.8. Its system daemon is able to manage connections without >> > anyone logged on, and with a number of features that makes ifupdown look >> > like a baby toy. >> >> So Network-Manager has finally gained basic features like the ability to >> set a lower than default MTU? > > AFAICT n-m had support for setting a lower MTU since 2008.
Great. Didn't know that. Couldn't find it documented anywhere, but that's probably because Network Manager in general is completely undocumented. > And with basic network features do you mean things like > > - custom routes per interface Sure, just add up ip route 2001:db8:42::/48 foo dev $IFACE to the interface config > - multiple ip adresses per interface Sure, just add up ip addr add 2001:db8:13::1/64 dev $IFACE to the interface config > - WLAN configuration Sure, just add wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf to the interface config > - 802.11x Don't to that, but the wpa_supplicant scripts should support it AFAIK. > - overriding default nameservers per connection That's actually a feature I try to avoid, as I rarely (if ever?) use a computer with a single interface. So which interface defines the "connection"? But it can of course be done. The main problem is knowing which servers to configure, based on which protocol and which interface, and not doing the actual /etc/resolv.conf replacement. > - overriding default search domain per connection Now, that's a "feature" I find extremely dangerous. So you connect to host "foo", which turns out to be either "foo.bar" or "foo.baz" depending on which interface is currently up? Weird. Why would anyone want that? Yes, it can of course be done. > - netmasks in CIDR notation Which would be nice, but staying backwards compatible is more important. > and all of that > - in a central place with a consistent interface Yes: /etc/network/interfaces > - without reliance on external commands (such as the ip command or shell > scripts) for basic stuff Which is bad because of what? Using the "ip" command or shell scripts is an important feature to me. I don't want "grep", "cp", "ls" etc unified to a single file handling program either. I prefer the UNIX way of simple utilities doing *one* thing and doing that well. > - without crude hacks (e.g. defining additional interfaces just to bring > up another ip) I assume you are talking about alias interfaces? Well, that's a kernel feature from way back and has nothing to do with ifupdown, except that it supports them. Which Network Manager doesn't, if I read the BTS correct. But I rarely use them for additional addresses, no. I use "up ip addr add" instead. >> The list of features *not* supported by Network Manager is so long that > > Most ifupdown features are not native. Its basically a framework which > allows *other* tools to provide all the features you named. Yes, that's why it works. It doesn't *prevent* you from doing what you want. >> I've always believed that peoply chose NM for simplicity. And I can >> understand that. It's simple because it doesn't support anything >> "complex", including common VPN setups. > > ifupdown does not support any VPN setup at all. how does that fit in > your argumentation? It doesn't? Weird. Bjørn -- 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/87ei53vcya....@nemi.mork.no
