110
submitted 2 months ago by d3Xt3r@lemmy.nz to c/linux_gaming@lemmy.world

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.

top 12 comments
sorted by: hot top controversial new old
[-] mox@lemmy.sdf.org 26 points 2 months ago* (last edited 2 months ago)

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.
[-] didnt_readit@lemmy.world 6 points 2 months ago

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…

[-] mox@lemmy.sdf.org 11 points 2 months ago

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.

[-] didnt_readit@lemmy.world 3 points 2 months ago

That is...unfortunate.

I've been thinking about learning Rust after hearing about it's benefits, but was put off by its ugly type syntax that I hate from C++ and the whole "fighting with the borrow checker to do simple stuff" thing. But now it seems it also has the terrible bloated dependency culture I hate from JavaScript too!

IMO any security benefits from the increased memory safety are immediately nullified by the security nightmare that is hundreds of statically compiled dependencies...

I guess I'll keep waiting on the sidelines and see how the standard lib and dependency culture evolves.

[-] mox@lemmy.sdf.org 4 points 2 months ago

You're not alone in finding the syntax awkward and ugly. :)

Rust's promise of lifetime management that can (with help from the programmer) be guaranteed correct is very appealing to me, but that feature alone is not enough to justify excessive code complexity or bad ergonomics.

IMO any security benefits from the increased memory safety are immediately nullified by the security nightmare that is hundreds of statically compiled dependencies…

Rust undermines itself in another way, too: A systems programming language that's difficult to use encourages switching off the safety features when they get in the way. That's frowned upon by the community, but the incentive is there, so it happens nevertheless. The result: overly complex software that's annoying to write/maintain and doesn't always deliver on the language's defining promise.

And then there's the fact that not all dangerous bugs are solved by memory safety. It's no panacea.

I guess I’ll keep waiting on the sidelines and see how the standard lib and dependency culture evolves.

If you're interested in something that improves on C++, you might have a look at D. The basic syntax is similar, the advanced syntax is better, it offers memory safety tools less burdensome than Rust's, and has an optional garbage collector. I find the standard library a bit rough, but an improved next edition is in progress. The dependency management tool (Dub) supports not only libraries from a community repo, but also OS-provided libs, git repos, and plain old directories. After using it actively for a month or so, I feel the language itself is sane, and the maintainers seem to be making good decisions about polishing it up in future versions.

[-] Narann@lemmy.world 2 points 2 months ago

Is the culture of Rust/Cargo getting as bad as JS/NPM these days

Thanks for saying it.

When I see some rust projects, they looks like they where managed by JS devs (“1 need, 1 package”) that want to do compiled language… The amount of dependencies can be utterly insane.

For me, it mostly means rust have a strong package system, not that rust have good devs.

I’m doing Python at work and you have to use a many pypi package for financial reasons (yet, I restrict myself as much as possible), but seeing this mindset is scope specific open source project is crazy.

All of this does not means all rust (or JS) devs are bad, its just a consequence of bringing code to the masses: Its a good thing in many way. Lets acknowledge this and not being impressed by badly engineered dependency choices.

[-] nullPointer@programming.dev 5 points 2 months ago* (last edited 2 months ago)

I've had pretty good luck with radeon-profile. I'll have to give this one a go

[-] azvasKvklenko@sh.itjust.works 4 points 2 months ago

I undervolted my RX 6700XT using Corectrl. While the tool is good overall, it makes no sense for Gamescope-SteamOS-like setup with Bazzite, so I did something absolutely disgusting and run it in the background using xvfb. Now looks like I can replace it with something far more suited to my needs. Can’t wait to test it

[-] squid_slime@lemmy.world 3 points 2 months ago

Is this able to maintain its profiles between reboots? I use amd-clocks as its low profile set and forget unlike corectrl which would need to launch its ui each boot and ask for polkit auth

[-] d3Xt3r@lemmy.nz 3 points 2 months ago

Yes, it maintains its config across reboots, it uses a systemd daemon that handles the backend. On most distros it should just work automatically, but if not you can edit the config.yaml file to set up your permissions there.

[-] Potatofish@lemmy.world 2 points 2 months ago

It's great software. I'll have to try editing the permissions because on Tumbleweed it only works when run as root. It complains that the service isn't running as a user.

Also, I noticed that series 7000 gpus have serious problems under the most recent stable kerne when using an egpu setup. LACT shows that they cannot draw enough wattage, so they never get up to speed. Older gpus work fine.

[-] Lettuceeatlettuce@lemmy.ml 3 points 2 months ago

Been using it for about 2 months, it's worked flawlessly so far. A little bare bones, but that's fine, it does everything I need it to.

this post was submitted on 05 Mar 2024
110 points (99.1% liked)

Linux Gaming

13920 readers
426 users here now

Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.

This page can be subscribed to via RSS.

Original /r/linux_gaming pengwing by uoou.

Resources

WWW:

Discord:

IRC:

Matrix:

Telegram:

founded 11 months ago
MODERATORS