| 29 Jun 2025 |
 hexa (clat on linux when) | and not network.interfaces.<name>dhcp.enable | 02:31:33 |
| hexa (clat on linux when) | it does not | 02:31:38 |
 emily | I believe both exis? | 02:31:45 |
| emily | * I believe both exist? | 02:31:46 |
| hexa (clat on linux when) | I don't want to force people onto networkd | 02:31:47 |
| hexa (clat on linux when) | * I don't want to force people onto networkd specifically | 02:31:49 |
| hexa (clat on linux when) | I want to force them off of scripted networking | 02:31:57 |
| emily | well, I think the idea of useNetworkd was precisely to be able to move everyone from scripted networking to networkd without having to break every single networking configuration in existence | 02:32:17 |
| emily | I think it's a lot easier to sell a flag day when it doesn't break the most basic networking config | 02:32:32 |
| emily | gradually deprecating the old stuff is going to be easier after everyone is already running an implementation backed by the migration path | 02:32:53 |
| hexa (clat on linux when) | it boils down to us being bad at deprecating interfaces | 02:32:56 |
| hexa (clat on linux when) | do you think we should support the old option interface indefinately then? | 02:33:21 |
| hexa (clat on linux when) | * do you think we should support the old option interface indefinately then and just deprecated the backend? | 02:33:27 |
| emily | not necessarily | 02:34:00 |
| hexa (clat on linux when) | because I would really hope that the average nixos user would arrive at a place where they can apply 7 lines of config for an interface | 02:34:02 |
| hexa (clat on linux when) | * do you think we should support the old option interface indefinately then and just deprecate the backend? | 02:34:12 |
| hexa (clat on linux when) | https://wiki.nixos.org/wiki/Systemd-networkd#Examples already covers the basic use cases | 02:34:43 |
| emily | but I think "ok, we're switching the backend, people have been using this for years but let us know if you run into any issues" → "ok, we're moving away from these options, you're already using networkd under the hood so you can migrate to an identical configuration" is easier to do as those two steps than if they have to switch both backend and migrate their config at the same time | 02:34:46 |
| hexa (clat on linux when) | they will still have to map the configuration from a to b | 02:35:12 |
| emily | yeah, but it will not risk behavioural changes at that point | 02:35:28 |
| emily | it disentangles the two parts | 02:35:39 |
| hexa (clat on linux when) | they will not understand the mapping | 02:35:45 |
| hexa (clat on linux when) | * they will not understand the mapping that they've used though | 02:35:51 |
| hexa (clat on linux when) | sure, you can inspect that with the repl | 02:36:05 |
| hexa (clat on linux when) | but who will realistically do that | 02:36:09 |
| hexa (clat on linux when) | it would probably be best to provide an alternative to networkd like ifstate and then set a date for 3 years in the future | 02:37:34 |
| emily | I just generally feel it is better when you can make changes to interface and implementation separately. not always possible. but e.g. a zero-rebuild package refactor PR followed by something that cleans up the actual build process is way better than the two separately IMO | 02:37:37 |
| hexa (clat on linux when) | when the interface goes away | 02:37:38 |
| emily | because you can verify the first part easily, and do not have to treat it as an entire rewrite | 02:37:54 |
| hexa (clat on linux when) | and start warning actively | 02:37:59 |
