Historia dystrybucji Linux: drzewo genealogiczne systemów

Czym w rzeczywistości jest dystrybucja systemu Linux

Historia dystrybucji systemu Linux zaczyna się od luki: samo jądro Linux nie oferuje funkcjonalności użytecznych dla użytkownika. System uruchamia się i wykrywa sprzęt, po czym kończy działanie. Niezbędne jest dodanie środowiska użytkownika, wybór sposobu instalacji i aktualizacji oprogramowania oraz zapewnienie długoterminowego wsparcia. Dystrybucja stanowi zestaw tych wyborów oraz grupę osób, która zajmuje się ich utrzymaniem.

Składa się ona z pięciu elementów. Zmiana któregokolwiek z nich tworzy nową dystrybucję, nawet jeśli większość plików binarnych pozostaje zgodna:

• Jądro w wersji wybranej przez projekt, wraz z dodanymi poprawkami i sterownikami.
• Środowisko użytkownika: biblioteka C, powłoka, system init, standardowe polecenia.
• Format pakietów oraz narzędzie do ich instalacji.
• Polityka wydawnicza: zakres możliwych zmian, częstotliwość aktualizacji oraz okres wsparcia dla każdego wydania.
• Ludzie: opiekunowie pakietów, zespół ds. bezpieczeństwa oraz osoby odpowiedzialne za usuwanie awarii pakietów.

Jądro jest elementem wspólnym, dlatego dwie dystrybucje systemu Linux są znacznie bardziej do siebie zbliżone niż każda z nich do innego systemu typu Unix. Warto o tym pamiętać, porównując systemy Linux i FreeBSD jako platformy serwerowe, gdzie jądro oraz podstawowe środowisko użytkownika są tworzone przez jeden projekt i wydawane wspólnie. W systemie Linux komponenty te pochodzą od oddzielnych dostawców (upstream), a dystrybucja jest podmiotem, który zapewnia ich wzajemną współpracę.

Historia dystrybucji Linux w trzech rodzinach

Trzy projekty zapoczątkowane w latach 1993 i 1994 stały się fundamentami rodzin: Slackware, Debian oraz Red Hat. Obecnie niemal każdy obraz systemu w panelu sterowania VPS wywodzi się z jednej z nich lub jest jej potomkiem. Potomek dziedziczy format pakietów, układ plików oraz zazwyczaj cykl wydawniczy, dlatego dystrybucje pochodne Debiana zachowują jego charakter nawet po usunięciu oznaczeń marki.

Projekty niezależne zasługują na osobne zestawienie, ponieważ nie powstały na bazie innych systemów. Arch, Gentoo, Alpine, NixOS oraz Void stworzyły własne menedżery pakietów i własne zasady działania. Dwie z nich, Arch oraz Alpine, trafiły na listy obrazów u dostawców usług chmurowych z powodów niezwiązanych z zastosowaniami desktopowymi.

1992: dystrybucje przed erą rodzin systemów

