Re: proposal: Hybrid network stack for Trixie

[Josh Triplett]

Simon McVittie wrote:
> On Sun, 22 Sep 2024 at 12:22:50 +0200, Chris Hofstaedtler wrote:
> > d-i could make (or offer) a choice between networkd and
> > NetworkManager.
>
> d-i *already* makes a choice between ifupdown and NetworkManager: if
> NM has been pulled in by a task's dependencies (e.g. this happens when
> you install the GNOME or KDE desktop, among others), it writes out NM
> config, else it writes out ifupdown config. I believe a 1:1 replacement
> of ifupdown with networkd in the packages and configuration provided by
> new installations would do what I think you're proposing.

There's one other desirable feature that would make this a robust
solution: having NetworkManager do something to handle or ignore
interfaces managed by networkd.

Currently, NetworkManager has a plugin for ifupdown; it doesn't allow NM
to *manage* interfaces handled by ifupdown (other than bringing them up
or down), but it's enough to ensure that NM doesn't disrupt
ifupdown-managed networking. (That's important, for instance, to make
sure that installing NetworkManager doesn't abruptly disrupt the
network mid-install.)

I am *not* suggesting that a prerequisite would be any kind of *full*
integration with networkd that allows NM to meaningfully configure it.
I'm suggesting that, with systemd-networkd installed and managing some
interfaces, installing NetworkManager should not touch those interfaces
in any way. (Ideally, NM guis would also give some indication of "you
might want to remove the networkd configuration if you want NM to manage
these interfaces, such as automatically switching between wired and
wireless".)


Apart from that, +1 for the plan of choosing between networkd and
NetworkManager, and *not* introducing any layer of indirection. The
primary point of NetworkManager is to support its
management/configuration GUIs, so we *especially* shouldn't have a layer
of indirection that doesn't treat the GUI-based configuration as
primary.

Re: proposal: Hybrid network stack for Trixie

[Jonas Smedegaard]

Quoting Sirius (2024-09-22 17:22:21)
> On fre, 2024/09/20 at 13:12:36 +0200, Lukas Märdian wrote:
> [snip]
> > # Proposal
> > My proposal is to enable a hybrid network stack, using systemd-networkd (on
> > server/cloud/container/embedded systems) and NetworkManager (on 
> > desktop/laptop
> > systems) unified through a common layer of Netplan configuration on top, to
> > avoid fragmentation. This utilizes 3 tools that are under active upstream
> > development and are already used as defaults in certain variants of Debian
> > today. Furthermore, it allows people to control this stack on the native
> > systemd-networkd/NetworkManager layer directly, while at the same time
> > providing a way to describe network configuration that is common across 
> > Debian.
> > 
> > I've repeated the reasons why I think a hybrid stack using Netplan is a
> > feasible solution many times in previous threads, therefore I'd like to 
> > refer
> > to a list of frequently asked questions, instead of spreading more reasons
> > across more replies: https://wiki.debian.org/Netplan/FAQ
> 
> If at all possible, permit it to also run without systemd and/or
> Network-Manager in the mix, for use-cases where all the bells and whistles
> (and complications, and deep integration into things it does not need to
> integrate into, nor necessarily should integrate into, like SSH server)
> is not required.
> 
> To have Netplan as an option (which should be the case for systemd and
> Network-Manager as well, options) seems very sensible IMHO.

Netplan seems like *different* bells and whistles, rather than none.

If you want no belss or whistles, then install neither of ifupdown,
network-manager nor systemd-networkd, and operate your network using ip
and (unless you also consider that a too large bell) iwd.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: proposal: Hybrid network stack for Trixie

[Josh Triplett]

On Sun, Sep 22, 2024 at 10:30:12PM +0200, Andrea Pappacoda wrote:
> On Sun Sep 22, 2024 at 8:06 PM CEST, Josh Triplett wrote:
> > There's one other desirable feature that would make this a robust
> > solution: having NetworkManager do something to handle or ignore
> > interfaces managed by networkd.
> 
> If I'm interpreting correctly what you mean, this should already be
> possible, see .

That's exactly what I mean, and that looks promising! As long as the
version of NetworkManager in Debian supports that, this should work
perfectly out of the box, even when a user installs a non-GUI system and
later installs a GUI that includes NetworkManager.

Re: proposal: Hybrid network stack for Trixie

[Andrea Pappacoda]

On Sun Sep 22, 2024 at 8:06 PM CEST, Josh Triplett wrote:
There's one other desirable feature that would make this a robust 
solution: having NetworkManager do something to handle or ignore 
interfaces managed by networkd.


If I'm interpreting correctly what you mean, this should already be 
possible, see .


signature.asc
Description: PGP signature

Re: sensible languages for younger contributors (was Re: lintian.debian.org off ?)

[thomas]

On Sep 22, 2024 5:05 PM, Jonathan Dowland  wrote:

>

> On Wed Sep 4, 2024 at 8:33 PM BST, Serafeim (Serafi) Zanikolas 

> Or maybe the issue isn't difficulty, but 

> that doing so is simply unattractive? 


Rewriting things just to change language is indeed unattractive.


> (Please, not Python :P) 


Why? If one looks at popularity, Python wins...


Thomas Goirand (zigo)

Re: proposal: Hybrid network stack for Trixie

[Hakan Bayındır]

> On 22 Sep 2024, at 14:47, Chris Hofstaedtler  wrote:
> 
> As far as I understood Lukas' mail, then at least currently not, as
> NM in Debian doesn't come with patches to support two-way
> configuration with netplan.

I think this is a very serious regression for desktop systems. Debian started 
shipping non-free firmware recently, enabling “one click networking (TM)” in 
terminal and desktop systems. Taking this capability away from users and expect 
them to fiddle with their system in the first five minutes to get this 
capability back will not help Debian’s image, esp. in the eyes of new users and 
beginners.

Not being able to work with plethora of NetworkManager GUIs already integrated 
into desktop environments out of the box is both very backwards and is one of 
the “Debianisms” which people want to prevent.

Best,

H.

Re: proposal: Hybrid network stack for Trixie

[Sirius]

On sön, 2024/09/22 at 23:41:56 +0200, Jonas Smedegaard wrote:
> Netplan seems like *different* bells and whistles, rather than none.

True.

> If you want no belss or whistles, then install neither of ifupdown,
> network-manager nor systemd-networkd, and operate your network using ip
> and (unless you also consider that a too large bell) iwd.

I did switch to ifupdown-ng (as it seems the regular ifupdown is on its
way out) and the one thing I noticed was that ifupdown-ng does not handle
the include directive for /etc/network/interfaces.d/. Not a big issue, did
not take long to consolidate the interfaces into /etc/network/interfaces
and then it works great.

iwd and ifupdown{,-ng} works, and works well, but what I like about them
most is that they have lean dependencies and focus on one thing in true
unix fashion. I can sidestep both systemd and Network-Manager entirely
with a few rebuilt packages. That works for me.

-- 
Kind regards,

/S

Re: proposal: Hybrid network stack for Trixie

[Simon McVittie]

On Sun, 22 Sep 2024 at 12:22:50 +0200, Chris Hofstaedtler wrote:
> d-i could make (or offer) a choice between networkd and
> NetworkManager.

d-i *already* makes a choice between ifupdown and NetworkManager: if
NM has been pulled in by a task's dependencies (e.g. this happens when
you install the GNOME or KDE desktop, among others), it writes out NM
config, else it writes out ifupdown config. I believe a 1:1 replacement
of ifupdown with networkd in the packages and configuration provided by
new installations would do what I think you're proposing.

