- Posts

Bind mounts are useful on NixOS

Raymond Douglas — Sat, 01 Aug 2026 00:00:00 +0000

Often, a NixOS module will not surface an option for overriding the default filesystem path for that module's persistence. Labeled dataDir</code> or stateDir</code>, this option is useful for placing stateful data in a known location for backups or other organizational reasons.

In the case of the Unifi module</a> there is no such exposed option. Though Nix/NixOS has several solutions to this predicament.

In the module definition there is a clear let</code> variable for stateDir</code> already. But, let</code> expressions cannot be overridden by overrideAttrs</a>. And ${stateDir}</code> is called ten times in the module, and frequently interpolated into strings. It would be very annoying to override each calling attribute just to change this path.

The right thing to do is to open a pull request against Nixpkgs to surface dataDir</code> as an option, which someone did in January</a>. And it's clean because it only concerns the /data</code> subpath in the modules stateDir</code> root. The rest of the contents in stateDir</code> are not crucial for persistence.

        BindPaths = [</span></span>
          [...]</span></span>
+</span>         "${cfg.dataDir}:${stateDir}/data"</span></span>
          [...]</span></span>
        ];</span></span></code></pre>
But in the interim I will leverage filesystem bind mounts</a>, referencing the hard coded path in the module.</p>
{</span> ...</span> }:</span></span>
</span>
{</span></span>
  services</span>.</span>unifi</span> =</span> {</span></span>
    enable</span> = true;</span></span>
    openFirewall</span> = false;</span></span>
  }</span>;</span></span>
  </span></span>
  fileSystems</span>.</span>"</span>/var/lib/unifi/data</span>"</span> =</span> {</span></span>
    device</span> =</span> "</span>/persist/unifi</span>"</span>;</span> # Where I tend to keep things.</span></span>
    fsType</span> =</span> "</span>none</span>"</span>;</span></span>
    options</span> =</span> [ "</span>bind</span>" ]</span>;</span></span>
  }</span>;</span></span>
}</span></span></code></pre>
Pretty readable and understandable!</p>

