Comment 2 for bug 94760

Revision history for this message
Charles Perreault (muganor) wrote : Re: [Bug 94760] Re: both wireless and wired connections are up after boot

I also disagree because having both interfaces enabled is the opposite
of the network manager primary goal, which was to manage wired /
wireless connections for mobile desktop users (laptop) and assure
everything would work plug'n'play. It's the opposite of
"configurations", "metric" and whatsoever human manipulation. Of course
it's not the choice of the OS to decide which connection you want to
use, but network-manager isn't part of the OS. Many in the OS Science
community argue wheter file systems should be part of the OS or not
(think of micro-kernels), so network-manager is still far from there.
It's a utility package one can use or not, install or disinstall.

However there was a set of rules (it's not available on the web page
anymore, but it was when the project started to explain how to users how
network-manager would work) :

1- By default, wired will always be prefered over wireless
2- If no wire is present, choose wireless, and vice-versa
3- If both are available and a wireless network was EXPLICITELY chosen
last time both were present, choose that wireless network (kind of
"remember my preference" rule) else choose wired mode (default)

The rules enumerated back then only stated 1 of the devices would be
active at a time, depending on the situation. It would avoid having to
manipulate the route table, or manually disable the wrong interface.
I'm sure of it, that's why I was compiling/using network-manager since
it's start, before I switch to Ubuntu(breezy) and before it was included
in the default Ubuntu setup. If 2 or more devices should be configured
(bridge, gateway, etc), then it's probably not a mobile/laptop user and
it should be done outside of network-manager (by disabling the roaming
mode in the network configuration for instance). Anyway such user would
have plenty of network configuration knowledge to not need network-manager.

This bug will be close because the behaviour stated originally seemed to
have disappared with the recent updates to the kernel and probably of
the bcm43xx driver, but not because this wasn't a bug in the first place.