> Given d-i then will have to make a choice, *none* of the networking
> stack packages should have a "Priority:" higher than optional.

This is technically true, because sd-networkd is part of systemd.deb which
has Priority: optional, but in practice it gets pulled in by the init
metapackage on full/bootable systems (unless manual steps have been taken
to select a non-default init system).

Whether interfaces are configured by sd-networkd is a matter
of configuration, rather than what packages are installed:
if you want it to be responsible for bringing up networking,
you need to configure it (minimally by copying or symlinking
e.g. /usr/lib/systemd/network/80-ethernet.network.example
into /etc/systemd/network/) and enable it (systemctl enable
systemd-networkd.service).

smcv

Re: proposal: Hybrid network stack for Trixie

[Chris Hofstaedtler]

* Marc Haber  [240922 13:08]:
> On Sun, 22 Sep 2024 12:22:50 +0200, Chris Hofstaedtler
>  wrote:
> >The "server" group supposedly wants (and I agree) networkd,
> >but they also want the configuration interface of networkd.
> 
> Ack. I'd love networkd to have some more robustness features, but
> netplan doesnt add anything here.
> 
> >The "laptop" group supposedly wants (and I agree) NetworkManager,
> >but they also want the configuration interface of NetworkManager.
> 
> nack. I truly despise the configuration interface of NetworkManager,
> and I have never fully understood it. I still have NetworkManager on
> my notebooks because it interfaces nicely with the clickable frontends
> in the desktop environment.

