Linux dağıtımlarının tarihçesi ve kökenleri

Linux dağıtımı gerçekte nedir

Linux dağıtımlarının tarihi bir boşlukla başlar: Linux çekirdeği tek başına bir kullanıcının işine yarayacak hiçbir şey yapmaz. Sistemi başlatır ve donanımı bulur. Ardından durur. Birinin kullanıcı alanı (userland) eklemesi, yazılımın nasıl kurulup güncelleneceğini seçmesi ve bunu yıllarca düzeltmeye devam edeceğine dair söz vermesi gerekir. Bir dağıtım, bu seçimler bütünü ve sonrasında orada kalmaya devam eden insan grubudur.

Beş parçadan oluşur. Bunlardan herhangi birini değiştirdiğinizde, ikili dosyaların çoğu aynı olsa bile farklı bir dağıtıma sahip olursunuz:

• Projenin seçtiği bir sürümde, eklediği yamalar ve sürücülerle birlikte bir çekirdek.
• Bir kullanıcı alanı: C kütüphanesi, kabuk (shell), init sistemi, standart komutlar.
• Bir paket formatı ve bunu kuran araç.
• Bir sürüm politikası: nelerin değişebileceği, ne sıklıkla değişeceği ve her sürümün ne kadar süreyle sabit kalacağı.
• İnsanlar: paket bakımcıları, bir güvenlik ekibi ve bir paket bozulduğunda yanıt verecek birileri.

Çekirdek ortak parçadır, bu nedenle iki Linux dağıtımı birbirine, herhangi birinin başka bir Unix'e olduğundan çok daha yakındır. Çekirdek ve temel kullanıcı alanının tek bir proje tarafından inşa edilip birlikte yayınlandığı sunucu platformları olarak Linux ve FreeBSD karşılaştırması yaparken bunu akılda tutmakta fayda vardır. Linux'ta bu parçalar ayrı kaynaklardan gelir ve dağıtım, onları uyumlu hale getiren yapıdır.

Üç aile üzerinden Linux dağıtımlarının tarihçesi

1993 ve 1994 yıllarında başlayan üç proje zamanla birer aile haline geldi: Slackware, Debian ve Red Hat. Günümüzde bir VPS kontrol panelinde bulunan neredeyse her imaj, bu üç aileden biri veya bunların bir türevidir. Bir türev, paket formatını, dosya dizilimini ve genellikle sürüm yayınlama alışkanlıklarını devralır; bu nedenle bir Debian türevi, marka isimleri kaldırıldığında bile Debian gibi hissettirir.

Bağımsız dağıtımlar kendi başlarına bir kategoriyi hak ederler çünkü hiçbir projeden çatallanmamışlardır. Arch, Gentoo, Alpine, NixOS ve Void projelerinin her biri kendi paket yöneticisini ve kendi kurallarını yazmıştır. Bunlardan ikisi olan Arch ve Alpine, masaüstü kullanımıyla ilgisi olmayan nedenlerden dolayı sağlayıcınızın imaj listesine girmeyi başarmıştır.

1992: ailelerden önceki dağıtımlar

