[GH-ISSUE #543] More clearly and directly explain why this better than ncdu/baobab/everything else out there #237

New Issue

2026-06-08T11:26:16+03:00

zhus commented

2026-06-08 11:26:16 +03:00

Originally created by @infinity0 on GitHub (Dec 9, 2025).
Original GitHub issue: https://github.com/bootandy/dust/issues/543

Just wanted to say thanks, the main algorithm that this tool uses is great, and has helped me delete several of my hacky sysadmin shell scripts that I was using previously to achieve the same effect.

The reason why it's great, IMO is not played up in a very clear way in the docs. This means that this tool has gone over the heads of various online NPC commentators talking about it. Here is my take, feel free to reuse/adapt/add to the docs:

With ncdu/baobab/etc, these still just give you a view of directory sizes but you have no idea where the largest files are. For example directory A could have a size larger than directory B, but in fact the largest file is in B and not A. Finding this out via these other tools is not trivial: it is a red herring to start browsing the largest directories manually, you will waste your time, and in fact it is quickest to simply skip these tools entirely and just do something like find . -type f -print0 | du --files0-from=- -xsh | sort -h. Or, just run dust -F -p.

Another advantage of dust is that it Just Does The Right Thing when combining files and directories. ncdu/baobab don't handle files well (as just explained), and du skips outputting files inside directories on purpose "to avoid double-counting hard links" - unless you give -l in which case it will output both files and directories but count hard links multiple times. This is a defect that is dressed up as unavoidable, but dust blasts through this gaslighting and Just Does The Right Thing.

One further issue with the docs, is that -n could be more clearly explained as the main parameter you probably want to tweak i.e. the number of largest files-or-directories to show. The current description "number of lines of output to show" does not do this justice; it is not like head -n or tail -n, but rather dust's -n is intelligent and primary to how its algorithm works, and is in fact what users care about most of the time. With du and previous tools, the main reason I messed around with --max-depth was only because I was trying to figure out the largest files-or-directories, I didn't actually care about specific depths - i.e. we only used -d because other tools don't have dust's -n option. But now that we have it, I realise it is the main thing I actually cared about all along. (Of course, sometimes you might still want --depth for its own sake, but these cases are secondary.)

Originally created by @infinity0 on GitHub (Dec 9, 2025). Original GitHub issue: https://github.com/bootandy/dust/issues/543 Just wanted to say thanks, the main algorithm that this tool uses is great, and has helped me delete several of my hacky sysadmin shell scripts that I was using previously to achieve the same effect. The reason why it's great, IMO is not played up in a very clear way in the docs. This means that this tool has gone over the heads of various online NPC commentators talking about it. Here is my take, feel free to reuse/adapt/add to the docs: With ncdu/baobab/etc, these still just give you a view of *directory* sizes but you have no idea where the largest files are. For example directory A could have a size larger than directory B, but in fact the largest file is in B and not A. Finding this out via these other tools is not trivial: it is a red herring to start browsing the largest directories manually, you will waste your time, and in fact it is quickest to simply skip these tools entirely and just do something like `find . -type f -print0 | du --files0-from=- -xsh | sort -h`. Or, just run `dust -F -p`. Another advantage of `dust` is that it Just Does The Right Thing when combining files and directories. ncdu/baobab don't handle files well (as just explained), and `du` skips outputting files inside directories on purpose "to avoid double-counting hard links" - unless you give `-l` in which case it will output both files and directories but count hard links multiple times. This is a defect that is dressed up as unavoidable, but `dust` blasts through this gaslighting and Just Does The Right Thing. One further issue with the docs, is that `-n` could be more clearly explained as the **main parameter you probably want to tweak** i.e. the **number of largest files-or-directories to show**. The current description "number of lines of output to show" does not do this justice; it is not like `head -n` or `tail -n`, but rather dust's `-n` is intelligent and primary to how its algorithm works, and is in fact what users care about most of the time. With `du` and previous tools, the main reason I messed around with `--max-depth` was only because I was trying to figure out the largest files-or-directories, I didn't actually care about specific depths - i.e. we only used `-d` because other tools don't have dust's `-n` option. But now that we have it, I realise it is the main thing I actually cared about all along. (Of course, sometimes you might still want `--depth` for its own sake, but these cases are secondary.)

zhus closed this issue

2026-06-08 11:26:17 +03:00

zhus commented

2026-06-08 11:26:17 +03:00

@bootandy commented on GitHub (Jan 7, 2026):

Thanks for the feedback, I'll update the readme.

@bootandy commented on GitHub (Jan 7, 2026): Thanks for the feedback, I'll update the readme.

zhus commented

2026-06-08 11:26:17 +03:00

@bootandy commented on GitHub (Jan 7, 2026):

updated. thanks for your thoughts. Much appreciated

https://github.com/bootandy/dust/blob/master/README.md

@bootandy commented on GitHub (Jan 7, 2026): updated. thanks for your thoughts. Much appreciated https://github.com/bootandy/dust/blob/master/README.md

zhus referenced this issue

2026-06-08 11:27:36 +03:00

[PR #237] [MERGED] Fix: Predictable iteration order #369

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bootandy/archived-dust#237