TBH the "interfaces nicely with the clickable frontends" part is
what I meant here. I don't know if anyone likes nm-cli. When I use
NetworkManager on a desktop or laptop, then it is through one of the
GUI frontends. I assume this is what people want.

> Will I continue to have that luxury if we have netplan above n-m?

Very good question.

As far as I understood Lukas' mail, then at least currently not, as
NM in Debian doesn't come with patches to support two-way
configuration with netplan. I would understand if the NetworkManager
maintainers in Debian don't want to apply them as a Debian patch;
without having looked at the patches, the whole objective sounds
like the patches would be quite intrusive.

> I am all for d-i pre-choosing sane defaults for workstation/notebook
> setups. The server people are likely to use the expert install, have
> preseeded installs or their completely own installation methods.

As pointed out by Simon, this is already done depending on the
desktop selection. Which I didn't know, but sounds like the sane
thing to do!

Chris

Bug#1082574: ITP: aquamarine -- Light-weight rendering library for Linux

[Alan M Varghese]

Package: wnpp
Severity: wishlist
Owner: Alan M Varghese 
X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in

* Package name: aquamarine
  Version : 0.4.1
  Upstream Contact: vaxerski 
* URL : https://github.com/hyprwm/aquamarine
* License : BSD-3-Clause
  Programming Lang: C++
  Description : Light-weight rendering library for Linux

>From the readme:
Aquamarine is a very light linux rendering backend library.
It provides basic abstractions for an application to render on a
Wayland session (in a window) or a native DRM session.
.
It is agnostic of the rendering API (Vulkan/OpenGL) and designed
to be lightweight, performant, and minimal.
.
Aquamarine provides no bindings for other languages. It is 
C++-only

Aquamarine is a dependency for the Hyprland window manager. It
replaces the wlroots dependency.

Re: proposal: Hybrid network stack for Trixie

[Marc Haber]

On Sun, 22 Sep 2024 12:22:50 +0200, Chris Hofstaedtler
 wrote:
>The "server" group supposedly wants (and I agree) networkd,
>but they also want the configuration interface of networkd.

Ack. I'd love networkd to have some more robustness features, but
netplan doesnt add anything here.

>The "laptop" group supposedly wants (and I agree) NetworkManager,
>but they also want the configuration interface of NetworkManager.

nack. I truly despise the configuration interface of NetworkManager,
and I have never fully understood it. I still have NetworkManager on
my notebooks because it interfaces nicely with the clickable frontends
in the desktop environment. Will I continue to have that luxury if we
have netplan above n-m?

Another case are setups where some software expects to be able to
configure the network, with docker and libvirt being the most obvious
cases. libvirt comes with its own lay of indirection which has never
gotten enough traction to go beyond very basic support of ifupdown. I
don't know how this works, for example, on Ubuntu or Fedora.

>Given d-i then will have to make a choice, *none* of the networking
>stack packages should have a "Priority:" higher than optional. As
>in, even if we would go with netplan in d-i, there is no "default"
>anymore and people have to make choices.

I am all for d-i pre-choosing sane defaults for workstation/notebook
setups. The server people are likely to use the expert install, have
preseeded installs or their completely own installation methods.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: proposal: Hybrid network stack for Trixie

[Chris Hofstaedtler]

* Lukas Märdian  [240920 13:13]:
> I've repeated the reasons why I think a hybrid stack using Netplan is a
> feasible solution many times in previous threads, therefore I'd like to refer
> to a list of frequently asked questions, instead of spreading more reasons
> across more replies: https://wiki.debian.org/Netplan/FAQ
> 
> # Why
> The ifupdown package is a Debian only solution that is becoming a maintenance
> burden. We've had plenty of discussions over the years and consensus is that 
> we
> want to get rid of it.
> Some variations of Debian have already moved forward with choosing a different
> stack, such as desktop/laptop installations (using NetworkManager) and cloud
> images (using Netplan+systemd-networkd). Also, ifupdown-ng exists as a modern
> re-implementation of the classic tooling, that strives to become drop-in
> [compatible].

