Transcribing 33,000 Danish voice logs on home GPUs — the local pipeline (2026)

2026-06-10T00:00:00+00:00

TL;DR —</strong> Business phone calls had been recorded for over a year: ~33,000 Danish mp3 files, ~570 hours, 32 kbps phone quality</strong>. The brief was to transcribe all of it, name the speakers, summarize per call / per day / per week, make it browsable — and do it locally, with no LLM API</strong>. The result is a pipeline that runs two ASR models and fuses them with Claude</strong>, identifies speakers from metadata before decoding any audio</strong>, heals itself across two GPUs</strong>, and uses Claude Code subagents as the summary layer</strong> instead of an API. Here’s the whole build, and what it teaches about a customer-service function.</p>

The grown-up sequel to running Whisper locally instead of a cloud Speech API</a>. Same instinct — keep the audio on your own box — at 33,000-file scale.</p> </blockquote>
Start by analysing the corpses</h2>
The folder already held nine half-finished attempts</strong> at this problem. Before writing anything new, three agents read all nine. Between them, the dead experiments contained almost every good idea the final system needed:</p>

One Python attempt (WhisperX + pyannote + Claude day-summaries) was the most complete — but had hardcoded API keys, an English-alignment bug on Danish audio, and mock diarization in the “real” pipeline.</li>
One had discovered the key trick: phone-first speaker identification</strong> (more below), and had already built voice profiles.</li>
A Go rewrite had a beautiful service architecture and a SQLite schema — but everything was stubs</strong>; zero segments were ever stored. Lesson: never build the shell before the signal path works.</li>
A benchmark harness had already compared six ASR models</strong> on the corpus.</li> </ul>
Synthesising the nine was far cheaper than inventing from scratch. Lesson one: analyse the corpses first.</strong></p>
The model benchmark</h2>
The pre-existing benchmark (on the RTX 4070 Ti) plus a fresh side-by-side settled the model choice:</p>
Model</th> Result</th></tr></thead>

faster-whisper large-v3-turbo</strong></td> Fastest — ~37× real-time, 1.8 GB VRAM. Great, but slips on noisy Danish.</td></tr>
faster-whisper large-v3 (full)</strong></td> Most coherent on real calls. ~18× real-time — fast enough. Chosen.</strong></td></tr>
hviske-v3-conversation</strong> (Danish fine-tune)</td> Catches Danish names/idioms the others garble. Chosen as the second track.</strong></td></tr>
Voxtral</strong></td> Hallucinated in loops (1,832 words for a 117-second call), language-bleed. Dropped.</strong></td></tr>
vibevoice</strong></td> ~6× slower than real-time. Dropped.</strong></td></tr> </tbody></table>
The non-obvious decision: run two models, not one.</strong> large-v3 and hviske fail differently</strong> — one has the grammar, the other has the Danish names — so keeping both and fusing them beats either alone.</p>
The pipeline</h2>
mp3 → ffmpeg band-pass (200–3400 Hz + light denoise + dynaudnorm) → 16 kHz mono → [A] faster-whisper large-v3 (int8_float16, beam 5, VAD, anti-loop guards) → [B] hviske-v3-conversation (Danish fine-tune) ← only on calls ≥45 s → ECAPA-TDNN diarization (token-free clustering, 2-speaker prior on long calls) → "phone-first" naming (filename + phonebook anchor identities; embeddings decide which cluster is the recurring party; reference profiles match the rest) → SQLite (idempotent: SHA-256 hash + status; duplicates inherit their twin's result) per day → Claude subagent reads BOTH transcripts per call, fuses them, fixes diarization from context, writes the Danish day summary per week → Claude subagent synthesises 7 day summaries into threads + a commitments table web → Flask reads the DB live (days, weeks, calls with audio, search, patterns) </code></pre> A few decisions earned their place:</p> Phone-first speaker ID.</strong> The filename carries the timestamp and both numbers; a small phonebook maps numbers to names. You know both</em> identities before decoding a word — audio only has to decide which voice is which</em>, not who they are</em>. Metadata is gold.</strong></li> ffmpeg band-pass helps; DeepFilterNet hurts.</strong> Measured: a 50-year-old band-pass filter made noisy calls more coherent for free; the SOTA neural denoiser caused hallucinations and dropped speech. SOTA is task-dependent.</strong></li> ECAPA over pyannote.</strong> pyannote OOM’d next to Whisper on a 12 GB card and was too slow on CPU for 33k files. Token-free ECAPA clustering on the GPU, with a 2-speaker prior</strong> (a phone call is</em> two-party), fixed the 79% of long calls that otherwise collapsed to a single speaker.</li> int8_float16 + expandable segments</strong> let both</strong> models coexist in ~6–8 GB on the 12 GB card.</li> </ul> The summary layer: Claude Code subagents, no API</h2> The hard constraint was no LLM API key</strong>. So the harness itself is the language model: one Claude Code subagent per day</strong> receives both ASR tracks for every call, a shared name register, and the previous day’s summary, and writes the day summary directly — ~50k–450k tokens per day-agent, no API call in the pipeline, no marginal cost.</strong></p> Three small “institutions” grew around it:</p> A fusion instruction file</strong> — the merge rules ([A]’s structure, [B]’s Danish words), fix diarization from context (a caller stating their own name pins that speaker), skip voicemails, never invent content, report uncertainty honestly.</strong></li> A shared, growing name register</strong> — agents read it before writing and append new clarifications. Over 60+ days it reconciles spelling variants of the same contact into one confirmed identity and keeps two same-named people apart. Name consistency across the whole corpus, accreted one day at a time.</li> A weekly commitments table</strong> — each week’s agent carries a “promises & deliveries” table forward (✅/⏳/❌). A genuinely useful primitive (and, as we’ll see, the bridge to customer service).</li> </ul> Running it across two machines</h2> Idempotency made the corpus splittable mid-run:</p> Machine 1 (RTX 4070 Ti, 12 GB):</strong> the full dual-model pipeline, working chronologically forward.</li> Machine 2 (GTX 1060, 6 GB, Pascal):</strong> deployed over SSH/Tailscale with one script; took a later partition. Runs only the [A] track in int8 (new CUDA wheels dropped Pascal, so torch is on CPU while CTranslate2 drives the GPU directly).</li> Merge:</strong> the worker writes its own SQLite; the main box pulls and merges every 15 minutes (idempotent — transcribed</code> can be upgraded to done</code>). The corpus is processed from both ends at once.</strong></li> </ul> Because every file is keyed by SHA-256 hash + status</strong>, moving half the work to another machine mid-run was harmless. Idempotency is the freedom to fail.</strong></p> Self-healing, learned the hard way</h2> Long unattended runs fail in creative ways. Each failure got a permanent countermeasure:</p> Two transcription processes on one GPU</strong> (an orphan survived a restart) → mutual OOM poisoning, 756 failed rows. Fix: a flock</code> singleton in the supervisor + auto-kill of orphans on startup.</li> The “poison file” myth</strong> — a file looked like it crashed the process repeatedly; it was actually the dual-process conflict. It ran fine on retry. The supervisor got retry-once-then-quarantine logic anyway.</li> Silent hangs</strong> — a worker hung for an hour on one file (process alive, no progress). Fix: a watchdog that kills the inner process after 20 minutes with no DB activity (DB mtime as the progress signal).</li> An outer watchdog every 10 minutes</strong> checks the supervisor, DB progress and web server locally — and all of it on the worker over SSH — and auto-restarts.</li> False “ready” days</strong> — a max-date heuristic declared a day finished while 93 of its 104 files were still missing. Fix: the inbox is ground truth</strong> — a day/week is ready only when every</em> one of its files has a settled DB row. Ground truth beats heuristics; the max-date guess lied twice, the inbox count never did.</strong></li> Anonymous calls</strong> — files from a withheld number didn’t match the filename pattern and went invisible to day-grouping. Parser widened, rows repaired.</li> A duplicate bug</strong> — identical audio under a new name was marked done</code> with no transcript (one hash shared by 103 empty ring-out files) and polluted the day dumps. Now duplicates inherit their twin’s status and content.</li> Reaped background processes</strong> — nohup</code> jobs were harvested by the environment and died unnoticed for hours. Fix: all long-running work as harness-managed background tasks, with the watchdog as backstop.</li> </ol> Self-healing has to be layered:</strong> process-level (supervisor: crash / hang / poison / orphan) and</em> system-level (watchdog: supervisor dead? web down? worker gone?).</p> The numbers (as of this writing)</h2> </th> </th></tr></thead> Corpus</td> ~33,000 mp3, ~570 audio hours, 13 months</td></tr> Processed</td> ~6,100 files (19%), from both ends</td></tr> Summaries</td> 60 daily + 7 weekly</td></tr> Local speed</td> dual-model ~0.2 RTF; ~430 files/hour</td></tr> Day-agent cost</td> ~50k–450k subagent tokens/day (avg ~200k)</td></tr> Diarization</td> 2-speaker prior + context repair rescued the 79% of long calls that collapsed to one voice</td></tr> </tbody></table> How this maps to a customer-service function</h2> The original use case is personal call intelligence, but the exact same pipeline is a customer-service</strong> system:</p> Two-track ASR + LLM fusion</strong> → accurate Danish transcripts of support calls.</li> Per-call / per-day / per-week summaries</strong> → QA without listening to every call.</li> The commitments table</strong> generalises directly to SLA / promise tracking</strong> — what an agent promised a customer, and whether it was delivered, carried week to week.</li> The shared name register</strong> → a consistent customer/contact directory built from the calls themselves.</li> The patterns view</strong> (volume by hour, call-direction asymmetry, recurring topics) → staffing and escalation insight, all from metadata + summaries.</li> PII discipline</strong> is built in: the “never invent, flag uncertainty” rule, and redaction before anything is stored.</li> </ul> And the privacy story is the selling point: everything runs locally behind Tailscale</strong> — audio never leaves the building, you set retention and redaction, and there’s no public endpoint. (The honest boundary: if your language layer is a cloud LLM API rather than a local harness, that text leaves — so redact first or keep the LLM local too.)</p> The lessons, distilled</h2> Analyse the corpses first</strong> — nine dead experiments held almost every right idea. Synthesis beats invention.</li> Metadata is gold</strong> — filenames alone gave speaker identity, day structure and the whole pattern analysis before a second of audio was decoded.</li> Two mediocre, diverse ASR tracks + a model that fuses them beat one good track.</strong> Error diversity is the point.</li> SOTA is task-dependent</strong> — neural denoise hurt</em> ASR measurably; a 50-year-old band-pass helped.</li> Idempotency is the freedom to fail</strong> — hash + status made every crash, restart and mid-run migration harmless.</li> Self-healing in layers</strong> — supervisor for the process, watchdog for the system.</li> Ground truth over heuristics</strong> for progress gates — count the inbox, don’t guess from the max date.</li> An LLM can be the pipeline’s expensive step without an API</strong> — when the harness itself is the model, a “summary stage” is a subagent with a good instruction file, a shared register, and an honesty norm.</li> </ol> Factory reset a Yealink phone — even without the admin password (2026) 2026-06-10T00:00:00+00:00 TL;DR —</strong> To factory reset a Yealink</strong> SIP desk phone you have three options: the keypad menu</strong> (needs the admin password), the web UI</strong> (needs the admin password), or a hardware key-hold</strong> that needs no password at all</strong> — hold the OK</strong> key for ~10 seconds. The last one is what you want for a used or inherited phone with an unknown admin login. This also covers the 2026 default-password situation: old firmware is admin</code>/admin</code>, newer units ship a unique password on a label</strong>.</p> The default password, then → now</h2> This trips people up, so get it straight first:</p> Older firmware:</strong> username admin</code>, password admin</code>. The classic default.</li> Newer firmware (security hardening, ~2021 onward):</strong> Yealink ships each phone with a unique random default password</strong> printed on a sticker (usually on the underside or the box), or forces you to set a new password on first web login. So admin</code>/admin</code> will not work</strong> on recent units.</li> </ul> If you have the password, reset from the menu or web UI. If you don’t, skip to the hardware reset</strong> — it clears the password entirely.</p> Method 1 — Hardware reset (no admin password needed)</h2> This is the one most people are searching for. With the phone powered on and idle</strong> (not in a call, not in a menu):</p> Press and hold the OK key</strong> — the round/centre key below the screen — for about 10 seconds</strong>.</li> The screen shows “Reset to factory settings?”</strong></li> Press OK</strong> to confirm.</li> The phone wipes everything and reboots. This takes a minute or two; don’t unplug it.</li> </ol> No login required — this resets the admin password along with everything else. (On a few models the prompt is triggered by holding the X</strong>/cancel key instead; if OK doesn’t do it, try that.)</p> Method 2 — From the phone’s keypad (needs admin password)</h2> Press the Menu</strong> soft key.</li> Go to Settings → Advanced Settings</strong> and enter the admin password (admin</code> on old firmware, or the label password).</li> Choose Reset to Factory</strong> (sometimes Reset Config</strong>) and confirm.</li> </ol> Method 3 — From the web interface (needs admin password)</h2> Find the phone’s IP: Menu → Status</strong> (or Settings → Status</strong>).</li> Browse to http://<phone-ip>/</code> and log in as admin</code>.</li> Go to Settings → Upgrade</strong> (or Reset & Reboot</strong>) and click Reset to Factory</strong>.</li> </ol> After the reset</h2> A full reset erases the SIP account, network config, contacts and call history</strong> — the phone comes back as if new. Before you reset (if you can log in), note your SIP credentials</strong> (server/registrar, username, auth ID, password) so you can re-register it afterward. On newer firmware you’ll be asked to set a fresh admin password on first login again.</p> Summary</h2> No admin password?</strong> Hold the OK</strong> key ~10 s while idle → confirm → done. No login needed.</li> Have the password?</strong> Reset from Menu → Settings → Advanced</strong>, or the web UI</strong> at http://<phone-ip>/</code>.</li> Default password:</strong> admin</code>/admin</code> on old firmware; a unique label password</strong> on newer units.</li> A factory reset erases the SIP account and contacts</strong> — save your SIP credentials first.</li> </ul> Update Garmin firmware and maps in 2026 — from WebUpdater to Garmin Express 2026-06-10T00:00:00+00:00 TL;DR —</strong> If you searched for Garmin WebUpdater</em> or how to update Garmin firmware</em>, the tool you remember is gone. WebUpdater was discontinued (~2015)</strong>; the current path is Garmin Express</strong> (a desktop app, USB cable) for nüvi/DriveSmart sat-navs, or Garmin Connect</strong> (phone, over the air) for watches and newer handhelds. This post covers the 2026 way to update firmware and maps</strong> on each, what to do with an old nüvi, and the hidden nüvi debug menu</strong>.</p> Then → now: WebUpdater is dead</h2> For years you updated a Garmin with WebUpdater</strong> — a small desktop helper that checked for firmware. Garmin retired it and folded everything into two apps:</p> Garmin Express</strong> — desktop (Windows/macOS), connects over USB cable</strong>. This is what replaced WebUpdater for sat-navs (nüvi, DriveSmart, Drive) and is also the cabled path for watches/handhelds and map</strong> updates.</li> Garmin Connect</strong> — phone app (iOS/Android), updates over the air</strong> over Bluetooth/Wi-Fi. This is the path for watches (Forerunner, fēnix, Venu), bike computers (Edge), and modern handhelds.</li> </ul> If you still have WebUpdater installed, uninstall it — it no longer does anything useful.</p> Update a nüvi / DriveSmart sat-nav (firmware + maps)</h2> This is the case behind most “update Garmin firmware” searches.</p> Download Garmin Express</strong> from garmin.com/express</a> and install it on a Windows or Mac computer.</li> Connect the device with a USB cable</strong> and power it on. Wait for the computer to recognise it as a drive.</li> Open Garmin Express. It detects the unit and lists available software (firmware)</strong> and map</strong> updates.</li> Click Install All</strong>, or pick individual updates. Map files are large (often several GB) — leave it plugged in and don’t disconnect mid-update.</li> When it finishes, safely eject and unplug. The unit reboots into the new firmware.</li> </ol> Map updates</strong> appear here too. If your unit has lifetime maps</strong> (“LM”/“LMT” in the model name), updates are free for the supported life of the device. Otherwise Express will offer a paid map purchase.</p> Update a watch / Edge / newer handheld (over the air)</h2> Install Garmin Connect</strong> on your phone and pair the device.</li> Connect updates download automatically; you’ll get a prompt when firmware is ready.</li> Keep the device charged and near the phone — it installs and reboots on its own.</li> </ol> For a cabled update of these devices (or if OTA fails), Garmin Express on a computer works too.</p> Very old nüvi units — what still works</h2> Many early nüvi models (the 2007–2012 era) are now end-of-life</strong>: firmware may still install via Garmin Express, but map updates are no longer offered</strong> and lifetime-map coverage has ended. If Express shows “up to date” with an old map year, that’s usually the end of the road — the hardware simply isn’t supported with new map data anymore. The unit keeps working with the maps it has.</p> Bonus: the hidden nüvi debug menu</h2> A long-standing trick for diagnosing a flaky nüvi: power it on, then press and hold the bottom-right corner of the touchscreen</strong> for a few seconds. A diagnostics screen</strong> appears — software version, touchscreen calibration test, GPS signal test, battery info. It’s safe to view; avoid changing touchscreen calibration unless the screen is genuinely misaligned.</p> Summary</h2> WebUpdater is discontinued</strong> — use Garmin Express</strong> (desktop, USB) or Garmin Connect</strong> (phone, over the air).</li> nüvi / DriveSmart</strong>: Garmin Express over USB handles both firmware and maps; “Install All”.</li> Watches / Edge / handhelds</strong>: Garmin Connect updates over the air.</li> Lifetime maps</strong> (LM/LMT models) update free; very old nüvi units are end-of-life for new map data.</li> nüvi debug menu</strong>: hold the bottom-right corner of the screen after power-on.</li> </ul> From Launchy to Raycast: the history of the keystroke launcher (2007 → 2026) 2026-06-07T00:00:00+00:00 TL;DR —</strong> In 2007 I posted a short screencast of Launchy</a></strong> — a “keystroke application launcher” that let you summon any program on Windows by hitting a hotkey and typing a few letters, instead of hunting through the Start menu. That pattern — hotkey → type → fuzzy-match → launch</strong> — was born on the Mac (Quicksilver, LaunchBar), crossed to Windows with Launchy, spread to Linux, and then did two things at once: it matured into full productivity platforms (Alfred</strong>, then Raycast</strong>), and it dissolved into the Cmd+K command palette</strong> that now lives inside nearly every app you use. Here’s the 19-year arc.</p> A companion to the other time-capsule posts here — like Xming on Windows XP → WSLg</a> and 25 years of Wi-Fi security</a>. An old screencast, and what the idea grew into.</p> </blockquote> The setup, back then</h2> The video</a> (“Shiny Windows Application Launcher” — Shiny</em> was a Launchy skin) shows the 2007 workflow. You install Launchy</strong>, it indexes your Start menu, and from then on:</p> Press Alt+Space</strong>. A small translucent box appears in the middle of the screen.</li> Type a few letters — fir</code> for Firefox, wor</code> for Word.</li> Launchy fuzzy-matches against everything it indexed and shows the best hit.</li> Hit Enter</strong>. The app launches. The box vanishes.</li> </ol> No mouse, no Start menu, no desktop icons. After a week your fingers knew the three-letter prefix for every app you used. Launchy — written by Josh Karlin and open-sourced — was explicitly pitched as “Quicksilver for Windows”</strong>, and that comparison is the key to the whole story.</p> Where the idea actually came from</h2> Launchy didn’t invent the keystroke launcher — it brought a Mac</strong> idea to Windows:</p> LaunchBar</strong> (Objective Development) — the granddaddy, with roots on NeXTSTEP in the 1990s</strong>, reborn on Mac OS X. Type an abbreviation, get the thing.</li> Quicksilver</strong> (Nicholas Jitkoff / Blacktree, ~2003) — the legendary, almost mystical Mac launcher. Not just “launch an app” but a verb-noun grammar: select a thing</em>, choose an action</em>, pick a target</em>. It defined the genre and inspired a generation (it was open-sourced in 2007 when its creator left for Google).</li> Spotlight</strong> (Mac OS X Tiger, 2005) — Apple baked search into the OS, which is where most casual users met the “just type to find things” idea.</li> </ul> Launchy (2004→) was the Windows answer to all that, and the 2007 video is a snapshot of it in its prime.</p> At a glance — 19 years of launchers</h2> Era</th> macOS</th> Windows</th> Linux</th> The pattern</th></tr></thead> ~2003–05</strong></td> Quicksilver, LaunchBar, Spotlight</td> Start menu (Vista adds search, 2007)</td> —</td> Launcher is a Mac power-user thing</td></tr> 2007 (the video)</strong></td> Quicksilver peak</td> Launchy</strong> (“Quicksilver for Windows”)</td> —</td> Keystroke launcher crosses to Windows</td></tr> ~2008–10</strong></td> Quicksilver stalls → Alfred</strong> (2010)</td> Launchy peaks, then slows</td> GNOME Do</strong>, Katapult</td> Launcher goes mainstream-power-user</td></tr> ~2011–15</strong></td> Alfred + Powerpack dominates</td> Wox (2014)</td> Synapse, Albert</td> Command palette</strong> appears (Sublime, then VS Code)</td></tr> ~2016–20</strong></td> Raycast</strong> founded (2020)</td> PowerToys Run</strong> (2020), Flow Launcher</td> Rofi, Ulauncher</td> Cmd+K spreads into every web app</td></tr> 2026 (today)</strong></td> Raycast dominant; Spotlight + Apple Intelligence</td> PowerToys Command Palette</strong>; Raycast (beta)</td> Rofi / Ulauncher / Albert</td> Launcher = AI-powered command hub</td></tr> </tbody></table> What changed</h2> 1. The launcher became a platform.</strong> Launchy launched apps and files. Alfred</strong> (2010) added workflows</em> — chain actions, run scripts, clipboard history, snippets — and became the Mac standard for a decade. Then Raycast</strong> (2020) rebuilt the idea as a native, extensible platform: an extension store, window management, clipboard history, snippets, calculators, and now built-in AI</strong>. The humble launch box turned into the place power users run half their day. Raycast’s Windows beta arrived in late 2025</strong>, closing the loop back to where Launchy started.</p> 2. Windows kept reinventing it.</strong> Launchy faded after ~2010. Wox</strong> (open source, 2014) carried the torch and spawned Flow Launcher</strong> (a Wox fork with a plugin marketplace and AI plugins). Microsoft itself shipped PowerToys Run</strong> (2020, Alt+Space</code> — a knowing nod to Launchy), now succeeded by the PowerToys Command Palette</strong>. The pattern is so obviously good that the OS vendor adopted it.</p> 3. Linux always had its own.</strong> GNOME Do</strong> (2008) was the early Quicksilver-alike; today it’s Rofi</strong> and dmenu</strong> (minimal, scriptable, beloved by tiling-WM users), Ulauncher</strong>, and Albert</strong>. Same muscle memory, different ecosystem.</p> 4. The biggest shift: the launcher dissolved into every app.</strong> The defining move of the last decade isn’t a better launcher — it’s that the command palette</em> became a universal UX primitive. Sublime Text</strong> (~2011) and then VS Code</strong> (Ctrl/Cmd+Shift+P</code>) made “hit a hotkey, type a command” the way you drive an editor. Then Cmd+K</strong> showed up everywhere: Slack, Linear, Notion, GitHub, Figma, Vercel, Stripe, your browser. The keystroke launcher stopped being a separate app you install and became a control built into the software itself. On the terminal, fzf</strong> (2013) is the same idea distilled to one fuzzy-finder binary.</p> 5. Then AI ate the command bar.</strong> The newest turn: the box you type into now talks to a model. Raycast AI</strong>, Flow Launcher’s AI plugins, Spotlight + Apple Intelligence</strong>, Windows Copilot</strong>. “Hotkey → type → fuzzy-match → act” is becoming “hotkey → ask → the launcher figures out the action.” Launchy’s little translucent box was the larval form of today’s AI command bar.</p> What to use today</h2> macOS</strong> — Raycast</a></strong> is the modern default: launching, clipboard history, window management, snippets, an extension store, and AI in one hotkey. Alfred</a></strong> is the alternative if you prefer a one-time purchase and local automation. Spotlight is built in and now quite good.</p> Windows</strong> — PowerToys Command Palette</strong> (official, free, ships in PowerToys</a>), Flow Launcher</a></strong> (open source, plugin marketplace), or Raycast</strong> (Windows beta since late 2025). Pair any of them with Everything</a></strong> for instant file search.</p> Linux</strong> — Rofi</strong> or dmenu</strong> for the scriptable/tiling crowd, Ulauncher</strong> or Albert</strong> for a friendlier GUI.</p> Terminal</strong> — fzf</a></strong>. Pipe anything into it, fuzzy-find, act. The launcher idea in 30 lines of muscle memory.</p> The takeaway</h2> The 2007 Launchy clip looks quaint — a translucent box, a Shiny skin, three letters and Enter. But the idea in it won completely. It started as a Mac curiosity, Launchy brought it to Windows, Linux picked it up, and from there it went two directions at once: up</em> into productivity platforms like Raycast, and sideways</em> into every app as the Cmd+K command palette. Today you use that 2007 idea dozens of times a day — you just don’t install it anymore, because it’s everywhere. And the box is starting to think.</p> FAQ</h2> What was Launchy?</h3> A free, open-source keystroke launcher for Windows (later cross-platform), first released by Josh Karlin around 2004. Hotkey, type a few letters, fuzzy-match, launch — “Quicksilver for Windows”. The 2007 video shows it on the Shiny skin.</p> Is Launchy still maintained?</h3> No — development tapered off around 2010 and it’s effectively dormant. On Windows today use PowerToys Command Palette, Flow Launcher, or Raycast.</p> App launcher vs command palette — what’s the difference?</h3> Same pattern, different scope. A launcher (Quicksilver, Launchy, Alfred, Raycast) is system-wide; a command palette (VS Code’s Ctrl+Shift+P</code>, the Cmd+K</code> bar in Slack/Linear/GitHub) is that same UX inside one app. The launcher came first; the palette is it absorbed into everything.</p> What should I use in 2026?</h3> macOS: Raycast or Alfred. Windows: PowerToys Command Palette, Flow Launcher, or Raycast. Linux: Rofi, Ulauncher, or Albert. Terminal: fzf.</p> Summary</h2> The keystroke launcher — hotkey → type → fuzzy-match → launch</strong> — started on the Mac (LaunchBar</strong>, Quicksilver</strong>) and reached Windows via Launchy</strong>, which my 2007 video</a> demos.</li> It grew up</em> into platforms: Alfred</strong> (2010) → Raycast</strong> (2020), now AI-powered, with a Windows beta</strong> as of late 2025.</li> Windows kept reinventing it: Wox</strong> → Flow Launcher</strong>, and Microsoft’s PowerToys Run → Command Palette</strong>.</li> It also spread sideways</em> into every app as the Cmd+K command palette</strong> (Sublime/VS Code → Slack, Linear, Notion, GitHub), and into the terminal as fzf</strong>.</li> The 2007 idea is now everywhere — and increasingly an AI command bar.</li> </ul> From Xming on Windows XP to WSLg: 18 years of Linux GUI apps on Windows (2026) 2026-06-07T00:00:00+00:00 TL;DR —</strong> Running a Linux GUI app on a Windows machine used to mean installing an X server</strong> (Xming, later VcXsrv), pointing an SSH session at it with ssh -X</code>, and watching a remote gedit</code> window paint itself onto your Windows desktop. I have an old screen recording of exactly that</a> — Xming putting gedit on Windows XP</strong>. Eighteen years later you mostly don’t bother: WSLg</strong> ships a Wayland + X server inside</em> Windows, so a Linux app installed in WSL2 just opens like any other window. This post traces the arc — X11 forwarding → VcXsrv → Wayland → WSLg — and what to actually use in 2026.</p> This is a companion to the other “then vs now” notes on this blog — like local speech-to-text replacing the cloud Speech API</a> and 25 years of Wi-Fi security</a>. Same shape: a thing that was fiddly in the XP era is now built in.</p> </blockquote> The setup, back then</h2> The video</a> shows the canonical mid-2000s trick. The pieces:</p> Xming</strong> — a free X11 server for Windows (a port of the X.Org server). It ran in the Windows system tray and provided a display</em> that X clients could draw to.</li> An SSH client</strong> — usually PuTTY, with “Enable X11 forwarding” ticked, or ssh -X</code> from Cygwin.</li> A remote Linux box</strong> running the actual app (gedit</code>, an editor) with no local window of its own.</li> </ul> The flow: SSH connects to the Linux host, the host sets $DISPLAY</code> to tunnel X11 back through the encrypted SSH channel, the app draws to Xming, and a Linux window appears on Windows XP. The application runs entirely on the remote machine; only the pixels and input events</em> travel. This worked because X11 was network-transparent from day one</strong> — a 1984 design decision that aged into a genuinely useful feature.</p> It was clever, and it was also slow and brittle: every menu and redraw was a round-trip, so over anything but a LAN it felt like wading through treacle.</p> At a glance — 18 years of Linux GUI on Windows</h2> Era</th> How you did it</th> What ran the display</th> Pain points</th></tr></thead> ~2007 (XP)</strong></td> ssh -X</code> / PuTTY → Xming</td> Xming X server in the tray</td> Manual install, chatty X11, laggy over WAN</td></tr> ~2012</strong></td> Same, or X over VNC</td> Xming / Xming-mesa, VcXsrv arrives (2011)</td> X server still a separate moving part</td></tr> ~2017</strong></td> VcXsrv + WSL1</td> VcXsrv, set DISPLAY=localhost:0</code></td> WSL1 quirks, fonts/clipboard glitches</td></tr> ~2021</strong></td> WSL2 + manual X server, or</em> WSLg preview</td> VcXsrv / X410, then WSLg</td> Transitional; manual DISPLAY</code> export still common</td></tr> 2026 (today)</strong></td> WSLg, built in</td> Weston (Wayland) + XWayland, auto</td> Basically none — apt install</code>, app opens</td></tr> </tbody></table> What actually changed</h2> 1. The X server stopped being yours to manage.</strong> For ~25 years the X server was a thing you</em> installed and babysat on Windows. With WSLg</a> — announced at Microsoft Build 2021, now standard on Windows 11 and Windows 10 21H2+ — Microsoft bundles a whole display stack into a system distro: a Weston</strong> Wayland compositor, XWayland</strong> for legacy X11 apps, a PulseAudio server for sound, and an RDP link that paints the windows onto the Windows desktop. You install a Linux GUI app in WSL2 and it opens. No DISPLAY</code>, no tray icon, no PuTTY checkbox.</p> # Inside WSL2 on Windows 11 — no X server to install: sudo apt update && sudo apt install -y gedit gedit # a real Linux gedit window opens on Windows </code></pre> 2. Wayland replaced X11 on the Linux side.</strong> The protocol that made the original trick possible is on its way out. Modern Linux desktops default to Wayland</strong>, which — unlike X11 — is not</em> network-transparent. So the “just forward it over SSH” reflex doesn’t map cleanly anymore; the Wayland-native answer for remote display is waypipe</code></a>, and XWayland keeps old X11 apps working in the meantime.</p> 3. Xming itself faded into a paid niche.</strong> Xming is still alive — Colin Harrison shipped 7.7.x builds as recently as January 2026 — but the freely downloadable public release froze at 6.9.0.31 in 2007</strong>; newer versions are donation-gated. The free, actively maintained torch passed to VcXsrv</a></strong>, an open-source X server built from current X.Org sources. (Note: VcXsrv dropped Windows XP support long ago — that era is genuinely over.)</p> 4. The whole reason</em> mostly evaporated.</strong> In 2007 you forwarded an editor because editing remote files any other way was painful. In 2026 you’d reach for VS Code Remote-SSH</strong>, mount the remote filesystem with sshfs</a>, or just work in a terminal over key-based SSH</a>. Forwarding a single GUI window is now the exception, not the workflow.</p> What to use today</h2> You’re on WSL2 (Windows 11 / Win10 21H2+):</strong> do nothing. WSLg is already there. apt install</code> the app and run it. Check with:</p> echo $WAYLAND_DISPLAY # wayland-0 → WSLg is active echo $DISPLAY # :0 → XWayland for legacy X11 apps </code></pre> You need to forward a GUI app from a remote Linux server to Windows:</strong> install VcXsrv</strong>, start it (multiple-windows mode, disable access control on a trusted network only), and:</p> ssh -X user@server # -Y for trusted forwarding if -X is blocked xterm # or whatever GUI app — it paints to VcXsrv </code></pre> This is the exact</em> same mechanism as the Xming clip, just with a modern X server. It still works. It’s still chatty over latency.</p> You want remote GUI that doesn’t crawl over WAN:</strong> skip raw X11. Use xpra</code></a> (“screen for X” — apps survive disconnects and it compresses well), waypipe</code> for Wayland, or a real remote-desktop protocol (RDP via xrdp</code>, or NoMachine/NX) for a full desktop.</p> The takeaway</h2> The Windows XP clip is a little time capsule: a tray-icon X server, a PuTTY tunnel, and a Linux text editor materialising on a beige XP desktop. The idea</em> — run the app over there, see it over here — never went away. What changed is that you no longer assemble it by hand. The X server moved inside Windows, X11 gave way to Wayland, and the common case (“I just want to touch files on that box”) got better answers entirely. Eighteen years of plumbing, quietly absorbed into apt install</code>.</p> FAQ</h2> Does SSH X11 forwarding still work in 2026?</h3> Yes — ssh -X</code> (or -Y</code> for trusted forwarding) is unchanged. It forwards X11 to any X server: VcXsrv, Xming, XQuartz, or WSLg’s. It’s just chatty over latency, which is why xpra/waypipe/RDP usually win for remote work today.</p> Is Xming still maintained?</h3> Builds still appear (7.7.x in 2026), but they’re donation-gated; the last free public release was 6.9.0.31 in 2007 — the Windows XP era of the clip. For a free, actively built X server on Windows, use VcXsrv.</p> Do I still need an X server at all?</h3> Only to forward GUI apps from a remote box over SSH, or to run X apps from a non-WSLg distro. On WSL2 with Windows 11 (or Win10 21H2+), WSLg already bundles one — local Linux GUI apps open with nothing extra installed.</p> Why did Wayland break the old “forward it over SSH” trick?</h3> X11 was network-transparent by design, so forwarding came free. Wayland deliberately isn’t — remote display is a separate concern handled by waypipe or RDP. WSLg papers over it by running Weston + XWayland, so both kinds of app work.</p> Summary</h2> The old way: install Xming</strong>, tick X11 forwarding in PuTTY, ssh -X</code>, and a remote Linux app paints onto Windows. The video</a> is that, on Windows XP.</li> Today: WSLg</strong> ships a Wayland + X server inside Windows — apt install</code> a Linux app in WSL2 and it just opens.</li> VcXsrv</strong> is the free, maintained successor to Xming for the classic remote-forwarding case; Xming</strong> itself went donation-only after 6.9.0.31 (2007).</li> Wayland</strong> replaced X11’s network transparency; use waypipe</strong>, xpra</strong>, or RDP for fast remote GUI.</li> For the original motivation — editing on a remote box — prefer VS Code Remote-SSH, sshfs</a>, or plain SSH</a>.</li> </ul> Extending video clips with AI on a 12 GB GPU — six models compared 2026-06-07T00:00:00+00:00 TL;DR —</strong> “Extending” a video clip is really image-to-video</strong>: grab the last frame and let a model generate a believable continuation, then concatenate. I ran the same machine shot through six</strong> I2V models on one 12 GB RTX 4070 Ti</strong>: Wan2.2-TI2V-5B, Wan2.2-I2V-A14B (GGUF Q4, at 640 px and at 720p), Stable Video Diffusion, LTX-Video and CogVideoX-5B. The headline isn’t the winner — it’s that a 14B</strong> model and 720p</strong> both fit in 12 GB once you get the offload strategy</strong> right.</p> The task</h2> I had a stack of short clips of forestry machines — an excavator digging, a wood chipper, a wheel loader — and wanted them a couple of seconds longer. There’s no more footage; the only way to extend is to invent</em> it. Modern image-to-video models do exactly this: condition on a starting image (here, the clip’s final frame) and a text prompt, and hallucinate motion forward. Stitch the real tail to the generated continuation and you have a longer clip.</p> Everything below ran locally on a single 12 GB RTX 4070 Ti with 125 GB of system RAM (the RAM matters — it’s where the offloaded weights live).</p> The real problem: fitting big video models in 12 GB</h2> Image diffusion is forgiving on VRAM. Video diffusion is not: you’re denoising a 3D latent (frames × height × width), and the newest quality models are 5B-14B parameters. Three things kept biting:</p> The text encoder is huge.</strong> Wan and LTX and CogVideoX all use a T5-XXL / umT5-XXL encoder that’s ~11 GB on its own. The instant model-level offload moves it onto a 12 GB card to encode the prompt, you OOM — before the video model even runs.</li> Activations, not weights, blow up at higher resolution.</strong> A 9 GB transformer can sit on the card fine; it’s the attention activations over (frames × tokens) that overflow when you push past ~480p.</li> Quantization helps disk and a bit of VRAM, but interacts badly with some offload modes.</strong> GGUF Q4 shrinks a 14B expert to ~9 GB, but the way you offload it matters (see below).</li> </ol> The fixes that made it all work:</p> Pre-encode the prompt on CPU, then evict the encoder.</strong> Compute the text embeddings with the T5 on the CPU in fp32</em> (bf16 matmuls on CPU are pathologically slow — it looks hung), cast the result to bf16, set text_encoder = None</code>, and only then start the video model. Now the 11 GB encoder never touches the GPU.</li> Pick the offload mode per model:</strong> enable_model_cpu_offload()</code> — moves whole sub-models on/off the GPU. Fast, but one model must fit at a time (so it caps resolution/length).</li> enable_sequential_cpu_offload()</code> — streams sub-modules. Lower peak VRAM, slower. Great for non-quantized models (LTX, CogVideoX), but breaks GGUF</strong> (accelerate’s meta-device step drops the quant type).</li> apply_group_offloading(..., offload_type="leaf_level", use_stream=True)</code> — streams the transformer leaf-by-leaf. This is the secret weapon.</li> </ul> </li> </ul> Wan2.2: from “fake” 5B to real 720p</h2> I started with Wan2.2-TI2V-5B</strong> (the small, consumer-friendly one). It runs easily with model-offload and produces coherent motion, but at the ~640 px the card allows it looks soft — the classic “AI video” plasticky feel.</p> Stepping up to Wan2.2-I2V-A14B</strong> meant quantization. The official 14B is two experts (high-noise + low-noise) and wants 24-35 GB in fp16. The GGUF Q4 build is ~9 GB per expert, and diffusers can load each through WanTransformer3DModel.from_single_file(..., quantization_config=GGUFQuantizationConfig(...))</code> — you just need the gguf</code> package, or it fails to read the file. With model-offload + the CPU-prompt trick, the 14B runs at 640 px and the motion is visibly better (the wood chipper, a chaotic close-up that the 5B turned to mush, came out coherent).</p> Then the actual goal: 720p</strong>. Model-offload at 1280×720 peaks at ~11.7 GB — it fits, but only ~13 frames before the activations overflow. The breakthrough was group-leaf offloading</strong>: stream the transformer one leaf module at a time, so almost nothing sits on the GPU. Peak VRAM at 1280×720: 1.9 GB</strong>. The card is suddenly empty and resolution is free; the cost is speed (leaf streaming is slow, ~20 min a clip). But it’s real, sharp 720p on a 12 GB card.</p> from diffusers.hooks import apply_group_offloading for t in (pipe.transformer, pipe.transformer_2): # both noise experts apply_group_offloading(t, onload_device=torch.device("cuda"), offload_device=torch.device("cpu"), offload_type="leaf_level", use_stream=True) pipe.vae.enable_tiling() </code></pre> The other three</h2> LTX-Video</strong> (2B). Fast and, for short extensions, the best of the lot — dynamic motion (the excavator throws dirt), prompt-guided, ~3 min a clip at 768×512. Needs sentencepiece</code> for its T5 tokenizer, and sequential</code> offload because that T5 is the same 11 GB OOM trap.</li> Stable Video Diffusion</strong> (img2vid-xt). The veteran. Runs at 1024×576 with model-offload + unet.enable_forward_chunking()</code>, and it’s quick — but SVD has no text prompt</strong>, so its motion is ambient</em> (a gentle drift, a breeze in the trees) rather than the directed action you asked for. Great for cinematic cutaways, wrong tool for “keep digging.”</li> CogVideoX-5B-I2V</strong>. The quality surprise: the longest and smoothest clip (6 s, 49 frames at 720×480), coherent throughout. The catch is speed — with sequential offload + VAE tiling it’s roughly an hour per clip</strong> on 12 GB, which makes it impractical here even though the output is lovely.</li> </ul> The scoreboard</h2> Model</th> Params</th> Fits 12 GB via</th> Output</th> Speed</th> Verdict</th></tr></thead> LTX-Video</td> 2B</td> sequential offload</td> 768×512</td> ~3 min</td> Best for short extensions</strong> — fast, dynamic</td></tr> Wan2.2-I2V-14B @ 720p</td> 14B (Q4)</td> group-leaf offload (1.9 GB!)</strong></td> 1280×720</td> ~20 min</td> Real 720p on 12 GB</strong> — sharpest</td></tr> Wan2.2-I2V-14B</td> 14B (Q4)</td> model offload + CPU prompt</td> 640×384</td> ~8 min</td> Good motion, esp. the hard cases</td></tr> CogVideoX-5B-I2V</td> 5B</td> sequential + VAE tiling</td> 720×480</td> ~1 hr</td> Longest/smoothest, but impractically slow here</td></tr> Stable Video Diffusion</td> ~1.5B</td> model offload + chunking</td> 1024×576</td> ~2 min</td> Fast & clean, but motion is ambient</td></tr> Wan2.2-TI2V-5B</td> 5B</td> model offload</td> 640×384</td> ~3 min</td> The soft, “fake”-looking baseline</td></tr> </tbody></table> What I’d actually do</h2> On a 12 GB card: reach for LTX-Video</strong> for quick, directed extensions, and Wan2.2-14B + group-offload</strong> when you specifically need 720p</strong> and can wait. SVD stays in the kit for ambient cutaways. CogVideoX is gorgeous but you’d want a bigger GPU to use it for real.</p> And the honest limitation: the thing that still reads as “AI” is mostly resolution</strong>. Group-offload buys you 720p or</em> a 12 GB card buys you length — not both at once. High-res and</em> multi-second is the one wall a 12 GB GPU won’t climb; that’s what a 24 GB+ card (or an hour of cloud) is for. Everything else — even a 14B model at 720p — turned out to be a question of offloading, not horsepower.</p> 8-digit BINs explained: what the IIN expansion means for card BIN lookups (2026) 2026-06-06T00:00:00+00:00 TL;DR —</strong> the IIN</strong> (issuer identification number) on a payment card grew from 6 digits to 8</strong>. A 6-digit prefix can now map to several</em> issuers or products, so BIN lookups that key on 6 digits return ambiguous results. The card number’s overall length didn’t change — the account portion just got two digits shorter.</p> This is the structural background behind binlist.net and iinlist.com</a> — if you do anything with card numbers, it’s worth understanding.</p> What a BIN/IIN actually is</h2> The first digits of a card’s PAN (primary account number) identify who issued it. Two terms for the same thing:</p> BIN</strong> — Bank Identification Number</em>, the older industry term.</li> IIN</strong> — Issuer Identification Number</em>, the term ISO/IEC 7812 uses.</li> </ul> They’re used interchangeably. The very first digit is the MII</strong> (Major Industry Identifier) — 4</code> = Visa, 5</code>/2</code> = Mastercard, 3</code> = Amex/Diners/JCB, and so on. The PAN as a whole is structured as:</p> IIN (issuer) account identifier check digit (Luhn) ┌────────────────┐ ┌───────────────────────┐ ┌──┐ 4 5 3 9 1 4 8 8 0 3 4 5 6 7 8 9 └─ 8 digits now ─┘ </code></pre> What changed</h2> Historically the IIN was the first 6 digits</strong>. ISO/IEC 7812 was updated to define it as 8 digits</strong>, and the card networks moved the ecosystem onto 8-digit BINs — Visa and Mastercard set April 2022</strong> as the point by which issuers, acquirers, and processors had to support the longer identifier.</p> Crucially, the PAN length didn’t change</strong> (still up to 19 digits, 16 for most cards). The issuer identifier took two more digits, so the account-identifier portion got two digits shorter</strong>.</p> Why they did it</h2> They were running out of room. A 6-digit space is one million possible IINs, and between new fintechs, BIN sponsorship, and ever-finer product segmentation (each card product often wants its own range) the 6-digit pool was being exhausted. Going to 8 digits multiplies the available ranges by a hundred.</p> The practical fallout for lookups</h2> This is the part that bites if you maintain or consume a BIN database:</p> A 6-digit prefix is no longer unique.</strong> Within one old 6-digit block, the two extra digits can now belong to different</em> issuers or different</em> products. Looking up only 6 digits can return the wrong bank, country, or card type.</li> You need at least 8 digits to be confident.</strong> If your input only has 6 (common with masked/truncated data), treat the result as a best-effort guess, not ground truth.</li> Your data source has to be 8-digit aware.</strong> A BIN list that only carries 6-digit granularity silently collapses distinct 8-digit issuers into one row.</li> </ol> # Same 6-digit prefix, two different 8-digit issuers (illustrative): 4539 14 .. -> 45391488 = Issuer A, debit, country X 4539 14 .. -> 45391499 = Issuer B, credit, country Y </code></pre> What to do in practice</h2> Capture and key on 8 digits</strong> wherever you legitimately have them.</li> Degrade gracefully</strong> when you only have 6 — return the prefix-level info and flag it as low-confidence rather than asserting a single issuer.</li> Mind PCI scope.</strong> The first 6 and</em> the first 8 are both allowed to be stored/displayed under PCI DSS truncation rules (BIN + last 4), but check your acquirer’s current guidance before widening what you persist.</li> Don’t hardcode “6”.</strong> If you have regexes or schema columns that assume a 6-digit BIN, they’re now wrong.</li> </ul> FAQ</h2> Did my card number get longer?</h3> No. The total PAN length is unchanged. Only the split</em> between issuer-identifier and account-identifier moved — issuer up by two digits, account down by two.</p> Is it “BIN” or “IIN”?</h3> Same thing. “BIN” is the everyday industry word; “IIN” is the formal ISO term. Expect to see both, often in the same document.</p> Can I still do a 6-digit lookup?</h3> You can, and for many ranges it’s still fine — but it’s no longer guaranteed</em> to identify a single issuer. Treat 6-digit results as approximate and prefer 8 when you have them.</p> Where do I get 8-digit BIN data?</h3> A maintained BIN/IIN database that carries 8-digit granularity. The free binlist.net</a> and the commercial iinlist.com exist precisely for this.</p> Summary</h2> The issuer identifier on a card went from 6 to 8 digits</strong> (networks: support required by ~April 2022).</li> Total card-number length is unchanged; the account portion shrank by two digits.</li> 6-digit BIN lookups are now ambiguous</strong> — capture and match on 8 digits where you can, and flag 6-digit results as low-confidence.</li> </ul> Find which process is using a port on Linux (ss, lsof, fuser) — 2026 2026-06-05T00:00:00+00:00 TL;DR —</strong> sudo ss -ltnp | grep :8080</code> shows the process listening on port 8080. Then kill <pid></code>. ss</code> is the modern replacement for the deprecated netstat</code>; lsof -i :8080</code> and fuser 8080/tcp</code> do the same job.</p> ss — the modern way</h2> ss</code> (from iproute2</code>) ships on every current distro and replaced netstat</code>. To see what’s listening</strong>:</p> sudo ss -ltnp </code></pre> -l</code></strong> listening sockets</li> -t</code></strong> TCP (use -u</code> for UDP)</li> -n</code></strong> numeric — don’t resolve ports to names (faster, clearer)</li> -p</code></strong> show the p</strong>rocess (needs root to see other users’ processes)</li> </ul> Filter to one port with ss</code>’s own expression (no grep needed):</p> sudo ss -ltnp 'sport = :8080' </code></pre> State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 511 0.0.0.0:8080 0.0.0.0:* users:(("node",pid=4123,fd=18)) </code></pre> There’s your PID: 4123</code>.</p> lsof — the alternative</h2> sudo lsof -i :8080 # anything using port 8080 sudo lsof -iTCP:8080 -sTCP:LISTEN # only the listener </code></pre> lsof</code> prints the command, PID, and user per line. It isn’t installed everywhere by default (sudo apt install lsof</code>), but it’s the most readable for “who has this port and</em> in what state”.</p> fuser — the quick one</h2> sudo fuser 8080/tcp </code></pre> Prints just the PID(s). It can even kill in one shot:</p> sudo fuser -k 8080/tcp # send SIGKILL to whatever holds 8080/tcp </code></pre> Convenient, but blunt — it’ll kill -9</code> without asking, so know what you’re terminating first.</p> netstat — only if you’re stuck on an old box</h2> The classic netstat -tulpn</code> still works where it’s installed, but netstat</code> is deprecated and missing from minimal modern images. Prefer ss</code>; the flags are nearly identical.</p> Free the port</h2> Once you have the PID, stop it gracefully first, then escalate only if it ignores you:</p> kill 4123 # SIGTERM — lets it shut down cleanly kill -9 4123 # SIGKILL — last resort, no cleanup </code></pre> If it’s a managed service, stop it properly so it doesn’t just respawn:</p> sudo systemctl stop myapp </code></pre> Gotchas</h2> No process shown?</strong> You’re not root. The -p</code>/-i</code> process columns are empty for sockets you don’t own — re-run with sudo</code>.</li> Port still “in use” after the process died.</strong> A closed TCP socket lingers in TIME_WAIT</code> for a couple of minutes. Either wait, or set SO_REUSEADDR</code> in your server (most frameworks have a “reuse address” flag).</li> It came back immediately.</strong> A supervisor (systemd, Docker, pm2) restarted it. Stop the supervisor unit, not the child PID.</li> IPv6 vs IPv4.</strong> 0.0.0.0:8080</code> is IPv4; [::]:8080</code> is IPv6. A process can hold both — ss -ltnp</code> lists each separately.</li> </ul> FAQ</h2> How do I see established connections, not just listeners?</h3> Drop -l</code>: sudo ss -tnp</code> shows active connections. Add state established</code> to filter.</p> What’s using a UDP port?</h3> Swap -t</code> for -u</code>: sudo ss -lunp 'sport = :53'</code> (e.g. to find what’s on DNS).</p> One-liner to kill whatever is on a port?</h3> sudo fuser -k 8080/tcp</code>, or sudo kill $(sudo lsof -t -i:8080)</code>. Use with care.</p> Summary</h2> Find it: sudo ss -ltnp 'sport = :8080'</code> (modern), sudo lsof -i :8080</code>, or sudo fuser 8080/tcp</code>.</li> Free it: kill <pid></code> first, kill -9</code> only if needed, or stop the systemd unit.</li> ss</code> replaces netstat</code> — same idea, fewer surprises on modern systems.</li> </ul> Local speech-to-text with whisper.cpp — a self-hosted Google Speech API alternative (2026) 2026-06-04T00:00:00+00:00 TL;DR —</strong> whisper.cpp</code> runs OpenAI’s Whisper speech-to-text models locally. Build it, download a model, convert your audio to 16 kHz mono WAV with ffmpeg</code>, and run whisper-cli -m models/ggml-base.en.bin -f audio.wav</code>. No API key, no upload, no per-minute charge.</p> This blog has a history of speech-to-text experiments</a> — the old ones leaned on the Google Speech API. The local-model story is dramatically better now: same quality tier, zero cloud dependency.</p> </blockquote> Why local</h2> A hosted speech API means keys, per-minute billing, and shipping (often sensitive) audio to a third party. whisper.cpp</code> is a small, dependency-light C/C++ port of Whisper that runs the same models offline — on CPU, or accelerated with Metal (Mac) / CUDA (NVIDIA). For batch transcription, private recordings, or just avoiding a metered API, it’s the obvious default in 2026.</p> Build it</h2> git clone https://github.com/ggml-org/whisper.cpp cd whisper.cpp cmake -B build cmake --build build -j --config Release </code></pre> The CLI lands at build/bin/whisper-cli</code>. (Older checkouts called this binary ./main</code> — if a guide references main</code>, it’s the same tool under the previous name.)</p> On a Mac, Metal acceleration is on by default. For an NVIDIA GPU, configure with CUDA:</p> cmake -B build -DGGML_CUDA=1 cmake --build build -j --config Release </code></pre> Get a model</h2> Models are GGML/GGUF files you download once. The helper script fetches them into models/</code>:</p> sh ./models/download-ggml-model.sh base.en </code></pre> Pick the size for your accuracy/speed trade-off:</p> tiny.en</code> / base.en</code></strong> — fast, fine for clean English; great on a laptop CPU.</li> small.en</code></strong> — a noticeable accuracy step up, still quick.</li> medium</code></strong> — strong, multilingual.</li> large-v3</code></strong> — best quality, wants a GPU and a few GB of RAM.</li> </ul> Drop the .en</code> suffix for the multilingual variants. Quantized builds (e.g. base.en-q5_0</code>) cut memory with minimal quality loss.</p> Convert your audio</h2> Whisper expects 16 kHz mono PCM WAV</strong>. Convert anything to that with ffmpeg</code>:</p> ffmpeg -i recording.mp3 -ar 16000 -ac 1 -c:a pcm_s16le recording.wav </code></pre> -ar 16000</code> — 16 kHz sample rate</li> -ac 1</code> — mono</li> -c:a pcm_s16le</code> — 16-bit PCM</li> </ul> Transcribe</h2> ./build/bin/whisper-cli -m models/ggml-base.en.bin -f recording.wav </code></pre> It prints the transcript with timestamps. Write it to files instead:</p> ./build/bin/whisper-cli -m models/ggml-base.en.bin -f recording.wav \ -otxt -osrt -ovtt -oj </code></pre> -otxt</code> plain text · -osrt</code> SRT subtitles · -ovtt</code> WebVTT · -oj</code> JSON (with word timing).</li> </ul> For non-English audio, use a multilingual model and set the language (or let it auto-detect):</p> ./build/bin/whisper-cli -m models/ggml-medium.bin -l da -f optagelse.wav # -l auto to detect automatically; add --translate to render English </code></pre> Speed notes</h2> tiny</code>/base</code> transcribe faster than real time on a modern laptop CPU. large-v3</code> wants a GPU to be comfortable.</li> Long file? Whisper chunks internally, but you can pre-split with ffmpeg -f segment</code> for parallelism across cores.</li> --threads N</code> tunes CPU usage; Metal/CUDA builds offload the heavy matmuls automatically.</li> </ul> FAQ</h2> Is this the same model as OpenAI’s Whisper?</h3> Yes — whisper.cpp</code> runs the released Whisper weights (converted to GGML/GGUF). The output quality matches the corresponding model size; only the runtime differs.</p> Do I need a GPU?</h3> No. tiny</code>/base</code>/small</code> are perfectly usable on CPU. A GPU mainly helps with medium</code>/large</code> and long batches.</p> How accurate is it versus a cloud speech API?</h3> For clean audio, small.en</code> and up is competitive with the major hosted APIs, and large-v3</code> generally beats them — with the bonus that nothing leaves your machine.</p> Can it do live/streaming transcription?</h3> There’s a stream</code> example in the repo that does near-real-time from a microphone. It’s rougher than batch mode but works for live captions.</p> Summary</h2> Build whisper.cpp</code>, download a model with download-ggml-model.sh</code>.</li> Convert audio to 16 kHz mono WAV with ffmpeg</code>.</li> whisper-cli -m models/ggml-base.en.bin -f audio.wav</code> — local, key-free transcription.</li> Scale the model size to your hardware; use -l</code>/--translate</code> for other languages.</li> </ul> Five ways to get b-roll from one ride — all on a local GPU 2026-06-02T00:00:00+00:00 TL;DR —</strong> B-roll is the cutaway footage that lets an edit breathe, and onboard POV footage from a single camera has exactly none of it. I took one ATV ride and tried five</strong> ways to manufacture b-roll from it: (1) auto-mine</strong> the best real frames with OpenCV, (2) generate stills</strong> and seed them from real frames with SDXL-Turbo → RealVisXL img2img</strong>, (3) fake a cinematic camera move with Depth-Anything-V2</strong> 2.5D parallax, (4) generate actual motion</em> with Stable Video Diffusion</strong>, and (5) make a slow-motion</strong> cut of the real footage with optical-flow interpolation. Everything ran locally on a 12 GB RTX 4070 Ti. They’re complementary — here’s the comparison and the traps.</p> The problem</h2> Onboard footage — a GoPro/DJI on the handlebars of a go-kart or an ATV — is one continuous first-person shot. It’s great for the action, but an edit needs cutaways</em>: the establishing shot, the scenery, the slow detail that gives the viewer a breath between the intense bits. With one camera and no B-cam, you have none. So: can you manufacture believable b-roll after the fact, locally, for free?</p> I tried five approaches on a single 11-minute ATV tour through Nordic forest and gravel trails. Each produces a short graded reel; the interesting part is the trade-offs.</p> 1. Auto-mine the real footage (OpenCV)</h2> The cheapest b-roll is the b-roll you already shot but didn’t notice. A small OpenCV pass samples ~1,400 frames across the ride and scores each for sharpness</strong> (variance of the Laplacian), colourfulness</strong> (the Hasler–Süsstrunk metric), exposure</strong> (distance from a mid-tone target) and motion-stability</strong> (inter-frame difference — low is good for a stable cutaway). Non-maximum suppression then spreads the picks out so you don’t get eight near-identical frames from the same 20 seconds.</p> score = 1.1*z(sharp) + 1.0*z(colourful) + 0.8*z(exposure) - 0.9*shake - 6.0*clipping </code></pre> It’s not glamorous, but it’s instant, free, and 100% authentic. The output is genuinely your ride — just the most b-roll-worthy three seconds you forgot you filmed.</p> 2. Generative stills, matched to the real ride</h2> This is where it got interesting — and where it first went wrong.</p> Attempt one: pure text-to-image.</strong> SDXL-Turbo with prompts like “cinematic misty forest at golden hour”</em> produced beautiful images that looked nothing like the actual ride. Wrong light (sunset vs. the real overcast), no quad in frame, no POV. Gorgeous stock footage for a</em> forest, not this</em> one.</p> Attempt two: img2img, seeded from real frames.</strong> Feeding a real frame in as the init image at moderate denoising strength keeps the real composition — the black quad’s handlebars and mirrors in the foreground, the grass-and-dirt two-track, the overcast palette — and regenerates the detail. Now it intercuts with the real footage. But SDXL-Turbo</strong> at strength ≈0.5 still melted</em>: it hallucinated extra gauges onto the dashboard and warped the handlebars. The classic “AI look.”</p> Attempt three: better models, lower strength.</strong> I compared three less-melty methods on the same frames:</p> </p> SDXL-base, low strength (0.30), 30 steps</strong> — faithful, no melt, but a touch soft.</li> ControlNet-Canny + SDXL</strong> — locks the real edges so nothing warps, but recomposed the scene greener and more stylised than the source.</li> RealVisXL</strong> (a photoreal SDXL fine-tune), img2img — the winner: sharp, photoreal, keeps the real POV and palette, no melt.</li> </ul> </p> The lesson: for footage-matching, the base model</em> and denoising strength</em> matter far more than the prompt. A photoreal checkpoint at low strength beats a flashy distilled model every time.</p> 3. AI Ken Burns — depth parallax</h2> A still doesn’t have to stay still. Depth-Anything-V2</strong> estimates a depth map for a frame in well under a second; with depth in hand you can render a 2.5D camera move where near pixels shift more than far ones, plus a gentle push toward the trail’s vanishing point. It reads like riding forward.</p> </p> The whole render is a backward cv2.remap</code> with depth-weighted displacement, so it’s hole-free and fast. One catch worth writing down: OpenCV’s remap</code> wants float32</code> maps, and a stray Python scalar in the arithmetic silently upcasts them to float64</code>, at which point remap</code> asserts. Cast the maps back to float32</code> explicitly.</p> This is the best value-for-effort of the synthetic options: real content, real-looking motion, a tiny model. The only limit is that large pushes start to reveal warping at depth discontinuities — keep the move subtle.</p> 4. Generative video — Stable Video Diffusion</h2> If you want motion a static frame genuinely cannot</em> fake, Stable Video Diffusion</strong> (image-to-video) animates a still into real movement — the camera drifts and pushes through the scene, parallax and all, invented by the model rather than warped geometrically.</p> </p> Seeding SVD from the RealVisXL stills gives generated motion that still looks like the ride. The honest caveats: clips are short (~2–3 seconds at 25 frames), the motion is only loosely controllable (you nudge it with a “motion bucket”, not a path), and there’s mild edge warping. It’s also the heaviest thing here — the model is ~9 GB and, on a 12 GB card, only fits with CPU-offload, UNet forward-chunking and a small VAE decode chunk:</p> pipe.enable_model_cpu_offload() pipe.unet.enable_forward_chunking() frames = pipe(image, num_frames=25, decode_chunk_size=2, motion_bucket_id=110, noise_aug_strength=0.04).frames[0] </code></pre> 5. Cinematic slow-motion — real footage, no AI</h2> The fifth option uses no generative model at all. Take the auto-mined moments, slow them to 50% with motion-compensated optical-flow interpolation</strong> (so the slow-mo is smooth, not stuttery duplicated frames), stabilise lightly, and apply a filmic grade. ffmpeg does it in one filter chain:</p> minterpolate=mi_mode=mci:mc_mode=aobmc:me_mode=bidir:vsbmc=1:fps=60,setpts=2.0*PTS </code></pre> It’s 100% real, looks premium, and is the most “broadcast” of the lot. Interpolation can smear very fast edges, but on scenic cutaways it’s clean.</p> Which one wins?</h2> None — they’re complementary, and a real edit blends several:</p> Method</th> Authenticity</th> Control</th> Cost</th> Best for</th></tr></thead> 1 · Auto-mine (CV)</td> Real</td> Limited to what you shot</td> Instant</td> Authentic cutaways, free</td></tr> 2 · Generative stills (RealVisXL)</td> Synthetic</td> High (any scene)</td> Medium (GPU)</td> Shots you never filmed</td></tr> 3 · Depth parallax</td> Real + fake motion</td> Motion only</td> Cheap</td> Bringing a great frame alive</td></tr> 4 · SVD video</td> Synthetic</td> Loose motion</td> Heaviest (~9 GB)</td> Living motion with no footage</td></tr> 5 · Slow-mo (real)</td> 100% real</td> Speed/grade</td> Medium</td> A premium cut of real moments</td></tr> </tbody></table> If I had to ship one b-roll bed for this kind of footage, it’d be slow-mo (5) for the authentic premium feel</strong>, with depth parallax (3)</strong> to add motion to standout frames, and RealVisXL stills (2)</strong> only where I need an establishing shot that was never possible to film.</p> Stack</h2> GPU:</strong> one RTX 4070 Ti, 12 GB</strong>. Everything below fits.</li> Diffusion:</strong> diffusers</code> 0.38 — SDXL-base, RealVisXL V4.0</strong>, ControlNet-Canny-SDXL, Stable Video Diffusion XT</strong>.</li> Depth:</strong> transformers</code> + Depth-Anything-V2-Small</strong>.</li> CV / assembly:</strong> OpenCV, NumPy, and ffmpeg</strong> (minterpolate</code>, deshake</code>, AV1 NVENC, AVIF stills).</li> A couple of traps worth keeping: a distro Python marked PEP 668 externally-managed</strong> will silently</em> refuse pip install</code> — use a real virtualenv. And pgrep -f build.sh</code> happily matches the watcher command</em> that contains that string, so don’t trust it to tell you a render finished; check for a live ffmpeg</code> instead.</li> </ul> Why it exists</h2> This started as “the onboard clips need cutaways and I have one camera.” The honest answer turned out to be that you don’t need a second camera — you need to find</em> the b-roll you already shot (1, 5) and fabricate</em> the rest with the smallest model that does the job (3 before 2 before 4). The flashiest option (generative video) is the one I’d reach for last. The least flashy (scoring frames with a Laplacian) is the one I’d reach for first.</p> All local, all on a card that costs less than a weekend of cloud GPU. Not interesting until you need it — and then it’s exactly what you need.</p> Stitching drone panoramas: OpenCV vs Hugin, benchmarked 2026-05-31T00:00:00+00:00 TL;DR —</strong> I had a folder of 63 DJI Phantom 4 Pro frames shot over Randers and wanted panoramas out of them. I stitched the same sweeps two ways: OpenCV’s Stitcher</code></strong> (fully automatic, spherical) and the Hugin command-line pipeline</strong> (cpfind</code> → autooptimiser</code> → nona</code> → enblend</code>). OpenCV is fast (a few seconds) and keeps the widest field of view, but the horizon comes out wavy, the borders are ragged, and exposure seams are visible. Hugin takes ~30 s per panorama but gives a straight horizon, seamless multi-band blend, and a clean rectangular crop</strong>. For anything you’d print or publish, Hugin wins. Full commands and a benchmark table below.</p> The starting point</h2> A folder, 63 files, DJI_0029.jpeg</code> through DJI_0091.jpeg</code>, ~15 MB each, 5464 × 3070 px. No flight log, no project file, and — as I’d find out — most of the useful metadata stripped. Just JPEGs and a stray result.jpg</code> from someone’s earlier attempt.</p> First job: figure out what these photos actually are</em> before deciding how to stitch them. Are they a nadir mapping grid? A single rotational panorama? Several separate sweeps? You stitch each of those differently.</p> Reverse-engineering the capture from metadata</h2> No exiftool</code> on the box, so:</p> sudo apt-get install -y libimage-exiftool-perl imagemagick </code></pre> DJI normally writes gimbal yaw/pitch/roll into an XMP namespace, which would tell me exactly how the camera was pointing for each frame. Here it had been stripped — the files had clearly been re-exported at some point (which also explains that root-owned result.jpg</code>). What survived was GPS and timestamps:</p> exiftool -n -T -FileName -GPSLatitude -GPSLongitude -GPSAltitude \ -SubSecDateTimeOriginal DJI_*.jpeg </code></pre> Two things fell out immediately.</p> There were two sessions, 90 minutes apart:</strong></p> 0029</code>–0054</code>, shot 09:01–09:15</li> 0055</code>–0091</code>, shot 10:31–10:36</li> </ul> The second session was a stack of horizontal sweeps at rising altitude.</strong> The GPS position barely moved while the altitude climbed in clear bands — 169 m, then 221 m, then 240 m, then 269 m. That’s the signature of a drone hovering on the spot and panning the camera across the horizon at each height. Each altitude band is one panorama.</p> A quick contact sheet confirmed it:</p> ls DJI_*.jpeg | sed 's/.jpeg//' | xargs -P4 -I{} \ convert {}.jpeg -resize 260x -gravity South -background black \ -splice 0x16 -pointsize 13 -fill yellow -annotate +0+1 '{}' /tmp/thumbs/{}.png montage /tmp/thumbs/DJI_00{55..91}.png -tile 6x -geometry +3+3 /tmp/sheet.png </code></pre> Session one turned out to be mixed — top-down shots of a single property at varying heights (a vertical zoom sequence, not a panorama) plus some oblique neighbourhood passes. So I focused the panoramas on session two’s sweeps, which is what the drone was clearly there to capture.</p> The groups I settled on:</p> Group</th> Frames</th> Altitude</th> Content</th></tr></thead> A</td> 0055–0065</td> ~169 m</td> Residential, low pan</td></tr> B</td> 0066–0076</td> ~221 m</td> Town</td></tr> C+D</td> 0077–0091</td> 240–269 m</td> High skyline</td></tr> </tbody></table> Technique 1 — OpenCV Stitcher</h2> The path of least resistance. OpenCV ships a high-level Stitcher</code> that does feature detection, matching, bundle adjustment, warping, and blending in one call.</p> pip install opencv-contrib-python numpy </code></pre> import cv2, glob imgs = [cv2.imread(f) for f in sorted(glob.glob("group_A/*.jpg"))] stitcher = cv2.Stitcher_create(cv2.Stitcher_PANORAMA) # spherical model status, pano = stitcher.stitch(imgs) if status == cv2.Stitcher_OK: cv2.imwrite("A_opencv.jpg", pano) </code></pre> Two modes matter:</p> PANORAMA</code></strong> assumes the camera rotated about its optical centre (spherical warp). Correct for these hover-and-pan sweeps.</li> SCANS</code></strong> assumes an affine/translational model (flatbed scans, nadir mapping). I tried it for completeness; it’s the wrong model here and collapsed most sweeps down to two or three frames. Don’t use it for rotational aerials.</li> </ul> I ran everything on a 2400 px working set first — full-res stitching is slow to iterate on, and you want to see whether a group connects before you commit minutes to it.</p> Verdict on OpenCV:</strong> it just works, with zero parameters, in seconds. Group A — eleven frames — stitched into a 10433 × 1595 panorama in about 5 seconds. The catch is the output: a wavy horizon</strong>, ragged torn edges</strong> you have to crop by hand, and faint exposure seams</strong> where frames meet. Fine for a quick look; not something you’d print.</p> Technique 2 — the Hugin pipeline</h2> Hugin</a> is the open-source panorama tool, and crucially its whole engine is scriptable from the command line — no GUI needed.</p> sudo apt-get install -y hugin-tools enblend enfuse </code></pre> The pipeline, stage by stage:</p> pto_gen -o p.pto DJI_0055.jpeg ... DJI_0065.jpeg # 1. project from EXIF cpfind --multirow -o p.pto p.pto # 2. find control points cpclean -o p.pto p.pto # 3. drop bad matches autooptimiser -a -m -l -s -o p.pto p.pto # 4. optimise + level horizon pano_modify --canvas=AUTO --crop=AUTO --projection=2 \ -o p.pto p.pto # 5. cylindrical + auto-crop nona -m TIFF_m -z LZW -o remap p.pto # 6. remap each frame enblend -o pano.tif remap*.tif # 7. multi-band blend </code></pre> What each stage buys you over the OpenCV one-liner:</p> cpfind --multirow</code></strong> finds proper control points across the whole set — it reported 250, 302, and 718 points for groups A, B and C+D respectively.</li> autooptimiser -l -s</code></strong> levels the horizon and straightens the panorama. This is the single biggest visible win: the wave disappears.</li> --projection=2</code></strong> is cylindrical, which keeps the horizon a straight horizontal line — exactly what you want for a wide aerial sweep.</li> --crop=AUTO</code></strong> trims to the largest clean rectangle, so no manual cropping.</li> enblend</code></strong> does multi-band (Burt–Adelson) blending, which hides the exposure differences between frames that OpenCV left visible.</li> </ul> Same group, two pipelines, stacked — OpenCV on top, Hugin below:</p> </p> The difference isn’t subtle.</p> The benchmark</h2> Same input groups, both pipelines. OpenCV numbers are the 2400 px working set; Hugin numbers are the final full-resolution 5464 px runs.</p> Group</th> Imgs</th> Tool</th> Result</th> Time</th> Horizon</th> Blend</th> Crop</th></tr></thead> A · residential</td> 11</td> OpenCV PANORAMA</td> 10433 × 1595</td> 5 s</td> wavy</td> seams</td> ragged</td></tr> A · residential</td> 11</td> Hugin + enblend</strong></td> 11581 × 1827</td> 31 s</td> straight</strong></td> seamless</strong></td> clean</strong></td></tr> B · town</td> 11</td> OpenCV PANORAMA</td> 10295 × 1838</td> 11 s</td> wavy</td> seams</td> ragged</td></tr> B · town</td> 11</td> Hugin + enblend</strong></td> 8190 × 2547</td> 30 s</td> straight</strong></td> seamless</strong></td> clean</strong></td></tr> C+D · skyline</td> 15</td> OpenCV PANORAMA</td> 8660 × 1975</td> 2 s</td> wavy</td> seams</td> ragged</td></tr> C+D · skyline</td> 15</td> Hugin + enblend</strong></td> 22469 × 2391</td> 60 s</td> straight</strong></td> seamless</strong></td> clean</strong></td></tr> </tbody></table> OpenCV is 3–10× faster and tends to keep a wider field of view (it warps and keeps the torn edges rather than cropping them). Hugin is slower but wins on every quality axis that matters for a finished image.</p> Going full resolution</h2> Once Hugin was the clear winner I re-ran it on the original 5464 px frames. The pipeline is identical — just point pto_gen</code> at the original JPEGs instead of the downscaled set. cpfind</code> and enblend</code> are the slow stages at full res, but it still came in around 30 s per panorama, a minute for the 15-frame skyline.</p> The finished panoramas:</p> The high skyline — fifteen frames, 22469 × 2391, a near-180° sweep across the whole town:</strong></p> </p> The residential sweep at 169 m:</strong></p> </p> The town at 221 m:</strong></p> </p> At 22469 px wide the skyline is comfortably large-format printable.</p> FAQ</h2> Why did the metadata matter so much — why not just throw all 63 into the stitcher?</h3> You can, and OpenCV will try to find connected components. But the files were two unrelated sessions plus a mix of nadir and oblique frames. Feeding the lot in risks the optimiser bridging frames that shouldn’t connect, or wasting minutes failing to. Five minutes with exiftool</code> to group the frames first saved a lot of guessing — and told me which</em> groups were even panoramas.</p> Why not just use the drone’s built-in panorama mode?</h3> These weren’t shot as in-camera panoramas — they’re individual frames from manual sweeps, and the on-board stitch (if it ran at all) is the low-res result.jpg</code> I found in the folder. Stitching from the original full-res frames yields far more detail than the in-camera JPEG.</p> What about PTGui / Lightroom / Microsoft ICE?</h3> All capable. PTGui is essentially commercial Hugin and excellent. Lightroom’s Photo Merge is convenient if you’re already in it. Microsoft ICE was great but is discontinued. I wanted a scriptable, free, Linux-native pipeline I could run headless over a folder — that’s Hugin.</p> Cylindrical, spherical, or rectilinear?</h3> For a wide horizontal sweep, cylindrical</strong> (--projection=2</code>) keeps the horizon straight and handles >120° without the extreme stretching rectilinear gives at the edges. Spherical (what OpenCV’s PANORAMA</code> uses) is fine too but tends to bow the horizon unless the pitch is well estimated — which is harder here because the gimbal angles were stripped.</p> Can this run unattended over a whole folder?</h3> Yes — the entire Hugin path is CLI, so it drops straight into a shell script or a Makefile</code>. Group the frames (by timestamp/altitude, or just let cpfind</code> find connected components), then loop the seven commands per group. That’s the real argument for Hugin over a GUI tool here.</p> Verdict</h2> If you want a panorama now</em> and don’t care about a wavy horizon or trimming edges yourself, OpenCV’s Stitcher</code> is a five-second one-liner and genuinely impressive for the effort.</p> For anything you’ll keep — print, publish, hang on a wall — the Hugin command-line pipeline</strong> is worth the extra half-minute. A straight horizon, a seamless blend, and an automatic clean crop are exactly the things that separate a snapshot from a finished panorama, and Hugin gets all three for free. It’s now my default for stitching anything off the drone.</p> The whole thing — install to finished full-res panoramas — was about an hour, most of it spent understanding the photos rather than stitching them. Which is usually how these go.</p> bchunk — convert .bin/.cue images to .iso and .wav on Linux and macOS 2026-04-22T00:00:00+00:00 TL;DR —</strong> bchunk</code></strong> — sometimes called binchunker</code></strong> — is a small, old, Unix command-line tool that takes a .bin</code>/.cue</code> pair (a raw CD image with a cue sheet) and splits it into a proper .iso</code> file for the data track</strong> and one .wav</code> file per audio track</strong>. It’s the right tool when a download or archive gave you game.bin</code> + game.cue</code> and you actually want to mount the data track</strong> or re-burn the audio tracks</strong>. Install with apt install bchunk</code> on Debian/Ubuntu, brew install bchunk</code> on macOS, or build from source on anything else. Usage is bchunk [options] image.bin image.cue basename</code> — you get basename01.iso</code>, basename02.wav</code>, basename03.wav</code>, and so on.</p> What .bin/.cue is, and why you’d want to split it</h2> A .bin</code>/.cue</code> pair is a raw, bit-accurate CD image</strong> plus a plain-text sheet that describes the track layout. The .bin</code> contains every sector of the CD back-to-back — including data tracks (Mode 1 or Mode 2), audio tracks (raw Red Book PCM, 2352 bytes per sector, no filesystem), and the gaps between them. The .cue</code> tells you where each track starts and what type it is.</p> This format is the standard output of CD-ripping tools like cdrdao and of old game-preservation scrapes, because it preserves everything</em> — pregaps, CD-TEXT, mixed-mode CDs, CD-DA audio. That’s also why you can’t just rename game.bin</code> to game.iso</code> and mount it: a mixed-mode CD has non-filesystem sectors</strong> at the beginning, audio tracks that aren’t a filesystem at all, and per-sector headers that ISO expects stripped.</p> bchunk</code> does the conversion properly:</p> Data tracks</strong> become ISO 9660 files (.iso</code>) — the 2352-byte CD sectors are trimmed to 2048-byte ISO sectors, headers discarded.</li> Audio tracks</strong> become 16-bit stereo 44.1 kHz .wav</code> files, each with a proper WAV header.</li> </ul> After that you can mount -o loop</code> the .iso</code>, play the .wav</code>s, or feed them to a burner.</p> Installing</h2> Debian / Ubuntu / Mint</h3> sudo apt install bchunk </code></pre> macOS (Homebrew)</h3> brew install bchunk </code></pre> Arch / Manjaro</h3> sudo pacman -S bchunk # or from AUR: yay -S bchunk </code></pre> Fedora / RHEL / CentOS</h3> bchunk</code> isn’t in the default repos; get it from RPMFusion or build from source:</p> git clone https://github.com/hessu/bchunk.git cd bchunk make sudo cp bchunk /usr/local/bin/ </code></pre> Windows</h3> Use WSL and apt install bchunk</code>. There’s an old native port but WSL is easier.</p> Basic usage</h2> bchunk game.bin game.cue game </code></pre> Output:</p> game01.iso # data track, mountable as ISO 9660 game02.wav # audio track 1 game03.wav # audio track 2 ... </code></pre> The basename</code> (game</code> in the example) is the prefix for every output file. Track numbers start at 01</code>.</p> Useful options</h2> bchunk</code> has a small, stable set of flags — most of them are there to handle specific CD quirks.</p> -v</code></strong> — verbose. Prints each track as it’s processed. Use this the first time you run it to confirm you’re getting the track layout you expect.</li> -w</code></strong> — write .wav</code> files (default). Explicit form.</li> -r</code></strong> — raw audio output instead of .wav</code>. Useful if you’re piping into sox</code> or ffmpeg</code> and don’t want a second header-stripping step.</li> -p</code></strong> — Psx/PlayStation mode</strong>. Treats Mode 2 sectors more loosely — needed for many PlayStation CD images where the cue sheet is imprecise.</li> -s</code></strong> — swap byte order on audio tracks. Needed if the .bin</code> was produced by a ripper that wrote little-endian audio where bchunk</code> expects big-endian (or vice versa). Symptom: output .wav</code> sounds like white noise.</li> -W</code></strong> — write .wav</code> with a verified (rather than computed) header size. Rarely needed.</li> -E</code></strong> — use the exact track boundaries from the cue sheet rather than probing. Use this if audio tracks sound clipped at the beginning or end.</li> </ul> Mounting the resulting .iso</h2> On Linux:</p> sudo mkdir /mnt/cd sudo mount -o loop game01.iso /mnt/cd ls /mnt/cd </code></pre> On macOS:</p> hdiutil attach game01.iso </code></pre> Common gotchas</h2> “Illegal or unsupported track type” or empty output</h3> Your cue sheet is malformed or references a .bin</code> size that doesn’t match. Open the .cue</code> in a text editor — it’s plain text — and check:</p> The FILE "..."</code> line points at the right .bin</code> filename, case-sensitive.</li> TRACK</code> entries are numbered sequentially with types MODE1/2352</code>, MODE2/2352</code>, or AUDIO</code>.</li> Index entries (INDEX 00</code>, INDEX 01</code>) are MM:SS:FF, with FF being frames (0–74).</li> </ul> Audio tracks sound like static</h3> Byte order mismatch. Retry with -s</code>:</p> bchunk -s game.bin game.cue game </code></pre> Single .iso</code> is fine, but audio tracks are silent or truncated</h3> Try -E</code> to force cue-sheet-exact boundaries:</p> bchunk -E game.bin game.cue game </code></pre> PlayStation/PSX image won’t split cleanly</h3> Use -p</code>:</p> bchunk -p psx.bin psx.cue psx </code></pre> This is the most common complaint on forums — PSX cues are almost always Mode 2 and bchunk</code> without -p</code> is strict about them.</p> Multiple .bin</code> files referenced in the cue</h3> Some rippers produce one .bin</code> per track plus a combining cue sheet. bchunk</code> expects one .bin</code> for the whole disc. Concatenate them first with cat track01.bin track02.bin ... > combined.bin</code> and point a single-file cue at combined.bin</code>.</p> Alternatives worth knowing</h2> cdemu</code></strong> — user-space CD emulator for Linux. Can mount a .bin</code>/.cue</code> directly without splitting. Useful if you just want to read</em> the data track temporarily.</li> ecm-tools</code></strong> — different format (.ecm</code>), but same problem space. Worth knowing if you encounter it.</li> 7z</code> / p7zip</code></strong> — newer 7-Zip versions can list and extract ISO 9660 data tracks from a raw .bin</code>, but can’t recover audio as .wav</code>.</li> ffmpeg</code></strong> — if you want MP3 / FLAC / Opus instead of .wav</code>, pipe the raw output: bchunk -r game.bin game.cue game && ffmpeg -f s16be -ar 44100 -ac 2 -i game02.raw game02.flac</code>.</li> </ul> Why it’s still useful in 2026</h2> Optical-media imaging has been a solved problem for decades, but .bin</code>/.cue</code> is still the default output of cdrdao</code>, still what old archives are stored as, and still what shows up when someone hands you a CD backup that isn’t an ISO. bchunk</code> is a ~1,000-line C program, written in the late 1990s, that does one job correctly and has barely changed in twenty years. It’s in every major distribution, it compiles cleanly on modern systems, and it’s the right tool.</p> If you’re trying to recover data from an old CD image: start here.</p> binlist.net — how a Fuerteventura holiday side-project became iinlist.com 2026-04-22T00:00:00+00:00 TL;DR —</strong> binlist.net</a> is a free HTTP API</strong> that takes the first 6–8 digits of a credit card number (the BIN</strong> or IIN</strong>) and returns the issuing bank, country, card scheme (Visa, Mastercard, etc.), card type (debit/credit/prepaid), and category. I started it in August 2013 on a holiday in Fuerteventura</strong>, because I needed a BIN lookup for another project and everything that existed was either paywalled, stale, or behind a sketchy scraper. It was my first ever Go project</strong>, hit 100,000 queries/day</strong> within weeks, and crossed 1 million queries/day in 2015</strong>. It is still online, still free, still curl</code>-friendly. The commercial variant, iinlist.com</a>, is what I co-founded after binlist.net’s success; it’s the same idea with payment-industry-grade accuracy</strong>, 8-digit IIN support</strong> (mandated by ISO/IEC 7812 since 2022), ARDEF-backed ranges</strong>, and an SLA — built for banks, PSPs, fraud teams, and issuers who need to treat BIN data as production data.</p> BIN vs IIN — a one-paragraph primer</h2> The first six (historically) or eight (since 2017, mandatory 2022) digits of a card number are the Issuer Identification Number</strong> (IIN). The old name, still widely used, is Bank Identification Number</strong> (BIN). Given a BIN/IIN, you can determine:</p> Scheme / network</strong> — Visa, Mastercard, Amex, Discover, JCB, UnionPay, Diners.</li> Issuer</strong> — the bank or fintech that issued the card.</li> Country</strong> — country of the issuer, which is not necessarily the cardholder’s country but is a useful proxy for risk scoring, tax logic (EU/EEA VAT MOSS), and user experience (preferred language, local payment methods).</li> Type</strong> — debit, credit, prepaid, deferred debit, charge.</li> Category / product</strong> — Classic, Gold, Platinum, Business, Corporate, etc. Useful for acceptance cost routing (commercial cards cost more to accept).</li> </ul> All of this is “sensitive” in the sense that issuers don’t publish full BIN tables and card schemes consider them proprietary. In practice, BIN ranges leak constantly — every authorisation the scheme routes, every chargeback dispute — and there’s a whole cottage industry around keeping reasonably accurate BIN tables.</p> Why I built binlist.net on holiday</h2> Summer 2013. Playitas, southern Fuerteventura</strong> — the resort on the Atlantic side down by Gran Tarajal. Rented apartment, small balcony, Canary wind doing its thing. I had an idea for a side-project that needed to look up cards by BIN and I did not want to pay a payments vendor €200/month for it. The existing free options were:</p> Wikipedia’s IIN list</strong> — reasonably accurate for well-known schemes, woefully incomplete for niche issuers, updated by volunteers who don’t work in payments.</li> Pasted CSVs on forums</strong> — decent coverage for US issuers, always outdated.</li> Google Fusion Tables</strong> — deprecated by Google that same year.</li> Scrapers of merchant-bank lookup forms</strong> — ToS-violating, brittle.</li> </ul> What I wanted was curl http://example.com/40012345</code> returning clean JSON. So I built it.</p> The stack (then)</h3> This was my first ever Go project</strong>. I’d been reading about Go for a while and wanted a small, well-scoped excuse to try it; a single-endpoint JSON API over an in-memory BIN table was perfect. Ruby/Sinatra would have been faster for me to type, but I wanted to learn something, and the memory and latency characteristics of a Go binary turned out to be exactly what a free-tier public API needed.</p> Go</strong> — a single binary, net/http</code>, no framework. The whole server was a few hundred lines.</li> In-memory BIN range table</strong>, built at boot from a ~300 MB source file. Lookups were O(log n) over a sorted slice.</li> Deployed on a single Hetzner VM</strong> from day one (I briefly considered Heroku but Heroku’s free dyno memory limits didn’t fit a fully-loaded BIN table).</li> JSON + XML + CSV</strong> response formats, because 2013.</li> Data seed</strong> from a combination of public Wikipedia scrapes, the old “Mars Base” CSV from 2009, and a set of ranges I’d been accumulating at work.</li> </ul> Total build time on that balcony: a weekend — about half of which was me figuring out go build</code>, GOPATH</code> (Go modules didn’t exist yet), and how interfaces worked. I bought the domain on the Monday, deployed the binary, and tweeted about it.</p> Traffic curve</h3> Week 1:</strong> a few hundred queries/day, mostly me testing.</li> Month 1:</strong> ~100,000 queries/day</strong> after developers on Stack Overflow and a couple of e-commerce forums found it.</li> By early 2015:</strong> crossed 1 million queries/day</strong> sustained, with spikes above 2M during flash-sale events on merchants that called it on every checkout page-load.</li> </ul> Scaling to that point cost almost nothing because Go’s single-binary footprint meant a ~€5/month VPS handled the whole thing; the bottleneck for a long time was the NIC, not CPU or memory.</p> 13 years later</h3> binlist.net still runs. It has migrated infrastructure a few times — Hetzner VM → Hetzner fleet → a small fleet behind Cloudflare — and the data seed has been continuously updated, but the API surface (and most of the original Go code) is the same. Today it serves tens of millions of lookups per month</strong>, free, no API key required, with a soft rate limit on anonymous callers to keep it honest.</p> It has ~2,000 Google impressions/month</strong> for queries like “binlist”, “bin list bank identification number”, “list of bank identification numbers” — still picking up the long tail of developers who type the same question I typed into Google in 2013.</p> Why iinlist.com exists</h2> binlist.net’s data is good enough for “what country is this card from” decisions — risk scoring, currency presentation, analytics. It is not</strong> good enough for:</p> Acceptance-cost routing</strong> where you route commercial-card transactions through a different processor.</li> Interchange++ modelling</strong> where the margin difference between Classic and Platinum Mastercard is real money.</li> Scheme compliance</strong> — the ISO/IEC 7812 migration from 6-digit BINs to 8-digit IINs, mandated 2022, broke a lot of “I’ll just use the first six digits” logic.</li> Co-badged cards</strong> (e.g. Dankort + Visa Debit) where two networks both claim the card and the routing decision is business-critical.</li> ARDEF-grade accuracy</strong> — Visa’s Account Range Definition File is the source of truth; you really do want data derived from ARDEF for anything production-grade.</li> </ul> iinlist.com solves these, commercially. I co-founded it with a small team of people who know payments data professionally. It’s the product binlist.net is the free-tier advertisement for. Some of our customers are names you’d recognise; most are not. All of them eventually reach the same conclusion: BIN data that’s “mostly right” costs more in wrong decisions than accurate data costs in licence fees</strong>.</p> What iinlist.com is, specifically</h3> 8-digit IIN support</strong> across all schemes.</li> Daily updates</strong>, derived from ARDEF + scheme feeds + issuer announcements + internal verification.</li> Richer enrichment</strong>: card type, product category, issuing country, issuer branding, regulatory classifications (commercial vs consumer, prepaid flag, etc.).</li> SLA and support</strong>. You can file a ticket and it will actually reach a human.</li> On-prem / self-hosted option</strong> for customers whose compliance doesn’t allow “BIN lookup as a third-party API call in the authorisation path”.</li> Pricing</strong> that makes sense for both a scrappy fintech (monthly plan) and an established acquirer (annual, unlimited).</li> </ul> Can I just use binlist.net commercially?</h2> You can use binlist.net however you want; there’s no gate. But:</p> There’s no SLA, no uptime guarantee, and no contract. It’s a side project that happens to have stayed up for 13 years.</li> Rate limits on anonymous traffic will kick in at production volume. Buy a licence from iinlist.com and the problem is solved.</li> If your regulator asks where your BIN data comes from, “a free API my developer found” is not the answer you want to give.</li> </ul> For anything hobby, demo, or prototype: binlist.net is perfect. For anything where wrong BIN data becomes someone’s KPI: iinlist.com.</p> Using binlist.net today</h2> $ curl -sH "Accept-Version: 3" https://lookup.binlist.net/45717360 { "number": { "length": 16, "luhn": true }, "scheme": "visa", "type": "debit", "brand": "Visa/Dankort", "country": { "numeric": "208", "alpha2": "DK", "name": "Denmark", "emoji": "🇩🇰", "currency": "DKK", "latitude": 56, "longitude": 10 }, "bank": { "name": "Jyske Bank A/S", "url": "www.jyskebank.dk", "phone": "+4589893300", "city": "Silkeborg" } } </code></pre> Accept-Version: 3</code></strong> — pins to API v3.</li> Anonymous rate limit</strong> — documented on the site, plenty for casual use.</li> Zero warranties</strong> — if the response is wrong, submit a correction on the GitHub repo. For commercial guarantees, see iinlist.com.</li> </ul> FAQ</h2> Is BIN / IIN data regulated?</h3> BIN ranges themselves are not personal data under GDPR — a BIN identifies an issuer, not a person. Combining a BIN with a full card number is a different story and falls under PCI-DSS.</p> What changed with the 8-digit IIN migration?</h3> ISO/IEC 7812 formalised 8-digit IINs in 2017 with a hard migration deadline in April 2022 for the major networks. If your code still treats only the first six digits as the issuer identifier, you’re silently misrouting a growing share of traffic — modern Visa and Mastercard issuer ranges are defined at 8 digits.</p> Why not just look it up client-side?</h3> You can, with a static list in the browser. But you’ll accept a trade-off: freshness (the static list will be out of date within weeks) or bundle size (the current BIN table is megabytes uncompressed). A server-side API is the conventional answer.</p> Does binlist.net log the BINs I query?</h3> Aggregate analytics only — enough to detect abuse and rate-limit. Individual queries are not associated with a user. iinlist.com has a stricter no-logging posture for customers where that matters.</p> Is the source code open?</h3> The API surface of binlist.net is on GitHub, with contribution guidelines for data corrections. The data ingestion pipeline is not open-source; it relies on scheme feeds that require licences.</p> Are binlist.net and iinlist.com the same company?</h3> Separate projects, overlapping origins, same operator on my side. binlist.net is a personal free service; iinlist.com is a commercial company with co-founders and employees. The two are operationally independent but share institutional knowledge about BIN data that is not easy to accumulate from scratch.</p> Thirteen years in</h2> The thing I find most interesting about binlist.net is not the traffic — it’s the kind of questions</strong> developers are still typing into Google in 2026: “what is a bin list”, “bin number example”, “list of issuer identification numbers”. These are the exact queries I was typing in 2013 on that balcony in Playitas. Payments as an industry keeps adding layers, but the foundational questions don’t change.</p> If you’re sitting on a beach with a laptop and you have an itch for a side-project that scratches your own back, go build it — and while you’re at it, try the language you’ve been meaning to learn. Sometimes it turns out a lot of people have the same itch, and thirteen years later you have a useful thing to point them at and a working knowledge of Go.</p> My CM3588 project — a 4-NVMe ARM64 home NAS on 10 W idle 2026-04-22T00:00:00+00:00 TL;DR —</strong> The FriendlyElec CM3588 NAS Kit</a> is an RK3588-based compute module on a carrier board with four M.2 NVMe slots (PCIe 3.0 x1 each)</strong>, 2.5 GbE</strong>, 2× HDMI out</strong>, USB 3.0</strong>, and an 8- or 16-core ARMv8 CPU (4× Cortex-A76 + 4× Cortex-A55). Fully loaded with four NVMe drives it idles at about 10 W</strong>, peaks around 20 W under heavy I/O, and reads/writes an NVMe at roughly 1 GB/s (the bus limit, not the drive). My own unit runs Debian on the mainline kernel, with ZFS on root, four 2 TB NVMe drives in a raidz2</code> pool, Samba for LAN shares, and Tailscale for off-LAN access. It has replaced a tower PC running TrueNAS and cut NAS power draw by about 60 W.</p> Why this board</h2> I’d been running a tower PC as a home NAS for years: a second-hand desktop, six 3.5“ spinning disks, and a noisy fan. It worked, but it was using 70–80 W idle and sitting in a cupboard that needed active ventilation. The disks were loud enough that I’d moved them to the far corner of the house.</p> Three things I wanted from a replacement:</p> NVMe-only.</strong> Spinning disks are cheaper per terabyte but the noise, vibration, and heat aren’t worth it for a home NAS sized in the single-digit terabytes. 4× 2 TB NVMe is plenty.</li> ARM, for the power draw.</strong> An x86 board with 4× PCIe slots wired to NVMe would pull 30–40 W idle. ARM can do it in 10.</li> Mainline Linux, not a vendor fork.</strong> I want apt-get dist-upgrade</code> to work, zfs</code> to compile from DKMS against a current kernel, and no three-year-old vendor BSP.</li> </ol> The CM3588 NAS Kit hits all three.</p> Hardware</h2> SoC:</strong> Rockchip RK3588 (4× Cortex-A76 @ 2.4 GHz + 4× Cortex-A55 @ 1.8 GHz, Mali-G610 GPU, 6 TOPS NPU). ARMv8.2-A.</li> RAM:</strong> 8 GB LPDDR4X on the module I bought. 16 GB and 32 GB variants exist.</li> Storage:</strong> 64 GB eMMC on-module for OS + 4× M.2 Key-M 2280 slots, each PCIe Gen 3 x1</strong> (so ~1 GB/s per slot, not x4).</li> Network:</strong> 1× 2.5 GbE (Realtek RTL8125B).</li> USB:</strong> 2× USB 3.0 Type-A, 1× USB 3.0 Type-C (DisplayPort alt-mode), 1× USB 2.0.</li> Video:</strong> 2× HDMI out, 1× HDMI in</strong> (RK3588’s capture block).</li> Power:</strong> 12 V barrel jack. A 60 W brick is more than enough.</li> </ul> The board is small — roughly 10 × 10 cm — and passive over the SoC plus a small fan blowing across the NVMe drives. Mine sits flat on a shelf without a case.</p> NVMe compatibility caveat</h3> The one gotcha worth knowing: the CM3588 NAS Kit is not compatible with some WD Blue SN580 and WD Black SN850 drives</strong> — the linkup flaps at boot. I use Samsung 990 EVO and Crucial P3 Plus; both are fine. Check the FriendlyElec wiki compatibility list before buying NVMe drives.</p> OS and filesystem</h2> I run Debian 13 (trixie)</strong> with the mainline kernel</strong> — RK3588 support is good enough from 6.8 onwards for headless use. The FriendlyElec-provided Debian image works out of the box, but I reinstall on top of it to get a clean Debian rather than their BSP.</p> Root filesystem:</strong> ext4</code> on eMMC.</li> Data pool:</strong> zfs</code> raidz2</code> across the four NVMe drives. With 4× 2 TB, raidz2</code> gives ~3.5 TB usable with two-disk redundancy. Yes, raidz2</code> on four drives is conservative; it also means a double failure doesn’t eat the pool, and on NVMe the rebuild is fast enough that I don’t lose sleep.</li> ZFS module:</strong> DKMS against the running kernel. Rebuilds automatically on kernel upgrades. Has worked without manual intervention across three kernel bumps.</li> ARC tuning:</strong> Capped at 2 GB. This leaves headroom on an 8 GB system.</li> </ul> Throughput is bottlenecked by 2.5 GbE for network I/O (~280 MB/s sustained) long before ZFS or the NVMe drives break a sweat. Local operations on the pool hit around 2 GB/s aggregate sequential read.</p> Services</h2> Kept deliberately simple:</p> Samba</strong> for SMB shares to the Macs and Windows box on the LAN.</li> rsync + cron</strong> for nightly backups from three other machines.</li> ZFS snapshots</strong> every hour, retained for a week. zfs send</code> pipes the dataset weekly to an off-site B2 bucket via zfs-autobackup</code> + rclone.</li> Tailscale</strong> for off-LAN access. No port-forwarding, no dyndns, no VPN concentrator. SSH and Samba both ride the Tailscale interface when I’m away.</li> Cockpit</strong> for the occasional “why is the fan loud” dashboard moment.</li> </ul> That’s it. No Docker swarm, no Kubernetes, no dozen sidecar containers. The board does one job — serve files on the LAN and let me pull backups off-site — and it does it quietly.</p> Power and noise</h2> Idle</strong> (all four NVMe spun up, no traffic): ~10 W</strong> at the wall.</li> Busy</strong> (NVMe read saturating 2.5 GbE, ZFS ARC warm): ~18–20 W</strong>.</li> Peak</strong> (scrub across the whole pool, all cores hot): ~25 W</strong>.</li> </ul> Compared to the 70–80 W tower it replaced, the ROI on electricity alone is about 500 kWh/year</strong>, or roughly 1,500 kr/year</strong> at Danish residential rates. The board paid for itself in about a year.</p> Noise: effectively inaudible from more than a metre away. The fan is small and 80% of the time it’s barely spinning.</p> What didn’t work, or took effort</h2> Vendor kernel.</strong> The FriendlyElec-shipped kernel is FriendlyElec’s fork of 6.1 with RK-specific patches. It works for their turnkey NAS image, but DKMS ZFS builds are painful against it. Moving to mainline fixed this.</li> HDMI capture.</strong> The RK3588 has a hardware HDMI input block. In mainline it’s still experimental. I have a rough use case for it (pulling a signal from an old device for archival) but haven’t made it work end-to-end. Parked for now.</li> NPU.</strong> The 6 TOPS NPU is underused. Mainline has basic RKNPU support but for anything practical you still need FriendlyElec’s rknn-toolkit2</code>. Not a blocker for a NAS.</li> </ul> FAQ</h2> Why not x86?</h3> An x86 mini-PC with 4× NVMe is ~2× the idle power and ~2× the purchase price (once you include the case, PSU, and CPU). For a home NAS where the workload is “serve files” rather than “run 40 containers”, ARM wins.</p> Why not Raspberry Pi 5?</h3> The Pi 5 has one PCIe 2.0 x1 lane exposed via an HAT — you can bolt on an NVMe, but only one, and at ~500 MB/s ceiling. The CM3588 has four lanes at PCIe 3.0 wired directly. Different class of board.</p> Why not OpenMediaVault or TrueNAS?</h3> Both would work. I prefer plain Debian + Samba + ZFS because the upgrade path for Debian is well-known to me, and OMV/TrueNAS are a layer I’d have to re-learn. Your mileage will vary.</p> Why raidz2</code> on four drives and not mirror + mirror</code>?</h3> I considered it. mirror + mirror</code> gives you faster writes and easier expansion but only 4 TB usable from 4× 2 TB, same as raidz2</code>. With raidz2</code> any two drives can fail; with striped mirrors you can lose two drives, but only if they’re in different mirror pairs. On four drives the capacity is identical and raidz2</code> has the stronger failure tolerance.</p> Can it run Plex / Jellyfin?</h3> Yes, and the RK3588’s hardware H.265/VP9/AV1 decode block does the heavy lifting. Jellyfin with rkmpp</code> accelerated decoding handles 4K HEVC transcodes at about 3× realtime. I don’t run either on this box — my Plex lives elsewhere — but it’s viable.</p> Does it suspend?</h3> Not reliably. Leave it on; idle is 10 W anyway.</p> What about noise and heat in summer?</h3> Passive heatsink plus one small fan. In a Danish summer (20–25 °C ambient) it tops out around 55 °C die temp under a ZFS scrub. No throttling I’ve measured.</p> Verdict</h2> If you want a quiet, low-power, all-NVMe home NAS with enough PCIe to matter</strong> and you’re willing to spend an evening on Debian + ZFS, the CM3588 NAS Kit is the best option I’ve found. It’s not the cheapest — a second-hand Optiplex is cheaper upfront — but on three-year TCO including electricity it pays back clearly.</p> The RK3588 itself is a surprisingly capable SoC for homelab workloads. Once mainline kernel support landed, I stopped treating it as “an ARM curiosity” and started treating it as a default answer for small always-on servers.</p> Two years in, mine has been rebooted twice (once for a kernel upgrade, once because I moved the shelf). I’d buy it again.</p> fcrackzip — recover lost zip passwords on Linux, macOS, and Windows (2026) 2026-04-22T00:00:00+00:00 TL;DR —</strong> fcrackzip</code></strong> is a free, open-source command-line tool for recovering the password of an encrypted .zip</code> file. It supports brute-force</strong> (over a user-defined charset and length) and dictionary</strong> attacks, works on Linux/macOS/WSL, and is the right first tool when you need to recover a forgotten password on a zip you legitimately own. It is only fast against classic ZipCrypto</strong> encryption; for the newer AES-256</strong> zip profile, fcrackzip</code> will not work — you want zip2john</code> + hashcat</code> instead. Install with apt install fcrackzip</code> (Debian/Ubuntu), brew install fcrackzip</code> (macOS), or build from source.</p> This post walks through the practical cases. It assumes you have authorisation to recover the password</strong> — your own files, a client’s, a CTF. Don’t use it against zips you don’t own.</p> Install</h2> # Debian / Ubuntu / Mint / Kali sudo apt install fcrackzip # macOS (Homebrew) brew install fcrackzip # Arch / Manjaro sudo pacman -S fcrackzip # Windows # Use WSL2 + Ubuntu and `apt install fcrackzip`. # A native .exe exists but is old — WSL is simpler. # From source git clone https://github.com/hyc/fcrackzip.git cd fcrackzip && ./configure && make sudo cp fcrackzip /usr/local/bin/ </code></pre> Check what kind of encryption your zip uses first</h2> fcrackzip</code> only handles classic ZipCrypto</strong> (the original, weak PKZIP encryption). For modern AES-128 / AES-256</strong> zips (introduced by WinZip 9 in 2003, now default in some tools), fcrackzip</code> will silently fail to find the password no matter how long you run it.</p> Quickest check with zipinfo</code>:</p> $ zipinfo -v archive.zip | head -40 </code></pre> Look for WinZip AES encryption, strength 3</code> (= AES-256). If you see that, skip to the hashcat section.</p> Or with 7z</code>:</p> $ 7z l -slt archive.zip | grep -i 'method\|encrypted' Method = ZipCrypto Store ← fcrackzip works Method = AES-256 Deflate ← fcrackzip will NOT work </code></pre> Basic brute-force</h2> fcrackzip -v -b -c 'a1' -p aaaa -u archive.zip </code></pre> -v</code></strong> — verbose.</li> -b</code></strong> — brute-force mode.</li> -c 'a1'</code></strong> — charset. a</code> = lowercase a–z</code>, A</code> = uppercase, 1</code> = digits, !</code> = printable symbols. Combine: 'aA1!'</code> = all printable ASCII (94 chars).</li> -p aaaa</code></strong> — starting password (defines minimum length = 4 here).</li> -u</code></strong> — only report if the decrypted file “unzips” cleanly (filters false positives — ZipCrypto has a small CRC that many random passwords pass).</li> </ul> Length: -p aaaaa</code> starts at 5 characters. fcrackzip</code> doesn’t have a --max-length</code> flag; it increments the starting password through the charset forever, so letting it run to “completion” at length 8 on the full printable ASCII charset is about 94⁸ ≈ 6×10¹⁵ candidates</strong> — not realistic. You bound the attack by picking a reasonable max charset + length, or by using a dictionary.</p> Dictionary attack</h2> fcrackzip -v -D -u -p /usr/share/wordlists/rockyou.txt archive.zip </code></pre> -D</code></strong> — dictionary mode.</li> -p <file></code></strong> — wordlist file, one candidate per line.</li> -u</code></strong> — verify via unzip, as before.</li> </ul> rockyou.txt</code> is the standard 14 M-entry wordlist shipped with Kali and available everywhere. If you have context about the password (it’s someone’s name + year, it’s a project codename), assemble a smaller targeted wordlist — hit rates are usually much higher than any generic list.</p> Speed and what to expect</h2> fcrackzip</code> is single-threaded and CPU-bound. On a modern laptop you’ll see roughly:</p> 10–30 million ZipCrypto attempts per second per core</strong> for a dictionary attack against a typical zip.</li> Brute-force slightly faster because less string I/O.</li> </ul> That makes it fine for:</p> Dictionary attacks</strong> against any reasonable wordlist.</li> Short brute-force</strong> (4–6 chars alphanumeric).</li> </ul> It makes it not fine for:</p> Length 8+ with symbols</strong> — you’ll never finish.</li> AES-256 zips</strong> — wrong tool.</li> </ul> When to reach for hashcat instead</h2> If fcrackzip</code> is too slow, or the zip is AES-encrypted, migrate to hashcat</code>. It’s the general-purpose password-cracking tool, GPU-accelerated, and handles both ZipCrypto and AES WinZip hashes.</p> Step 1: extract the hash with zip2john</code></h3> zip2john</code> is part of John the Ripper. Ubuntu: apt install john</code>.</p> $ zip2john archive.zip > hash.txt $ cat hash.txt archive.zip:$zip2$*0*3*0*...*$/zip2$::archive.zip:secret.pdf:/path/to/archive.zip </code></pre> Step 2: feed it to hashcat</h3> # ZipCrypto (mode 17200, 17210, 17220, 17225 depending on compression) hashcat -m 17200 hash.txt /path/to/wordlist.txt # AES-encrypted WinZip (mode 13600) hashcat -m 13600 hash.txt /path/to/wordlist.txt </code></pre> On a single modern discrete GPU (e.g. RTX 4090) you’ll see:</p> ZipCrypto: ~5–10 billion H/s</strong></li> WinZip AES-256: ~10–50 million H/s</strong> (much slower because AES is expensive and PBKDF2 iterations are involved)</li> </ul> hashcat’s rule engine, mask attacks (-a 3</code>), and combinator mode (-a 1</code>) make it vastly more flexible than fcrackzip</code>. For anything non-trivial it is the right tool.</p> Common gotchas</h2> “PASSWORD FOUND!!!!: pw == abc” but unzip</code> still asks for a password</h3> You didn’t use -u</code>. fcrackzip’s CRC check has false positives. Re-run with -u</code> to verify candidates against a real decompression attempt.</p> Different files in the same zip have different passwords</h3> Classic PKZIP supports per-file passwords. fcrackzip</code> attacks one file at a time; pass -l <filename></code> (or let it pick the first encrypted one) if you need to be specific.</p> fcrackzip finds the password, but I still can’t unzip</h3> Character set / locale issue. If the password contains non-ASCII characters, the zip’s creator may have used a different encoding than your terminal. Try unzip -P "$(echo -n 'passwd' | iconv -t cp437)" archive.zip</code>.</p> AES-encrypted and dictionary doesn’t find it</h3> hashcat + rules + a targeted wordlist is the move. See the migration steps above.</p> Defensive takeaway</h2> If you’re generating zip files you want to stay encrypted: use AES-256</strong>, not ZipCrypto. Most modern tools (7z</code>, zip</code> from InfoZIP with -e</code>, WinZip, Keka) give you AES if you ask. The default on zip</code> unfortunately is still ZipCrypto on many systems. Check with 7z l -slt archive.zip</code> before shipping it.</p> And pick a password with length, not cleverness. hashcat</code> doesn’t care how weird your substitution pattern is; it only cares about entropy. A four-word passphrase (correct-horse-battery-staple</code>-style, ~44 bits) is fine against offline ZipCrypto attacks; a random 12-character mixed password (~78 bits) is fine against GPU AES attacks. Anything shorter is recoverable.</p> FAQ</h2> Is fcrackzip legal?</h3> Recovering passwords on files you own or are authorised to access is legal in every jurisdiction I’m aware of. Doing it on someone else’s file without authorisation is unauthorised access — the same law that applies to any other computer intrusion.</p> Is fcrackzip maintained?</h3> Barely. The codebase has been stable for fifteen-plus years. For modern work, the combination of zip2john</code> + hashcat</code> has eclipsed it.</p> Can fcrackzip use a GPU?</h3> No. fcrackzip</code> is CPU-only. If GPU is what you have, go straight to hashcat.</p> Does fcrackzip handle .7z, .rar, .gpg files?</h3> No — only classic PKZIP .zip</code>. For .7z</code>, use 7z2john</code> + hashcat (mode 11600). For .rar</code>, rar2john</code> + hashcat (mode 12500 / 13000). For .gpg</code>, gpg2john</code> + hashcat (mode 17010+).</p> How do I generate a targeted wordlist?</h3> hashcat</code>’s maskprocessor (mp64</code>), crunch</code>, and cewl</code> (crawls a site for candidate words) are all worth knowing. For recovering a specific forgotten password, writing down what you remember about it — length, likely words, likely numbers — and building a mask attack from that is the highest-yield approach.</p> Summary</h2> fcrackzip</code> + -D</code> + a wordlist is the right first try.</li> If that doesn’t work and it’s ZipCrypto: fcrackzip</code> + -b</code> with a narrow charset and short length.</li> If that doesn’t work or it’s AES: zip2john</code> + hashcat</code> on a GPU.</li> If that doesn’t work: your password was strong enough. That’s the system working as intended.</li> </ul> pdfcrack — recover lost PDF passwords on Linux and macOS (2026) 2026-04-22T00:00:00+00:00 TL;DR —</strong> pdfcrack</code></strong> is a command-line tool that recovers the user password</strong> or owner password</strong> of an encrypted PDF by brute-force or dictionary attack. It’s small, written in C, runs on Linux/macOS/WSL, and handles every encryption profile PDF has shipped — 40-bit RC4, 128-bit RC4, 128-bit AES, 256-bit AES (PDF 1.7 + 2.0). It is single-threaded and CPU-only</strong>, so it is fast on the weak old RC4-40 encryption but increasingly slow as PDFs get modern. Install with apt install pdfcrack</code> (Debian/Ubuntu), brew install pdfcrack</code> (macOS), or build from source. When pdfcrack</code> is too slow, switch to pdf2john</code> + hashcat</code></strong> on a GPU.</p> This walkthrough assumes you have authorisation to recover the password</strong> on the PDF — your own document, a client’s, or a legally-acquired file. Don’t attack PDFs you don’t own.</p> User password vs owner password</h2> PDF has two passwords:</p> User password</strong> — required to open and read</strong> the document.</li> Owner password</strong> — required to remove restrictions</strong> (print, copy, modify) on a document that opens without a user password.</li> </ul> Many “protected” PDFs are only owner-password-restricted: they open fine, but printing and copying are disabled by the reader. Those are trivial to unlock — qpdf --decrypt</code> or any of the pdftk</code>-style tools strip owner-only restrictions without needing to guess anything. pdfcrack</code> is for the harder case: a user-password-protected PDF you can’t open at all</strong>.</p> Check which you’re dealing with:</p> $ qpdf --show-encryption document.pdf R = 6 P = -3904 User password = Supplied password is owner password extract for accessibility: allowed extract for any purpose: not allowed print low resolution: allowed print high resolution: not allowed modify document assembly: not allowed modify forms: not allowed modify annotations: not allowed modify other: not allowed stream encryption method: AESv3 string encryption method: AESv3 file encryption method: AESv3 </code></pre> R = ...</code></strong> tells you the revision / profile. R=2</code> = RC4-40, R=3</code> = RC4-128, R=4</code> = AES-128, R=5/6</code> = AES-256.</li> “Supplied password is owner password”</strong> + “User password = (empty)” means you can open it and just need to strip restrictions. Use qpdf --decrypt --password='' input.pdf output.pdf</code> and you’re done.</li> </ul> Install</h2> # Debian / Ubuntu / Mint / Kali sudo apt install pdfcrack # macOS (Homebrew) brew install pdfcrack # Arch / Manjaro sudo pacman -S pdfcrack # Fedora / RHEL sudo dnf install pdfcrack # From source wget https://sourceforge.net/projects/pdfcrack/files/latest/download -O pdfcrack.tar.gz tar xf pdfcrack.tar.gz && cd pdfcrack-* make sudo cp pdfcrack /usr/local/bin/ </code></pre> Benchmark</h2> $ pdfcrack -b Benchmark: Average Speed (calls / second): MD5: 1728972.6 MD5_50 (fast): 97879.3 MD5_50 (slow): 69167.0 RC4 (40, static): 606555.3 RC4 (40, no check): 598050.0 RC4 (128, no check): 590141.7 Benchmark: Average Speed (passwords / second): PDF (40, user): 453510.2 PDF (40, owner): 220250.0 PDF (40, owner, fast): 499995.0 PDF (128, user): 22000.0 PDF (128, owner): 10408.7 PDF (128, owner, fast): 22220.0 </code></pre> Translation:</p> RC4-40</strong> (PDF 1.3, very old) — ~450k passwords/sec. Brute-force of a full 8-character alphanumeric space: ~1 week on one core.</li> RC4-128 / AES-128</strong> — ~22k passwords/sec. Brute-force becomes unrealistic above length 6 with any charset.</li> AES-256 (R=5/6)</strong> — even slower; pdfcrack</code> does support it but effectively only for dictionary attacks against small wordlists.</li> </ul> If you need speed beyond this, you want hashcat</code> on a GPU. Numbers at the bottom.</p> Dictionary attack</h2> pdfcrack -f document.pdf -w /usr/share/wordlists/rockyou.txt </code></pre> -f</code></strong> — target file.</li> -w <file></code></strong> — wordlist, one candidate per line.</li> Optional -o</code></strong> — attack the owner password only (ignore user password). Default is to try user password first.</li> Optional -u</code></strong> — attack user password only.</li> </ul> If you have context — the password is probably a first name, a year, a project code — assemble a smaller targeted list. Generic lists are a long shot once you’re past the top ten thousand entries.</p> Brute-force attack</h2> pdfcrack -f document.pdf -c 'abcdefghijklmnopqrstuvwxyz0123456789' -n 4 -m 8 </code></pre> -c <charset></code></strong> — character set to try. Default includes a broad ASCII range.</li> -n <min></code></strong> — minimum length.</li> -m <max></code></strong> — maximum length.</li> </ul> Tune -c</code> aggressively. If you know the password is all lowercase, don’t give it uppercase. If you know it has a digit at the end, use a mask attack (hashcat territory, not pdfcrack).</p> Resume a long run</h2> pdfcrack -f document.pdf -w rockyou.txt -s /tmp/state.sav </code></pre> -s</code> writes periodic save files; if you kill pdfcrack and restart, pass -l /tmp/state.sav</code> to resume.</p> When to switch to hashcat</h2> For any modern PDF (R=4, 5, or 6 — i.e. AES-128 or AES-256), pdfcrack</code>’s single-core speed becomes the bottleneck. pdf2john</code> + hashcat</code> gets you two to three orders of magnitude more throughput on a GPU.</p> Step 1: extract the hash</h3> $ /usr/share/john/pdf2john.pl document.pdf > hash.txt </code></pre> (On Debian/Ubuntu: apt install john</code> provides pdf2john.pl</code>.)</p> Step 2: identify the hash mode</h3> $ head -1 hash.txt document.pdf:$pdf$5*6*256*-1028*1*16*... </code></pre> Map the first two numbers:</p> $pdf$1*2*...</code> → mode 10400</strong> (PDF 1.1–1.3, RC4-40, user)</li> $pdf$1*2*...</code> with owner salt → mode 10410 / 10420</strong></li> $pdf$2*3*...</code> → mode 10500</strong> (PDF 1.4–1.6, RC4-128 / AES-128)</li> $pdf$5*5*...</code> → mode 10600</strong> (PDF 1.7 r=5, AES-256)</li> $pdf$5*6*...</code> → mode 10700</strong> (PDF 1.7 r=6 / PDF 2.0, AES-256 with PBKDF2)</li> </ul> Step 3: run hashcat</h3> hashcat -m 10700 hash.txt /path/to/wordlist.txt </code></pre> On a single modern GPU (e.g. RTX 4090):</p> Mode 10400 (RC4-40):</strong> ~10 billion H/s — any practical password is recovered instantly.</li> Mode 10500 (RC4-128 / AES-128):</strong> ~100 million H/s.</li> Mode 10700 (AES-256, PBKDF2):</strong> ~50,000 H/s. This is by design — the PBKDF2 iterations make brute-force expensive.</li> </ul> For mode 10700, your attack strategy matters more than raw speed. Dictionary + rules + mask attacks targeted at likely password patterns are orders of magnitude more productive than exhaustive brute-force.</p> Common gotchas</h2> “File seems encrypted but I can still open it without a password”</h3> You’re looking at owner-only restrictions. Use qpdf --decrypt input.pdf output.pdf</code> — no cracking needed.</p> pdfcrack runs but never finds anything</h3> Three likely causes:</p> Password is longer / more complex than your charset × length covers.</strong> Increase -m</code> and/or expand -c</code>, or switch to a dictionary.</li> Password contains non-ASCII characters.</strong> pdfcrack’s charset is ASCII by default; non-ASCII user passwords in old PDFs used varying encodings (PDFDocEncoding, UTF-16). Try pdf2john</code> + hashcat, which handles the encoding properly.</li> It’s AES-256 (R=6) and you’re being patient.</strong> See speed notes above — realistic only with a dictionary.</li> </ol> “Only AES-256 is supported” error or similar</h3> Your pdfcrack</code> build is old. Ubuntu LTS sometimes ships a version that doesn’t fully handle R=6. Build from source or switch to pdf2john</code> + hashcat</code>.</p> PDF opens but printing/copying is blocked</h3> That’s owner-password-restricted only. qpdf --decrypt</code> without needing a password usually works:</p> qpdf --decrypt --password='' input.pdf output.pdf </code></pre> Defensive takeaway</h2> For anything you want to stay encrypted in 2026, use AES-256 with a PDF 2.0 (R=6) password</strong>. That’s the profile with PBKDF2 key derivation that makes offline attacks expensive on current hardware.</p> And, as always, the password’s length matters more than anything else. A 20-character random passphrase is brute-force-intractable against any current GPU. A 6-character “clever substitution” password is a coffee break on an RTX 4090.</p> FAQ</h2> Is pdfcrack still maintained?</h3> Updated slowly. The codebase handles all currently shipped PDF encryption profiles; it just isn’t where performance work is happening anymore (that’s hashcat).</p> Does pdfcrack use GPU?</h3> No. CPU-only, single-threaded. For GPU work, use pdf2john</code> + hashcat</code>.</p> Can pdfcrack recover the document if the creator cleared the user password but kept the owner password?</h3> Yes — use qpdf --decrypt</code> first; if that won’t fully decrypt, pdfcrack -o</code> attacks the owner password.</p> Does pdfcrack leak my PDF anywhere?</h3> No. It’s local. Anything online-only (“crack my PDF at cloud-service-X.com”) involves uploading the file, which you shouldn’t do for confidential material.</p> What if I only vaguely remember the password?</h3> Write down what you remember — likely words, likely digits, likely length — and build a targeted wordlist or hashcat</code> mask (-a 3 ?l?l?l?l?l?d?d?d?d</code>). That beats any generic list.</p> Can I recover text from an AES-256 PDF without the password?</h3> No. AES-256 with PBKDF2 (R=6) is, to the best of public cryptanalysis, not broken. If the password is strong and lost, the contents are lost.</p> Summary</h2> Owner-password-only?</strong> qpdf --decrypt</code>, no cracking needed.</li> User-password-protected, old (R=2/3)?</strong> pdfcrack</code> with a dictionary works fine.</li> Modern (R=4/5/6)?</strong> pdf2john</code> + hashcat</code> on a GPU, targeted attack.</li> Strong 20-character random?</strong> Accept the loss.</li> </ul> Hacking Wi-Fi across 25 years — 2002, 2007, 2012, 2017, 2022, 2027 2026-04-22T00:00:00+00:00 TL;DR —</strong> Wi-Fi security has gone through four generations — WEP</strong>, WPA</strong>, WPA2</strong>, WPA3</strong> — each introduced because its predecessor was broken. This post walks through six snapshots of the state of the art: 2002</strong> (WEP, trivial), 2007</strong> (WEP dead, WPA widespread, offline attacks emerging), 2012</strong> (WPA2 dominant, dictionary attacks on GPUs), 2017</strong> (KRACK breaks WPA2 under the right conditions, PMKID leak in 2018), 2022</strong> (WPA3 rolling out, downgrade attacks, cloud-scale cracking), 2027</strong> (today’s landscape: WPA3 nearly universal, 6 GHz opens new surface, attacks move up the stack). For each year I summarise the attack, the tool, and what a defender should have been doing. Authorised testing only — the defensive guidance at the bottom is the point.</p> At a glance</h2> Year</th> Dominant standard</th> Headline attack</th> Effort to compromise a typical network</th> Fastest dictionary / key-rate at the time</th></tr></thead> 2002</td> WEP (100%)</td> FMS statistical IV</td> ~4M packets / 2–10 h on a busy AP</td> N/A — key recovered from IVs</td></tr> 2007</td> WEP 35%, WPA 25%, WPA2 20%, open 20%</td> PTW + aircrack-ng</td> 40–85k packets / <5 min (WEP)</td> ~50–100 PSK/s (CPU, cowpatty)</td></tr> 2012</td> WPA2 ~70%</td> Reaver (WPS) + GPU PSK dictionary</td> 11,000 WPS PINs / 2–10 h</td> ~75,000 PSK/s (GTX 580)</td></tr> 2017</td> WPA2 ~85%</td> KRACK; then PMKID (2018)</td> 1 packet (PMKID) → offline dict</td> ~400,000 PSK/s (GTX 1080)</td></tr> 2022</td> WPA2 ~60%, WPA3 ~20%, mixed ~15%</td> Dragonblood downgrade</td> Force WPA2 fallback, then GPU/cloud</td> ~1.2M PSK/s (RTX 3090), ~10M (8× A100)</td></tr> 2027</td> WPA3 ~40%, mixed ~35%, WPA2 ~20%</td> Client-side + downgrade + chipset FW</td> SAE intact; legacy WPA2 on borrowed time</td> ~5–8M PSK/s (RTX 5090-era single GPU)</td></tr> </tbody></table> Approximate global deployment shares are from public Wi-Fi surveys (WiGLE aggregate trends + vendor reports); treat as ± 10 points.</p> 2002 — WEP everywhere, and trivially broken</h2> Standard:</strong> IEEE 802.11b with WEP</strong> (Wired Equivalent Privacy). 40-bit or 104-bit RC4 key, 24-bit IV, CRC-32 integrity.</p> What’s wrong with it:</strong> The IV is too small, keys are static, and RC4’s initial key schedule leaks bits of the key when certain IVs are used. These are the FMS attack</strong> (Fluhrer, Mantin, Shamir, 2001) and its descendants.</p> What an attacker did in 2002:</strong> captured traffic with a Prism-based USB adapter, collected a few million packets (hours on an active network), and extracted the key with AirSnort</strong> or WEPCrack</strong>. Attacks were so embarrassing that Wi-Fi Alliance pushed WPA as a temporary firmware-patchable fix in 2003.</p> By the numbers (2002):</strong></p> Global Wi-Fi deployment:</strong> ~100% WEP (WPA not ratified until March 2003).</li> Key length:</strong> 40-bit (export-grade) or 104-bit. Irrelevant — the attack is on the IV, not the key.</li> IV space:</strong> 24 bits → only ~16.7 M possible IVs. Birthday-paradox collision around ~5,000 packets.</li> FMS attack packet count:</strong> ~500 k–4 M “interesting” IV frames (a few hours of active traffic).</li> Typical crack wall-clock:</strong> 2–10 h on a busy SOHO network.</li> Consumer hardware required:</strong> one laptop + one Prism2/Prism2.5 USB dongle (~$40 used at the time).</li> Tools:</strong> AirSnort, WEPCrack, Kismet for capture.</li> CVEs:</strong> WEP itself isn’t a CVE, but the 2001 Borisov/Goldberg/Wagner paper and the 2001 FMS paper are the canonical breakage references.</li> </ul> What a defender should have done:</strong> realise WEP is not a security feature and treat the wireless LAN as untrusted. Use a VPN or IPSec at layer 3.</p> 2007 — WEP dead, WPA transitional, WPA2 arriving</h2> Standard:</strong> WPA (2003), a stopgap with per-packet keys (TKIP). WPA2 (2004) with AES-CCMP starting to appear in home routers.</p> What’s new for attackers:</strong> the PTW attack</strong> on WEP (2007) drops the packet count needed from ~1 million to ~40,000 — WEP now cracks in minutes. aircrack-ng</strong> becomes the canonical toolkit. Against WPA-Personal, offline dictionary attacks on the 4-way-handshake become practical on CPUs: capture a handshake, feed the PSK derivation through cowpatty</code> or aircrack-ng</code>, try dictionary entries one at a time.</p> What attackers didn’t have yet:</strong> meaningful GPU acceleration of WPA-PSK. Dictionary attacks were slow.</p> By the numbers (2007):</strong></p> Global deployment (WiGLE-style surveys):</strong> WEP ~35%, WPA ~25%, WPA2 ~20%, open ~20%.</li> PTW attack packet count:</strong> ~40,000–85,000 captured frames to recover a WEP key (down from millions).</li> Crack time with aircrack-ng + packet injection:</strong> <5 minutes, often under 60 seconds.</li> WPA-PSK dictionary rate (CPU, cowpatty/aircrack-ng):</strong> ~50–100 candidates/sec per core.</li> Rockyou wordlist</strong> (leaked Dec 2009): 14.3 M entries — became the de-facto English PSK wordlist.</li> WPA2 mandatory for Wi-Fi CERTIFIED:</strong> March 2006.</li> Aircrack-ng 1.0:</strong> released 2006, consolidating the ecosystem.</li> </ul> What a defender should have done:</strong> migrate to WPA2-AES-CCMP, pick a PSK longer than any dictionary. Drop WEP networks entirely.</p> 2012 — WPA2 dominant, GPU-cracking mature</h2> Standard:</strong> WPA2 is the default on essentially all consumer gear. WPA2-Enterprise (802.1X / EAP) in corporate networks.</p> What’s new for attackers:</strong> hashcat</strong> and oclHashcat</strong>, pyrit</strong>, and John the Ripper</strong> turn the WPA-PSK dictionary attack into a GPU problem</strong>. A handshake capture + a single modern GPU does tens of thousands of candidate PSKs per second; a small rented GPU farm handles hundreds of thousands. airodump-ng</strong> + Reaver</strong> (2011) exploit a WPS PIN</strong> implementation flaw to recover the WPA-PSK without a dictionary at all — a dealbreaker for home routers with WPS-on-by-default.</p> By the numbers (2012):</strong></p> Global deployment:</strong> WPA2 ~70%, WEP ~10%, open ~15%, WPA ~5%.</li> WPS PIN space on paper:</strong> 10⁸ = 100 million. Effective</strong> attack space after the Viehböck split: 10⁴ + 10³ = ~11,000 tries.</li> Reaver wall-clock to recover WPS PIN → PSK:</strong> 2–10 hours against an unpatched AP.</li> hashcat WPA-PSK throughput on GTX 580 (reference 2012 GPU):</strong> ~75,000 candidates/sec.</li> hashcat WPA-PSK on a small 4-GPU rig of the era:</strong> ~300,000 candidates/sec, i.e. rockyou.txt</code> (14.3 M) in ~50 seconds.</li> Real-world PSK recovery rate with rockyou + common rules:</strong> ~20–25% on captured handshakes in academic studies.</li> WPA2-PEAP/MSCHAPv2 hash rate (a Wi-Fi-adjacent Enterprise pain point):</strong> tens of millions/sec on a single GPU, full 2²⁸ keyspace within a day.</li> </ul> What defenders should have done:</strong></p> Turn off WPS.</strong> Most routers had it on by default.</li> Use long random PSKs</strong>, not dictionary words.</li> For enterprise: 802.1X + EAP-TLS with client certificates</strong>, not PEAP-MSCHAPv2 (which is itself a GPU problem).</li> </ul> 2017 — KRACK</h2> Standard:</strong> WPA2 still everywhere.</p> What’s new for attackers:</strong> KRACK</strong> (Vanhoef, Piessens, 2017) — Key Reinstallation Attack. It doesn’t crack the PSK. It exploits a subtle flaw in the 4-way handshake where, under certain conditions (specifically on Android 6+ and wpa_supplicant 2.4–2.6), replaying handshake message 3 causes the client to reinstall an all-zero session key</strong>. From there, the attacker can decrypt selected traffic and, depending on cipher suite, inject packets.</p> What made KRACK different from prior attacks:</strong> it hit the protocol, not the key</strong>. A strong PSK didn’t help. Every WPA2 implementation needed a patch. Most vendors shipped one within weeks; some took years.</p> Also in this era:</strong></p> PMKID hashcat attack</strong> (2018, Steube). Many APs leak the PMKID in a single message; one packet is enough to start an offline PSK attack. Lowered the capture bar further — no client association needed.</li> Evil twin / captive portal phishing.</strong> As device UIs got prettier, fake captive portals became alarmingly effective against humans.</li> </ul> By the numbers (2017–2018):</strong></p> Global deployment:</strong> WPA2 ~85%, WEP <3%, open ~10%, WPA3 not yet shipping.</li> KRACK CVEs:</strong> 10 in the coordinated disclosure (CVE-2017-13077 through CVE-2017-13088).</li> KRACK-affected devices:</strong> all WPA2 clients and APs — 10+ billion</strong> endpoints. Real patching took years for long-tail IoT.</li> Vendor patch latency:</strong> Microsoft / most Linux distros within 1 week of disclosure; Android 2 months+ depending on OEM; many embedded devices never patched.</li> PMKID attack packet count:</strong> 1 single frame</strong> vs. the 4-way handshake’s 4 frames — no client association or deauth needed.</li> hashcat on GTX 1080 (reference 2017 GPU):</strong> ~400,000 WPA-PSK candidates/sec — ~5× faster than 2012.</li> A rented 8× 1080 Ti instance (~$4/h in 2017):</strong> ~3M candidates/sec — rockyou.txt</code> in <5 seconds.</li> Coordinated disclosure lead time:</strong> 4 months from vendor notification to public release.</li> </ul> What a defender should have done:</strong> patch Android / wpa_supplicant immediately, enforce HTTPS everywhere so decrypted Wi-Fi traffic is less useful, start planning WPA3 migration.</p> 2022 — WPA3 rolling out, downgrade attacks</h2> Standard:</strong> WPA3 (2018) required for Wi-Fi CERTIFIED devices since 2020. Key upgrades:</p> SAE</strong> (Simultaneous Authentication of Equals) replaces the 4-way handshake PSK — offline dictionary attacks become infeasible.</li> 192-bit mode</strong> for Enterprise.</li> Forward secrecy</strong>.</li> PMF</strong> (Protected Management Frames) mandatory — neutralises deauth-based denial-of-service.</li> </ul> What’s new for attackers:</strong> WPA3 isn’t broken, but its deployment mostly isn’t WPA3-only</strong>. WPA2/3 transition mode</strong> — the default on most APs — means an attacker can force a downgrade and attack as WPA2. This is Dragonblood</strong> (Vanhoef, Ronen, 2019 + follow-ups): a family of side-channel and downgrade attacks against SAE. By 2022, patched SAE implementations mostly closed the timing side-channels; the downgrade attack still works on mixed-mode networks.</p> Also in this era:</strong></p> Cloud-scale cracking</strong>: renting 8× H100 or similar on an hourly basis makes PMK dictionary attacks practical at a scale no amateur had in 2012.</li> Chipset firmware vulnerabilities</strong> (FragAttacks, 2021): flaws in the Wi-Fi stack itself, below the WPA layer, let attackers inject frames without needing any handshake break at all.</li> </ul> By the numbers (2022):</strong></p> Global deployment:</strong> WPA2-only ~60%, WPA3 ~20%, WPA2/3 transition mode ~15%, WEP <1%.</li> New-router WPA3 support:</strong> ~60% of consumer APs shipped in 2022 supported WPA3 (vs. ~10% in 2020).</li> Dragonblood CVEs:</strong> 5 (CVE-2019-9494 through CVE-2019-9499).</li> FragAttacks CVEs:</strong> 12 in the 2021 bundle.</li> hashcat WPA-PSK on RTX 3090:</strong> ~1.2M candidates/sec.</li> 8× A100 cloud instance:</strong> ~10M candidates/sec aggregate. rockyou.txt</code> in ~1.5 seconds; a 10B-candidate mask attack in ~17 minutes.</li> Cost per billion PSK attempts on spot cloud GPUs:</strong> ~$3–5.</li> 12-character fully-random PSK entropy:</strong> 2⁷² ≈ 4.7 × 10²¹. At 10M H/s, exhaustive attack = ~15,000 years</strong>. Safe.</li> 8-character lowercase+digit PSK entropy:</strong> 2⁴¹ ≈ 2.2 × 10¹². At 10M H/s, ~2.5 days</strong>. Not safe.</li> </ul> What a defender should have done:</strong> WPA3-Personal only (no WPA2 transition) on networks where you can enforce it; PMF required; long random PSK even with SAE; keep AP firmware current.</p> 2027 — today’s landscape</h2> Standard:</strong> Wi-Fi 6E (6 GHz) and early Wi-Fi 7 deployments. WPA3 near-universal on new gear; legacy WPA2 still common in small businesses and long-lived home networks.</p> State of the art in attacks:</strong></p> SAE is holding up.</strong> No public, practical attack against a well-configured WPA3-Personal network in 2027. Dictionary attacks against the PSK are not feasible — that’s SAE’s point.</li> Downgrade attacks</strong> are the main thing. Any network still advertising WPA2/3 transition is attackable as WPA2. Adversaries look for mixed-mode SSIDs first.</li> 6 GHz opens new surface.</strong> The 6 GHz band requires WPA3 for new standards; but legacy client bridging, IoT devices without 6 GHz support, and misconfigured co-broadcast SSIDs create inconsistencies attackers exploit.</li> Client-side attacks.</strong> When the link layer is secure, attackers move up. Rogue captive portals that trick phones into trusting a bad certificate, QR-code joining with fake SSIDs, deauth-during-roaming attacks (harder now with PMF but not eliminated).</li> Supply chain.</strong> Firmware-embedded backdoors and vendor bugs in Wi-Fi chipsets (the FragAttacks legacy) remain a durable source of exploits.</li> Cloud cracking is commoditised.</strong> A weekend-long SAE-offline attack (for the cases where offline attack is possible, i.e. the target ran an unpatched SAE) costs roughly the price of a nice dinner. This mostly doesn’t matter because SAE isn’t reducible to offline dictionary attack — but it shifts economics on legacy WPA2 networks that people haven’t migrated.</li> </ul> Tools still in rotation in 2027:</strong> aircrack-ng (older, still canonical for captures and WPA2), hashcat (cracking), bettercap (Wi-Fi MITM / rogue AP), airgeddon (workflow glue), and a wave of ESP32-based pocket tools for opportunistic deauth and handshake capture.</p> By the numbers (2027):</strong></p> Global deployment:</strong> WPA3 ~40%, WPA2/3 transition ~35%, WPA2-only ~20%, WEP ~0.5% (long tail of ancient gear).</li> Enterprise share running WPA3-Enterprise 192-bit mode:</strong> still <10%. Most corporate networks remain WPA2-Enterprise with PEAP.</li> New-device WPA3 certification:</strong> mandatory for Wi-Fi 6 since 2020, Wi-Fi 6E (6 GHz) since 2022, Wi-Fi 7 at launch.</li> hashcat WPA-PSK on RTX 5090-class single GPU (2025+):</strong> ~5–8M candidates/sec.</li> 8× H100 cloud instance:</strong> ~50M candidates/sec aggregate. rockyou.txt</code> in ~0.3 seconds.</li> SAE (WPA3-Personal) offline attack:</strong> infeasible at any hash rate — the handshake does not release a crackable hash to an eavesdropper.</li> Cost to brute-force a weak 8-char WPA2 PSK in 2027:</strong> <$10 on spot cloud GPUs.</li> Cost to brute-force a 12-char random WPA2 PSK:</strong> still ~ $10⁹ (same math as 2022, GPUs 5× faster → still millennia).</li> ESP32-S3 “Wi-Fi Nugget” / Flipper Zero-class pocket tools</strong> in circulation in 2027: hundreds of thousands of units. Opportunistic handshake capture is trivial; PSK cracking is still offline on a beefy host.</li> Deauth-DoS effectiveness:</strong> near-zero on PMF-required networks; still works against the ~30% of deployed APs where PMF is “capable” but not “required”.</li> </ul> Bottom line: against WPA3-Personal with SAE, PMF required, and a random PSK</strong>, none of the 2027 toolkit gets you in via the link layer. Against a typical 2019-vintage home router still running WPA2 with a weak PSK and WPS optionally exposed</strong>, a weekend on a mid-range GPU is plenty.</p> Defensive guidance for 2027</h2> This is the part that matters more than any of the history.</p> WPA3-Personal SAE-only, or WPA3-Enterprise with EAP-TLS.</strong> No transition mode on any network you can control. Check explicitly — many APs default to transition.</li> PMF required, not optional.</strong> Protected Management Frames prevent deauth-driven handshake captures and basic denial-of-service.</li> PSK length: random, ≥ 20 characters.</strong> SAE makes short PSKs safer than they used to be, but no reason to gamble.</li> Disable WPS permanently.</strong> Even though the WPS-PIN attack is ancient, many routers still ship with it enabled for “convenience”.</li> Guest SSID isolated.</strong> Client-to-client isolation on and routed to a separate VLAN with no internal LAN access.</li> IoT SSID, separate and cloistered.</strong> Cheap Wi-Fi thermostats and toys are the weakest link on most home networks. They get their own SSID, their own VLAN, and no route to anything important.</li> Firmware updates on APs.</strong> Most of the interesting 2020s Wi-Fi vulnerabilities were chipset-level; the fix is always a firmware update. Buy APs from a vendor that ships them.</li> Assume the link layer will fail and defend above it.</strong> HTTPS everywhere, client certs on anything that matters, VPN or Tailscale for remote access. When (not if) someone breaks your Wi-Fi, layer 4+ should still hold.</li> </ul> What stayed the same across 25 years</h2> Three patterns repeat at every generation:</p> The cryptography is almost always stronger than the deployments.</strong> WEP was a design failure; WPA2 and WPA3 have been broken by implementation flaws, downgrade paths, and side channels — not by pure crypto weaknesses.</li> Defaults matter more than capabilities.</strong> WPS on by default, WPA2/3 transition mode on by default, guest networks without isolation by default — this is what attackers actually find, at scale.</li> The attacker always moves up the stack.</strong> When link-layer security improves, attacks shift to captive portals, rogue certs, client mis-configurations, and phishing. No amount of WPA3 fixes the user who clicks “Trust” on the evil twin’s fake certificate.</li> </ol> Coda</h2> If this post’s ancestor on this site, from 2010, was “How to Hack a Wireless Network” and focused on WEP with aircrack-ng</code>, the 2027 version is closer to “How to Think About Wi-Fi Security” and focuses on configuration, patching, and realistic threat modelling. The cryptography has done its job. The layers around it are the interesting frontier now.</p> Test your own networks — or networks you’re authorised to test — don’t test anyone else’s. The same law that applied in 2002 applies in 2027.</p> nemboks.dk — forward your Danish digital post (mit.dk, e-Boks) to your email inbox 2026-04-22T00:00:00+00:00 TL;DR —</strong> nemboks.dk</a> is a service that forwards Danish digital post</strong> (from mit.dk</a> and e-Boks</a>) straight to your email. The problem it solves: digital post is “push” in theory but pull in practice — you still have to log in with MitID, open an app, and click around to read a letter from SKAT or your kommune. Nemboks turns that into an email that lands in the inbox you already live in, attachments and all. Built for Danish SMBs where the same virksomhed</code> receives post for multiple companies or employees, and where accountants, bookkeepers, and property managers want digital post in the same place as every other email. Free beta; after beta, 39 kr/md on annual billing, 49 kr/md monthly.</p> The problem with Danish digital post</h2> Since 2014, communication from the Danish public sector is digital by default. That means if your kommune, SKAT, Udbetaling Danmark, or FerieKonto needs to reach you, they drop a letter into either mit.dk</a></strong> (the public portal) or e-Boks</a></strong> (historically the most used private portal, now share-gated with Digital Post).</p> In principle this is great: centralised, auditable, no paper. In practice it’s friction-heavy:</p> You need MitID to log in every time.</strong> Every tax letter, parking ticket, or vacation-pay notice is gated behind an MFA flow.</li> The apps notify you, but the notifications are thin.</strong> “You have new post” — not a subject line, not a sender, not enough to triage.</li> There’s no native forwarding.</strong> You can’t say “send everything from SKAT to my accountant at bogholder@firma.dk</code>.”</li> Businesses inherit the worst of both worlds.</strong> A CVR-registered company has its own mit.dk / e-Boks inbox. If the owner doesn’t check it, nobody does.</li> </ul> Email, by contrast, is the default inbox for small businesses: shared mailboxes, forwarding rules, archiving, filters, search. Nemboks bridges the two.</p> What Nemboks does</h2> Once set up, Nemboks authenticates against your mit.dk / e-Boks on your behalf, polls your inbox for new post, and forwards each new letter — as a real email with the PDF attached</strong> — to the address(es) you configure.</p> One email per letter.</strong> Subject = sender + subject. Body = plain-text preview. Attachment = the PDF.</li> Multiple companies per account.</strong> If you’re a revisor managing post for many CVRs, they all live under one Nemboks dashboard.</li> Multiple destinations per company.</strong> Forward everything from SKAT to the bogholder, everything else to the owner, for example.</li> Keeps the original in mit.dk / e-Boks.</strong> Nothing is deleted — Nemboks only reads.</li> Logs every forward.</strong> For audit and peace of mind.</li> </ul> The practical outcome: the accountant or bookkeeper who already lives in Outlook or Gmail stops context-switching into a portal once a week.</p> Who it’s for</h2> Nemboks is built for small- and medium-sized Danish businesses, especially:</p> Accountants and bookkeepers (revisorer</code>, bogholdere</code>).</strong> Clients give them Nemboks access once; from then on, every SKAT letter for every client turns into an email in the shared inbox.</li> Property managers (ejendomsadministratorer</code>).</strong> A single administrator might manage post for dozens of property-owning A/S and ApS.</li> Small-company owners.</strong> The enkeltmandsvirksomhed</code> or two-person ApS</code> whose owner would rather receive a letter from their municipality in the same place as their customer email.</li> </ul> The stack</h2> For the curious:</p> Rails 8</strong> on Ruby 3.4, using Hotwire (Turbo + Stimulus) and Tailwind for the dashboard.</li> PostgreSQL</strong> for persistence.</li> Auth0</a></strong> for authentication. Users sign in with Google, Microsoft, or email+password — no separate Nemboks password to forget.</li> Stripe</a></strong> for subscription management, including the hosted customer portal for self-service card updates and cancellations.</li> Postmark</a></strong> for transactional email — it’s the category leader for “email that must land in the inbox,” which is the entire point of a forwarding service.</li> Docker + Kamal</strong> for deployment. Zero-downtime rollouts on a small fleet; no Kubernetes to operate.</li> Cloudflare Pages</strong> for the static marketing site at nemboks.dk</a>.</li> </ul> The split — Rails app on Kamal, marketing site on Pages — is deliberate. The marketing site needs to be cheap, fast, and heavily cached; the Rails app needs a database and background jobs. Running them as two separate deployments keeps each one simple.</p> Pricing</h2> Free beta</strong> while the service is stabilising.</li> After beta: 39 kr/md</strong> on annual billing, 49 kr/md</strong> monthly — VAT not included. Flat per-company pricing; no per-letter fees.</li> 60-day free trial</strong> for new customers after beta ends.</li> </ul> FAQ</h2> Is Nemboks allowed to read my mit.dk / e-Boks?</h3> Yes — as the inbox owner, you authorise Nemboks to read on your behalf. Nemboks only reads; it does not delete, reply, or mark as read anything you didn’t configure.</p> Is this GDPR-compliant?</h3> Nemboks processes personal data on your behalf. As a customer you’re the data controller; Nemboks is the data processor, and there’s a standard databehandleraftale (DPA) to sign. All data is stored in the EU.</p> What happens to the original letter in mit.dk / e-Boks?</h3> It stays there. Nemboks is read-only.</p> Can I forward to multiple email addresses?</h3> Yes. Each company can have multiple forwarding destinations, and you can route different senders to different addresses (for example, everything from SKAT to the bookkeeper).</p> Does Nemboks work for private individuals?</h3> The current focus is Danish businesses (CVR). A private-individual plan may come later.</p> What if Nemboks goes down?</h3> Your post still arrives in mit.dk / e-Boks normally; Nemboks just won’t forward it until the service is back. Nothing is lost.</p> How do I cancel?</h3> Through the Stripe customer portal from inside the dashboard. No email, no phone call.</p> Why build it</h2> Digital post works. It’s secure, it’s auditable, and I’d rather trust a SKAT letter in mit.dk than a brown envelope. But the user interface is designed for a citizen reading a handful of letters a year, not for a business receiving dozens a week across several CVRs. Email solves the “dozens a week across several mailboxes” problem well — filters, rules, shared inboxes, search — so the smallest useful bridge is to get the letters out of the portal and into email, with the PDF attached, without anyone having to log in every time.</p> That’s Nemboks.</p> How to play Spotify on a Logitech Squeezebox in 2026 2026-04-22T00:00:00+00:00 TL;DR —</strong> The official Spotify plugin Logitech shipped with Squeezebox stopped working when Spotify retired the libspotify</code> API in 2022. In 2026 there are two working paths to get Spotify on a Squeezebox Classic, Touch, Boom, Radio, or Transporter</strong>: (1) Logitech Media Server + the Spotty plugin</a></strong> (now renamed Spotty</code> / sometimes Spotty-XL</code>), which uses the Spotify Web API plus librespot</code> under the hood, or (2) run spotifyd</a></strong> on the same host as LMS and point LMS at it as a generic audio source. Path 1 is the one you want unless you have a reason otherwise. This post walks through it.</p> What happened to the official plugin</h2> Squeezebox hardware went end-of-life at Logitech in 2012, but the software — Logitech Media Server (LMS)</strong>, the thing that actually streams music to the devices — has been community-maintained ever since. For years it shipped an official “Spotify” plugin that used Spotify’s now-discontinued libspotify</code> C library. When Spotify shut libspotify</code> down in 2022, that plugin stopped working, and Spotify has not shipped a replacement for third-party embedded devices.</p> The community filled the gap:</p> librespot</code></strong> — an open-source, Rust reimplementation of the Spotify Connect client protocol. It’s the basis of most modern third-party Spotify integrations.</li> Spotty plugin for LMS</strong> — wraps librespot</code> plus the Spotify Web API into an LMS plugin. Presents Spotify browsing, search, playlists, and playback inside the Squeezebox UI (both the device screen and the LMS web UI).</li> spotifyd</strong> — a standalone librespot</code>-based daemon that shows up as a Spotify Connect target. Your phone sees it as a speaker, you cast to it, and its audio output goes somewhere LMS can pick it up.</li> </ul> Path 1 (recommended): Spotty plugin on LMS</h2> This is the cleanest experience and the one that feels native on the Squeezebox. You search and browse from the Squeezebox remote or Touch screen, and it Just Works.</p> 1. Get LMS running</h3> If you’re not already running LMS, install it on whatever always-on machine you have — a Raspberry Pi, a NAS with a Docker runtime, or a small Linux box is ideal.</p> # Debian/Ubuntu — grab the latest .deb from the community repo wget https://downloads.slimdevices.com/LogitechMediaServer_v8.x/logitechmediaserver_<latest>_amd64.deb sudo apt install ./logitechmediaserver_<latest>_amd64.deb sudo systemctl enable --now logitechmediaserver </code></pre> Or via Docker — lmscommunity/logitechmediaserver</code> is a maintained image:</p> docker run -d --name lms \ --network host \ -v lms-config:/config \ -v /path/to/music:/music:ro \ lmscommunity/logitechmediaserver:latest </code></pre> Open http://<host>:9000/</code> and you should see the LMS web UI. Your Squeezebox devices on the same LAN should appear under Players</strong> automatically.</p> 2. Install Spotty</h3> In the LMS web UI: Settings → Plugins → Install new plugins</strong> and tick Spotty</strong> (author: Michael Herger). LMS downloads, installs, and restarts. On restart, you’ll have a Spotty</strong> entry in Settings → Advanced → Spotty</strong>.</p> 3. Authorise Spotty with your Spotify account</h3> In Settings → Advanced → Spotty</strong>, click Add account</strong>.</li> Spotty kicks off an OAuth flow via Spotify’s Web API — you log in once in a browser, approve the access, and the token is stored on the LMS server.</li> You need Spotify Premium</strong> for playback. (This is a Spotify-side limit: librespot</code> can authenticate with Free, but full-quality playback is Premium-only.)</li> </ul> 4. Play something</h3> On the Squeezebox device itself, Home → My Music → Spotty</strong> (or Home → Music Library → Spotty</strong>, depending on your LMS version) — browse playlists, search, start a track. On the Squeezebox Touch the on-screen artwork works. On the Classic the text UI works. On the Radio and Boom you drive it from the web UI or the Squeeze Commander</a> / Squeezer</a> apps.</p> Spotty also adds Squeezebox devices as Spotify Connect targets</strong> — meaning you can cast from your phone’s Spotify app to “Living Room Squeezebox” natively, the same way you’d cast to a Sonos or a Google Home.</p> Path 2: spotifyd as a Connect bridge</h2> Use this if Spotty won’t install (old LMS version, old Perl, weird OS) or you specifically want Spotify Connect behaviour without Spotty.</p> # Debian/Ubuntu sudo apt install spotifyd # or from source: cargo install spotifyd </code></pre> Configure /etc/spotifyd.conf</code> with your Spotify credentials, a backend (alsa</code>, pulseaudio</code>, or pipe</code>), and a device name. Start the daemon:</p> sudo systemctl enable --now spotifyd </code></pre> From your phone, cast to the spotifyd</code>-named device. Audio comes out of the host.</p> To get that audio into a Squeezebox, pipe spotifyd</code> to a FIFO and play the FIFO in LMS:</p> # spotifyd.conf backend = "pipe" device = "/var/run/spotifyd.pipe" </code></pre> Then in LMS: add the FIFO as a File system music folder</strong> and play it as a live stream.</p> This is clunkier and has ~1 s of latency vs. Spotty’s tight integration. Only use it if Path 1 doesn’t work for you.</p> Works on which Squeezebox?</h2> Spotty works on every Squeezebox device that talks to LMS:</p> Squeezebox Classic / Squeezebox v3</strong> (text display) — text-UI browsing and playback.</li> Squeezebox Touch</strong> — colour touchscreen, artwork, the whole UI.</li> Squeezebox Boom</strong> — text UI, same as Classic.</li> Squeezebox Radio</strong> — text UI, built-in speaker.</li> Squeezebox Duet / Controller</strong> — the controller’s UI works; playback goes to the Receiver.</li> Transporter</strong> — full support.</li> piCorePlayer / SqueezeLite on Pi</strong> — yes, these are software Squeezeboxes and Spotty streams to them fine.</li> </ul> As long as the device can connect to LMS, Spotty can feed it.</p> FAQ</h2> Do I need Spotify Premium?</h3> Yes, for playback. librespot</code> (and therefore Spotty) requires a Premium account to decode audio. Spotify Free accounts can authenticate but won’t play.</p> Does Spotify Connect “appear the Squeezebox as a speaker” work?</h3> Yes, with Spotty installed. Each Squeezebox player shows up in the Spotify app’s device picker as a Connect target.</p> Does hi-res / lossless work?</h3> Spotify itself doesn’t offer lossless on standard plans (Hi-Fi has been “coming soon” for years). Spotty plays whatever Spotify serves — Ogg Vorbis 320 kbps on Premium — and the Squeezebox handles it natively.</p> Gapless playback?</h3> Yes, Spotty supports gapless.</p> Does this break if Spotify’s Web API changes?</h3> Yes, occasionally — Spotify periodically rotates OAuth scopes or deprecates endpoints, and Spotty gets a patch release. Keep the plugin updated.</p> Can I run LMS on the same box as my NAS?</h3> Absolutely. LMS is lightweight (~200 MB RAM, minimal CPU except during library scans). Running it next to Samba or on a homelab SBC is the common setup.</p> Is this the same as “piCorePlayer”?</h3> piCorePlayer is a tiny Linux distribution that turns a Raspberry Pi into a Squeezebox-compatible player (via SqueezeLite). It does not replace LMS — you still need LMS as the server. piCorePlayer + LMS + Spotty is a very common 2026 stack for people whose original Squeezebox hardware finally died.</p> What to do if your Squeezebox won’t connect to LMS at all</h2> Two things to check first:</p> mDNS / multicast across your network.</strong> Modern Wi-Fi routers often block multicast between SSIDs or to wired hosts. Put the Squeezebox and LMS on the same subnet/VLAN with multicast allowed.</li> SlimProto port (3483/udp and 3483/tcp).</strong> That’s what the Squeezebox uses to find LMS. Not blocked by anything sensible, but worth checking if you run a strict firewall.</li> </ol> Beyond that, the Squeezebox community is still active — forums.slimdevices.com</a> and the LMS Community GitHub</a> are where problems get solved.</p> Squeezebox hardware was discontinued fifteen years ago. Thanks to LMS, Spotty, and librespot</code>, it still plays Spotify better than most “smart speakers” sold new in 2026.</p> elpriser.org — Danish hourly electricity prices 2026-04-20T00:00:00+00:00 TL;DR —</strong> elpriser.org</a> shows the real, all-in hourly price of electricity in Denmark</strong> — not just the spot price. It combines the Nord Pool spot price, your local grid tariff (netselskab</code>), Energinet’s system and transmission tariffs, the state electricity tax (elafgift</code>), and 25% VAT. Data comes from Energi Data Service</a> and updates daily after Nord Pool publishes the next 24 hours around 13:00. DK1 (Vestdanmark) and DK2 (Østdanmark). Danish-language, free, no login.</p> What does Danish electricity actually cost?</h2> The “spot price” you see on most energy dashboards is only one component. The price you actually pay per kWh is made up of six parts:</p> Spot price</strong> — set hourly on the Nord Pool wholesale market for the following day.</li> Grid tariff (nettarif)</strong> — paid to your local grid operator (netselskab</code>). Varies by company and by time-of-day (off-peak, shoulder, peak).</li> System tariff (systemtarif)</strong> — paid to Energinet, the Danish TSO.</li> Transmission tariff (transmissionstarif)</strong> — also paid to Energinet.</li> Electricity tax (elafgift)</strong> — a state tax on consumption.</li> VAT (moms)</strong> — 25% applied on top of everything else.</li> </ol> Most price sites show the first number. A few show one or two more. None that I could find showed all six, hour by hour, for both price zones, with the correct grid tariff automatically picked for the user’s netselskab</code>. That’s what elpriser.org does.</p> The two price zones: DK1 and DK2</h2> Denmark is split into two electricity price zones by geography — the Great Belt separates them — and they often have different prices at the same hour:</p> DK1 — Vestdanmark.</strong> Jylland and Fyn. More wind-dominated.</li> DK2 — Østdanmark.</strong> Sjælland, Lolland, Falster, Møn, Bornholm. More interconnected with Sweden (SE4) and Germany.</li> </ul> When the wind blows hard in Jylland, DK1 can be cheap while DK2 is pricey. When an interconnector is down, the gap widens further. elpriser.org shows both zones side by side.</p> Which netselskab are you on?</h2> You cannot choose your netselskab</code> — it depends on where you live — but the grid tariff they charge is a significant chunk of your bill, and it varies by 15–25 øre/kWh at peak</strong> between the cheapest and the most expensive, which works out to ~500–1,000 kr/year</strong> for a typical household.</p> Rough ranking of peak (spidslast) tariffs as of 2025:</p> Zone</th> Netselskab</th> Peak tariff (øre/kWh)</th></tr></thead> DK1</td> RAH Net</td> ~33</td></tr> DK1</td> Trefor</td> ~37</td></tr> DK1</td> N1</td> ~46</td></tr> DK2</td> Cerius</td> ~47</td></tr> DK2</td> Radius</td> ~65</td></tr> </tbody></table> Smaller operators (Konstant, Nord Energi, Vores Elnet, El-net Kongerslev, and others) each have their own tariffs. elpriser.org lets you pick yours; the all-in hourly price adjusts accordingly.</p> You can’t switch netselskab</code>, but you can</strong> shift consumption — laundry, dishwasher, EV charging, heat-pump heating — into the low-tariff hours. The hourly chart exists for exactly that.</p> Historical extremes</h2> Record high:</strong> 16.69 kr/kWh (spot price, excl. VAT) in DK2, at 19:00 on 5 September 2022, during the European energy crisis.</li> Record low:</strong> −2.76 kr/kWh in DK1, at 14:00 on 2 July 2023, when wind production overshot demand.</li> </ul> Negative prices are not a bug: when production is high and demand is low, producers pay consumers to absorb the surplus. Modern price-aware heat pumps and EV chargers can lean into this.</p> How elpriser.org is built</h2> Static HTML</strong>, regenerated once per day after Nord Pool’s next-day publication around 13:00 CET.</li> Data source</strong>: Energi Data Service</a>, the open-data service from Energinet. No API keys required.</li> Structured data</strong>: schema.org/WebApplication</code> and FAQPage</code> are emitted on every page so Google can surface the prices directly in search results and AI overviews.</li> Hosting</strong>: a small origin behind Cloudflare. Cacheable for the full day; purged on the daily rebuild.</li> Language</strong>: Danish only. The domain name should have been a hint.</li> </ul> The whole thing is a single-purpose tool: no tracking, no login, no newsletter popover, no “10 ways to save on your electricity bill” listicles.</p> FAQ</h2> How often does elpriser.org update?</h3> Once a day, after the Nord Pool day-ahead auction publishes next-day prices around 13:00 CET. Intraday adjustments are not shown; most consumers are billed against the day-ahead price anyway.</p> Is the price shown with or without VAT?</h3> With. The headline number on elpriser.org is the all-in price per kWh: spot + tariffs + tax + 25% VAT. You can toggle to see the breakdown.</p> Why are prices in DK1 and DK2 different?</h3> Denmark has two physically separated electricity areas joined by the Great Belt interconnector. When the interconnector is fully used or wind production differs sharply between east and west, the two zones clear at different Nord Pool prices.</p> Can I see the breakdown of each component?</h3> Yes. Every hourly cell can be expanded to show spot price, each tariff component, elafgift, and VAT.</p> Do I really pay negative prices when the wholesale price goes negative?</h3> It depends on your contract. Pure spot-price contracts pass the raw Nord Pool price through — tariffs and tax still apply, so the all-in price can go slightly negative or just very low. Fixed-price contracts don’t.</p> Why Danish only?</h3> The data, the regulatory rules, the netselskab</code> structure, and the target audience are all Danish. An English version would be translating context, not content.</p> Where does the data come from?</h3> Energi Data Service</a> (Nord Pool spot) and Energinet’s tariff data. Both are official public data sets from the Danish TSO.</p> Small, focused, no login, no tracking. The way consumer energy tools should look.</p> winniemethmann.com — from WordPress to Astro 2026-04-19T00:00:00+00:00 TL;DR —</strong> winniemethmann.com</a> is the portfolio of a Danish food photographer and recipe developer. It was a WordPress site for a decade. I rebuilt it on Astro</a>, using content collections</strong> (typed Markdown) instead of a CMS, Sharp + AVIF</strong> for the image pipeline, and Astro’s i18n routing</strong> (Danish default, English at /en/</code>). Build time: ~30 seconds. Output size: ~70% smaller. No more admin panel, no more plugin updates, no more bot-probed login endpoint.</p> Why move off WordPress</h2> For a portfolio that changes a few times a month, WordPress was doing too much work:</p> PHP runtime and MySQL</strong> for a site that is functionally static.</li> Dozens of plugins</strong> for image galleries, contact forms, SEO, caching — each with its own update cadence and security disclosures.</li> A half-forked theme</strong> that had accumulated patches nobody remembered why.</li> An admin login endpoint</strong> that was probed several thousand times a day by bots.</li> Regular caching headaches</strong> every time the CDN and the plugins disagreed.</li> </ul> Concretely, dropping WordPress meant:</p> No admin panel to keep patched.</strong> WordPress core releases, plugin updates, theme updates — gone.</li> No database.</strong> Content lives as Markdown in the repo.</li> No login surface for bots to probe.</strong> There’s no /wp-admin/</code> anymore.</li> ~10× faster page loads</strong> with no caching layer required.</li> ~70% smaller total build size</strong>, swapping hand-exported JPEGs for AVIF at sensible srcset</code> breakpoints.</li> </ul> The tradeoff is that non-technical editing goes away. In practice that did not matter: the site owner was happier editing Markdown than fighting the WordPress block editor.</p> Why Astro</h2> I considered Hugo, 11ty, Next.js static export, and SvelteKit. Astro won on three specific points:</p> Content collections.</strong> A typed, schema-checked way to describe a portfolio project as a directory of photos plus some front-matter. Build fails loudly if anything is malformed. No CMS required.</li> The <Image></code> component.</strong> Astro’s built-in image pipeline handles AVIF + JPEG fallback + srcset</code> + width</code>/height</code> attributes with a one-liner. Sharp is the engine under the hood.</li> Islands architecture, not relevant here.</strong> The site has no interactive components, so it ships basically zero JavaScript.</li> </ol> Content collections, not a CMS</h2> Each portfolio project is a directory under src/content/portfolio/</code> with a front-matter schema:</p> src/content/portfolio/ ├── 2024-cookbook-editorial/ │ ├── index.mdx │ ├── cover.jpg │ ├── 01.jpg, 02.jpg, … └── 2023-spring-catalogue/ ├── index.mdx ├── cover.jpg └── 01.jpg … </code></pre> index.mdx</code> front-matter declares the project title, category, year, and cover image. Astro enforces the schema at build time via defineCollection</code></a> with a Zod schema. If a project is missing a cover image or has a bad category, the build fails.</p> Categories used: food photography, recipe development, interior & garden styling, editorial, cookbooks, and fashion</strong>. Adding a new project is mkdir</code> + cp *.jpg</code> + a short YAML front-matter block. No admin UI, no database migration, no cache to invalidate.</p> Image pipeline: Sharp + AVIF</h2> Food photography lives or dies on image quality. Astro’s <Image></code> component, powered by Sharp</a>, generates:</p> AVIF</strong> as the primary format. Roughly all modern browsers support it now (see caniuse</a>).</li> JPEG</strong> fallback with matching srcset</code> breakpoints (320, 640, 960, 1280, 1920 px).</li> Explicit width</code> and height</code> attributes, so there is zero cumulative layout shift while images load.</li> loading="lazy"</code> for below-the-fold images and fetchpriority="high"</code> for the hero.</li> </ul> Numbers</strong>: a typical portfolio page went from ~4.8 MB of hand-exported JPEGs to ~1.4 MB of AVIF — about a 70% reduction — with no visible quality loss at typical display sizes.</p> i18n — Danish default, English at /en/</h2> Astro’s i18n routing sits in astro.config.mjs</code>:</p> export default defineConfig({ i18n: { defaultLocale: "da", locales: ["da", "en"], routing: { prefixDefaultLocale: false }, }, }); </code></pre> That gives:</p> /</code> for Danish (the default, no prefix).</li> /en/</code> for English.</li> Each content entry declares its language via its collection and filename.</li> <link rel="alternate" hreflang></code> and the sitemap are generated from the same source.</li> </ul> Posts and portfolio entries that lack a translation simply don’t appear in the other locale’s routing — they don’t 404 to a wrong-language page.</p> Deployment and build</h2> Output</strong>: fully static, deployed as plain files behind Cloudflare.</li> Build time</strong>: ~30 seconds on a cold cache, ~6 seconds incrementally.</li> No server, no database, no runtime cost.</strong></li> </ul> Measurable outcomes</h2> Metric</th> WordPress (before)</th> Astro (after)</th></tr></thead> Build / deploy time</td> n/a (instant publish)</td> ~30s cold, ~6s warm</td></tr> Typical page size (portfolio page)</td> ~4.8 MB</td> ~1.4 MB</td></tr> Largest Contentful Paint</td> ~2.8 s</td> ~0.9 s</td></tr> Time to Interactive</td> ~3.5 s</td> ~1.1 s</td></tr> JS shipped</td> ~220 KB</td> ~0 KB</td></tr> Plugins to keep patched</td> 14</td> 0</td></tr> </tbody></table> FAQ</h2> Can a non-technical owner still edit the site?</h3> Yes, for copy. Editing Markdown in a GitHub web editor is, in practice, easier than the WordPress block editor. For new portfolio projects, the workflow is: drag images into a folder, write a short front-matter block, commit. If that’s too technical, a one-page admin (Decap CMS / Sveltia CMS / Keystatic) can be bolted on.</p> What about SEO after the migration?</h3> URLs were kept as-is wherever possible. Missing old paths redirect via Cloudflare rules. The sitemap is regenerated on every build, and structured data (Person</code>, ImageGallery</code>, Article</code>) is emitted per page.</p> Why Astro and not Hugo?</h3> Hugo is faster and simpler for pure blogging, but Astro’s typed content collections and first-class <Image></code> component won this case. For x2q.net</a> itself, I later went with Zola — for a portfolio with a heavy image pipeline, Astro remained the better fit.</p> How do images stay organised?</h3> Each portfolio project owns its own folder. The Git repo is the CMS. git log</code> tells you when an image was added and why.</p> Is the build deterministic?</h3> Yes. Given the same inputs, the output is byte-for-byte identical. Sharp is pinned in package.json</code>; so is Astro. CI runs on Node LTS.</p> If you’re on a WordPress site that’s doing far less than its infrastructure suggests, Astro is worth the afternoon it takes to try.</p> apextowww.com — a free apex-to-www redirect service 2026-04-18T00:00:00+00:00 TL;DR —</strong> DNS does not allow CNAME</code> records at the zone apex (RFC 1034 §3.6.2</a>). That’s why hosts like Netlify, Vercel, Cloudflare Pages, Firebase, and Heroku ask you to configure www.example.com</code> with a CNAME</code> and leave example.com</code> (the apex) as a problem. apextowww.com</a> solves it: point two A</code> records and two AAAA</code> records at the service, and it issues a Let’s Encrypt certificate for your apex and 301</code>-redirects every request to https://www.yourdomain.tld/</code>, preserving path and query string. Free, no signup, no account.</p> Why you can’t put a CNAME on the apex</h2> The DNS spec is unambiguous: a zone apex (the “bare” domain like example.com</code>) must carry an SOA</code> record and usually NS</code> records. CNAME</code> is defined as an alias that must be the only record at a name, and it is forbidden to coexist with the SOA</code> and NS</code> records that the apex is required to have. That’s why you can CNAME www.example.com → mysite.netlify.app</code> but you cannot</strong> CNAME example.com → mysite.netlify.app</code>.</p> Workarounds exist, and all of them are a little awkward:</p> ALIAS / ANAME records.</strong> Proprietary to each DNS provider (Cloudflare, Route 53, DNSimple, NS1). They work by resolving the target behind the scenes and returning an A</code>/AAAA</code>. Fine if your DNS provider supports it; useless if it doesn’t.</li> Flattening at the provider level.</strong> Cloudflare’s “CNAME flattening” is this, done automatically for you.</li> Your own always-on VPS doing 301 → www</code>.</strong> This is what I was doing for multiple domains, and it’s both over-engineered and a small maintenance tax.</li> </ul> apextowww is the fourth option: somebody else’s always-on redirector, managed for you.</p> What apextowww does</h2> Exactly one thing: a 301 Moved Permanently</code> from https://yourdomain.tld/anything?x=y</code> to https://www.yourdomain.tld/anything?x=y</code>.</p> TLS</strong> is issued automatically on first request via the Let’s Encrypt HTTP-01 challenge. No ACME client to run yourself.</li> IPv4 + IPv6</strong> on dual-stack by design. Both apex records are required.</li> HTTP/1.1, HTTP/2, and HTTP/3</strong> are all served. The redirect itself is trivially small, so protocol version matters less, but it helps the first-paint story when the redirect is on the critical path.</li> Path and query string</strong> are preserved, so deep links keep working.</li> No signup, no login, no account.</strong> If your DNS is pointed correctly, it just works.</li> </ul> How to set it up</h2> Go to apextowww.com</a> and copy the current IP addresses (two IPv4, two IPv6).</li> In your DNS provider, set A</code> records on your apex pointing at the two IPv4 addresses. Remove any existing A</code> record at the apex.</li> Set AAAA</code> records on your apex pointing at the two IPv6 addresses.</li> Make sure www.yourdomain.tld</code> still points at your real host (CNAME to Netlify/Vercel/Pages/etc).</li> Wait for DNS to propagate. Visit http://yourdomain.tld/</code> — it should 301 to https://www.yourdomain.tld/</code>.</li> </ol> The apextowww site has per-platform walkthroughs at /netlify-apex-domain-redirect/</code>, /vercel-apex-domain-redirect/</code>, /cloudflare-pages-apex-redirect/</code>, /firebase-hosting-apex-redirect/</code>, and /heroku-apex-domain-redirect/</code>.</p> Stack</h2> Hetzner ARM64</strong> servers, for cheap, low-power compute. ARM64 is ~30% cheaper per vCPU at Hetzner than x86 and runs the redirector fine.</li> Caddy-style automatic TLS</strong> with Let’s Encrypt</strong> HTTP-01 challenges.</li> Dual-stack IPv4 + IPv6</strong>.</li> HTTP/1.1, HTTP/2, HTTP/3</strong>.</li> Public static marketing site</strong> on Cloudflare Pages, with per-platform guides in separate URL paths so they each rank independently on Google for “netlify apex redirect”, “vercel apex domain”, etc.</li> </ul> FAQ</h2> Can I use apextowww with Cloudflare DNS?</h3> Yes, but you’ll want Cloudflare’s proxy (orange cloud) off</strong> for the apex A</code>/AAAA</code> records. If the proxy is on, Cloudflare intercepts the request and Let’s Encrypt’s HTTP-01 challenge won’t reach apextowww. Once the certificate is issued and renewed, you don’t need to toggle anything manually; just keep it off.</p> Does apextowww support wildcards or redirecting subdomains other than www?</h3> No. The service only redirects the apex to www.</code>. Everything else stays on your real host.</p> What happens if the apextowww IPs change?</h3> You’ll need to update your DNS A</code>/AAAA</code> records. The operator publishes current IPs on the homepage and gives advance notice for changes. For a personal domain this is fine; for anything mission-critical, run your own redirector.</p> Is there a rate limit?</h3> There’s no published hard limit, but this is a free community service. If you’re serving millions of apex redirects a day, self-host.</p> Why not just use Cloudflare’s free plan?</h3> Cloudflare’s CNAME flattening at the apex is a perfectly reasonable alternative if your whole DNS is on Cloudflare. apextowww is useful when your DNS isn’t on Cloudflare, or when you want a host-agnostic redirector that works identically across domains.</p> Is it really free?</h3> Yes. The marginal cost per redirect on ARM64 is negligible. No ads, no tracking beyond basic logs, no upsell.</p> Why it exists</h2> Hosting platforms optimise for their own onboarding, not for the DNS truisms that trip up every new user. Sending people to a stranger’s VPS felt worse than running one myself. Now my own apex domains (including x2q.net</a>) point at apextowww, which means I could tear down the last little redirector VPS I still had running for historical reasons.</p> It’s the kind of project that isn’t interesting until you need it, and then it’s the only thing you need.</p> Print to PDF on Linux — set up a system-wide PDF printer with cups-pdf (2026) 2013-01-30T00:00:00+00:00 TL;DR —</strong> install cups-pdf</code></strong>, restart CUPS, and you get a virtual “PDF” printer</strong> that any application can print to. The files land in ~/PDF</code></strong> by default. On Debian/Ubuntu that’s sudo apt install printer-driver-cups-pdf && sudo systemctl restart cups</code>.</p> This post first went up here in 2013 as a two-line note — apt-get install cups-pdf</code>, restart CUPS, done. The tool is still the right answer in 2026, so here is the current, fuller version.</p> </blockquote> Do you even need this?</h2> Most Linux desktop apps already print to PDF on their own. GTK and KDE print dialogs (so Firefox, Chrome, LibreOffice, GNOME apps, etc.) have a built-in “Print to File → PDF”</strong> option. If that covers you, you’re done.</p> cups-pdf</code> earns its place when you want a real, system-wide printer queue</strong> rather than a per-app export:</p> Available to every</em> application, including ones that have no PDF export of their own.</li> Usable from the command line</strong> and scripts.</li> Shareable over the network</strong> from a headless server, so other machines can “print to PDF” to a central spool.</li> </ul> Install</h2> cups-pdf</code> is packaged on every mainstream distro:</p> # Debian / Ubuntu / Mint / Kali sudo apt install printer-driver-cups-pdf # older name: cups-pdf # Fedora sudo dnf install cups-pdf # Arch / Manjaro sudo pacman -S cups-pdf </code></pre> Then (re)start the CUPS daemon so it picks up the new backend:</p> sudo systemctl restart cups # systemd sudo service cups restart # older sysvinit </code></pre> The package’s post-install step normally registers the queue for you. That’s it — you can print to PDF now.</p> Verify the printer exists</h2> $ lpstat -p -d printer PDF is idle. enabled since ... </code></pre> You’re looking for a queue named PDF</code></strong> (sometimes Virtual_PDF_Printer</code>). If it isn’t there, add it by hand — first find the exact model string CUPS registered:</p> $ lpinfo -m | grep -i pdf CUPS-PDF_opt.ppd Generic CUPS-PDF Printer (w/ options) </code></pre> …then create the queue with that model:</p> sudo lpadmin -p PDF -E -v cups-pdf:/ -m CUPS-PDF_opt.ppd </code></pre> Or do it in the GUI: Settings → Printers → Add</strong>, pick the Generic CUPS-PDF</em> printer.</p> Where the files go</h2> By default, output lands in ~/PDF/</code></strong> for the user who submitted the job. The location is set in /etc/cups/cups-pdf.conf</code>:</p> $ grep -i '^Out\|^AnonDirName' /etc/cups/cups-pdf.conf Out ${HOME}/PDF AnonDirName /var/spool/cups-pdf/ANONYMOUS </code></pre> Change the Out</code> directive and sudo systemctl restart cups</code> to send PDFs somewhere else. Jobs that arrive without a resolvable home directory (e.g. from a shared network queue) collect under /var/spool/cups-pdf/</code>.</p> Print from the command line</h2> Once the queue exists, it’s a normal CUPS printer:</p> lp -d PDF report.txt # any printable file lpr -P PDF document.ps </code></pre> The resulting PDF shows up in ~/PDF</code>. Set a default page size if the wrong one keeps appearing:</p> lpoptions -p PDF -o media=A4 # or media=Letter </code></pre> Headless / network “print to PDF”</h2> On a server with no desktop you can still run the whole thing: install cups</code> + cups-pdf</code>, enable the daemon, and share the queue.</p> sudo systemctl enable --now cups sudo lpadmin -p PDF -o printer-is-shared=true </code></pre> With CUPS configured to listen on the network (Listen</code>/Allow</code> in /etc/cups/cupsd.conf</code>), other machines can add this IPP printer and “print to PDF” remotely — the PDFs collect in the spool on the server. Handy for appliances and apps that only know how to talk to a network printer.</p> Gotchas</h2> Nothing appears in ~/PDF</h3> Check the job actually completed and read the CUPS log:</p> lpstat -W completed -o sudo tail -n 50 /var/log/cups/error_log </code></pre> Then confirm the Out</code> path in /etc/cups/cups-pdf.conf</code> is what you expect.</p> Permission denied writing the PDF</h3> ~/PDF</code> has to be writable by the CUPS spool. If you print across a shared queue as another user, output lands under /var/spool/cups-pdf/<user></code> or …/ANONYMOUS</code> instead of your home directory.</p> Fedora: SELinux blocks the write</h3> If a job silently disappears on Fedora, check for an SELinux denial (sudo ausearch -m avc -ts recent</code>) — the cups-pdf</code> backend writing to a non-default directory is the usual trigger.</p> FAQ</h2> Do I need cups-pdf if I use GNOME, Firefox, or Chrome?</h3> Probably not — those export PDF directly from their print dialog. Reach for cups-pdf</code> when you want one system-wide queue, command-line/scripted output, or a network print-to-PDF server.</p> How do I print to PDF on Windows or macOS?</h3> You don’t need cups-pdf</code>. Windows has a built-in “Microsoft Print to PDF”</strong> printer; macOS has a PDF</strong> dropdown in every print dialog. This post is Linux-only — and, as the 2013 original put it, setting this up on Linux is the easy case.</p> What’s the difference between this and “Print to File”?</h3> “Print to File → PDF” in an app’s dialog is per-application and exports a single file. cups-pdf</code> is a genuine CUPS print queue: shared across apps, scriptable, and shareable over the network.</p> Which package name — cups-pdf or printer-driver-cups-pdf?</h3> On current Debian/Ubuntu the package is printer-driver-cups-pdf</code>; cups-pdf</code> is kept as a transitional name and still works. Fedora and Arch call it cups-pdf</code>.</p> Summary</h2> sudo apt install printer-driver-cups-pdf</code> (or your distro’s equivalent), then sudo systemctl restart cups</code>.</li> A virtual PDF</strong> printer appears; verify with lpstat -p -d</code>.</li> Output defaults to ~/PDF</code></strong>, configurable via Out</code> in /etc/cups/cups-pdf.conf</code>.</li> Print from any app’s dialog, from the CLI with lp -d PDF file</code>, or over the network from a headless box.</li> </ul> Create a real multi-resolution favicon.ico (2026) 2013-01-13T00:00:00+00:00 TL;DR —</strong> a .ico</code> file can contain multiple</em> image sizes in one file. Render 16/32/48px PNGs from a high-res source and combine them: magick 16.png 32.png 48.png favicon.ico</code>. Then add a modern favicon.svg</code> and an apple-touch-icon.png</code> for everything else.</p> This first went up here in 2013 with GIMP-by-hand instructions. The multi-resolution .ico</code> trick still matters, but in 2026 the command-line route is faster and an SVG favicon</strong> does most of the heavy lifting — both are below.</p> </blockquote> Why multi-resolution</h2> Most favicons are exported at a single 16×16 resolution. That looks fine in a tab but pixelated when a browser scales it up — bookmarks bars, the address bar on hi-DPI screens, pinned tabs, OS shortcuts. Browsers ask for different sizes (16, 32, 48…), and the .ico</code> container can hold all of them in one file, so the browser picks the best fit.</p> The command-line way (ImageMagick)</h2> Start from a square source image, at least 256×256</strong>. Rasterize the sizes you want, then pack them into one .ico</code>.</p> From a PNG source:</p> magick source.png -resize 16x16 /tmp/16.png magick source.png -resize 32x32 /tmp/32.png magick source.png -resize 48x48 /tmp/48.png magick /tmp/16.png /tmp/32.png /tmp/48.png favicon.ico </code></pre> ImageMagick’s own SVG rasterizer is flaky — if your source is an SVG, render the PNGs with rsvg-convert</code> first, then combine:</p> rsvg-convert -w 16 -h 16 logo.svg -o /tmp/16.png rsvg-convert -w 32 -h 32 logo.svg -o /tmp/32.png rsvg-convert -w 48 -h 48 logo.svg -o /tmp/48.png magick /tmp/16.png /tmp/32.png /tmp/48.png favicon.ico </code></pre> Verify the .ico</code> really contains all three sizes:</p> magick identify favicon.ico favicon.ico[0] ICO 16x16 ... favicon.ico[1] ICO 32x32 ... favicon.ico[2] ICO 48x48 ... </code></pre> The GIMP way (no ImageMagick)</h2> Open your square, high-res source in GIMP.</li> Image → Canvas Size</strong> to make it perfectly square if it isn’t.</li> Image → Scale Image</strong> to 48×48, then Layer → Duplicate</strong> and scale copies to 32×32 and 16×16, so you have one layer per size.</li> File → Export As → favicon.ico</code></strong>. GIMP writes each layer as a resolution inside the single .ico</code>.</li> </ol> The modern half: SVG + apple-touch-icon</h2> In 2026 the .ico</code> is the legacy fallback. Modern browsers prefer a crisp, scalable SVG favicon</strong>, and iOS wants a PNG apple-touch-icon</strong>. Ship all three:</p> rsvg-convert -w 180 -h 180 -b "#fff" logo.svg -o apple-touch-icon.png </code></pre> Then in your <head></code>:</p> <link rel="icon" href="/favicon.ico" sizes="32x32"> <link rel="icon" type="image/svg+xml" href="/favicon.svg"> <link rel="apple-touch-icon" href="/apple-touch-icon.png"> </code></pre> The sizes="32x32"</code> hint on the .ico</code> tells modern browsers “there’s something better here” so they reach for the SVG, while older ones fall back to the multi-resolution .ico</code>.</p> FAQ</h2> Do I still need favicon.ico if I have an SVG?</h3> Yes, as a fallback. Older browsers and a lot of link-preview/scraper bots only look for /favicon.ico</code> at the site root, so keep it there.</p> What sizes should the .ico contain?</h3> 16, 32, and 48 cover essentially everything in practice. You can</em> add 64 and 128, but they mostly just inflate the file — the SVG handles large sizes better.</p> Why does my favicon not update?</h3> Browsers cache favicons aggressively. Hard-refresh, or append a one-off query string while testing (/favicon.ico?v=2</code>).</p> Summary</h2> A .ico</code> holds multiple sizes; bake in 16/32/48 with magick 16.png 32.png 48.png favicon.ico</code>.</li> Rasterize SVG sources with rsvg-convert</code> first (ImageMagick’s SVG support is unreliable).</li> Pair the .ico</code> with a modern favicon.svg</code> + apple-touch-icon.png</code> and three <link></code> tags.</li> </ul> Pretty-print XML on the command line with xmllint (2026) 2012-11-20T00:00:00+00:00 TL;DR —</strong> xmllint --format file.xml</code> pretty-prints XML. Read from a pipe with -</code>, control indentation with XMLLINT_INDENT</code>, and write back with --output</code>. It ships with libxml2</strong>, so it’s almost certainly already installed.</p> This one first went up here in 2012 — I was poking at a Visa 3-D Secure</strong> test directory that answered in single-line XML and needed it readable. The tool hasn’t changed; the flags below are the current, double-dash forms.</p> </blockquote> The problem</h2> API responses come back as one unreadable line. Here’s the kind of thing a payment directory server hands you:</p> <?xml version="1.0" encoding="UTF-8"?><ThreeDSecure><Message><VERes><version>1.0.2</version><CH><enrolled>Y</enrolled></CH><url>https://acs.example/PIT/ACS</url></VERes></Message></ThreeDSecure> </code></pre> Format a file</h2> xmllint --format response.xml </code></pre> That writes the indented version to stdout. To overwrite (or write a new file):</p> xmllint --format response.xml --output response.pretty.xml </code></pre> Format a stream (the useful one)</h2> Pass -</code> as the filename to read stdin, so you can pretty-print straight from curl</code>:</p> curl -s https://api.example/thing | xmllint --format - </code></pre> <?xml version="1.0" encoding="UTF-8"?> <ThreeDSecure> <Message> <VERes> <version>1.0.2</version> <CH> <enrolled>Y</enrolled> </CH> <url>https://acs.example/PIT/ACS</url> </VERes> </Message> </ThreeDSecure> </code></pre> Control the indentation</h2> By default xmllint</code> indents with two spaces. Override it with the XMLLINT_INDENT</code> environment variable — set it to spaces or a tab:</p> XMLLINT_INDENT=" " xmllint --format response.xml # 4 spaces XMLLINT_INDENT=$'\t' xmllint --format response.xml # tabs </code></pre> Recover broken XML</h2> If the document is slightly malformed (a stray entity, a missing close tag from a truncated download), add --recover</code> to format what it can instead of bailing:</p> xmllint --recover --format broken.xml </code></pre> While you’re there: validate</h2> xmllint</code> isn’t just a formatter. Check well-formedness (exit code 0 = OK), or validate against a schema:</p> xmllint --noout response.xml # well-formed? xmllint --noout --schema schema.xsd response.xml # valid against XSD? xmllint --noout --dtdvalid doc.dtd response.xml # valid against DTD? </code></pre> Install (if it’s somehow missing)</h2> sudo apt install libxml2-utils # Debian / Ubuntu sudo dnf install libxml2 # Fedora brew install libxml2 # macOS (then use the keg's bin) </code></pre> FAQ</h2> How do I minify XML instead of pretty-printing it?</h3> Use --noblanks</code>: xmllint --noblanks file.xml</code> strips the insignificant whitespace.</p> Can I extract a single value instead of formatting the whole thing?</h3> Yes — xmllint --xpath '//url/text()' response.xml</code> pulls out a node with XPath. Handy for scripting against XML APIs.</p> What about JSON?</h3> xmllint</code> is XML-only. For JSON, jq .</code> is the equivalent (“jq</code> for XML” is roughly xmllint --format</code>).</p> Summary</h2> xmllint --format file.xml</code> — pretty-print a file.</li> … | xmllint --format -</code> — pretty-print a stream.</li> XMLLINT_INDENT</code> — set the indent.</li> --recover</code>, --noout --schema</code>, --xpath</code> — fix, validate, and query.</li> </ul> Mount a BIN/CUE disc image on Linux (2026) 2012-10-16T00:00:00+00:00 TL;DR —</strong> you can’t mount</code> a BIN/CUE pair straight away. Convert it: bchunk image.bin image.cue out</code> produces an ISO you can loop-mount. For discs with audio tracks or copy protection, use cdemu</strong> to emulate a drive instead.</p> A 2012 note, still accurate. BIN/CUE images are everywhere (old game/VCD rips), and the loop-mount confusion is perennial. See also the companion post on bchunk itself</a> if you just need the conversion.</p> </blockquote> Why you can’t just mount it</h2> A .bin</code> is a raw CD sector dump and the .cue</code> is a text sheet describing its track layout. The kernel’s loopback mounter understands filesystem images (ISO9660, etc.), not raw sector dumps with a separate cue sheet — so mount image.bin</code> fails. You bridge the gap one of two ways.</p> Option 1 — convert to ISO with bchunk (data discs)</h2> bchunk</code> (binchunker) converts a .bin</code>/.cue</code> set into .iso</code> (data) and .cdr</code> (audio) tracks.</p> sudo apt install bchunk # Debian / Ubuntu sudo dnf install bchunk # Fedora </code></pre> Convert — the last argument is the output basename</em>, so this writes out01.iso</code>:</p> bchunk image.bin image.cue out </code></pre> Then loop-mount the ISO:</p> sudo mount -o loop,ro -t iso9660 out01.iso /mnt ls /mnt sudo umount /mnt </code></pre> This is the right tool when the image is a single data track — most software/VCD rips.</p> Option 2 — emulate a drive with cdemu (audio / mixed-mode)</h2> If the disc has audio tracks, multiple sessions, or anything bchunk’s flat conversion would mangle, emulate a real optical drive with cdemu</strong>. It loads the .cue</code> directly and exposes a virtual /dev/sr</code> device the desktop auto-mounts.</p> sudo apt install cdemu-client gcdemu # Debian / Ubuntu (universe) cdemu load 0 image.cue # load into virtual drive 0 cdemu status # the virtual disc now appears like a real one; eject with: cdemu unload 0 </code></pre> cdemu handles audio and mixed-mode discs that a straight ISO conversion can’t represent.</p> Option 3 — just extract the files</h2> If you don’t need a mounted volume, 7-Zip</strong> can list and extract straight from many BIN/CUE data images:</p> 7z l image.cue # list contents 7z x image.cue # extract here </code></pre> FAQ</h2> bchunk wrote a .iso and several .cdr files — what are those?</h3> The .cdr</code> files are the raw audio tracks. Convert one to WAV with sox track.cdr track.wav</code> (it’s headerless CD-DA), or ignore them if you only wanted the data track.</p> mount says “wrong fs type” on the converted ISO</h3> The image may not be ISO9660 (e.g. a UDF or game-console format). Drop the -t iso9660</code> and let the kernel autodetect: sudo mount -o loop,ro out01.iso /mnt</code>. Console images often need a dedicated emulator instead.</p> Can I do this on macOS?</h3> bchunk</code> is in Homebrew (brew install bchunk</code>); convert to ISO, then hdiutil attach out01.iso</code>.</p> Summary</h2> BIN/CUE won’t loop-mount directly.</li> Data disc → bchunk image.bin image.cue out</code> then mount -o loop out01.iso /mnt</code>.</li> Audio/mixed-mode → load the .cue</code> in cdemu</strong>.</li> Just need the files → 7z x image.cue</code>.</li> </ul> sudo without a password on Ubuntu/Debian — safely (2026) 2012-10-11T00:00:00+00:00 TL;DR —</strong> don’t edit /etc/sudoers</code> directly. Create a validated drop-in: sudo visudo -f /etc/sudoers.d/nopasswd</code> and add youruser ALL=(ALL) NOPASSWD: ALL</code>. Better yet, scope it to the specific commands</em> you actually need to run unattended.</p> A 2012 note, refreshed. The mechanism is unchanged, but in 2026 the right move is a drop-in file under /etc/sudoers.d/</code> (not editing the main file), and scoping the rule rather than handing out blanket root.</p> </blockquote> Always use visudo</h2> sudo</code> reads /etc/sudoers</code> and every file in /etc/sudoers.d/</code>. visudo</code> syntax-checks before saving</strong> — a typo in sudoers</code> can lock you out of sudo</code> entirely, so never edit these files with a plain editor.</p> Edit a dedicated drop-in (keeps your change out of the distro-managed main file):</p> sudo visudo -f /etc/sudoers.d/nopasswd </code></pre> Single user</h2> Add this line (swap in your username):</p> alice ALL=(ALL) NOPASSWD: ALL </code></pre> A group instead</h2> On Ubuntu, members of the sudo</code> group get admin rights (it’s wheel</code> on Fedora/RHEL). Make the whole group passwordless:</p> %sudo ALL=(ALL) NOPASSWD: ALL </code></pre> The version you should actually use: scope it</h2> Blanket NOPASSWD: ALL</code> means anything that can run as that user can now become root with no further check — a real escalation risk. For automation, grant only the commands the job needs:</p> # deploy user may restart one service and nothing else, no password deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/systemctl status myapp </code></pre> This is the difference between “convenient” and “convenient and</em> defensible”.</p> Apply and test</h2> Files in /etc/sudoers.d/</code> are picked up immediately — no reload needed. Validate the whole config and test in a way that won’t strand you:</p> sudo visudo -c # syntax-check every sudoers file sudo -k # clear the cached credential sudo -n true && echo "passwordless works" </code></pre> Keep your current root shell open until you’ve confirmed it works in a second</em> terminal.</p> Gotchas</h2> Filenames matter.</strong> sudo</code> ignores files in /etc/sudoers.d/</code> with a .</code> or ~</code> in the name (so nopasswd.conf</code> is silently skipped). Use a plain name like nopasswd</code>.</li> Permissions matter.</strong> The file must be 0440</code> and owned by root; visudo -f</code> sets this for you. A wrong mode makes sudo refuse to start.</li> Order matters.</strong> Later rules win. A broad NOPASSWD: ALL</code> after a narrow rule re-opens everything.</li> </ul> FAQ</h2> Is passwordless sudo a security risk?</h3> Blanket NOPASSWD: ALL</code> removes the last speed-bump between a compromised user account and root. Fine on a throwaway lab VM; scope it (or skip it) on anything that matters. Command-scoped rules are the compromise.</p> How do I require a password again?</h3> Delete the drop-in (sudo rm /etc/sudoers.d/nopasswd</code>) or remove the NOPASSWD:</code> keyword from the line.</p> Why does it still ask for a password?</h3> Another rule later in the chain overrides yours, the filename contains a .</code>/~</code> (so it’s ignored), or you edited /etc/sudoers</code> but a drop-in re-requires it. Run sudo visudo -c</code> and check /etc/sudoers.d/</code> for conflicting files.</p> Summary</h2> Edit a drop-in with sudo visudo -f /etc/sudoers.d/nopasswd</code> — never the main file by hand.</li> user ALL=(ALL) NOPASSWD: ALL</code> for a user, %sudo …</code> for a group.</li> Scope to specific commands for anything beyond a lab box. Validate with visudo -c</code>.</li> </ul> View the contents of a CSR with OpenSSL (2026) 2010-07-04T00:00:00+00:00 TL;DR —</strong> openssl req -in host.csr -noout -text -verify</code> decodes a certificate signing request into human-readable form and checks its signature. Use it to confirm the CN, the SANs, and the key before you hand the CSR to a CA.</p> This is one of the oldest notes on this blog (2010). OpenSSL’s CLI is famously sprawling, and “how do I just read</em> a CSR” is a question that never goes away — so here’s the refreshed version.</p> </blockquote> What a CSR is</h2> A Certificate Signing Request (CSR)</strong> is what you send to a Certificate Authority (CA) to be signed. It bundles your public key plus the identity you’re requesting (the subject: common name, organisation, and — the part that actually matters now — the Subject Alternative Names</strong>), all signed by your private key. The CA signs it and hands back a certificate.</p> Read it</h2> openssl req -in host.csr -noout -text -verify </code></pre> -in host.csr</code></strong> — the request file.</li> -noout</code></strong> — don’t re-print the encoded CSR, just the decoded info.</li> -text</code></strong> — human-readable output.</li> -verify</code></strong> — check the CSR’s self-signature (catches a corrupted or tampered request).</li> </ul> You’ll get something like:</p> Certificate Request: Data: Version: 1 (0x0) Subject: C=DK, ST=Capital, L=Copenhagen, O=Example ApS, CN=example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Requested Extensions: X509v3 Subject Alternative Name: DNS:example.com, DNS:www.example.com Signature Algorithm: sha256WithRSAEncryption </code></pre> Check three things before sending it off: the CN/subject</strong> is right, the SANs</strong> list every hostname the cert must cover (modern browsers ignore the CN and only trust SANs), and the key size/algorithm</strong> meets the CA’s minimum (2048-bit RSA or an EC key).</p> Pull out just one field</h2> When you only need the subject or the SANs (e.g. in a script):</p> openssl req -in host.csr -noout -subject openssl req -in host.csr -noout -text | grep -A1 "Subject Alternative Name" </code></pre> Verify a CSR matches its private key</h2> A common cutover mistake is generating the CSR from the wrong key. The modulus (RSA) of the CSR, the key, and the eventual certificate must all match. Compare hashes:</p> openssl req -in host.csr -noout -modulus | openssl md5 openssl rsa -in host.key -noout -modulus | openssl md5 openssl x509 -in host.crt -noout -modulus | openssl md5 </code></pre> All three digests identical → they belong together. Any mismatch → you’ve got the wrong key (or wrong cert) and TLS will fail to start.</p> Generate a CSR (for completeness)</h2> openssl req -new -newkey rsa:2048 -nodes \ -keyout host.key -out host.csr \ -subj "/C=DK/O=Example ApS/CN=example.com" \ -addext "subjectAltName=DNS:example.com,DNS:www.example.com" </code></pre> -addext subjectAltName=…</code> is the part people forget — without SANs the request is useless to a modern CA.</p> FAQ</h2> How do I read a CSR that’s in DER (binary), not PEM?</h3> Add -inform der</code>: openssl req -in host.der -inform der -noout -text</code>.</p> Can I paste a CSR online to decode it?</h3> You can, but don’t get in the habit — a CSR contains your public key and identity, and the paste site sees all of it. Decoding locally with OpenSSL leaks nothing.</p> What’s the difference between a CSR and a certificate?</h3> The CSR is the request</em> (your public key + identity, self-signed). The certificate is the CA’s signed answer</em>. Read a certificate with openssl x509 -in host.crt -noout -text</code>.</p> Summary</h2> Read: openssl req -in host.csr -noout -text -verify</code>.</li> Check the SANs</strong>, not just the CN — that’s what browsers trust.</li> Confirm key/CSR/cert belong together by comparing -modulus | openssl md5</code>.</li> </ul> Inspect and verify a TLS certificate with OpenSSL (2026) 2009-05-06T00:00:00+00:00 TL;DR —</strong> openssl x509 -in cert.crt -noout -text</code> dumps a certificate in readable form. Compare -modulus | openssl md5</code> of the cert and the key to confirm they match. Use openssl s_client -connect host:443</code> to see what a live server serves.</p> Two short 2009 notes (“view x509 details” and “verify a cert matches a key”), merged and refreshed into one. Companion to reading a CSR</a> and removing a key passphrase</a>.</p> </blockquote> View a certificate</h2> openssl x509 -in filename.crt -noout -text </code></pre> filename</code> is the X.509 file — typically .crt</code>, .cert</code>, .pem</code>. -noout</code> skips re-printing the encoded blob; -text</code> gives the human-readable view: subject, issuer, validity dates, key, and extensions.</p> Pull out just the fields you care about:</p> openssl x509 -in cert.crt -noout -subject -issuer -dates openssl x509 -in cert.crt -noout -ext subjectAltName # the SANs openssl x509 -in cert.crt -noout -fingerprint -sha256 </code></pre> The SANs</strong> are the part that matters most now — browsers ignore the CN and only trust the Subject Alternative Names, so confirm every hostname is listed.</p> Verify a certificate matches a private key</h2> The classic cutover failure: the cert and key don’t belong together, and TLS refuses to start. The certificate, key (and CSR) share the same public modulus — compare hashes:</p> (openssl x509 -noout -modulus -in server.crt | openssl md5; \ openssl rsa -noout -modulus -in server.key | openssl md5) | uniq </code></pre> One line of output → they match. Two lines → they don’t</strong> (uniq</code> collapses identical hashes). For an EC key, compare the public keys instead:</p> diff <(openssl x509 -in server.crt -noout -pubkey) \ <(openssl ec -in server.key -pubout) </code></pre> No diff → they match.</p> Inspect what a live server is serving</h2> To see the certificate an HTTPS host actually presents (expiry, chain, SANs):</p> openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName </code></pre> -servername</code> sends SNI, so you get the right cert on a multi-site host. Quick expiry check:</p> echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -enddate </code></pre> Other formats</h2> openssl x509 -in cert.der -inform der -noout -text # DER (binary) openssl pkcs12 -in cert.pfx -info -nodes # inspect a .pfx/.p12 bundle </code></pre> FAQ</h2> “No certificate matches private key” — what now?</h3> The cert and key are from different keypairs. Run the modulus check above; if the hashes differ, find the key that was used to generate this cert’s CSR (or reissue the cert from the key you have).</p> How do I check the full chain?</h3> openssl verify -untrusted intermediate.crt server.crt</code>, or inspect what s_client</code> returns with -showcerts</code> to see every cert the server sends.</p> When does this cert expire, across many hosts?</h3> Script the s_client … -enddate</code> one-liner over a host list — it’s the no-dependencies way to monitor expiry.</p> Summary</h2> View: openssl x509 -in cert.crt -noout -text</code> (and -subject -dates -ext subjectAltName</code>).</li> Match cert↔key: compare -modulus | openssl md5</code> — one line = match.</li> Live server: openssl s_client -connect host:443 -servername host</code>.</li> </ul> Recover RAR, 7z, and ZIP archive passwords on Linux (2026) 2009-03-22T00:00:00+00:00 TL;DR —</strong> extract a hash with rar2john</code> / 7z2john</code> / zip2john</code>, then crack it with hashcat</code> (GPU) or john</code>. Dictionary attack first, then a targeted mask. This replaces the old rarcrack</code> tool, which is unmaintained and CPU-only.</p> The 2009 version of this post used rarcrack</strong> — abandoned for over a decade. The modern, far faster approach is John the Ripper’s hash extractors + hashcat on a GPU. For the ZIP-specific deep dive, see the fcrackzip post</a>; this one covers RAR and 7z too. Only do this on archives you own or are authorised to access.</p> </blockquote> The two-step approach</h2> Modern crackers don’t attack the archive directly. You extract a hash</strong> that represents the password check, then throw a cracker at the hash. The extractors ship with John the Ripper:</p> sudo apt install john # provides rar2john, zip2john, and the *2john scripts sudo apt install hashcat # GPU-accelerated cracker </code></pre> RAR</h2> rar2john archive.rar > hash.txt cat hash.txt </code></pre> The hash format tells you the RAR version. Pick the hashcat mode:</p> # RAR3 (-hp, older): hashcat -m 12500 hash.txt /usr/share/wordlists/rockyou.txt # RAR5 (modern): hashcat -m 13000 hash.txt /usr/share/wordlists/rockyou.txt </code></pre> 7-Zip</h2> 7z2john</code> is a Perl script (install libcompress-raw-lzma-perl</code> if it complains):</p> 7z2john archive.7z > hash.txt # or: 7z2john.pl archive.7z > hash.txt hashcat -m 11600 hash.txt /usr/share/wordlists/rockyou.txt </code></pre> 7-Zip uses AES-256 with many KDF iterations, so it’s slow</strong> to crack — a good wordlist matters far more than raw speed here.</p> ZIP</h2> zip2john archive.zip > hash.txt </code></pre> Which mode depends on the encryption:</p> # Classic ZipCrypto (weak, old PKZIP): hashcat -m 17200 hash.txt /usr/share/wordlists/rockyou.txt # WinZip AES (modern, strong): hashcat -m 13600 hash.txt /usr/share/wordlists/rockyou.txt </code></pre> For ZipCrypto specifically, the lightweight fcrackzip</code> is also an option — covered separately</a>.</p> Dictionary first, then masks</h2> Most recoveries succeed with a wordlist — start there (rockyou.txt</code> ships with Kali, or grab it anywhere). If you remember the shape</em> of the password, a mask attack</strong> is far more efficient than blind brute force:</p> # 8 chars: capital + 5 lowercase + 2 digits, e.g. "Summer26" hashcat -m 13000 -a 3 hash.txt '?u?l?l?l?l?l?d?d' </code></pre> Add rules to a dictionary run to cover common mutations:</p> hashcat -m 13000 hash.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule </code></pre> What to expect</h2> GPU vs CPU:</strong> hashcat on a modern GPU is orders of magnitude faster than the old CPU tools. ZipCrypto cracks at billions/sec; RAR5 and 7z are deliberately slow (strong KDF), so lean on good wordlists and masks rather than exhaustive brute force.</li> Resume:</strong> hashcat checkpoints automatically — --restore</code> continues an interrupted run.</li> Find the running guess:</strong> press s</code> for status during a run.</li> </ul> FAQ</h2> hashcat says “No hashes loaded” or “Token length exception”</h3> The extracted hash includes a prefix the mode must match (e.g. RAR3 vs RAR5). Check the start of hash.txt</code> against the mode you chose; hashcat --identify hash.txt</code> can help.</p> Is this legal?</h3> Recovering a password on an archive you own or are authorised to access is fine. Doing it to someone else’s file without permission is unauthorised access — the usual computer-misuse laws apply.</p> Strong password, dictionary failed — now what?</h3> If it’s a long random password on RAR5/7z/WinZip-AES, it may simply be out of reach — that’s the encryption working as intended. Spend your effort on a smarter wordlist/mask built from what you remember, not on brute-forcing length.</p> Summary</h2> Extract: rar2john</code> / 7z2john</code> / zip2john</code> → hash.txt</code>.</li> Crack: hashcat modes — RAR3 12500</code>, RAR5 13000</code>, 7z 11600</code>, ZipCrypto 17200</code>, WinZip-AES 13600</code>.</li> Wordlist + rules first, then targeted masks. rarcrack is obsolete — don’t bother.</li> </ul> Compress a mysqldump backup — gzip, zstd, xz (2026) 2009-01-31T00:00:00+00:00 TL;DR —</strong> mysqldump db | zstd > db.sql.zst</code> dumps and compresses in one pipe — no giant intermediate file. Restore with zstd -dc db.sql.zst | mysql db</code>. Use gzip</code> for maximum portability, zstd</code> for the best speed/size balance, xz</code> for the smallest file.</p> A 2009 note — the pipe pattern is timeless, but the original reached for lzma</code>. In 2026 zstd</strong> is the one to use; the commands for all the common compressors are below.</p> </blockquote> Dump and compress in one pipe</h2> Piping avoids ever writing the full uncompressed dump to disk:</p> # zstd — modern default: fast, great ratio mysqldump mydb | zstd -o mydb.sql.zst # gzip — universal, on every system mysqldump mydb | gzip > mydb.sql.gz # xz — smallest file, slowest mysqldump mydb | xz > mydb.sql.xz </code></pre> Add the options you’d normally pass to mysqldump</code> (credentials, flags) before the database name.</p> Restore: decompress back into mysql</h2> zstd -dc mydb.sql.zst | mysql mydb gunzip < mydb.sql.gz | mysql mydb xz -dc mydb.sql.xz | mysql mydb </code></pre> -dc</code> / gunzip <</code> stream straight to mysql</code> — again, no temp file.</p> A sane production dump line</h2> For a consistent, restorable backup of an InnoDB database without locking it:</p> mysqldump --single-transaction --quick --routines --triggers --events \ mydb | zstd > mydb-$(date +%F).sql.zst </code></pre> --single-transaction</code> — consistent snapshot without locking (InnoDB).</li> --quick</code> — stream rows instead of buffering (low memory on huge tables).</li> --routines --triggers --events</code> — include stored programs, not just data.</li> </ul> MariaDB</h2> Use the mariadb-dump</code> / mariadb</code> client names (the mysqldump</code>/mysql</code> names still exist as compatibility symlinks):</p> mariadb-dump --single-transaction mydb | zstd > mydb.sql.zst zstd -dc mydb.sql.zst | mariadb mydb </code></pre> Speed vs size, roughly</h2> gzip</strong> — fast, ~everywhere, moderate ratio. Safe default if you can’t install anything.</li> zstd</strong> — as fast as gzip (often faster), notably smaller; zstd -19</code> or --long</code> for archival. Best all-rounder.</li> xz</strong> — smallest output, much slower CPU. Good for cold archives where size is king.</li> </ul> Tune threads on big dumps: zstd -T0</code> (all cores), xz -T0</code>.</p> FAQ</h2> How do I check the dump without restoring it?</h3> zstd -dc mydb.sql.zst | head -50</code> — peek at the SQL header. zstd -t</code> / gzip -t</code> test archive integrity.</p> Can I dump just one table?</h3> mysqldump mydb mytable | zstd > mytable.sql.zst</code>. Add more table names to include several.</p> Restore is slow — anything to do?</h3> Wrap large imports with SET autocommit=0; … COMMIT;</code> and disable keys during load, or restore from a physical backup tool (Percona XtraBackup / mariabackup) for very large datasets.</p> Summary</h2> Dump+compress: mysqldump db | zstd > db.sql.zst</code> (or gzip</code>/xz</code>).</li> Restore: zstd -dc db.sql.zst | mysql db</code>.</li> Production: add --single-transaction --quick --routines --triggers</code>.</li> zstd is the modern pick; gzip for portability; xz for smallest.</li> </ul> Remove the password / editing protection from a Word document (2026) 2008-07-28T00:00:00+00:00 TL;DR —</strong> if a Word doc is read-only / restricted from editing</strong>, a .docx</code> is just a ZIP — unzip it, delete the <w:documentProtection></code> element from word/settings.xml</code>, re-zip. If it’s password-to-open</strong> (encrypted), that’s real crypto: extract a hash with office2john</code> and recover it with hashcat</code>.</p> The 2008 version of this used Office XP’s “Script Editor” — long gone. The modern .docx</code> format makes editing-protection removal even easier (it’s a ZIP), and the distinction between editing protection</em> and real encryption</em> is the thing to get right. Only do this on documents you own or are authorised to modify.</p> </blockquote> First: which kind of “password” is it?</h2> Two completely different protections get called “password” in Word:</p> Editing / read-only protection (“Restrict Editing”).</strong> The document opens fine; you just can’t edit it. This is not encryption</strong> — it’s a flag in the file. Trivial to remove.</li> Password to open (“Encrypt with Password”).</strong> The document won’t open at all without the password. This is</strong> strong AES encryption. You can’t “remove” it — you have to recover the password.</li> </ol> Case 1 — remove editing / read-only protection</h2> A modern .docx</code> is a ZIP archive of XML. The protection lives in one element.</p> # work on a copy cp protected.docx unlocked.docx mkdir extracted && cd extracted unzip ../unlocked.docx </code></pre> Edit word/settings.xml</code> and delete the whole <w:documentProtection .../></code> element. It looks like:</p> <w:documentProtection w:edit="readOnly" w:enforcement="1" w:cryptProviderType="rsaAES" w:cryptAlgorithmSid="14" w:hash="…" w:salt="…"/> </code></pre> Remove that one self-closing tag, then repackage:</p> zip -r ../unlocked.docx . # re-zip the contents </code></pre> Open unlocked.docx</code> — fully editable. (The w:hash</code>/w:salt</code> only protect re-enabling</em> the restriction in the UI; deleting the element ignores them entirely, which is why this “protection” is cosmetic.)</p> Even simpler: LibreOffice</h3> Open the file in LibreOffice Writer → Edit → Edit Mode</strong> (or Format → Sections</strong> / Tools → Protect Document</strong> depending on the protection), turn the protection off, and save. For form/section protection, LibreOffice toggles it without any password.</p> Case 2 — password to open (encrypted)</h2> If Word demands a password just to open</em> the file, the content is AES-encrypted and there’s no shortcut — you recover the password with the same hash-then-crack flow as archive passwords</a>.</p> # office2john ships with John the Ripper office2john protected.docx > hash.txt # hashcat mode depends on the Office version that saved it: # 9400 = Office 2007, 9500 = 2010, 9600 = 2013+ (most modern files) hashcat -m 9600 hash.txt /usr/share/wordlists/rockyou.txt </code></pre> Modern Office encryption uses a heavy KDF, so it’s slow</strong> — a good, targeted wordlist (and a mask built from what you remember) beats brute force. If it was a long random password, it may be genuinely unrecoverable, which is the encryption doing its job.</p> Old .doc (binary format)</h2> The pre-2007 .doc</code> binary format isn’t a ZIP. For editing</em> protection, opening and re-saving in LibreOffice usually drops it; for password-to-open, office2john</code> handles old .doc</code> too (it autodetects the format) — same crack flow.</p> FAQ</h2> Is read-only protection actually security?</h3> No. As above, it’s a removable flag, not encryption — useful to prevent accidental</em> edits, useless against anyone who doesn’t want to be stopped. If you need real protection, use Encrypt with Password</strong>.</p> Excel / PowerPoint?</h3> Same model. .xlsx</code>/.pptx</code> are ZIPs — sheet/workbook protection is an element you can delete; password-to-open is encryption, recoverable via office2john</code> (mode 9600 etc.).</p> Is this legal?</h3> On your own documents, or ones you’re authorised to edit — yes. Removing protection from someone else’s confidential document without permission is not.</p> Summary</h2> Editing/read-only</strong>: unzip the .docx</code>, delete <w:documentProtection></code> from word/settings.xml</code>, re-zip — or just toggle it off in LibreOffice.</li> Password-to-open</strong>: real encryption — office2john file.docx > hash.txt</code>, then hashcat -m 9600 …</code>.</li> Read-only protection is not security; use real encryption if you need it.</li> </ul> Convert Windows line endings to Unix with dos2unix (2026) 2008-04-30T00:00:00+00:00 TL;DR —</strong> dos2unix file.txt</code> rewrites a file’s CRLF (Windows) line endings to LF (Unix) in place. Install it with sudo apt install dos2unix</code>. No dos2unix? sed -i 's/\r$//' file.txt</code> does the same.</p> A 2008 note that pointed at the tofrodos</code> package. On modern Debian/Ubuntu dos2unix</code> is its own package now</strong> — simpler. The rest still applies: CRLF vs LF mismatches are a perennial nuisance.</p> </blockquote> Why it matters</h2> DOS/Windows ends each line with CR+LF</strong> (\r\n</code>); Unix/Linux/macOS use just LF</strong> (\n</code>). A file authored on Windows and run on Linux carries stray \r</code> characters that cause:</p> #!/bin/bash^M: bad interpreter</code> when running a script.</li> Configs and .env</code> files where a value silently gains a trailing \r</code>.</li> Diffs and grep</code> matching things that look identical but aren’t.</li> </ul> Install</h2> sudo apt install dos2unix # Debian / Ubuntu (its own package now) sudo dnf install dos2unix # Fedora brew install dos2unix # macOS </code></pre> Convert</h2> dos2unix script.sh </code></pre> It converts in place</strong>. Keep a copy under a new name if you want the original:</p> dos2unix -n script.sh script.unix.sh </code></pre> The reverse exists too — unix2dos file.txt</code> adds CRLF back (e.g. for a file a Windows tool insists on).</p> Batch a whole tree</h2> Convert every shell script under the current directory:</p> find . -type f -name '*.sh' -exec dos2unix {} + </code></pre> dos2unix</code> skips binary files it detects, so a broad find . -type f</code> is usually safe — but scope it with -name</code> when you can.</p> No dos2unix installed? Use sed</h2> Strip the trailing CR with sed</code> (in place with -i</code>):</p> sed -i 's/\r$//' file.txt </code></pre> Or with tr</code> (writes to a new file — tr</code> can’t edit in place):</p> tr -d '\r' < dosfile.txt > unixfile.txt </code></pre> Check what you’ve got</h2> file script.sh script.sh: Bourne-Again shell script, ASCII text, with CRLF line terminators </code></pre> “with CRLF line terminators” is the tell. cat -A file</code> shows ^M</code> at each line end.</p> FAQ</h2> macOS sed says “invalid command code”</h3> BSD sed</code> (macOS) needs an argument after -i</code>: sed -i '' 's/\r$//' file.txt</code>. Or just brew install dos2unix</code> and avoid the difference.</p> Git keeps reintroducing CRLF</h3> That’s Git’s core.autocrlf</code> / .gitattributes</code>, not the file itself. Set * text=auto eol=lf</code> in .gitattributes</code> to normalise on commit.</p> Does this change the file’s encoding too?</h3> No — line endings and character encoding are independent. For UTF-8/Latin-1 conversion see iconv</a>.</p> Summary</h2> dos2unix file</code> — CRLF → LF, in place. unix2dos</code> for the reverse.</li> Install: sudo apt install dos2unix</code> (now its own package).</li> Batch: find . -name '*.sh' -exec dos2unix {} +</code>.</li> Fallback: sed -i 's/\r$//' file</code> (sed -i '' …</code> on macOS).</li> </ul> Mount a remote filesystem over SSH with sshfs (2026) 2008-03-06T00:00:00+00:00 TL;DR —</strong> sshfs user@host:/remote/path /mnt/point -o reconnect,uid=$(id -u),gid=$(id -g)</code> mounts a remote directory locally over SSH. Unmount with fusermount -u /mnt/point</code>. The server needs nothing beyond OpenSSH, which it already has.</p> A 2008 note that still holds up — if anything sshfs is more useful now that everything’s a remote box. Pairs nicely with SSH key login</a> so the mount comes up without a password prompt.</p> </blockquote> Why sshfs</h2> It’s a FUSE filesystem that speaks the SSH SFTP</strong> protocol. Because every server running OpenSSH already supports SFTP, there is nothing to set up on the server side</strong> — if you can ssh</code> in, you can sshfs</code> in. Great for editing remote files with local tools, copying across, or poking at a server’s filesystem without a full sync.</p> Install</h2> sudo apt install sshfs # Debian / Ubuntu sudo dnf install fuse-sshfs # Fedora brew install macfuse # macOS: needs macFUSE + the sshfs cask </code></pre> Mount</h2> mkdir -p ~/mnt/server sshfs user@remote.host:/home/user ~/mnt/server -o reconnect,uid=$(id -u),gid=$(id -g) </code></pre> uid</code>/gid</code></strong>: map remote file ownership to your</em> local user so you have read/write access (otherwise files may show up owned by someone else and be read-only).</li> reconnect</code></strong>: transparently re-establish the connection if SSH drops.</li> </ul> Now ~/mnt/server</code> is the remote directory — use ls</code>, your editor, file manager, anything.</p> Keep it alive on flaky links</h2> Network blips otherwise leave the mount hung. Add keepalive + auto-reconnect options:</p> sshfs user@host:/path ~/mnt/server \ -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,follow_symlinks </code></pre> ServerAliveInterval</code>/CountMax</code> make SSH notice a dead link in ~45 s; follow_symlinks</code> resolves remote symlinks locally.</p> Unmount</h2> fusermount -u ~/mnt/server # Linux umount ~/mnt/server # macOS </code></pre> Use fusermount -uz</code> (lazy) if it’s stuck on a dead connection.</p> Mount automatically via fstab</h2> For a mount you want back after reboot (key-based auth required, since fstab can’t type a password):</p> user@host:/path /home/me/mnt/server fuse.sshfs noauto,x-systemd.automount,_netdev,reconnect,uid=1000,gid=1000,IdentityFile=/home/me/.ssh/id_ed25519 0 0 </code></pre> x-systemd.automount</code> mounts it on first access rather than at boot, so a slow/absent server doesn’t stall startup.</p> Gotchas</h2> Files owned by the wrong user / read-only</strong> → you forgot uid</code>/gid</code>. Set them to your local id -u</code>/id -g</code>.</li> “Transport endpoint is not connected”</strong> → the SSH link died. fusermount -uz</code> then remount; add reconnect</code> to avoid it.</li> Slow with many small files</strong> → SFTP is chatty; add -o cache=yes,kernel_cache,compression=no</code> and avoid running e.g. grep -r</code> over huge remote trees.</li> macOS</strong> → macFUSE needs a one-time approval in System Settings → Privacy & Security after install.</li> </ul> FAQ</h2> Is sshfs secure?</h3> Yes — all traffic rides inside the SSH connection, same encryption as a normal SSH session.</p> Does the server admin need to install anything?</h3> No. SFTP ships with OpenSSH. If you can SSH in, sshfs works.</p> sshfs vs NFS/Samba?</h3> NFS/Samba are faster for LAN file serving but need server-side setup and open ports. sshfs needs only SSH — ideal for ad-hoc access to a remote box you can already log into.</p> Summary</h2> sshfs user@host:/path /mnt -o reconnect,uid=$(id -u),gid=$(id -g)</code>.</li> Set uid</code>/gid</code> for write access; add ServerAliveInterval</code> + reconnect</code> for stability.</li> Unmount with fusermount -u</code> (Linux) / umount</code> (macOS).</li> Combine with key auth for a password-free mount.</li> </ul> Find the most recently changed files on Linux (2026) 2007-10-30T00:00:00+00:00 TL;DR —</strong> find . -type f -printf '%T+ %p\n' | sort | tail</code> lists files newest-last across a whole tree. To filter by age, find . -type f -mmin -60</code> (last hour) or -mtime -1</code> (last day). On macOS, use the stat</code>/-newermt</code> variants below.</p> A one-line note from 2007 that’s still in my muscle memory. “What changed on this box recently?” comes up constantly — here’s the full toolkit.</p> </blockquote> Newest files in a directory tree (GNU/Linux)</h2> find . -type f -printf '%T+ %p\n' | sort | tail -20 </code></pre> -printf '%T+ %p\n'</code> prints a sortable YYYY-MM-DD+HH:MM:SS</code> timestamp then the path.</li> sort</code> orders oldest→newest; tail -20</code> shows the 20 most recent (| sort -r | head</code> flips it).</li> </ul> Filter by age directly</h2> find</code> can select by modification time without sorting:</p> find . -type f -mmin -60 # modified in the last 60 minutes find . -type f -mmin -5 # last 5 minutes find . -type f -mtime -1 # last 24 hours (-mtime is in days) find . -type f -mtime -7 # last week </code></pre> The leading -</code> means “less than N ago”; +N</code> means “more than N ago”.</p> Files newer than a reference</h2> find . -type f -newer /etc/some.reference # changed after that file find . -type f -newermt "2026-06-01" # changed after a date (GNU) find . -type f -newermt "2 hours ago" # changed in the last 2 hours </code></pre> Add details (size, time) to the listing</h2> find . -type f -mmin -60 -printf '%TY-%Tm-%Td %TT %10s %p\n' | sort # or hand off to ls for human sizes: find . -type f -mmin -60 -exec ls -lh --time-style=long-iso {} + </code></pre> macOS / BSD find (no -printf)</h2> BSD find</code> on macOS doesn’t support -printf</code>. Use -newermt</code> (it does have that) or fall back to stat</code>:</p> find . -type f -mtime -1 # works on macOS too find . -type f -newermt "2026-06-01" # date filter # newest-last with stat (macOS stat syntax): find . -type f -exec stat -f '%m %N' {} + | sort -n | tail -20 </code></pre> (%m</code> = epoch mtime, %N</code> = name; sort -n</code> orders numerically.)</p> FAQ</h2> What’s the difference between modified, changed, and accessed?</h3> -mtime</code>/%T</code> = content</strong> last modified. -ctime</code>/%C</code> = inode changed</strong> (permissions, rename, content). -atime</code>/%A</code> = last accessed</strong> (often disabled via noatime</code> mounts). For “what file changed” you almost always want -mtime</code>/-mmin</code>.</p> How do I find the single newest file?</h3> find . -type f -printf '%T@ %p\n' | sort -n | tail -1 | cut -d' ' -f2-</code> (%T@</code> is epoch seconds).</p> Exclude a directory (e.g. .git)?</h3> find . -path ./.git -prune -o -type f -mmin -60 -print</code>.</p> Summary</h2> Newest-last list: find . -type f -printf '%T+ %p\n' | sort | tail</code>.</li> By age: -mmin -60</code> (minutes), -mtime -1</code> (days), -newermt "…"</code>.</li> macOS: use -mtime</code>/-newermt</code>, or stat -f '%m %N'</code> since BSD find has no -printf</code>.</li> </ul> MySQL: find and remove duplicate rows (2026) 2007-06-09T00:00:00+00:00 TL;DR —</strong> find duplicates with GROUP BY … HAVING COUNT(*) > 1</code>; delete them with a self-join DELETE</code> that keeps the lowest id</code>; then add a UNIQUE</code> index so they can’t return. The old ALTER IGNORE TABLE … ADD UNIQUE</code> shortcut was removed in MySQL 5.7</strong> — don’t use it.</p> The 2007 version of this post used ALTER IGNORE TABLE … ADD UNIQUE INDEX</code> to let MySQL drop the dupes for you. That IGNORE</code> clause is gone in modern MySQL, so here are the approaches that actually work in 2026.</p> </blockquote> 1. Find the duplicates first</h2> Decide what “duplicate” means — which columns must match. Say rows are duplicates when (a, b)</code> are equal:</p> SELECT a, b, COUNT(*) AS n FROM mydata GROUP BY a, b HAVING n > 1; </code></pre> Always look before you delete.</p> 2. Delete them, keeping one row</h2> Self-join (works on every version)</h3> Keep the row with the lowest id</code></strong> in each duplicate group:</p> DELETE t1 FROM mydata t1 JOIN mydata t2 ON t1.a = t2.a AND t1.b = t2.b AND t1.id > t2.id; </code></pre> t1.id > t2.id</code> deletes every copy except the smallest id. Flip to <</code> to keep the newest instead.</p> Window function (MySQL 8.0+ / MariaDB 10.2+)</h3> Cleaner and easy to extend to “keep the newest per group”:</p> DELETE FROM mydata WHERE id IN ( SELECT id FROM ( SELECT id, ROW_NUMBER() OVER (PARTITION BY a, b ORDER BY id) AS rn FROM mydata ) x WHERE rn > 1 ); </code></pre> The extra subquery layer is required — MySQL won’t let you delete from a table you’re selecting from directly.</p> 3. Stop them coming back</h2> Once the table is clean, add a UNIQUE</code> index so future inserts can’t duplicate:</p> ALTER TABLE mydata ADD UNIQUE INDEX uq_a_b (a, b); </code></pre> Then write inserts as INSERT … ON DUPLICATE KEY UPDATE …</code> or INSERT IGNORE</code> so the dedup is enforced at write time.</p> Big tables: the rebuild approach</h2> For very large tables, rewriting via a fresh table is often faster than a giant DELETE</code>:</p> CREATE TABLE mydata_clean LIKE mydata; ALTER TABLE mydata_clean ADD UNIQUE INDEX uq_a_b (a, b); INSERT IGNORE INTO mydata_clean SELECT * FROM mydata; -- IGNORE drops dup-key rows RENAME TABLE mydata TO mydata_old, mydata_clean TO mydata; </code></pre> FAQ</h2> Why doesn’t ALTER IGNORE TABLE work anymore?</h3> The IGNORE</code> keyword on ALTER TABLE</code> was deprecated in MySQL 5.6 and removed in 5.7</strong>. The self-join or rebuild approach replaces it.</p> How do I keep the newest row instead of the oldest?</h3> Self-join: change t1.id > t2.id</code> to t1.id < t2.id</code>. Window function: ORDER BY id DESC</code> in the PARTITION BY</code>.</p> Back up first?</h3> Yes. DELETE</code> is irreversible — take a compressed dump</a> before running it on production.</p> Summary</h2> Find: GROUP BY cols HAVING COUNT(*) > 1</code>.</li> Delete (portable): self-join DELETE … WHERE t1.id > t2.id</code>.</li> Delete (modern): ROW_NUMBER() OVER (PARTITION BY …)</code>.</li> Prevent: add a UNIQUE</code> index + INSERT … ON DUPLICATE KEY</code>.</li> </ul> SSH login without a password — set up key authentication (2026) 2007-06-09T00:00:00+00:00 TL;DR —</strong> ssh-keygen -t ed25519</code>, then ssh-copy-id user@host</code>. Now ssh user@host</code> logs you in with no password. Use a passphrase on the key plus ssh-agent</code> so it stays both convenient and</em> safe.</p> One of the oldest how-tos from my blog (2007), back when ssh-keygen -t rsa</code> was the answer. In 2026 you want ed25519</strong> keys, and ssh-copy-id</code> does the fiddly part for you.</p> </blockquote> How it works</h2> Key authentication uses a key pair</strong>: a private</em> key that never leaves your machine, and a matching public</em> key you place on each server. The server challenges you with something only the private key can answer — so you prove who you are without ever sending a password.</p> 1. Generate a key pair</h2> ssh-keygen -t ed25519 -C "you@laptop" </code></pre> -t ed25519</code></strong> — modern, short, fast, secure. (Use -t rsa -b 4096</code> only for ancient servers that don’t support ed25519.)</li> -C</code></strong> — a comment to identify the key later.</li> </ul> You’ll be asked where to save it (default ~/.ssh/id_ed25519</code>) and for a passphrase</strong>. Use one — see the agent note below. This produces two files: id_ed25519</code> (private — guard it) and id_ed25519.pub</code> (public — safe to share).</p> 2. Copy the public key to the server</h2> The easy way:</p> ssh-copy-id user@remote.host </code></pre> It appends your public key to ~/.ssh/authorized_keys</code> on the server and fixes the permissions. If ssh-copy-id</code> isn’t available, do it by hand:</p> cat ~/.ssh/id_ed25519.pub | ssh user@remote.host \ "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys" </code></pre> 3. Log in</h2> ssh user@remote.host </code></pre> No password prompt (just your key’s passphrase the first time, if you set one).</p> Keep it convenient with ssh-agent</h2> A passphrase-protected key would defeat the “no password” goal — except ssh-agent</code> caches the unlocked key for your session, so you type the passphrase once</strong>:</p> eval "$(ssh-agent -s)" # start the agent (often already running) ssh-add ~/.ssh/id_ed25519 # unlock the key once </code></pre> macOS stores it in the Keychain automatically with ssh-add --apple-use-keychain</code>.</p> Optionally: turn off password logins</h2> Once keys work, disabling password auth shuts the door on brute-force attempts entirely. On the server, edit /etc/ssh/sshd_config</code>:</p> PasswordAuthentication no PubkeyAuthentication yes </code></pre> Then reload: sudo systemctl reload ssh</code> (or sshd</code>). Confirm key login works in a second session before you do this</strong>, or you can lock yourself out.</p> Permissions matter (the #1 reason it “doesn’t work”)</h2> SSH refuses keys if the permissions are too loose:</p> chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys # on the server chmod 600 ~/.ssh/id_ed25519 # your private key </code></pre> FAQ</h2> Still asks for a password?</h3> Almost always permissions (above) or the wrong key. Debug with ssh -v user@host</code> and watch which key it offers and whether the server rejects authorized_keys</code> for being group/world-writable.</p> Multiple keys / multiple servers?</h3> Put them in ~/.ssh/config</code>:</p> Host prod HostName prod.example.com User deploy IdentityFile ~/.ssh/id_ed25519 </code></pre> Then just ssh prod</code>.</p> rsa or ed25519?</h3> ed25519 by default — smaller, faster, and secure. Reach for rsa -b 4096</code> only when talking to an old server that lacks ed25519 support.</p> Summary</h2> ssh-keygen -t ed25519</code> → ssh-copy-id user@host</code> → ssh user@host</code>.</li> Use a passphrase + ssh-agent</code> to stay convenient and safe.</li> Fix ~/.ssh</code> permissions (700/600) if it won’t take the key.</li> Set PasswordAuthentication no</code> once keys work — after testing.</li> </ul> Convert a text file's character encoding with iconv (2026) 2007-02-24T00:00:00+00:00 TL;DR —</strong> iconv -f UTF-8 -t ISO-8859-1 in.txt > out.txt</code> converts encodings. Check what you’ve got first with file -i in.txt</code>, and add //TRANSLIT</code> (approximate) or //IGNORE</code> (drop) for characters the target can’t represent.</p> A 2007 note — and the original even had the direction muddled, which is exactly the trap. iconv</code> does nothing to tell</em> you which way to go, so step one is always: find out what encoding you actually have.</p> </blockquote> 1. Detect the current encoding</h2> file -i mystery.txt mystery.txt: text/plain; charset=utf-8 </code></pre> file</code> guesses from the bytes — usually right for UTF-8 vs Latin-1, but a guess. If Danish æ ø å</code> (or other non-ASCII) shows up garbled in your editor, the declared/assumed encoding is wrong.</p> 2. Convert</h2> The flags are -f</code> (from)</strong> and -t</code> (to)</strong>. Don’t mix them up:</p> # UTF-8 -> ISO-8859-1 (Latin-1) iconv -f UTF-8 -t ISO-8859-1 utf.txt > latin1.txt # ISO-8859-1 -> UTF-8 iconv -f ISO-8859-1 -t UTF-8 latin1.txt > utf.txt </code></pre> (The long forms --from-code</code> / --to-code</code> are identical.)</p> 3. Handle characters the target can’t represent</h2> Converting to</em> a narrow charset like ISO-8859-1 fails on characters it doesn’t contain (€, em-dashes, emoji) with illegal input sequence</code>. Two ways out:</p> # //TRANSLIT — approximate: “ ” -> " ", é -> e where needed iconv -f UTF-8 -t ISO-8859-1//TRANSLIT in.txt > out.txt # //IGNORE — silently drop characters that don't fit iconv -f UTF-8 -t ISO-8859-1//IGNORE in.txt > out.txt </code></pre> Edit in place safely</h2> iconv in.txt > in.txt</code> truncates the file before reading it — you lose the data. Use a temp file:</p> iconv -f ISO-8859-1 -t UTF-8 in.txt > in.tmp && mv in.tmp in.txt </code></pre> Batch-convert a tree</h2> Convert every .txt</code> under a directory from Latin-1 to UTF-8:</p> find . -type f -name '*.txt' -exec sh -c \ 'iconv -f ISO-8859-1 -t UTF-8 "$1" > "$1.utf8" && mv "$1.utf8" "$1"' _ {} \; </code></pre> List everything iconv</code> supports with iconv -l</code>.</p> FAQ</h2> iconv says “illegal input sequence at position N”</h3> The real source encoding isn’t what you told -f</code>, or you’re converting to a charset that can’t hold a character. Re-check with file -i</code>, or add //TRANSLIT</code>///IGNORE</code>.</p> How do I strip a UTF-8 BOM?</h3> iconv</code> won’t always remove it; sed '1s/^\xEF\xBB\xBF//' in.txt > out.txt</code> drops a leading BOM.</p> What about Windows line endings while I’m at it?</h3> Encoding and line endings are separate problems — see dos2unix</a> for CRLF→LF.</p> Summary</h2> Detect: file -i file.txt</code>.</li> Convert: iconv -f FROM -t TO in > out</code> (-f</code> = from, -t</code> = to).</li> Lossy targets: append //TRANSLIT</code> or //IGNORE</code>.</li> In place: go via a temp file, never > same-file</code>.</li> </ul> Remove the passphrase from a private key with OpenSSL (2026) 2006-09-03T00:00:00+00:00 TL;DR —</strong> openssl rsa -in server.key -out server.key.nopass</code> writes a passphrase-free copy of an RSA key (use openssl pkey</code> for any key type). Then chmod 600</code> it. The server will start without prompting — at the cost of an unencrypted key on disk, so guard it.</p> Refreshed from a 2006 note. The mechanism is unchanged; the commands below add the EC and modern any-key forms, and the security caveat it really deserves.</p> </blockquote> The problem</h2> If your TLS private key is passphrase-encrypted, the web server can’t start unattended — it stops and waits for someone to type the passphrase. That breaks reboots, autoscaling, and config-management. The fix is an unencrypted</strong> copy of the key.</p> Remove it</h2> For a classic RSA key:</p> openssl rsa -in server.key -out server.key.nopass </code></pre> For an EC (elliptic-curve) key:</p> openssl ec -in server.key -out server.key.nopass </code></pre> Type-agnostic (works for RSA, EC, Ed25519 — the modern catch-all):</p> openssl pkey -in server.key -out server.key.nopass </code></pre> OpenSSL prompts for the current passphrase, then writes the decrypted key. Point your server at the .nopass</code> file and it’ll start silently.</p> Lock the file down</h2> An unencrypted key is a plaintext credential. At minimum:</p> chmod 600 server.key.nopass chown root:root server.key.nopass </code></pre> Anyone who reads this file owns your certificate’s identity until it’s revoked. Treat it accordingly.</p> Going the other way: add a passphrase</h2> To encrypt</em> a key (e.g. before moving it):</p> openssl rsa -aes256 -in plain.key -out encrypted.key </code></pre> Should you actually do this?</h2> Removing the passphrase is convenient but trades away a layer of protection — a stolen disk image now hands over a working key. Consider the alternatives before reaching for .nopass</code>:</p> systemd ask-password</code> / a key-loading agent</strong> can supply the passphrase at boot without baking it in.</li> A secrets manager</strong> (Vault, cloud KMS, or the platform’s secret store) hands the key to the process at runtime and never persists it in the clear.</li> Tight file permissions + full-disk encryption</strong> mitigate the plaintext-on-disk risk if you must use an unencrypted key.</li> </ul> For a single hobby server, .nopass</code> + chmod 600</code> is a reasonable, honest trade. For anything sensitive, push the passphrase/secret out of the filesystem.</p> FAQ</h2> Will the certificate still match after I do this?</h3> Yes — you’re only changing how the key is stored</em>, not the key itself. The public key, certificate, and CSR all still match. (Verify with the modulus check in inspecting & verifying certificates</a>.)</p> nginx/Apache still prompts after I switched files?</h3> You’re still pointing at the encrypted key. Check ssl_certificate_key</code> (nginx) / SSLCertificateKeyFile</code> (Apache) really points at the .nopass</code> file, then reload.</p> Can I tell whether a key is encrypted?</h3> head -1 server.key</code> — an encrypted PEM shows Proc-Type: 4,ENCRYPTED</code> or a BEGIN ENCRYPTED PRIVATE KEY</code> header.</p> Summary</h2> RSA: openssl rsa -in server.key -out server.key.nopass</code>; any key: openssl pkey …</code>.</li> chmod 600</code> and restrict ownership — it’s now a plaintext credential.</li> Prefer a boot-time passphrase supplier or secrets manager for anything that matters.</li> </ul> MySQL: set or reset the AUTO_INCREMENT value (2026) 2006-08-31T00:00:00+00:00 TL;DR —</strong> ALTER TABLE t AUTO_INCREMENT = 100000;</code> sets the next auto-increment value. You can raise it freely, but you can’t set it below the current maximum id</strong> — MySQL silently clamps it to max+1.</p> One of the shortest notes from the old blog (2006) — one line. Still correct, but the caveats below are what actually trip people up.</p> </blockquote> Set it</h2> ALTER TABLE mytable AUTO_INCREMENT = 100000; </code></pre> The next inserted row gets id 100000</code> (assuming that’s above the current max). Handy for leaving room between data sets, or starting ids at a friendlier number.</p> Reset after deleting rows</h2> Deleted the tail of a table and want ids to continue from the real maximum instead of the old high-water mark?</p> -- continue from the highest existing id ALTER TABLE mytable AUTO_INCREMENT = 1; -- clamps up to max(id)+1 automatically </code></pre> Setting it to 1</code> doesn’t reset to 1 if rows exist — MySQL clamps to MAX(id) + 1</code>. That’s usually exactly what you want after a cleanup.</p> Empty a table and truly start at 1</h2> If you want ids to restart from 1, the table must be empty. TRUNCATE</code> does both — wipes rows and</em> resets the counter:</p> TRUNCATE TABLE mytable; -- removes all rows AND resets AUTO_INCREMENT to 1 </code></pre> (DELETE FROM mytable</code> removes rows but leaves the counter where it was — use ALTER TABLE … AUTO_INCREMENT = 1</code> after it, or TRUNCATE</code>.)</p> Gotchas</h2> Can’t go below the max.</strong> ALTER TABLE … AUTO_INCREMENT = 5</code> on a table whose largest id is 900 leaves it at 901. There’s no way to reuse ids below existing data without rewriting the table.</li> Engine differences on restart.</strong> Modern InnoDB (MySQL 8.0+) persists the counter across restarts. Older InnoDB (≤5.7) recomputed it as MAX(id)+1</code> at startup, so a gap at the top could “shrink” after a reboot. MyISAM always persisted it.</li> Replication / Galera.</strong> With auto_increment_increment</code> > 1 (multi-primary, Galera, group replication), ids jump in steps (e.g. 1, 3, 5…) by design — don’t “fix” the gaps, they prevent id collisions between nodes.</li> Gaps are normal.</strong> Rolled-back transactions and failed inserts consume ids. Auto-increment guarantees uniqueness and monotonicity, not</strong> contiguity. Don’t rely on “no holes”.</li> </ul> FAQ</h2> How do I see the current value?</h3> SHOW TABLE STATUS LIKE 'mytable'; -- the Auto_increment column </code></pre> or query information_schema.TABLES</code>.</p> It won’t let me lower it — why?</h3> By design: lowering below existing ids would risk duplicate keys. Rewrite the table (dump, recreate, reload) if you genuinely must renumber.</p> Does this work the same in MariaDB?</h3> Yes — ALTER TABLE … AUTO_INCREMENT = N</code> and TRUNCATE</code> behave the same. Restart-persistence depends on the engine/version as above.</p> Summary</h2> Set/raise: ALTER TABLE t AUTO_INCREMENT = N</code>.</li> After deletes: ALTER TABLE t AUTO_INCREMENT = 1</code> clamps to MAX(id)+1</code>.</li> Restart at 1: TRUNCATE TABLE t</code> (must be empty).</li> Can’t set below the current max; gaps are expected.</li> </ul> Java cacerts default password — and how to use the truststore (2026) 2006-08-29T00:00:00+00:00 TL;DR —</strong> the default password for Java’s cacerts</code> truststore is changeit</code></strong>. The file lives at $JAVA_HOME/lib/security/cacerts</code> in any modern (Java 9+) JDK. Use keytool</code> to list, import, and change the password.</p> This was a two-line note in 2006 (the password and the path). Both are still right — Java never changed the default — but the path moved in Java 9, and the useful part is what you do</em> with the truststore, below.</p> </blockquote> The default password</h2> changeit </code></pre> That’s it. It’s the same on every JDK, every OS, and has been for the entire history of Java. (Some Linux distros that manage the system truststore set it to changeme</code> — if changeit</code> is rejected, try that.)</p> Where cacerts lives</h2> In a modern JDK (Java 9 and later, after the JRE/JDK merge):</p> $JAVA_HOME/lib/security/cacerts </code></pre> On older Java 8 and earlier it was under $JAVA_HOME/jre/lib/security/cacerts</code>. Find it if unsure:</p> find "$JAVA_HOME" -name cacerts </code></pre> List the trusted CAs</h2> keytool -list -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit </code></pre> Add -v</code> for full detail, or grep for a specific alias.</p> Import a certificate (internal CA / self-signed)</h2> The common reason you’re here: a Java app throws PKIX path building failed</code> / unable to find valid certification path</code> because it doesn’t trust an internal or self-signed cert. Import it into the truststore:</p> keytool -importcert \ -alias my-internal-ca \ -file internal-ca.crt \ -keystore "$JAVA_HOME/lib/security/cacerts" \ -storepass changeit </code></pre> Grab the cert a server is presenting first if you don’t have the file — see inspecting a TLS certificate</a> (openssl s_client … -showcerts</code>). Prefer importing the CA</strong> that signed the cert over the leaf cert itself, so it keeps working after renewal.</p> Remove or replace an entry</h2> keytool -delete -alias my-internal-ca \ -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit </code></pre> Actually change the password</h2> The alias is literally “changeit” for a reason:</p> keytool -storepasswd \ -keystore "$JAVA_HOME/lib/security/cacerts" \ -storepass changeit -new <new-password> </code></pre> In practice most setups leave the global cacerts</code> at the default and instead point apps at a separate truststore</strong> they control (-Djavax.net.ssl.trustStore=…</code>), which is cleaner than editing the JDK’s own file.</p> FAQ</h2> Should I edit the JDK’s cacerts directly?</h3> For a quick fix, sure. Better practice: keep a project-specific truststore and pass -Djavax.net.ssl.trustStore=/path/to/store -Djavax.net.ssl.trustStorePassword=…</code>, so a JDK upgrade doesn’t wipe your changes.</p> keytool says “keystore was tampered with, or password was incorrect”</h3> Wrong password — try changeit</code>, then changeme</code> (distro-managed JDKs). Confirm you’re pointing at the right cacerts</code> if you have multiple JDKs installed.</p> Truststore vs keystore — what’s the difference?</h3> A truststore</strong> holds the CA certs you trust (cacerts). A keystore</strong> holds your</em> private keys + certs (what a server presents). Same file format, opposite roles.</p> Summary</h2> Default cacerts</code> password: changeit</code></strong> (sometimes changeme</code> on distro JDKs).</li> Path (Java 9+): $JAVA_HOME/lib/security/cacerts</code>.</li> keytool -list</code> to view, -importcert</code> to trust an internal CA, -storepasswd</code> to change it.</li> Prefer a separate app-managed truststore over editing the JDK’s own.</li> </ul>

Network</th>	IIN prefix range(s)</th>	PAN length</th></tr></thead>
Visa</strong></td>	`4</code></td>`	13, 16, 19</td></tr>
Mastercard</strong></td>	`51</code>–55</code>, 2221</code>–2720</code></td>`	16</td></tr>
American Express</strong></td>	`34</code>, 37</code></td>`	15</td></tr>
Discover</strong></td>	`6011</code>, 644</code>–649</code>, 65</code>, 622126</code>–622925</code></td>`	16–19</td></tr>
Diners Club Intl</strong></td>	`36</code>, 300</code>–305</code>, 3095</code>, 38</code>–39</code></td>`	14–19</td></tr>
JCB</strong></td>	`3528</code>–3589</code></td>`	16–19</td></tr>
UnionPay</strong></td>	`62</code>, 81</code></td>`	16–19</td></tr>
Maestro</strong></td>	`50</code>, 56</code>–69</code>, 6304</code>, 6759</code>, 676770</code>, 676774</code></td>`	12–19</td></tr>
RuPay</strong></td>	`60</code>, 6521</code>, 6522</code></td>`	16</td></tr>
Mir</strong></td>	`2200</code>–2204</code></td>`	16</td></tr>
Troy</strong></td>	`9792</code></td>`	16</td></tr> </tbody></table> Notes: ranges can overlap at the edges (e.g. some `62</code> UnionPay vs 622126</code>–622925</code> Discover co-badging), and 50</code>/56</code>–69</code> for Maestro is broad and collides with others — which is exactly why issuer-level resolution needs a database, not a prefix rule.</p>` What you cannot</em> tell from the prefix</h2> There is no formula</strong> that turns a prefix into a bank name, country, or debit/credit flag. That mapping lives in a maintained BIN database</strong> built from network bulletins and observed cards. So:</p> Network</strong> → readable from the table above. ✅</li> Issuer bank, country, card type, product, prepaid/debit/credit</strong> → database lookup only. ❌ by hand.</li> </ul> Three ways to look up a BIN</h2> 1. By hand (network only)</h3> Take the first digits and match them against the table above. Good enough when all you need is “is this Visa or Mastercard?”.</p> 2. On a lookup site / free API</h3> For issuer-level detail, use a BIN lookup service. The well-known free option is binlist.net</strong>, which exposes a JSON API:</p> curl https://lookup.binlist.net/45717360 </code></pre> { "scheme": "visa", "type": "debit", "brand": "Visa Classic", "bank": { "name": "Example Bank", "country": "..." }, "country": { "name": "United Kingdom", "alpha2": "GB" } } </code></pre> It’s rate-limited</strong> (a handful of requests per hour) and best for occasional lookups. For volume, 8-digit granularity, and reliability you want a licensed database — iinlist.com</strong> is the commercial option built for exactly this. (Background: how both came to exist</a>.)</p> Only ever send the BIN — the first 6-8 digits — never a full card number</strong> to a third-party lookup. The prefix is all a lookup needs, and full PANs are sensitive (PCI) data.</p> 3. Programmatically</h3> For more than the occasional check, validate and normalise first, then look up:</p> # normalise: strip spaces, take first 8 digits as the BIN bin=$(echo "4571 7360 1234 5678" \| tr -dc '0-9' \| cut -c1-8) curl -s "https://lookup.binlist.net/$bin" </code></pre> A quick Luhn</strong> validity check before you store or look anything up (POSIX shell):</p> luhn() { # returns 0 if the number passes the Luhn check echo "$1" \| tr -dc '0-9' \| rev \| awk '{ s=0; for(i=1;i<=length;i++){d=substr($0,i,1); if(i%2==0){d=2; if(d>9)d-=9}; s+=d} exit (s%10!=0) }' } luhn "4571736012345678" && echo valid \|\| echo invalid </code></pre> For production BIN matching, load a licensed BIN file into your own table and key on 8 digits</strong>, falling back to 6 with a low-confidence flag.</p> Summary</h2> The BIN/IIN</strong> is the card number’s leading digits — network + issuer</strong>; 6 digits historically, 8 now</strong>.</li> You can read the network</strong> off the prefix ranges</a>; issuer/bank/country needs a database</strong>.</li> Look up: by hand</strong> (network), a site/API</strong> like binlist.net (free, rate-limited) or iinlist.com</strong> (commercial, 8-digit), or programmatically</strong>.</li> Send only the first 6-8 digits</strong>, never a full PAN, to any third-party lookup.</li> Prefer 8-digit</strong> matching — see why 6 digits is now ambiguous</a>.</li> </ul> Transcribing 33,000 Danish voice logs on home GPUs — the local pipeline (2026) 2026-06-10T00:00:00+00:00 TL;DR —</strong> Business phone calls had been recorded for over a year: ~33,000 Danish mp3 files, ~570 hours, 32 kbps phone quality</strong>. The brief was to transcribe all of it, name the speakers, summarize per call / per day / per week, make it browsable — and do it locally, with no LLM API</strong>. The result is a pipeline that runs two ASR models and fuses them with Claude</strong>, identifies speakers from metadata before decoding any audio</strong>, heals itself across two GPUs</strong>, and uses Claude Code subagents as the summary layer</strong> instead of an API. Here’s the whole build, and what it teaches about a customer-service function.</p> The grown-up sequel to running Whisper locally instead of a cloud Speech API</a>. Same instinct — keep the audio on your own box — at 33,000-file scale.</p> </blockquote> Start by analysing the corpses</h2> The folder already held nine half-finished attempts</strong> at this problem. Before writing anything new, three agents read all nine. Between them, the dead experiments contained almost every good idea the final system needed:</p> One Python attempt (WhisperX + pyannote + Claude day-summaries) was the most complete — but had hardcoded API keys, an English-alignment bug on Danish audio, and mock diarization in the “real” pipeline.</li> One had discovered the key trick: phone-first speaker identification</strong> (more below), and had already built voice profiles.</li> A Go rewrite had a beautiful service architecture and a SQLite schema — but everything was stubs</strong>; zero segments were ever stored. Lesson: never build the shell before the signal path works.</li> A benchmark harness had already compared six ASR models</strong> on the corpus.</li> </ul> Synthesising the nine was far cheaper than inventing from scratch. Lesson one: analyse the corpses first.</strong></p> The model benchmark</h2> The pre-existing benchmark (on the RTX 4070 Ti) plus a fresh side-by-side settled the model choice:</p> Model</th> Result</th></tr></thead> faster-whisper large-v3-turbo</strong></td> Fastest — ~37× real-time, 1.8 GB VRAM. Great, but slips on noisy Danish.</td></tr> faster-whisper large-v3 (full)</strong></td> Most coherent on real calls. ~18× real-time — fast enough. Chosen.</strong></td></tr> hviske-v3-conversation</strong> (Danish fine-tune)</td> Catches Danish names/idioms the others garble. Chosen as the second track.</strong></td></tr> Voxtral</strong></td> Hallucinated in loops (1,832 words for a 117-second call), language-bleed. Dropped.</strong></td></tr> vibevoice</strong></td> ~6× slower than real-time. Dropped.</strong></td></tr> </tbody></table> The non-obvious decision: run two models, not one.</strong> large-v3 and hviske fail differently</strong> — one has the grammar, the other has the Danish names — so keeping both and fusing them beats either alone.</p> The pipeline</h2> mp3 → ffmpeg band-pass (200–3400 Hz + light denoise + dynaudnorm) → 16 kHz mono → [A] faster-whisper large-v3 (int8_float16, beam 5, VAD, anti-loop guards) → [B] hviske-v3-conversation (Danish fine-tune) ← only on calls ≥45 s → ECAPA-TDNN diarization (token-free clustering, 2-speaker prior on long calls) → "phone-first" naming (filename + phonebook anchor identities; embeddings decide which cluster is the recurring party; reference profiles match the rest) → SQLite (idempotent: SHA-256 hash + status; duplicates inherit their twin's result) per day → Claude subagent reads BOTH transcripts per call, fuses them, fixes diarization from context, writes the Danish day summary per week → Claude subagent synthesises 7 day summaries into threads + a commitments table web → Flask reads the DB live (days, weeks, calls with audio, search, patterns) </code></pre> A few decisions earned their place:</p> Phone-first speaker ID.</strong> The filename carries the timestamp and both numbers; a small phonebook maps numbers to names. You know both</em> identities before decoding a word — audio only has to decide which voice is which</em>, not who they are</em>. Metadata is gold.</strong></li> ffmpeg band-pass helps; DeepFilterNet hurts.</strong> Measured: a 50-year-old band-pass filter made noisy calls more coherent for free; the SOTA neural denoiser caused hallucinations and dropped speech. SOTA is task-dependent.</strong></li> ECAPA over pyannote.</strong> pyannote OOM’d next to Whisper on a 12 GB card and was too slow on CPU for 33k files. Token-free ECAPA clustering on the GPU, with a 2-speaker prior</strong> (a phone call is</em> two-party), fixed the 79% of long calls that otherwise collapsed to a single speaker.</li> int8_float16 + expandable segments</strong> let both</strong> models coexist in ~6–8 GB on the 12 GB card.</li> </ul> The summary layer: Claude Code subagents, no API</h2> The hard constraint was no LLM API key</strong>. So the harness itself is the language model: one Claude Code subagent per day</strong> receives both ASR tracks for every call, a shared name register, and the previous day’s summary, and writes the day summary directly — ~50k–450k tokens per day-agent, no API call in the pipeline, no marginal cost.</strong></p> Three small “institutions” grew around it:</p> A fusion instruction file</strong> — the merge rules ([A]’s structure, [B]’s Danish words), fix diarization from context (a caller stating their own name pins that speaker), skip voicemails, never invent content, report uncertainty honestly.</strong></li> A shared, growing name register</strong> — agents read it before writing and append new clarifications. Over 60+ days it reconciles spelling variants of the same contact into one confirmed identity and keeps two same-named people apart. Name consistency across the whole corpus, accreted one day at a time.</li> A weekly commitments table</strong> — each week’s agent carries a “promises & deliveries” table forward (✅/⏳/❌). A genuinely useful primitive (and, as we’ll see, the bridge to customer service).</li> </ul> Running it across two machines</h2> Idempotency made the corpus splittable mid-run:</p> Machine 1 (RTX 4070 Ti, 12 GB):</strong> the full dual-model pipeline, working chronologically forward.</li> Machine 2 (GTX 1060, 6 GB, Pascal):</strong> deployed over SSH/Tailscale with one script; took a later partition. Runs only the [A] track in int8 (new CUDA wheels dropped Pascal, so torch is on CPU while CTranslate2 drives the GPU directly).</li> Merge:</strong> the worker writes its own SQLite; the main box pulls and merges every 15 minutes (idempotent — transcribed</code> can be upgraded to done</code>). The corpus is processed from both ends at once.</strong></li> </ul> Because every file is keyed by SHA-256 hash + status</strong>, moving half the work to another machine mid-run was harmless. Idempotency is the freedom to fail.</strong></p> Self-healing, learned the hard way</h2> Long unattended runs fail in creative ways. Each failure got a permanent countermeasure:</p> Two transcription processes on one GPU</strong> (an orphan survived a restart) → mutual OOM poisoning, 756 failed rows. Fix: a flock</code> singleton in the supervisor + auto-kill of orphans on startup.</li> The “poison file” myth</strong> — a file looked like it crashed the process repeatedly; it was actually the dual-process conflict. It ran fine on retry. The supervisor got retry-once-then-quarantine logic anyway.</li> Silent hangs</strong> — a worker hung for an hour on one file (process alive, no progress). Fix: a watchdog that kills the inner process after 20 minutes with no DB activity (DB mtime as the progress signal).</li> An outer watchdog every 10 minutes</strong> checks the supervisor, DB progress and web server locally — and all of it on the worker over SSH — and auto-restarts.</li> False “ready” days</strong> — a max-date heuristic declared a day finished while 93 of its 104 files were still missing. Fix: the inbox is ground truth</strong> — a day/week is ready only when every</em> one of its files has a settled DB row. Ground truth beats heuristics; the max-date guess lied twice, the inbox count never did.</strong></li> Anonymous calls</strong> — files from a withheld number didn’t match the filename pattern and went invisible to day-grouping. Parser widened, rows repaired.</li> A duplicate bug</strong> — identical audio under a new name was marked done</code> with no transcript (one hash shared by 103 empty ring-out files) and polluted the day dumps. Now duplicates inherit their twin’s status and content.</li> Reaped background processes</strong> — nohup</code> jobs were harvested by the environment and died unnoticed for hours. Fix: all long-running work as harness-managed background tasks, with the watchdog as backstop.</li> </ol> Self-healing has to be layered:</strong> process-level (supervisor: crash / hang / poison / orphan) and</em> system-level (watchdog: supervisor dead? web down? worker gone?).</p> The numbers (as of this writing)</h2> </th> </th></tr></thead> Corpus</td> ~33,000 mp3, ~570 audio hours, 13 months</td></tr> Processed</td> ~6,100 files (19%), from both ends</td></tr> Summaries</td> 60 daily + 7 weekly</td></tr> Local speed</td> dual-model ~0.2 RTF; ~430 files/hour</td></tr> Day-agent cost</td> ~50k–450k subagent tokens/day (avg ~200k)</td></tr> Diarization</td> 2-speaker prior + context repair rescued the 79% of long calls that collapsed to one voice</td></tr> </tbody></table> How this maps to a customer-service function</h2> The original use case is personal call intelligence, but the exact same pipeline is a customer-service</strong> system:</p> Two-track ASR + LLM fusion</strong> → accurate Danish transcripts of support calls.</li> Per-call / per-day / per-week summaries</strong> → QA without listening to every call.</li> The commitments table</strong> generalises directly to SLA / promise tracking</strong> — what an agent promised a customer, and whether it was delivered, carried week to week.</li> The shared name register</strong> → a consistent customer/contact directory built from the calls themselves.</li> The patterns view</strong> (volume by hour, call-direction asymmetry, recurring topics) → staffing and escalation insight, all from metadata + summaries.</li> PII discipline</strong> is built in: the “never invent, flag uncertainty” rule, and redaction before anything is stored.</li> </ul> And the privacy story is the selling point: everything runs locally behind Tailscale</strong> — audio never leaves the building, you set retention and redaction, and there’s no public endpoint. (The honest boundary: if your language layer is a cloud LLM API rather than a local harness, that text leaves — so redact first or keep the LLM local too.)</p> The lessons, distilled</h2> Analyse the corpses first</strong> — nine dead experiments held almost every right idea. Synthesis beats invention.</li> Metadata is gold</strong> — filenames alone gave speaker identity, day structure and the whole pattern analysis before a second of audio was decoded.</li> Two mediocre, diverse ASR tracks + a model that fuses them beat one good track.</strong> Error diversity is the point.</li> SOTA is task-dependent</strong> — neural denoise hurt</em> ASR measurably; a 50-year-old band-pass helped.</li> Idempotency is the freedom to fail</strong> — hash + status made every crash, restart and mid-run migration harmless.</li> Self-healing in layers</strong> — supervisor for the process, watchdog for the system.</li> Ground truth over heuristics</strong> for progress gates — count the inbox, don’t guess from the max date.</li> An LLM can be the pipeline’s expensive step without an API</strong> — when the harness itself is the model, a “summary stage” is a subagent with a good instruction file, a shared register, and an honesty norm.</li> </ol> Factory reset a Yealink phone — even without the admin password (2026) 2026-06-10T00:00:00+00:00 TL;DR —</strong> To factory reset a Yealink</strong> SIP desk phone you have three options: the keypad menu</strong> (needs the admin password), the web UI</strong> (needs the admin password), or a hardware key-hold</strong> that needs no password at all</strong> — hold the OK</strong> key for ~10 seconds. The last one is what you want for a used or inherited phone with an unknown admin login. This also covers the 2026 default-password situation: old firmware is admin</code>/admin</code>, newer units ship a unique password on a label</strong>.</p> The default password, then → now</h2> This trips people up, so get it straight first:</p> Older firmware:</strong> username admin</code>, password admin</code>. The classic default.</li> Newer firmware (security hardening, ~2021 onward):</strong> Yealink ships each phone with a unique random default password</strong> printed on a sticker (usually on the underside or the box), or forces you to set a new password on first web login. So admin</code>/admin</code> will not work</strong> on recent units.</li> </ul> If you have the password, reset from the menu or web UI. If you don’t, skip to the hardware reset</strong> — it clears the password entirely.</p> Method 1 — Hardware reset (no admin password needed)</h2> This is the one most people are searching for. With the phone powered on and idle</strong> (not in a call, not in a menu):</p> Press and hold the OK key</strong> — the round/centre key below the screen — for about 10 seconds</strong>.</li> The screen shows “Reset to factory settings?”</strong></li> Press OK</strong> to confirm.</li> The phone wipes everything and reboots. This takes a minute or two; don’t unplug it.</li> </ol> No login required — this resets the admin password along with everything else. (On a few models the prompt is triggered by holding the X</strong>/cancel key instead; if OK doesn’t do it, try that.)</p> Method 2 — From the phone’s keypad (needs admin password)</h2> Press the Menu</strong> soft key.</li> Go to Settings → Advanced Settings</strong> and enter the admin password (admin</code> on old firmware, or the label password).</li> Choose Reset to Factory</strong> (sometimes Reset Config</strong>) and confirm.</li> </ol> Method 3 — From the web interface (needs admin password)</h2> Find the phone’s IP: Menu → Status</strong> (or Settings → Status</strong>).</li> Browse to http://<phone-ip>/</code> and log in as admin</code>.</li> Go to Settings → Upgrade</strong> (or Reset & Reboot</strong>) and click Reset to Factory</strong>.</li> </ol> After the reset</h2> A full reset erases the SIP account, network config, contacts and call history</strong> — the phone comes back as if new. Before you reset (if you can log in), note your SIP credentials</strong> (server/registrar, username, auth ID, password) so you can re-register it afterward. On newer firmware you’ll be asked to set a fresh admin password on first login again.</p> Summary</h2> No admin password?</strong> Hold the OK</strong> key ~10 s while idle → confirm → done. No login needed.</li> Have the password?</strong> Reset from Menu → Settings → Advanced</strong>, or the web UI</strong> at http://<phone-ip>/</code>.</li> Default password:</strong> admin</code>/admin</code> on old firmware; a unique label password</strong> on newer units.</li> A factory reset erases the SIP account and contacts</strong> — save your SIP credentials first.</li> </ul> Update Garmin firmware and maps in 2026 — from WebUpdater to Garmin Express 2026-06-10T00:00:00+00:00 TL;DR —</strong> If you searched for Garmin WebUpdater</em> or how to update Garmin firmware</em>, the tool you remember is gone. WebUpdater was discontinued (~2015)</strong>; the current path is Garmin Express</strong> (a desktop app, USB cable) for nüvi/DriveSmart sat-navs, or Garmin Connect</strong> (phone, over the air) for watches and newer handhelds. This post covers the 2026 way to update firmware and maps</strong> on each, what to do with an old nüvi, and the hidden nüvi debug menu</strong>.</p> Then → now: WebUpdater is dead</h2> For years you updated a Garmin with WebUpdater</strong> — a small desktop helper that checked for firmware. Garmin retired it and folded everything into two apps:</p> Garmin Express</strong> — desktop (Windows/macOS), connects over USB cable</strong>. This is what replaced WebUpdater for sat-navs (nüvi, DriveSmart, Drive) and is also the cabled path for watches/handhelds and map</strong> updates.</li> Garmin Connect</strong> — phone app (iOS/Android), updates over the air</strong> over Bluetooth/Wi-Fi. This is the path for watches (Forerunner, fēnix, Venu), bike computers (Edge), and modern handhelds.</li> </ul> If you still have WebUpdater installed, uninstall it — it no longer does anything useful.</p> Update a nüvi / DriveSmart sat-nav (firmware + maps)</h2> This is the case behind most “update Garmin firmware” searches.</p> Download Garmin Express</strong> from garmin.com/express</a> and install it on a Windows or Mac computer.</li> Connect the device with a USB cable</strong> and power it on. Wait for the computer to recognise it as a drive.</li> Open Garmin Express. It detects the unit and lists available software (firmware)</strong> and map</strong> updates.</li> Click Install All</strong>, or pick individual updates. Map files are large (often several GB) — leave it plugged in and don’t disconnect mid-update.</li> When it finishes, safely eject and unplug. The unit reboots into the new firmware.</li> </ol> Map updates</strong> appear here too. If your unit has lifetime maps</strong> (“LM”/“LMT” in the model name), updates are free for the supported life of the device. Otherwise Express will offer a paid map purchase.</p> Update a watch / Edge / newer handheld (over the air)</h2> Install Garmin Connect</strong> on your phone and pair the device.</li> Connect updates download automatically; you’ll get a prompt when firmware is ready.</li> Keep the device charged and near the phone — it installs and reboots on its own.</li> </ol> For a cabled update of these devices (or if OTA fails), Garmin Express on a computer works too.</p> Very old nüvi units — what still works</h2> Many early nüvi models (the 2007–2012 era) are now end-of-life</strong>: firmware may still install via Garmin Express, but map updates are no longer offered</strong> and lifetime-map coverage has ended. If Express shows “up to date” with an old map year, that’s usually the end of the road — the hardware simply isn’t supported with new map data anymore. The unit keeps working with the maps it has.</p> Bonus: the hidden nüvi debug menu</h2> A long-standing trick for diagnosing a flaky nüvi: power it on, then press and hold the bottom-right corner of the touchscreen</strong> for a few seconds. A diagnostics screen</strong> appears — software version, touchscreen calibration test, GPS signal test, battery info. It’s safe to view; avoid changing touchscreen calibration unless the screen is genuinely misaligned.</p> Summary</h2> WebUpdater is discontinued</strong> — use Garmin Express</strong> (desktop, USB) or Garmin Connect</strong> (phone, over the air).</li> nüvi / DriveSmart</strong>: Garmin Express over USB handles both firmware and maps; “Install All”.</li> Watches / Edge / handhelds</strong>: Garmin Connect updates over the air.</li> Lifetime maps</strong> (LM/LMT models) update free; very old nüvi units are end-of-life for new map data.</li> nüvi debug menu</strong>: hold the bottom-right corner of the screen after power-on.</li> </ul> From Launchy to Raycast: the history of the keystroke launcher (2007 → 2026) 2026-06-07T00:00:00+00:00 TL;DR —</strong> In 2007 I posted a short screencast of Launchy</a></strong> — a “keystroke application launcher” that let you summon any program on Windows by hitting a hotkey and typing a few letters, instead of hunting through the Start menu. That pattern — hotkey → type → fuzzy-match → launch</strong> — was born on the Mac (Quicksilver, LaunchBar), crossed to Windows with Launchy, spread to Linux, and then did two things at once: it matured into full productivity platforms (Alfred</strong>, then Raycast</strong>), and it dissolved into the Cmd+K command palette</strong> that now lives inside nearly every app you use. Here’s the 19-year arc.</p> A companion to the other time-capsule posts here — like Xming on Windows XP → WSLg</a> and 25 years of Wi-Fi security</a>. An old screencast, and what the idea grew into.</p> </blockquote> The setup, back then</h2> The video</a> (“Shiny Windows Application Launcher” — Shiny</em> was a Launchy skin) shows the 2007 workflow. You install Launchy</strong>, it indexes your Start menu, and from then on:</p> Press Alt+Space</strong>. A small translucent box appears in the middle of the screen.</li> Type a few letters — fir</code> for Firefox, wor</code> for Word.</li> Launchy fuzzy-matches against everything it indexed and shows the best hit.</li> Hit Enter</strong>. The app launches. The box vanishes.</li> </ol> No mouse, no Start menu, no desktop icons. After a week your fingers knew the three-letter prefix for every app you used. Launchy — written by Josh Karlin and open-sourced — was explicitly pitched as “Quicksilver for Windows”</strong>, and that comparison is the key to the whole story.</p> Where the idea actually came from</h2> Launchy didn’t invent the keystroke launcher — it brought a Mac</strong> idea to Windows:</p> LaunchBar</strong> (Objective Development) — the granddaddy, with roots on NeXTSTEP in the 1990s</strong>, reborn on Mac OS X. Type an abbreviation, get the thing.</li> Quicksilver</strong> (Nicholas Jitkoff / Blacktree, ~2003) — the legendary, almost mystical Mac launcher. Not just “launch an app” but a verb-noun grammar: select a thing</em>, choose an action</em>, pick a target</em>. It defined the genre and inspired a generation (it was open-sourced in 2007 when its creator left for Google).</li> Spotlight</strong> (Mac OS X Tiger, 2005) — Apple baked search into the OS, which is where most casual users met the “just type to find things” idea.</li> </ul> Launchy (2004→) was the Windows answer to all that, and the 2007 video is a snapshot of it in its prime.</p> At a glance — 19 years of launchers</h2> Era</th> macOS</th> Windows</th> Linux</th> The pattern</th></tr></thead> ~2003–05</strong></td> Quicksilver, LaunchBar, Spotlight</td> Start menu (Vista adds search, 2007)</td> —</td> Launcher is a Mac power-user thing</td></tr> 2007 (the video)</strong></td> Quicksilver peak</td> Launchy</strong> (“Quicksilver for Windows”)</td> —</td> Keystroke launcher crosses to Windows</td></tr> ~2008–10</strong></td> Quicksilver stalls → Alfred</strong> (2010)</td> Launchy peaks, then slows</td> GNOME Do</strong>, Katapult</td> Launcher goes mainstream-power-user</td></tr> ~2011–15</strong></td> Alfred + Powerpack dominates</td> Wox (2014)</td> Synapse, Albert</td> Command palette</strong> appears (Sublime, then VS Code)</td></tr> ~2016–20</strong></td> Raycast</strong> founded (2020)</td> PowerToys Run</strong> (2020), Flow Launcher</td> Rofi, Ulauncher</td> Cmd+K spreads into every web app</td></tr> 2026 (today)</strong></td> Raycast dominant; Spotlight + Apple Intelligence</td> PowerToys Command Palette</strong>; Raycast (beta)</td> Rofi / Ulauncher / Albert</td> Launcher = AI-powered command hub</td></tr> </tbody></table> What changed</h2> 1. The launcher became a platform.</strong> Launchy launched apps and files. Alfred</strong> (2010) added workflows</em> — chain actions, run scripts, clipboard history, snippets — and became the Mac standard for a decade. Then Raycast</strong> (2020) rebuilt the idea as a native, extensible platform: an extension store, window management, clipboard history, snippets, calculators, and now built-in AI</strong>. The humble launch box turned into the place power users run half their day. Raycast’s Windows beta arrived in late 2025</strong>, closing the loop back to where Launchy started.</p> 2. Windows kept reinventing it.</strong> Launchy faded after ~2010. Wox</strong> (open source, 2014) carried the torch and spawned Flow Launcher</strong> (a Wox fork with a plugin marketplace and AI plugins). Microsoft itself shipped PowerToys Run</strong> (2020, Alt+Space</code> — a knowing nod to Launchy), now succeeded by the PowerToys Command Palette</strong>. The pattern is so obviously good that the OS vendor adopted it.</p> 3. Linux always had its own.</strong> GNOME Do</strong> (2008) was the early Quicksilver-alike; today it’s Rofi</strong> and dmenu</strong> (minimal, scriptable, beloved by tiling-WM users), Ulauncher</strong>, and Albert</strong>. Same muscle memory, different ecosystem.</p> 4. The biggest shift: the launcher dissolved into every app.</strong> The defining move of the last decade isn’t a better launcher — it’s that the command palette</em> became a universal UX primitive. Sublime Text</strong> (~2011) and then VS Code</strong> (Ctrl/Cmd+Shift+P</code>) made “hit a hotkey, type a command” the way you drive an editor. Then Cmd+K</strong> showed up everywhere: Slack, Linear, Notion, GitHub, Figma, Vercel, Stripe, your browser. The keystroke launcher stopped being a separate app you install and became a control built into the software itself. On the terminal, fzf</strong> (2013) is the same idea distilled to one fuzzy-finder binary.</p> 5. Then AI ate the command bar.</strong> The newest turn: the box you type into now talks to a model. Raycast AI</strong>, Flow Launcher’s AI plugins, Spotlight + Apple Intelligence</strong>, Windows Copilot</strong>. “Hotkey → type → fuzzy-match → act” is becoming “hotkey → ask → the launcher figures out the action.” Launchy’s little translucent box was the larval form of today’s AI command bar.</p> What to use today</h2> macOS</strong> — Raycast</a></strong> is the modern default: launching, clipboard history, window management, snippets, an extension store, and AI in one hotkey. Alfred</a></strong> is the alternative if you prefer a one-time purchase and local automation. Spotlight is built in and now quite good.</p> Windows</strong> — PowerToys Command Palette</strong> (official, free, ships in PowerToys</a>), Flow Launcher</a></strong> (open source, plugin marketplace), or Raycast</strong> (Windows beta since late 2025). Pair any of them with Everything</a></strong> for instant file search.</p> Linux</strong> — Rofi</strong> or dmenu</strong> for the scriptable/tiling crowd, Ulauncher</strong> or Albert</strong> for a friendlier GUI.</p> Terminal</strong> — fzf</a></strong>. Pipe anything into it, fuzzy-find, act. The launcher idea in 30 lines of muscle memory.</p> The takeaway</h2> The 2007 Launchy clip looks quaint — a translucent box, a Shiny skin, three letters and Enter. But the idea in it won completely. It started as a Mac curiosity, Launchy brought it to Windows, Linux picked it up, and from there it went two directions at once: up</em> into productivity platforms like Raycast, and sideways</em> into every app as the Cmd+K command palette. Today you use that 2007 idea dozens of times a day — you just don’t install it anymore, because it’s everywhere. And the box is starting to think.</p> FAQ</h2> What was Launchy?</h3> A free, open-source keystroke launcher for Windows (later cross-platform), first released by Josh Karlin around 2004. Hotkey, type a few letters, fuzzy-match, launch — “Quicksilver for Windows”. The 2007 video shows it on the Shiny skin.</p> Is Launchy still maintained?</h3> No — development tapered off around 2010 and it’s effectively dormant. On Windows today use PowerToys Command Palette, Flow Launcher, or Raycast.</p> App launcher vs command palette — what’s the difference?</h3> Same pattern, different scope. A launcher (Quicksilver, Launchy, Alfred, Raycast) is system-wide; a command palette (VS Code’s Ctrl+Shift+P</code>, the Cmd+K</code> bar in Slack/Linear/GitHub) is that same UX inside one app. The launcher came first; the palette is it absorbed into everything.</p> What should I use in 2026?</h3> macOS: Raycast or Alfred. Windows: PowerToys Command Palette, Flow Launcher, or Raycast. Linux: Rofi, Ulauncher, or Albert. Terminal: fzf.</p> Summary</h2> The keystroke launcher — hotkey → type → fuzzy-match → launch</strong> — started on the Mac (LaunchBar</strong>, Quicksilver</strong>) and reached Windows via Launchy</strong>, which my 2007 video</a> demos.</li> It grew up</em> into platforms: Alfred</strong> (2010) → Raycast</strong> (2020), now AI-powered, with a Windows beta</strong> as of late 2025.</li> Windows kept reinventing it: Wox</strong> → Flow Launcher</strong>, and Microsoft’s PowerToys Run → Command Palette</strong>.</li> It also spread sideways</em> into every app as the Cmd+K command palette</strong> (Sublime/VS Code → Slack, Linear, Notion, GitHub), and into the terminal as fzf</strong>.</li> The 2007 idea is now everywhere — and increasingly an AI command bar.</li> </ul> From Xming on Windows XP to WSLg: 18 years of Linux GUI apps on Windows (2026) 2026-06-07T00:00:00+00:00 TL;DR —</strong> Running a Linux GUI app on a Windows machine used to mean installing an X server</strong> (Xming, later VcXsrv), pointing an SSH session at it with ssh -X</code>, and watching a remote gedit</code> window paint itself onto your Windows desktop. I have an old screen recording of exactly that</a> — Xming putting gedit on Windows XP</strong>. Eighteen years later you mostly don’t bother: WSLg</strong> ships a Wayland + X server inside</em> Windows, so a Linux app installed in WSL2 just opens like any other window. This post traces the arc — X11 forwarding → VcXsrv → Wayland → WSLg — and what to actually use in 2026.</p> This is a companion to the other “then vs now” notes on this blog — like local speech-to-text replacing the cloud Speech API</a> and 25 years of Wi-Fi security</a>. Same shape: a thing that was fiddly in the XP era is now built in.</p> </blockquote> The setup, back then</h2> The video</a> shows the canonical mid-2000s trick. The pieces:</p> Xming</strong> — a free X11 server for Windows (a port of the X.Org server). It ran in the Windows system tray and provided a display</em> that X clients could draw to.</li> An SSH client</strong> — usually PuTTY, with “Enable X11 forwarding” ticked, or ssh -X</code> from Cygwin.</li> A remote Linux box</strong> running the actual app (gedit</code>, an editor) with no local window of its own.</li> </ul> The flow: SSH connects to the Linux host, the host sets $DISPLAY</code> to tunnel X11 back through the encrypted SSH channel, the app draws to Xming, and a Linux window appears on Windows XP. The application runs entirely on the remote machine; only the pixels and input events</em> travel. This worked because X11 was network-transparent from day one</strong> — a 1984 design decision that aged into a genuinely useful feature.</p> It was clever, and it was also slow and brittle: every menu and redraw was a round-trip, so over anything but a LAN it felt like wading through treacle.</p> At a glance — 18 years of Linux GUI on Windows</h2> Era</th> How you did it</th> What ran the display</th> Pain points</th></tr></thead> ~2007 (XP)</strong></td> ssh -X</code> / PuTTY → Xming</td> Xming X server in the tray</td> Manual install, chatty X11, laggy over WAN</td></tr> ~2012</strong></td> Same, or X over VNC</td> Xming / Xming-mesa, VcXsrv arrives (2011)</td> X server still a separate moving part</td></tr> ~2017</strong></td> VcXsrv + WSL1</td> VcXsrv, set DISPLAY=localhost:0</code></td> WSL1 quirks, fonts/clipboard glitches</td></tr> ~2021</strong></td> WSL2 + manual X server, or</em> WSLg preview</td> VcXsrv / X410, then WSLg</td> Transitional; manual DISPLAY</code> export still common</td></tr> 2026 (today)</strong></td> WSLg, built in</td> Weston (Wayland) + XWayland, auto</td> Basically none — apt install</code>, app opens</td></tr> </tbody></table> What actually changed</h2> 1. The X server stopped being yours to manage.</strong> For ~25 years the X server was a thing you</em> installed and babysat on Windows. With WSLg</a> — announced at Microsoft Build 2021, now standard on Windows 11 and Windows 10 21H2+ — Microsoft bundles a whole display stack into a system distro: a Weston</strong> Wayland compositor, XWayland</strong> for legacy X11 apps, a PulseAudio server for sound, and an RDP link that paints the windows onto the Windows desktop. You install a Linux GUI app in WSL2 and it opens. No DISPLAY</code>, no tray icon, no PuTTY checkbox.</p> # Inside WSL2 on Windows 11 — no X server to install: sudo apt update && sudo apt install -y gedit gedit # a real Linux gedit window opens on Windows </code></pre> 2. Wayland replaced X11 on the Linux side.</strong> The protocol that made the original trick possible is on its way out. Modern Linux desktops default to Wayland</strong>, which — unlike X11 — is not</em> network-transparent. So the “just forward it over SSH” reflex doesn’t map cleanly anymore; the Wayland-native answer for remote display is waypipe</code></a>, and XWayland keeps old X11 apps working in the meantime.</p> 3. Xming itself faded into a paid niche.</strong> Xming is still alive — Colin Harrison shipped 7.7.x builds as recently as January 2026 — but the freely downloadable public release froze at 6.9.0.31 in 2007</strong>; newer versions are donation-gated. The free, actively maintained torch passed to VcXsrv</a></strong>, an open-source X server built from current X.Org sources. (Note: VcXsrv dropped Windows XP support long ago — that era is genuinely over.)</p> 4. The whole reason</em> mostly evaporated.</strong> In 2007 you forwarded an editor because editing remote files any other way was painful. In 2026 you’d reach for VS Code Remote-SSH</strong>, mount the remote filesystem with sshfs</a>, or just work in a terminal over key-based SSH</a>. Forwarding a single GUI window is now the exception, not the workflow.</p> What to use today</h2> You’re on WSL2 (Windows 11 / Win10 21H2+):</strong> do nothing. WSLg is already there. apt install</code> the app and run it. Check with:</p> echo $WAYLAND_DISPLAY # wayland-0 → WSLg is active echo $DISPLAY # :0 → XWayland for legacy X11 apps </code></pre> You need to forward a GUI app from a remote Linux server to Windows:</strong> install VcXsrv</strong>, start it (multiple-windows mode, disable access control on a trusted network only), and:</p> ssh -X user@server # -Y for trusted forwarding if -X is blocked xterm # or whatever GUI app — it paints to VcXsrv </code></pre> This is the exact</em> same mechanism as the Xming clip, just with a modern X server. It still works. It’s still chatty over latency.</p> You want remote GUI that doesn’t crawl over WAN:</strong> skip raw X11. Use xpra</code></a> (“screen for X” — apps survive disconnects and it compresses well), waypipe</code> for Wayland, or a real remote-desktop protocol (RDP via xrdp</code>, or NoMachine/NX) for a full desktop.</p> The takeaway</h2> The Windows XP clip is a little time capsule: a tray-icon X server, a PuTTY tunnel, and a Linux text editor materialising on a beige XP desktop. The idea</em> — run the app over there, see it over here — never went away. What changed is that you no longer assemble it by hand. The X server moved inside Windows, X11 gave way to Wayland, and the common case (“I just want to touch files on that box”) got better answers entirely. Eighteen years of plumbing, quietly absorbed into apt install</code>.</p> FAQ</h2> Does SSH X11 forwarding still work in 2026?</h3> Yes — ssh -X</code> (or -Y</code> for trusted forwarding) is unchanged. It forwards X11 to any X server: VcXsrv, Xming, XQuartz, or WSLg’s. It’s just chatty over latency, which is why xpra/waypipe/RDP usually win for remote work today.</p> Is Xming still maintained?</h3> Builds still appear (7.7.x in 2026), but they’re donation-gated; the last free public release was 6.9.0.31 in 2007 — the Windows XP era of the clip. For a free, actively built X server on Windows, use VcXsrv.</p> Do I still need an X server at all?</h3> Only to forward GUI apps from a remote box over SSH, or to run X apps from a non-WSLg distro. On WSL2 with Windows 11 (or Win10 21H2+), WSLg already bundles one — local Linux GUI apps open with nothing extra installed.</p> Why did Wayland break the old “forward it over SSH” trick?</h3> X11 was network-transparent by design, so forwarding came free. Wayland deliberately isn’t — remote display is a separate concern handled by waypipe or RDP. WSLg papers over it by running Weston + XWayland, so both kinds of app work.</p> Summary</h2> The old way: install Xming</strong>, tick X11 forwarding in PuTTY, ssh -X</code>, and a remote Linux app paints onto Windows. The video</a> is that, on Windows XP.</li> Today: WSLg</strong> ships a Wayland + X server inside Windows — apt install</code> a Linux app in WSL2 and it just opens.</li> VcXsrv</strong> is the free, maintained successor to Xming for the classic remote-forwarding case; Xming</strong> itself went donation-only after 6.9.0.31 (2007).</li> Wayland</strong> replaced X11’s network transparency; use waypipe</strong>, xpra</strong>, or RDP for fast remote GUI.</li> For the original motivation — editing on a remote box — prefer VS Code Remote-SSH, sshfs</a>, or plain SSH</a>.</li> </ul> Extending video clips with AI on a 12 GB GPU — six models compared 2026-06-07T00:00:00+00:00 TL;DR —</strong> “Extending” a video clip is really image-to-video</strong>: grab the last frame and let a model generate a believable continuation, then concatenate. I ran the same machine shot through six</strong> I2V models on one 12 GB RTX 4070 Ti</strong>: Wan2.2-TI2V-5B, Wan2.2-I2V-A14B (GGUF Q4, at 640 px and at 720p), Stable Video Diffusion, LTX-Video and CogVideoX-5B. The headline isn’t the winner — it’s that a 14B</strong> model and 720p</strong> both fit in 12 GB once you get the offload strategy</strong> right.</p> The task</h2> I had a stack of short clips of forestry machines — an excavator digging, a wood chipper, a wheel loader — and wanted them a couple of seconds longer. There’s no more footage; the only way to extend is to invent</em> it. Modern image-to-video models do exactly this: condition on a starting image (here, the clip’s final frame) and a text prompt, and hallucinate motion forward. Stitch the real tail to the generated continuation and you have a longer clip.</p> Everything below ran locally on a single 12 GB RTX 4070 Ti with 125 GB of system RAM (the RAM matters — it’s where the offloaded weights live).</p> The real problem: fitting big video models in 12 GB</h2> Image diffusion is forgiving on VRAM. Video diffusion is not: you’re denoising a 3D latent (frames × height × width), and the newest quality models are 5B-14B parameters. Three things kept biting:</p> The text encoder is huge.</strong> Wan and LTX and CogVideoX all use a T5-XXL / umT5-XXL encoder that’s ~11 GB on its own. The instant model-level offload moves it onto a 12 GB card to encode the prompt, you OOM — before the video model even runs.</li> Activations, not weights, blow up at higher resolution.</strong> A 9 GB transformer can sit on the card fine; it’s the attention activations over (frames × tokens) that overflow when you push past ~480p.</li> Quantization helps disk and a bit of VRAM, but interacts badly with some offload modes.</strong> GGUF Q4 shrinks a 14B expert to ~9 GB, but the way you offload it matters (see below).</li> </ol> The fixes that made it all work:</p> Pre-encode the prompt on CPU, then evict the encoder.</strong> Compute the text embeddings with the T5 on the CPU in fp32</em> (bf16 matmuls on CPU are pathologically slow — it looks hung), cast the result to bf16, set text_encoder = None</code>, and only then start the video model. Now the 11 GB encoder never touches the GPU.</li> Pick the offload mode per model:</strong> enable_model_cpu_offload()</code> — moves whole sub-models on/off the GPU. Fast, but one model must fit at a time (so it caps resolution/length).</li> enable_sequential_cpu_offload()</code> — streams sub-modules. Lower peak VRAM, slower. Great for non-quantized models (LTX, CogVideoX), but breaks GGUF</strong> (accelerate’s meta-device step drops the quant type).</li> apply_group_offloading(..., offload_type="leaf_level", use_stream=True)</code> — streams the transformer leaf-by-leaf. This is the secret weapon.</li> </ul> </li> </ul> Wan2.2: from “fake” 5B to real 720p</h2> I started with Wan2.2-TI2V-5B</strong> (the small, consumer-friendly one). It runs easily with model-offload and produces coherent motion, but at the ~640 px the card allows it looks soft — the classic “AI video” plasticky feel.</p> Stepping up to Wan2.2-I2V-A14B</strong> meant quantization. The official 14B is two experts (high-noise + low-noise) and wants 24-35 GB in fp16. The GGUF Q4 build is ~9 GB per expert, and diffusers can load each through WanTransformer3DModel.from_single_file(..., quantization_config=GGUFQuantizationConfig(...))</code> — you just need the gguf</code> package, or it fails to read the file. With model-offload + the CPU-prompt trick, the 14B runs at 640 px and the motion is visibly better (the wood chipper, a chaotic close-up that the 5B turned to mush, came out coherent).</p> Then the actual goal: 720p</strong>. Model-offload at 1280×720 peaks at ~11.7 GB — it fits, but only ~13 frames before the activations overflow. The breakthrough was group-leaf offloading</strong>: stream the transformer one leaf module at a time, so almost nothing sits on the GPU. Peak VRAM at 1280×720: 1.9 GB</strong>. The card is suddenly empty and resolution is free; the cost is speed (leaf streaming is slow, ~20 min a clip). But it’s real, sharp 720p on a 12 GB card.</p> from diffusers.hooks import apply_group_offloading for t in (pipe.transformer, pipe.transformer_2): # both noise experts apply_group_offloading(t, onload_device=torch.device("cuda"), offload_device=torch.device("cpu"), offload_type="leaf_level", use_stream=True) pipe.vae.enable_tiling() </code></pre> The other three</h2> LTX-Video</strong> (2B). Fast and, for short extensions, the best of the lot — dynamic motion (the excavator throws dirt), prompt-guided, ~3 min a clip at 768×512. Needs sentencepiece</code> for its T5 tokenizer, and sequential</code> offload because that T5 is the same 11 GB OOM trap.</li> Stable Video Diffusion</strong> (img2vid-xt). The veteran. Runs at 1024×576 with model-offload + unet.enable_forward_chunking()</code>, and it’s quick — but SVD has no text prompt</strong>, so its motion is ambient</em> (a gentle drift, a breeze in the trees) rather than the directed action you asked for. Great for cinematic cutaways, wrong tool for “keep digging.”</li> CogVideoX-5B-I2V</strong>. The quality surprise: the longest and smoothest clip (6 s, 49 frames at 720×480), coherent throughout. The catch is speed — with sequential offload + VAE tiling it’s roughly an hour per clip</strong> on 12 GB, which makes it impractical here even though the output is lovely.</li> </ul> The scoreboard</h2> Model</th> Params</th> Fits 12 GB via</th> Output</th> Speed</th> Verdict</th></tr></thead> LTX-Video</td> 2B</td> sequential offload</td> 768×512</td> ~3 min</td> Best for short extensions</strong> — fast, dynamic</td></tr> Wan2.2-I2V-14B @ 720p</td> 14B (Q4)</td> group-leaf offload (1.9 GB!)</strong></td> 1280×720</td> ~20 min</td> Real 720p on 12 GB</strong> — sharpest</td></tr> Wan2.2-I2V-14B</td> 14B (Q4)</td> model offload + CPU prompt</td> 640×384</td> ~8 min</td> Good motion, esp. the hard cases</td></tr> CogVideoX-5B-I2V</td> 5B</td> sequential + VAE tiling</td> 720×480</td> ~1 hr</td> Longest/smoothest, but impractically slow here</td></tr> Stable Video Diffusion</td> ~1.5B</td> model offload + chunking</td> 1024×576</td> ~2 min</td> Fast & clean, but motion is ambient</td></tr> Wan2.2-TI2V-5B</td> 5B</td> model offload</td> 640×384</td> ~3 min</td> The soft, “fake”-looking baseline</td></tr> </tbody></table> What I’d actually do</h2> On a 12 GB card: reach for LTX-Video</strong> for quick, directed extensions, and Wan2.2-14B + group-offload</strong> when you specifically need 720p</strong> and can wait. SVD stays in the kit for ambient cutaways. CogVideoX is gorgeous but you’d want a bigger GPU to use it for real.</p> And the honest limitation: the thing that still reads as “AI” is mostly resolution</strong>. Group-offload buys you 720p or</em> a 12 GB card buys you length — not both at once. High-res and</em> multi-second is the one wall a 12 GB GPU won’t climb; that’s what a 24 GB+ card (or an hour of cloud) is for. Everything else — even a 14B model at 720p — turned out to be a question of offloading, not horsepower.</p> 8-digit BINs explained: what the IIN expansion means for card BIN lookups (2026) 2026-06-06T00:00:00+00:00 TL;DR —</strong> the IIN</strong> (issuer identification number) on a payment card grew from 6 digits to 8</strong>. A 6-digit prefix can now map to several</em> issuers or products, so BIN lookups that key on 6 digits return ambiguous results. The card number’s overall length didn’t change — the account portion just got two digits shorter.</p> This is the structural background behind binlist.net and iinlist.com</a> — if you do anything with card numbers, it’s worth understanding.</p> What a BIN/IIN actually is</h2> The first digits of a card’s PAN (primary account number) identify who issued it. Two terms for the same thing:</p> BIN</strong> — Bank Identification Number</em>, the older industry term.</li> IIN</strong> — Issuer Identification Number</em>, the term ISO/IEC 7812 uses.</li> </ul> They’re used interchangeably. The very first digit is the MII</strong> (Major Industry Identifier) — 4</code> = Visa, 5</code>/2</code> = Mastercard, 3</code> = Amex/Diners/JCB, and so on. The PAN as a whole is structured as:</p> IIN (issuer) account identifier check digit (Luhn) ┌────────────────┐ ┌───────────────────────┐ ┌──┐ 4 5 3 9 1 4 8 8 0 3 4 5 6 7 8 9 └─ 8 digits now ─┘ </code></pre> What changed</h2> Historically the IIN was the first 6 digits</strong>. ISO/IEC 7812 was updated to define it as 8 digits</strong>, and the card networks moved the ecosystem onto 8-digit BINs — Visa and Mastercard set April 2022</strong> as the point by which issuers, acquirers, and processors had to support the longer identifier.</p> Crucially, the PAN length didn’t change</strong> (still up to 19 digits, 16 for most cards). The issuer identifier took two more digits, so the account-identifier portion got two digits shorter</strong>.</p> Why they did it</h2> They were running out of room. A 6-digit space is one million possible IINs, and between new fintechs, BIN sponsorship, and ever-finer product segmentation (each card product often wants its own range) the 6-digit pool was being exhausted. Going to 8 digits multiplies the available ranges by a hundred.</p> The practical fallout for lookups</h2> This is the part that bites if you maintain or consume a BIN database:</p> A 6-digit prefix is no longer unique.</strong> Within one old 6-digit block, the two extra digits can now belong to different</em> issuers or different</em> products. Looking up only 6 digits can return the wrong bank, country, or card type.</li> You need at least 8 digits to be confident.</strong> If your input only has 6 (common with masked/truncated data), treat the result as a best-effort guess, not ground truth.</li> Your data source has to be 8-digit aware.</strong> A BIN list that only carries 6-digit granularity silently collapses distinct 8-digit issuers into one row.</li> </ol> # Same 6-digit prefix, two different 8-digit issuers (illustrative): 4539 14 .. -> 45391488 = Issuer A, debit, country X 4539 14 .. -> 45391499 = Issuer B, credit, country Y </code></pre> What to do in practice</h2> Capture and key on 8 digits</strong> wherever you legitimately have them.</li> Degrade gracefully</strong> when you only have 6 — return the prefix-level info and flag it as low-confidence rather than asserting a single issuer.</li> Mind PCI scope.</strong> The first 6 and</em> the first 8 are both allowed to be stored/displayed under PCI DSS truncation rules (BIN + last 4), but check your acquirer’s current guidance before widening what you persist.</li> Don’t hardcode “6”.</strong> If you have regexes or schema columns that assume a 6-digit BIN, they’re now wrong.</li> </ul> FAQ</h2> Did my card number get longer?</h3> No. The total PAN length is unchanged. Only the split</em> between issuer-identifier and account-identifier moved — issuer up by two digits, account down by two.</p> Is it “BIN” or “IIN”?</h3> Same thing. “BIN” is the everyday industry word; “IIN” is the formal ISO term. Expect to see both, often in the same document.</p> Can I still do a 6-digit lookup?</h3> You can, and for many ranges it’s still fine — but it’s no longer guaranteed</em> to identify a single issuer. Treat 6-digit results as approximate and prefer 8 when you have them.</p> Where do I get 8-digit BIN data?</h3> A maintained BIN/IIN database that carries 8-digit granularity. The free binlist.net</a> and the commercial iinlist.com exist precisely for this.</p> Summary</h2> The issuer identifier on a card went from 6 to 8 digits</strong> (networks: support required by ~April 2022).</li> Total card-number length is unchanged; the account portion shrank by two digits.</li> 6-digit BIN lookups are now ambiguous</strong> — capture and match on 8 digits where you can, and flag 6-digit results as low-confidence.</li> </ul> Find which process is using a port on Linux (ss, lsof, fuser) — 2026 2026-06-05T00:00:00+00:00 TL;DR —</strong> sudo ss -ltnp \| grep :8080</code> shows the process listening on port 8080. Then kill <pid></code>. ss</code> is the modern replacement for the deprecated netstat</code>; lsof -i :8080</code> and fuser 8080/tcp</code> do the same job.</p> ss — the modern way</h2> ss</code> (from iproute2</code>) ships on every current distro and replaced netstat</code>. To see what’s listening</strong>:</p> sudo ss -ltnp </code></pre> -l</code></strong> listening sockets</li> -t</code></strong> TCP (use -u</code> for UDP)</li> -n</code></strong> numeric — don’t resolve ports to names (faster, clearer)</li> -p</code></strong> show the p</strong>rocess (needs root to see other users’ processes)</li> </ul> Filter to one port with ss</code>’s own expression (no grep needed):</p> sudo ss -ltnp 'sport = :8080' </code></pre> State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 511 0.0.0.0:8080 0.0.0.0: users:(("node",pid=4123,fd=18)) </code></pre> There’s your PID: 4123</code>.</p> lsof — the alternative</h2> sudo lsof -i :8080 # anything using port 8080 sudo lsof -iTCP:8080 -sTCP:LISTEN # only the listener </code></pre> lsof</code> prints the command, PID, and user per line. It isn’t installed everywhere by default (sudo apt install lsof</code>), but it’s the most readable for “who has this port and</em> in what state”.</p> fuser — the quick one</h2> sudo fuser 8080/tcp </code></pre> Prints just the PID(s). It can even kill in one shot:</p> sudo fuser -k 8080/tcp # send SIGKILL to whatever holds 8080/tcp </code></pre> Convenient, but blunt — it’ll kill -9</code> without asking, so know what you’re terminating first.</p> netstat — only if you’re stuck on an old box</h2> The classic netstat -tulpn</code> still works where it’s installed, but netstat</code> is deprecated and missing from minimal modern images. Prefer ss</code>; the flags are nearly identical.</p> Free the port</h2> Once you have the PID, stop it gracefully first, then escalate only if it ignores you:</p> kill 4123 # SIGTERM — lets it shut down cleanly kill -9 4123 # SIGKILL — last resort, no cleanup </code></pre> If it’s a managed service, stop it properly so it doesn’t just respawn:</p> sudo systemctl stop myapp </code></pre> Gotchas</h2> No process shown?</strong> You’re not root. The -p</code>/-i</code> process columns are empty for sockets you don’t own — re-run with sudo</code>.</li> Port still “in use” after the process died.</strong> A closed TCP socket lingers in TIME_WAIT</code> for a couple of minutes. Either wait, or set SO_REUSEADDR</code> in your server (most frameworks have a “reuse address” flag).</li> It came back immediately.</strong> A supervisor (systemd, Docker, pm2) restarted it. Stop the supervisor unit, not the child PID.</li> IPv6 vs IPv4.</strong> 0.0.0.0:8080</code> is IPv4; [::]:8080</code> is IPv6. A process can hold both — ss -ltnp</code> lists each separately.</li> </ul> FAQ</h2> How do I see established connections, not just listeners?</h3> Drop -l</code>: sudo ss -tnp</code> shows active connections. Add state established</code> to filter.</p> What’s using a UDP port?</h3> Swap -t</code> for -u</code>: sudo ss -lunp 'sport = :53'</code> (e.g. to find what’s on DNS).</p> One-liner to kill whatever is on a port?</h3> sudo fuser -k 8080/tcp</code>, or sudo kill $(sudo lsof -t -i:8080)</code>. Use with care.</p> Summary</h2> Find it: sudo ss -ltnp 'sport = :8080'</code> (modern), sudo lsof -i :8080</code>, or sudo fuser 8080/tcp</code>.</li> Free it: kill <pid></code> first, kill -9</code> only if needed, or stop the systemd unit.</li> ss</code> replaces netstat</code> — same idea, fewer surprises on modern systems.</li> </ul> Local speech-to-text with whisper.cpp — a self-hosted Google Speech API alternative (2026) 2026-06-04T00:00:00+00:00 TL;DR —</strong> whisper.cpp</code> runs OpenAI’s Whisper speech-to-text models locally. Build it, download a model, convert your audio to 16 kHz mono WAV with ffmpeg</code>, and run whisper-cli -m models/ggml-base.en.bin -f audio.wav</code>. No API key, no upload, no per-minute charge.</p> This blog has a history of speech-to-text experiments</a> — the old ones leaned on the Google Speech API. The local-model story is dramatically better now: same quality tier, zero cloud dependency.</p> </blockquote> Why local</h2> A hosted speech API means keys, per-minute billing, and shipping (often sensitive) audio to a third party. whisper.cpp</code> is a small, dependency-light C/C++ port of Whisper that runs the same models offline — on CPU, or accelerated with Metal (Mac) / CUDA (NVIDIA). For batch transcription, private recordings, or just avoiding a metered API, it’s the obvious default in 2026.</p> Build it</h2> git clone https://github.com/ggml-org/whisper.cpp cd whisper.cpp cmake -B build cmake --build build -j --config Release </code></pre> The CLI lands at build/bin/whisper-cli</code>. (Older checkouts called this binary ./main</code> — if a guide references main</code>, it’s the same tool under the previous name.)</p> On a Mac, Metal acceleration is on by default. For an NVIDIA GPU, configure with CUDA:</p> cmake -B build -DGGML_CUDA=1 cmake --build build -j --config Release </code></pre> Get a model</h2> Models are GGML/GGUF files you download once. The helper script fetches them into models/</code>:</p> sh ./models/download-ggml-model.sh base.en </code></pre> Pick the size for your accuracy/speed trade-off:</p> tiny.en</code> / base.en</code></strong> — fast, fine for clean English; great on a laptop CPU.</li> small.en</code></strong> — a noticeable accuracy step up, still quick.</li> medium</code></strong> — strong, multilingual.</li> large-v3</code></strong> — best quality, wants a GPU and a few GB of RAM.</li> </ul> Drop the .en</code> suffix for the multilingual variants. Quantized builds (e.g. base.en-q5_0</code>) cut memory with minimal quality loss.</p> Convert your audio</h2> Whisper expects 16 kHz mono PCM WAV</strong>. Convert anything to that with ffmpeg</code>:</p> ffmpeg -i recording.mp3 -ar 16000 -ac 1 -c:a pcm_s16le recording.wav </code></pre> -ar 16000</code> — 16 kHz sample rate</li> -ac 1</code> — mono</li> -c:a pcm_s16le</code> — 16-bit PCM</li> </ul> Transcribe</h2> ./build/bin/whisper-cli -m models/ggml-base.en.bin -f recording.wav </code></pre> It prints the transcript with timestamps. Write it to files instead:</p> ./build/bin/whisper-cli -m models/ggml-base.en.bin -f recording.wav \ -otxt -osrt -ovtt -oj </code></pre> -otxt</code> plain text · -osrt</code> SRT subtitles · -ovtt</code> WebVTT · -oj</code> JSON (with word timing).</li> </ul> For non-English audio, use a multilingual model and set the language (or let it auto-detect):</p> ./build/bin/whisper-cli -m models/ggml-medium.bin -l da -f optagelse.wav # -l auto to detect automatically; add --translate to render English </code></pre> Speed notes</h2> tiny</code>/base</code> transcribe faster than real time on a modern laptop CPU. large-v3</code> wants a GPU to be comfortable.</li> Long file? Whisper chunks internally, but you can pre-split with ffmpeg -f segment</code> for parallelism across cores.</li> --threads N</code> tunes CPU usage; Metal/CUDA builds offload the heavy matmuls automatically.</li> </ul> FAQ</h2> Is this the same model as OpenAI’s Whisper?</h3> Yes — whisper.cpp</code> runs the released Whisper weights (converted to GGML/GGUF). The output quality matches the corresponding model size; only the runtime differs.</p> Do I need a GPU?</h3> No. tiny</code>/base</code>/small</code> are perfectly usable on CPU. A GPU mainly helps with medium</code>/large</code> and long batches.</p> How accurate is it versus a cloud speech API?</h3> For clean audio, small.en</code> and up is competitive with the major hosted APIs, and large-v3</code> generally beats them — with the bonus that nothing leaves your machine.</p> Can it do live/streaming transcription?</h3> There’s a stream</code> example in the repo that does near-real-time from a microphone. It’s rougher than batch mode but works for live captions.</p> Summary</h2> Build whisper.cpp</code>, download a model with download-ggml-model.sh</code>.</li> Convert audio to 16 kHz mono WAV with ffmpeg</code>.</li> whisper-cli -m models/ggml-base.en.bin -f audio.wav</code> — local, key-free transcription.</li> Scale the model size to your hardware; use -l</code>/--translate</code> for other languages.</li> </ul> Five ways to get b-roll from one ride — all on a local GPU 2026-06-02T00:00:00+00:00 TL;DR —</strong> B-roll is the cutaway footage that lets an edit breathe, and onboard POV footage from a single camera has exactly none of it. I took one ATV ride and tried five</strong> ways to manufacture b-roll from it: (1) auto-mine</strong> the best real frames with OpenCV, (2) generate stills</strong> and seed them from real frames with SDXL-Turbo → RealVisXL img2img</strong>, (3) fake a cinematic camera move with Depth-Anything-V2</strong> 2.5D parallax, (4) generate actual motion</em> with Stable Video Diffusion</strong>, and (5) make a slow-motion</strong> cut of the real footage with optical-flow interpolation. Everything ran locally on a 12 GB RTX 4070 Ti. They’re complementary — here’s the comparison and the traps.</p> The problem</h2> Onboard footage — a GoPro/DJI on the handlebars of a go-kart or an ATV — is one continuous first-person shot. It’s great for the action, but an edit needs cutaways</em>: the establishing shot, the scenery, the slow detail that gives the viewer a breath between the intense bits. With one camera and no B-cam, you have none. So: can you manufacture believable b-roll after the fact, locally, for free?</p> I tried five approaches on a single 11-minute ATV tour through Nordic forest and gravel trails. Each produces a short graded reel; the interesting part is the trade-offs.</p> 1. Auto-mine the real footage (OpenCV)</h2> The cheapest b-roll is the b-roll you already shot but didn’t notice. A small OpenCV pass samples ~1,400 frames across the ride and scores each for sharpness</strong> (variance of the Laplacian), colourfulness</strong> (the Hasler–Süsstrunk metric), exposure</strong> (distance from a mid-tone target) and motion-stability</strong> (inter-frame difference — low is good for a stable cutaway). Non-maximum suppression then spreads the picks out so you don’t get eight near-identical frames from the same 20 seconds.</p> score = 1.1z(sharp) + 1.0z(colourful) + 0.8z(exposure) - 0.9shake - 6.0clipping </code></pre> It’s not glamorous, but it’s instant, free, and 100% authentic. The output is genuinely your ride — just the most b-roll-worthy three seconds you forgot you filmed.</p> 2. Generative stills, matched to the real ride</h2> This is where it got interesting — and where it first went wrong.</p> Attempt one: pure text-to-image.</strong> SDXL-Turbo with prompts like “cinematic misty forest at golden hour”</em> produced beautiful images that looked nothing like the actual ride. Wrong light (sunset vs. the real overcast), no quad in frame, no POV. Gorgeous stock footage for a</em> forest, not this</em> one.</p> Attempt two: img2img, seeded from real frames.</strong> Feeding a real frame in as the init image at moderate denoising strength keeps the real composition — the black quad’s handlebars and mirrors in the foreground, the grass-and-dirt two-track, the overcast palette — and regenerates the detail. Now it intercuts with the real footage. But SDXL-Turbo</strong> at strength ≈0.5 still melted</em>: it hallucinated extra gauges onto the dashboard and warped the handlebars. The classic “AI look.”</p> Attempt three: better models, lower strength.</strong> I compared three less-melty methods on the same frames:</p> </p> SDXL-base, low strength (0.30), 30 steps</strong> — faithful, no melt, but a touch soft.</li> ControlNet-Canny + SDXL</strong> — locks the real edges so nothing warps, but recomposed the scene greener and more stylised than the source.</li> RealVisXL</strong> (a photoreal SDXL fine-tune), img2img — the winner: sharp, photoreal, keeps the real POV and palette, no melt.</li> </ul> </p> The lesson: for footage-matching, the base model</em> and denoising strength</em> matter far more than the prompt. A photoreal checkpoint at low strength beats a flashy distilled model every time.</p> 3. AI Ken Burns — depth parallax</h2> A still doesn’t have to stay still. Depth-Anything-V2</strong> estimates a depth map for a frame in well under a second; with depth in hand you can render a 2.5D camera move where near pixels shift more than far ones, plus a gentle push toward the trail’s vanishing point. It reads like riding forward.</p> </p> The whole render is a backward cv2.remap</code> with depth-weighted displacement, so it’s hole-free and fast. One catch worth writing down: OpenCV’s remap</code> wants float32</code> maps, and a stray Python scalar in the arithmetic silently upcasts them to float64</code>, at which point remap</code> asserts. Cast the maps back to float32</code> explicitly.</p> This is the best value-for-effort of the synthetic options: real content, real-looking motion, a tiny model. The only limit is that large pushes start to reveal warping at depth discontinuities — keep the move subtle.</p> 4. Generative video — Stable Video Diffusion</h2> If you want motion a static frame genuinely cannot</em> fake, Stable Video Diffusion</strong> (image-to-video) animates a still into real movement — the camera drifts and pushes through the scene, parallax and all, invented by the model rather than warped geometrically.</p> </p> Seeding SVD from the RealVisXL stills gives generated motion that still looks like the ride. The honest caveats: clips are short (~2–3 seconds at 25 frames), the motion is only loosely controllable (you nudge it with a “motion bucket”, not a path), and there’s mild edge warping. It’s also the heaviest thing here — the model is ~9 GB and, on a 12 GB card, only fits with CPU-offload, UNet forward-chunking and a small VAE decode chunk:</p> pipe.enable_model_cpu_offload() pipe.unet.enable_forward_chunking() frames = pipe(image, num_frames=25, decode_chunk_size=2, motion_bucket_id=110, noise_aug_strength=0.04).frames[0] </code></pre> 5. Cinematic slow-motion — real footage, no AI</h2> The fifth option uses no generative model at all. Take the auto-mined moments, slow them to 50% with motion-compensated optical-flow interpolation</strong> (so the slow-mo is smooth, not stuttery duplicated frames), stabilise lightly, and apply a filmic grade. ffmpeg does it in one filter chain:</p> minterpolate=mi_mode=mci:mc_mode=aobmc:me_mode=bidir:vsbmc=1:fps=60,setpts=2.0PTS </code></pre> It’s 100% real, looks premium, and is the most “broadcast” of the lot. Interpolation can smear very fast edges, but on scenic cutaways it’s clean.</p> Which one wins?</h2> None — they’re complementary, and a real edit blends several:</p> Method</th> Authenticity</th> Control</th> Cost</th> Best for</th></tr></thead> 1 · Auto-mine (CV)</td> Real</td> Limited to what you shot</td> Instant</td> Authentic cutaways, free</td></tr> 2 · Generative stills (RealVisXL)</td> Synthetic</td> High (any scene)</td> Medium (GPU)</td> Shots you never filmed</td></tr> 3 · Depth parallax</td> Real + fake motion</td> Motion only</td> Cheap</td> Bringing a great frame alive</td></tr> 4 · SVD video</td> Synthetic</td> Loose motion</td> Heaviest (~9 GB)</td> Living motion with no footage</td></tr> 5 · Slow-mo (real)</td> 100% real</td> Speed/grade</td> Medium</td> A premium cut of real moments</td></tr> </tbody></table> If I had to ship one b-roll bed for this kind of footage, it’d be slow-mo (5) for the authentic premium feel</strong>, with depth parallax (3)</strong> to add motion to standout frames, and RealVisXL stills (2)</strong> only where I need an establishing shot that was never possible to film.</p> Stack</h2> GPU:</strong> one RTX 4070 Ti, 12 GB</strong>. Everything below fits.</li> Diffusion:</strong> diffusers</code> 0.38 — SDXL-base, RealVisXL V4.0</strong>, ControlNet-Canny-SDXL, Stable Video Diffusion XT</strong>.</li> Depth:</strong> transformers</code> + Depth-Anything-V2-Small</strong>.</li> CV / assembly:</strong> OpenCV, NumPy, and ffmpeg</strong> (minterpolate</code>, deshake</code>, AV1 NVENC, AVIF stills).</li> A couple of traps worth keeping: a distro Python marked PEP 668 externally-managed</strong> will silently</em> refuse pip install</code> — use a real virtualenv. And pgrep -f build.sh</code> happily matches the watcher command</em> that contains that string, so don’t trust it to tell you a render finished; check for a live ffmpeg</code> instead.</li> </ul> Why it exists</h2> This started as “the onboard clips need cutaways and I have one camera.” The honest answer turned out to be that you don’t need a second camera — you need to find</em> the b-roll you already shot (1, 5) and fabricate</em> the rest with the smallest model that does the job (3 before 2 before 4). The flashiest option (generative video) is the one I’d reach for last. The least flashy (scoring frames with a Laplacian) is the one I’d reach for first.</p> All local, all on a card that costs less than a weekend of cloud GPU. Not interesting until you need it — and then it’s exactly what you need.</p> Stitching drone panoramas: OpenCV vs Hugin, benchmarked 2026-05-31T00:00:00+00:00 TL;DR —</strong> I had a folder of 63 DJI Phantom 4 Pro frames shot over Randers and wanted panoramas out of them. I stitched the same sweeps two ways: OpenCV’s Stitcher</code></strong> (fully automatic, spherical) and the Hugin command-line pipeline</strong> (cpfind</code> → autooptimiser</code> → nona</code> → enblend</code>). OpenCV is fast (a few seconds) and keeps the widest field of view, but the horizon comes out wavy, the borders are ragged, and exposure seams are visible. Hugin takes ~30 s per panorama but gives a straight horizon, seamless multi-band blend, and a clean rectangular crop</strong>. For anything you’d print or publish, Hugin wins. Full commands and a benchmark table below.</p> The starting point</h2> A folder, 63 files, DJI_0029.jpeg</code> through DJI_0091.jpeg</code>, ~15 MB each, 5464 × 3070 px. No flight log, no project file, and — as I’d find out — most of the useful metadata stripped. Just JPEGs and a stray result.jpg</code> from someone’s earlier attempt.</p> First job: figure out what these photos actually are</em> before deciding how to stitch them. Are they a nadir mapping grid? A single rotational panorama? Several separate sweeps? You stitch each of those differently.</p> Reverse-engineering the capture from metadata</h2> No exiftool</code> on the box, so:</p> sudo apt-get install -y libimage-exiftool-perl imagemagick </code></pre> DJI normally writes gimbal yaw/pitch/roll into an XMP namespace, which would tell me exactly how the camera was pointing for each frame. Here it had been stripped — the files had clearly been re-exported at some point (which also explains that root-owned result.jpg</code>). What survived was GPS and timestamps:</p> exiftool -n -T -FileName -GPSLatitude -GPSLongitude -GPSAltitude \ -SubSecDateTimeOriginal DJI_.jpeg </code></pre> Two things fell out immediately.</p> There were two sessions, 90 minutes apart:</strong></p> 0029</code>–0054</code>, shot 09:01–09:15</li> 0055</code>–0091</code>, shot 10:31–10:36</li> </ul> The second session was a stack of horizontal sweeps at rising altitude.</strong> The GPS position barely moved while the altitude climbed in clear bands — 169 m, then 221 m, then 240 m, then 269 m. That’s the signature of a drone hovering on the spot and panning the camera across the horizon at each height. Each altitude band is one panorama.</p> A quick contact sheet confirmed it:</p> ls DJI_.jpeg \| sed 's/.jpeg//' \| xargs -P4 -I{} \ convert {}.jpeg -resize 260x -gravity South -background black \ -splice 0x16 -pointsize 13 -fill yellow -annotate +0+1 '{}' /tmp/thumbs/{}.png montage /tmp/thumbs/DJI_00{55..91}.png -tile 6x -geometry +3+3 /tmp/sheet.png </code></pre> Session one turned out to be mixed — top-down shots of a single property at varying heights (a vertical zoom sequence, not a panorama) plus some oblique neighbourhood passes. So I focused the panoramas on session two’s sweeps, which is what the drone was clearly there to capture.</p> The groups I settled on:</p> Group</th> Frames</th> Altitude</th> Content</th></tr></thead> A</td> 0055–0065</td> ~169 m</td> Residential, low pan</td></tr> B</td> 0066–0076</td> ~221 m</td> Town</td></tr> C+D</td> 0077–0091</td> 240–269 m</td> High skyline</td></tr> </tbody></table> Technique 1 — OpenCV Stitcher</h2> The path of least resistance. OpenCV ships a high-level Stitcher</code> that does feature detection, matching, bundle adjustment, warping, and blending in one call.</p> pip install opencv-contrib-python numpy </code></pre> import cv2, glob imgs = [cv2.imread(f) for f in sorted(glob.glob("group_A/.jpg"))] stitcher = cv2.Stitcher_create(cv2.Stitcher_PANORAMA) # spherical model status, pano = stitcher.stitch(imgs) if status == cv2.Stitcher_OK: cv2.imwrite("A_opencv.jpg", pano) </code></pre> Two modes matter:</p> PANORAMA</code></strong> assumes the camera rotated about its optical centre (spherical warp). Correct for these hover-and-pan sweeps.</li> SCANS</code></strong> assumes an affine/translational model (flatbed scans, nadir mapping). I tried it for completeness; it’s the wrong model here and collapsed most sweeps down to two or three frames. Don’t use it for rotational aerials.</li> </ul> I ran everything on a 2400 px working set first — full-res stitching is slow to iterate on, and you want to see whether a group connects before you commit minutes to it.</p> Verdict on OpenCV:</strong> it just works, with zero parameters, in seconds. Group A — eleven frames — stitched into a 10433 × 1595 panorama in about 5 seconds. The catch is the output: a wavy horizon</strong>, ragged torn edges</strong> you have to crop by hand, and faint exposure seams</strong> where frames meet. Fine for a quick look; not something you’d print.</p> Technique 2 — the Hugin pipeline</h2> Hugin</a> is the open-source panorama tool, and crucially its whole engine is scriptable from the command line — no GUI needed.</p> sudo apt-get install -y hugin-tools enblend enfuse </code></pre> The pipeline, stage by stage:</p> pto_gen -o p.pto DJI_0055.jpeg ... DJI_0065.jpeg # 1. project from EXIF cpfind --multirow -o p.pto p.pto # 2. find control points cpclean -o p.pto p.pto # 3. drop bad matches autooptimiser -a -m -l -s -o p.pto p.pto # 4. optimise + level horizon pano_modify --canvas=AUTO --crop=AUTO --projection=2 \ -o p.pto p.pto # 5. cylindrical + auto-crop nona -m TIFF_m -z LZW -o remap p.pto # 6. remap each frame enblend -o pano.tif remap.tif # 7. multi-band blend </code></pre> What each stage buys you over the OpenCV one-liner:</p> cpfind --multirow</code></strong> finds proper control points across the whole set — it reported 250, 302, and 718 points for groups A, B and C+D respectively.</li> autooptimiser -l -s</code></strong> levels the horizon and straightens the panorama. This is the single biggest visible win: the wave disappears.</li> --projection=2</code></strong> is cylindrical, which keeps the horizon a straight horizontal line — exactly what you want for a wide aerial sweep.</li> --crop=AUTO</code></strong> trims to the largest clean rectangle, so no manual cropping.</li> enblend</code></strong> does multi-band (Burt–Adelson) blending, which hides the exposure differences between frames that OpenCV left visible.</li> </ul> Same group, two pipelines, stacked — OpenCV on top, Hugin below:</p> </p> The difference isn’t subtle.</p> The benchmark</h2> Same input groups, both pipelines. OpenCV numbers are the 2400 px working set; Hugin numbers are the final full-resolution 5464 px runs.</p> Group</th> Imgs</th> Tool</th> Result</th> Time</th> Horizon</th> Blend</th> Crop</th></tr></thead> A · residential</td> 11</td> OpenCV PANORAMA</td> 10433 × 1595</td> 5 s</td> wavy</td> seams</td> ragged</td></tr> A · residential</td> 11</td> Hugin + enblend</strong></td> 11581 × 1827</td> 31 s</td> straight</strong></td> seamless</strong></td> clean</strong></td></tr> B · town</td> 11</td> OpenCV PANORAMA</td> 10295 × 1838</td> 11 s</td> wavy</td> seams</td> ragged</td></tr> B · town</td> 11</td> Hugin + enblend</strong></td> 8190 × 2547</td> 30 s</td> straight</strong></td> seamless</strong></td> clean</strong></td></tr> C+D · skyline</td> 15</td> OpenCV PANORAMA</td> 8660 × 1975</td> 2 s</td> wavy</td> seams</td> ragged</td></tr> C+D · skyline</td> 15</td> Hugin + enblend</strong></td> 22469 × 2391</td> 60 s</td> straight</strong></td> seamless</strong></td> clean</strong></td></tr> </tbody></table> OpenCV is 3–10× faster and tends to keep a wider field of view (it warps and keeps the torn edges rather than cropping them). Hugin is slower but wins on every quality axis that matters for a finished image.</p> Going full resolution</h2> Once Hugin was the clear winner I re-ran it on the original 5464 px frames. The pipeline is identical — just point pto_gen</code> at the original JPEGs instead of the downscaled set. cpfind</code> and enblend</code> are the slow stages at full res, but it still came in around 30 s per panorama, a minute for the 15-frame skyline.</p> The finished panoramas:</p> The high skyline — fifteen frames, 22469 × 2391, a near-180° sweep across the whole town:</strong></p> </p> The residential sweep at 169 m:</strong></p> </p> The town at 221 m:</strong></p> </p> At 22469 px wide the skyline is comfortably large-format printable.</p> FAQ</h2> Why did the metadata matter so much — why not just throw all 63 into the stitcher?</h3> You can, and OpenCV will try to find connected components. But the files were two unrelated sessions plus a mix of nadir and oblique frames. Feeding the lot in risks the optimiser bridging frames that shouldn’t connect, or wasting minutes failing to. Five minutes with exiftool</code> to group the frames first saved a lot of guessing — and told me which</em> groups were even panoramas.</p> Why not just use the drone’s built-in panorama mode?</h3> These weren’t shot as in-camera panoramas — they’re individual frames from manual sweeps, and the on-board stitch (if it ran at all) is the low-res result.jpg</code> I found in the folder. Stitching from the original full-res frames yields far more detail than the in-camera JPEG.</p> What about PTGui / Lightroom / Microsoft ICE?</h3> All capable. PTGui is essentially commercial Hugin and excellent. Lightroom’s Photo Merge is convenient if you’re already in it. Microsoft ICE was great but is discontinued. I wanted a scriptable, free, Linux-native pipeline I could run headless over a folder — that’s Hugin.</p> Cylindrical, spherical, or rectilinear?</h3> For a wide horizontal sweep, cylindrical</strong> (--projection=2</code>) keeps the horizon straight and handles >120° without the extreme stretching rectilinear gives at the edges. Spherical (what OpenCV’s PANORAMA</code> uses) is fine too but tends to bow the horizon unless the pitch is well estimated — which is harder here because the gimbal angles were stripped.</p> Can this run unattended over a whole folder?</h3> Yes — the entire Hugin path is CLI, so it drops straight into a shell script or a Makefile</code>. Group the frames (by timestamp/altitude, or just let cpfind</code> find connected components), then loop the seven commands per group. That’s the real argument for Hugin over a GUI tool here.</p> Verdict</h2> If you want a panorama now</em> and don’t care about a wavy horizon or trimming edges yourself, OpenCV’s Stitcher</code> is a five-second one-liner and genuinely impressive for the effort.</p> For anything you’ll keep — print, publish, hang on a wall — the Hugin command-line pipeline</strong> is worth the extra half-minute. A straight horizon, a seamless blend, and an automatic clean crop are exactly the things that separate a snapshot from a finished panorama, and Hugin gets all three for free. It’s now my default for stitching anything off the drone.</p> The whole thing — install to finished full-res panoramas — was about an hour, most of it spent understanding the photos rather than stitching them. Which is usually how these go.</p> bchunk — convert .bin/.cue images to .iso and .wav on Linux and macOS 2026-04-22T00:00:00+00:00 TL;DR —</strong> bchunk</code></strong> — sometimes called binchunker</code></strong> — is a small, old, Unix command-line tool that takes a .bin</code>/.cue</code> pair (a raw CD image with a cue sheet) and splits it into a proper .iso</code> file for the data track</strong> and one .wav</code> file per audio track</strong>. It’s the right tool when a download or archive gave you game.bin</code> + game.cue</code> and you actually want to mount the data track</strong> or re-burn the audio tracks</strong>. Install with apt install bchunk</code> on Debian/Ubuntu, brew install bchunk</code> on macOS, or build from source on anything else. Usage is bchunk [options] image.bin image.cue basename</code> — you get basename01.iso</code>, basename02.wav</code>, basename03.wav</code>, and so on.</p> What .bin/.cue is, and why you’d want to split it</h2> A .bin</code>/.cue</code> pair is a raw, bit-accurate CD image</strong> plus a plain-text sheet that describes the track layout. The .bin</code> contains every sector of the CD back-to-back — including data tracks (Mode 1 or Mode 2), audio tracks (raw Red Book PCM, 2352 bytes per sector, no filesystem), and the gaps between them. The .cue</code> tells you where each track starts and what type it is.</p> This format is the standard output of CD-ripping tools like cdrdao and of old game-preservation scrapes, because it preserves everything</em> — pregaps, CD-TEXT, mixed-mode CDs, CD-DA audio. That’s also why you can’t just rename game.bin</code> to game.iso</code> and mount it: a mixed-mode CD has non-filesystem sectors</strong> at the beginning, audio tracks that aren’t a filesystem at all, and per-sector headers that ISO expects stripped.</p> bchunk</code> does the conversion properly:</p> Data tracks</strong> become ISO 9660 files (.iso</code>) — the 2352-byte CD sectors are trimmed to 2048-byte ISO sectors, headers discarded.</li> Audio tracks</strong> become 16-bit stereo 44.1 kHz .wav</code> files, each with a proper WAV header.</li> </ul> After that you can mount -o loop</code> the .iso</code>, play the .wav</code>s, or feed them to a burner.</p> Installing</h2> Debian / Ubuntu / Mint</h3> sudo apt install bchunk </code></pre> macOS (Homebrew)</h3> brew install bchunk </code></pre> Arch / Manjaro</h3> sudo pacman -S bchunk # or from AUR: yay -S bchunk </code></pre> Fedora / RHEL / CentOS</h3> bchunk</code> isn’t in the default repos; get it from RPMFusion or build from source:</p> git clone https://github.com/hessu/bchunk.git cd bchunk make sudo cp bchunk /usr/local/bin/ </code></pre> Windows</h3> Use WSL and apt install bchunk</code>. There’s an old native port but WSL is easier.</p> Basic usage</h2> bchunk game.bin game.cue game </code></pre> Output:</p> game01.iso # data track, mountable as ISO 9660 game02.wav # audio track 1 game03.wav # audio track 2 ... </code></pre> The basename</code> (game</code> in the example) is the prefix for every output file. Track numbers start at 01</code>.</p> Useful options</h2> bchunk</code> has a small, stable set of flags — most of them are there to handle specific CD quirks.</p> -v</code></strong> — verbose. Prints each track as it’s processed. Use this the first time you run it to confirm you’re getting the track layout you expect.</li> -w</code></strong> — write .wav</code> files (default). Explicit form.</li> -r</code></strong> — raw audio output instead of .wav</code>. Useful if you’re piping into sox</code> or ffmpeg</code> and don’t want a second header-stripping step.</li> -p</code></strong> — Psx/PlayStation mode</strong>. Treats Mode 2 sectors more loosely — needed for many PlayStation CD images where the cue sheet is imprecise.</li> -s</code></strong> — swap byte order on audio tracks. Needed if the .bin</code> was produced by a ripper that wrote little-endian audio where bchunk</code> expects big-endian (or vice versa). Symptom: output .wav</code> sounds like white noise.</li> -W</code></strong> — write .wav</code> with a verified (rather than computed) header size. Rarely needed.</li> -E</code></strong> — use the exact track boundaries from the cue sheet rather than probing. Use this if audio tracks sound clipped at the beginning or end.</li> </ul> Mounting the resulting .iso</h2> On Linux:</p> sudo mkdir /mnt/cd sudo mount -o loop game01.iso /mnt/cd ls /mnt/cd </code></pre> On macOS:</p> hdiutil attach game01.iso </code></pre> Common gotchas</h2> “Illegal or unsupported track type” or empty output</h3> Your cue sheet is malformed or references a .bin</code> size that doesn’t match. Open the .cue</code> in a text editor — it’s plain text — and check:</p> The FILE "..."</code> line points at the right .bin</code> filename, case-sensitive.</li> TRACK</code> entries are numbered sequentially with types MODE1/2352</code>, MODE2/2352</code>, or AUDIO</code>.</li> Index entries (INDEX 00</code>, INDEX 01</code>) are MM:SS:FF, with FF being frames (0–74).</li> </ul> Audio tracks sound like static</h3> Byte order mismatch. Retry with -s</code>:</p> bchunk -s game.bin game.cue game </code></pre> Single .iso</code> is fine, but audio tracks are silent or truncated</h3> Try -E</code> to force cue-sheet-exact boundaries:</p> bchunk -E game.bin game.cue game </code></pre> PlayStation/PSX image won’t split cleanly</h3> Use -p</code>:</p> bchunk -p psx.bin psx.cue psx </code></pre> This is the most common complaint on forums — PSX cues are almost always Mode 2 and bchunk</code> without -p</code> is strict about them.</p> Multiple .bin</code> files referenced in the cue</h3> Some rippers produce one .bin</code> per track plus a combining cue sheet. bchunk</code> expects one .bin</code> for the whole disc. Concatenate them first with cat track01.bin track02.bin ... > combined.bin</code> and point a single-file cue at combined.bin</code>.</p> Alternatives worth knowing</h2> cdemu</code></strong> — user-space CD emulator for Linux. Can mount a .bin</code>/.cue</code> directly without splitting. Useful if you just want to read</em> the data track temporarily.</li> ecm-tools</code></strong> — different format (.ecm</code>), but same problem space. Worth knowing if you encounter it.</li> 7z</code> / p7zip</code></strong> — newer 7-Zip versions can list and extract ISO 9660 data tracks from a raw .bin</code>, but can’t recover audio as .wav</code>.</li> ffmpeg</code></strong> — if you want MP3 / FLAC / Opus instead of .wav</code>, pipe the raw output: bchunk -r game.bin game.cue game && ffmpeg -f s16be -ar 44100 -ac 2 -i game02.raw game02.flac</code>.</li> </ul> Why it’s still useful in 2026</h2> Optical-media imaging has been a solved problem for decades, but .bin</code>/.cue</code> is still the default output of cdrdao</code>, still what old archives are stored as, and still what shows up when someone hands you a CD backup that isn’t an ISO. bchunk</code> is a ~1,000-line C program, written in the late 1990s, that does one job correctly and has barely changed in twenty years. It’s in every major distribution, it compiles cleanly on modern systems, and it’s the right tool.</p> If you’re trying to recover data from an old CD image: start here.</p> binlist.net — how a Fuerteventura holiday side-project became iinlist.com 2026-04-22T00:00:00+00:00 TL;DR —</strong> binlist.net</a> is a free HTTP API</strong> that takes the first 6–8 digits of a credit card number (the BIN</strong> or IIN</strong>) and returns the issuing bank, country, card scheme (Visa, Mastercard, etc.), card type (debit/credit/prepaid), and category. I started it in August 2013 on a holiday in Fuerteventura</strong>, because I needed a BIN lookup for another project and everything that existed was either paywalled, stale, or behind a sketchy scraper. It was my first ever Go project</strong>, hit 100,000 queries/day</strong> within weeks, and crossed 1 million queries/day in 2015</strong>. It is still online, still free, still curl</code>-friendly. The commercial variant, iinlist.com</a>, is what I co-founded after binlist.net’s success; it’s the same idea with payment-industry-grade accuracy</strong>, 8-digit IIN support</strong> (mandated by ISO/IEC 7812 since 2022), ARDEF-backed ranges</strong>, and an SLA — built for banks, PSPs, fraud teams, and issuers who need to treat BIN data as production data.</p> BIN vs IIN — a one-paragraph primer</h2> The first six (historically) or eight (since 2017, mandatory 2022) digits of a card number are the Issuer Identification Number</strong> (IIN). The old name, still widely used, is Bank Identification Number</strong> (BIN). Given a BIN/IIN, you can determine:</p> Scheme / network</strong> — Visa, Mastercard, Amex, Discover, JCB, UnionPay, Diners.</li> Issuer</strong> — the bank or fintech that issued the card.</li> Country</strong> — country of the issuer, which is not necessarily the cardholder’s country but is a useful proxy for risk scoring, tax logic (EU/EEA VAT MOSS), and user experience (preferred language, local payment methods).</li> Type</strong> — debit, credit, prepaid, deferred debit, charge.</li> Category / product</strong> — Classic, Gold, Platinum, Business, Corporate, etc. Useful for acceptance cost routing (commercial cards cost more to accept).</li> </ul> All of this is “sensitive” in the sense that issuers don’t publish full BIN tables and card schemes consider them proprietary. In practice, BIN ranges leak constantly — every authorisation the scheme routes, every chargeback dispute — and there’s a whole cottage industry around keeping reasonably accurate BIN tables.</p> Why I built binlist.net on holiday</h2> Summer 2013. Playitas, southern Fuerteventura</strong> — the resort on the Atlantic side down by Gran Tarajal. Rented apartment, small balcony, Canary wind doing its thing. I had an idea for a side-project that needed to look up cards by BIN and I did not want to pay a payments vendor €200/month for it. The existing free options were:</p> Wikipedia’s IIN list</strong> — reasonably accurate for well-known schemes, woefully incomplete for niche issuers, updated by volunteers who don’t work in payments.</li> Pasted CSVs on forums</strong> — decent coverage for US issuers, always outdated.</li> Google Fusion Tables</strong> — deprecated by Google that same year.</li> Scrapers of merchant-bank lookup forms</strong> — ToS-violating, brittle.</li> </ul> What I wanted was curl http://example.com/40012345</code> returning clean JSON. So I built it.</p> The stack (then)</h3> This was my first ever Go project</strong>. I’d been reading about Go for a while and wanted a small, well-scoped excuse to try it; a single-endpoint JSON API over an in-memory BIN table was perfect. Ruby/Sinatra would have been faster for me to type, but I wanted to learn something, and the memory and latency characteristics of a Go binary turned out to be exactly what a free-tier public API needed.</p> Go</strong> — a single binary, net/http</code>, no framework. The whole server was a few hundred lines.</li> In-memory BIN range table</strong>, built at boot from a ~300 MB source file. Lookups were O(log n) over a sorted slice.</li> Deployed on a single Hetzner VM</strong> from day one (I briefly considered Heroku but Heroku’s free dyno memory limits didn’t fit a fully-loaded BIN table).</li> JSON + XML + CSV</strong> response formats, because 2013.</li> Data seed</strong> from a combination of public Wikipedia scrapes, the old “Mars Base” CSV from 2009, and a set of ranges I’d been accumulating at work.</li> </ul> Total build time on that balcony: a weekend — about half of which was me figuring out go build</code>, GOPATH</code> (Go modules didn’t exist yet), and how interfaces worked. I bought the domain on the Monday, deployed the binary, and tweeted about it.</p> Traffic curve</h3> Week 1:</strong> a few hundred queries/day, mostly me testing.</li> Month 1:</strong> ~100,000 queries/day</strong> after developers on Stack Overflow and a couple of e-commerce forums found it.</li> By early 2015:</strong> crossed 1 million queries/day</strong> sustained, with spikes above 2M during flash-sale events on merchants that called it on every checkout page-load.</li> </ul> Scaling to that point cost almost nothing because Go’s single-binary footprint meant a ~€5/month VPS handled the whole thing; the bottleneck for a long time was the NIC, not CPU or memory.</p> 13 years later</h3> binlist.net still runs. It has migrated infrastructure a few times — Hetzner VM → Hetzner fleet → a small fleet behind Cloudflare — and the data seed has been continuously updated, but the API surface (and most of the original Go code) is the same. Today it serves tens of millions of lookups per month</strong>, free, no API key required, with a soft rate limit on anonymous callers to keep it honest.</p> It has ~2,000 Google impressions/month</strong> for queries like “binlist”, “bin list bank identification number”, “list of bank identification numbers” — still picking up the long tail of developers who type the same question I typed into Google in 2013.</p> Why iinlist.com exists</h2> binlist.net’s data is good enough for “what country is this card from” decisions — risk scoring, currency presentation, analytics. It is not</strong> good enough for:</p> Acceptance-cost routing</strong> where you route commercial-card transactions through a different processor.</li> Interchange++ modelling</strong> where the margin difference between Classic and Platinum Mastercard is real money.</li> Scheme compliance</strong> — the ISO/IEC 7812 migration from 6-digit BINs to 8-digit IINs, mandated 2022, broke a lot of “I’ll just use the first six digits” logic.</li> Co-badged cards</strong> (e.g. Dankort + Visa Debit) where two networks both claim the card and the routing decision is business-critical.</li> ARDEF-grade accuracy</strong> — Visa’s Account Range Definition File is the source of truth; you really do want data derived from ARDEF for anything production-grade.</li> </ul> iinlist.com solves these, commercially. I co-founded it with a small team of people who know payments data professionally. It’s the product binlist.net is the free-tier advertisement for. Some of our customers are names you’d recognise; most are not. All of them eventually reach the same conclusion: BIN data that’s “mostly right” costs more in wrong decisions than accurate data costs in licence fees</strong>.</p> What iinlist.com is, specifically</h3> 8-digit IIN support</strong> across all schemes.</li> Daily updates</strong>, derived from ARDEF + scheme feeds + issuer announcements + internal verification.</li> Richer enrichment</strong>: card type, product category, issuing country, issuer branding, regulatory classifications (commercial vs consumer, prepaid flag, etc.).</li> SLA and support</strong>. You can file a ticket and it will actually reach a human.</li> On-prem / self-hosted option</strong> for customers whose compliance doesn’t allow “BIN lookup as a third-party API call in the authorisation path”.</li> Pricing</strong> that makes sense for both a scrappy fintech (monthly plan) and an established acquirer (annual, unlimited).</li> </ul> Can I just use binlist.net commercially?</h2> You can use binlist.net however you want; there’s no gate. But:</p> There’s no SLA, no uptime guarantee, and no contract. It’s a side project that happens to have stayed up for 13 years.</li> Rate limits on anonymous traffic will kick in at production volume. Buy a licence from iinlist.com and the problem is solved.</li> If your regulator asks where your BIN data comes from, “a free API my developer found” is not the answer you want to give.</li> </ul> For anything hobby, demo, or prototype: binlist.net is perfect. For anything where wrong BIN data becomes someone’s KPI: iinlist.com.</p> Using binlist.net today</h2> $ curl -sH "Accept-Version: 3" https://lookup.binlist.net/45717360 { "number": { "length": 16, "luhn": true }, "scheme": "visa", "type": "debit", "brand": "Visa/Dankort", "country": { "numeric": "208", "alpha2": "DK", "name": "Denmark", "emoji": "🇩🇰", "currency": "DKK", "latitude": 56, "longitude": 10 }, "bank": { "name": "Jyske Bank A/S", "url": "www.jyskebank.dk", "phone": "+4589893300", "city": "Silkeborg" } } </code></pre> Accept-Version: 3</code></strong> — pins to API v3.</li> Anonymous rate limit</strong> — documented on the site, plenty for casual use.</li> Zero warranties</strong> — if the response is wrong, submit a correction on the GitHub repo. For commercial guarantees, see iinlist.com.</li> </ul> FAQ</h2> Is BIN / IIN data regulated?</h3> BIN ranges themselves are not personal data under GDPR — a BIN identifies an issuer, not a person. Combining a BIN with a full card number is a different story and falls under PCI-DSS.</p> What changed with the 8-digit IIN migration?</h3> ISO/IEC 7812 formalised 8-digit IINs in 2017 with a hard migration deadline in April 2022 for the major networks. If your code still treats only the first six digits as the issuer identifier, you’re silently misrouting a growing share of traffic — modern Visa and Mastercard issuer ranges are defined at 8 digits.</p> Why not just look it up client-side?</h3> You can, with a static list in the browser. But you’ll accept a trade-off: freshness (the static list will be out of date within weeks) or bundle size (the current BIN table is megabytes uncompressed). A server-side API is the conventional answer.</p> Does binlist.net log the BINs I query?</h3> Aggregate analytics only — enough to detect abuse and rate-limit. Individual queries are not associated with a user. iinlist.com has a stricter no-logging posture for customers where that matters.</p> Is the source code open?</h3> The API surface of binlist.net is on GitHub, with contribution guidelines for data corrections. The data ingestion pipeline is not open-source; it relies on scheme feeds that require licences.</p> Are binlist.net and iinlist.com the same company?</h3> Separate projects, overlapping origins, same operator on my side. binlist.net is a personal free service; iinlist.com is a commercial company with co-founders and employees. The two are operationally independent but share institutional knowledge about BIN data that is not easy to accumulate from scratch.</p> Thirteen years in</h2> The thing I find most interesting about binlist.net is not the traffic — it’s the kind of questions</strong> developers are still typing into Google in 2026: “what is a bin list”, “bin number example”, “list of issuer identification numbers”. These are the exact queries I was typing in 2013 on that balcony in Playitas. Payments as an industry keeps adding layers, but the foundational questions don’t change.</p> If you’re sitting on a beach with a laptop and you have an itch for a side-project that scratches your own back, go build it — and while you’re at it, try the language you’ve been meaning to learn. Sometimes it turns out a lot of people have the same itch, and thirteen years later you have a useful thing to point them at and a working knowledge of Go.</p> My CM3588 project — a 4-NVMe ARM64 home NAS on 10 W idle 2026-04-22T00:00:00+00:00 TL;DR —</strong> The FriendlyElec CM3588 NAS Kit</a> is an RK3588-based compute module on a carrier board with four M.2 NVMe slots (PCIe 3.0 x1 each)</strong>, 2.5 GbE</strong>, 2× HDMI out</strong>, USB 3.0</strong>, and an 8- or 16-core ARMv8 CPU (4× Cortex-A76 + 4× Cortex-A55). Fully loaded with four NVMe drives it idles at about 10 W</strong>, peaks around 20 W under heavy I/O, and reads/writes an NVMe at roughly 1 GB/s (the bus limit, not the drive). My own unit runs Debian on the mainline kernel, with ZFS on root, four 2 TB NVMe drives in a raidz2</code> pool, Samba for LAN shares, and Tailscale for off-LAN access. It has replaced a tower PC running TrueNAS and cut NAS power draw by about 60 W.</p> Why this board</h2> I’d been running a tower PC as a home NAS for years: a second-hand desktop, six 3.5“ spinning disks, and a noisy fan. It worked, but it was using 70–80 W idle and sitting in a cupboard that needed active ventilation. The disks were loud enough that I’d moved them to the far corner of the house.</p> Three things I wanted from a replacement:</p> NVMe-only.</strong> Spinning disks are cheaper per terabyte but the noise, vibration, and heat aren’t worth it for a home NAS sized in the single-digit terabytes. 4× 2 TB NVMe is plenty.</li> ARM, for the power draw.</strong> An x86 board with 4× PCIe slots wired to NVMe would pull 30–40 W idle. ARM can do it in 10.</li> Mainline Linux, not a vendor fork.</strong> I want apt-get dist-upgrade</code> to work, zfs</code> to compile from DKMS against a current kernel, and no three-year-old vendor BSP.</li> </ol> The CM3588 NAS Kit hits all three.</p> Hardware</h2> SoC:</strong> Rockchip RK3588 (4× Cortex-A76 @ 2.4 GHz + 4× Cortex-A55 @ 1.8 GHz, Mali-G610 GPU, 6 TOPS NPU). ARMv8.2-A.</li> RAM:</strong> 8 GB LPDDR4X on the module I bought. 16 GB and 32 GB variants exist.</li> Storage:</strong> 64 GB eMMC on-module for OS + 4× M.2 Key-M 2280 slots, each PCIe Gen 3 x1</strong> (so ~1 GB/s per slot, not x4).</li> Network:</strong> 1× 2.5 GbE (Realtek RTL8125B).</li> USB:</strong> 2× USB 3.0 Type-A, 1× USB 3.0 Type-C (DisplayPort alt-mode), 1× USB 2.0.</li> Video:</strong> 2× HDMI out, 1× HDMI in</strong> (RK3588’s capture block).</li> Power:</strong> 12 V barrel jack. A 60 W brick is more than enough.</li> </ul> The board is small — roughly 10 × 10 cm — and passive over the SoC plus a small fan blowing across the NVMe drives. Mine sits flat on a shelf without a case.</p> NVMe compatibility caveat</h3> The one gotcha worth knowing: the CM3588 NAS Kit is not compatible with some WD Blue SN580 and WD Black SN850 drives</strong> — the linkup flaps at boot. I use Samsung 990 EVO and Crucial P3 Plus; both are fine. Check the FriendlyElec wiki compatibility list before buying NVMe drives.</p> OS and filesystem</h2> I run Debian 13 (trixie)</strong> with the mainline kernel</strong> — RK3588 support is good enough from 6.8 onwards for headless use. The FriendlyElec-provided Debian image works out of the box, but I reinstall on top of it to get a clean Debian rather than their BSP.</p> Root filesystem:</strong> ext4</code> on eMMC.</li> Data pool:</strong> zfs</code> raidz2</code> across the four NVMe drives. With 4× 2 TB, raidz2</code> gives ~3.5 TB usable with two-disk redundancy. Yes, raidz2</code> on four drives is conservative; it also means a double failure doesn’t eat the pool, and on NVMe the rebuild is fast enough that I don’t lose sleep.</li> ZFS module:</strong> DKMS against the running kernel. Rebuilds automatically on kernel upgrades. Has worked without manual intervention across three kernel bumps.</li> ARC tuning:</strong> Capped at 2 GB. This leaves headroom on an 8 GB system.</li> </ul> Throughput is bottlenecked by 2.5 GbE for network I/O (~280 MB/s sustained) long before ZFS or the NVMe drives break a sweat. Local operations on the pool hit around 2 GB/s aggregate sequential read.</p> Services</h2> Kept deliberately simple:</p> Samba</strong> for SMB shares to the Macs and Windows box on the LAN.</li> rsync + cron</strong> for nightly backups from three other machines.</li> ZFS snapshots</strong> every hour, retained for a week. zfs send</code> pipes the dataset weekly to an off-site B2 bucket via zfs-autobackup</code> + rclone.</li> Tailscale</strong> for off-LAN access. No port-forwarding, no dyndns, no VPN concentrator. SSH and Samba both ride the Tailscale interface when I’m away.</li> Cockpit</strong> for the occasional “why is the fan loud” dashboard moment.</li> </ul> That’s it. No Docker swarm, no Kubernetes, no dozen sidecar containers. The board does one job — serve files on the LAN and let me pull backups off-site — and it does it quietly.</p> Power and noise</h2> Idle</strong> (all four NVMe spun up, no traffic): ~10 W</strong> at the wall.</li> Busy</strong> (NVMe read saturating 2.5 GbE, ZFS ARC warm): ~18–20 W</strong>.</li> Peak</strong> (scrub across the whole pool, all cores hot): ~25 W</strong>.</li> </ul> Compared to the 70–80 W tower it replaced, the ROI on electricity alone is about 500 kWh/year</strong>, or roughly 1,500 kr/year</strong> at Danish residential rates. The board paid for itself in about a year.</p> Noise: effectively inaudible from more than a metre away. The fan is small and 80% of the time it’s barely spinning.</p> What didn’t work, or took effort</h2> Vendor kernel.</strong> The FriendlyElec-shipped kernel is FriendlyElec’s fork of 6.1 with RK-specific patches. It works for their turnkey NAS image, but DKMS ZFS builds are painful against it. Moving to mainline fixed this.</li> HDMI capture.</strong> The RK3588 has a hardware HDMI input block. In mainline it’s still experimental. I have a rough use case for it (pulling a signal from an old device for archival) but haven’t made it work end-to-end. Parked for now.</li> NPU.</strong> The 6 TOPS NPU is underused. Mainline has basic RKNPU support but for anything practical you still need FriendlyElec’s rknn-toolkit2</code>. Not a blocker for a NAS.</li> </ul> FAQ</h2> Why not x86?</h3> An x86 mini-PC with 4× NVMe is ~2× the idle power and ~2× the purchase price (once you include the case, PSU, and CPU). For a home NAS where the workload is “serve files” rather than “run 40 containers”, ARM wins.</p> Why not Raspberry Pi 5?</h3> The Pi 5 has one PCIe 2.0 x1 lane exposed via an HAT — you can bolt on an NVMe, but only one, and at ~500 MB/s ceiling. The CM3588 has four lanes at PCIe 3.0 wired directly. Different class of board.</p> Why not OpenMediaVault or TrueNAS?</h3> Both would work. I prefer plain Debian + Samba + ZFS because the upgrade path for Debian is well-known to me, and OMV/TrueNAS are a layer I’d have to re-learn. Your mileage will vary.</p> Why raidz2</code> on four drives and not mirror + mirror</code>?</h3> I considered it. mirror + mirror</code> gives you faster writes and easier expansion but only 4 TB usable from 4× 2 TB, same as raidz2</code>. With raidz2</code> any two drives can fail; with striped mirrors you can lose two drives, but only if they’re in different mirror pairs. On four drives the capacity is identical and raidz2</code> has the stronger failure tolerance.</p> Can it run Plex / Jellyfin?</h3> Yes, and the RK3588’s hardware H.265/VP9/AV1 decode block does the heavy lifting. Jellyfin with rkmpp</code> accelerated decoding handles 4K HEVC transcodes at about 3× realtime. I don’t run either on this box — my Plex lives elsewhere — but it’s viable.</p> Does it suspend?</h3> Not reliably. Leave it on; idle is 10 W anyway.</p> What about noise and heat in summer?</h3> Passive heatsink plus one small fan. In a Danish summer (20–25 °C ambient) it tops out around 55 °C die temp under a ZFS scrub. No throttling I’ve measured.</p> Verdict</h2> If you want a quiet, low-power, all-NVMe home NAS with enough PCIe to matter</strong> and you’re willing to spend an evening on Debian + ZFS, the CM3588 NAS Kit is the best option I’ve found. It’s not the cheapest — a second-hand Optiplex is cheaper upfront — but on three-year TCO including electricity it pays back clearly.</p> The RK3588 itself is a surprisingly capable SoC for homelab workloads. Once mainline kernel support landed, I stopped treating it as “an ARM curiosity” and started treating it as a default answer for small always-on servers.</p> Two years in, mine has been rebooted twice (once for a kernel upgrade, once because I moved the shelf). I’d buy it again.</p> fcrackzip — recover lost zip passwords on Linux, macOS, and Windows (2026) 2026-04-22T00:00:00+00:00 TL;DR —</strong> fcrackzip</code></strong> is a free, open-source command-line tool for recovering the password of an encrypted .zip</code> file. It supports brute-force</strong> (over a user-defined charset and length) and dictionary</strong> attacks, works on Linux/macOS/WSL, and is the right first tool when you need to recover a forgotten password on a zip you legitimately own. It is only fast against classic ZipCrypto</strong> encryption; for the newer AES-256</strong> zip profile, fcrackzip</code> will not work — you want zip2john</code> + hashcat</code> instead. Install with apt install fcrackzip</code> (Debian/Ubuntu), brew install fcrackzip</code> (macOS), or build from source.</p> This post walks through the practical cases. It assumes you have authorisation to recover the password</strong> — your own files, a client’s, a CTF. Don’t use it against zips you don’t own.</p> Install</h2> # Debian / Ubuntu / Mint / Kali sudo apt install fcrackzip # macOS (Homebrew) brew install fcrackzip # Arch / Manjaro sudo pacman -S fcrackzip # Windows # Use WSL2 + Ubuntu and `apt install fcrackzip`. # A native .exe exists but is old — WSL is simpler. # From source git clone https://github.com/hyc/fcrackzip.git cd fcrackzip && ./configure && make sudo cp fcrackzip /usr/local/bin/ </code></pre> Check what kind of encryption your zip uses first</h2> fcrackzip</code> only handles classic ZipCrypto</strong> (the original, weak PKZIP encryption). For modern AES-128 / AES-256</strong> zips (introduced by WinZip 9 in 2003, now default in some tools), fcrackzip</code> will silently fail to find the password no matter how long you run it.</p> Quickest check with zipinfo</code>:</p> $ zipinfo -v archive.zip \| head -40 </code></pre> Look for WinZip AES encryption, strength 3</code> (= AES-256). If you see that, skip to the hashcat section.</p> Or with 7z</code>:</p> $ 7z l -slt archive.zip \| grep -i 'method\\|encrypted' Method = ZipCrypto Store ← fcrackzip works Method = AES-256 Deflate ← fcrackzip will NOT work </code></pre> Basic brute-force</h2> fcrackzip -v -b -c 'a1' -p aaaa -u archive.zip </code></pre> -v</code></strong> — verbose.</li> -b</code></strong> — brute-force mode.</li> -c 'a1'</code></strong> — charset. a</code> = lowercase a–z</code>, A</code> = uppercase, 1</code> = digits, !</code> = printable symbols. Combine: 'aA1!'</code> = all printable ASCII (94 chars).</li> -p aaaa</code></strong> — starting password (defines minimum length = 4 here).</li> -u</code></strong> — only report if the decrypted file “unzips” cleanly (filters false positives — ZipCrypto has a small CRC that many random passwords pass).</li> </ul> Length: -p aaaaa</code> starts at 5 characters. fcrackzip</code> doesn’t have a --max-length</code> flag; it increments the starting password through the charset forever, so letting it run to “completion” at length 8 on the full printable ASCII charset is about 94⁸ ≈ 6×10¹⁵ candidates</strong> — not realistic. You bound the attack by picking a reasonable max charset + length, or by using a dictionary.</p> Dictionary attack</h2> fcrackzip -v -D -u -p /usr/share/wordlists/rockyou.txt archive.zip </code></pre> -D</code></strong> — dictionary mode.</li> -p <file></code></strong> — wordlist file, one candidate per line.</li> -u</code></strong> — verify via unzip, as before.</li> </ul> rockyou.txt</code> is the standard 14 M-entry wordlist shipped with Kali and available everywhere. If you have context about the password (it’s someone’s name + year, it’s a project codename), assemble a smaller targeted wordlist — hit rates are usually much higher than any generic list.</p> Speed and what to expect</h2> fcrackzip</code> is single-threaded and CPU-bound. On a modern laptop you’ll see roughly:</p> 10–30 million ZipCrypto attempts per second per core</strong> for a dictionary attack against a typical zip.</li> Brute-force slightly faster because less string I/O.</li> </ul> That makes it fine for:</p> Dictionary attacks</strong> against any reasonable wordlist.</li> Short brute-force</strong> (4–6 chars alphanumeric).</li> </ul> It makes it not fine for:</p> Length 8+ with symbols</strong> — you’ll never finish.</li> AES-256 zips</strong> — wrong tool.</li> </ul> When to reach for hashcat instead</h2> If fcrackzip</code> is too slow, or the zip is AES-encrypted, migrate to hashcat</code>. It’s the general-purpose password-cracking tool, GPU-accelerated, and handles both ZipCrypto and AES WinZip hashes.</p> Step 1: extract the hash with zip2john</code></h3> zip2john</code> is part of John the Ripper. Ubuntu: apt install john</code>.</p> $ zip2john archive.zip > hash.txt $ cat hash.txt archive.zip:$zip2$030...$/zip2$::archive.zip:secret.pdf:/path/to/archive.zip </code></pre> Step 2: feed it to hashcat</h3> # ZipCrypto (mode 17200, 17210, 17220, 17225 depending on compression) hashcat -m 17200 hash.txt /path/to/wordlist.txt # AES-encrypted WinZip (mode 13600) hashcat -m 13600 hash.txt /path/to/wordlist.txt </code></pre> On a single modern discrete GPU (e.g. RTX 4090) you’ll see:</p> ZipCrypto: ~5–10 billion H/s</strong></li> WinZip AES-256: ~10–50 million H/s</strong> (much slower because AES is expensive and PBKDF2 iterations are involved)</li> </ul> hashcat’s rule engine, mask attacks (-a 3</code>), and combinator mode (-a 1</code>) make it vastly more flexible than fcrackzip</code>. For anything non-trivial it is the right tool.</p> Common gotchas</h2> “PASSWORD FOUND!!!!: pw == abc” but unzip</code> still asks for a password</h3> You didn’t use -u</code>. fcrackzip’s CRC check has false positives. Re-run with -u</code> to verify candidates against a real decompression attempt.</p> Different files in the same zip have different passwords</h3> Classic PKZIP supports per-file passwords. fcrackzip</code> attacks one file at a time; pass -l <filename></code> (or let it pick the first encrypted one) if you need to be specific.</p> fcrackzip finds the password, but I still can’t unzip</h3> Character set / locale issue. If the password contains non-ASCII characters, the zip’s creator may have used a different encoding than your terminal. Try unzip -P "$(echo -n 'passwd' \| iconv -t cp437)" archive.zip</code>.</p> AES-encrypted and dictionary doesn’t find it</h3> hashcat + rules + a targeted wordlist is the move. See the migration steps above.</p> Defensive takeaway</h2> If you’re generating zip files you want to stay encrypted: use AES-256</strong>, not ZipCrypto. Most modern tools (7z</code>, zip</code> from InfoZIP with -e</code>, WinZip, Keka) give you AES if you ask. The default on zip</code> unfortunately is still ZipCrypto on many systems. Check with 7z l -slt archive.zip</code> before shipping it.</p> And pick a password with length, not cleverness. hashcat</code> doesn’t care how weird your substitution pattern is; it only cares about entropy. A four-word passphrase (correct-horse-battery-staple</code>-style, ~44 bits) is fine against offline ZipCrypto attacks; a random 12-character mixed password (~78 bits) is fine against GPU AES attacks. Anything shorter is recoverable.</p> FAQ</h2> Is fcrackzip legal?</h3> Recovering passwords on files you own or are authorised to access is legal in every jurisdiction I’m aware of. Doing it on someone else’s file without authorisation is unauthorised access — the same law that applies to any other computer intrusion.</p> Is fcrackzip maintained?</h3> Barely. The codebase has been stable for fifteen-plus years. For modern work, the combination of zip2john</code> + hashcat</code> has eclipsed it.</p> Can fcrackzip use a GPU?</h3> No. fcrackzip</code> is CPU-only. If GPU is what you have, go straight to hashcat.</p> Does fcrackzip handle .7z, .rar, .gpg files?</h3> No — only classic PKZIP .zip</code>. For .7z</code>, use 7z2john</code> + hashcat (mode 11600). For .rar</code>, rar2john</code> + hashcat (mode 12500 / 13000). For .gpg</code>, gpg2john</code> + hashcat (mode 17010+).</p> How do I generate a targeted wordlist?</h3> hashcat</code>’s maskprocessor (mp64</code>), crunch</code>, and cewl</code> (crawls a site for candidate words) are all worth knowing. For recovering a specific forgotten password, writing down what you remember about it — length, likely words, likely numbers — and building a mask attack from that is the highest-yield approach.</p> Summary</h2> fcrackzip</code> + -D</code> + a wordlist is the right first try.</li> If that doesn’t work and it’s ZipCrypto: fcrackzip</code> + -b</code> with a narrow charset and short length.</li> If that doesn’t work or it’s AES: zip2john</code> + hashcat</code> on a GPU.</li> If that doesn’t work: your password was strong enough. That’s the system working as intended.</li> </ul> pdfcrack — recover lost PDF passwords on Linux and macOS (2026) 2026-04-22T00:00:00+00:00 TL;DR —</strong> pdfcrack</code></strong> is a command-line tool that recovers the user password</strong> or owner password</strong> of an encrypted PDF by brute-force or dictionary attack. It’s small, written in C, runs on Linux/macOS/WSL, and handles every encryption profile PDF has shipped — 40-bit RC4, 128-bit RC4, 128-bit AES, 256-bit AES (PDF 1.7 + 2.0). It is single-threaded and CPU-only</strong>, so it is fast on the weak old RC4-40 encryption but increasingly slow as PDFs get modern. Install with apt install pdfcrack</code> (Debian/Ubuntu), brew install pdfcrack</code> (macOS), or build from source. When pdfcrack</code> is too slow, switch to pdf2john</code> + hashcat</code></strong> on a GPU.</p> This walkthrough assumes you have authorisation to recover the password</strong> on the PDF — your own document, a client’s, or a legally-acquired file. Don’t attack PDFs you don’t own.</p> User password vs owner password</h2> PDF has two passwords:</p> User password</strong> — required to open and read</strong> the document.</li> Owner password</strong> — required to remove restrictions</strong> (print, copy, modify) on a document that opens without a user password.</li> </ul> Many “protected” PDFs are only owner-password-restricted: they open fine, but printing and copying are disabled by the reader. Those are trivial to unlock — qpdf --decrypt</code> or any of the pdftk</code>-style tools strip owner-only restrictions without needing to guess anything. pdfcrack</code> is for the harder case: a user-password-protected PDF you can’t open at all</strong>.</p> Check which you’re dealing with:</p> $ qpdf --show-encryption document.pdf R = 6 P = -3904 User password = Supplied password is owner password extract for accessibility: allowed extract for any purpose: not allowed print low resolution: allowed print high resolution: not allowed modify document assembly: not allowed modify forms: not allowed modify annotations: not allowed modify other: not allowed stream encryption method: AESv3 string encryption method: AESv3 file encryption method: AESv3 </code></pre> R = ...</code></strong> tells you the revision / profile. R=2</code> = RC4-40, R=3</code> = RC4-128, R=4</code> = AES-128, R=5/6</code> = AES-256.</li> “Supplied password is owner password”</strong> + “User password = (empty)” means you can open it and just need to strip restrictions. Use qpdf --decrypt --password='' input.pdf output.pdf</code> and you’re done.</li> </ul> Install</h2> # Debian / Ubuntu / Mint / Kali sudo apt install pdfcrack # macOS (Homebrew) brew install pdfcrack # Arch / Manjaro sudo pacman -S pdfcrack # Fedora / RHEL sudo dnf install pdfcrack # From source wget https://sourceforge.net/projects/pdfcrack/files/latest/download -O pdfcrack.tar.gz tar xf pdfcrack.tar.gz && cd pdfcrack- make sudo cp pdfcrack /usr/local/bin/ </code></pre> Benchmark</h2> $ pdfcrack -b Benchmark: Average Speed (calls / second): MD5: 1728972.6 MD5_50 (fast): 97879.3 MD5_50 (slow): 69167.0 RC4 (40, static): 606555.3 RC4 (40, no check): 598050.0 RC4 (128, no check): 590141.7 Benchmark: Average Speed (passwords / second): PDF (40, user): 453510.2 PDF (40, owner): 220250.0 PDF (40, owner, fast): 499995.0 PDF (128, user): 22000.0 PDF (128, owner): 10408.7 PDF (128, owner, fast): 22220.0 </code></pre> Translation:</p> RC4-40</strong> (PDF 1.3, very old) — ~450k passwords/sec. Brute-force of a full 8-character alphanumeric space: ~1 week on one core.</li> RC4-128 / AES-128</strong> — ~22k passwords/sec. Brute-force becomes unrealistic above length 6 with any charset.</li> AES-256 (R=5/6)</strong> — even slower; pdfcrack</code> does support it but effectively only for dictionary attacks against small wordlists.</li> </ul> If you need speed beyond this, you want hashcat</code> on a GPU. Numbers at the bottom.</p> Dictionary attack</h2> pdfcrack -f document.pdf -w /usr/share/wordlists/rockyou.txt </code></pre> -f</code></strong> — target file.</li> -w <file></code></strong> — wordlist, one candidate per line.</li> Optional -o</code></strong> — attack the owner password only (ignore user password). Default is to try user password first.</li> Optional -u</code></strong> — attack user password only.</li> </ul> If you have context — the password is probably a first name, a year, a project code — assemble a smaller targeted list. Generic lists are a long shot once you’re past the top ten thousand entries.</p> Brute-force attack</h2> pdfcrack -f document.pdf -c 'abcdefghijklmnopqrstuvwxyz0123456789' -n 4 -m 8 </code></pre> -c <charset></code></strong> — character set to try. Default includes a broad ASCII range.</li> -n <min></code></strong> — minimum length.</li> -m <max></code></strong> — maximum length.</li> </ul> Tune -c</code> aggressively. If you know the password is all lowercase, don’t give it uppercase. If you know it has a digit at the end, use a mask attack (hashcat territory, not pdfcrack).</p> Resume a long run</h2> pdfcrack -f document.pdf -w rockyou.txt -s /tmp/state.sav </code></pre> -s</code> writes periodic save files; if you kill pdfcrack and restart, pass -l /tmp/state.sav</code> to resume.</p> When to switch to hashcat</h2> For any modern PDF (R=4, 5, or 6 — i.e. AES-128 or AES-256), pdfcrack</code>’s single-core speed becomes the bottleneck. pdf2john</code> + hashcat</code> gets you two to three orders of magnitude more throughput on a GPU.</p> Step 1: extract the hash</h3> $ /usr/share/john/pdf2john.pl document.pdf > hash.txt </code></pre> (On Debian/Ubuntu: apt install john</code> provides pdf2john.pl</code>.)</p> Step 2: identify the hash mode</h3> $ head -1 hash.txt document.pdf:$pdf$56256-1028116... </code></pre> Map the first two numbers:</p> $pdf$12...</code> → mode 10400</strong> (PDF 1.1–1.3, RC4-40, user)</li> $pdf$12...</code> with owner salt → mode 10410 / 10420</strong></li> $pdf$23...</code> → mode 10500</strong> (PDF 1.4–1.6, RC4-128 / AES-128)</li> $pdf$55...</code> → mode 10600</strong> (PDF 1.7 r=5, AES-256)</li> $pdf$56...</code> → mode 10700</strong> (PDF 1.7 r=6 / PDF 2.0, AES-256 with PBKDF2)</li> </ul> Step 3: run hashcat</h3> hashcat -m 10700 hash.txt /path/to/wordlist.txt </code></pre> On a single modern GPU (e.g. RTX 4090):</p> Mode 10400 (RC4-40):</strong> ~10 billion H/s — any practical password is recovered instantly.</li> Mode 10500 (RC4-128 / AES-128):</strong> ~100 million H/s.</li> Mode 10700 (AES-256, PBKDF2):</strong> ~50,000 H/s. This is by design — the PBKDF2 iterations make brute-force expensive.</li> </ul> For mode 10700, your attack strategy matters more than raw speed. Dictionary + rules + mask attacks targeted at likely password patterns are orders of magnitude more productive than exhaustive brute-force.</p> Common gotchas</h2> “File seems encrypted but I can still open it without a password”</h3> You’re looking at owner-only restrictions. Use qpdf --decrypt input.pdf output.pdf</code> — no cracking needed.</p> pdfcrack runs but never finds anything</h3> Three likely causes:</p> Password is longer / more complex than your charset × length covers.</strong> Increase -m</code> and/or expand -c</code>, or switch to a dictionary.</li> Password contains non-ASCII characters.</strong> pdfcrack’s charset is ASCII by default; non-ASCII user passwords in old PDFs used varying encodings (PDFDocEncoding, UTF-16). Try pdf2john</code> + hashcat, which handles the encoding properly.</li> It’s AES-256 (R=6) and you’re being patient.</strong> See speed notes above — realistic only with a dictionary.</li> </ol> “Only AES-256 is supported” error or similar</h3> Your pdfcrack</code> build is old. Ubuntu LTS sometimes ships a version that doesn’t fully handle R=6. Build from source or switch to pdf2john</code> + hashcat</code>.</p> PDF opens but printing/copying is blocked</h3> That’s owner-password-restricted only. qpdf --decrypt</code> without needing a password usually works:</p> qpdf --decrypt --password='' input.pdf output.pdf </code></pre> Defensive takeaway</h2> For anything you want to stay encrypted in 2026, use AES-256 with a PDF 2.0 (R=6) password</strong>. That’s the profile with PBKDF2 key derivation that makes offline attacks expensive on current hardware.</p> And, as always, the password’s length matters more than anything else. A 20-character random passphrase is brute-force-intractable against any current GPU. A 6-character “clever substitution” password is a coffee break on an RTX 4090.</p> FAQ</h2> Is pdfcrack still maintained?</h3> Updated slowly. The codebase handles all currently shipped PDF encryption profiles; it just isn’t where performance work is happening anymore (that’s hashcat).</p> Does pdfcrack use GPU?</h3> No. CPU-only, single-threaded. For GPU work, use pdf2john</code> + hashcat</code>.</p> Can pdfcrack recover the document if the creator cleared the user password but kept the owner password?</h3> Yes — use qpdf --decrypt</code> first; if that won’t fully decrypt, pdfcrack -o</code> attacks the owner password.</p> Does pdfcrack leak my PDF anywhere?</h3> No. It’s local. Anything online-only (“crack my PDF at cloud-service-X.com”) involves uploading the file, which you shouldn’t do for confidential material.</p> What if I only vaguely remember the password?</h3> Write down what you remember — likely words, likely digits, likely length — and build a targeted wordlist or hashcat</code> mask (-a 3 ?l?l?l?l?l?d?d?d?d</code>). That beats any generic list.</p> Can I recover text from an AES-256 PDF without the password?</h3> No. AES-256 with PBKDF2 (R=6) is, to the best of public cryptanalysis, not broken. If the password is strong and lost, the contents are lost.</p> Summary</h2> Owner-password-only?</strong> qpdf --decrypt</code>, no cracking needed.</li> User-password-protected, old (R=2/3)?</strong> pdfcrack</code> with a dictionary works fine.</li> Modern (R=4/5/6)?</strong> pdf2john</code> + hashcat</code> on a GPU, targeted attack.</li> Strong 20-character random?</strong> Accept the loss.</li> </ul> Hacking Wi-Fi across 25 years — 2002, 2007, 2012, 2017, 2022, 2027 2026-04-22T00:00:00+00:00 TL;DR —</strong> Wi-Fi security has gone through four generations — WEP</strong>, WPA</strong>, WPA2</strong>, WPA3</strong> — each introduced because its predecessor was broken. This post walks through six snapshots of the state of the art: 2002</strong> (WEP, trivial), 2007</strong> (WEP dead, WPA widespread, offline attacks emerging), 2012</strong> (WPA2 dominant, dictionary attacks on GPUs), 2017</strong> (KRACK breaks WPA2 under the right conditions, PMKID leak in 2018), 2022</strong> (WPA3 rolling out, downgrade attacks, cloud-scale cracking), 2027</strong> (today’s landscape: WPA3 nearly universal, 6 GHz opens new surface, attacks move up the stack). For each year I summarise the attack, the tool, and what a defender should have been doing. Authorised testing only — the defensive guidance at the bottom is the point.</p> At a glance</h2> Year</th> Dominant standard</th> Headline attack</th> Effort to compromise a typical network</th> Fastest dictionary / key-rate at the time</th></tr></thead> 2002</td> WEP (100%)</td> FMS statistical IV</td> ~4M packets / 2–10 h on a busy AP</td> N/A — key recovered from IVs</td></tr> 2007</td> WEP 35%, WPA 25%, WPA2 20%, open 20%</td> PTW + aircrack-ng</td> 40–85k packets / <5 min (WEP)</td> ~50–100 PSK/s (CPU, cowpatty)</td></tr> 2012</td> WPA2 ~70%</td> Reaver (WPS) + GPU PSK dictionary</td> 11,000 WPS PINs / 2–10 h</td> ~75,000 PSK/s (GTX 580)</td></tr> 2017</td> WPA2 ~85%</td> KRACK; then PMKID (2018)</td> 1 packet (PMKID) → offline dict</td> ~400,000 PSK/s (GTX 1080)</td></tr> 2022</td> WPA2 ~60%, WPA3 ~20%, mixed ~15%</td> Dragonblood downgrade</td> Force WPA2 fallback, then GPU/cloud</td> ~1.2M PSK/s (RTX 3090), ~10M (8× A100)</td></tr> 2027</td> WPA3 ~40%, mixed ~35%, WPA2 ~20%</td> Client-side + downgrade + chipset FW</td> SAE intact; legacy WPA2 on borrowed time</td> ~5–8M PSK/s (RTX 5090-era single GPU)</td></tr> </tbody></table> Approximate global deployment shares are from public Wi-Fi surveys (WiGLE aggregate trends + vendor reports); treat as ± 10 points.</p> 2002 — WEP everywhere, and trivially broken</h2> Standard:</strong> IEEE 802.11b with WEP</strong> (Wired Equivalent Privacy). 40-bit or 104-bit RC4 key, 24-bit IV, CRC-32 integrity.</p> What’s wrong with it:</strong> The IV is too small, keys are static, and RC4’s initial key schedule leaks bits of the key when certain IVs are used. These are the FMS attack</strong> (Fluhrer, Mantin, Shamir, 2001) and its descendants.</p> What an attacker did in 2002:</strong> captured traffic with a Prism-based USB adapter, collected a few million packets (hours on an active network), and extracted the key with AirSnort</strong> or WEPCrack</strong>. Attacks were so embarrassing that Wi-Fi Alliance pushed WPA as a temporary firmware-patchable fix in 2003.</p> By the numbers (2002):</strong></p> Global Wi-Fi deployment:</strong> ~100% WEP (WPA not ratified until March 2003).</li> Key length:</strong> 40-bit (export-grade) or 104-bit. Irrelevant — the attack is on the IV, not the key.</li> IV space:</strong> 24 bits → only ~16.7 M possible IVs. Birthday-paradox collision around ~5,000 packets.</li> FMS attack packet count:</strong> ~500 k–4 M “interesting” IV frames (a few hours of active traffic).</li> Typical crack wall-clock:</strong> 2–10 h on a busy SOHO network.</li> Consumer hardware required:</strong> one laptop + one Prism2/Prism2.5 USB dongle (~$40 used at the time).</li> Tools:</strong> AirSnort, WEPCrack, Kismet for capture.</li> CVEs:</strong> WEP itself isn’t a CVE, but the 2001 Borisov/Goldberg/Wagner paper and the 2001 FMS paper are the canonical breakage references.</li> </ul> What a defender should have done:</strong> realise WEP is not a security feature and treat the wireless LAN as untrusted. Use a VPN or IPSec at layer 3.</p> 2007 — WEP dead, WPA transitional, WPA2 arriving</h2> Standard:</strong> WPA (2003), a stopgap with per-packet keys (TKIP). WPA2 (2004) with AES-CCMP starting to appear in home routers.</p> What’s new for attackers:</strong> the PTW attack</strong> on WEP (2007) drops the packet count needed from ~1 million to ~40,000 — WEP now cracks in minutes. aircrack-ng</strong> becomes the canonical toolkit. Against WPA-Personal, offline dictionary attacks on the 4-way-handshake become practical on CPUs: capture a handshake, feed the PSK derivation through cowpatty</code> or aircrack-ng</code>, try dictionary entries one at a time.</p> What attackers didn’t have yet:</strong> meaningful GPU acceleration of WPA-PSK. Dictionary attacks were slow.</p> By the numbers (2007):</strong></p> Global deployment (WiGLE-style surveys):</strong> WEP ~35%, WPA ~25%, WPA2 ~20%, open ~20%.</li> PTW attack packet count:</strong> ~40,000–85,000 captured frames to recover a WEP key (down from millions).</li> Crack time with aircrack-ng + packet injection:</strong> <5 minutes, often under 60 seconds.</li> WPA-PSK dictionary rate (CPU, cowpatty/aircrack-ng):</strong> ~50–100 candidates/sec per core.</li> Rockyou wordlist</strong> (leaked Dec 2009): 14.3 M entries — became the de-facto English PSK wordlist.</li> WPA2 mandatory for Wi-Fi CERTIFIED:</strong> March 2006.</li> Aircrack-ng 1.0:</strong> released 2006, consolidating the ecosystem.</li> </ul> What a defender should have done:</strong> migrate to WPA2-AES-CCMP, pick a PSK longer than any dictionary. Drop WEP networks entirely.</p> 2012 — WPA2 dominant, GPU-cracking mature</h2> Standard:</strong> WPA2 is the default on essentially all consumer gear. WPA2-Enterprise (802.1X / EAP) in corporate networks.</p> What’s new for attackers:</strong> hashcat</strong> and oclHashcat</strong>, pyrit</strong>, and John the Ripper</strong> turn the WPA-PSK dictionary attack into a GPU problem</strong>. A handshake capture + a single modern GPU does tens of thousands of candidate PSKs per second; a small rented GPU farm handles hundreds of thousands. airodump-ng</strong> + Reaver</strong> (2011) exploit a WPS PIN</strong> implementation flaw to recover the WPA-PSK without a dictionary at all — a dealbreaker for home routers with WPS-on-by-default.</p> By the numbers (2012):</strong></p> Global deployment:</strong> WPA2 ~70%, WEP ~10%, open ~15%, WPA ~5%.</li> WPS PIN space on paper:</strong> 10⁸ = 100 million. Effective</strong> attack space after the Viehböck split: 10⁴ + 10³ = ~11,000 tries.</li> Reaver wall-clock to recover WPS PIN → PSK:</strong> 2–10 hours against an unpatched AP.</li> hashcat WPA-PSK throughput on GTX 580 (reference 2012 GPU):</strong> ~75,000 candidates/sec.</li> hashcat WPA-PSK on a small 4-GPU rig of the era:</strong> ~300,000 candidates/sec, i.e. rockyou.txt</code> (14.3 M) in ~50 seconds.</li> Real-world PSK recovery rate with rockyou + common rules:</strong> ~20–25% on captured handshakes in academic studies.</li> WPA2-PEAP/MSCHAPv2 hash rate (a Wi-Fi-adjacent Enterprise pain point):</strong> tens of millions/sec on a single GPU, full 2²⁸ keyspace within a day.</li> </ul> What defenders should have done:</strong></p> Turn off WPS.</strong> Most routers had it on by default.</li> Use long random PSKs</strong>, not dictionary words.</li> For enterprise: 802.1X + EAP-TLS with client certificates</strong>, not PEAP-MSCHAPv2 (which is itself a GPU problem).</li> </ul> 2017 — KRACK</h2> Standard:</strong> WPA2 still everywhere.</p> What’s new for attackers:</strong> KRACK</strong> (Vanhoef, Piessens, 2017) — Key Reinstallation Attack. It doesn’t crack the PSK. It exploits a subtle flaw in the 4-way handshake where, under certain conditions (specifically on Android 6+ and wpa_supplicant 2.4–2.6), replaying handshake message 3 causes the client to reinstall an all-zero session key</strong>. From there, the attacker can decrypt selected traffic and, depending on cipher suite, inject packets.</p> What made KRACK different from prior attacks:</strong> it hit the protocol, not the key</strong>. A strong PSK didn’t help. Every WPA2 implementation needed a patch. Most vendors shipped one within weeks; some took years.</p> Also in this era:</strong></p> PMKID hashcat attack</strong> (2018, Steube). Many APs leak the PMKID in a single message; one packet is enough to start an offline PSK attack. Lowered the capture bar further — no client association needed.</li> Evil twin / captive portal phishing.</strong> As device UIs got prettier, fake captive portals became alarmingly effective against humans.</li> </ul> By the numbers (2017–2018):</strong></p> Global deployment:</strong> WPA2 ~85%, WEP <3%, open ~10%, WPA3 not yet shipping.</li> KRACK CVEs:</strong> 10 in the coordinated disclosure (CVE-2017-13077 through CVE-2017-13088).</li> KRACK-affected devices:</strong> all WPA2 clients and APs — 10+ billion</strong> endpoints. Real patching took years for long-tail IoT.</li> Vendor patch latency:</strong> Microsoft / most Linux distros within 1 week of disclosure; Android 2 months+ depending on OEM; many embedded devices never patched.</li> PMKID attack packet count:</strong> 1 single frame</strong> vs. the 4-way handshake’s 4 frames — no client association or deauth needed.</li> hashcat on GTX 1080 (reference 2017 GPU):</strong> ~400,000 WPA-PSK candidates/sec — ~5× faster than 2012.</li> A rented 8× 1080 Ti instance (~$4/h in 2017):</strong> ~3M candidates/sec — rockyou.txt</code> in <5 seconds.</li> Coordinated disclosure lead time:</strong> 4 months from vendor notification to public release.</li> </ul> What a defender should have done:</strong> patch Android / wpa_supplicant immediately, enforce HTTPS everywhere so decrypted Wi-Fi traffic is less useful, start planning WPA3 migration.</p> 2022 — WPA3 rolling out, downgrade attacks</h2> Standard:</strong> WPA3 (2018) required for Wi-Fi CERTIFIED devices since 2020. Key upgrades:</p> SAE</strong> (Simultaneous Authentication of Equals) replaces the 4-way handshake PSK — offline dictionary attacks become infeasible.</li> 192-bit mode</strong> for Enterprise.</li> Forward secrecy</strong>.</li> PMF</strong> (Protected Management Frames) mandatory — neutralises deauth-based denial-of-service.</li> </ul> What’s new for attackers:</strong> WPA3 isn’t broken, but its deployment mostly isn’t WPA3-only</strong>. WPA2/3 transition mode</strong> — the default on most APs — means an attacker can force a downgrade and attack as WPA2. This is Dragonblood</strong> (Vanhoef, Ronen, 2019 + follow-ups): a family of side-channel and downgrade attacks against SAE. By 2022, patched SAE implementations mostly closed the timing side-channels; the downgrade attack still works on mixed-mode networks.</p> Also in this era:</strong></p> Cloud-scale cracking</strong>: renting 8× H100 or similar on an hourly basis makes PMK dictionary attacks practical at a scale no amateur had in 2012.</li> Chipset firmware vulnerabilities</strong> (FragAttacks, 2021): flaws in the Wi-Fi stack itself, below the WPA layer, let attackers inject frames without needing any handshake break at all.</li> </ul> By the numbers (2022):</strong></p> Global deployment:</strong> WPA2-only ~60%, WPA3 ~20%, WPA2/3 transition mode ~15%, WEP <1%.</li> New-router WPA3 support:</strong> ~60% of consumer APs shipped in 2022 supported WPA3 (vs. ~10% in 2020).</li> Dragonblood CVEs:</strong> 5 (CVE-2019-9494 through CVE-2019-9499).</li> FragAttacks CVEs:</strong> 12 in the 2021 bundle.</li> hashcat WPA-PSK on RTX 3090:</strong> ~1.2M candidates/sec.</li> 8× A100 cloud instance:</strong> ~10M candidates/sec aggregate. rockyou.txt</code> in ~1.5 seconds; a 10B-candidate mask attack in ~17 minutes.</li> Cost per billion PSK attempts on spot cloud GPUs:</strong> ~$3–5.</li> 12-character fully-random PSK entropy:</strong> 2⁷² ≈ 4.7 × 10²¹. At 10M H/s, exhaustive attack = ~15,000 years</strong>. Safe.</li> 8-character lowercase+digit PSK entropy:</strong> 2⁴¹ ≈ 2.2 × 10¹². At 10M H/s, ~2.5 days</strong>. Not safe.</li> </ul> What a defender should have done:</strong> WPA3-Personal only (no WPA2 transition) on networks where you can enforce it; PMF required; long random PSK even with SAE; keep AP firmware current.</p> 2027 — today’s landscape</h2> Standard:</strong> Wi-Fi 6E (6 GHz) and early Wi-Fi 7 deployments. WPA3 near-universal on new gear; legacy WPA2 still common in small businesses and long-lived home networks.</p> State of the art in attacks:</strong></p> SAE is holding up.</strong> No public, practical attack against a well-configured WPA3-Personal network in 2027. Dictionary attacks against the PSK are not feasible — that’s SAE’s point.</li> Downgrade attacks</strong> are the main thing. Any network still advertising WPA2/3 transition is attackable as WPA2. Adversaries look for mixed-mode SSIDs first.</li> 6 GHz opens new surface.</strong> The 6 GHz band requires WPA3 for new standards; but legacy client bridging, IoT devices without 6 GHz support, and misconfigured co-broadcast SSIDs create inconsistencies attackers exploit.</li> Client-side attacks.</strong> When the link layer is secure, attackers move up. Rogue captive portals that trick phones into trusting a bad certificate, QR-code joining with fake SSIDs, deauth-during-roaming attacks (harder now with PMF but not eliminated).</li> Supply chain.</strong> Firmware-embedded backdoors and vendor bugs in Wi-Fi chipsets (the FragAttacks legacy) remain a durable source of exploits.</li> Cloud cracking is commoditised.</strong> A weekend-long SAE-offline attack (for the cases where offline attack is possible, i.e. the target ran an unpatched SAE) costs roughly the price of a nice dinner. This mostly doesn’t matter because SAE isn’t reducible to offline dictionary attack — but it shifts economics on legacy WPA2 networks that people haven’t migrated.</li> </ul> Tools still in rotation in 2027:</strong> aircrack-ng (older, still canonical for captures and WPA2), hashcat (cracking), bettercap (Wi-Fi MITM / rogue AP), airgeddon (workflow glue), and a wave of ESP32-based pocket tools for opportunistic deauth and handshake capture.</p> By the numbers (2027):</strong></p> Global deployment:</strong> WPA3 ~40%, WPA2/3 transition ~35%, WPA2-only ~20%, WEP ~0.5% (long tail of ancient gear).</li> Enterprise share running WPA3-Enterprise 192-bit mode:</strong> still <10%. Most corporate networks remain WPA2-Enterprise with PEAP.</li> New-device WPA3 certification:</strong> mandatory for Wi-Fi 6 since 2020, Wi-Fi 6E (6 GHz) since 2022, Wi-Fi 7 at launch.</li> hashcat WPA-PSK on RTX 5090-class single GPU (2025+):</strong> ~5–8M candidates/sec.</li> 8× H100 cloud instance:</strong> ~50M candidates/sec aggregate. rockyou.txt</code> in ~0.3 seconds.</li> SAE (WPA3-Personal) offline attack:</strong> infeasible at any hash rate — the handshake does not release a crackable hash to an eavesdropper.</li> Cost to brute-force a weak 8-char WPA2 PSK in 2027:</strong> <$10 on spot cloud GPUs.</li> Cost to brute-force a 12-char random WPA2 PSK:</strong> still ~ $10⁹ (same math as 2022, GPUs 5× faster → still millennia).</li> ESP32-S3 “Wi-Fi Nugget” / Flipper Zero-class pocket tools</strong> in circulation in 2027: hundreds of thousands of units. Opportunistic handshake capture is trivial; PSK cracking is still offline on a beefy host.</li> Deauth-DoS effectiveness:</strong> near-zero on PMF-required networks; still works against the ~30% of deployed APs where PMF is “capable” but not “required”.</li> </ul> Bottom line: against WPA3-Personal with SAE, PMF required, and a random PSK</strong>, none of the 2027 toolkit gets you in via the link layer. Against a typical 2019-vintage home router still running WPA2 with a weak PSK and WPS optionally exposed</strong>, a weekend on a mid-range GPU is plenty.</p> Defensive guidance for 2027</h2> This is the part that matters more than any of the history.</p> WPA3-Personal SAE-only, or WPA3-Enterprise with EAP-TLS.</strong> No transition mode on any network you can control. Check explicitly — many APs default to transition.</li> PMF required, not optional.</strong> Protected Management Frames prevent deauth-driven handshake captures and basic denial-of-service.</li> PSK length: random, ≥ 20 characters.</strong> SAE makes short PSKs safer than they used to be, but no reason to gamble.</li> Disable WPS permanently.</strong> Even though the WPS-PIN attack is ancient, many routers still ship with it enabled for “convenience”.</li> Guest SSID isolated.</strong> Client-to-client isolation on and routed to a separate VLAN with no internal LAN access.</li> IoT SSID, separate and cloistered.</strong> Cheap Wi-Fi thermostats and toys are the weakest link on most home networks. They get their own SSID, their own VLAN, and no route to anything important.</li> Firmware updates on APs.</strong> Most of the interesting 2020s Wi-Fi vulnerabilities were chipset-level; the fix is always a firmware update. Buy APs from a vendor that ships them.</li> Assume the link layer will fail and defend above it.</strong> HTTPS everywhere, client certs on anything that matters, VPN or Tailscale for remote access. When (not if) someone breaks your Wi-Fi, layer 4+ should still hold.</li> </ul> What stayed the same across 25 years</h2> Three patterns repeat at every generation:</p> The cryptography is almost always stronger than the deployments.</strong> WEP was a design failure; WPA2 and WPA3 have been broken by implementation flaws, downgrade paths, and side channels — not by pure crypto weaknesses.</li> Defaults matter more than capabilities.</strong> WPS on by default, WPA2/3 transition mode on by default, guest networks without isolation by default — this is what attackers actually find, at scale.</li> The attacker always moves up the stack.</strong> When link-layer security improves, attacks shift to captive portals, rogue certs, client mis-configurations, and phishing. No amount of WPA3 fixes the user who clicks “Trust” on the evil twin’s fake certificate.</li> </ol> Coda</h2> If this post’s ancestor on this site, from 2010, was “How to Hack a Wireless Network” and focused on WEP with aircrack-ng</code>, the 2027 version is closer to “How to Think About Wi-Fi Security” and focuses on configuration, patching, and realistic threat modelling. The cryptography has done its job. The layers around it are the interesting frontier now.</p> Test your own networks — or networks you’re authorised to test — don’t test anyone else’s. The same law that applied in 2002 applies in 2027.</p> nemboks.dk — forward your Danish digital post (mit.dk, e-Boks) to your email inbox 2026-04-22T00:00:00+00:00 TL;DR —</strong> nemboks.dk</a> is a service that forwards Danish digital post</strong> (from mit.dk</a> and e-Boks</a>) straight to your email. The problem it solves: digital post is “push” in theory but pull in practice — you still have to log in with MitID, open an app, and click around to read a letter from SKAT or your kommune. Nemboks turns that into an email that lands in the inbox you already live in, attachments and all. Built for Danish SMBs where the same virksomhed</code> receives post for multiple companies or employees, and where accountants, bookkeepers, and property managers want digital post in the same place as every other email. Free beta; after beta, 39 kr/md on annual billing, 49 kr/md monthly.</p> The problem with Danish digital post</h2> Since 2014, communication from the Danish public sector is digital by default. That means if your kommune, SKAT, Udbetaling Danmark, or FerieKonto needs to reach you, they drop a letter into either mit.dk</a></strong> (the public portal) or e-Boks</a></strong> (historically the most used private portal, now share-gated with Digital Post).</p> In principle this is great: centralised, auditable, no paper. In practice it’s friction-heavy:</p> You need MitID to log in every time.</strong> Every tax letter, parking ticket, or vacation-pay notice is gated behind an MFA flow.</li> The apps notify you, but the notifications are thin.</strong> “You have new post” — not a subject line, not a sender, not enough to triage.</li> There’s no native forwarding.</strong> You can’t say “send everything from SKAT to my accountant at bogholder@firma.dk</code>.”</li> Businesses inherit the worst of both worlds.</strong> A CVR-registered company has its own mit.dk / e-Boks inbox. If the owner doesn’t check it, nobody does.</li> </ul> Email, by contrast, is the default inbox for small businesses: shared mailboxes, forwarding rules, archiving, filters, search. Nemboks bridges the two.</p> What Nemboks does</h2> Once set up, Nemboks authenticates against your mit.dk / e-Boks on your behalf, polls your inbox for new post, and forwards each new letter — as a real email with the PDF attached</strong> — to the address(es) you configure.</p> One email per letter.</strong> Subject = sender + subject. Body = plain-text preview. Attachment = the PDF.</li> Multiple companies per account.</strong> If you’re a revisor managing post for many CVRs, they all live under one Nemboks dashboard.</li> Multiple destinations per company.</strong> Forward everything from SKAT to the bogholder, everything else to the owner, for example.</li> Keeps the original in mit.dk / e-Boks.</strong> Nothing is deleted — Nemboks only reads.</li> Logs every forward.</strong> For audit and peace of mind.</li> </ul> The practical outcome: the accountant or bookkeeper who already lives in Outlook or Gmail stops context-switching into a portal once a week.</p> Who it’s for</h2> Nemboks is built for small- and medium-sized Danish businesses, especially:</p> Accountants and bookkeepers (revisorer</code>, bogholdere</code>).</strong> Clients give them Nemboks access once; from then on, every SKAT letter for every client turns into an email in the shared inbox.</li> Property managers (ejendomsadministratorer</code>).</strong> A single administrator might manage post for dozens of property-owning A/S and ApS.</li> Small-company owners.</strong> The enkeltmandsvirksomhed</code> or two-person ApS</code> whose owner would rather receive a letter from their municipality in the same place as their customer email.</li> </ul> The stack</h2> For the curious:</p> Rails 8</strong> on Ruby 3.4, using Hotwire (Turbo + Stimulus) and Tailwind for the dashboard.</li> PostgreSQL</strong> for persistence.</li> Auth0</a></strong> for authentication. Users sign in with Google, Microsoft, or email+password — no separate Nemboks password to forget.</li> Stripe</a></strong> for subscription management, including the hosted customer portal for self-service card updates and cancellations.</li> Postmark</a></strong> for transactional email — it’s the category leader for “email that must land in the inbox,” which is the entire point of a forwarding service.</li> Docker + Kamal</strong> for deployment. Zero-downtime rollouts on a small fleet; no Kubernetes to operate.</li> Cloudflare Pages</strong> for the static marketing site at nemboks.dk</a>.</li> </ul> The split — Rails app on Kamal, marketing site on Pages — is deliberate. The marketing site needs to be cheap, fast, and heavily cached; the Rails app needs a database and background jobs. Running them as two separate deployments keeps each one simple.</p> Pricing</h2> Free beta</strong> while the service is stabilising.</li> After beta: 39 kr/md</strong> on annual billing, 49 kr/md</strong> monthly — VAT not included. Flat per-company pricing; no per-letter fees.</li> 60-day free trial</strong> for new customers after beta ends.</li> </ul> FAQ</h2> Is Nemboks allowed to read my mit.dk / e-Boks?</h3> Yes — as the inbox owner, you authorise Nemboks to read on your behalf. Nemboks only reads; it does not delete, reply, or mark as read anything you didn’t configure.</p> Is this GDPR-compliant?</h3> Nemboks processes personal data on your behalf. As a customer you’re the data controller; Nemboks is the data processor, and there’s a standard databehandleraftale (DPA) to sign. All data is stored in the EU.</p> What happens to the original letter in mit.dk / e-Boks?</h3> It stays there. Nemboks is read-only.</p> Can I forward to multiple email addresses?</h3> Yes. Each company can have multiple forwarding destinations, and you can route different senders to different addresses (for example, everything from SKAT to the bookkeeper).</p> Does Nemboks work for private individuals?</h3> The current focus is Danish businesses (CVR). A private-individual plan may come later.</p> What if Nemboks goes down?</h3> Your post still arrives in mit.dk / e-Boks normally; Nemboks just won’t forward it until the service is back. Nothing is lost.</p> How do I cancel?</h3> Through the Stripe customer portal from inside the dashboard. No email, no phone call.</p> Why build it</h2> Digital post works. It’s secure, it’s auditable, and I’d rather trust a SKAT letter in mit.dk than a brown envelope. But the user interface is designed for a citizen reading a handful of letters a year, not for a business receiving dozens a week across several CVRs. Email solves the “dozens a week across several mailboxes” problem well — filters, rules, shared inboxes, search — so the smallest useful bridge is to get the letters out of the portal and into email, with the PDF attached, without anyone having to log in every time.</p> That’s Nemboks.</p> How to play Spotify on a Logitech Squeezebox in 2026 2026-04-22T00:00:00+00:00 TL;DR —</strong> The official Spotify plugin Logitech shipped with Squeezebox stopped working when Spotify retired the libspotify</code> API in 2022. In 2026 there are two working paths to get Spotify on a Squeezebox Classic, Touch, Boom, Radio, or Transporter</strong>: (1) Logitech Media Server + the Spotty plugin</a></strong> (now renamed Spotty</code> / sometimes Spotty-XL</code>), which uses the Spotify Web API plus librespot</code> under the hood, or (2) run spotifyd</a></strong> on the same host as LMS and point LMS at it as a generic audio source. Path 1 is the one you want unless you have a reason otherwise. This post walks through it.</p> What happened to the official plugin</h2> Squeezebox hardware went end-of-life at Logitech in 2012, but the software — Logitech Media Server (LMS)</strong>, the thing that actually streams music to the devices — has been community-maintained ever since. For years it shipped an official “Spotify” plugin that used Spotify’s now-discontinued libspotify</code> C library. When Spotify shut libspotify</code> down in 2022, that plugin stopped working, and Spotify has not shipped a replacement for third-party embedded devices.</p> The community filled the gap:</p> librespot</code></strong> — an open-source, Rust reimplementation of the Spotify Connect client protocol. It’s the basis of most modern third-party Spotify integrations.</li> Spotty plugin for LMS</strong> — wraps librespot</code> plus the Spotify Web API into an LMS plugin. Presents Spotify browsing, search, playlists, and playback inside the Squeezebox UI (both the device screen and the LMS web UI).</li> spotifyd</strong> — a standalone librespot</code>-based daemon that shows up as a Spotify Connect target. Your phone sees it as a speaker, you cast to it, and its audio output goes somewhere LMS can pick it up.</li> </ul> Path 1 (recommended): Spotty plugin on LMS</h2> This is the cleanest experience and the one that feels native on the Squeezebox. You search and browse from the Squeezebox remote or Touch screen, and it Just Works.</p> 1. Get LMS running</h3> If you’re not already running LMS, install it on whatever always-on machine you have — a Raspberry Pi, a NAS with a Docker runtime, or a small Linux box is ideal.</p> # Debian/Ubuntu — grab the latest .deb from the community repo wget https://downloads.slimdevices.com/LogitechMediaServer_v8.x/logitechmediaserver_<latest>_amd64.deb sudo apt install ./logitechmediaserver_<latest>_amd64.deb sudo systemctl enable --now logitechmediaserver </code></pre> Or via Docker — lmscommunity/logitechmediaserver</code> is a maintained image:</p> docker run -d --name lms \ --network host \ -v lms-config:/config \ -v /path/to/music:/music:ro \ lmscommunity/logitechmediaserver:latest </code></pre> Open http://<host>:9000/</code> and you should see the LMS web UI. Your Squeezebox devices on the same LAN should appear under Players</strong> automatically.</p> 2. Install Spotty</h3> In the LMS web UI: Settings → Plugins → Install new plugins</strong> and tick Spotty</strong> (author: Michael Herger). LMS downloads, installs, and restarts. On restart, you’ll have a Spotty</strong> entry in Settings → Advanced → Spotty</strong>.</p> 3. Authorise Spotty with your Spotify account</h3> In Settings → Advanced → Spotty</strong>, click Add account</strong>.</li> Spotty kicks off an OAuth flow via Spotify’s Web API — you log in once in a browser, approve the access, and the token is stored on the LMS server.</li> You need Spotify Premium</strong> for playback. (This is a Spotify-side limit: librespot</code> can authenticate with Free, but full-quality playback is Premium-only.)</li> </ul> 4. Play something</h3> On the Squeezebox device itself, Home → My Music → Spotty</strong> (or Home → Music Library → Spotty</strong>, depending on your LMS version) — browse playlists, search, start a track. On the Squeezebox Touch the on-screen artwork works. On the Classic the text UI works. On the Radio and Boom you drive it from the web UI or the Squeeze Commander</a> / Squeezer</a> apps.</p> Spotty also adds Squeezebox devices as Spotify Connect targets</strong> — meaning you can cast from your phone’s Spotify app to “Living Room Squeezebox” natively, the same way you’d cast to a Sonos or a Google Home.</p> Path 2: spotifyd as a Connect bridge</h2> Use this if Spotty won’t install (old LMS version, old Perl, weird OS) or you specifically want Spotify Connect behaviour without Spotty.</p> # Debian/Ubuntu sudo apt install spotifyd # or from source: cargo install spotifyd </code></pre> Configure /etc/spotifyd.conf</code> with your Spotify credentials, a backend (alsa</code>, pulseaudio</code>, or pipe</code>), and a device name. Start the daemon:</p> sudo systemctl enable --now spotifyd </code></pre> From your phone, cast to the spotifyd</code>-named device. Audio comes out of the host.</p> To get that audio into a Squeezebox, pipe spotifyd</code> to a FIFO and play the FIFO in LMS:</p> # spotifyd.conf backend = "pipe" device = "/var/run/spotifyd.pipe" </code></pre> Then in LMS: add the FIFO as a File system music folder</strong> and play it as a live stream.</p> This is clunkier and has ~1 s of latency vs. Spotty’s tight integration. Only use it if Path 1 doesn’t work for you.</p> Works on which Squeezebox?</h2> Spotty works on every Squeezebox device that talks to LMS:</p> Squeezebox Classic / Squeezebox v3</strong> (text display) — text-UI browsing and playback.</li> Squeezebox Touch</strong> — colour touchscreen, artwork, the whole UI.</li> Squeezebox Boom</strong> — text UI, same as Classic.</li> Squeezebox Radio</strong> — text UI, built-in speaker.</li> Squeezebox Duet / Controller</strong> — the controller’s UI works; playback goes to the Receiver.</li> Transporter</strong> — full support.</li> piCorePlayer / SqueezeLite on Pi</strong> — yes, these are software Squeezeboxes and Spotty streams to them fine.</li> </ul> As long as the device can connect to LMS, Spotty can feed it.</p> FAQ</h2> Do I need Spotify Premium?</h3> Yes, for playback. librespot</code> (and therefore Spotty) requires a Premium account to decode audio. Spotify Free accounts can authenticate but won’t play.</p> Does Spotify Connect “appear the Squeezebox as a speaker” work?</h3> Yes, with Spotty installed. Each Squeezebox player shows up in the Spotify app’s device picker as a Connect target.</p> Does hi-res / lossless work?</h3> Spotify itself doesn’t offer lossless on standard plans (Hi-Fi has been “coming soon” for years). Spotty plays whatever Spotify serves — Ogg Vorbis 320 kbps on Premium — and the Squeezebox handles it natively.</p> Gapless playback?</h3> Yes, Spotty supports gapless.</p> Does this break if Spotify’s Web API changes?</h3> Yes, occasionally — Spotify periodically rotates OAuth scopes or deprecates endpoints, and Spotty gets a patch release. Keep the plugin updated.</p> Can I run LMS on the same box as my NAS?</h3> Absolutely. LMS is lightweight (~200 MB RAM, minimal CPU except during library scans). Running it next to Samba or on a homelab SBC is the common setup.</p> Is this the same as “piCorePlayer”?</h3> piCorePlayer is a tiny Linux distribution that turns a Raspberry Pi into a Squeezebox-compatible player (via SqueezeLite). It does not replace LMS — you still need LMS as the server. piCorePlayer + LMS + Spotty is a very common 2026 stack for people whose original Squeezebox hardware finally died.</p> What to do if your Squeezebox won’t connect to LMS at all</h2> Two things to check first:</p> mDNS / multicast across your network.</strong> Modern Wi-Fi routers often block multicast between SSIDs or to wired hosts. Put the Squeezebox and LMS on the same subnet/VLAN with multicast allowed.</li> SlimProto port (3483/udp and 3483/tcp).</strong> That’s what the Squeezebox uses to find LMS. Not blocked by anything sensible, but worth checking if you run a strict firewall.</li> </ol> Beyond that, the Squeezebox community is still active — forums.slimdevices.com</a> and the LMS Community GitHub</a> are where problems get solved.</p> Squeezebox hardware was discontinued fifteen years ago. Thanks to LMS, Spotty, and librespot</code>, it still plays Spotify better than most “smart speakers” sold new in 2026.</p> elpriser.org — Danish hourly electricity prices 2026-04-20T00:00:00+00:00 TL;DR —</strong> elpriser.org</a> shows the real, all-in hourly price of electricity in Denmark</strong> — not just the spot price. It combines the Nord Pool spot price, your local grid tariff (netselskab</code>), Energinet’s system and transmission tariffs, the state electricity tax (elafgift</code>), and 25% VAT. Data comes from Energi Data Service</a> and updates daily after Nord Pool publishes the next 24 hours around 13:00. DK1 (Vestdanmark) and DK2 (Østdanmark). Danish-language, free, no login.</p> What does Danish electricity actually cost?</h2> The “spot price” you see on most energy dashboards is only one component. The price you actually pay per kWh is made up of six parts:</p> Spot price</strong> — set hourly on the Nord Pool wholesale market for the following day.</li> Grid tariff (nettarif)</strong> — paid to your local grid operator (netselskab</code>). Varies by company and by time-of-day (off-peak, shoulder, peak).</li> System tariff (systemtarif)</strong> — paid to Energinet, the Danish TSO.</li> Transmission tariff (transmissionstarif)</strong> — also paid to Energinet.</li> Electricity tax (elafgift)</strong> — a state tax on consumption.</li> VAT (moms)</strong> — 25% applied on top of everything else.</li> </ol> Most price sites show the first number. A few show one or two more. None that I could find showed all six, hour by hour, for both price zones, with the correct grid tariff automatically picked for the user’s netselskab</code>. That’s what elpriser.org does.</p> The two price zones: DK1 and DK2</h2> Denmark is split into two electricity price zones by geography — the Great Belt separates them — and they often have different prices at the same hour:</p> DK1 — Vestdanmark.</strong> Jylland and Fyn. More wind-dominated.</li> DK2 — Østdanmark.</strong> Sjælland, Lolland, Falster, Møn, Bornholm. More interconnected with Sweden (SE4) and Germany.</li> </ul> When the wind blows hard in Jylland, DK1 can be cheap while DK2 is pricey. When an interconnector is down, the gap widens further. elpriser.org shows both zones side by side.</p> Which netselskab are you on?</h2> You cannot choose your netselskab</code> — it depends on where you live — but the grid tariff they charge is a significant chunk of your bill, and it varies by 15–25 øre/kWh at peak</strong> between the cheapest and the most expensive, which works out to ~500–1,000 kr/year</strong> for a typical household.</p> Rough ranking of peak (spidslast) tariffs as of 2025:</p> Zone</th> Netselskab</th> Peak tariff (øre/kWh)</th></tr></thead> DK1</td> RAH Net</td> ~33</td></tr> DK1</td> Trefor</td> ~37</td></tr> DK1</td> N1</td> ~46</td></tr> DK2</td> Cerius</td> ~47</td></tr> DK2</td> Radius</td> ~65</td></tr> </tbody></table> Smaller operators (Konstant, Nord Energi, Vores Elnet, El-net Kongerslev, and others) each have their own tariffs. elpriser.org lets you pick yours; the all-in hourly price adjusts accordingly.</p> You can’t switch netselskab</code>, but you can</strong> shift consumption — laundry, dishwasher, EV charging, heat-pump heating — into the low-tariff hours. The hourly chart exists for exactly that.</p> Historical extremes</h2> Record high:</strong> 16.69 kr/kWh (spot price, excl. VAT) in DK2, at 19:00 on 5 September 2022, during the European energy crisis.</li> Record low:</strong> −2.76 kr/kWh in DK1, at 14:00 on 2 July 2023, when wind production overshot demand.</li> </ul> Negative prices are not a bug: when production is high and demand is low, producers pay consumers to absorb the surplus. Modern price-aware heat pumps and EV chargers can lean into this.</p> How elpriser.org is built</h2> Static HTML</strong>, regenerated once per day after Nord Pool’s next-day publication around 13:00 CET.</li> Data source</strong>: Energi Data Service</a>, the open-data service from Energinet. No API keys required.</li> Structured data</strong>: schema.org/WebApplication</code> and FAQPage</code> are emitted on every page so Google can surface the prices directly in search results and AI overviews.</li> Hosting</strong>: a small origin behind Cloudflare. Cacheable for the full day; purged on the daily rebuild.</li> Language</strong>: Danish only. The domain name should have been a hint.</li> </ul> The whole thing is a single-purpose tool: no tracking, no login, no newsletter popover, no “10 ways to save on your electricity bill” listicles.</p> FAQ</h2> How often does elpriser.org update?</h3> Once a day, after the Nord Pool day-ahead auction publishes next-day prices around 13:00 CET. Intraday adjustments are not shown; most consumers are billed against the day-ahead price anyway.</p> Is the price shown with or without VAT?</h3> With. The headline number on elpriser.org is the all-in price per kWh: spot + tariffs + tax + 25% VAT. You can toggle to see the breakdown.</p> Why are prices in DK1 and DK2 different?</h3> Denmark has two physically separated electricity areas joined by the Great Belt interconnector. When the interconnector is fully used or wind production differs sharply between east and west, the two zones clear at different Nord Pool prices.</p> Can I see the breakdown of each component?</h3> Yes. Every hourly cell can be expanded to show spot price, each tariff component, elafgift, and VAT.</p> Do I really pay negative prices when the wholesale price goes negative?</h3> It depends on your contract. Pure spot-price contracts pass the raw Nord Pool price through — tariffs and tax still apply, so the all-in price can go slightly negative or just very low. Fixed-price contracts don’t.</p> Why Danish only?</h3> The data, the regulatory rules, the netselskab</code> structure, and the target audience are all Danish. An English version would be translating context, not content.</p> Where does the data come from?</h3> Energi Data Service</a> (Nord Pool spot) and Energinet’s tariff data. Both are official public data sets from the Danish TSO.</p> Small, focused, no login, no tracking. The way consumer energy tools should look.</p> winniemethmann.com — from WordPress to Astro 2026-04-19T00:00:00+00:00 TL;DR —</strong> winniemethmann.com</a> is the portfolio of a Danish food photographer and recipe developer. It was a WordPress site for a decade. I rebuilt it on Astro</a>, using content collections</strong> (typed Markdown) instead of a CMS, Sharp + AVIF</strong> for the image pipeline, and Astro’s i18n routing</strong> (Danish default, English at /en/</code>). Build time: ~30 seconds. Output size: ~70% smaller. No more admin panel, no more plugin updates, no more bot-probed login endpoint.</p> Why move off WordPress</h2> For a portfolio that changes a few times a month, WordPress was doing too much work:</p> PHP runtime and MySQL</strong> for a site that is functionally static.</li> Dozens of plugins</strong> for image galleries, contact forms, SEO, caching — each with its own update cadence and security disclosures.</li> A half-forked theme</strong> that had accumulated patches nobody remembered why.</li> An admin login endpoint</strong> that was probed several thousand times a day by bots.</li> Regular caching headaches</strong> every time the CDN and the plugins disagreed.</li> </ul> Concretely, dropping WordPress meant:</p> No admin panel to keep patched.</strong> WordPress core releases, plugin updates, theme updates — gone.</li> No database.</strong> Content lives as Markdown in the repo.</li> No login surface for bots to probe.</strong> There’s no /wp-admin/</code> anymore.</li> ~10× faster page loads</strong> with no caching layer required.</li> ~70% smaller total build size</strong>, swapping hand-exported JPEGs for AVIF at sensible srcset</code> breakpoints.</li> </ul> The tradeoff is that non-technical editing goes away. In practice that did not matter: the site owner was happier editing Markdown than fighting the WordPress block editor.</p> Why Astro</h2> I considered Hugo, 11ty, Next.js static export, and SvelteKit. Astro won on three specific points:</p> Content collections.</strong> A typed, schema-checked way to describe a portfolio project as a directory of photos plus some front-matter. Build fails loudly if anything is malformed. No CMS required.</li> The <Image></code> component.</strong> Astro’s built-in image pipeline handles AVIF + JPEG fallback + srcset</code> + width</code>/height</code> attributes with a one-liner. Sharp is the engine under the hood.</li> Islands architecture, not relevant here.</strong> The site has no interactive components, so it ships basically zero JavaScript.</li> </ol> Content collections, not a CMS</h2> Each portfolio project is a directory under src/content/portfolio/</code> with a front-matter schema:</p> src/content/portfolio/ ├── 2024-cookbook-editorial/ │ ├── index.mdx │ ├── cover.jpg │ ├── 01.jpg, 02.jpg, … └── 2023-spring-catalogue/ ├── index.mdx ├── cover.jpg └── 01.jpg … </code></pre> index.mdx</code> front-matter declares the project title, category, year, and cover image. Astro enforces the schema at build time via defineCollection</code></a> with a Zod schema. If a project is missing a cover image or has a bad category, the build fails.</p> Categories used: food photography, recipe development, interior & garden styling, editorial, cookbooks, and fashion</strong>. Adding a new project is mkdir</code> + cp .jpg</code> + a short YAML front-matter block. No admin UI, no database migration, no cache to invalidate.</p> Image pipeline: Sharp + AVIF</h2> Food photography lives or dies on image quality. Astro’s <Image></code> component, powered by Sharp</a>, generates:</p> AVIF</strong> as the primary format. Roughly all modern browsers support it now (see caniuse</a>).</li> JPEG</strong> fallback with matching srcset</code> breakpoints (320, 640, 960, 1280, 1920 px).</li> Explicit width</code> and height</code> attributes, so there is zero cumulative layout shift while images load.</li> loading="lazy"</code> for below-the-fold images and fetchpriority="high"</code> for the hero.</li> </ul> Numbers</strong>: a typical portfolio page went from ~4.8 MB of hand-exported JPEGs to ~1.4 MB of AVIF — about a 70% reduction — with no visible quality loss at typical display sizes.</p> i18n — Danish default, English at /en/</h2> Astro’s i18n routing sits in astro.config.mjs</code>:</p> export default defineConfig({ i18n: { defaultLocale: "da", locales: ["da", "en"], routing: { prefixDefaultLocale: false }, }, }); </code></pre> That gives:</p> /</code> for Danish (the default, no prefix).</li> /en/</code> for English.</li> Each content entry declares its language via its collection and filename.</li> <link rel="alternate" hreflang></code> and the sitemap are generated from the same source.</li> </ul> Posts and portfolio entries that lack a translation simply don’t appear in the other locale’s routing — they don’t 404 to a wrong-language page.</p> Deployment and build</h2> Output</strong>: fully static, deployed as plain files behind Cloudflare.</li> Build time</strong>: ~30 seconds on a cold cache, ~6 seconds incrementally.</li> No server, no database, no runtime cost.</strong></li> </ul> Measurable outcomes</h2> Metric</th> WordPress (before)</th> Astro (after)</th></tr></thead> Build / deploy time</td> n/a (instant publish)</td> ~30s cold, ~6s warm</td></tr> Typical page size (portfolio page)</td> ~4.8 MB</td> ~1.4 MB</td></tr> Largest Contentful Paint</td> ~2.8 s</td> ~0.9 s</td></tr> Time to Interactive</td> ~3.5 s</td> ~1.1 s</td></tr> JS shipped</td> ~220 KB</td> ~0 KB</td></tr> Plugins to keep patched</td> 14</td> 0</td></tr> </tbody></table> FAQ</h2> Can a non-technical owner still edit the site?</h3> Yes, for copy. Editing Markdown in a GitHub web editor is, in practice, easier than the WordPress block editor. For new portfolio projects, the workflow is: drag images into a folder, write a short front-matter block, commit. If that’s too technical, a one-page admin (Decap CMS / Sveltia CMS / Keystatic) can be bolted on.</p> What about SEO after the migration?</h3> URLs were kept as-is wherever possible. Missing old paths redirect via Cloudflare rules. The sitemap is regenerated on every build, and structured data (Person</code>, ImageGallery</code>, Article</code>) is emitted per page.</p> Why Astro and not Hugo?</h3> Hugo is faster and simpler for pure blogging, but Astro’s typed content collections and first-class <Image></code> component won this case. For x2q.net</a> itself, I later went with Zola — for a portfolio with a heavy image pipeline, Astro remained the better fit.</p> How do images stay organised?</h3> Each portfolio project owns its own folder. The Git repo is the CMS. git log</code> tells you when an image was added and why.</p> Is the build deterministic?</h3> Yes. Given the same inputs, the output is byte-for-byte identical. Sharp is pinned in package.json</code>; so is Astro. CI runs on Node LTS.</p> If you’re on a WordPress site that’s doing far less than its infrastructure suggests, Astro is worth the afternoon it takes to try.</p> apextowww.com — a free apex-to-www redirect service 2026-04-18T00:00:00+00:00 TL;DR —</strong> DNS does not allow CNAME</code> records at the zone apex (RFC 1034 §3.6.2</a>). That’s why hosts like Netlify, Vercel, Cloudflare Pages, Firebase, and Heroku ask you to configure www.example.com</code> with a CNAME</code> and leave example.com</code> (the apex) as a problem. apextowww.com</a> solves it: point two A</code> records and two AAAA</code> records at the service, and it issues a Let’s Encrypt certificate for your apex and 301</code>-redirects every request to https://www.yourdomain.tld/</code>, preserving path and query string. Free, no signup, no account.</p> Why you can’t put a CNAME on the apex</h2> The DNS spec is unambiguous: a zone apex (the “bare” domain like example.com</code>) must carry an SOA</code> record and usually NS</code> records. CNAME</code> is defined as an alias that must be the only record at a name, and it is forbidden to coexist with the SOA</code> and NS</code> records that the apex is required to have. That’s why you can CNAME www.example.com → mysite.netlify.app</code> but you cannot</strong> CNAME example.com → mysite.netlify.app</code>.</p> Workarounds exist, and all of them are a little awkward:</p> ALIAS / ANAME records.</strong> Proprietary to each DNS provider (Cloudflare, Route 53, DNSimple, NS1). They work by resolving the target behind the scenes and returning an A</code>/AAAA</code>. Fine if your DNS provider supports it; useless if it doesn’t.</li> Flattening at the provider level.</strong> Cloudflare’s “CNAME flattening” is this, done automatically for you.</li> Your own always-on VPS doing 301 → www</code>.</strong> This is what I was doing for multiple domains, and it’s both over-engineered and a small maintenance tax.</li> </ul> apextowww is the fourth option: somebody else’s always-on redirector, managed for you.</p> What apextowww does</h2> Exactly one thing: a 301 Moved Permanently</code> from https://yourdomain.tld/anything?x=y</code> to https://www.yourdomain.tld/anything?x=y</code>.</p> TLS</strong> is issued automatically on first request via the Let’s Encrypt HTTP-01 challenge. No ACME client to run yourself.</li> IPv4 + IPv6</strong> on dual-stack by design. Both apex records are required.</li> HTTP/1.1, HTTP/2, and HTTP/3</strong> are all served. The redirect itself is trivially small, so protocol version matters less, but it helps the first-paint story when the redirect is on the critical path.</li> Path and query string</strong> are preserved, so deep links keep working.</li> No signup, no login, no account.</strong> If your DNS is pointed correctly, it just works.</li> </ul> How to set it up</h2> Go to apextowww.com</a> and copy the current IP addresses (two IPv4, two IPv6).</li> In your DNS provider, set A</code> records on your apex pointing at the two IPv4 addresses. Remove any existing A</code> record at the apex.</li> Set AAAA</code> records on your apex pointing at the two IPv6 addresses.</li> Make sure www.yourdomain.tld</code> still points at your real host (CNAME to Netlify/Vercel/Pages/etc).</li> Wait for DNS to propagate. Visit http://yourdomain.tld/</code> — it should 301 to https://www.yourdomain.tld/</code>.</li> </ol> The apextowww site has per-platform walkthroughs at /netlify-apex-domain-redirect/</code>, /vercel-apex-domain-redirect/</code>, /cloudflare-pages-apex-redirect/</code>, /firebase-hosting-apex-redirect/</code>, and /heroku-apex-domain-redirect/</code>.</p> Stack</h2> Hetzner ARM64</strong> servers, for cheap, low-power compute. ARM64 is ~30% cheaper per vCPU at Hetzner than x86 and runs the redirector fine.</li> Caddy-style automatic TLS</strong> with Let’s Encrypt</strong> HTTP-01 challenges.</li> Dual-stack IPv4 + IPv6</strong>.</li> HTTP/1.1, HTTP/2, HTTP/3</strong>.</li> Public static marketing site</strong> on Cloudflare Pages, with per-platform guides in separate URL paths so they each rank independently on Google for “netlify apex redirect”, “vercel apex domain”, etc.</li> </ul> FAQ</h2> Can I use apextowww with Cloudflare DNS?</h3> Yes, but you’ll want Cloudflare’s proxy (orange cloud) off</strong> for the apex A</code>/AAAA</code> records. If the proxy is on, Cloudflare intercepts the request and Let’s Encrypt’s HTTP-01 challenge won’t reach apextowww. Once the certificate is issued and renewed, you don’t need to toggle anything manually; just keep it off.</p> Does apextowww support wildcards or redirecting subdomains other than www?</h3> No. The service only redirects the apex to www.</code>. Everything else stays on your real host.</p> What happens if the apextowww IPs change?</h3> You’ll need to update your DNS A</code>/AAAA</code> records. The operator publishes current IPs on the homepage and gives advance notice for changes. For a personal domain this is fine; for anything mission-critical, run your own redirector.</p> Is there a rate limit?</h3> There’s no published hard limit, but this is a free community service. If you’re serving millions of apex redirects a day, self-host.</p> Why not just use Cloudflare’s free plan?</h3> Cloudflare’s CNAME flattening at the apex is a perfectly reasonable alternative if your whole DNS is on Cloudflare. apextowww is useful when your DNS isn’t on Cloudflare, or when you want a host-agnostic redirector that works identically across domains.</p> Is it really free?</h3> Yes. The marginal cost per redirect on ARM64 is negligible. No ads, no tracking beyond basic logs, no upsell.</p> Why it exists</h2> Hosting platforms optimise for their own onboarding, not for the DNS truisms that trip up every new user. Sending people to a stranger’s VPS felt worse than running one myself. Now my own apex domains (including x2q.net</a>) point at apextowww, which means I could tear down the last little redirector VPS I still had running for historical reasons.</p> It’s the kind of project that isn’t interesting until you need it, and then it’s the only thing you need.</p> Print to PDF on Linux — set up a system-wide PDF printer with cups-pdf (2026) 2013-01-30T00:00:00+00:00 TL;DR —</strong> install cups-pdf</code></strong>, restart CUPS, and you get a virtual “PDF” printer</strong> that any application can print to. The files land in ~/PDF</code></strong> by default. On Debian/Ubuntu that’s sudo apt install printer-driver-cups-pdf && sudo systemctl restart cups</code>.</p> This post first went up here in 2013 as a two-line note — apt-get install cups-pdf</code>, restart CUPS, done. The tool is still the right answer in 2026, so here is the current, fuller version.</p> </blockquote> Do you even need this?</h2> Most Linux desktop apps already print to PDF on their own. GTK and KDE print dialogs (so Firefox, Chrome, LibreOffice, GNOME apps, etc.) have a built-in “Print to File → PDF”</strong> option. If that covers you, you’re done.</p> cups-pdf</code> earns its place when you want a real, system-wide printer queue</strong> rather than a per-app export:</p> Available to every</em> application, including ones that have no PDF export of their own.</li> Usable from the command line</strong> and scripts.</li> Shareable over the network</strong> from a headless server, so other machines can “print to PDF” to a central spool.</li> </ul> Install</h2> cups-pdf</code> is packaged on every mainstream distro:</p> # Debian / Ubuntu / Mint / Kali sudo apt install printer-driver-cups-pdf # older name: cups-pdf # Fedora sudo dnf install cups-pdf # Arch / Manjaro sudo pacman -S cups-pdf </code></pre> Then (re)start the CUPS daemon so it picks up the new backend:</p> sudo systemctl restart cups # systemd sudo service cups restart # older sysvinit </code></pre> The package’s post-install step normally registers the queue for you. That’s it — you can print to PDF now.</p> Verify the printer exists</h2> $ lpstat -p -d printer PDF is idle. enabled since ... </code></pre> You’re looking for a queue named PDF</code></strong> (sometimes Virtual_PDF_Printer</code>). If it isn’t there, add it by hand — first find the exact model string CUPS registered:</p> $ lpinfo -m \| grep -i pdf CUPS-PDF_opt.ppd Generic CUPS-PDF Printer (w/ options) </code></pre> …then create the queue with that model:</p> sudo lpadmin -p PDF -E -v cups-pdf:/ -m CUPS-PDF_opt.ppd </code></pre> Or do it in the GUI: Settings → Printers → Add</strong>, pick the Generic CUPS-PDF</em> printer.</p> Where the files go</h2> By default, output lands in ~/PDF/</code></strong> for the user who submitted the job. The location is set in /etc/cups/cups-pdf.conf</code>:</p> $ grep -i '^Out\\|^AnonDirName' /etc/cups/cups-pdf.conf Out ${HOME}/PDF AnonDirName /var/spool/cups-pdf/ANONYMOUS </code></pre> Change the Out</code> directive and sudo systemctl restart cups</code> to send PDFs somewhere else. Jobs that arrive without a resolvable home directory (e.g. from a shared network queue) collect under /var/spool/cups-pdf/</code>.</p> Print from the command line</h2> Once the queue exists, it’s a normal CUPS printer:</p> lp -d PDF report.txt # any printable file lpr -P PDF document.ps </code></pre> The resulting PDF shows up in ~/PDF</code>. Set a default page size if the wrong one keeps appearing:</p> lpoptions -p PDF -o media=A4 # or media=Letter </code></pre> Headless / network “print to PDF”</h2> On a server with no desktop you can still run the whole thing: install cups</code> + cups-pdf</code>, enable the daemon, and share the queue.</p> sudo systemctl enable --now cups sudo lpadmin -p PDF -o printer-is-shared=true </code></pre> With CUPS configured to listen on the network (Listen</code>/Allow</code> in /etc/cups/cupsd.conf</code>), other machines can add this IPP printer and “print to PDF” remotely — the PDFs collect in the spool on the server. Handy for appliances and apps that only know how to talk to a network printer.</p> Gotchas</h2> Nothing appears in ~/PDF</h3> Check the job actually completed and read the CUPS log:</p> lpstat -W completed -o sudo tail -n 50 /var/log/cups/error_log </code></pre> Then confirm the Out</code> path in /etc/cups/cups-pdf.conf</code> is what you expect.</p> Permission denied writing the PDF</h3> ~/PDF</code> has to be writable by the CUPS spool. If you print across a shared queue as another user, output lands under /var/spool/cups-pdf/<user></code> or …/ANONYMOUS</code> instead of your home directory.</p> Fedora: SELinux blocks the write</h3> If a job silently disappears on Fedora, check for an SELinux denial (sudo ausearch -m avc -ts recent</code>) — the cups-pdf</code> backend writing to a non-default directory is the usual trigger.</p> FAQ</h2> Do I need cups-pdf if I use GNOME, Firefox, or Chrome?</h3> Probably not — those export PDF directly from their print dialog. Reach for cups-pdf</code> when you want one system-wide queue, command-line/scripted output, or a network print-to-PDF server.</p> How do I print to PDF on Windows or macOS?</h3> You don’t need cups-pdf</code>. Windows has a built-in “Microsoft Print to PDF”</strong> printer; macOS has a PDF</strong> dropdown in every print dialog. This post is Linux-only — and, as the 2013 original put it, setting this up on Linux is the easy case.</p> What’s the difference between this and “Print to File”?</h3> “Print to File → PDF” in an app’s dialog is per-application and exports a single file. cups-pdf</code> is a genuine CUPS print queue: shared across apps, scriptable, and shareable over the network.</p> Which package name — cups-pdf or printer-driver-cups-pdf?</h3> On current Debian/Ubuntu the package is printer-driver-cups-pdf</code>; cups-pdf</code> is kept as a transitional name and still works. Fedora and Arch call it cups-pdf</code>.</p> Summary</h2> sudo apt install printer-driver-cups-pdf</code> (or your distro’s equivalent), then sudo systemctl restart cups</code>.</li> A virtual PDF</strong> printer appears; verify with lpstat -p -d</code>.</li> Output defaults to ~/PDF</code></strong>, configurable via Out</code> in /etc/cups/cups-pdf.conf</code>.</li> Print from any app’s dialog, from the CLI with lp -d PDF file</code>, or over the network from a headless box.</li> </ul> Create a real multi-resolution favicon.ico (2026) 2013-01-13T00:00:00+00:00 TL;DR —</strong> a .ico</code> file can contain multiple</em> image sizes in one file. Render 16/32/48px PNGs from a high-res source and combine them: magick 16.png 32.png 48.png favicon.ico</code>. Then add a modern favicon.svg</code> and an apple-touch-icon.png</code> for everything else.</p> This first went up here in 2013 with GIMP-by-hand instructions. The multi-resolution .ico</code> trick still matters, but in 2026 the command-line route is faster and an SVG favicon</strong> does most of the heavy lifting — both are below.</p> </blockquote> Why multi-resolution</h2> Most favicons are exported at a single 16×16 resolution. That looks fine in a tab but pixelated when a browser scales it up — bookmarks bars, the address bar on hi-DPI screens, pinned tabs, OS shortcuts. Browsers ask for different sizes (16, 32, 48…), and the .ico</code> container can hold all of them in one file, so the browser picks the best fit.</p> The command-line way (ImageMagick)</h2> Start from a square source image, at least 256×256</strong>. Rasterize the sizes you want, then pack them into one .ico</code>.</p> From a PNG source:</p> magick source.png -resize 16x16 /tmp/16.png magick source.png -resize 32x32 /tmp/32.png magick source.png -resize 48x48 /tmp/48.png magick /tmp/16.png /tmp/32.png /tmp/48.png favicon.ico </code></pre> ImageMagick’s own SVG rasterizer is flaky — if your source is an SVG, render the PNGs with rsvg-convert</code> first, then combine:</p> rsvg-convert -w 16 -h 16 logo.svg -o /tmp/16.png rsvg-convert -w 32 -h 32 logo.svg -o /tmp/32.png rsvg-convert -w 48 -h 48 logo.svg -o /tmp/48.png magick /tmp/16.png /tmp/32.png /tmp/48.png favicon.ico </code></pre> Verify the .ico</code> really contains all three sizes:</p> magick identify favicon.ico favicon.ico[0] ICO 16x16 ... favicon.ico[1] ICO 32x32 ... favicon.ico[2] ICO 48x48 ... </code></pre> The GIMP way (no ImageMagick)</h2> Open your square, high-res source in GIMP.</li> Image → Canvas Size</strong> to make it perfectly square if it isn’t.</li> Image → Scale Image</strong> to 48×48, then Layer → Duplicate</strong> and scale copies to 32×32 and 16×16, so you have one layer per size.</li> File → Export As → favicon.ico</code></strong>. GIMP writes each layer as a resolution inside the single .ico</code>.</li> </ol> The modern half: SVG + apple-touch-icon</h2> In 2026 the .ico</code> is the legacy fallback. Modern browsers prefer a crisp, scalable SVG favicon</strong>, and iOS wants a PNG apple-touch-icon</strong>. Ship all three:</p> rsvg-convert -w 180 -h 180 -b "#fff" logo.svg -o apple-touch-icon.png </code></pre> Then in your <head></code>:</p> <link rel="icon" href="/favicon.ico" sizes="32x32"> <link rel="icon" type="image/svg+xml" href="/favicon.svg"> <link rel="apple-touch-icon" href="/apple-touch-icon.png"> </code></pre> The sizes="32x32"</code> hint on the .ico</code> tells modern browsers “there’s something better here” so they reach for the SVG, while older ones fall back to the multi-resolution .ico</code>.</p> FAQ</h2> Do I still need favicon.ico if I have an SVG?</h3> Yes, as a fallback. Older browsers and a lot of link-preview/scraper bots only look for /favicon.ico</code> at the site root, so keep it there.</p> What sizes should the .ico contain?</h3> 16, 32, and 48 cover essentially everything in practice. You can</em> add 64 and 128, but they mostly just inflate the file — the SVG handles large sizes better.</p> Why does my favicon not update?</h3> Browsers cache favicons aggressively. Hard-refresh, or append a one-off query string while testing (/favicon.ico?v=2</code>).</p> Summary</h2> A .ico</code> holds multiple sizes; bake in 16/32/48 with magick 16.png 32.png 48.png favicon.ico</code>.</li> Rasterize SVG sources with rsvg-convert</code> first (ImageMagick’s SVG support is unreliable).</li> Pair the .ico</code> with a modern favicon.svg</code> + apple-touch-icon.png</code> and three <link></code> tags.</li> </ul> Pretty-print XML on the command line with xmllint (2026) 2012-11-20T00:00:00+00:00 TL;DR —</strong> xmllint --format file.xml</code> pretty-prints XML. Read from a pipe with -</code>, control indentation with XMLLINT_INDENT</code>, and write back with --output</code>. It ships with libxml2</strong>, so it’s almost certainly already installed.</p> This one first went up here in 2012 — I was poking at a Visa 3-D Secure</strong> test directory that answered in single-line XML and needed it readable. The tool hasn’t changed; the flags below are the current, double-dash forms.</p> </blockquote> The problem</h2> API responses come back as one unreadable line. Here’s the kind of thing a payment directory server hands you:</p> <?xml version="1.0" encoding="UTF-8"?><ThreeDSecure><Message><VERes><version>1.0.2</version><CH><enrolled>Y</enrolled></CH><url>https://acs.example/PIT/ACS</url></VERes></Message></ThreeDSecure> </code></pre> Format a file</h2> xmllint --format response.xml </code></pre> That writes the indented version to stdout. To overwrite (or write a new file):</p> xmllint --format response.xml --output response.pretty.xml </code></pre> Format a stream (the useful one)</h2> Pass -</code> as the filename to read stdin, so you can pretty-print straight from curl</code>:</p> curl -s https://api.example/thing \| xmllint --format - </code></pre> <?xml version="1.0" encoding="UTF-8"?> <ThreeDSecure> <Message> <VERes> <version>1.0.2</version> <CH> <enrolled>Y</enrolled> </CH> <url>https://acs.example/PIT/ACS</url> </VERes> </Message> </ThreeDSecure> </code></pre> Control the indentation</h2> By default xmllint</code> indents with two spaces. Override it with the XMLLINT_INDENT</code> environment variable — set it to spaces or a tab:</p> XMLLINT_INDENT=" " xmllint --format response.xml # 4 spaces XMLLINT_INDENT=$'\t' xmllint --format response.xml # tabs </code></pre> Recover broken XML</h2> If the document is slightly malformed (a stray entity, a missing close tag from a truncated download), add --recover</code> to format what it can instead of bailing:</p> xmllint --recover --format broken.xml </code></pre> While you’re there: validate</h2> xmllint</code> isn’t just a formatter. Check well-formedness (exit code 0 = OK), or validate against a schema:</p> xmllint --noout response.xml # well-formed? xmllint --noout --schema schema.xsd response.xml # valid against XSD? xmllint --noout --dtdvalid doc.dtd response.xml # valid against DTD? </code></pre> Install (if it’s somehow missing)</h2> sudo apt install libxml2-utils # Debian / Ubuntu sudo dnf install libxml2 # Fedora brew install libxml2 # macOS (then use the keg's bin) </code></pre> FAQ</h2> How do I minify XML instead of pretty-printing it?</h3> Use --noblanks</code>: xmllint --noblanks file.xml</code> strips the insignificant whitespace.</p> Can I extract a single value instead of formatting the whole thing?</h3> Yes — xmllint --xpath '//url/text()' response.xml</code> pulls out a node with XPath. Handy for scripting against XML APIs.</p> What about JSON?</h3> xmllint</code> is XML-only. For JSON, jq .</code> is the equivalent (“jq</code> for XML” is roughly xmllint --format</code>).</p> Summary</h2> xmllint --format file.xml</code> — pretty-print a file.</li> … \| xmllint --format -</code> — pretty-print a stream.</li> XMLLINT_INDENT</code> — set the indent.</li> --recover</code>, --noout --schema</code>, --xpath</code> — fix, validate, and query.</li> </ul> Mount a BIN/CUE disc image on Linux (2026) 2012-10-16T00:00:00+00:00 TL;DR —</strong> you can’t mount</code> a BIN/CUE pair straight away. Convert it: bchunk image.bin image.cue out</code> produces an ISO you can loop-mount. For discs with audio tracks or copy protection, use cdemu</strong> to emulate a drive instead.</p> A 2012 note, still accurate. BIN/CUE images are everywhere (old game/VCD rips), and the loop-mount confusion is perennial. See also the companion post on bchunk itself</a> if you just need the conversion.</p> </blockquote> Why you can’t just mount it</h2> A .bin</code> is a raw CD sector dump and the .cue</code> is a text sheet describing its track layout. The kernel’s loopback mounter understands filesystem images (ISO9660, etc.), not raw sector dumps with a separate cue sheet — so mount image.bin</code> fails. You bridge the gap one of two ways.</p> Option 1 — convert to ISO with bchunk (data discs)</h2> bchunk</code> (binchunker) converts a .bin</code>/.cue</code> set into .iso</code> (data) and .cdr</code> (audio) tracks.</p> sudo apt install bchunk # Debian / Ubuntu sudo dnf install bchunk # Fedora </code></pre> Convert — the last argument is the output basename</em>, so this writes out01.iso</code>:</p> bchunk image.bin image.cue out </code></pre> Then loop-mount the ISO:</p> sudo mount -o loop,ro -t iso9660 out01.iso /mnt ls /mnt sudo umount /mnt </code></pre> This is the right tool when the image is a single data track — most software/VCD rips.</p> Option 2 — emulate a drive with cdemu (audio / mixed-mode)</h2> If the disc has audio tracks, multiple sessions, or anything bchunk’s flat conversion would mangle, emulate a real optical drive with cdemu</strong>. It loads the .cue</code> directly and exposes a virtual /dev/sr</code> device the desktop auto-mounts.</p> sudo apt install cdemu-client gcdemu # Debian / Ubuntu (universe) cdemu load 0 image.cue # load into virtual drive 0 cdemu status # the virtual disc now appears like a real one; eject with: cdemu unload 0 </code></pre> cdemu handles audio and mixed-mode discs that a straight ISO conversion can’t represent.</p> Option 3 — just extract the files</h2> If you don’t need a mounted volume, 7-Zip</strong> can list and extract straight from many BIN/CUE data images:</p> 7z l image.cue # list contents 7z x image.cue # extract here </code></pre> FAQ</h2> bchunk wrote a .iso and several .cdr files — what are those?</h3> The .cdr</code> files are the raw audio tracks. Convert one to WAV with sox track.cdr track.wav</code> (it’s headerless CD-DA), or ignore them if you only wanted the data track.</p> mount says “wrong fs type” on the converted ISO</h3> The image may not be ISO9660 (e.g. a UDF or game-console format). Drop the -t iso9660</code> and let the kernel autodetect: sudo mount -o loop,ro out01.iso /mnt</code>. Console images often need a dedicated emulator instead.</p> Can I do this on macOS?</h3> bchunk</code> is in Homebrew (brew install bchunk</code>); convert to ISO, then hdiutil attach out01.iso</code>.</p> Summary</h2> BIN/CUE won’t loop-mount directly.</li> Data disc → bchunk image.bin image.cue out</code> then mount -o loop out01.iso /mnt</code>.</li> Audio/mixed-mode → load the .cue</code> in cdemu</strong>.</li> Just need the files → 7z x image.cue</code>.</li> </ul> sudo without a password on Ubuntu/Debian — safely (2026) 2012-10-11T00:00:00+00:00 TL;DR —</strong> don’t edit /etc/sudoers</code> directly. Create a validated drop-in: sudo visudo -f /etc/sudoers.d/nopasswd</code> and add youruser ALL=(ALL) NOPASSWD: ALL</code>. Better yet, scope it to the specific commands</em> you actually need to run unattended.</p> A 2012 note, refreshed. The mechanism is unchanged, but in 2026 the right move is a drop-in file under /etc/sudoers.d/</code> (not editing the main file), and scoping the rule rather than handing out blanket root.</p> </blockquote> Always use visudo</h2> sudo</code> reads /etc/sudoers</code> and every file in /etc/sudoers.d/</code>. visudo</code> syntax-checks before saving</strong> — a typo in sudoers</code> can lock you out of sudo</code> entirely, so never edit these files with a plain editor.</p> Edit a dedicated drop-in (keeps your change out of the distro-managed main file):</p> sudo visudo -f /etc/sudoers.d/nopasswd </code></pre> Single user</h2> Add this line (swap in your username):</p> alice ALL=(ALL) NOPASSWD: ALL </code></pre> A group instead</h2> On Ubuntu, members of the sudo</code> group get admin rights (it’s wheel</code> on Fedora/RHEL). Make the whole group passwordless:</p> %sudo ALL=(ALL) NOPASSWD: ALL </code></pre> The version you should actually use: scope it</h2> Blanket NOPASSWD: ALL</code> means anything that can run as that user can now become root with no further check — a real escalation risk. For automation, grant only the commands the job needs:</p> # deploy user may restart one service and nothing else, no password deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/systemctl status myapp </code></pre> This is the difference between “convenient” and “convenient and</em> defensible”.</p> Apply and test</h2> Files in /etc/sudoers.d/</code> are picked up immediately — no reload needed. Validate the whole config and test in a way that won’t strand you:</p> sudo visudo -c # syntax-check every sudoers file sudo -k # clear the cached credential sudo -n true && echo "passwordless works" </code></pre> Keep your current root shell open until you’ve confirmed it works in a second</em> terminal.</p> Gotchas</h2> Filenames matter.</strong> sudo</code> ignores files in /etc/sudoers.d/</code> with a .</code> or ~</code> in the name (so nopasswd.conf</code> is silently skipped). Use a plain name like nopasswd</code>.</li> Permissions matter.</strong> The file must be 0440</code> and owned by root; visudo -f</code> sets this for you. A wrong mode makes sudo refuse to start.</li> Order matters.</strong> Later rules win. A broad NOPASSWD: ALL</code> after a narrow rule re-opens everything.</li> </ul> FAQ</h2> Is passwordless sudo a security risk?</h3> Blanket NOPASSWD: ALL</code> removes the last speed-bump between a compromised user account and root. Fine on a throwaway lab VM; scope it (or skip it) on anything that matters. Command-scoped rules are the compromise.</p> How do I require a password again?</h3> Delete the drop-in (sudo rm /etc/sudoers.d/nopasswd</code>) or remove the NOPASSWD:</code> keyword from the line.</p> Why does it still ask for a password?</h3> Another rule later in the chain overrides yours, the filename contains a .</code>/~</code> (so it’s ignored), or you edited /etc/sudoers</code> but a drop-in re-requires it. Run sudo visudo -c</code> and check /etc/sudoers.d/</code> for conflicting files.</p> Summary</h2> Edit a drop-in with sudo visudo -f /etc/sudoers.d/nopasswd</code> — never the main file by hand.</li> user ALL=(ALL) NOPASSWD: ALL</code> for a user, %sudo …</code> for a group.</li> Scope to specific commands for anything beyond a lab box. Validate with visudo -c</code>.</li> </ul> View the contents of a CSR with OpenSSL (2026) 2010-07-04T00:00:00+00:00 TL;DR —</strong> openssl req -in host.csr -noout -text -verify</code> decodes a certificate signing request into human-readable form and checks its signature. Use it to confirm the CN, the SANs, and the key before you hand the CSR to a CA.</p> This is one of the oldest notes on this blog (2010). OpenSSL’s CLI is famously sprawling, and “how do I just read</em> a CSR” is a question that never goes away — so here’s the refreshed version.</p> </blockquote> What a CSR is</h2> A Certificate Signing Request (CSR)</strong> is what you send to a Certificate Authority (CA) to be signed. It bundles your public key plus the identity you’re requesting (the subject: common name, organisation, and — the part that actually matters now — the Subject Alternative Names</strong>), all signed by your private key. The CA signs it and hands back a certificate.</p> Read it</h2> openssl req -in host.csr -noout -text -verify </code></pre> -in host.csr</code></strong> — the request file.</li> -noout</code></strong> — don’t re-print the encoded CSR, just the decoded info.</li> -text</code></strong> — human-readable output.</li> -verify</code></strong> — check the CSR’s self-signature (catches a corrupted or tampered request).</li> </ul> You’ll get something like:</p> Certificate Request: Data: Version: 1 (0x0) Subject: C=DK, ST=Capital, L=Copenhagen, O=Example ApS, CN=example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Requested Extensions: X509v3 Subject Alternative Name: DNS:example.com, DNS:www.example.com Signature Algorithm: sha256WithRSAEncryption </code></pre> Check three things before sending it off: the CN/subject</strong> is right, the SANs</strong> list every hostname the cert must cover (modern browsers ignore the CN and only trust SANs), and the key size/algorithm</strong> meets the CA’s minimum (2048-bit RSA or an EC key).</p> Pull out just one field</h2> When you only need the subject or the SANs (e.g. in a script):</p> openssl req -in host.csr -noout -subject openssl req -in host.csr -noout -text \| grep -A1 "Subject Alternative Name" </code></pre> Verify a CSR matches its private key</h2> A common cutover mistake is generating the CSR from the wrong key. The modulus (RSA) of the CSR, the key, and the eventual certificate must all match. Compare hashes:</p> openssl req -in host.csr -noout -modulus \| openssl md5 openssl rsa -in host.key -noout -modulus \| openssl md5 openssl x509 -in host.crt -noout -modulus \| openssl md5 </code></pre> All three digests identical → they belong together. Any mismatch → you’ve got the wrong key (or wrong cert) and TLS will fail to start.</p> Generate a CSR (for completeness)</h2> openssl req -new -newkey rsa:2048 -nodes \ -keyout host.key -out host.csr \ -subj "/C=DK/O=Example ApS/CN=example.com" \ -addext "subjectAltName=DNS:example.com,DNS:www.example.com" </code></pre> -addext subjectAltName=…</code> is the part people forget — without SANs the request is useless to a modern CA.</p> FAQ</h2> How do I read a CSR that’s in DER (binary), not PEM?</h3> Add -inform der</code>: openssl req -in host.der -inform der -noout -text</code>.</p> Can I paste a CSR online to decode it?</h3> You can, but don’t get in the habit — a CSR contains your public key and identity, and the paste site sees all of it. Decoding locally with OpenSSL leaks nothing.</p> What’s the difference between a CSR and a certificate?</h3> The CSR is the request</em> (your public key + identity, self-signed). The certificate is the CA’s signed answer</em>. Read a certificate with openssl x509 -in host.crt -noout -text</code>.</p> Summary</h2> Read: openssl req -in host.csr -noout -text -verify</code>.</li> Check the SANs</strong>, not just the CN — that’s what browsers trust.</li> Confirm key/CSR/cert belong together by comparing -modulus \| openssl md5</code>.</li> </ul> Inspect and verify a TLS certificate with OpenSSL (2026) 2009-05-06T00:00:00+00:00 TL;DR —</strong> openssl x509 -in cert.crt -noout -text</code> dumps a certificate in readable form. Compare -modulus \| openssl md5</code> of the cert and the key to confirm they match. Use openssl s_client -connect host:443</code> to see what a live server serves.</p> Two short 2009 notes (“view x509 details” and “verify a cert matches a key”), merged and refreshed into one. Companion to reading a CSR</a> and removing a key passphrase</a>.</p> </blockquote> View a certificate</h2> openssl x509 -in filename.crt -noout -text </code></pre> filename</code> is the X.509 file — typically .crt</code>, .cert</code>, .pem</code>. -noout</code> skips re-printing the encoded blob; -text</code> gives the human-readable view: subject, issuer, validity dates, key, and extensions.</p> Pull out just the fields you care about:</p> openssl x509 -in cert.crt -noout -subject -issuer -dates openssl x509 -in cert.crt -noout -ext subjectAltName # the SANs openssl x509 -in cert.crt -noout -fingerprint -sha256 </code></pre> The SANs</strong> are the part that matters most now — browsers ignore the CN and only trust the Subject Alternative Names, so confirm every hostname is listed.</p> Verify a certificate matches a private key</h2> The classic cutover failure: the cert and key don’t belong together, and TLS refuses to start. The certificate, key (and CSR) share the same public modulus — compare hashes:</p> (openssl x509 -noout -modulus -in server.crt \| openssl md5; \ openssl rsa -noout -modulus -in server.key \| openssl md5) \| uniq </code></pre> One line of output → they match. Two lines → they don’t</strong> (uniq</code> collapses identical hashes). For an EC key, compare the public keys instead:</p> diff <(openssl x509 -in server.crt -noout -pubkey) \ <(openssl ec -in server.key -pubout) </code></pre> No diff → they match.</p> Inspect what a live server is serving</h2> To see the certificate an HTTPS host actually presents (expiry, chain, SANs):</p> openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \ \| openssl x509 -noout -subject -issuer -dates -ext subjectAltName </code></pre> -servername</code> sends SNI, so you get the right cert on a multi-site host. Quick expiry check:</p> echo \| openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ \| openssl x509 -noout -enddate </code></pre> Other formats</h2> openssl x509 -in cert.der -inform der -noout -text # DER (binary) openssl pkcs12 -in cert.pfx -info -nodes # inspect a .pfx/.p12 bundle </code></pre> FAQ</h2> “No certificate matches private key” — what now?</h3> The cert and key are from different keypairs. Run the modulus check above; if the hashes differ, find the key that was used to generate this cert’s CSR (or reissue the cert from the key you have).</p> How do I check the full chain?</h3> openssl verify -untrusted intermediate.crt server.crt</code>, or inspect what s_client</code> returns with -showcerts</code> to see every cert the server sends.</p> When does this cert expire, across many hosts?</h3> Script the s_client … -enddate</code> one-liner over a host list — it’s the no-dependencies way to monitor expiry.</p> Summary</h2> View: openssl x509 -in cert.crt -noout -text</code> (and -subject -dates -ext subjectAltName</code>).</li> Match cert↔key: compare -modulus \| openssl md5</code> — one line = match.</li> Live server: openssl s_client -connect host:443 -servername host</code>.</li> </ul> Recover RAR, 7z, and ZIP archive passwords on Linux (2026) 2009-03-22T00:00:00+00:00 TL;DR —</strong> extract a hash with rar2john</code> / 7z2john</code> / zip2john</code>, then crack it with hashcat</code> (GPU) or john</code>. Dictionary attack first, then a targeted mask. This replaces the old rarcrack</code> tool, which is unmaintained and CPU-only.</p> The 2009 version of this post used rarcrack</strong> — abandoned for over a decade. The modern, far faster approach is John the Ripper’s hash extractors + hashcat on a GPU. For the ZIP-specific deep dive, see the fcrackzip post</a>; this one covers RAR and 7z too. Only do this on archives you own or are authorised to access.</p> </blockquote> The two-step approach</h2> Modern crackers don’t attack the archive directly. You extract a hash</strong> that represents the password check, then throw a cracker at the hash. The extractors ship with John the Ripper:</p> sudo apt install john # provides rar2john, zip2john, and the 2john scripts sudo apt install hashcat # GPU-accelerated cracker </code></pre> RAR</h2> rar2john archive.rar > hash.txt cat hash.txt </code></pre> The hash format tells you the RAR version. Pick the hashcat mode:</p> # RAR3 (-hp, older): hashcat -m 12500 hash.txt /usr/share/wordlists/rockyou.txt # RAR5 (modern): hashcat -m 13000 hash.txt /usr/share/wordlists/rockyou.txt </code></pre> 7-Zip</h2> 7z2john</code> is a Perl script (install libcompress-raw-lzma-perl</code> if it complains):</p> 7z2john archive.7z > hash.txt # or: 7z2john.pl archive.7z > hash.txt hashcat -m 11600 hash.txt /usr/share/wordlists/rockyou.txt </code></pre> 7-Zip uses AES-256 with many KDF iterations, so it’s slow</strong> to crack — a good wordlist matters far more than raw speed here.</p> ZIP</h2> zip2john archive.zip > hash.txt </code></pre> Which mode depends on the encryption:</p> # Classic ZipCrypto (weak, old PKZIP): hashcat -m 17200 hash.txt /usr/share/wordlists/rockyou.txt # WinZip AES (modern, strong): hashcat -m 13600 hash.txt /usr/share/wordlists/rockyou.txt </code></pre> For ZipCrypto specifically, the lightweight fcrackzip</code> is also an option — covered separately</a>.</p> Dictionary first, then masks</h2> Most recoveries succeed with a wordlist — start there (rockyou.txt</code> ships with Kali, or grab it anywhere). If you remember the shape</em> of the password, a mask attack</strong> is far more efficient than blind brute force:</p> # 8 chars: capital + 5 lowercase + 2 digits, e.g. "Summer26" hashcat -m 13000 -a 3 hash.txt '?u?l?l?l?l?l?d?d' </code></pre> Add rules to a dictionary run to cover common mutations:</p> hashcat -m 13000 hash.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule </code></pre> What to expect</h2> GPU vs CPU:</strong> hashcat on a modern GPU is orders of magnitude faster than the old CPU tools. ZipCrypto cracks at billions/sec; RAR5 and 7z are deliberately slow (strong KDF), so lean on good wordlists and masks rather than exhaustive brute force.</li> Resume:</strong> hashcat checkpoints automatically — --restore</code> continues an interrupted run.</li> Find the running guess:</strong> press s</code> for status during a run.</li> </ul> FAQ</h2> hashcat says “No hashes loaded” or “Token length exception”</h3> The extracted hash includes a prefix the mode must match (e.g. RAR3 vs RAR5). Check the start of hash.txt</code> against the mode you chose; hashcat --identify hash.txt</code> can help.</p> Is this legal?</h3> Recovering a password on an archive you own or are authorised to access is fine. Doing it to someone else’s file without permission is unauthorised access — the usual computer-misuse laws apply.</p> Strong password, dictionary failed — now what?</h3> If it’s a long random password on RAR5/7z/WinZip-AES, it may simply be out of reach — that’s the encryption working as intended. Spend your effort on a smarter wordlist/mask built from what you remember, not on brute-forcing length.</p> Summary</h2> Extract: rar2john</code> / 7z2john</code> / zip2john</code> → hash.txt</code>.</li> Crack: hashcat modes — RAR3 12500</code>, RAR5 13000</code>, 7z 11600</code>, ZipCrypto 17200</code>, WinZip-AES 13600</code>.</li> Wordlist + rules first, then targeted masks. rarcrack is obsolete — don’t bother.</li> </ul> Compress a mysqldump backup — gzip, zstd, xz (2026) 2009-01-31T00:00:00+00:00 TL;DR —</strong> mysqldump db \| zstd > db.sql.zst</code> dumps and compresses in one pipe — no giant intermediate file. Restore with zstd -dc db.sql.zst \| mysql db</code>. Use gzip</code> for maximum portability, zstd</code> for the best speed/size balance, xz</code> for the smallest file.</p> A 2009 note — the pipe pattern is timeless, but the original reached for lzma</code>. In 2026 zstd</strong> is the one to use; the commands for all the common compressors are below.</p> </blockquote> Dump and compress in one pipe</h2> Piping avoids ever writing the full uncompressed dump to disk:</p> # zstd — modern default: fast, great ratio mysqldump mydb \| zstd -o mydb.sql.zst # gzip — universal, on every system mysqldump mydb \| gzip > mydb.sql.gz # xz — smallest file, slowest mysqldump mydb \| xz > mydb.sql.xz </code></pre> Add the options you’d normally pass to mysqldump</code> (credentials, flags) before the database name.</p> Restore: decompress back into mysql</h2> zstd -dc mydb.sql.zst \| mysql mydb gunzip < mydb.sql.gz \| mysql mydb xz -dc mydb.sql.xz \| mysql mydb </code></pre> -dc</code> / gunzip <</code> stream straight to mysql</code> — again, no temp file.</p> A sane production dump line</h2> For a consistent, restorable backup of an InnoDB database without locking it:</p> mysqldump --single-transaction --quick --routines --triggers --events \ mydb \| zstd > mydb-$(date +%F).sql.zst </code></pre> --single-transaction</code> — consistent snapshot without locking (InnoDB).</li> --quick</code> — stream rows instead of buffering (low memory on huge tables).</li> --routines --triggers --events</code> — include stored programs, not just data.</li> </ul> MariaDB</h2> Use the mariadb-dump</code> / mariadb</code> client names (the mysqldump</code>/mysql</code> names still exist as compatibility symlinks):</p> mariadb-dump --single-transaction mydb \| zstd > mydb.sql.zst zstd -dc mydb.sql.zst \| mariadb mydb </code></pre> Speed vs size, roughly</h2> gzip</strong> — fast, ~everywhere, moderate ratio. Safe default if you can’t install anything.</li> zstd</strong> — as fast as gzip (often faster), notably smaller; zstd -19</code> or --long</code> for archival. Best all-rounder.</li> xz</strong> — smallest output, much slower CPU. Good for cold archives where size is king.</li> </ul> Tune threads on big dumps: zstd -T0</code> (all cores), xz -T0</code>.</p> FAQ</h2> How do I check the dump without restoring it?</h3> zstd -dc mydb.sql.zst \| head -50</code> — peek at the SQL header. zstd -t</code> / gzip -t</code> test archive integrity.</p> Can I dump just one table?</h3> mysqldump mydb mytable \| zstd > mytable.sql.zst</code>. Add more table names to include several.</p> Restore is slow — anything to do?</h3> Wrap large imports with SET autocommit=0; … COMMIT;</code> and disable keys during load, or restore from a physical backup tool (Percona XtraBackup / mariabackup) for very large datasets.</p> Summary</h2> Dump+compress: mysqldump db \| zstd > db.sql.zst</code> (or gzip</code>/xz</code>).</li> Restore: zstd -dc db.sql.zst \| mysql db</code>.</li> Production: add --single-transaction --quick --routines --triggers</code>.</li> zstd is the modern pick; gzip for portability; xz for smallest.</li> </ul> Remove the password / editing protection from a Word document (2026) 2008-07-28T00:00:00+00:00 TL;DR —</strong> if a Word doc is read-only / restricted from editing</strong>, a .docx</code> is just a ZIP — unzip it, delete the <w:documentProtection></code> element from word/settings.xml</code>, re-zip. If it’s password-to-open</strong> (encrypted), that’s real crypto: extract a hash with office2john</code> and recover it with hashcat</code>.</p> The 2008 version of this used Office XP’s “Script Editor” — long gone. The modern .docx</code> format makes editing-protection removal even easier (it’s a ZIP), and the distinction between editing protection</em> and real encryption</em> is the thing to get right. Only do this on documents you own or are authorised to modify.</p> </blockquote> First: which kind of “password” is it?</h2> Two completely different protections get called “password” in Word:</p> Editing / read-only protection (“Restrict Editing”).</strong> The document opens fine; you just can’t edit it. This is not encryption</strong> — it’s a flag in the file. Trivial to remove.</li> Password to open (“Encrypt with Password”).</strong> The document won’t open at all without the password. This is</strong> strong AES encryption. You can’t “remove” it — you have to recover the password.</li> </ol> Case 1 — remove editing / read-only protection</h2> A modern .docx</code> is a ZIP archive of XML. The protection lives in one element.</p> # work on a copy cp protected.docx unlocked.docx mkdir extracted && cd extracted unzip ../unlocked.docx </code></pre> Edit word/settings.xml</code> and delete the whole <w:documentProtection .../></code> element. It looks like:</p> <w:documentProtection w:edit="readOnly" w:enforcement="1" w:cryptProviderType="rsaAES" w:cryptAlgorithmSid="14" w:hash="…" w:salt="…"/> </code></pre> Remove that one self-closing tag, then repackage:</p> zip -r ../unlocked.docx . # re-zip the contents </code></pre> Open unlocked.docx</code> — fully editable. (The w:hash</code>/w:salt</code> only protect re-enabling</em> the restriction in the UI; deleting the element ignores them entirely, which is why this “protection” is cosmetic.)</p> Even simpler: LibreOffice</h3> Open the file in LibreOffice Writer → Edit → Edit Mode</strong> (or Format → Sections</strong> / Tools → Protect Document</strong> depending on the protection), turn the protection off, and save. For form/section protection, LibreOffice toggles it without any password.</p> Case 2 — password to open (encrypted)</h2> If Word demands a password just to open</em> the file, the content is AES-encrypted and there’s no shortcut — you recover the password with the same hash-then-crack flow as archive passwords</a>.</p> # office2john ships with John the Ripper office2john protected.docx > hash.txt # hashcat mode depends on the Office version that saved it: # 9400 = Office 2007, 9500 = 2010, 9600 = 2013+ (most modern files) hashcat -m 9600 hash.txt /usr/share/wordlists/rockyou.txt </code></pre> Modern Office encryption uses a heavy KDF, so it’s slow</strong> — a good, targeted wordlist (and a mask built from what you remember) beats brute force. If it was a long random password, it may be genuinely unrecoverable, which is the encryption doing its job.</p> Old .doc (binary format)</h2> The pre-2007 .doc</code> binary format isn’t a ZIP. For editing</em> protection, opening and re-saving in LibreOffice usually drops it; for password-to-open, office2john</code> handles old .doc</code> too (it autodetects the format) — same crack flow.</p> FAQ</h2> Is read-only protection actually security?</h3> No. As above, it’s a removable flag, not encryption — useful to prevent accidental</em> edits, useless against anyone who doesn’t want to be stopped. If you need real protection, use Encrypt with Password</strong>.</p> Excel / PowerPoint?</h3> Same model. .xlsx</code>/.pptx</code> are ZIPs — sheet/workbook protection is an element you can delete; password-to-open is encryption, recoverable via office2john</code> (mode 9600 etc.).</p> Is this legal?</h3> On your own documents, or ones you’re authorised to edit — yes. Removing protection from someone else’s confidential document without permission is not.</p> Summary</h2> Editing/read-only</strong>: unzip the .docx</code>, delete <w:documentProtection></code> from word/settings.xml</code>, re-zip — or just toggle it off in LibreOffice.</li> Password-to-open</strong>: real encryption — office2john file.docx > hash.txt</code>, then hashcat -m 9600 …</code>.</li> Read-only protection is not security; use real encryption if you need it.</li> </ul> Convert Windows line endings to Unix with dos2unix (2026) 2008-04-30T00:00:00+00:00 TL;DR —</strong> dos2unix file.txt</code> rewrites a file’s CRLF (Windows) line endings to LF (Unix) in place. Install it with sudo apt install dos2unix</code>. No dos2unix? sed -i 's/\r$//' file.txt</code> does the same.</p> A 2008 note that pointed at the tofrodos</code> package. On modern Debian/Ubuntu dos2unix</code> is its own package now</strong> — simpler. The rest still applies: CRLF vs LF mismatches are a perennial nuisance.</p> </blockquote> Why it matters</h2> DOS/Windows ends each line with CR+LF</strong> (\r\n</code>); Unix/Linux/macOS use just LF</strong> (\n</code>). A file authored on Windows and run on Linux carries stray \r</code> characters that cause:</p> #!/bin/bash^M: bad interpreter</code> when running a script.</li> Configs and .env</code> files where a value silently gains a trailing \r</code>.</li> Diffs and grep</code> matching things that look identical but aren’t.</li> </ul> Install</h2> sudo apt install dos2unix # Debian / Ubuntu (its own package now) sudo dnf install dos2unix # Fedora brew install dos2unix # macOS </code></pre> Convert</h2> dos2unix script.sh </code></pre> It converts in place</strong>. Keep a copy under a new name if you want the original:</p> dos2unix -n script.sh script.unix.sh </code></pre> The reverse exists too — unix2dos file.txt</code> adds CRLF back (e.g. for a file a Windows tool insists on).</p> Batch a whole tree</h2> Convert every shell script under the current directory:</p> find . -type f -name '.sh' -exec dos2unix {} + </code></pre> dos2unix</code> skips binary files it detects, so a broad find . -type f</code> is usually safe — but scope it with -name</code> when you can.</p> No dos2unix installed? Use sed</h2> Strip the trailing CR with sed</code> (in place with -i</code>):</p> sed -i 's/\r$//' file.txt </code></pre> Or with tr</code> (writes to a new file — tr</code> can’t edit in place):</p> tr -d '\r' < dosfile.txt > unixfile.txt </code></pre> Check what you’ve got</h2> file script.sh script.sh: Bourne-Again shell script, ASCII text, with CRLF line terminators </code></pre> “with CRLF line terminators” is the tell. cat -A file</code> shows ^M</code> at each line end.</p> FAQ</h2> macOS sed says “invalid command code”</h3> BSD sed</code> (macOS) needs an argument after -i</code>: sed -i '' 's/\r$//' file.txt</code>. Or just brew install dos2unix</code> and avoid the difference.</p> Git keeps reintroducing CRLF</h3> That’s Git’s core.autocrlf</code> / .gitattributes</code>, not the file itself. Set text=auto eol=lf</code> in .gitattributes</code> to normalise on commit.</p> Does this change the file’s encoding too?</h3> No — line endings and character encoding are independent. For UTF-8/Latin-1 conversion see iconv</a>.</p> Summary</h2> dos2unix file</code> — CRLF → LF, in place. unix2dos</code> for the reverse.</li> Install: sudo apt install dos2unix</code> (now its own package).</li> Batch: find . -name '.sh' -exec dos2unix {} +</code>.</li> Fallback: sed -i 's/\r$//' file</code> (sed -i '' …</code> on macOS).</li> </ul> Mount a remote filesystem over SSH with sshfs (2026) 2008-03-06T00:00:00+00:00 TL;DR —</strong> sshfs user@host:/remote/path /mnt/point -o reconnect,uid=$(id -u),gid=$(id -g)</code> mounts a remote directory locally over SSH. Unmount with fusermount -u /mnt/point</code>. The server needs nothing beyond OpenSSH, which it already has.</p> A 2008 note that still holds up — if anything sshfs is more useful now that everything’s a remote box. Pairs nicely with SSH key login</a> so the mount comes up without a password prompt.</p> </blockquote> Why sshfs</h2> It’s a FUSE filesystem that speaks the SSH SFTP</strong> protocol. Because every server running OpenSSH already supports SFTP, there is nothing to set up on the server side</strong> — if you can ssh</code> in, you can sshfs</code> in. Great for editing remote files with local tools, copying across, or poking at a server’s filesystem without a full sync.</p> Install</h2> sudo apt install sshfs # Debian / Ubuntu sudo dnf install fuse-sshfs # Fedora brew install macfuse # macOS: needs macFUSE + the sshfs cask </code></pre> Mount</h2> mkdir -p ~/mnt/server sshfs user@remote.host:/home/user ~/mnt/server -o reconnect,uid=$(id -u),gid=$(id -g) </code></pre> uid</code>/gid</code></strong>: map remote file ownership to your</em> local user so you have read/write access (otherwise files may show up owned by someone else and be read-only).</li> reconnect</code></strong>: transparently re-establish the connection if SSH drops.</li> </ul> Now ~/mnt/server</code> is the remote directory — use ls</code>, your editor, file manager, anything.</p> Keep it alive on flaky links</h2> Network blips otherwise leave the mount hung. Add keepalive + auto-reconnect options:</p> sshfs user@host:/path ~/mnt/server \ -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,follow_symlinks </code></pre> ServerAliveInterval</code>/CountMax</code> make SSH notice a dead link in ~45 s; follow_symlinks</code> resolves remote symlinks locally.</p> Unmount</h2> fusermount -u ~/mnt/server # Linux umount ~/mnt/server # macOS </code></pre> Use fusermount -uz</code> (lazy) if it’s stuck on a dead connection.</p> Mount automatically via fstab</h2> For a mount you want back after reboot (key-based auth required, since fstab can’t type a password):</p> user@host:/path /home/me/mnt/server fuse.sshfs noauto,x-systemd.automount,_netdev,reconnect,uid=1000,gid=1000,IdentityFile=/home/me/.ssh/id_ed25519 0 0 </code></pre> x-systemd.automount</code> mounts it on first access rather than at boot, so a slow/absent server doesn’t stall startup.</p> Gotchas</h2> Files owned by the wrong user / read-only</strong> → you forgot uid</code>/gid</code>. Set them to your local id -u</code>/id -g</code>.</li> “Transport endpoint is not connected”</strong> → the SSH link died. fusermount -uz</code> then remount; add reconnect</code> to avoid it.</li> Slow with many small files</strong> → SFTP is chatty; add -o cache=yes,kernel_cache,compression=no</code> and avoid running e.g. grep -r</code> over huge remote trees.</li> macOS</strong> → macFUSE needs a one-time approval in System Settings → Privacy & Security after install.</li> </ul> FAQ</h2> Is sshfs secure?</h3> Yes — all traffic rides inside the SSH connection, same encryption as a normal SSH session.</p> Does the server admin need to install anything?</h3> No. SFTP ships with OpenSSH. If you can SSH in, sshfs works.</p> sshfs vs NFS/Samba?</h3> NFS/Samba are faster for LAN file serving but need server-side setup and open ports. sshfs needs only SSH — ideal for ad-hoc access to a remote box you can already log into.</p> Summary</h2> sshfs user@host:/path /mnt -o reconnect,uid=$(id -u),gid=$(id -g)</code>.</li> Set uid</code>/gid</code> for write access; add ServerAliveInterval</code> + reconnect</code> for stability.</li> Unmount with fusermount -u</code> (Linux) / umount</code> (macOS).</li> Combine with key auth for a password-free mount.</li> </ul> Find the most recently changed files on Linux (2026) 2007-10-30T00:00:00+00:00 TL;DR —</strong> find . -type f -printf '%T+ %p\n' \| sort \| tail</code> lists files newest-last across a whole tree. To filter by age, find . -type f -mmin -60</code> (last hour) or -mtime -1</code> (last day). On macOS, use the stat</code>/-newermt</code> variants below.</p> A one-line note from 2007 that’s still in my muscle memory. “What changed on this box recently?” comes up constantly — here’s the full toolkit.</p> </blockquote> Newest files in a directory tree (GNU/Linux)</h2> find . -type f -printf '%T+ %p\n' \| sort \| tail -20 </code></pre> -printf '%T+ %p\n'</code> prints a sortable YYYY-MM-DD+HH:MM:SS</code> timestamp then the path.</li> sort</code> orders oldest→newest; tail -20</code> shows the 20 most recent (\| sort -r \| head</code> flips it).</li> </ul> Filter by age directly</h2> find</code> can select by modification time without sorting:</p> find . -type f -mmin -60 # modified in the last 60 minutes find . -type f -mmin -5 # last 5 minutes find . -type f -mtime -1 # last 24 hours (-mtime is in days) find . -type f -mtime -7 # last week </code></pre> The leading -</code> means “less than N ago”; +N</code> means “more than N ago”.</p> Files newer than a reference</h2> find . -type f -newer /etc/some.reference # changed after that file find . -type f -newermt "2026-06-01" # changed after a date (GNU) find . -type f -newermt "2 hours ago" # changed in the last 2 hours </code></pre> Add details (size, time) to the listing</h2> find . -type f -mmin -60 -printf '%TY-%Tm-%Td %TT %10s %p\n' \| sort # or hand off to ls for human sizes: find . -type f -mmin -60 -exec ls -lh --time-style=long-iso {} + </code></pre> macOS / BSD find (no -printf)</h2> BSD find</code> on macOS doesn’t support -printf</code>. Use -newermt</code> (it does have that) or fall back to stat</code>:</p> find . -type f -mtime -1 # works on macOS too find . -type f -newermt "2026-06-01" # date filter # newest-last with stat (macOS stat syntax): find . -type f -exec stat -f '%m %N' {} + \| sort -n \| tail -20 </code></pre> (%m</code> = epoch mtime, %N</code> = name; sort -n</code> orders numerically.)</p> FAQ</h2> What’s the difference between modified, changed, and accessed?</h3> -mtime</code>/%T</code> = content</strong> last modified. -ctime</code>/%C</code> = inode changed</strong> (permissions, rename, content). -atime</code>/%A</code> = last accessed</strong> (often disabled via noatime</code> mounts). For “what file changed” you almost always want -mtime</code>/-mmin</code>.</p> How do I find the single newest file?</h3> find . -type f -printf '%T@ %p\n' \| sort -n \| tail -1 \| cut -d' ' -f2-</code> (%T@</code> is epoch seconds).</p> Exclude a directory (e.g. .git)?</h3> find . -path ./.git -prune -o -type f -mmin -60 -print</code>.</p> Summary</h2> Newest-last list: find . -type f -printf '%T+ %p\n' \| sort \| tail</code>.</li> By age: -mmin -60</code> (minutes), -mtime -1</code> (days), -newermt "…"</code>.</li> macOS: use -mtime</code>/-newermt</code>, or stat -f '%m %N'</code> since BSD find has no -printf</code>.</li> </ul> MySQL: find and remove duplicate rows (2026) 2007-06-09T00:00:00+00:00 TL;DR —</strong> find duplicates with GROUP BY … HAVING COUNT() > 1</code>; delete them with a self-join DELETE</code> that keeps the lowest id</code>; then add a UNIQUE</code> index so they can’t return. The old ALTER IGNORE TABLE … ADD UNIQUE</code> shortcut was removed in MySQL 5.7</strong> — don’t use it.</p> The 2007 version of this post used ALTER IGNORE TABLE … ADD UNIQUE INDEX</code> to let MySQL drop the dupes for you. That IGNORE</code> clause is gone in modern MySQL, so here are the approaches that actually work in 2026.</p> </blockquote> 1. Find the duplicates first</h2> Decide what “duplicate” means — which columns must match. Say rows are duplicates when (a, b)</code> are equal:</p> SELECT a, b, COUNT() AS n FROM mydata GROUP BY a, b HAVING n > 1; </code></pre> Always look before you delete.</p> 2. Delete them, keeping one row</h2> Self-join (works on every version)</h3> Keep the row with the lowest id</code></strong> in each duplicate group:</p> DELETE t1 FROM mydata t1 JOIN mydata t2 ON t1.a = t2.a AND t1.b = t2.b AND t1.id > t2.id; </code></pre> t1.id > t2.id</code> deletes every copy except the smallest id. Flip to <</code> to keep the newest instead.</p> Window function (MySQL 8.0+ / MariaDB 10.2+)</h3> Cleaner and easy to extend to “keep the newest per group”:</p> DELETE FROM mydata WHERE id IN ( SELECT id FROM ( SELECT id, ROW_NUMBER() OVER (PARTITION BY a, b ORDER BY id) AS rn FROM mydata ) x WHERE rn > 1 ); </code></pre> The extra subquery layer is required — MySQL won’t let you delete from a table you’re selecting from directly.</p> 3. Stop them coming back</h2> Once the table is clean, add a UNIQUE</code> index so future inserts can’t duplicate:</p> ALTER TABLE mydata ADD UNIQUE INDEX uq_a_b (a, b); </code></pre> Then write inserts as INSERT … ON DUPLICATE KEY UPDATE …</code> or INSERT IGNORE</code> so the dedup is enforced at write time.</p> Big tables: the rebuild approach</h2> For very large tables, rewriting via a fresh table is often faster than a giant DELETE</code>:</p> CREATE TABLE mydata_clean LIKE mydata; ALTER TABLE mydata_clean ADD UNIQUE INDEX uq_a_b (a, b); INSERT IGNORE INTO mydata_clean SELECT FROM mydata; -- IGNORE drops dup-key rows RENAME TABLE mydata TO mydata_old, mydata_clean TO mydata; </code></pre> FAQ</h2> Why doesn’t ALTER IGNORE TABLE work anymore?</h3> The IGNORE</code> keyword on ALTER TABLE</code> was deprecated in MySQL 5.6 and removed in 5.7</strong>. The self-join or rebuild approach replaces it.</p> How do I keep the newest row instead of the oldest?</h3> Self-join: change t1.id > t2.id</code> to t1.id < t2.id</code>. Window function: ORDER BY id DESC</code> in the PARTITION BY</code>.</p> Back up first?</h3> Yes. DELETE</code> is irreversible — take a compressed dump</a> before running it on production.</p> Summary</h2> Find: GROUP BY cols HAVING COUNT() > 1</code>.</li> Delete (portable): self-join DELETE … WHERE t1.id > t2.id</code>.</li> Delete (modern): ROW_NUMBER() OVER (PARTITION BY …)</code>.</li> Prevent: add a UNIQUE</code> index + INSERT … ON DUPLICATE KEY</code>.</li> </ul> SSH login without a password — set up key authentication (2026) 2007-06-09T00:00:00+00:00 TL;DR —</strong> ssh-keygen -t ed25519</code>, then ssh-copy-id user@host</code>. Now ssh user@host</code> logs you in with no password. Use a passphrase on the key plus ssh-agent</code> so it stays both convenient and</em> safe.</p> One of the oldest how-tos from my blog (2007), back when ssh-keygen -t rsa</code> was the answer. In 2026 you want ed25519</strong> keys, and ssh-copy-id</code> does the fiddly part for you.</p> </blockquote> How it works</h2> Key authentication uses a key pair</strong>: a private</em> key that never leaves your machine, and a matching public</em> key you place on each server. The server challenges you with something only the private key can answer — so you prove who you are without ever sending a password.</p> 1. Generate a key pair</h2> ssh-keygen -t ed25519 -C "you@laptop" </code></pre> -t ed25519</code></strong> — modern, short, fast, secure. (Use -t rsa -b 4096</code> only for ancient servers that don’t support ed25519.)</li> -C</code></strong> — a comment to identify the key later.</li> </ul> You’ll be asked where to save it (default ~/.ssh/id_ed25519</code>) and for a passphrase</strong>. Use one — see the agent note below. This produces two files: id_ed25519</code> (private — guard it) and id_ed25519.pub</code> (public — safe to share).</p> 2. Copy the public key to the server</h2> The easy way:</p> ssh-copy-id user@remote.host </code></pre> It appends your public key to ~/.ssh/authorized_keys</code> on the server and fixes the permissions. If ssh-copy-id</code> isn’t available, do it by hand:</p> cat ~/.ssh/id_ed25519.pub \| ssh user@remote.host \ "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys" </code></pre> 3. Log in</h2> ssh user@remote.host </code></pre> No password prompt (just your key’s passphrase the first time, if you set one).</p> Keep it convenient with ssh-agent</h2> A passphrase-protected key would defeat the “no password” goal — except ssh-agent</code> caches the unlocked key for your session, so you type the passphrase once</strong>:</p> eval "$(ssh-agent -s)" # start the agent (often already running) ssh-add ~/.ssh/id_ed25519 # unlock the key once </code></pre> macOS stores it in the Keychain automatically with ssh-add --apple-use-keychain</code>.</p> Optionally: turn off password logins</h2> Once keys work, disabling password auth shuts the door on brute-force attempts entirely. On the server, edit /etc/ssh/sshd_config</code>:</p> PasswordAuthentication no PubkeyAuthentication yes </code></pre> Then reload: sudo systemctl reload ssh</code> (or sshd</code>). Confirm key login works in a second session before you do this</strong>, or you can lock yourself out.</p> Permissions matter (the #1 reason it “doesn’t work”)</h2> SSH refuses keys if the permissions are too loose:</p> chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys # on the server chmod 600 ~/.ssh/id_ed25519 # your private key </code></pre> FAQ</h2> Still asks for a password?</h3> Almost always permissions (above) or the wrong key. Debug with ssh -v user@host</code> and watch which key it offers and whether the server rejects authorized_keys</code> for being group/world-writable.</p> Multiple keys / multiple servers?</h3> Put them in ~/.ssh/config</code>:</p> Host prod HostName prod.example.com User deploy IdentityFile ~/.ssh/id_ed25519 </code></pre> Then just ssh prod</code>.</p> rsa or ed25519?</h3> ed25519 by default — smaller, faster, and secure. Reach for rsa -b 4096</code> only when talking to an old server that lacks ed25519 support.</p> Summary</h2> ssh-keygen -t ed25519</code> → ssh-copy-id user@host</code> → ssh user@host</code>.</li> Use a passphrase + ssh-agent</code> to stay convenient and safe.</li> Fix ~/.ssh</code> permissions (700/600) if it won’t take the key.</li> Set PasswordAuthentication no</code> once keys work — after testing.</li> </ul> Convert a text file's character encoding with iconv (2026) 2007-02-24T00:00:00+00:00 TL;DR —</strong> iconv -f UTF-8 -t ISO-8859-1 in.txt > out.txt</code> converts encodings. Check what you’ve got first with file -i in.txt</code>, and add //TRANSLIT</code> (approximate) or //IGNORE</code> (drop) for characters the target can’t represent.</p> A 2007 note — and the original even had the direction muddled, which is exactly the trap. iconv</code> does nothing to tell</em> you which way to go, so step one is always: find out what encoding you actually have.</p> </blockquote> 1. Detect the current encoding</h2> file -i mystery.txt mystery.txt: text/plain; charset=utf-8 </code></pre> file</code> guesses from the bytes — usually right for UTF-8 vs Latin-1, but a guess. If Danish æ ø å</code> (or other non-ASCII) shows up garbled in your editor, the declared/assumed encoding is wrong.</p> 2. Convert</h2> The flags are -f</code> (from)</strong> and -t</code> (to)</strong>. Don’t mix them up:</p> # UTF-8 -> ISO-8859-1 (Latin-1) iconv -f UTF-8 -t ISO-8859-1 utf.txt > latin1.txt # ISO-8859-1 -> UTF-8 iconv -f ISO-8859-1 -t UTF-8 latin1.txt > utf.txt </code></pre> (The long forms --from-code</code> / --to-code</code> are identical.)</p> 3. Handle characters the target can’t represent</h2> Converting to</em> a narrow charset like ISO-8859-1 fails on characters it doesn’t contain (€, em-dashes, emoji) with illegal input sequence</code>. Two ways out:</p> # //TRANSLIT — approximate: “ ” -> " ", é -> e where needed iconv -f UTF-8 -t ISO-8859-1//TRANSLIT in.txt > out.txt # //IGNORE — silently drop characters that don't fit iconv -f UTF-8 -t ISO-8859-1//IGNORE in.txt > out.txt </code></pre> Edit in place safely</h2> iconv in.txt > in.txt</code> truncates the file before reading it — you lose the data. Use a temp file:</p> iconv -f ISO-8859-1 -t UTF-8 in.txt > in.tmp && mv in.tmp in.txt </code></pre> Batch-convert a tree</h2> Convert every .txt</code> under a directory from Latin-1 to UTF-8:</p> find . -type f -name '.txt' -exec sh -c \ 'iconv -f ISO-8859-1 -t UTF-8 "$1" > "$1.utf8" && mv "$1.utf8" "$1"' _ {} \; </code></pre> List everything iconv</code> supports with iconv -l</code>.</p> FAQ</h2> iconv says “illegal input sequence at position N”</h3> The real source encoding isn’t what you told -f</code>, or you’re converting to a charset that can’t hold a character. Re-check with file -i</code>, or add //TRANSLIT</code>///IGNORE</code>.</p> How do I strip a UTF-8 BOM?</h3> iconv</code> won’t always remove it; sed '1s/^\xEF\xBB\xBF//' in.txt > out.txt</code> drops a leading BOM.</p> What about Windows line endings while I’m at it?</h3> Encoding and line endings are separate problems — see dos2unix</a> for CRLF→LF.</p> Summary</h2> Detect: file -i file.txt</code>.</li> Convert: iconv -f FROM -t TO in > out</code> (-f</code> = from, -t</code> = to).</li> Lossy targets: append //TRANSLIT</code> or //IGNORE</code>.</li> In place: go via a temp file, never > same-file</code>.</li> </ul> Remove the passphrase from a private key with OpenSSL (2026) 2006-09-03T00:00:00+00:00 TL;DR —</strong> openssl rsa -in server.key -out server.key.nopass</code> writes a passphrase-free copy of an RSA key (use openssl pkey</code> for any key type). Then chmod 600</code> it. The server will start without prompting — at the cost of an unencrypted key on disk, so guard it.</p> Refreshed from a 2006 note. The mechanism is unchanged; the commands below add the EC and modern any-key forms, and the security caveat it really deserves.</p> </blockquote> The problem</h2> If your TLS private key is passphrase-encrypted, the web server can’t start unattended — it stops and waits for someone to type the passphrase. That breaks reboots, autoscaling, and config-management. The fix is an unencrypted</strong> copy of the key.</p> Remove it</h2> For a classic RSA key:</p> openssl rsa -in server.key -out server.key.nopass </code></pre> For an EC (elliptic-curve) key:</p> openssl ec -in server.key -out server.key.nopass </code></pre> Type-agnostic (works for RSA, EC, Ed25519 — the modern catch-all):</p> openssl pkey -in server.key -out server.key.nopass </code></pre> OpenSSL prompts for the current passphrase, then writes the decrypted key. Point your server at the .nopass</code> file and it’ll start silently.</p> Lock the file down</h2> An unencrypted key is a plaintext credential. At minimum:</p> chmod 600 server.key.nopass chown root:root server.key.nopass </code></pre> Anyone who reads this file owns your certificate’s identity until it’s revoked. Treat it accordingly.</p> Going the other way: add a passphrase</h2> To encrypt</em> a key (e.g. before moving it):</p> openssl rsa -aes256 -in plain.key -out encrypted.key </code></pre> Should you actually do this?</h2> Removing the passphrase is convenient but trades away a layer of protection — a stolen disk image now hands over a working key. Consider the alternatives before reaching for .nopass</code>:</p> systemd ask-password</code> / a key-loading agent</strong> can supply the passphrase at boot without baking it in.</li> A secrets manager</strong> (Vault, cloud KMS, or the platform’s secret store) hands the key to the process at runtime and never persists it in the clear.</li> Tight file permissions + full-disk encryption</strong> mitigate the plaintext-on-disk risk if you must use an unencrypted key.</li> </ul> For a single hobby server, .nopass</code> + chmod 600</code> is a reasonable, honest trade. For anything sensitive, push the passphrase/secret out of the filesystem.</p> FAQ</h2> Will the certificate still match after I do this?</h3> Yes — you’re only changing how the key is stored</em>, not the key itself. The public key, certificate, and CSR all still match. (Verify with the modulus check in inspecting & verifying certificates</a>.)</p> nginx/Apache still prompts after I switched files?</h3> You’re still pointing at the encrypted key. Check ssl_certificate_key</code> (nginx) / SSLCertificateKeyFile</code> (Apache) really points at the .nopass</code> file, then reload.</p> Can I tell whether a key is encrypted?</h3> head -1 server.key</code> — an encrypted PEM shows Proc-Type: 4,ENCRYPTED</code> or a BEGIN ENCRYPTED PRIVATE KEY</code> header.</p> Summary</h2> RSA: openssl rsa -in server.key -out server.key.nopass</code>; any key: openssl pkey …</code>.</li> chmod 600</code> and restrict ownership — it’s now a plaintext credential.</li> Prefer a boot-time passphrase supplier or secrets manager for anything that matters.</li> </ul> MySQL: set or reset the AUTO_INCREMENT value (2026) 2006-08-31T00:00:00+00:00 TL;DR —</strong> ALTER TABLE t AUTO_INCREMENT = 100000;</code> sets the next auto-increment value. You can raise it freely, but you can’t set it below the current maximum id</strong> — MySQL silently clamps it to max+1.</p> One of the shortest notes from the old blog (2006) — one line. Still correct, but the caveats below are what actually trip people up.</p> </blockquote> Set it</h2> ALTER TABLE mytable AUTO_INCREMENT = 100000; </code></pre> The next inserted row gets id 100000</code> (assuming that’s above the current max). Handy for leaving room between data sets, or starting ids at a friendlier number.</p> Reset after deleting rows</h2> Deleted the tail of a table and want ids to continue from the real maximum instead of the old high-water mark?</p> -- continue from the highest existing id ALTER TABLE mytable AUTO_INCREMENT = 1; -- clamps up to max(id)+1 automatically </code></pre> Setting it to 1</code> doesn’t reset to 1 if rows exist — MySQL clamps to MAX(id) + 1</code>. That’s usually exactly what you want after a cleanup.</p> Empty a table and truly start at 1</h2> If you want ids to restart from 1, the table must be empty. TRUNCATE</code> does both — wipes rows and</em> resets the counter:</p> TRUNCATE TABLE mytable; -- removes all rows AND resets AUTO_INCREMENT to 1 </code></pre> (DELETE FROM mytable</code> removes rows but leaves the counter where it was — use ALTER TABLE … AUTO_INCREMENT = 1</code> after it, or TRUNCATE</code>.)</p> Gotchas</h2> Can’t go below the max.</strong> ALTER TABLE … AUTO_INCREMENT = 5</code> on a table whose largest id is 900 leaves it at 901. There’s no way to reuse ids below existing data without rewriting the table.</li> Engine differences on restart.</strong> Modern InnoDB (MySQL 8.0+) persists the counter across restarts. Older InnoDB (≤5.7) recomputed it as MAX(id)+1</code> at startup, so a gap at the top could “shrink” after a reboot. MyISAM always persisted it.</li> Replication / Galera.</strong> With auto_increment_increment</code> > 1 (multi-primary, Galera, group replication), ids jump in steps (e.g. 1, 3, 5…) by design — don’t “fix” the gaps, they prevent id collisions between nodes.</li> Gaps are normal.</strong> Rolled-back transactions and failed inserts consume ids. Auto-increment guarantees uniqueness and monotonicity, not</strong> contiguity. Don’t rely on “no holes”.</li> </ul> FAQ</h2> How do I see the current value?</h3> SHOW TABLE STATUS LIKE 'mytable'; -- the Auto_increment column </code></pre> or query information_schema.TABLES</code>.</p> It won’t let me lower it — why?</h3> By design: lowering below existing ids would risk duplicate keys. Rewrite the table (dump, recreate, reload) if you genuinely must renumber.</p> Does this work the same in MariaDB?</h3> Yes — ALTER TABLE … AUTO_INCREMENT = N</code> and TRUNCATE</code> behave the same. Restart-persistence depends on the engine/version as above.</p> Summary</h2> Set/raise: ALTER TABLE t AUTO_INCREMENT = N</code>.</li> After deletes: ALTER TABLE t AUTO_INCREMENT = 1</code> clamps to MAX(id)+1</code>.</li> Restart at 1: TRUNCATE TABLE t</code> (must be empty).</li> Can’t set below the current max; gaps are expected.</li> </ul> Java cacerts default password — and how to use the truststore (2026) 2006-08-29T00:00:00+00:00 TL;DR —</strong> the default password for Java’s cacerts</code> truststore is changeit</code></strong>. The file lives at $JAVA_HOME/lib/security/cacerts</code> in any modern (Java 9+) JDK. Use keytool</code> to list, import, and change the password.</p> This was a two-line note in 2006 (the password and the path). Both are still right — Java never changed the default — but the path moved in Java 9, and the useful part is what you do</em> with the truststore, below.</p> </blockquote> The default password</h2> changeit </code></pre> That’s it. It’s the same on every JDK, every OS, and has been for the entire history of Java. (Some Linux distros that manage the system truststore set it to changeme</code> — if changeit</code> is rejected, try that.)</p> Where cacerts lives</h2> In a modern JDK (Java 9 and later, after the JRE/JDK merge):</p> $JAVA_HOME/lib/security/cacerts </code></pre> On older Java 8 and earlier it was under $JAVA_HOME/jre/lib/security/cacerts</code>. Find it if unsure:</p> find "$JAVA_HOME" -name cacerts </code></pre> List the trusted CAs</h2> keytool -list -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit </code></pre> Add -v</code> for full detail, or grep for a specific alias.</p> Import a certificate (internal CA / self-signed)</h2> The common reason you’re here: a Java app throws PKIX path building failed</code> / unable to find valid certification path</code> because it doesn’t trust an internal or self-signed cert. Import it into the truststore:</p> keytool -importcert \ -alias my-internal-ca \ -file internal-ca.crt \ -keystore "$JAVA_HOME/lib/security/cacerts" \ -storepass changeit </code></pre> Grab the cert a server is presenting first if you don’t have the file — see inspecting a TLS certificate</a> (openssl s_client … -showcerts</code>). Prefer importing the CA</strong> that signed the cert over the leaf cert itself, so it keeps working after renewal.</p> Remove or replace an entry</h2> keytool -delete -alias my-internal-ca \ -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit </code></pre> Actually change the password</h2> The alias is literally “changeit” for a reason:</p> keytool -storepasswd \ -keystore "$JAVA_HOME/lib/security/cacerts" \ -storepass changeit -new <new-password> </code></pre> In practice most setups leave the global cacerts</code> at the default and instead point apps at a separate truststore</strong> they control (-Djavax.net.ssl.trustStore=…</code>), which is cleaner than editing the JDK’s own file.</p> FAQ</h2> Should I edit the JDK’s cacerts directly?</h3> For a quick fix, sure. Better practice: keep a project-specific truststore and pass -Djavax.net.ssl.trustStore=/path/to/store -Djavax.net.ssl.trustStorePassword=…</code>, so a JDK upgrade doesn’t wipe your changes.</p> keytool says “keystore was tampered with, or password was incorrect”</h3> Wrong password — try changeit</code>, then changeme</code> (distro-managed JDKs). Confirm you’re pointing at the right cacerts</code> if you have multiple JDKs installed.</p> Truststore vs keystore — what’s the difference?</h3> A truststore</strong> holds the CA certs you trust (cacerts). A keystore</strong> holds your</em> private keys + certs (what a server presents). Same file format, opposite roles.</p> Summary</h2> Default cacerts</code> password: changeit</code></strong> (sometimes changeme</code> on distro JDKs).</li> Path (Java 9+): $JAVA_HOME/lib/security/cacerts</code>.</li> keytool -list</code> to view, -importcert</code> to trust an internal CA, -storepasswd</code> to change it.</li> Prefer a separate app-managed truststore over editing the JDK’s own.</li> </ul>

X2Q

BIN/IIN lookup: the card prefix ranges and how to look one up (2026)

Three ways to look up a BIN</h2>

1. By hand (network only)</h3> Take the first digits and match them against the table above. Good enough when all you need is “is this Visa or Mastercard?”.</p>

Transcribing 33,000 Danish voice logs on home GPUs — the local pipeline (2026)

Factory reset a Yealink phone — even without the admin password (2026)

Update Garmin firmware and maps in 2026 — from WebUpdater to Garmin Express

From Launchy to Raycast: the history of the keystroke launcher (2007 → 2026)

What was Launchy?</h3> A free, open-source keystroke launcher for Windows (later cross-platform), first released by Josh Karlin around 2004. Hotkey, type a few letters, fuzzy-match, launch — “Quicksilver for Windows”. The 2007 video shows it on the Shiny skin.</p>

Is Launchy still maintained?</h3> No — development tapered off around 2010 and it’s effectively dormant. On Windows today use PowerToys Command Palette, Flow Launcher, or Raycast.</p>

From Xming on Windows XP to WSLg: 18 years of Linux GUI apps on Windows (2026)

Does SSH X11 forwarding still work in 2026?</h3> Yes — ssh -X</code> (or -Y</code> for trusted forwarding) is unchanged. It forwards X11 to any X server: VcXsrv, Xming, XQuartz, or WSLg’s. It’s just chatty over latency, which is why xpra/waypipe/RDP usually win for remote work today.</p>

Do I still need an X server at all?</h3> Only to forward GUI apps from a remote box over SSH, or to run X apps from a non-WSLg distro. On WSL2 with Windows 11 (or Win10 21H2+), WSLg already bundles one — local Linux GUI apps open with nothing extra installed.</p>

Extending video clips with AI on a 12 GB GPU — six models compared

8-digit BINs explained: what the IIN expansion means for card BIN lookups (2026)

What a BIN/IIN actually is</h2> The first digits of a card’s PAN (primary account number) identify who issued it. Two terms for the same thing:</p> BIN</strong> — Bank Identification Number</em>, the older industry term.</li>

The practical fallout for lookups</h2> This is the part that bites if you maintain or consume a BIN database:</p>

FAQ</h2>

Did my card number get longer?</h3> No. The total PAN length is unchanged. Only the split</em> between issuer-identifier and account-identifier moved — issuer up by two digits, account down by two.</p>

Can I still do a 6-digit lookup?</h3> You can, and for many ranges it’s still fine — but it’s no longer guaranteed</em> to identify a single issuer. Treat 6-digit results as approximate and prefer 8 when you have them.</p>

Find which process is using a port on Linux (ss, lsof, fuser) — 2026

FAQ</h2>

How do I see established connections, not just listeners?</h3> Drop -l</code>: sudo ss -tnp</code> shows active connections. Add state established</code> to filter.</p>

Local speech-to-text with whisper.cpp — a self-hosted Google Speech API alternative (2026)

FAQ</h2>

Is this the same model as OpenAI’s Whisper?</h3> Yes — whisper.cpp</code> runs the released Whisper weights (converted to GGML/GGUF). The output quality matches the corresponding model size; only the runtime differs.</p>

Five ways to get b-roll from one ride — all on a local GPU

Stitching drone panoramas: OpenCV vs Hugin, benchmarked

bchunk — convert .bin/.cue images to .iso and .wav on Linux and macOS

Windows</h3> Use WSL and apt install bchunk</code>. There’s an old native port but WSL is easier.</p>

Common gotchas</h2>

binlist.net — how a Fuerteventura holiday side-project became iinlist.com

1. By hand (network only)</h3>
Take the first digits and match them against the table above. Good enough when all you need is “is this Visa or Mastercard?”.</p>

What was Launchy?</h3>
A free, open-source keystroke launcher for Windows (later cross-platform), first released by Josh Karlin around 2004. Hotkey, type a few letters, fuzzy-match, launch — “Quicksilver for Windows”. The 2007 video shows it on the Shiny skin.</p>

Is Launchy still maintained?</h3>
No — development tapered off around 2010 and it’s effectively dormant. On Windows today use PowerToys Command Palette, Flow Launcher, or Raycast.</p>

Does SSH X11 forwarding still work in 2026?</h3>
Yes — `ssh -X</code> (or -Y</code> for trusted forwarding) is unchanged. It forwards X11 to any X server: VcXsrv, Xming, XQuartz, or WSLg’s. It’s just chatty over latency, which is why xpra/waypipe/RDP usually win for remote work today.</p>`

Do I still need an X server at all?</h3>
Only to forward GUI apps from a remote box over SSH, or to run X apps from a non-WSLg distro. On WSL2 with Windows 11 (or Win10 21H2+), WSLg already bundles one — local Linux GUI apps open with nothing extra installed.</p>

Did my card number get longer?</h3>
No. The total PAN length is unchanged. Only the split</em> between issuer-identifier and account-identifier moved — issuer up by two digits, account down by two.</p>

Can I still do a 6-digit lookup?</h3>
You can, and for many ranges it’s still fine — but it’s no longer guaranteed</em> to identify a single issuer. Treat 6-digit results as approximate and prefer 8 when you have them.</p>

How do I see established connections, not just listeners?</h3>
Drop `-l</code>: sudo ss -tnp</code> shows active connections. Add state established</code> to filter.</p>`

Is this the same model as OpenAI’s Whisper?</h3>
Yes — `whisper.cpp</code> runs the released Whisper weights (converted to GGML/GGUF). The output quality matches the corresponding model size; only the runtime differs.</p>`

Windows</h3>
Use WSL and `apt install bchunk</code>. There’s an old native port but WSL is easier.</p>`