Show HN: Leaves – A text-UI disk usage treemap visualizer (github.com)
On containers or remote servers, the options are limited to purely text based utilities (e.g. du) or list-centric TUIs (e.g. ncdu) which are usually limited to viewing one directory at a time.
I created leaves to fill that gap.
Inspired by classic utilities like WinDirStat and KDirStat, it uses a 2-dimensional treemap^1 visualization to show the entire directory hierarchy with proportionally sized rectangles.
It's performant enough to handle millions of files, thanks to Rust and multi-threading. However, block characters aren't as suited as pixels for resolving a large number of items. Leaves can show file-type summaries per directory or partition the top-level directories by extension, allowing you to see not only where space is being used, but also how.
For instance, I can see the largest chunk of my home directory is taken up by uv caches for python and old Linux ISOs that I could easily re-download if needed. Or in a particular container, +600MB is used by standard Rust documentation and tutorials, and that it is the only location with HTML/JS files, when only the libraries and build tools are needed (note to self: remember to use the minimal profile next time).
^1: https://github.com/shundhammer/qdirstat/blob/master/doc/Tree...
29 comments
[ 0.29 ms ] story [ 43.8 ms ] threadIf possible, being able to “brew install” on a Mac would be killer
What I really also want is a way to do an offline index that this reads ... I ended up using duc. Maybe I will fork and add it!
thanks for sharing!
Naturally ncdu wasn’t installed, so it took me a bit to figure out what the heck happened.
It’s interesting and ironic how so many things in proxmox that would normally release space, instead become nonfunctional when the disk is full. Things like deleting old VM disks or cached iso’s will fail via the interface. I think the web console also broke, had to ssh in to manually free space up.
I found out that 'zfs destroy' has a dry-run option along with one that can show reclaimed space. After this i hacked together a little cli tool [1] that calculates what snapshots need to be deleted to reclaim e.g. 10GB.
It's not really production ready but from time to time it's useful :-)
1: https://github.com/sandreas/zfs-tool
I might borrow a little from that CI workflow for cross-compilation.
A pity we can't use something like this (and actually take action on the results) on closed systems like iOS (I've just had to factory reset my iphone to rein in a 37GB "system data" mess... even on the newly restored phone that consumes 15GB but at least that's better).
https://gist.github.com/dunhamsteve/59f5e6b9a4bc69039853674d...
re: memory usage, because of the price of RAM these days, my original plan was for a hierarchical memory usage analyzer, but attribution of shared libraries on Linux isn't straightforward.
"Real" memory usage is unfortunately ill-defined since it could mean "memory freed by killing a process", "memory allocated specifically to the process", "proportional of system memory shared by other processes", etc.
Such a tool would likely need multiple subcommands to reflect how the user's intent, along with an extensive README to explain the subtleties.
To illustrate, if we only show the proportional set size in a hierarchy (e.g. IDE with LSP... I'm looking at you rust-analyzer!), but the user wants to know how much memory could be reclaimed by killing the parent process, two things could happen, as far as I understand. If it's the only hierarchy using a large chunk of shared libraries, the PSS will be pretty close. However, if other apps are using those libraries, very little memory will be freed (mostly what was allocated specifically to the killed app).
On top of that, we also have to consider swap space.
I may revisit this in the future once I have a better understanding of smaps and friends, if RAM prices don't normalize anytime soon.
I've had on my someday bucket list doing up a web based version of daisy disk as a docker image I can slap on my various servers, but this is probably just as good an approach. I like it.