public digest · 5 picks
This Week: Local LLMs, LoRa Mesh, and a Clipboard Manager That Just Works
This week's list is a grab bag on purpose: an ADS-B container for plane spotters, the LLM runtime that basically everyone else is built on top of, a LoRa mesh library that takes embedded constraints seriously, a Rust replacement for corporate mouse software, and a clipboard manager that does exactly what it says and nothing more.
What ties them together is craft. None of these are flashy demos — they're tools built by people who use them daily and have opinions about how the edges should behave.
// pick 1 of 5
A multi-arch Docker container packaging FlightAware's PiAware feeder software with dump1090/dump978, supporting RTL-SDR and other SDRs. Aimed at ADS-B hobbyists running Raspberry Pis or other boxes who want to feed FlightAware without manually installing piaware on bare metal.
If you're feeding FlightAware data from a Raspberry Pi, this saves you from the usual dance of installing piaware on bare metal and hoping it survives an OS upgrade. The multi-arch build is real, and the use of s6-overlay for process supervision instead of a single bash entrypoint is the kind of detail that tells you the maintainers have actually operated these things in production, not just built them once.
The environment variable coverage is deep enough that it slots cleanly into the wider sdr-enthusiasts stack — ultrafeeder, dump978, relay configs — without you needing to hand-edit configs inside the container.
What to know going in: the BladeRF/HackRF/LimeSDR support advertised in the topics isn't actually finished — the README says so plainly, so don't pick this repo expecting multi-SDR out of the box. You'll also still need to blacklist kernel modules on the host for RTL-SDR, which the container can't do for you. And dump1090 compiles on first run rather than being baked in, so your first boot is slower than you'd expect.
View on GitHub → Our full take →
// pick 2 of 5
llama.cpp is the dependency-free C/C++ inference engine that made running LLMs and VLMs locally practical on everything from Raspberry Pis to multi-GPU servers. It's for anyone who needs to serve GGUF-quantized models without pulling in PyTorch or a Python runtime, and it underpins a huge chunk of the local-inference ecosystem (Ollama, LM Studio, etc. all sit on top of it or its ideas).
This is the engine quietly running under most of the local-LLM tools you've heard of, and the backend list is the best evidence of how seriously it's maintained — CUDA, Metal, Vulkan, SYCL, HIP, CANN, even RISC-V vector extensions, all actually built in CI rather than just claimed in a README. The quantization schemes here are the reference implementation; everyone else is copying ggml's homework.
llama-server ships an OpenAI-compatible API and a web UI, so it's not a toy CLI you graduate from — for a lot of people it's the whole deployment.
What to know going in: the public API isn't really documented in any normal sense, and there's a pinned issue asking what the API should even be — that's how unsettled the internals still are. Chat templates and tool-calling logic have grown organically across several parser layers and are genuinely hard to trace. And model support for brand-new architectures lags upstream transformers by days or weeks, so patience is part of the deal.
View on GitHub → Our full take →
// pick 3 of 5
MeshCore is a C++ library for building multi-hop LoRa mesh networks on embedded hardware (ESP32, nRF52, STM32). It targets developers building off-grid communication tools and competes directly with Meshtastic, positioning itself as more hackable and less opinionated about use cases. Ships with pre-built firmware, a web flasher, and mobile apps so non-developers can also use it.
MeshCore is the more hackable alternative to Meshtastic, and the embedded discipline shows: a strict no-dynamic-allocation policy after init that's actually enforced via a StaticPoolPacketManager, not just asserted in docs. Hardware support is wide — 40+ boards across ESP32/nRF52/STM32 with RadioLib wrappers for half a dozen radio chips — and identity/encryption via Ed25519 keypairs is structural to the protocol, not a bolt-on.
CI runs native unit tests plus per-firmware build checks, which is more rigor than most Arduino-ecosystem projects bother with.
What to know going in: the routing protocol lives mostly in comments and one markdown file, with no formal spec, so evaluating correctness or contributing to the core routing logic is genuinely hard right now. The wire format is explicitly not stable — V2 is still 'discussion and consensus' on the roadmap — so anything you build on top today could break later with no migration path. And despite being labeled C on GitHub, it's C++ heavily coupled to Arduino helpers, so porting off that stack is real work, not a config flag.
View on GitHub → Our full take →
// pick 4 of 5
OpenLogi is a Rust-based replacement for Logitech Options+ that talks directly to Logitech devices over HID++ without requiring an account or network access. It targets power users on macOS, Linux, and Windows who want plain-text config, a CLI, and no background telemetry. Still pre-1.0 but already shipping signed installers and NixOS module support.
OpenLogi replaces Logitech's Options+ with something that talks HID++ directly, needs no account, and phones home to nobody. The workspace is split into independently testable crates — hidpp protocol, device management, CLI, agent, GUI — and the lint setup (unsafe_code deny, unwrap_used and expect_used as warnings) is stricter than plenty of commercial Rust shops manage.
Linux support is a first-class citizen here, not an afterthought: udev rules, a systemd service, a NixOS module, and D-Bus MPRIS integration for media keys. The plain TOML config that syncs across machines is a real, concrete improvement over Options+'s cloud-account approach.
What to know going in: GPUI is pinned to zed's default branch via a floating git dependency, not a tag or hash, so a zed refactor could break your build between lockfile bumps. There's no compatibility matrix telling you whether your specific mouse's HID++ features are supported before you uninstall Options+. And it's pre-1.0 — the config format can and will change between releases with no documented migration path, which matters if you've scripted your setup.
View on GitHub → Our full take →
// pick 5 of 5
Maccy is a free, open-source clipboard history manager for macOS that lives in the menu bar and lets you search and recall previous clipboard entries via keyboard. It's for macOS users who want something like Alfred's clipboard history without paying for Alfred, or who want a dedicated tool with no fluff. Requires macOS Sonoma 14+.
Maccy does one job — clipboard history — and does it without dragging in Electron, subscriptions, or telemetry. It's native SwiftUI over CoreData, polls at a configurable interval, and correctly respects NSPasteboard's transient/concealed types so password manager entries don't leak into your history without you having to configure anything.
The AppIntents support is a nice surprise for something this small — you can wire clipboard actions into Shortcuts automations. Localization is also unusually thorough, with 30+ languages including RTL scripts, maintained by the community through Weblate.
What to know going in: auto-paste needs Accessibility permission, which is a hard no in some managed/enterprise environments with no fallback. There's a known keyboard-shortcut trap in password fields that requires installing Karabiner-Elements to fix, which is a heavy dependency for a small annoyance. Search is substring/fuzzy only with no content-type filtering, and pinned items get random, non-configurable keyboard shortcuts that get confusing past about nine pins.
View on GitHub → Our full take →
That's five. If you want this in your inbox instead of hunting for it, the signup's below — same format, same amount of honesty about the rough edges.
Get this in your inbox →