gdu VS bottom

Not sure these are really popular, but I cannot resist advertising a few utilities written in Go that I regularly use in my daily workflow:

- gdu: a NCDU clone, much faster on SSD mounts [1]

- duf: a `df` clone with a nicer interface [2]

- massren: a `vidir` clone (simpler to use but with fewer options) [3]

- gotop: a `top` clone [4]

- micro: a nice TUI editor [5]

Building this kind of tools in Go makes sense, as the executables are statically compiled and are thus easy to install on remote servers.

[1]: https://github.com/dundee/gdu

[2]: https://github.com/muesli/duf

[3]: https://github.com/laurent22/massren

[4]: https://github.com/xxxserxxx/gotop

[5]: https://github.com/zyedidia/micro

For anyone that likes ncdu I would highly recommend gdu. https://github.com/dundee/gdu

gdu is faster

gdu - Just a very fast and cool disk usage explorer

The RPCS3 flatpak lives in /home/deck/.var/app/net.rpcs3.RPCS3. I'd advise you to install a tool like gdu or use something like du -h --max-depth=1 in the console in that directory, to find where the disk usage goes. There are also GUI tools, but I prefer these myself.

While ncdu does the job I've found gdu (similar tool written in Go) significantly faster for larger directories.

https://github.com/dundee/gdu

There's also gdu, which is much faster on SSDs.

bottom

I'd suggest Bottom as a TUI alternative to the in-built task managers - https://github.com/ClementTsang/bottom

It works on Windows also.

If anyone is looking for a "top" like, written in Rust, might have a look at https://github.com/ClementTsang/bottom

Looks like bottom with another theme

bottom - A cross-platform graphical process/system monitor with a customizable interface and a multitude of features.

As a macOS user, it boils my brain whenever I've to type in something like ~/Library/Application Support/org.rust-lang.Cargo/config.toml. macOS users have been begging CLI tools to support XDG variables on macOS too. Setting defaults is a strong indication to the community what should be the "preferred" locations. The defaults defined in your article will invariably lead to some authors saying that if that path is good enough for cargo, then it is good enough for their tool. Even the latest draft RFC acknowledges that macOS should use XDG variables too. I've written more about this here.