amdgpu_top VS cargo-deb

This exists for AMD: https://github.com/Umio-Yasuno/amdgpu_top

i use amdgpu_top to monitor my gpu's power consumption

btop is a great tool to monitor cpu/disks/network/processes. For GPU, you could look at amdgpu_top.

git clone https://github.com/Umio-Yasuno/amdgpu_top cd amdgpu_top cargo install --locked --path .

Ok, AMDGPU_TOP v0.1.3 is released. And the deb package is released at the same time (thanks cargo-deb).

cargo deb?

Rust actually works fine with distros. See for example https://github.com/kornelski/cargo-deb and https://wiki.archlinux.org/title/Rust_package_guidelines

I use Arch Linux and Most Rust programs I use are installed from the Arch repositories or AUR. Rust packages are very well integrated with the distro, they depend on distro packages and have other packages depend on it. As far as the user is concerned, the Rust build system is just a developer-only stuff like CMake or autotools or ninja or whatever.

Anyway I would like to point out that C++ also do something similar to what Rust libraries typically do, which is to use header-only libraries that don't appear as separate distro packages. It's as if every Rust library meant to be used by Rust programs (as opposed to libraries that expose a C API that can be called by other languages) were a header-only library. And this is actually great because Rust (like C++) monomorphizes generics, that is, if you call a generic function defined on another crate, the compiler actually generates a new function just with the type parameters you supplied, and there's no way the library can know upfront which generic instantiations will happen over all programs that use it.

On the reproducibility front, I think it would be great if C program actually did what Rust does and pinned the exact damn versions of all libraries they use (like Cargo.toml does)