| 29 Jun 2025 |
 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 |
| emily | if useDHCP and basic static IP/routing configuration works, probably we do not need to support openvswitch or whatever | 02:41:39 |
| emily | you can tear those parts out and point to the native networkd options | 02:41:52 |
| emily | and at the point where it is just a very simple layer for the most basic networking configuration I don't think it would be meaningful tech debt at all, but you still avoided breaking "every config that sets up the most basic network stuff" | 02:42:35 |
| emily | * anyway I think most of the friction of the deprecation here just comes from breaking something ~every single system has for really basic needs | 02:42:42 |
| hexa | networkd has no ovs support, that's why that part is hacky | 02:42:47 |
| emily | right | 02:42:57 |
| hexa | any ovs support should go in a services.openvswitch module though | 02:42:59 |
| hexa | but the ovs package is barely maintained as well | 02:43:05 |
| emily | well substitute any of the "fancy" stuff in there as an example :p | 02:43:05 |
| emily | if you are configuring big brain stuff then little basis to object to switching to the native options | 02:43:21 |
| emily | it's the "I just want DHCP" or "I just want this IP" usecase where it is annoying to break every single user | 02:43:40 |
