| 29 Jun 2025 |
 hexa | and why the hell is it usedhcp? | 02:30:59 |
| hexa | * and why the hell is it useDHCP? | 02:31:19 |
 emily | I thought networkd didn't use dhcpcd | 02:31:29 |
| hexa | and not network.interfaces.<name>dhcp.enable | 02:31:33 |
| hexa | it does not | 02:31:38 |
| emily | I believe both exis? | 02:31:45 |
| emily | * I believe both exist? | 02:31:46 |
| hexa | I don't want to force people onto networkd | 02:31:47 |
| hexa | * I don't want to force people onto networkd specifically | 02:31:49 |
| hexa | 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 | it boils down to us being bad at deprecating interfaces | 02:32:56 |
| hexa | do you think we should support the old option interface indefinately then? | 02:33:21 |
| hexa | * 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 | 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 | * do you think we should support the old option interface indefinately then and just deprecate the backend? | 02:34:12 |
| hexa | 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 | 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 | they will not understand the mapping | 02:35:45 |
| hexa | * they will not understand the mapping that they've used though | 02:35:51 |
| hexa | sure, you can inspect that with the repl | 02:36:05 |
| hexa | but who will realistically do that | 02:36:09 |
| hexa | 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 |
