| 30 Jun 2025 |
 emily | we just started the process of not making it the default option any more | 15:02:41 |
| emily | it will probably be timed roughly around the systemd stage 1 transition | 15:02:57 |
| emily | expect 25.11 to ship with different defaults and deprecations/removals around 26.05, 26.11, say | 15:03:14 |
| emily | though we were meant to flip some of those defaults releases ago already :) | 15:03:25 |
 Molly Miller | okay | 15:03:40 |
| Molly Miller | with my work hat on: we rely really heavily on scripted networking internally, though i've long been expecting that it'll eventually be removed | 15:04:36 |
| Molly Miller | one of my colleagues has suggested that we (flying circus) might be able to take over maintainership of the scripted networking support, though i have the impression that having more than one network configuration subsystem in the tree is an ongoing maintenance headache | 15:05:55 |
 clerie | You don't want this, really /o\ | 15:06:46 |
| emily | I don't think there's the appetite for it – if anything it seems like the path is likely to be deprecating the networking.* interfaces entirely | 15:07:11 |
| emily | in favour of NM or direct use of systemd.network.* | 15:07:18 |
| emily | rather than maintaining our own abstraction layers | 15:07:24 |
| emily | OTOH I think that means there's nothing preventing maintenance of an identical not-networking.* interface out of tree? | 15:07:42 |
| Molly Miller | true, that's an option to bear in mind | 15:08:05 |
| emily | I think the focus right now is more on getting new users off it and explicitly signalling deprecation than immediate removal though | 15:08:19 |
| emily | but given that useNetworkd is a seamless switch for probably >95% of existing users of the interface I'm also not sure there'll be much desire to keep the scripted code around for too long after flipping the default backend for that stuff | 15:09:04 |
 K900 | Honestly | 15:09:51 |
| Molly Miller | my colleagues are a little skeptical of networkd given that in the past the official answer from upstream regarding online reconfiguration has been "just reboot", which is a bit impractical when you have several racks full of servers which each take several minutes to boot, though i'm aware that networkd has grown much better online reconfiguration functionality in recent years | 15:09:52 |
| K900 | I don't even know the size of your org | 15:09:56 |
| emily | (Matrix ID is a hint :p) | 15:10:08 |
| K900 | But I can promise you porting to networkd will be less pain than maintaining networking.interfaces | 15:10:12 |
| Molly Miller | :) | 15:10:14 |
| emily | I'm unconvinced scripted networking has advantages over networkd in that area in 2025 | 15:10:47 |
| emily | there is also IfState | 15:10:57 |
| emily | we have no integration for that but if you don't like networkd maybe it might be an interesting migration target | 15:11:10 |
| Molly Miller | if networkd can handle online interface renaming then it's probably doable | 15:11:26 |
 hexa | no, that's a udev skill | 15:11:38 |
| hexa | still requires rebooting | 15:11:41 |
| emily | and RFC 42 style integration for that seems like something we'd accept in NixOS | 15:11:43 |
| emily | networkd can rename interfaces | 15:11:56 |
| emily | but maybe I misunderstand | 15:12:21 |
