Hi all!
On 04.09.24 15:46, Marc Haber wrote:
On Wed, 4 Sep 2024 11:27:45 +0200, Chris Hofstaedtler
<z...@debian.org> wrote:
* Marco d'Itri <m...@linux.it> [240903 14:04]:
My position is that I am happy for Debian to have the option of netplan
but I do not think that it should be installed by default, because it is
an abstraction which adds complexity and that nobody asked for other
than its developers.
And this is an orthogonal issue with deciding if ifupdown is appropriate
for a modern system (I have been using it for close to 30 years and at
this point I think that it has served its purpose and there are better
defaults...).
I want to echo all of this. All my customers sites are currently
migrating away from ifupdown to networkd, and they don't need or
want an intermediate layer.
For the desktop(-like) systems, NetworkManager works nicely, again
without a need for an intermediate layer.
This, and this.
Again, having the option is nice. But I don't see netplan as a
useful default.
And, choosing Netplan as a default doesn't solve the issue, since we'd
still have to decide what we'd use below it by default, leaving us
with the same hard decision: NetworkManager which bears its mock name
NetworkDamager for a reason, systemd-networkd which is kind of
unsuitable for desktop(-like) systems, comes from the much-hated
systemd world (thus igniting a systemd debate everywhere it is
mentioned) and contains way to much not-invented-here code regarding
IPv6, or ifupdown, which is outdated if I'm being friendly, and a
Debianism.
That's exactly the point of Netplan. Try looking at the bigger picture:
Debian as a whole.
With Netplan we could provide coherent network configuration across all
variants of Debian (server, cloud, laptop, ...), while choosing the best
underlying stack for the usecase (i.e. systemd-networkd on server/cloud
and NetworkManager on desktop/laptop).
Yes, it's an additional abstraction layer, but it brings the big benefit
of coherence across Debian. Not confusing our users by having 4 different
ways to do network configuration.
In our documentation we could reference a single Netplan configuration,
that would get applied to both of the underlying stacks. As stated
previously, advanced users can easily configure the underlying stack
natively and Netplan will get out of their way.
Cheers,
Lukas
