On Tue, Sep 28, 2021, 8:01 AM Henning Follmann <hfollm...@itcfollmann.com> wrote:
> On Tue, Sep 28, 2021 at 09:41:22AM +0200, to...@tuxteam.de wrote: > > On Mon, Sep 27, 2021 at 04:47:07PM -0400, Henning Follmann wrote: > > > > [...] > > > > > And N-M is not "buggy". [...] > > > > Uh-huh. > > > > What a great argument! > > But I play along. > Are there bugs filed against N-M? Yes there are! > Are there reasons why people have issues with N-M? You bet! > > Up until Jessie N-M had a lot of issues and missing features, which led to > .... > But since buster, if you trust the work and knowledge of the > package maintainers N-M results in reliable network configurations > when we are talking about a default desktop setup. Most issues here > are mainly related to propietary drivers from various chip > manufacturers and not an N-M issue. > But please stress your comment "when we are talking about a default desktop setup". In the non-desktop server environment, N-M is disabled. Indeed it is a type of risk. Last times I've been on AWS and Google cloud, their VM instances also remove N-M. Same reason. In these environments wifi does not exist, so network connections should be known ahead of time, and a fixed set. My comment to the OP was basically on the nebulous source (most VPN > Providers) > and the generalized categorization (N-M is buggy), which I disagree with. > That is not the view that I have heard expressed. N-M is a 1-size-fits-all approach to network setup that only fits 1 use-case. But we all get to have it :-) Some developers would call it "over engineered". That I agree with. -H > > > -- > Henning Follmann | hfollm...@itcfollmann.com > >
