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

Linux dağıtımının gerçekte ne olduğu

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

Beş parçadan oluşur. Bunları farklı şekilde seçen projeler, ikili dosyaların çoğu aynı olsa bile farklı dağıtımlardır:

• Projenin seçtiği bir sürümde, eklediği yamalar ve sürücülerle birlikte bir çekirdek. Bir sürüm birden fazla çekirdek sunabilir: Ubuntu 24.04 LTS, sunucularda varsayılan olarak GA (genel erişilebilirlik) çekirdeğini kurar ve daha yeni olan HWE (donanım etkinleştirme) çekirdeğini bir seçenek olarak sunar.
• 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üre destekleneceğ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. Çekirdeğin 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ı yapılırken bu durum akılda tutulmalıdır. Linux'ta bu parçalar ayrı kaynaklardan gelir ve dağıtım, bunların uyumlu çalışmasını sağlayan 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 dağıtım hattı

Ian Murdock, Debian’ı 16 Ağustos 1993 tarihinde, Slackware’den bir ay sonra ve aynı gerekçeyle duyurdu. Projenin ismi, ortağı Debra ile kendi isminin birleşimidir. Ocak 1994’te yayımlanan Debian Manifestosu, kuralları belirledi: Bu dağıtım, bir şirket tarafından değil, gönüllüler tarafından açık bir şekilde yönetilecekti.

Debian daha sonra bu kuralları yazılı hale getirdi. 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 alacağını belirlemek için yazılan bir belge, tüm endüstri 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 uyan ve main dışında hiçbir şeye ihtiyaç duymayan yazılımları barındırır; contrib, yönergelere uyan ancak derlenmesi veya çalışması için main dışında bir şeye ihtiyaç duyan yazılımları içerir; non-free yönergelere uymayanları tutar ve Debian 12, kablosuz ağ kartına sahip bir dizüstü bilgisayarın sürücü arayışına girmeden kurulum yapabilmesi için non-free-firmware bileşenini ekledi.

Araç seti, diğer mirastır. dpkg tek bir paket 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ı hesaplayan katmandır. Her Debian türevindeki her apt komutu, bu çalışmanın bir devamıdır.

Sürüm makinesi üç aşamalı bir yapıya ve tek bir kurala sahiptir. Bir paket sorumlusu, kalıcı kod adı sid olan unstable deposuna yükleme yapar. Bir betik, paketi yüklemenin aciliyetine bağlı olarak 2, 5 veya 10 gün sonra testing deposuna taşır; ancak bunun için paketin derlenmiş olması, daha önce desteklediği tüm mimarilerde güncel olması, testing sürümünde bulunmayan kritik bir hata içermemesi ve testing deposundaki mevcut paketleri bozmadan kurulabilmesi gerekir. Ardından testing aşaması 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 ve kararlı çalışmasının nedeni budur: Sürüm numaraları dondurma aşamasında sabitlenir, güvenlik düzeltmeleri ise bu sürümlere geriye dönük olarak (backport) uygulanır. Genellikle böyledir; çünkü güvenlik ekibi bazen, Haziran 2026’da Tomcat 11 için yapıldığı gibi, daha yeni bir upstream sürümünü doğrudan yayımlamayı tercih edebilir.

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. Bu karara katılmayanlar Devuan’ı çatalladı (fork) ve ilk sürümünü 2017’de yayımladı. 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ımda izlenebilir. Dağıtımın daha büyük türevleri arasında Ubuntu, Raspberry Pi OS, Proxmox VE, Kali ve Linux Mint yer alı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 almak, ticari markaları kaldırmak, bunları yeniden derlemek ve sonucu ücretsiz olarak dağıtmak. 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 kullanmayı 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, halka açık RHEL kaynaklarını CentOS Stream, müşteri portalı ve UBI (Universal Base Image) container'ları ile birlikte yayınladığı kaynak imajları ile sınırladı. Rocky, birebir yeniden derleme hedefini sürdürdü. AlmaLinux ise hedefini ABI (application binary interface) 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ılıştan 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", onu takip eden ve on yıllık bir destek penceresi sunan 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 Gentoo'nun bir çatalı olarak ortaya çıkmıştır. Kendisi de Linux Router Project'ten türeyen LEAF (Linux embedded appliance framework) tarafından şekillendirilmiş olup, Natanael Copa tarafından masaüstü sistemler yerine cihazlar (appliances) için geliştirilmiştir. 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ş yapılan sürümdür.