Civic inheritance Raymond Douglas — Thu, 16 Apr 2026 00:00:00 +0000 Here in San Luis Obispo, the downtown area's street parking has largely migrated to license plate-tied pay stations and a PayByPhone mobile app</a>. When I began frequenting this area about ten years ago each designated street parking spot had a parking meter like you see above. It accepted coins, cards (chip or strip), and—more recently—contactless forms of payment. A given parking meter represented a one-to-one relationship with its physically adjacent parking spot. Associating a license plate with the parking payment was wholly unnecessary. The spatial association was obvious, and clearly enforceable by the city. PayByPhone</a> isn't a bad mobile app by any means. It even lets you pay for parking without creating an account (!), and remembers your vehicle/license plate history via local device storage. My most salient complaint—outside of its obvious contributions to mass surveillance—is that this license plate and database-driven parking system is anti-social. In the previous era, I could pre-pay for 45 minutes of parking whilst only needing 15 of those minutes. The remaining 30 minutes would remain associated with that parking spot and be civically inherited by the next person to park there. It was a passive pay-it-forward scheme and it was amazing. Arriving at a parking meter that had 25 minutes of remaining time from the previous person's transaction was like winning a tiny lottery. And with the roles reversed, it was the philanthropic mini-rush of giving $1.30</code> of value to a stranger. San Luis Obispo still has a number of these older meters at the edges of downtown. And when parking is necessary, I like to seek them out over the more modern alternative. A modified Casio F-91W Raymond Douglas — Sat, 21 Jan 2023 00:00:00 +0000 Having had—and seldom worn—an Apple watch since 2019 or so, I often found myself liking the idea of a smarter-than-typical watch but never quite aligned with the notification-heavy and tethered nature of the modern smart watch. A few months ago I came across this blog post</a> by John Graham-Cumming in which he performs a literal engine swap of his Casio F-91W</a> with a mainboard from Sensor Watch</a> (purchased from their Crowd Supply page</a>). This sweet little board is a drop-in replacement featuring: An ARM Cortex M0+ microprocessor</li> About a year's worth of battery life on a single CR2016</a> cell</li> A very accurate 32.768 KHz crystal</li> Red-ish, green-ish, and yellow-ish LED backlighting</li> Access to the original piezo buzzer with some light soldering</li> A 9-pin connector to access the I^{2C bus and five GPIO for additional sensing</li> </ul> So yes, I ordered an F-91W and a Sensor Watch mainboard with a thermistor sensor board.}Surgery</h3> What's nice is that all you need to perform this transplant is a small Phillips screwdriver, some tweezers (a nice-to-have), and a soldering iron/solder to move over the piezo buzzer clip. This video from the creator, Jose Castillo, is more than adequate to get things moving: </iframe> </div> Firmware</h3> By building and flashing the community Movement</a> firmware onto the board, you can leverage their toolchain to configure general functionality, and even design your own watch faces</a>. If all you're interested in is choosing and ordering the set of existing watch faces, you can do so via movement/movement_config.h</code> and re-compile/re-flash the firmware. My current watch face array: const watch_face_t watch_faces[] = { simple_clock_face, countdown_face, stopwatch_face, thermistor_readout_face, /* Requires the thermistor sensor board */ thermistor_logging_face, /* ^^^ */ pulsometer_face, day_one_face, sunrise_sunset_face, moon_phase_face, preferences_face, set_time_face, };</code></pre> The Sensor Watch board has exposed traces such that you can plug it directly into a USB Micro B cable and flash new firmware via the build-in UF2 bootloader. Easy. Docs are here</a>. Enjoyment</h3> I highly recommend this project if you're losing interest in smart watches, but still like the idea of a tiny ARM computer on your wrist. My Crowd Supply order shipped within a week—so this project is seemingly no longer in the pre-order phase! Intel X520: Enabling unsupported transceivers Raymond Douglas — Thu, 02 Jan 2020 00:00:00 +0000 Having recently set up a new-to-me Dell R720 in a colocation provider's environment—in my quest to "own" the whole stack from metal to service—I ran into an issue with not being able to use generic or Cisco-coded SFP+/SFP trancseivers in the included Intel X520</a> network card. dmesg</code> kept indicating that the transceiver was unsupported. Because of impatience and other factors, I decided to dig a bit and see what it would take to enable support for good 'ol grab bag generic SFP+/SFP transceivers. I came across this article</a> on the ServeTheHome forums where user NathanA had already dug to the bottom of this issue, and fortunately came out the other side with a solution. NathanA discovered—via datasheets, mailing lists, and discussion threads—that a particular bit in a particular byte of the NIC EEPROM needs to be flipped in order to allow any SFP. In the Linux ixgbe driver, the byte in question is referred to as IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP</code>. The steps to flip this bit, and thus allowing "unsupported" SFPs, is as follows: Note: I am in no way liable for any permanent damaged caused by running the following commands on your Intel NIC! Identify current value of offset 0x58</h3> $ sudo ethtool -e eno1 offset 0x58 length 1 Offset Values ------ ------ 0x0058: fc</code></pre>Write the new value to the card's EEPROM</h3> The new hex value below is identical to simply flipping the last binary bit in the fc</code> hex value. $ sudo ethtool -E eno1 magic 0x10fb8086 offset 0x58 value 0xfd</code></pre>Let's check if we were successful</h3> If the output of the command below returns the new value of our 0x58</code> offset, we should be good to go! $ sudo ethtool -e eno1 offset 0x58 length 1 Offset Values ------ ------ 0x0058: fd</code></pre> What's best about this EEPROM change is that is survives reboots, poweroffs, and will enable usage of unsupported SFPs in non-Unix operating systems. And, to return the EEPROM to its original state, simply write the old hex value back to the 0x58</code> offset and call it a day.

- Posts

Bind mounts are useful on NixOS

Civic inheritance

A modified Casio F-91W

Enjoyment</h3> </p> I highly recommend this project if you're losing interest in smart watches, but still like the idea of a tiny ARM computer on your wrist.</p> My Crowd Supply order shipped within a week—so this project is seemingly no longer in the pre-order phase!</p>

Intel X520: Enabling unsupported transceivers

Enjoyment</h3>
</p>
I highly recommend this project if you're losing interest in smart watches, but still like the idea of a tiny ARM computer on your wrist.</p>
My Crowd Supply order shipped within a week—so this project is seemingly no longer in the pre-order phase!</p>