MCC Interim Linux, Şubat 1992'de Manchester Computing Centre'dan Owen Le Blanc tarafından bir araya getirilerek yayınlandı. Bu dağıtım, çekirdeği ve GNU (GNU's not Unix) araçlarını menü tabanlı bir yükleyici ile iki adet disket imajına sığdırıyordu. Bu çalışmanın varlık nedeni, aynı kurulumun elle yapılmasının bir tam gün sürmesiydi.

Peter MacDonald tarafından 1992'de yayınlanan SLS (Softlanding Linux System), bir adım daha ileri giderek X (X Window System) ve TCP/IP ağ desteğini ekledi. Dağıtım kelimesinin günümüzdeki anlamını kazanmasının sebebi SLS'dir. Ancak SLS hatalarla doluydu ve bakımı yavaştı; bu durum 1993 yılında iki kişinin birbirinden bağımsız olarak sorunu çözmeye karar vermesine yol açtı. Bir kişi sistemi yeniden inşa ederken, diğeri yazılı kurallar çerçevesinde sıfırdan bir başlangıç yaptı.

Slackware, 1993: hala dağıtımı yapılan en eski aile

Patrick Volkerding, 16 Temmuz 1993 tarihinde, SLS üzerine kurulu ve hataları giderilmiş Slackware 1.00 sürümünü yayınladı. Bu dağıtım günümüzde hala bakımı yapıldığı için, varlığını sürdüren en eski Linux dağıtımı olma özelliğini taşır.

Bir Slackware paketi, içerisinde bir kurulum betiği barındıran sıkıştırılmış bir tar arşividir. Bağımlılık çözümleme özelliği yoktur: yeni paketinizin ihtiyaç duyduğu kütüphanenin diskte halihazırda mevcut olup olmadığını kontrol eden bir mekanizma bulunmaz. Bu tek karar, diğer her şeyi şekillendirmiştir. Araç bağımlılıkları çözümlemeyecekse, sunulan setin yapısal olarak tutarlı olması gerekir; bu nedenle sürümler nadir ve muhafazakar bir şekilde yayınlanır. Slackware 15.0, 14.2 sürümünden altı yıl sonra, Şubat 2022'de gelmiştir.

Bu aile küçüktür. SUSE'nin 1990'ların ortalarındaki ilk sürümleri, proje YaST ve daha sonra RPM paket formatı ile kendi yolunu çizmeden önce Slackware üzerine inşa edilmişti. Bu son kısım insanların kafasını karıştırır. SUSE ve openSUSE, RPM paketlerini kullanır ancak bunlar Red Hat türevi değildir. Format yer değiştirmiştir, ancak soy ağacı değişmemiştir.

Debian, 1993: bir sosyal sözleşme ve üç aşamalı bir hat

Ian Murdock, Debian’ı 16 Ağustos 1993’te, Slackware’den üç hafta sonra ve aynı gerekçeyle duyurdu. İsim, ortağı Debra ile kendi isminin birleşimidir. Debian Manifestosu Ocak 1994’te yayımlandı ve kuralları belirledi: bu dağıtım bir şirket tarafından değil, gönüllüler tarafından açık bir şekilde sürdürülecekti.

Debian daha sonra bu şartları yazıya döktü. Debian Sosyal Sözleşmesi ve DFSG (Debian özgür yazılım yönergeleri) Temmuz 1997’de kabul edildi ve DFSG, 1998’de Açık Kaynak Tanımı’nın temelini oluşturdu. Bir dağıtımda nelerin yer alması gerektiğini belirlemek için yazılan bir belge, tüm sektör için bir lisans kategorisini tanımlar hale geldi. sources.list yapınızın bileşenlere sahip olmasının nedeni de budur: main yönergelere uygun yazılımları barındırır, contrib ve non-free uygun olmayanları tutar; Debian 12 ise kablosuz ağ kartına sahip bir dizüstü bilgisayarın sürücü arama zahmetine girmeden kurulabilmesi için non-free-firmware bileşenini eklemiştir.

Araç seti, diğer mirastır. dpkg bir paketi kurar ve bir şey eksik olduğunda dpkg: dependency problems prevent configuration of çıktısını vererek işlemi reddeder. 1999’da Debian 2.1 ile varsayılan hale gelen APT (advanced package tool), nelerin getirilmesi gerektiğini ve hangi sırayla kurulacağını çözen katmandır. Her Debian türevindeki her apt komutu, bu çalışmanın bir devamıdır.

Sürüm mekanizması üç aşamalı bir yapıya ve tek bir kurala sahiptir. Bir paket sorumlusu, kalıcı kod adı sid olan unstable sürümüne yükleme yapar. Bir betik, paket derleme mimarilerinde başarıyla derlenmişse ve yeni bir sürüm kritik hatası almamışsa, yaklaşık 5 ila 10 gün içinde paketi testing aşamasına taşır. Ardından testing sürümü dondurulur, sürüm ekibi kalan hataları temizler ve hata listesi yeterince kısaldığında stable sürümü yayınlanır. Bu işlem bir tarihe bağlı değildir. Debian stable sürümünün eski görünmesinin ve kararlı çalışmasının nedeni budur: sürüm numaraları dondurma aşamasında sabitlenir, ancak güvenlik düzeltmeleri bu sürümlere geriye dönük olarak aktarılmaya devam eder.

Yönetim yapısı da yazılı kurallara bağlıdır; seçilmiş bir proje lideri ve bağlayıcı genel kararlar mevcuttur. 2014 yılında bu mekanizma, varsayılan init sistemi olarak systemd’yi seçti ve buna karşı çıkanlar Devuan’ı çatallayarak (fork) 2017’de ilk sürümlerini yayımladılar. Debian bu değişikliği yapan ne ilk ne de son dağıtımdı; bu geçişin nedenleri ve haklı çıkan itirazlar, systemd’nin SysV init’in yerini nasıl aldığına dair anlatıda izlenebilir. Daha büyük türevleri arasında Ubuntu, Raspberry Pi OS, Proxmox VE, Kali ve Linux Mint bulunmaktadır.

Red Hat, 1994: RPM ve ardından Fedora ile RHEL ayrımı

Marc Ewing, ilk Red Hat Linux sürümünü 1994 yılının Cadılar Bayramı civarında yayınladı. Bob Young'ın şirketi 1995 yılında bu girişimi satın aldı ve ikili, yazılım yerine destek satışı yapan ilk Linux iş modelini kurdu. Red Hat, 11 Ağustos 1999 tarihinde halka arz edildi. IBM, şirketi Temmuz 2019'da yaklaşık 34 milyar dolar karşılığında satın alma işlemini tamamladı; bu nedenle, çoğu kurumsal yazılımın sertifikalı olduğu dağıtım o tarihten bu yana IBM mülkiyetindedir.

Kalıcı teknik katkı, 1995 yılında Red Hat Linux 2.0 için Erik Troan ve Marc Ewing tarafından yazılan RPM (Red Hat package manager) olmuştur. Bir RPM paketi bağımlılıklarını beyan eder ve herkesin çalıştırabileceği bir derleme tarifi olan spec dosyasından üretilir. Bu ikinci özellik, Red Hat'in kurumsal ürününün bağımsız olarak yeniden derlenmesini mümkün kılan temel unsurdur.

2003 yılındaki Red Hat Linux 9, orijinal serinin sonuncusuydu. Şirket bu seriyi ikiye böldü: Hızlı topluluk sürümü olarak Kasım 2003'te Fedora Core 1 ve 2002'de Advanced Server 2.1 olarak başlayan, yavaş ve ücretli olan RHEL (Red Hat Enterprise Linux). Bunun nedeni açıktır. Tek bir ürün, hem yeni sürümlerin denendiği bir alan hem de bir bankanın on yıl boyunca dokunmadan çalıştırdığı bir platform olamaz. İki parça birbirine bağlıdır: Bir RHEL ana sürümü, bir Fedora sürümünden dallanır, kararlı hale getirilir ve ardından dondurulur. Paket aracı da aynı takvimi izlemiş; 2000'lerde yum sürümünden 2015'te Fedora varsayılanı olan dnf sürümüne geçmiş ve her ikisinin temelinde rpm yer almıştır.

CentOS neden ücretsiz bir RHEL yeniden derlemesi olmaktan çıktı

CentOS, 2004 yılında basit bir görevle başladı: Red Hat tarafından yayınlanan kaynak paketlerini al, ticari markaları kaldır, yeniden derle ve sonucu ücretsiz dağıt. On yıl boyunca varsayılan ücretsiz sunucu dağıtımı haline geldi ve Red Hat, 2014 yılında projeyi bünyesine kattı.

8 Aralık 2020 tarihinde Red Hat, CentOS Linux 8'in ömrünün, ilan edilen tarihten sekiz yıl önce, 31 Aralık 2021'de sona ereceğini ve ismin CentOS Stream olarak devam edeceğini duyurdu. Stream bir yeniden derleme değildir. RHEL ara sürümlerinin türetildiği daldır; bu nedenle RHEL'in gerisinde değil, ilerisinde çalışır. Yıllarca tutmayı planladığınız bir makine için "ileride" olmak yanlış bir yöndür, çünkü değişiklikleri Red Hat'in ücretli müşterilerinden önce alırsınız.

2021 yılında iki yeniden derleme ortaya çıktı. Rocky Linux, CentOS'un kurucu ortaklarından Gregory Kurtzer tarafından başlatıldı. AlmaLinux ise CloudLinux tarafından finanse edildi. Haziran 2023'te Red Hat, RHEL kaynaklarını CentOS Stream ve kendi müşteri portalı dışında hiçbir yerde yayınlamayı durdurdu. Rocky, birebir yeniden derlemeleri hedeflemeye devam etti. AlmaLinux ise hedefini ABI (uygulama ikili arayüzü) uyumluluğuna çevirdi; bu, RHEL için derlenen yazılımların çalışacağı ancak hata listesinin satırı satırına aynı olacağının garanti edilmediği anlamına gelir. Oracle, SUSE ve CIQ, aynı yılın ilerleyen dönemlerinde paylaşılan kaynakları yayınlamak için OpenELA'yı kurdu. 2003'teki ayrılmadan 2023'teki kaynak değişikliğine ve her bir yeniden derlemenin bugün ne vaat ettiğine kadar tüm bu süreç, Red Hat, CentOS, Rocky ve AlmaLinux hakkındaki daha kapsamlı anlatımda izlenebilir.

Bir sağlayıcının imaj listesinde hala CentOS yazıyorsa, üzerine kurulum yapmadan önce bunun hangisini ifade ettiğini öğrenin.

cat /etc/os-release

NAME="CentOS Stream", RHEL'in öncüsü olan bir sürekli geliştirme dalıdır. NAME="AlmaLinux" veya NAME="Rocky Linux", on yıllık bir destek penceresiyle onu takip eden bir yeniden derlemedir.

Ubuntu 20.04: Takvim tabanlı bir Debian unstable anlık görüntüsü

Ubuntu 4.10, 20 Ekim 2004 tarihinde Mark Shuttleworth tarafından finanse edilerek piyasaya sürüldü. Debian ile olan ilişkisi duygusal olmaktan ziyade mekaniktir. Her döngü, Debian unstable içindeki paketlerin yeni Ubuntu sürümüne aktarılmasıyla başlar. Bu aktarımlar, döngünün orta kısımlarında gerçekleşen Debian Import Freeze aşamasına kadar devam eder; bu noktadan sonra Ubuntu kendi değişikliklerini uygular. Birçok Ubuntu paketi, Debian paketinin üzerine eklenen bir farktan (delta) oluşur ve bu durum değişiklik günlüğünde (changelog) belirtilir.

İşin diğer yarısı ise takvimdir. Debian hazır olduğunda yayınlanır. Ubuntu ise Nisan ve Ekim aylarında yayınlanır ve sürüm numarası tarihi temsil eder: 24.04, Nisan 2024'te çıkmıştır. Her iki Nisan sürümünden biri LTS (uzun süreli destek) sürümüdür; bir sağlayıcı Ubuntu'yu herhangi bir niteleyici olmadan listelediğinde kastettiği budur. Bir sunucuda hangisinin kullanılması gerektiği, Ubuntu LTS ve ara sürümler arasında seçim yapma konusunun tamamını oluşturur ve bir LTS sürümünden diğerine geçişin kendine has bir prosedürü vardır; bu da 24.04'ten 26.04'e yükseltme bölümünde ele alınmıştır.

Bir detay, sunucu yöneticilerini her yıl yanıltır. Ubuntu arşivi bileşenlere ayrılmıştır. main, Canonical tarafından tam destek süresi boyunca korunur. universe ise topluluk tarafından korunur ve güvenlik kapsamı farklı bir taahhüde tabidir. apt install, bu fark hakkında herhangi bir bilgi sunmaz. Bunu gösteren tek bir komut vardır:

apt-cache policy nginx

/main ile biten bir depo satırı, o paketin sorumluluğunun Canonical güvenlik ekibinde olduğu anlamına gelir. /universe ile biten bir satır ise sorumluluğun toplulukta olduğunu gösterir. İnternete açık olan her şey için bunu kontrol edin.

Arch, 2002: rolling release modeli ve kısmi güncellemenin maliyeti

Judd Vinet, 11 Mart 2002 tarihinde Arch 0.1 sürümünü, kendi yazdığı bir paket yöneticisi olan pacman ve saf kabuk betiklerinden oluşan derleme tarifleri ile yayınladı. Arch, sürüm tabanlı bir dağıtım değildir. Kurulum medyaları, aynı rolling (sürekli güncellenen) depoların tarihli anlık görüntüleridir; bu nedenle 2019 yılında kurulan ve her hafta güncellenen bir makine, bugün kurulan bir makine ile aynı Arch sürümünü çalıştırır. AUR (Arch user repository), kullanıcılar tarafından sağlanan derleme tariflerini barındırır. Bunlar denetlenmiş paketler değil, sadece tariflerdir; bu yüzden çalıştırmadan önce bir PKGBUILD dosyasını okumak işin bir parçasıdır.

Rolling modelinin tek bir başarısızlık modu vardır ve bu her seferinde kullanıcı kaynaklıdır. pacman -Sy foo ile tek bir paket kurmak, paket veritabanını yeniler ve ardından diskteki kütüphanelerden daha yeni kütüphanelere bağlı olan yeni bir ikili dosyayı yükler. Bu durumda programlar şu şekilde hata verir:

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

Desteklenen işlem, her şeyi bir bütün olarak güncelleyen pacman -Syu komutudur. Proje ayrıca, belirli güncellemelerden önce manuel müdahale gerektiğini belirten haber girişleri yayınlar; bu duyuruları okumadan güncelleme yapmak, makinenin açılmamasına neden olabilir.

Bu durum, Arch'ı göz ardı etmeyi planladığınız bir sunucu için kötü bir seçenek haline getirir. Haftalık güncellenen bir makine sorunsuzdur. Bir yıl sonra tek seferde güncellenen bir makine ise, atlanan tüm müdahaleleri tek bir çalıştırmada karşınıza çıkarır.

Alpine: konteynerler sayesinde ün kazanan küçük bir dağıtım

Alpine, 2005 civarında Linux Router Project'ten türetilen LEAF (Linux embedded appliance framework) projesinin bir çatalı olarak ortaya çıktı ve Natanael Copa tarafından masaüstü sistemlerden ziyade cihazlar (appliances) için geliştirildi. Alpine, standart kullanıcı alanı araçlarının çoğunu değiştirir: GNU C kütüphanesi yerine musl, GNU temel araçları yerine BusyBox, systemd yerine OpenRC ve paket yöneticisi olarak apk kullanılır. 2014 yılındaki Alpine 3.0 sürümü, musl kütüphanesine geçişin yapıldığı sürümdür.

Konteynerler bu dağıtımı popüler hale getirdi. Bir Alpine temel katmanı, Debian veya Ubuntu temel imajlarının boyutunun çok küçük bir kısmını kaplar; bu nedenle 2016'dan itibaren yaygın bir temel imaj haline geldi ve Alpine'i hiçbir zaman doğrudan kurmamış olan pek çok kişi, onu her gün çalıştırır oldu.

Bunun bedeli ise musl'un glibc ile aynı olmamasıdır; bu fark, birbiriyle alakasız görünen hatalar şeklinde ortaya çıkar. glibc ile bağlantılı (linked) bir ikili dosya, Alpine üzerinde çalıştırıldığında, kullanıcıyı aslında orada olan bir dosyayı aramaya yönlendiren bir hata mesajıyla başarısız olur:

sh: ./myapp: not found

Program mevcuttur. Ancak glibc'nin yükleyicisi eksik olduğu için ELF yorumlayıcısı bulunamaz. Python ise bir diğer düzenli sürpriz kaynağıdır: manylinux için önceden derlenmiş tekerlekler (wheels) musl üzerinde kurulamaz; bu yüzden pip kaynak koddan derlemeye geri döner ve sistemde derleyici bulunmadığında işlem durur. 2021'den itibaren gelen musllinux tekerlek standardı, bu tekerlekleri yayınlayan projeler için sorunu çözmüştür, ancak diğerleri için durum aynıdır.

Bir VPS üzerinde ana işletim sistemi olarak Alpine, az yer kaplar ve hızlı güncellenir; ancak sizi çoğu dokümantasyonun varsaydığı yoldan uzaklaştırır. systemctl enable komutunu çalıştırmanızı söyleyen her rehberin, rc-update add komutuna çevrilmesi gerekir.

Değişmez nesil: atomik güncellemeler ve imaj tabanlı sunucular

En yeni dal, paket listesi yerine güncelleme modelini değiştirmektedir. ostree tabanlı bir sistem /usr dizinini salt okunur tutar. Bir güncelleme, indirilen, hazırlanan ve bir sonraki yeniden başlatmada geçiş yapılan tamamen yeni bir dosya sistemi ağacıdır. Önceki ağaç bir önyükleme girdisi olarak kalır; bu sayede hatalı bir güncelleme, eski ağaca yeniden başlatma yapılarak geri alınabilir.

Fedora Silverblue bunu 2018 yılında masaüstüne, Fedora CoreOS ise Red Hat'in 2018'de CoreOS'i satın almasının ardından 2019 yılında sunuculara getirdi. Flatcar Container Linux, 2020 yılında kullanımdan kaldırılan orijinal Container Linux'un devamı niteliğindedir. openSUSE MicroOS, btrfs snapshot'ları ve transactional-update aracılığıyla aynı noktaya ulaşır. 2024 yılında Red Hat, bootc üzerine inşa edilen ve işletim sisteminin bir container imajı olarak sunulduğu, makinenin ise yeni bir etikete yönlendirilerek güncellendiği imaj tabanlı bir modu RHEL'e ekledi. Talos Linux ise en uç noktaya giderek shell ve SSH erişimini tamamen kaldırır: makine bir API aracılığıyla yapılandırılır, bu nedenle giriş yapılacak bir ortam bulunmaz. İlk sürümü 2007'de yayınlanan NixOS ise farklı bir yönden gelir. Tüm sistem tek bir bildirimsel yapılandırmadan oluşturulur ve önceki nesiller önyüklenebilir durumda kalır.

Servis sağlayıcınız muhtemelen bunların hiçbirini tek tıkla kurulabilir bir imaj olarak sunmaz; çünkü bu sistemlerin bir yönetici tarafından SSH üzerinden dosya düzenlenerek değil, ilk önyükleme sırasında Ignition veya cloud-init ile yapılandırılması beklenir. Bu sistemler, aynı anda birden fazla Linux sunucusu yönettiğiniz ve her birinin diğerleriyle kanıtlanabilir şekilde aynı olması gereken durumlarda, çok sayıda özdeş makine üzerinde verim sağlar.

FAQ

Bir sürüm ne kadar süre desteklenir?

Sürüm politikası, bir dağıtımda en uzun süre bağlı kaldığınız kısımdır ve yıl cinsinden ifade edilir. Aşağıda 5 güncel sunucu sürümü için destek süreleri yer almaktadır.

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine, her 3.x dalını 2 yıl boyunca destekler; bu nedenle sık sık yeniden oluşturduğunuz container imajları için, kendi haline bıraktığınız bir ana makineden daha uygundur. Debian güvenlik ekibi, kararlı bir sürümü yaklaşık 3 yıl boyunca destekler; ardından LTS ekibi, yaygın mimariler için bu süreyi toplamda yaklaşık 5 yıla çıkarır. Bir Ubuntu LTS, main içindeki paketler için 5 yıl destek sunar; Ubuntu Pro aboneliği ise bunu 10 yıla kadar uzatır ve az sayıda makinede kişisel kullanım için ücretsizdir. RHEL 10, 10 yıllık destek süresi açıklar; ücretli genişletilmiş yaşam döngüsü desteği eklentisi ise bu süreyi 13 yıla çıkarır. AlmaLinux 10, herhangi bir abonelik gerektirmeden RHEL'in 10 yıllık süresini karşılar; bu dağıtımların var olma nedeni de tam olarak budur.

Arch bu listede yer almaz, çünkü rolling (sürekli güncellenen) bir dağıtımın desteklenecek bir sürümü yoktur. Arch için önemli olan sayı, bir makineyi ne kadar süre dokunmadan bırakabileceğinizdir ve bu süre hafta cinsinden ölçülür.

VPS imaj listeniz neden bu şekilde görünür

Bir sağlayıcı, müşterilerin isimleriyle talep ettiği ve hipervizörü üzerinde katılımsız olarak kurulan imajları sunar. Bu nedenle neredeyse her liste bir Ubuntu LTS ve bir Debian stable sürümüyle başlar, yazılımı RHEL üzerinde sertifikalı olanlar için AlmaLinux veya Rocky ekler ve Alpine, Arch ve Fedora gibi seçenekleri listenin alt kısımlarında tutar. VPS'in ne olduğunu ve imajın diske nasıl ulaştığını öğrendiğinizde, bu düzen net bir şekilde anlaşılır: Sağlayıcı, katılımsız kurulumda sorun çıkarmayan ve ortalama bir müşterinin sunucuyu tutma süresinden daha uzun süre desteklenen işletim sistemlerini seçmektedir.

Bu seçim sizi sadece bir paket yöneticisinden daha fazlasına bağlar. Üç yıl sonra çalıştıracağınız yükseltme yöntemini belirler ve bu yöntemler ailelere göre tamamen farklılık gösterir. Debian ve Ubuntu, yerinde (in-place) ana sürüm yükseltmelerini destekler. Red Hat ailesi bunları leapp aracılığıyla yürütür. Arch'ın bir sürümü olmadığı için yükseltmesi de yoktur. Alpine'in yükseltme yöntemi ise /etc/apk/repositories dosyasını düzenleyip apk upgrade --available komutunu çalıştırmaktan ibarettir. Bu seçim ayrıca üçüncü taraf bir depo eklemeden hangi yazılımları kurabileceğinizi, çalıştırdığınız bir yazılım için CVE (ortak güvenlik açıkları ve maruziyetler) kaydı yayınlandığında yamayı kimin sunacağını ve gelecekteki yazılımlarınızın hangi init sistemini ve C kütüphanesini varsayacağını belirler.

Göz ardı edilmesi kolay bir etki daha vardır. İnternette yazılan cevapların çoğu Debian ailesi veya Red Hat ailesi yolunu varsayar; bu nedenle bu ikisinin dışında bir seçim yapmak, makinenin ömrü boyunca talimatları çevirmek anlamına gelir. Yayın politikası, sunucuya ne sıklıkla müdahale etmek istediğinizle örtüşen aileyi seçin ve ona sadık kalın. Üstteki paketleri değiştirmek kolaydır. Altındaki dağıtımı değiştirmek ise sunucuyu baştan kurmak anlamına gelir.

FAQ

Sunucum hangi Linux dağıtım ailesine ait?

cat /etc/os-release komutunu çalıştırın. ID alanı dağıtımın adını, ID_LIKE alanı ise ailesini belirtir; bu nedenle bir Ubuntu makinesi ID_LIKE=debian, bir AlmaLinux makinesi ise ID_LIKE="rhel centos fedora" çıktısını verir. Paket yöneticisi bir diğer ayırt edici özelliktir. apt ve dpkg Debian ailesini, dnf ve rpm Red Hat ailesini, apk Alpine'i, pacman ise Arch'ı ifade eder.

CentOS hala RHEL'in ücretsiz bir sürümü mü?

Hayır. Bu isimle yayınlanan son yeniden yapılandırma olan CentOS Linux 8, 31 Aralık 2021 tarihinde sona ermiş; CentOS Linux 7 ise 30 Haziran 2024 tarihinde ömrünü tamamlamıştır. Güncel proje olan CentOS Stream, RHEL ara sürümlerinin oluşturulduğu daldır; bu nedenle değişiklikler RHEL'den sonra değil, önce bu sürüme gelir. Eski rolü devralan ücretsiz yeniden yapılandırmalar, her ikisi de on yıllık destek süresine sahip olan AlmaLinux ve Rocky Linux'tur.

Debian stable neden bu kadar eski sürüm numaraları kullanıyor?

Çünkü düzeltmeler gelmeye devam ederken sürüm numarası sabitlenir. Debian, daha yeni bir upstream sürümünü içe aktarmak yerine güvenlik yamalarını yayınladığı sürüme geri taşır (backport); bu nedenle 2.4.57-2+deb13u1 görünen bir paket, geçen hafta yayınlanmış bir düzeltmeyi içeriyor olabilir. Upstream sürümünden sonra gelen sonek Debian revizyonudur ve apt changelog <package> bu revizyona nelerin dahil edildiğini listeler. Bir Debian sunucusunun güvenliğini sürüm numaralarına bakarak değerlendirmek her zaman hatalı sonuç verir.

VPS üzerinde Arch gibi rolling release bir dağıtım kullanmalı mıyım?

Yalnızca düzenli bir takvimle güncelleyecekseniz kullanmalısınız. Rolling dağıtımlar, her makinenin güncel paket setine uyum sağlayacağını varsayar; bu nedenle pacman -Sy foo ile tek bir paketi güncellemek, uyumsuz kütüphanelere ve cannot open shared object file gibi hatalara yol açar. pacman -Syu komutunu düzenli olarak çalıştırın, her işlemden önce proje haber sayfasını okuyun; sistem bu şekilde kararlı kalacaktır. Güncellemeleri bir yıl boyunca ihmal ederseniz, yapacağınız ilk yükseltme riskli hale gelir.

Immutable veya atomic bir dağıtım aslında neleri değiştirir?

Güncellemelerin ne zaman uygulanacağını ve bunları nasıl geri alacağınızı değiştirir. /usr salt okunur (read-only) olarak bağlanır, güncelleme tamamen yeni bir ağaç yapısı olarak hazırlanır ve geçiş yeniden başlatma sırasında gerçekleşir; önceki yapı ise geri dönüş (rollback) için bir önyükleme girdisi olarak saklanır. Yarım kalmış bir durum olmaksızın, tamamen güncellenmiş veya hiç güncellenmemiş bir makineye sahip olursunuz. Dosyaları yerinde düzenleyerek yazılım kurma yönteminden vazgeçersiniz; bu nedenle uygulamalar konteynerlere veya katmanlı paketlere taşınır.