Konteynerler onu popüler hale getirmiştir. Bir Alpine temel katmanı, Debian veya Ubuntu temel katmanının çok küçük bir kısmını oluşturur; bu nedenle 2016'dan itibaren yaygın bir temel imaj haline gelmiş ve Alpine'i hiç kurmamış pek çok kişi onu her gün çalıştırmaya başlamıştır.

Bunun bedeli, musl'un glibc ile aynı olmamasıdır ve bu fark, alakasız görünen hatalar şeklinde ortaya çıkar. glibc ile bağlantılı bir ikili dosya, Alpine üzerinde, kullanıcıları zaten mevcut olan bir dosyayı aramaya yönlendiren bir mesajla başarısız olur:

sh: ./myapp: not found

Program mevcuttur. Ancak ELF yorumlayıcısı mevcut değildir, çünkü glibc'nin yükleyicisi eksiktir. Python bir diğer düzenli sürprizdir: manylinux için önceden oluşturulmuş paketler (wheels) musl üzerinde kurulamaz; bu nedenle pip kaynak koddan derlemeye geri döner ve sistemde derleyici bulunmadığında durur. 2021'den itibaren gelen 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 bir kurulum alanına sahiptir 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ımın en uzun süre etkileşimde kaldığınız parçasıdı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": 14
  }
]

Alpine, her 3.x dalının main deposunu 2 yıl boyunca destekler; community deposu ise yalnızca bir sonraki kararlı sürüme kadar desteklenir. Bu nedenle, sık sık yeniden oluşturduğunuz container imajları için, kendi haline bıraktığınız bir ana makineye kıyasla daha uygundur. Debian güvenlik ekibi, kararlı bir sürümü yaklaşık 3 yıl boyunca destekler; ardından LTS ekibi, seçili mimariler için bu süreyi toplamda yaklaşık 5 yıla çıkarır. Ubuntu LTS, main içindeki paketler için 5 yıllık destek sunar; Ubuntu Pro aboneliği ise bu süreyi, az sayıda makinede kişisel kullanım için ücretsiz olacak şekilde 10 yıla uzatır. Ubuntu Pro için ücretli Legacy eklentisi, bu süreyi 15 yıla kadar çıkarır. RHEL 10, 10 yıllık destek süresi açıklar; ücretli Extended Life Cycle Premium eklentisi, son ara sürüm için bu süreyi 14 yıla uzatır ve yenilenebilir Long-Life dönemleri kapsamı bunun ötesine taşıyabilir. AlmaLinux 10, hiçbir abonelik gerektirmeden 10 yıllık RHEL destek süresiyle eşleşir; yeniden oluşturma (rebuild) projelerinin varlık sebebi de budur.

Arch bu tabloda 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 da 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ı verir. Paket yöneticisi de bir diğer ayırt edici unsurdur. 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 erdi; CentOS Linux 7'nin ömrü ise 30 Haziran 2024 tarihinde tamamlandı. Mevcut proje olan CentOS Stream, RHEL ara sürümlerinin üzerine inşa edildiği daldır; bu nedenle değişiklikleri RHEL'den sonra değil, önce alır. 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ıyla gelir?

Çünkü sürüm numarası büyük ölçüde sabit kalırken düzeltmeler gelmeye devam eder. Debian, çoğu paket için daha yeni bir upstream sürümünü içe aktarmak yerine, yayınladığı sürüm içerisine güvenlik yamalarını 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ç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 yanlış sonuç verir.

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

Yalnızca düzenli bir takvimle güncelleme yapacaksanız kullanmalısınız. Rolling release 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 çalıştırmadan ö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 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 ağaç yapısı geri dönüş için bir önyükleme girdisi olarak saklanır. Tamamen güncellenmiş veya hiç güncellenmemiş, yarıda kalmış bir durum içermeyen bir makineye sahip olursunuz. Dosyaları yerinde düzenleyerek yazılım yükleme yönteminden vazgeçersiniz; bu nedenle uygulamalar container yapılarına veya katmanlı paketlere taşınır.