| 16 Jun 2025 |
 emily | (for the resolvconf command) | 04:35:30 |
| emily | no, it uses the module system to link it to the /run path | 04:35:52 |
| emily | resolvconf bypasses it entirely | 04:35:55 |
| emily | I think that we need an assertion preventing both services.resolved.enable and networking.resolvconf.enable | 04:37:25 |
| emily | however I suspect in your case stuff is setting networking.resolvconf.useLocalResolver but not networking.resolvconf.enable explicitly | 04:37:37 |
 hexa | right | 04:37:38 |
| emily | so there's not an actual conflict, just networking.resolvconf.enable defaulting off because there's an explicit resolv.conf symlink because of services.resolved.enable | 04:38:00 |
| emily | and I'm not sure if asserting on networking.resolvconf.useLocalResolver when !networking.resolvconf.enable makes sense | 04:38:11 |
| emily | since usually module options are meant to be inert if the module is not enabled | 04:38:18 |
| emily | (agreed that there's a UX issue here I'm just not sure what the best solution is) | 04:38:36 |
| emily | it might be best to move the useLocalResolver outside of the resolver services altogether | 04:40:10 |
| emily | since arguably enabling a service changing your resolv.conf is a bit action-at-a-distance to begin with | 04:40:35 |
| emily | alternatively, lift useLocalResolver outside of networking.resolvconf, have services.resolved.enable either handle it or assert on it | 04:41:09 |
| 17 Jun 2025 |
|  jopejoe1 (4094@39c3) changed their display name from jopejoe1 (4094@eh22) to jopejoe1 (4094@GPN23). | 12:06:53 |
 Zhaofeng Li | by the way, has anyone tried one of those smart SFP optics? | 15:53:38 |
| Zhaofeng Li | not a new thing (might have even mentioned this in this channel), but never really got to give it a try | 15:53:58 |
| Zhaofeng Li | * | 15:54:20 |
 K900 | Why tho | 15:55:42 |
| K900 | Like in most cases they're absolutely evil | 15:55:51 |
| K900 | And don't actually do anything your router can't do | 15:55:59 |
| K900 | The one exception is PON modems which are just absolutely evil | 15:56:08 |
| Zhaofeng Li | well, they are cool and you can probably do some fancy filtering/rewriting even with a dumb switch | 15:57:03 |
| emily | I just don't know why you'd want mystery Linux running on a tiny little metal thing when you can run Linux on the thing it plugs into instead | 16:01:11 |
|  Autiboy joined the room. | 16:07:47 |
| Zhaofeng Li | so you can add some latency that mysteriously appears every other Saturday at 1am? 😈 apart from that, one actually useful thing I can think of is running tailscale on it to provide resilient OOB access to the switches/server IPMI/etc | 16:10:55 |
| Zhaofeng Li | there are some more ideas: https://blog.benjojo.co.uk/post/smart-sfp-linux-inside | 16:11:08 |
| emily | it's an additional point of failure, right? I don't see how it's necessarily more resilient than what you'd run on the switch | 16:16:20 |
| Zhaofeng Li | well, not everyone has the luxury of having a Linux-capable (or Linux-accessible) switch | 16:19:32 |
| emily | a Linux-capable SFP+ is also its own even rarer luxury, right? :P | 16:20:30 |
| Zhaofeng Li | and the power situation is presumably better than a device plugged in separately? | 16:20:33 |
