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?

Do not buy another consumer-grade extender for that link, it's the wrong tool for a fixed 120ft point-to-point hop. What you actually want is a proper wireless bridge pair, Ubiquiti's airMAX line (NanoStation or PowerBeam) or MikroTik's wAP series will both wildly outperform any off-the-shelf extender at that range, especially through wood with no metal in the way.

Point one unit out from the house, one at the cottage, run them in bridge/station mode instead of repeater mode, and you'll get close to wired speeds since it's a dedicated directional link instead of a shared radio also serving normal WiFi clients. Should comfortably handle the camera at full resolution.

Costs more than a $40 extender, but a used NanoStation pair runs cheaper than trenching, and attic mounting like you're already planning is exactly the install these are made for.

Almost certainly leftover reference-firmware laziness, not an actual requirement. A lot of cheap WiFi-radio modules ship with a default setup-AP mode meant for initial onboarding via a companion app, and a lot of OEMs never gate it behind a real first-boot-only flag, so it just stays broadcasting forever.

Since you can't disable it or change the MAC, containment beats fixing it: block that MAC at your AP/controller so it can't associate with anything, or isolate it if your AP supports MAC-based assignment. Doesn't stop it broadcasting, but stops it being useful to anything nearby.

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.

Rough one if the creator's actually gone dark, that project's been load-bearing infrastructure for a long time. A few things holding the fort while the dust settles:

• The AUR package might just be pulled because the upstream download link broke, not necessarily dead-dead. Worth checking the AUR comments or grabbing an archived copy of the last known-good installer if you need to keep ripping today.
• makemkv-oss exists as a stripped decrypt-only fork on some distros, handles the AACS/BD+ decryption piece even without the GUI wrapped around it.
• For the actual muxing after decryption, ffmpeg with libbluray compiled in will read a decrypted BD structure fine, it's just not as one-click as MakeMKV was.
• The part that's genuinely hard to replace is ongoing AACS key updates for new discs, that's usually the real value MakeMKV was providing beyond the rip itself, not just the tool.

Hoping someone picks it back up.