Re: Diskless clients and NetworkManager



Dan Williams a écrit :

> if NM is not managing your default internet connection, then you
> should probably turn NM off when setting up the machine.

This "take it or leave it" philosophy is quite disappointing.


> But the core problem is that network management is a *system-wide*
> problem, and you can't just write one component and call it a day.  The
> policy needs to make informed choices based on the entire network state
> of the machine.  And the configuration of all the network connections
> needs to be in *one* place, with *one* format, not spread around in 3
> different locations because you're trying to put 2 or 3 connection
> managers on the same machine.  There should only be one connection
> manager running at any given time, or else you've just (a) doubled your
> work and QA, and (b) made it suck for users because configuration is
> split up, and (c) behavior is different than they expect.

In an ideal world this is definitely what you want, but the reality
unfortunately often departs from this. No matter your (impressive)
efforts, NM will by nature always be catching up with the latest
technologies or new fancy ways people configure their network.
And we do not even know if there will be enough will and development
manpower to make NM compatible with every latest connectivity
invention.

So I think assuming NM will always know about everything in the system
is not realistic. There will always be exceptions. If your answer to
this is "not supported, not interested, bye", then it is quite
disappointing (but the mere existence of "NM_CONTROLLED=no" suggests
otherwise). An alternative answer is: "graceful degradation". That is:
if you really think you know everything, then fine be the Oracle. But
otherwise be more modest and reduce the number of features _without_
getting rid of all of them!


About this more specific "online/offline" issue, you must consider
that there was a time before NetworkManager even existed, and that
there are systems where NM will probably never run on. Because of this
legacy, every single network application and every single end user is
assuming "online" status by default and prepared to catch possible
network errors. In other words, everyone is prepared to deal with
wrong online status. On the other hand, no one is prepared to handle
wrong offline status (how could that be?).

When NM sees "NM_CONTROLLED=no", reporting "offline" or "online" are
admittedly both lies (the accurate answer is "unknown").  But there is
a huge difference. Reporting "online" is a lie that everyone is used
to live with since ages, whereas reporting "offline" is a lie that
breaks everything. Pick one.

Making the simple easy AND the complex possible sometimes costs more,
but in this simple, specific case I really doubt it.

NM is great for many OTHER features than just (abusively) reporting
offline status, and I fail to see why users should give up on all
these other great features just because they sometimes want to connect
using a connection not controlled by NetworkManager.


> Why do we have more than one program that controls 3G connections?

Because it is Linux, not Windows. It is a free country, take it or
leave it?


> There's a lot more to the problem than online/offline.

Well, you can design beautiful and advanced software architecture(s)
with multiple modules exchanging very fine-grained connection
information, I still think this will never change anything to the
simple online/offline problem described above.



Cheers,

Marc




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]