OEMs perform rigorous stress-test cycles during development. For example they might require a machine to suspend+resume 1000 times in a row. This shakes out bot

OEMs perform rigorous stress-test cycles during development. For example they might require a machine to suspend+resume 1000 times in a row. This shakes out both OS + driver issues before they go to market. This level of rigor is important to avoid support calls + RMAs, which are expensive for the OEM. Many Linux drivers can't pass this level of rigor. Back when I used to care about this professionally (before 2014), video + wifi drivers were some of the worst culprits. Each variant of each chipset would need its own driver, and often those drivers needed tweaks for stability. Firmware implementations are (were?) also built + tested exclusively for Windows, and Linux is different enough that it can trigger untested/broken code paths or otherwise cause firmware to misbehave. Linux also has its own set of issues with ACPI + UEFI. Canonical, RedHat, etc have teams dedicated to enablement and testing for OEMs like Dell that ship computers with Linux. Back when I was involved, Canonical had 60+ people dedicated to this, and qualified hundreds of SKUs each year. Even then they don't cover all hardware. The fixes+workarounds those teams produce also take time to make their way upstream.