wired ethernet disabled between reboots, was: when startup delays become bugs

[Chris Murphy]

On May 21, 2013, at 5:50 PM, Doug Ledford <dledford at redhat.com> wrote:

> On 05/21/2013 04:25 PM, Chris Murphy wrote:
>> 
>> On May 21, 2013, at 2:07 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>> 
>>> 
>>> 
>>> Am 21.05.2013 22:02, schrieb Chris Murphy:
>>>> Maybe someone can explain to me the use case for ONBOOT= where its value isn't tied 
>>>> to the current network state. I wasted an inordinate,  unreasonable amount of time 
>>>> trying to figure this out before I realized what was going on
>>> 
>>> why should ONBOOT tied to the *current* state?
>> 
>> Common and reasonable user expectation, at least in a GUI.
> 
> Maybe common, definitely not reasonable.

The GUI is the user domain by definition. I'm not just a user, I'm a very reasonable user. If I'm experiencing significant dissonance, something in the UI is almost certainly unreasonable. There may also be user confusion, but so far that only explains a narrow part of this experience.

There are all sorts of conventions used in a wide array of user interfaces that totally, completely, utterly contradict this particular Gnome + anaconda convention of persistently disabled wired networks through reboots, despite the user enabling the connection. I've already mentioned multiple times including in the bug report cited from the start that this is inconsistent with the wireless connectivity behavior in the same scenario. 


> 
>>> it simply controls if a interface is brought up at
>>> boot or not - not more and not less
>> 
>> It's an unusual convention.
> 
> The unusual convention is clearly delineated by the language around it.
> In Windows, eth interfaces are either Enabled or Disabled.  There is no
> on or off.  You can't bring up an eth interface with Enabling it.
> Because there is no distinction between on/off and enabled/disabled, it
> is not possible to bring up an interface and not have it come up at the
> next reboot.  Fedora (and all linux OSes for that matter) simply offer
> two distinctly different states that can be utilized: on/off,
> enabled/disabled.

The two states aren't co-located in the Gnome UI. They use different UI elements: a slider vs a checkbox. The options appear in completely different layers of the UI. Don't say the states are *offered* when the interface to those states are so tragically obscured. The equivalent is having the gas pedal in the driver's seat floor, and the brake pedal attached horizontally to the rear passenger door in lieu of the door handle. 

"Ahh yes absolutely we offer a totally safe vehicle equipped with the necessary means to accelerate and come to a complete and safe stop."

Except in Gnome, it's not nearly as conspicuous (and hence discoverable) as a brake on the rear passenger's door would be.

>  You are basically saying "This isn't the way Windows
> does it,

Not really, as I don't use or maintain any Windows installations. If you'd said "this isn't the way OS X does it" you'd be closer to the mark. But the assessment is against the consistency of the UI I'm given, not the other UI's I use. I don't have a problem with the additional granularity on Fedora. I have a problem with the UI and feedback I'm given, compared to the reasonable expectations for behavior I have as the admin user for the system.


> even though what you offer is more flexible, so do away with it
> so it doesn't confuse us simple folk",

I'm not saying get rid of the additional granularity from all UIs. I'm saying that the offered, default GUI, both Gnome and anaconda, don't adequately convey system behavior, don't accept user preference for alternate behavior adequately, and don't behave consistently across different interface types or versions. That should be fixed.

> This is where, if I controlled NetworkManager, I
> would say "please don't waste our time with an argument of 'Windows
> dumbs everything down for me, please do the same'"

Except that's not what I'm saying. You're starting to rival Reindl on taking 90 degree turns at 90 miles an hour.

I did not say remove granularity. I said alter the default behavior. That doesn't mean the behavior shouldn't be modifiable to some other behavior. The default behavior for wired connections right now isn't consistent with how wireless is treated. It isn't consistent with how F18 worked. It isn't consistent with Android. OS X. iOS. Or Windows.

You can have the additional granularity but a GUI commensurate with the additional complexity is then required. You don't just get to put brake pedals on the antenna of the car and say, "yeah man, bad ass, better than f'n Windows". It's just irritating to read that granularity = better, all other considerations are unimportant and make the critic a wanker Windows user.

And I happen to know people suffering from brain damage as a result of excessive granularity. Rather smart ones.


>>> the use case is easy and simple:
>>> i have a spare network for testings on one of my machines
>>> most of the time it is not useed and so not started
>>> if i need it "ifup eth1"
>> 
>> What is the negative side effect of it being On at reboot, when it was left On at the time you initiated the reboot?
> 
> Who's to say that on the reboot it is still connnected?  And depending
> on your system configuration, having extra connections can slow down and
> complicate the boot process.  And if both interfaces are dhcp managed,
> the dhcp configurations may be conflicting in nature (for example both
> can define a default route and you may want the default route of the
> second interface to only be used when you have manually brought the
> interface up and overrode the normal interface, where as having this
> happen every time at boot would not be what you want).

Yes fine all interesting and maybe valid reasons, I'm not going to argue that. Tell me why the onboot=no behavior by default is appropriate for a Fedora Live media installation? Why is it an appropriate default for a laptop? Why is it appropriate in the face of wireless not having the same behavior in the same scenario described?


Chris Murphy