If you came from Windows and AIDA64 or HWiNFO64, you probably assume every OS exposes roughly the same sensor data and the differences are just UI. They don’t, and the gaps aren’t random, some are kernel design choices, some are vendor politics, one is a CVE. Here’s the actual map.

The foundation: hwmon is a stable kernel ABI, Windows has nothing like it

Linux’s hwmon subsystem is a documented, versioned kernel interface: any driver that wants to expose a temperature, fan speed, or voltage registers with it, and userspace reads it the same way regardless of vendor.

It’s been stable for decades. Windows has no equivalent: there is no official API for CPU package temperature or motherboard Super-I/O sensors, which is exactly why Windows tools like HWiNFO64 need a signed kernel-mode driver (historically WinRing0-class) just to read what Linux exposes through a plain sysfs file.

This is the one area where Linux is unambiguously ahead, not a niche opinion, a structural fact about the two kernels.

GPU temperature: AMD gives you two numbers, NVIDIA gives you one

AMD’s amdgpu driver exposes both edge temperature (an average across the die) and junction (hotspot) temperature, the single hottest point on the die, both through standard hwmon. That’s genuinely useful: tracking the gap between the two over time is one of the earliest signs of drying thermal paste, months before it shows up as a crash.

NVIDIA’s NVML, on Linux, exposes only edge temperature. No junction reading, at all, today. This isn’t a driver bug or an oversight in this app, it’s simply not in the API NVIDIA ships. If you’re on an NVIDIA card and wondering why some tools only show you one GPU temperature number, that’s why.

Why the same asymmetry runs the other way for throttle diagnosis

NVML does expose something AMD doesn’t: a live bitmask of why clocks are currently reduced, thermal, power cap, or the motherboard itself limiting delivery over PCIe. AMD’s amdgpu has no equivalent throttle-reason readout today.

So the ledger evens out in a strange way: AMD wins on hotspot temperature, NVIDIA wins on throttle-cause diagnosis, and neither vendor is symmetric with the other. Two completely different blind spots, not one vendor being generally worse.

CPU power: real data, gated behind a CVE

Intel CPUs expose package power draw through RAPL (Running Average Power Limit), /sys/class/powercap/intel-rapl:0/energy_uj, a real energy counter, not an estimate. Since 2020 it’s root-only by default on most kernels, because of CVE-2020-8694 (“PLATYPUS”): RAPL’s power readings can leak enough information to act as a side channel for extracting data from the CPU.

That’s not paranoia, it’s a real, named, patched vulnerability. Reading your own CPU’s power draw isn’t dangerous by itself, the kernel just locked the whole interface down rather than try to reason about which reads are safe.

Getting it back requires an explicit, one-time opt-in (a udev rule + a graphical polkit prompt, no root shell required afterward), which is exactly the kind of tradeoff a monitoring tool should make visible instead of silently sudo-ing around it.

DDR5 DIMM temperatures: an address space, not a driver

DDR5 modules commonly expose an on-module temperature sensor over SMBus, at addresses 0x50 through 0x57, the full 3-bit JEDEC SPD address space, one address per DIMM slot. That means up to 8 DIMMs on a single SMBus segment are readable with straightforward I2C transactions, no special driver, just addressing the right chip.

Past 8 DIMMs (workstation and server boards with more slots than that on one segment), boards switch to a vendor-specific I2C multiplexer chip to fan out further, which is a meaningfully different, higher-risk integration problem (walking mux channels on a bus shared with fan controllers and power monitors), not just “read a few more addresses.”

What Windows and macOS get wrong that Linux doesn’t

Windows: no hwmon, no official CPU/motherboard sensor API, full stop, hence the kernel-driver requirement above.

macOS, on Apple Silicon specifically, is arguably worse for this than Windows: sensor data comes from undocumented SMC (System Management Controller) keys that every existing Mac monitoring tool reverse-engineers per chip generation, and Apple can silently break or move those keys across OS releases.

There’s no stable ABI to target at all, hwmon on Linux has been the same interface for years; SMC on macOS is a moving target by design.

The takeaway

None of this is “Linux good, everything else bad” as a slogan, it’s a specific, checkable map: hwmon gives Linux a real structural advantage over Windows for raw sensor access, AMD and NVIDIA each expose one thing the other doesn’t on GPUs, CPU power data exists but is deliberately gated behind a real CVE, and DIMM temperature reads scale cleanly up to 8 slots before hitting a genuinely harder problem. If a tool tells you otherwise, one of you is wrong, and it’s worth knowing which.