It could be that they chose something bleeding edge and the hardware drivers were built for windows but might be a couple revisions behind for the Linux equivalents. It could be the development cycle for windows vs that of Linux and how they integrate with new hardware. Just a hypothesis.
https://news.ycombinator.com/item?id=46002989
(i.e. no license, have to fallback to unaccelerated software-only implementation)
To my knowledge Linux isn’t that capable on BIG.little architectures, and Linux power-management (as this intersects with) has always left a little to be desired - when comparing battery life to Windows.
Disclaimer: pure speculation. Possibly misinformed :-D
As much as I want to use Linux on the desktop I've had terrible cases of instability:
My hardware on Windows 10 works perfectly well. Literally 11 years of being super stable, running assorted workloads (WSL 2, Docker based development, browsers, heavy terminal based workflows with Neovim, tmux, etc., video recording and editing, image editing, gaming, etc.). There's no lag, jittering or instability. My system never crashes or has weird issues requiring a reboot on Windows 10.
1 day into using Arch Linux, as soon as my GPU's memory gets close to 75% full then apps crash, my Wayland based window compositor (niri) starts to fail in unpredictable ways and I have to reboot basically every 3 hours because of GPU memory usage.
It's not stable or very usable IMO.
All I did was open 3 Firefox windows and 2 Ghostty terminals. Both apps are hardware accelerated so they use GPU memory.
Windows seems like it does something magical with how it offloads GPU requested memory to system memory in a transparent way if GPU memory is full but Linux, at least with the official proprietary 580 series DKMS NVIDIA drivers doesn't seem to do this with my GTX 750 Ti. Instead, I get kernel errors from the NVIDIA drivers when it fails to allocate memory, such as:
kernel: [drm:nv_drm_gem_alloc_nvkms_memory_ioctl [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to allocate NVKMS memory for GEM object
It's wild that my system can be using 2 GB out of 16 GB of system memory at 5% CPU load with no disk I/O happening but I can't run a few apps in parallel, it's especially bad when trying to record 1080p videos with OBS. I recorded literally over 1,000 videos on Windows without a single hiccup.I wrote a lot more details about this Linux issue in an Ask HN but it didn't gain traction https://news.ycombinator.com/item?id=46436245.
I have to hand it to Windows with how it manages system memory and "just works", especially with older hardware.
Also as an aside, Ghostty on this Linux machine is very slow compared to the Windows Terminal. Opening half a dozen Neovim splits on my 4k monitor completely tanks its performance to where there's a lot of input lag and jitters. The screen redraws are very slow. The Microsoft Terminal had no issues with the same Neovim version and configs running in Arch Linux within WSL 2, it was buttery smooth. I opened a discussion about this on Ghostty with more information https://github.com/ghostty-org/ghostty/discussions/10114.
In 2019 I tried switching to native Linux and it failed with my Scarlett 2i2 USB audio interface. I got endless crackles and pops and after 5 days of debugging and trying everything I gave up and went back to Windows.
In Dec 2025 I tried switching to native Linux with the same hardware and the audio problems are solved but now there's this GPU memory problem. I spent another few days debugging as much as I could but it's looking like it's back to Windows.
I think the GPU issues probably won't be solved in 7 years because NVIDIA said they are going to end of life the 580 series drivers in August 2026 and the 590+ series don't support my card. The open source drivers produced a worse experience, it wouldn't let me use my 4k monitor and hard locked my machine a few times.
As a scientist myself I would do my best to figure out why before publishing something like this.
The consumer loses out but that's not something new either.
Responsible articles and journals note these things.