On Tue, 20 Jun 2023 at 05:03:19 -0400, nick black wrote:
> Simon McVittie left as an exercise for the reader:
> > At the moment I believe the status quo for d-i is that networking is
> > managed by NetworkManager if a desktop task happens to have pulled it in,
> > or ifupdown otherwise? And that seems reasonable (although I personally
> > prefer to set up systemd-networkd on servers).
>
> i don't wish to start an argument, but just to ask: everyone has
> recommended NetworkManager for workstations. i've been running
> systemd-networkd on everything (servers, laptops, and
> workstations) for several years now, usually in conjunction with
> dnsmasq and wpa_supplicant, and it's been pretty great. what
> does NetworkManager offer that makes it superior to
> systemd-networkd on the desktop (which i'm interpreting to mean
> "for interactive use")?
Ubiquitous user interfaces, mostly. Our default for laptops and other
portable computers needs to be something that lets a non-technical user
of GNOME/Plasma/etc. join a wireless network, without learning how to
write configuration files and operate sudo, and in practice that means
the various desktop environments' UIs for NM (or something analogous
like connman or wicd, but NM seems to be by far the best-supported choice
out of those).
I don't know enough about implementation details of NM and
systemd-networkd to know whether the API design of NM is more suitable
for that purpose, or whether the various UIs for NM and the absence of
UIs for systemd-networkd is just inertia; but in practice the network
configuration service that has first-class support in most of our desktop
environments (in particular GNOME and Plasma) is NM.
I was using "desktop" in the sense of task-gnome-desktop and friends, more
than as a class of hardware. Laptops and other portable computers are the
main thing that really needs easily user-configurable networking.
I think it makes sense for desktop/workstation hardware to be treated like
an oddly-shaped laptop by default, which means it gets the benefit of the
wider testing that goes into NM and its various user interfaces, rather
than having laptops and desktops behave differently for reasons that are
unlikely to be obvious to a new user.
Some users of desktop/workstation hardware strongly prefer to use a more
"static" network configuration service like systemd-networkd or ifupdown
so that they can rely on having the network setup not change under
them, particularly if they're using services like NFS filesystems or
LDAP authentication. That's an entirely reasonable thing to want to do,
but IMO this is an example of the design principle that the choice that
is better for non-technical users can make a better default, because
technically adept users who know they have particular requirements can
easily switch to what we might characterize as "server" infrastructure,
but non-technical users can't easily switch in the opposite direction
(or even know that they might want to).
A secondary benefit of NM is that it works on non-systemd-booted systems,
whereas systemd-networkd isn't designed for that use. I'm personally
happy with systemd as pid 1, but some people consider requiring systemd
as pid 1 to be a deal-breaker, and if NM is a good candidate for being
our default *anyway* then we might as well get that secondary benefit too.
smcv
