| 29 Jun 2025 |
 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 |
| hexa | 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 | and start warning actively | 02:37:59 |
| emily | or configuration switching behaviour is a total mess also, but rewriting it bug-for-bug in Rust was the right choice, because we got rid of the Perl with very very little breakage compared to if we had tried to renovate the entire logic | 02:38:28 |
| emily | and now we have a codebase that is not ancient code in a language nobody wants to touch that improvements to the actual semantics can be iterated on | 02:38:43 |
| emily | switching out scripted initrd and cleaning up its exposed interfaces feel good to separate out for similar reasons to me | 02:39:06 |
| hexa | I just feel that people will be afraid of touching network related things and fight any deprecation of the networking interfaces | 02:39:51 |
| emily | I don't know why we need to provide an alternative though. we don't for systemd. if people hate networkd they can always assemble their own thing in their configs. I doubt there's anything scripted networking is good at that networkd is hopeless at, since scripted networking is not that great to begin with | 02:40:02 |
| hexa | because for some reason basic network knowledge is not very common for some reason | 02:40:06 |
| emily | and NetworkManager already exists/works too | 02:40:08 |
| hexa | * because for some reason basic network knowledge is not very common | 02:40:10 |
| hexa | fair | 02:40:29 |
| emily | anyway I think most of the friction of the deprecation here just comes from breaking something ~every single commit has for really basic needs | 02:41:02 |
| emily | what seems viable to me is switching out the implementation and then incrementally deprecating the gnarlier parts of the shim module | 02:41:20 |
