On Tue, 09 Jul 2024 at 10:57:39 +0200, Matthias Urlichs wrote:
> Agreed: either it's drop-in compatible or we may as well switch the
> default to NM and/or systemd-networkd.
>
> Well, here's a heretical thought: why don't we do that anyway, at least for
> new
> installations?
To some extent, we are already there: for new laptop/desktop
installations, NM is already the default (certainly true for GNOME,
and hopefully for most/all of the other tasksel-supported desktops).
For new server/embedded installations, I think networkd would be a
better default than ifupdown (I switched my servers from ifupdown to
networkd sometime between Debian 9 and 10, according to the etckeeper
logs). See my recent mail about how we should probably not be inventing
Debian-specific container frameworks that will end up with one overworked
maintainer being a single point of failure for the distribution, but
replace "container framework" with "network management tool" and the
same ideas are equally valid. Like Podman in the containers space, NM
and systemd-networkd both have the advantage of being used outside the
Debian bubble, sharing the responsibility for their continued existence
among *considerably* more people.
networkd seems like an entirely reasonable implementation of "make the
easy things easy" (/lib/systemd/network/80-ethernet.network.example
shows how to bring up DHCPv4 and DHCPv6 on every Ethernet device in 4
non-comment lines, without having to hard-code the name of any specific
device), which is the main thing we want from a default - I continue to
believe that defaults should be chosen to be appropriate for new users
without specialized requirements, because experienced users already
know how to apply different configuration if they want to, and users
with specialized requirements will have to apply special configuration
to achieve what they require whatever we do.
At the same time, networkd also has "make the hard things possible"
available in its configuration language (see man pages for details).
I'm sure that when ifupdown was written, having our own network management
tool was seen as a necessary part of providing an OS distribution
(in the same way that the Red Hat family historically had its own
framework based on /etc/sysconfig, and so on), but thankfully things
have changed since then, and we now have non-distro-specific network
management components that can do just as good a job (if not better). It
used to be the case that ifupdown could bring up many network interfaces
"statically" with no extraneous background processes, but available RAM
has grown by several orders of magnitude, and DHCP and modern wifi both
require long-running processes to supervise them *anyway*, making that
much less of an advantage.
Of course, there is nothing to stop anyone who is interested in it from
keeping non-default frameworks available, either Debian-specific or not -
if nothing else, users of non-systemd init systems are going to want an
alternative to networkd - but if those frameworks aren't load-bearing for
the distribution as a whole, then that will give their maintainers less
support burden and more freedom to experiment.
smcv
