Comment 32 for bug 911706

Revision history for this message
Selene ToyKeeper (toykeeper) wrote :

If Network Manager were a rock-solid piece of software which always worked and was always installed and running, it might be reasonable to require it for default apps to function. But in the 7 years I've been trying to use it, NM hasn't worked correctly on *any* of the computers I've used it on. It's full of corner-case bugs, weird environmental incompatibilities, and is even a few missing basic functions (like letting the network be up when nobody is logged in to X).

Nobody would expect a different network stack in Windows or OSX because each only has one reasonable option... but Linux is a jungle, with dozens of valid systems for managing the network. We can mitigate that somewhat by setting sane and robust defaults, but we still have to respond gracefully when the defaults aren't being used.

If a user is on dial-up, it seems reasonable for them to install something like wvdial, but then they will have no clue why USC and U1 stopped working. Or if they're in a public place behind a captive portal, NM will report a valid network even when the system can't talk to anything other than the gateway. Or if they've already disabled NM completely, it tends to get re-enabled on each upgrade and sometimes on normal package updates, meaning the user must fix it over and over again.

As a general rule, in software I try to always use whatever method is simplest and least fragile... and for checking network status, that means sending a packet to an outside service and testing for the expected response. Network Manager is an awfully large and complex tool to use for something as simple as checking network status, and it's an unnecessary complication which gives us false negatives and weird failure modes.

I still don't see what's wrong with omitting all the look-before-you-leap checks entirely, and simply attempting to load content when requested. It'll fail sometimes even with a good network connection, so online error handlers need to be written anyway... and then the buggy pre-checks can simply be dropped as redundant. If you want to provide a smarter error message, make the error handler check the connection to narrow down the list of possible explanations. This logic could even be exported into its own network diagnostic package, to allow other apps to take advantage of an intelligent error handler for common issues.

Anyway, just my thoughts on the issue. It seems broken as-is, and there's a robust, straightforward way to fix it. It would be less error-prone if we removed the NM logic entirely.