| 17 Jun 2025 |
 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 |
| Zhaofeng Li | well, rarer yes, but less expensive and disruptive to the existing infrastructure | 16:21:27 |
 raitobezarius | In reply to @emilazy:matrix.org
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 coughs nefarious purposes | 16:35:17 |
 Charles | i'm reminded of this article i just saw like 10 minutes ago https://hackaday.com/2025/06/16/an-open-source-justification-for-usb-cable-paranoia/ | 17:07:14 |
| raitobezarius | In reply to @charles:computer.surgery
i'm reminded of this article i just saw like 10 minutes ago https://hackaday.com/2025/06/16/an-open-source-justification-for-usb-cable-paranoia/ https://shop.hak5.org/ | 18:02:30 |
| Autiboy | Has anyone used NixOS to provision mikrotik routers? | 18:04:09 |
 zenware | In reply to @zhaofeng: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 At best it provides side-band access, out-of-band requires different communication infrastructure. e.g. Wireline/POTS, Radio, ... Such that if your SFP failed, you would still be able to access that system. While, it is kind of cool, by running inside the SFP you're practically more "in-band" than just a cable itself. | 19:39:01 |
|  plantfan27 joined the room. | 21:38:05 |
| 18 Jun 2025 |
|  @zeromute:matrix.org joined the room. | 00:52:32 |
 hexa | diff --git a/nixos/modules/config/resolvconf.nix b/nixos/modules/config/resolvconf.nix
index f9c9d04b3fbe..79d3b2043148 100644
--- a/nixos/modules/config/resolvconf.nix
+++ b/nixos/modules/config/resolvconf.nix
@@ -158,6 +158,10 @@ in
config = lib.mkMerge [
{
+ warnings = lib.optionals (!cfg.enable && cfg.useLocalResolver) ''
+ The resolvconf module was instructed to configure the local resolver (127.0.0.1, ::1) in /etc/resolv.conf, but resolvconf was disabled.
+ '';
+
environment.etc."resolvconf.conf".text =
if !cfg.enable then
# Force-stop any attempts to use resolvconf
| 06:40:23 |
| hexa | emily: roast me | 06:40:27 |
| hexa | (while I take a nap) | 06:40:32 |
| emily | In reply to @hexa:lossy.network
emily: roast me do we have precedent for this kind of thing? I feel like it's normal for modules to configure defaults for other modules that might not be enabled (and in general to expect that you can set foo.X harmlessly if !foo.enable). I feel like it would be better for the resolver service modules to either get out of the game of setting the local resolver entirely or to explicitly turn on resolvconf to cause an explicit conflict | 13:43:19 |
| emily | (or we could move the setting out of resolvconf and have the resolved module respect it but that might be tricky) | 13:43:44 |
 @alina:kescher.at | can someone please give me some feedback for how to deal with unbound's broken upstream?
https://github.com/NixOS/nixpkgs/pull/417917 | 17:49:03 |
| @alina:kescher.at | and my technically this is also my first nixpkgs PR because i have the tendency to rather not submit things that aren't entirely perfect, which i want to get rid off - i have like 10 different projects that are all 90% finished that i still want to upstream | 17:49:04 |
| @alina:kescher.at | * and technically this is also my first nixpkgs PR because i have the tendency to rather not submit things that aren't entirely perfect, which i want to get rid off - i have like 10 different projects that are all 90% finished that i still want to upstream | 17:49:12 |
 Alyssa Ross | In reply to @alina:kescher.at
can someone please give me some feedback for how to deal with unbound's broken upstream?
https://github.com/NixOS/nixpkgs/pull/417917 Contacting them is best. Looking at what other distros that try to stay up to date (like Fedora) do can also be helpful. You can find links to other distros' package builds using Repology. | 17:51:15 |
| Alyssa Ross | Have you checked whether unbound HEAD still needs this old version? | 17:52:07 |
| Alyssa Ross | Sometimes we can just backport a change that makes it compatible with new versions. | 17:52:30 |
| @alina:kescher.at | i assume so, since that feature was only introduced in 1.22.0 while we are now at 1.23.0 | 18:22:17 |
| @alina:kescher.at | but i'm having a hard time making sense of that huge autoconfigure mess | 18:22:36 |
| @alina:kescher.at | this is so fun, though i'm still a bit scared of messing up regarding social conventions around contributing to open source projects | 18:37:50 |
