The catalog — what's different

The unpins catalog is a curated set of common programs that upstream doesn't ship as portable single-file binaries (see the packages page for the current list). We build them with Nix and publish one executable per OS. Four properties make these builds different from what you usually get:

• Single binary, no third-party shared libraries. CI rejects any artifact that imports a third-party DLL / dylib / so. Linux builds are musl-static; macOS depends only on libraries Apple guarantees (libSystem, frameworks, libobjc); Windows depends only on system DLLs in System32. Some programs need read-only data files — vim's runtime scripts, for example — which ship in a separate .tar.zst next to the binary and are extracted by unpin install. The binary itself loads no third-party code at runtime.
• Cross-OS parity from one recipe. The same Nix flake produces a Linux, macOS, and Windows build of the program (when feasible — see "Scope and limits" below). When upstream fixes a bug, all three platforms get the fix from a single source change.
• Runs on old systems. Linux binaries use musl and don't pin a glibc version, so they work on a 5-year-old Debian, a minimal Alpine container, or anything with a reasonable kernel API. No "this binary needs glibc 2.36" surprises.
• Reproducible from source. Every catalog flake is public. Run nix build github:unpins/htop on your machine and you get a byte-identical binary. Don't trust our CI? Rebuild it.

The CLI — a convenience layer

unpin is a small Rust binary that does one thing: fetch a GitHub release asset, verify its SHA256, and drop it in PATH with a normalized name. It has two install modes:

• unpin install htop — resolves to the unpins catalog (unpins/htop). You get our reproducible build with the properties above.
• unpin install jgm/pandoc — installs from any <owner>/<repo>. You get whatever that upstream published; unpin picks the right asset for your OS / arch and verifies the SHA256, but doesn't audit the binary. The reproducibility and single-binary guarantees do not apply here.

There are similar tools in this space — eget, ubi, dra. The unpins CLI's main pluses are the aliased catalog and a one-line cross-OS bootstrap. The catalog is the part of unpins that's genuinely different.

How it compares

The closest competitors in user mental model, and where unpins fits:

Scope and limits

• We don't replace your OS package manager. apt, dnf, brew still own the system pieces — libc, the kernel, X11, fonts. unpins focuses on user-space programs.
• Not every program reduces to one binary. Some programs — bash on Windows, for instance — have upstream architectures that assume POSIX semantics or fork-exec patterns that don't fit a single .exe; those don't make the catalog. The packages page shows which platforms each program supports.
• Non-catalog installs are SHA256-pinned downloads, not audited builds. When you unpin install <owner>/<repo>, we don't rebuild or audit that binary — we trust the publisher. The reproducibility and single-binary guarantees apply only to the unpins catalog.

How to verify yourself

Every catalog flake is public on GitHub — inspect the build recipe and rebuild it locally:

Read a flake to see exactly what we patch, what we link, and how the artifact is verified — start with github:unpins/htop/flake.nix. Shared build helpers are in nix-lib, CI workflows in action-build, and the project's technical documentation — architecture, the single-binary policy, per-platform notes, patch recipes, templates — in docs.