seenix

Every byte of a Nix closure, one pixel each. Each store path's NAR is laid out along a Hilbert curve, so bytes that sit together in a file sit together on the map. The layout needs only narinfos; NARs are fetched from cache.nixos.org as you zoom in, decompressed in the tab, and checked against their signed hashes. Nothing runs on a server.

Try:

Pick a closure to map.

    Reading the map

    One pixel is one byte of NAR. Paths are sorted by name with the root first, and the curve visits them in that order, so each path is one connected region. Until a NAR is fetched its region is hatched in the package's colour. Zoomed in far enough, NARs are fetched automatically while what is on screen stays under 64 MiB; beyond that the toolbar offers to fetch what is visible.

    bytes: 0x00 black, control bytes green, printable ASCII blue, high bytes red to amber, 0xff white, each shade following the byte's value once a pixel is one byte. Further out a pixel covers many bytes, so it shows their mix of those classes. sections: what each byte of an ELF file is for, from its section headers: code, read-only data, writable data, symbols, relocations and debug information. entropy: compressed and random data is bright, code and text middling, zeros and repetition dark. package colours by package.

    Drag or use the arrow keys to pan; scroll, pinch, + and - to zoom; double-click or double-tap to zoom in; 0 fits the closure, f flies to the pinned path, Esc unpins it. Hovering names the path, the file inside its NAR, the ELF section, and the store path a reference string points to.

    Fetched NARs are kept in this browser's origin private file system, up to 2 GiB, and their summaries in IndexedDB, so a map seen once loads from disk next time.