The Neighbours
Scope: the tools that answer the same
question — du first and honestly, then
the terminal rivals, then the graphical
and other-platform natives. Only du was
run for this guide; the rest are placed
from their own documentation, and
criteria.md says so.
du: the ancestor, still working
du computes the same numbers from the
same metadata and prints them as a table:
$ du -B1 homedir | sort -k2
4280320 homedir/.cache
81920 homedir/.cache/app-a
4194304 homedir/.cache/app-b
12288 homedir/Documents
26218496 homedir/Downloads
6029312 homedir/Pictures
35651584 homedir/Videos
72208384 homedir
Everything ncdu knows, du knew first:
-x is --one-file-system,
--apparent-size swaps the same two
rulers, and it counts hardlinked data
once per inode just as ncdu's totals do —
the two agree to the byte when the
options align (chapter 3's table).
What du gives back in return for having
no browser: it is everywhere (every
Unix, every rescue shell, every container),
it is scriptable (its output is the
input of a thousand monitoring scripts),
and one-shot questions are one command —
du -sh dir, or the classic top-ten
du -B1 dir | sort -rn | head. What it
costs: every new question is a new scan,
the table for a big tree is a haystack,
and there is no descending into a result
to ask "and inside that?" ncdu exists
because the follow-up questions are
usually the point.
Terminal rivals
- dust (Rust) prints a ranked, indented tree of the biggest entries in one shot — no browsing, which for a quick "top ten, biggest first" is exactly the right amount of program. Where ncdu's answer is a place to walk, dust's is a paragraph to paste into a ticket.
- dua-cli (Rust) is the closest relative: an interactive browser in the same spirit, plus a non-interactive aggregate mode for scripts.
- gdu (Go) goes after speed — parallel scanning — and speaks this guide's file format: it reads and writes ncdu's JSON exports (noted on ncdu's own site), so the chapter 6 workflow survives a change of browser.
None of these changes the arithmetic. Blocks, sparse files and hard links behave identically under all of them, because the filesystem is the one keeping score.
Graphical: pictures of the same tree
On a desktop, the question is often visual — "show me the disk" — and three presentations compete:
- Baobab (GNOME's Disk Usage Analyzer): bars and a rings chart, installed with GNOME on most Linux desktops.
- Filelight (KDE): concentric rings you hover and click to descend — the browser idea, drawn.
- QDirStat (Qt): a treemap, every file a rectangle sized by its bytes, with cleanup actions attached; the treemap is the one view that makes a single huge file look huge among ten thousand small ones.
Treemaps and rings answer "where is it big?" at a glance and are poor at "how many items, exactly, and what did it cost in blocks?" — the textual tools keep the exact numbers this guide trades in.
Other platforms
- macOS: GrandPerspective is the long-standing free treemap; DaisyDisk is the commercial, polished one. ncdu itself also runs (chapter 1) — the choice is picture versus keyboard, not capability versus none.
- Windows: WinDirStat draws the treemap (free, open source). WizTree takes the other road to the same map and is famously fast because it reads the NTFS master file table directly rather than walking the tree — the speed is real, and it is a Windows-only trick that no portable tool can copy.
Placing them
| Situation | Reach for |
|---|---|
| A server over SSH, a disk to explore | ncdu |
| One ranking, for a script or a ticket | du or dust |
| Exports, audits, a disk's history | ncdu (chapter 6) |
| A desktop, a non-terminal user | Baobab / Filelight / QDirStat |
| macOS, a picture | GrandPerspective |
| Windows | WizTree or WinDirStat |
The tools are interchangeable far more often than their fans admit. The habits are not: knowing which size you are reading, what was excluded, and how old the scan is — those transfer to whichever of these you open next.