llama.cpp Linux CUDA binaries still lag Windows releases

Hot take: this is a distribution problem, not a capability problem, and llama.cpp is effectively nudging Linux users toward source builds, distro packages, or containers instead of one-size-fits-all CUDA tarballs.

• –The release assets list Windows CUDA builds, while Linux assets are CPU/Vulkan/ROCm/OpenVINO focused: https://github.com/ggml-org/llama.cpp/releases
• –Upstream Docker docs show official Linux CUDA images (`full-cuda`, `light-cuda`, `server-cuda`), so Linux CUDA support exists but is container-first: https://raw.githubusercontent.com/ggml-org/llama.cpp/master/docs/docker.md
• –Build docs include first-class CUDA instructions for Linux (`-DGGML_CUDA=ON`), confirming no fundamental technical block: https://raw.githubusercontent.com/ggml-org/llama.cpp/master/docs/build.md
• –In packaging discussions, collaborators call out Linux distro/package policy friction for backend-split binaries, which explains the conservative release strategy: https://github.com/ggml-org/llama.cpp/discussions/15313
• –New Debian/Ubuntu packaging notes also highlight toolkit-version constraints (and newer GPU support gaps) when relying on distro CUDA stacks: https://github.com/ggml-org/llama.cpp/discussions/20042