bu ikiliyi karşı karşıya getirmek aslında biraz haksızlık; biri işletim sistemi katmanı, diğeri o katmanın üzerinde koşan bir hesaplama paradigması. ama pratikte ikisi sürekli aynı cümlede geçiyor, çünkü model eğitimi dediğimiz şey özünde bir kaynak yönetimi hikayesi: cuda sürücüsü, cudnn, nccl, pytorch derken zaten kendini apt ile paket çözen bir dünyanın içinde buluyorsun. zamanında yazdığımız gibi (bkz: #H11YKVb9bjUgc1y450k_k) tek bir çekirdek etrafında şekillenen dağıtımların farkı burada acımasızca ortaya çıkıyor; ubuntu nvidia sürücülerini sana kolaylaştırırken arch seni dkms ile baş başa bırakıyor, fedora ise rpmfusion üzerinden elini tutuyor ama bırakmıyor. yani mesele "hangi dağıtım daha iyi" değil, "hangi dağıtım seni model eğitirken daha az ağlatır" meselesi.
işin ekonomik boyutu da tam burada düğümleniyor: kurumsal taraf neredeyse tamamen rhel/ubuntu lts kilitli, çünkü cuda ve rocm matrisleri o sürümlere göre test ediliyor. kişisel taraf ise rolling release hevesine kapılıp her zypper dup sonrası nvidia-smi'nin "no devices were found" demesini izliyor. bu yüzden ciddi eğitim işlerinde insanlar genelde docker/podman konteynerine kaçıyor; host dağıtımı ne olursa olsun içeride sabit bir cuda runtime tutuyorsun, böylece "dağıtım savaşları" bir anda anlamsızlaşıyor. hatta şunu söyleyeyim: bugün bir ml mühendisinin gerçek düşmanı dağıtım değil, sürücü-matris uyumsuzluğu ve pip bağımlılık cehennemi.
bana kalırsa doğru soru şu: linux dağıtımları bir ml altyapısı için ne kadar şeffaf olmalı? gentoo'da her şeyi kendin derleyip use bayraklarıyla oynamak entelektüel olarak tatmin edici ama transformers eğitirken saatlerini openblas derlemeye harcamak akıl karı değil. pop!_os gibi dağıtımların bu boşluğu görüp nvidia sürücülerini kutudan çıkar çıkmaz hazır vermesi tesadüf değil, doğrudan bir pazar okuması. sonuçta ikisi rakip değil, aynı boru hattının iki farklı katmanı; biri diğerinin boşluğunu doldurduğu sürece mutlu mesut yaşıyorlar.