LACT is a graphical tool for AMD Radeon information reporting, GPU overclocking, fan control, power/thermal monitoring, and additional power state configurations.
v0.5.3 adds support for displaying the current graphics clock “current_gfxclk”, information around GPU throttling is now reported, improved fan control for older GPUs, improved fan curve point adjustments, many bug fixes, and other enhancements.
Separate daemon & GUI processes… Permissions aware… Modular installation of modprobe config… It looks like the author understands the basics of designing a tool like this. Nice.
I have a couple of reservations from a security perspective, though:
- The daemon and GUI are the same executable, which means a lot of complexity in the binary that runs in a privileged context. I would suggest splitting the daemon into a separate, minimal binary.
- 268 dependencies might be tough for some people to swallow.
Wow I when you said 268 dependencies I figured JavaScript was involved…
Is the culture of Rust/Cargo getting as bad as JS/NPM these days or is this developer just using an insane amount of dependencies? I don’t have any experience working with Rust so I’m genuinely curious. I stay away from JS in part due to the insane amount of dependencies every non-trivial project has.
I’ve built projects in many languages and other than a few JS/React/ReactNative projects which seem to have unavoidably massive node_modules folders, I’ve never had more than maybe 10 dependencies in a project ever…
Is the culture of Rust/Cargo getting as bad as JS/NPM these days or is this developer just using an insane amount of dependencies?
From a quick glance through the files, I see maybe a couple dozen direct dependencies. That’s not what I would call conservative (especially for a privileged daemon) but the bulk of those hundreds seem to be sub-dependencies.
I’ve seen similar in the other Rust projects that caught my attention. I suppose this is a predictable result of Rust’s Cargo culture: When pulling in other people’s code is convenient, automated, and normalized, it tends to happen a lot, and the transitive nature of dependencies amplifies the effect.
So even a small project can easily include code from hundreds of random people other than the author, with practically no accountability, as we see here. And since it’s a long tail of small and often obscure projects, rather than a handful of well-known ones like a standard library, there is little hope of meaningful auditing.
There also seems to be a culture of statically linking all those dependencies. That means security patches will never reach a user through OS updates, and with so many dependencies involved, chances are slim that every upstream vulnerability will be patched on the user’s machine soon after it’s discovered (if ever).
I would find Rust more appealing if it had a standard library (and maybe a few high-profile well-maintained external libs) comprehensive enough to cover most needs, and if the tooling and culture encouraged minimizing dependencies. I think the former might develop with time. I fear the latter might not ever appear.