MCC Interim Linux pojawił się w lutym 1992 roku, przygotowany przez Owena Le Blanca w Manchester Computing Centre. System zawierał jądro oraz narzędzia GNU (GNU's not Unix) na dwóch obrazach dyskietek, wraz z instalatorem opartym na menu. Powstał, ponieważ ręczna konfiguracja tych elementów zajmowała cały dzień pracy.

SLS (Softlanding Linux System), wydany przez Petera MacDonalda w 1992 roku, poszedł o krok dalej, dodając X (X Window System) oraz obsługę sieci TCP/IP. To właśnie SLS sprawił, że termin dystrybucja zyskał swoje obecne znaczenie. System był jednak pełen błędów i rzadko aktualizowany, co w 1993 roku skłoniło dwie osoby do niezależnych prób poprawy tej sytuacji. Jedna z nich przebudowała system, druga natomiast rozpoczęła prace od podstaw, opierając się na spisanych zasadach.

Slackware, 1993: najstarsza rodzina wciąż wydawana

Patrick Volkerding wydał Slackware 1.00 w dniu 16 lipca 1993 roku, tworząc go na bazie SLS i usuwając błędy. Dystrybucja jest nadal utrzymywana, co czyni ją najstarszą istniejącą dystrybucją Linux.

Pakiet Slackware to skompresowane archiwum tar zawierające skrypt instalacyjny. Brak w nim mechanizmu rozwiązywania zależności: żaden proces nie sprawdza, czy biblioteka wymagana przez nowy pakiet znajduje się już na dysku. Ta jedna decyzja ukształtowała wszystko inne. Skoro narzędzie nie rozwiązuje zależności, dostarczany zestaw musi być spójny z założenia, dlatego wydania są rzadkie i konserwatywne. Slackware 15.0 ukazało się w lutym 2022 roku, sześć lat po wersji 14.2.

Rodzina ta jest niewielka. Najwcześniejsze wydania SUSE z połowy lat 90. bazowały na Slackware, zanim projekt poszedł własną drogą, wprowadzając YaST, a później format pakietów RPM. Ten ostatni element bywa mylący. SUSE oraz openSUSE używają pakietów RPM, ale nie są pochodnymi Red Hat. Format został przejęty, jednak linia rozwojowa nie.

Debian, 1993: kontrakt społeczny i potok trzech wydań

Ian Murdock ogłosił powstanie Debian 16 sierpnia 1993 roku, trzy tygodnie po Slackware i z tego samego powodu. Nazwa łączy imię jego partnerki, Debry, z jego własnym. Manifest Debian ukazał się w styczniu 1994 roku i określił zasady: dystrybucja miała być utrzymywana otwarcie przez wolontariuszy, a nie przez firmę.

Następnie Debian spisał swoje zasady. Kontrakt społeczny Debian oraz DFSG (Debian free software guidelines) zostały przyjęte w lipcu 1997 roku, a DFSG stały się podstawą Open Source Definition w 1998 roku. Dokument napisany w celu ustalenia zawartości jednej dystrybucji ostatecznie zdefiniował kategorię licencji dla całej branży. Jest to również powód, dla którego Twój sources.list posiada komponenty: main zawiera oprogramowanie spełniające wytyczne, contrib oraz non-free przechowują to, co ich nie spełnia, a Debian 12 dodał non-free-firmware, aby laptop z kartą bezprzewodową mógł zostać zainstalowany bez konieczności poszukiwania sterowników.

Narzędzia to drugie dziedzictwo. dpkg instaluje jeden pakiet i odmawia wykonania operacji, gdy brakuje zależności, wyświetlając dpkg: dependency problems prevent configuration of. APT (advanced package tool), który stał się domyślnym narzędziem wraz z Debian 2.1 w 1999 roku, to warstwa obliczająca, co jeszcze należy pobrać i w jakiej kolejności. Każde polecenie apt w każdej pochodnej Debian wywodzi się z tej pracy.

Mechanizm wydawniczy posiada trzy zestawy pakietów i jedną zasadę. Opiekun przesyła pakiet do unstable, na stałe oznaczonego nazwą kodową sid. Skrypt przenosi pakiet do testing po około 5 do 10 dniach, jeśli zbudował się poprawnie na architekturach wydawniczych i nie wykryto w nim nowych krytycznych błędów. Następnie testing zostaje zamrożony, zespół wydawniczy usuwa pozostałe błędy, a stable zostaje wydane, gdy lista błędów jest wystarczająco krótka. Nie dzieje się to w oparciu o datę. Dlatego Debian stable wygląda na przestarzały, ale działa stabilnie: numery wersji zatrzymują się w momencie zamrożenia, podczas gdy poprawki bezpieczeństwa są do nich stale przenoszone (backporting).

Zarządzanie również jest sformalizowane, z wybieranym liderem projektu i wiążącymi uchwałami ogólnymi. W 2014 roku ten mechanizm wybrał systemd jako domyślny system init, a osoby, które się z tym nie zgadzały, utworzyły fork o nazwie Devuan, który wydał swoją pierwszą wersję w 2017 roku. Większymi potomkami są Ubuntu, Raspberry Pi OS, Proxmox VE, Kali oraz Linux Mint.

Red Hat, 1994: RPM, a następnie podział na Fedora i RHEL

Marc Ewing wydał pierwszą wersję Red Hat Linux w okolicach Halloween 1994 roku. Firma Boba Younga wykupiła ją w 1995 roku i wspólnie stworzyli pierwsze przedsiębiorstwo w branży Linux, które sprzedawało wsparcie techniczne, a nie oprogramowanie. Red Hat zadebiutował na giełdzie 11 sierpnia 1999 roku. IBM sfinalizował przejęcie spółki w lipcu 2019 roku za kwotę około 34 miliardów dolarów, więc dystrybucja, dla której certyfikowana jest większość oprogramowania klasy enterprise, od tego czasu stanowi własność IBM.

Trwałym wkładem technicznym jest RPM (Red Hat package manager), napisany przez Erika Troana i Marca Ewinga dla Red Hat Linux 2.0 w 1995 roku. Pakiet RPM deklaruje swoje zależności i jest tworzony na podstawie pliku spec, czyli receptury budowania, którą może uruchomić każdy. Ta druga właściwość umożliwiła później niezależne przebudowywanie produktu enterprise firmy Red Hat.

Red Hat Linux 9 z 2003 roku był ostatnim wydaniem oryginalnej linii. Firma podzieliła ją na dwie części: Fedora Core 1 w listopadzie 2003 roku jako szybkie wydanie społecznościowe oraz RHEL (Red Hat Enterprise Linux), który rozpoczął się jako Advanced Server 2.1 w 2002 roku, jako powolny produkt płatny. Przyczyna jest oczywista. Jeden produkt nie może być jednocześnie miejscem testowania nowych wersji oraz platformą, na której bank pracuje bez zmian przez dziesięć lat. Obie połowy są ze sobą powiązane: główna wersja RHEL wywodzi się z wydania Fedora, jest stabilizowana, a następnie zamrażana. Narzędzie do obsługi pakietów zmieniało się zgodnie z tym samym harmonogramem, przechodząc od yum w latach 2000. do dnf jako domyślnego rozwiązania w Fedora w 2015 roku, z rpm działającym pod spodem obu systemów.

Dlaczego CentOS przestał być darmową kopią RHEL

Projekt CentOS powstał w 2004 roku z prostym założeniem: pobrać pakiety źródłowe opublikowane przez Red Hat, usunąć znaki towarowe, skompilować je ponownie i udostępnić wynik. Przez dekadę był to domyślny darmowy system operacyjny dla serwerów, a w 2014 roku Red Hat przejął projekt pod swoje skrzydła.

8 grudnia 2020 roku Red Hat ogłosił, że wsparcie dla CentOS Linux 8 zakończy się 31 grudnia 2021 roku, czyli osiem lat wcześniej niż pierwotnie planowano, a nazwa będzie kontynuowana jako CentOS Stream. Stream nie jest kopią binarną. Jest to gałąź rozwojowa, z której wycinane są wydania minor RHEL, więc wyprzedza ona RHEL, zamiast za nim podążać. W przypadku maszyny, która ma działać przez lata, wyprzedzanie jest niewłaściwym kierunkiem, ponieważ zmiany otrzymuje się przed płacącymi klientami Red Hat.

W 2021 roku pojawiły się dwie alternatywne kopie. Rocky Linux został zainicjowany przez Gregory'ego Kurtzera, współzałożyciela CentOS. AlmaLinux został sfinansowany przez CloudLinux. W czerwcu 2023 roku Red Hat przestał publikować źródła RHEL gdziekolwiek poza CentOS Stream oraz swoim portalem klienta. Rocky Linux nadal dąży do tworzenia identycznych kopii binarnych. AlmaLinux zmienił swój cel na kompatybilność ABI (application binary interface), co oznacza, że oprogramowanie zbudowane dla RHEL działa, bez gwarancji, że lista błędów jest identyczna co do linii. Oracle, SUSE oraz CIQ utworzyły później w tym samym roku OpenELA, aby publikować wspólne źródła.

Jeśli lista obrazów u dostawcy nadal zawiera CentOS, należy ustalić, o którą wersję chodzi, zanim rozpocznie się na niej budowę infrastruktury.

cat /etc/os-release

NAME="CentOS Stream" to ciągła gałąź rozwojowa, która wyprzedza RHEL. NAME="AlmaLinux" lub NAME="Rocky Linux" to kopia binarna, która podąża za RHEL z dziesięcioletnim cyklem wsparcia.

Ubuntu 20.04: migawka Debian unstable w kalendarzu

System Ubuntu 4.10 został wydany 20 października 2004 roku, a jego finansowanie zapewnił Mark Shuttleworth. Relacja z Debianem ma charakter techniczny, a nie sentymentalny. Każdy cykl wydawniczy rozpoczyna się od importu pakietów z Debian unstable do nowego wydania Ubuntu. Importy trwają do momentu zamrożenia importu z Debiana (Debian Import Freeze), które następuje w trakcie cyklu; po tym terminie Ubuntu wprowadza własne zmiany. Wiele pakietów Ubuntu stanowi połączenie pakietu z Debiana oraz dodatkowej różnicy (delta), co jest udokumentowane w pliku changelog.

Drugim filarem jest kalendarz. Debian wydaje swoje wersje, gdy są gotowe. Ubuntu publikuje wydania w kwietniu i październiku, a numer wersji odpowiada dacie: wersja 24.04 ukazała się w kwietniu 2024 roku. Każde drugie wydanie kwietniowe to LTS (long term support), co jest domyślnym wyborem dostawców usług, gdy oferują Ubuntu bez dodatkowych kwalifikatorów. Wybór między tymi dwoma wariantami na serwerze jest głównym tematem wyboru między Ubuntu LTS a wydaniami tymczasowymi, natomiast przejście między kolejnymi wersjami LTS posiada własną procedurę, opisaną w aktualizacji z 24.04 do 26.04.

Jeden szczegół co roku sprawia trudności administratorom serwerów. Archiwum Ubuntu jest podzielone na komponenty. main jest utrzymywane przez Canonical przez cały okres wsparcia. universe jest utrzymywane przez społeczność, a zakres wsparcia w zakresie bezpieczeństwa jest objęty innymi gwarancjami. apt install nie zawiera informacji o tej różnicy. Jedno polecenie pozwala to sprawdzić:

apt-cache policy nginx

Linia repozytorium kończąca się na /main oznacza, że za dany pakiet odpowiada zespół ds. bezpieczeństwa Canonical. Linia kończąca się na /universe oznacza, że odpowiada za niego społeczność. Należy to zweryfikować dla każdego komponentu wystawionego na działanie sieci Internet.

Arch, 2002: wydania kroczące i koszt częściowej aktualizacji

Judd Vinet wydał Arch 0.1 w dniu 11 marca 2002 roku, wraz z napisanym przez siebie menedżerem pakietów pacman oraz skryptami budowania, które są zwykłymi skryptami powłoki. Arch nie posiada wydań wersjonowanych. Nośniki instalacyjne to datowane migawki tych samych repozytoriów kroczących, więc maszyna zainstalowana w 2019 roku i aktualizowana co tydzień uruchamia ten sam system Arch, co maszyna zainstalowana dzisiaj. AUR (Arch user repository) przechowuje przepisy budowania dostarczane przez użytkowników. Są to przepisy, a nie zweryfikowane pakiety, dlatego czytanie pliku PKGBUILD przed jego uruchomieniem jest częścią obowiązków administratora.

Model kroczący ma jeden tryb awarii, za który za każdym razem odpowiada użytkownik. Instalacja pojedynczego pakietu za pomocą pacman -Sy foo odświeża bazę danych pakietów, a następnie instaluje nowy plik binarny połączony z bibliotekami nowszymi niż te znajdujące się na dysku. Programy ulegają wtedy awarii w następujący sposób:

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

Wspieraną operacją jest pacman -Syu, która aktualizuje wszystko jednocześnie. Projekt publikuje również wpisy informacyjne, które wskazują, kiedy przed niektórymi aktualizacjami wymagana jest ręczna interwencja; przeprowadzenie aktualizacji bez ich przeczytania może doprowadzić do sytuacji, w której maszyna nie uruchomi się.

To sprawia, że Arch jest słabym wyborem dla serwera, który ma być ignorowany. Maszyna aktualizowana co tydzień działa poprawnie. Maszyna aktualizowana raz, po roku, wymusza wykonanie wszystkich pominiętych interwencji w trakcie jednego uruchomienia.

Alpine: niewielka dystrybucja spopularyzowana przez kontenery

Projekt Alpine rozpoczął się około 2005 roku jako fork LEAF (Linux embedded appliance framework), wywodzącego się z kolei z Linux Router Project. Natanael Copa stworzył go z myślą o urządzeniach typu appliance, a nie o komputerach stacjonarnych. System zastępuje większość standardowych komponentów użytkownika: bibliotekę glibc zastąpiono musl, narzędzia GNU core utilities zastąpiono BusyBox, a systemd zastąpiono OpenRC. Menedżerem pakietów jest apk. W 2014 roku wydanie Alpine 3.0 wprowadziło przejście na musl.

Popularność systemu wzrosła wraz z rozwojem kontenerów. Warstwa bazowa Alpine zajmuje ułamek rozmiaru obrazu Debian lub Ubuntu, dlatego od 2016 roku stała się powszechnym wyborem. Wiele osób korzysta z Alpine codziennie, mimo że nigdy nie instalowało tego systemu na fizycznym sprzęcie.

Koszt tego rozwiązania wynika z faktu, że musl nie jest tożsamy z glibc. Różnice objawiają się błędami, które pozornie wydają się niepowiązane. Plik binarny skompilowany dla glibc nie uruchomi się w Alpine, zwracając komunikat sugerujący brak pliku, który w rzeczywistości istnieje:

sh: ./myapp: not found

Program jest obecny w systemie. Brakuje jednak jego interpretera ELF, ponieważ loader glibc nie jest dostępny. Kolejnym częstym zaskoczeniem jest Python: gotowe pakiety typu wheel przygotowane dla manylinux nie instalują się w środowisku musl. W rezultacie pip próbuje kompilować kod ze źródeł i przerywa pracę, jeśli w systemie nie zainstalowano kompilatora. Standard musllinux wheel wprowadzony w 2021 roku rozwiązał ten problem dla projektów, które publikują takie pakiety, jednak nie dotyczy to pozostałego oprogramowania.

Jako system operacyjny na VPS, Alpine charakteryzuje się niewielkim rozmiarem i szybką aktualizacją, jednak wymusza odejście od ścieżek zakładanych w większości dokumentacji. Każdy poradnik zalecający użycie systemctl enable wymaga przełożenia na rc-update add.

Generacja niezmienna: aktualizacje atomowe i serwery oparte na obrazach

Najnowsza gałąź rozwoju zmienia model aktualizacji zamiast listy pakietów. System oparty na ostree utrzymuje /usr w trybie tylko do odczytu. Aktualizacja stanowi kompletne, nowe drzewo systemu plików, które jest pobierane, przygotowywane i aktywowane przy następnym restarcie. Poprzednie drzewo pozostaje jako wpis rozruchowy, więc nieudaną aktualizację można cofnąć, uruchamiając system ponownie ze starej wersji.

Fedora Silverblue wprowadziła to rozwiązanie na komputery stacjonarne w 2018 roku, a Fedora CoreOS przeniosła je na serwery w 2019 roku, po przejęciu CoreOS przez Red Hat w 2018 roku. Flatcar Container Linux kontynuował rozwój oryginalnego Container Linux po jego wycofaniu w 2020 roku. openSUSE MicroOS osiąga ten sam cel poprzez migawki btrfs i transactional-update. W 2024 roku Red Hat dodał do RHEL tryb oparty na obrazach, zbudowany na bootc, w którym system operacyjny jest dostarczany jako obraz kontenera, a maszyna jest aktualizowana poprzez wskazanie nowego tagu. Talos Linux idzie najdalej i całkowicie usuwa powłokę oraz SSH: maszyna jest konfigurowana przez API, więc nie ma możliwości zalogowania się. NixOS, wydany po raz pierwszy w 2007 roku, wywodzi się z innego założenia. Cały system jest budowany z jednej deklaratywnej konfiguracji, a poprzednie generacje pozostają możliwe do uruchomienia.

Dostawca usług prawdopodobnie nie oferuje żadnego z tych rozwiązań jako obrazu instalowanego jednym kliknięciem, ponieważ oczekuje konfiguracji przy pierwszym uruchomieniu za pomocą Ignition lub cloud-init, zamiast edycji plików przez administratora za pośrednictwem SSH. Rozwiązania te przynoszą korzyści w przypadku wielu identycznych maszyn, co jest sytuacją, w której znajdujesz się, gdy zarządzasz wieloma serwerami Linux jednocześnie i potrzebujesz, aby każdy z nich był weryfikowalnie taki sam jak pozostałe.

Jak długo wspierane jest jedno wydanie?

Polityka wydań to element dystrybucji, z którym użytkownik obcuje najdłużej; jest ona publikowana jako liczba lat. Poniżej przedstawiono okresy wsparcia dla 5 bieżących wydań serwerowych.

[
  {
    "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 wspiera każdą gałąź 3.x przez 2 lata, dlatego lepiej sprawdza się w obrazach kontenerów, które często przebudowujesz, niż na hoście pozostawionym bez zmian. Zespół ds. bezpieczeństwa Debian obejmuje wydanie stable wsparciem przez około 3 lata, a następnie zespół LTS utrzymuje wsparcie dla popularnych architektur łącznie przez około 5 lat. Ubuntu LTS zapewnia 5 lata dla pakietów w main, a subskrypcja Ubuntu Pro wydłuża ten okres do 10 lat (bezpłatnie do użytku osobistego na ograniczonej liczbie maszyn). RHEL 10 deklaruje 10 lat, co płatny dodatek extended life cycle support wydłuża do 13. AlmaLinux 10 oferuje taki sam okres jak RHEL, czyli 10 lat, bez żadnych subskrypcji – co stanowi główny powód istnienia tego typu rebuildów.

Arch nie posiada tutaj swojego wiersza, ponieważ dystrybucja typu rolling release nie posiada wydań, które wymagałyby wsparcia. W przypadku Arch istotną liczbą jest czas, przez jaki można pozostawić maszynę bez ingerencji, co mierzy się w tygodniach.

Dlaczego lista obrazów VPS wygląda w ten sposób

Dostawca udostępnia obrazy, o które proszą klienci, a które instalują się automatycznie na jego hiperwizorze. Dlatego niemal każda lista otwiera się systemami Ubuntu LTS i Debian stable, dodaje AlmaLinux lub Rocky dla użytkowników, których oprogramowanie posiada certyfikację dla RHEL, a na dalszych pozycjach umieszcza Alpine, Arch oraz Fedora. Gdy wiadomo już, czym jest VPS i w jaki sposób obraz trafia na dysk, wzorzec staje się czytelny: dostawca wybiera systemy operacyjne, które przechodzą przez instalację bezobsługową i pozostają wspierane dłużej, niż wynosi średni czas utrzymywania serwera przez klienta.

Wybór ten zobowiązuje do czegoś więcej niż tylko korzystania z menedżera pakietów. Określa on sposób aktualizacji, którą przeprowadzisz za trzy lata, a te różnią się całkowicie w zależności od rodziny systemu. Debian i Ubuntu wspierają aktualizacje wersji głównych w miejscu. Rodzina Red Hat przeprowadza je za pomocą leapp. Arch nie posiada aktualizacji wersji, ponieważ nie posiada wersji. W przypadku Alpine polega to na edycji /etc/apk/repositories i uruchomieniu apk upgrade --available. Wybór ten określa również, jakie oprogramowanie można zainstalować bez dodawania zewnętrznych repozytoriów, kto dostarcza poprawkę, gdy wpis CVE (common vulnerabilities and exposures) dotyczy używanego komponentu, oraz jaki system init i biblioteka C będą wymagane przez przyszłe oprogramowanie.

Istnieje jeszcze jeden skutek, który łatwo zlekceważyć. Większość odpowiedzi w Internecie zakłada ścieżkę dla rodziny Debian lub rodziny Red Hat, więc wybór systemu spoza tych dwóch grup oznacza konieczność tłumaczenia instrukcji przez cały okres eksploatacji maszyny. Należy wybrać rodzinę, której polityka wydań odpowiada częstotliwości, z jaką użytkownik chce ingerować w serwer, a następnie pozostać przy niej. Zmiana pakietów zainstalowanych w systemie jest łatwa. Zmiana dystrybucji pod nimi oznacza konieczność przebudowania serwera od podstaw.

FAQ

Do której rodziny dystrybucji Linux należy mój serwer?

Uruchom cat /etc/os-release. Pole ID wskazuje nazwę dystrybucji, a ID_LIKE nazwę jej rodziny; maszyna z Ubuntu zwróci ID_LIKE=debian, a maszyna z AlmaLinux zwróci ID_LIKE="rhel centos fedora". Innym wyznacznikiem jest menedżer pakietów. apt oraz dpkg oznaczają rodzinę Debian, dnf oraz rpm rodzinę Red Hat, apk oznacza Alpine, a pacman oznacza Arch.

Czy CentOS jest nadal darmową wersją RHEL?

Nie. CentOS Linux 8, ostatnia wersja typu rebuild o tej nazwie, zakończyła wsparcie 31 grudnia 2021 r., a CentOS Linux 7 osiągnął kres cyklu życia 30 czerwca 2024 r. Obecny projekt, CentOS Stream, stanowi gałąź, na której bazują wydania minor RHEL, dlatego zmiany trafiają tam przed RHEL, a nie po nim. Darmowe wersje typu rebuild, które przejęły dawną rolę, to AlmaLinux oraz Rocky Linux; obie oferują dziesięcioletni okres wsparcia.

Dlaczego Debian stable dostarcza tak stare numery wersji?

Ponieważ numer wersji zostaje zamrożony, podczas gdy poprawki są stale wdrażane. Debian przenosi poprawki bezpieczeństwa (backport) do wydanej wersji zamiast importować nowsze wydanie od twórców oprogramowania (upstream), więc pakiet oznaczony jako 2.4.57-2+deb13u1 może zawierać poprawkę opublikowaną w zeszłym tygodniu. Sufiks po wersji upstream to rewizja Debiana, a apt changelog <package> zawiera listę zmian w niej zawartych. Ocenianie bezpieczeństwa serwera Debian na podstawie numerów wersji zawsze prowadzi do błędnych wniosków.

Czy powinienem używać dystrybucji typu rolling release, takiej jak Arch, na VPS?

Tylko jeśli będziesz aktualizować system zgodnie z harmonogramem. Dystrybucja typu rolling zakłada, że każda maszyna dąży do aktualnego zestawu pakietów, więc aktualizacja pojedynczego pakietu za pomocą pacman -Sy foo prowadzi do niedopasowania bibliotek i błędów typu cannot open shared object file. Uruchamiaj pacman -Syu regularnie, czytaj stronę z aktualnościami projektu przed każdym uruchomieniem, a system będzie stabilny. Jeśli pozostawisz system bez aktualizacji przez rok, pierwsza próba aktualizacji stanie się ryzykowna.

Co faktycznie zmienia dystrybucja niezmienna (immutable) lub atomowa?

Zmienia ona moment stosowania aktualizacji oraz sposób ich wycofywania. /usr jest montowane w trybie tylko do odczytu, aktualizacja jest przygotowywana jako kompletne nowe drzewo plików, a przełączenie następuje przy restarcie, przy czym poprzednie drzewo jest zachowywane jako wpis rozruchowy umożliwiający wycofanie zmian (rollback). Otrzymujesz maszynę, która jest albo w pełni zaktualizowana, albo w pełni nie, bez stanu częściowego wdrożenia. Rezygnujesz z instalacji oprogramowania poprzez edycję plików w miejscu, więc aplikacje przenoszą się do kontenerów lub pakietów warstwowych.