Solid list. Two more for a ZFS-based box: cap zfs_arc_max explicitly if idle RAM usage matters, ZFS will happily eat most of your RAM for ARC and won’t always release it cleanly, keeping memory controllers busier than needed at idle. And check hdparm -B / hd-idle for spinning drives not in constant use, letting them actually spin down makes a bigger power dent than people expect.

Good writeup. One caution from having done this on a couple boxes: test stability after flipping ASPM on, especially with NVMe drives in the mix. There is a known class of Linux kernel PCIe ASPM bugs where L1/L1.1 substates cause certain NVMe (and some USB3) controllers to drop out under load, especially on older Intel platforms. If a boot drive starts acting flaky after enabling this, ASPM is worth reverting before chasing anything else.

This is exactly the kind of project that’s easy to take for granted until the day you need a specific BIOS and every download you find is dead or unverifiable. Checking against emulator source rather than trusting whatever’s floating around is the right call, that’s usually where these collections go wrong.

Bookmarked for when my Batocera box inevitably needs a re-flash. Do you have a cadence for pulling in new releases as RetroArch etc. cut new versions, or is this more of an as-needed refresh?

If you’re on anything with a reasonably current systemd (248+, so basically any Debian 12/Fedora/Arch box), FIDO2 via systemd-cryptenroll is the one I’d reach for first, no extra daemons, actively maintained since it’s just systemd itself.

HMAC-SHA1 (yubikey-luks project) is the most battle-tested of the three, but it’s a third-party keyscript hook with spottier maintenance over the years. The SHA1 part isn’t actually a security weakness here since it’s HMAC challenge-response, not collision resistance, so don’t let the algorithm name scare you off it.

OpenPGP-on-Nitrokey is the heaviest of the three (needs gpg/scdaemon alive in initramfs), but worth it if you’re already using the OpenPGP applet for SSH auth or email signing.

I run FIDO2 with a TPM2 enrollment as fallback so a lost key doesn’t lock me out entirely.

True fully-open WiFi camera hardware is basically nonexistent. Closest you’ll get is OpenIPC (openipc.org), open source firmware for the SoCs a bunch of budget cameras use, but it’s a compatibility gamble per exact model, not plug-and-play.

More realistic path for a Tapo-style setup: keep the camera on an isolated VLAN with zero internet route (kills the cloud phone-home even on stock firmware), point it at a self-hosted NVR like Frigate or Shinobi over local RTSP/ONVIF, and never touch the TP-Link app or cloud account. Doesn’t make the firmware itself open, but it makes the actual footage 100% local, which is usually the part people actually care about.

If you specifically want reflashable open firmware, OpenIPC’s supported-devices list is worth checking before buying anything new.

Pangolin’s default docker-compose ships its own Traefik container, and that’s almost always what’s actually fighting your existing one, not a config typo on your end. Two ways out of it that I’ve seen work:

• Comment out the traefik service in Pangolin’s compose file entirely and let your existing traefik instance handle routing via labels. Pangolin’s docs have a section for using an existing reverse proxy that walks through pointing your own traefik at Gerbil’s exposed port instead of the bundled one.
• Or the reverse: let Pangolin’s traefik own ports 80/443 and demote your main one to a different port/internal-only role if it’s not doing much else.

First option is cleaner if your main traefik is already handling other services and you don’t want two separate ACME/cert setups running side by side.