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

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

Linux dağıtımlarının geçmişi bir boşlukla başlar: Linux çekirdeği tek başına bir kullanıcının işine yarayacak hiçbir şey yapmaz. Önyükleme yapar ve donanımı bulur. Sonra durur. Birinin kullanıcı alanını (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 elinizde farklı bir dağıtım olur:

• 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 düzeltileceği.
• İnsanlar: paket bakımcıları, bir güvenlik ekibi ve bir paket bozulduğunda yanıt verecek birileri.

Çekirdek paylaşılan kısımdır, bu nedenle iki Linux dağıtımı birbirine, herhangi birinin başka bir Unix sistemine olduğundan çok daha yakındır. Çekirdek ve temel kullanıcı alanının tek bir proje tarafından oluşturulup 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ı ayrı kaynaklardan (upstream) 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 yer alan 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 alışkanlıklarını devralır; bu nedenle bir Debian türevi, markalama kaldırıldığında bile Debian gibi hissettirir.

Bağımsız dağıtımlar kendi kategorilerini hak eder, çünkü hiçbir projeden çatallanmamışlardır. Arch, Gentoo, Alpine, NixOS ve Void; her biri kendi paket yöneticisini ve kendi kurallarını oluşturmuştur. 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 derlenerek kullanıma sunuldu. Bu dağıtım, çekirdeği ve GNU (GNU's not Unix) araçlarını menü tabanlı bir yükleyici ile birlikte iki adet disket imajına sığdırıyordu. Bu çalışmanın ortaya çıkış nedeni, aynı işlemin manuel olarak 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 (distribution) kelimesinin günümüzdeki anlamını kazanmasının temel sebebi SLS'dir. Ancak SLS hatalarla doluydu ve bakımı yavaş ilerliyordu; bu durum 1993 yılında iki kişinin birbirinden bağımsız olarak sorunu çözmeye karar vermesine yol açtı. Birisi 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ı süren en eski aile

Patrick Volkerding, 16 Temmuz 1993 tarihinde, SLS üzerine inşa edilen 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 mekanizması yoktur: yeni paketinizin ihtiyaç duyduğu kütüphanenin diskte halihazırda bulunup bulunmadığını denetleyen bir sistem bulunmaz. Bu tek karar, diğer her şeyi şekillendirmiştir. Araç bağımlılıkları çözümlemiyorsa, sunulan paket kümesinin yapısal olarak tutarlı olması gerekir; bu nedenle sürümler nadiren çıkar ve muhafazakar bir yapıda kalır. Slackware 15.0, 14.2 sürümünden altı yıl sonra, Şubat 2022'de yayınlanmıştır.

Bu aile küçüktür. SUSE'nin 1990'ların ortası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ırmaktadı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, Slackware'den üç hafta sonra ve aynı gerekçeyle, 16 Ağustos 1993 tarihinde Debian'ı duyurdu. Projenin ismi, ortağı Debra ile kendi isminin birleşimidir. Ocak 1994'te yayımlanan Debian Manifestosu, projenin şartlarını 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; DFSG, 1998 yılında Açık Kaynak Tanımı'nın temelini oluşturdu. Tek 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 farklı bileşenlere sahip olmasının nedeni de budur: main yönergelere uygun yazılımları barındırırken, contrib ve non-free uygun olmayanları içerir; Debian 12 ise non-free-firmware bileşenini ekleyerek kablosuz ağ kartına sahip bir dizüstü bilgisayarın, ek sürücü arayışına girmeden kurulum yapabilmesini sağladı.

Araç seti, projenin bir diğer mirasıdır. dpkg tek bir paketi kurar ve bir eksiklik olduğunda dpkg: dependency problems prevent configuration of çıktısını vererek işlemi reddeder. 1999 yılında 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. Debian tabanlı her sistemdeki her apt komutu, bu çalışmanın bir türevidir.

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 derlendiyse ve yeni bir sürüm kritik hatası almadıysa, paketi yaklaşık 5 ila 10 gün içinde 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ımlanır. Bu süreç bir tarihe bağlı değildir. Debian stable sürümünün eski görünmesinin ancak kararlı çalışmasının nedeni budur: sürüm numaraları dondurma aşamasında sabitlenir, ancak güvenlik yamaları bu sürümlere geriye dönük olarak aktarılmaya devam eder.

Yönetim yapısı da yazılı kurallara bağlanmıştı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. Bu karara katılmayanlar Devuan'ı çatalladı (fork) ve bu proje ilk sürümünü 2017'de yayımladı. Debian'ın daha büyük türevleri arasında Ubuntu, Raspberry Pi OS, Proxmox VE, Kali ve Linux Mint yer almaktadı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 projeyi satın aldı ve ikili, yazılım yerine destek satışı yapan ilk Linux işletmesini 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 kurumsal yazılımların çoğunun sertifikalandırıldığı 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ü: Kasım 2003’te hızlı topluluk sürümü olarak Fedora Core 1 ve 2002’de Advanced Server 2.1 olarak başlayan, yavaş ve ücretli sürüm 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ıracağı bir platform olamaz. Bu iki yarı 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çilmiş ve her ikisinin altında rpm kullanılmış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 olarak 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 desteğinin planlanan tarihten sekiz yıl önce, 31 Aralık 2021 tarihinde 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 arkasında değil, önünde ilerler. Yıllarca kullanmayı planladığınız bir makine için "önde 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ınlamamaya başladı. Rocky Linux, birebir yeniden derleme hedefini korudu. AlmaLinux ise hedefini ABI (uygulama ikili arayüzü) uyumluluğu olarak değiştirdi; 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.

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 üzerinde 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ülmüştür. Debian ile olan ilişkisi duygusal olmaktan ziyade mekanik bir yapıdadır. Her geliştirme döngüsü, Debian unstable içindeki paketlerin yeni Ubuntu sürümüne aktarılmasıyla başlar. Bu aktarım süreci, döngünün ortasındaki Debian Import Freeze aşamasına kadar devam eder; bu noktadan sonra Ubuntu kendi değişikliklerini uygulamaya başlar. Birçok Ubuntu paketi, Debian paketinin üzerine eklenen bir farktan (delta) oluşur ve bu durum changelog dosyasında 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 sürümü 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 sürüm 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; bir LTS sürümünden diğerine geçişin kendine has bir prosedürü vardır ve bu, 24.04'ten 26.04'e yükseltme bölümünde ele alınmıştır.

Sunucu yöneticilerini her yıl şaşırtan bir detay mevcuttur. Ubuntu arşivi bileşenlere ayrılmıştır. main, tam destek süresi boyunca Canonical tarafından 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. Tek bir komut bu farkı gösterir:

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 tüm paketler için bu kontrolü yapın.

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

Judd Vinet, 11 Mart 2002 tarihinde kendi yazdığı bir paket yöneticisi olan pacman ve saf kabuk betiklerinden oluşan derleme tarifleri ile Arch 0.1 sürümünü yayınladı. Arch, sürüm numaralı yayınlar kullanmaz. 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 gözden geçirilmiş paketler değil, sadece tariflerdir; bu yüzden bir PKGBUILD dosyasını çalıştırmadan önce okumak işin bir parçasıdır.

Rolling modelinin tek bir hata modu vardır ve bu her seferinde kullanıcı tarafından tetiklenir. 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ı kurar. 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 kayıtları yayınlar; bu kayıtları okumadan güncelleme yapmak, makinenin açılmamasına neden olabilir.

Bu durum, Arch'ı ilgilenmeyeceğiniz 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 ile ü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ü sistemler yerine cihazlar (appliances) için geliştirildi. 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 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, 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ı verir:

sh: ./myapp: not found

Program mevcuttur. Ancak ELF yorumlayıcısı mevcut değildir, çünkü glibc'nin yükleyicisi (loader) bulunmamaktadır. Python ise bir diğer düzenli sürpriz kaynağıdır: manylinux için önceden oluşturulmuş paketler (wheels) musl üzerinde kurulamaz; bu yüzden pip kaynak koddan derlemeye geri döner ve sistemde derleyici yüklü olmadığında işlem durur. 2021 yılındaki musllinux wheel standardı, bu paketleri 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, küçük boyutlu kurulumu ve hızlı güncellemeleriyle öne çıkar, ancak sizi çoğu dokümantasyonun varsaydığı yoldan uzaklaştırır. systemctl enable komutunu çalıştırmanızı söyleyen her kılavuzun, 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. /usr tabanlı bir sistem, dosya sistemini salt okunur tutar. Güncelleme, tamamen yeni bir dosya sistemi ağacıdır; indirilir, hazırlanır ve bir sonraki yeniden başlatmada bu ağaca geçiş yapılı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 bu yaklaşımı 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 getirmiştir. Flatcar Container Linux, 2020 yılında kullanımdan kaldırılan orijinal Container Linux'un devamı niteliğindedir. openSUSE MicroOS, btrfs anlık görüntüleri 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 eklemiştir. Talos Linux ise en ileri giderek kabuğu ve SSH erişimini tamamen kaldırmıştır: makine bir API üzerinden yapılandırılır, bu nedenle giriş yapılabilecek 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.

Sunucu 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 açılışta Ignition veya cloud-init ile yapılandırılması beklenir. Bu sistemler, birden fazla Linux sunucusunu aynı anda yönettiğiniz ve her birinin diğerleriyle kanıtlanabilir şekilde aynı olması gereken durumlarda, çok sayıda özdeş makine üzerinde verimlilik sağlar.

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 yayınlanır. 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 bir container imajı 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 sürümü, main içindeki paketler için size 5 yıl sunar; Ubuntu Pro aboneliği ise bu süreyi 10 yıla 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 ile aynı olan 10 yıllık süreyi sunar; bu dağıtımların var olma sebebi 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üyor

Bir sağlayıcı, müşterilerin talep ettiği ve hipervizörü üzerinde katılımsız olarak kurulan imajları sunar. Bu nedenle neredeyse her liste bir Ubuntu LTS ve Debian stable ile 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 bir paket yöneticisinden çok daha fazlasına bağlar. Üç yıl sonra gerçekleştireceğiniz yükseltme yöntemini belirler ve bu yöntemler ailelere göre tamamen farklılık gösterir. Debian ve Ubuntu, yerinde ana sürüm yükseltmelerini destekler. Red Hat ailesi bunları leapp aracılığıyla yürütür. Arch'ın sürümü olmadığı için yükseltmesi de yoktur. Alpine'de ise işlem /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.

Küçümsenmemesi gereken 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ı çevirmeniz gerektiği anlamına gelir. Yayın politikası sunucuya müdahale etme sıklığınızla örtüşen aileyi seçin ve ona sadık kalın. Üzerindeki paketleri değiştirmek kolaydır. Altındaki dağıtımı değiştirmek ise sunucuyu yeniden inşa etmek 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; örneğin bir Ubuntu makinesi ID_LIKE=debian, bir AlmaLinux makinesi ise ID_LIKE="rhel centos fedora" çıktısını verir. Paket yöneticisi de 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'in ömrü 31 Aralık 2021'de, CentOS Linux 7'nin ömrü ise 30 Haziran 2024'te sona erdi. Mevcut proje olan CentOS Stream, RHEL ara sürümlerinin temel alındığı daldır; bu nedenle değişiklikler RHEL'den sonra değil, önce bu dala 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ı dondurulur. 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 olarak görünen bir paket, geçen hafta yayınlanmış bir düzeltmeyi içerebilir. 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 güncelleme takviminiz varsa 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 ve her güncellemeden önce proje haber sayfasını okuyun; bu şekilde sistem kararlı kalacaktır. Güncellemeleri bir yıl boyunca ihmal ederseniz, yapacağınız ilk yükseltme riskli hale gelir.

Immutable veya atomic dağıtımlar tam olarak neyi değiştirir?

Güncellemelerin uygulanma zamanını ve geri alma yöntemini değiştirirler. /usr salt okunur 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üş için bir önyükleme girdisi olarak saklanır. Böylece sistem ya tamamen güncellenmiş ya da hiç güncellenmemiş olur; yarıda kalmış bir durum oluşmaz. Dosyaları yerinde düzenleyerek yazılım kurma yönteminden vazgeçersiniz, bu nedenle uygulamalar container yapılarına veya katmanlı paketlere taşınır.