Oh okay, I had assumed compiling would be a bit more I/O bound, while gaming would be a bit more CPU bound, but I guess you're right about the benchmarks!
SteveTech
If it helps, I wrote a KDE widget to switch between the modes: https://github.com/Steve-Tech/KDE-AMD-X3D-Selector
My understanding is amd_x3d_mode
basically prioritises what cores the scheduler will assign tasks to.
I usually keep it on cache since I do a lot of code compilation, but I will usually switch it to frequency for gaming and stuff.
No it's real! I can't verify the exact rating since it OL's my meter, but with some circuitry it can power my Pi for a few minutes. I got them from element14, so it's unlikely to be a fake product.
You can host a page with an iframe, but you can't directly change the DNS record to point to something that isn't GitHub.
Guys you're not gonna believe this:
The common sketchy performance advice is to disable mitigations in the kernel, this post is about disabling mitigations in Intel's userspace graphics stack because it's already checked in the kernel.
Assuming you meant disabling kernel mitigations, since AFAIK audio stuff doesn't usually use OpenCL:
Has anyone else here disabled it?
Nah, my understanding is it's not worth it on newer CPUs, and in some cases, the microcode expects things to be mitigated for best performance. Older CPUs (pre-2019ish) it does make a difference though.
But you're welcome to benchmark it, and see if it makes a worthwhile difference on your CPU. Kernel mitigations are easy enough to turn on and off.
I think they were trying to say that the cage in front with the AP behind, acts as a directional antenna. Similar to how Yagi antennas have metal elements that aren't connected in front of the actual antenna.
But I don't know enough antenna theory to know if that's correct.
I've previously found OpenRGB's udev rules to be a really good example since there's a bit of everything in there: https://openrgb.org/releases/release_0.9/60-openrgb.rules
But I think you'd want something like: SUBSYSTEMS=="usb|hidraw", ATTRS{idVendor}=="REPLACE WITH USB VENDOR", ATTRS{idProduct}=="REPLACE WITH USB PRODUCT", TAG+="uaccess"
It's not strictly Linux anymore, but I wrote a library (or userspace driver?) in Python that interacts with a ChromeOS Embedded Controller found in Framework Laptops and Chromebooks. The driver part of it interacts with the EC directly over the IO ports, which was originally written for Linux but later ported to FreeBSD and Windows since IO ports aren't at all OS specific. It can also talk to the cros_ec_dev
driver on Linux if it's loaded.
https://github.com/Steve-Tech/CrOS_EC_Python
I wrote a GUI utility for Framework Laptops too, which also serves as the example for CrOS_EC_Python: https://github.com/Steve-Tech/YAFI
help
now actually opens the help utility on Python 3.13!
Thanks TIL! Although I prefer this diagram that has all the wifi channels on it, instead of just the 3 common ones.
I know this seems pretty much solved, but I just wanted to point out:
Frigate doesn't need a TPU, OpenVINO is quite performant even on decade old Haswells, or if you've got a GTX 750 or higher you might be able to use that as well.