Thanks for providing the FAQ and this "Why" section, but it seems to
leave open why we would want or need netplan as the default. As the
FAQ shows, netplan is available as an optional package in many
distros. The same is already true in Debian thanks to you.

For your described usecase groups, which seem to clearly map to the
backends used by netplan, I do not see what netplan brings to the
table. The "server" group supposedly wants (and I agree) networkd,
but they also want the configuration interface of networkd.
The "laptop" group supposedly wants (and I agree) NetworkManager,
but they also want the configuration interface of NetworkManager.

Who actually wants the configuration interface of netplan,
especially by default?

I see nobody saying "yet another layer is a lot of fun!", and the
usecase groups do not overlap that much, that they both would *need*
the same interface? The opposite seems to apply.

> PS: I know this proposal doesn't please everybody, but I think it's the most
> actionable option that we have on the table and strikes a good compromise. As 
> a
> replacement for ifupdown is overdue, we should adopt our network stack for
> Trixie.

d-i could make (or offer) a choice between networkd and
NetworkManager. Doesn't have to be netplan. I can vaguely see how
d-i might be simpler by writing netplan config, but it still has to
make a choice of the default backend? And then what does netplan
help here?

Given d-i then will have to make a choice, *none* of the networking
stack packages should have a "Priority:" higher than optional. As
in, even if we would go with netplan in d-i, there is no "default"
anymore and people have to make choices.

Best,
Chris

Re: proposal: Hybrid network stack for Trixie

[Sirius]

On fre, 2024/09/20 at 13:12:36 +0200, Lukas Märdian wrote:
[snip]
> # Proposal
> My proposal is to enable a hybrid network stack, using systemd-networkd (on
> server/cloud/container/embedded systems) and NetworkManager (on desktop/laptop
> systems) unified through a common layer of Netplan configuration on top, to
> avoid fragmentation. This utilizes 3 tools that are under active upstream
> development and are already used as defaults in certain variants of Debian
> today. Furthermore, it allows people to control this stack on the native
> systemd-networkd/NetworkManager layer directly, while at the same time
> providing a way to describe network configuration that is common across 
> Debian.
> 
> I've repeated the reasons why I think a hybrid stack using Netplan is a
> feasible solution many times in previous threads, therefore I'd like to refer
> to a list of frequently asked questions, instead of spreading more reasons
> across more replies: https://wiki.debian.org/Netplan/FAQ

If at all possible, permit it to also run without systemd and/or
Network-Manager in the mix, for use-cases where all the bells and whistles
(and complications, and deep integration into things it does not need to
integrate into, nor necessarily should integrate into, like SSH server)
is not required.

To have Netplan as an option (which should be the case for systemd and
Network-Manager as well, options) seems very sensible IMHO.

> # Why
> The ifupdown package is a Debian only solution that is becoming a maintenance
> burden. We've had plenty of discussions over the years and consensus is that 
> we
> want to get rid of it.
> Some variations of Debian have already moved forward with choosing a different
> stack, such as desktop/laptop installations (using NetworkManager) and cloud
> images (using Netplan+systemd-networkd). Also, ifupdown-ng exists as a modern
> re-implementation of the classic tooling, that strives to become drop-in
> [compatible].

Question: is ifupdown-ng geared at replacing ifupdown as soon as the next
major release, and should those that today use ifupdown migrate to
ifupdown-ng proactively? And does Netplan generate ifupdown-ng
configuration, or it this strictly a helper-tool for systemd/NM?

> # Compatibility
> We do not want to break existing systems or people that want to keep using the
> classic way of /etc/network/interfaces.

Very glad to hear that.

-- 
Kind regards,

/S

Re: sensible languages for younger contributors (was Re: lintian.debian.org off ?)

[Charles Plessy]

Le Sun, Sep 22, 2024 at 04:05:08PM +0100, Jonathan Dowland a écrit :
> Perl is rusty

Well, if you forget what I wrote earlier about LLMs being a
copyright-laundering machine, I can tell you that if you ask for Perl to
ChatGPT, it does wonders.

Maybe if we had an LLM trained on Wikipedia plus everything available
under debian.org…

Cheers,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: proposal: Hybrid network stack for Trixie

[Ansgar 🙀]

Hi,

On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:
> I've repeated the reasons why I think a hybrid stack using Netplan is a
> feasible solution many times in previous threads, therefore I'd like to refer
> to a list of frequently asked questions, instead of spreading more reasons
> across more replies: https://wiki.debian.org/Netplan/FAQ

The FAQ states: "If native backend configuration is applied on top of
that, Netplan will now know, nor care about it (unless they try to
configure an interface controlled by Netplan in a conflicting way)."

What does that mean on desktop systems? What will happen when a user
wants to change the configuration using the UI (which usually talks to
NetworkManager)?

Ansgar

Re: proposal: Hybrid network stack for Trixie

[Jonathan Dowland]

On Sun Sep 22, 2024 at 12:47 PM BST, Chris Hofstaedtler wrote:
> TBH the "interfaces nicely with the clickable frontends" part is
> what I meant here. I don't know if anyone likes nm-cli.

I prefer it to `ip`, when I can get away with using it instead.


-- 
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

sensible languages for younger contributors (was Re: lintian.debian.org off ?)

[Jonathan Dowland]

On Wed Sep 4, 2024 at 8:33 PM BST, Serafeim (Serafi) Zanikolas wrote:
> incidentally, lots of Debian native code is in perl, and like it or
> not, we should allow for, or even encourage [0] (partial) rewrites if
> we want to attract new contributors, especially below the average DD
> age

I have some sympathy with this idea, but I'd love to see a rigorous
exploration of it. I probably fall on the greybeard side of the dividing
line now, and my Perl is rusty (but not non-existent). Partly I wonder
if we are underestimating younger folk by suggesting that grokking old
stuff like Perl is Too Hard. Or maybe the issue isn't difficulty, but
that doing so is simply unattractive?

If we did have consensus that Perl should be retired, the question
should be replaced *with what*? I'd be very surprised if we could get
consensus on that; but I'd happily read people's suggestions. I guess
you'd advocate for Rust or Go, based on your slide deck.

What criteria are important for such a recommendation?

(Please, not Python :P)

> [0] see slide 6 of 
> https://raw.githubusercontent.com/samueloph/personal_website_files/main/slides/samueloph_slides_2024_08_i_use_debian_btw.pdf

Slide 6 seems to be a picture of a Powerline terminal prompt.

Slide 7 seems relevant: since it's just two bullet points I'll reproduce
it here in its entirety:

Title: Rewrite in Golang/Rust BTW
 * Rewrite the same thing using a different language OR...
 * Start fresh with better defaults and UX



-- 
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Re: proposal: Hybrid network stack for Trixie

[Andrew M.A. Cater]

On Sun, Sep 22, 2024 at 03:45:30PM +0100, Jonathan Dowland wrote:
> On Sun Sep 22, 2024 at 12:47 PM BST, Chris Hofstaedtler wrote:
> > TBH the "interfaces nicely with the clickable frontends" part is
> > what I meant here. I don't know if anyone likes nm-cli.
> 
> I prefer it to `ip`, when I can get away with using it instead.
> 

if you don't have a desktop environment on either a laptop or a server,
then nm-cli / nmtui are a very useful way to do this.

This whole discussion has made me think about trying networkd-systemd to
see what its like.

Andrew Cater
> 
> -- 
> Please do not CC me for listmail.
> 
> 👱🏻Jonathan Dowland
> ✎  j...@debian.org
> 🔗 https://jmtd.net
> 

Re: sensible languages for younger contributors (was Re: lintian.debian.org off ?)

[Russ Allbery]

"Jonathan Dowland"  writes:

> If we did have consensus that Perl should be retired, the question
> should be replaced *with what*? I'd be very surprised if we could get
> consensus on that; but I'd happily read people's suggestions. I guess
> you'd advocate for Rust or Go, based on your slide deck.

> What criteria are important for such a recommendation?

> (Please, not Python :P)

I mean, you say that, but Python is by far the most obvious choice.  It's
the most popular programming language in the IEEE Spectrum 2024 survey by
a very large margin, and the next most popular languages (Java,
JavaScript, and C++) are all less suitable for this type of integration
programming.  You have to go down to eighth place before you find Go, at
about a fifth the popularity of Python.

Python is also replacing Java as the language of college CS classes, which
means the base of people who know at least some Python is probably larger
than any other language filling the same niche.

I think the only real competitor to Python today on the popularity and
existing knowledge front would be JavaScript, and I think it's less
suitable for the type of development we do in Debian.

-- 
Russ Allbery (r...@debian.org)