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ę, wykrywa sprzęt i na tym kończy działanie. Niezbędne jest dodanie przestrzeni użytkownika (userland), wybór sposobu instalacji i aktualizacji oprogramowania oraz zapewnienie długoterminowego wsparcia technicznego. 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 identyczna:

• Jądro w określonej wersji, wybranej przez projekt, wraz z dodanymi poprawkami i sterownikami.
• Przestrzeń użytkownika (userland): biblioteka C, powłoka (shell), system init, standardowe polecenia.
• Format pakietów oraz narzędzie do ich instalacji.
• Polityka wydawnicza: zakres dopuszczalnych zmian, częstotliwość aktualizacji oraz czas wsparcia dla każdego wydania.
• Zespół: 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 podstawowa przestrzeń użytkownika są tworzone przez jeden projekt i wydawane wspólnie. W systemie Linux komponenty te pochodzą z oddzielnych źródeł (upstreams), a dystrybucja jest podmiotem, który zapewnia ich wzajemną kompatybilność.

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 dystrybucja pochodna Debiana zachowuje 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, choć przyczyny tego stanu rzeczy nie były związane z zastosowaniami desktopowymi.

1992: dystrybucje przed powstaniem rodzin

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 sterowanym 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. SLS jest powodem, dla którego słowo dystrybucja ma dzisiejsze 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 naprawy sytuacji. Jedna z nich przebudowała system, druga natomiast rozpoczęła prace od zera, 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 wpłynęła na wszystkie pozostałe aspekty. 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 korzystają z pakietów RPM, ale nie są pochodnymi Red Hat. Format został przeniesiony. Linia rozwojowa – nie.

Debian, 1993: umowa społeczna 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. Umowa społeczna 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 rozwiązaniem wraz z Debian 2.1 w 1999 roku, to warstwa ustalają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 gałęzie 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 usterki, a stable zostaje wydane, gdy lista błędów jest wystarczająco krótka. Nie dzieje się to w konkretnym terminie. 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 Devuan, który swoje pierwsze wydanie miał w 2017 roku. Debian nie był ani pierwszą dystrybucją, która dokonała tej zmiany, ani ostatnią, a powody, dla których to się powtarzało, wraz z zastrzeżeniami, które okazały się słuszne, zostały opisane w relacji o tym, jak systemd zastąpił SysV init. 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 zakupiła ją w 1995 roku i wspólnie stworzyli pierwsze przedsiębiorstwo w branży Linux, które sprzedawało wsparcie techniczne zamiast oprogramowania. 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 z pliku spec, czyli przepisu budowania, który może uruchomić każdy. Ta druga właściwość umożliwiła później niezależne kompilacje produktu enterprise firmy Red Hat.

Red Hat Linux 9 z 2003 roku był ostatnim wydaniem z oryginalnej linii. Firma podzieliła go 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 powolne wydanie płatne. 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 zarządzania pakietami ewoluowało zgodnie z tym samym harmonogramem, 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 zadaniem: pobrać pakiety źródłowe opublikowane przez Red Hat, usunąć znaki towarowe, zbudować 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 wywodzą się 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 niepożądane, 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 własnym portalem klienta. Rocky Linux nadal dąży do bycia identyczną kopią. AlmaLinux zmienił swój cel na kompatybilność ABI (application binary interface), co oznacza, że oprogramowanie zbudowane dla RHEL będzie działać, bez gwarancji, że lista błędów pokrywa się w każdym szczególe. Oracle, SUSE oraz CIQ utworzyły później w tym samym roku OpenELA, aby publikować wspólne źródła. Cały ten proces, od podziału w 2003 roku po zmianę w udostępnianiu źródeł w 2023 roku oraz aktualne obietnice poszczególnych projektów, został opisany w szczegółowym opracowaniu na temat Red Hat, CentOS, Rocky i AlmaLinux.

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 okresem wsparcia.

Ubuntu 20.04: migawka Debian unstable w kalendarzu

System Ubuntu 4.10 został wydany 20 października 2004 roku dzięki finansowaniu Marka Shuttlewortha. Relacja tego systemu z Debianem ma charakter techniczny, a nie sentymentalny. Każdy cykl wydawniczy rozpoczyna się od zaimportowania 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 połowie cyklu; po tym terminie Ubuntu wprowadza własne zmiany. Wiele pakietów Ubuntu to pakiety Debiana z dodatkową deltą, co jest odnotowane w dzienniku zmian (changelog).

Drugim filarem jest kalendarz. Debian wydaje swoje wersje, gdy są gotowe. Ubuntu wydaje wersje 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), czyli wersja, którą dostawcy usług mają na myśli, oferując Ubuntu bez dodatkowych kwalifikatorów. Wybór między tymi dwoma wariantami na serwer jest głównym tematem wyboru między Ubuntu LTS a wydaniami przejściowymi, a przejście z jednego wydania LTS na kolejne posiada własną procedurę, opisaną w aktualizacji z 24.04 do 26.04.

Jeden szczegół co roku zaskakuje administratorów 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 bezpieczeństwa stanowi odrębną obietnicę. 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 Internetu.

Arch, 2002: wydania typu rolling release 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 jedynie datowane migawki tych samych repozytoriów typu rolling, więc maszyna zainstalowana w 2019 roku i aktualizowana co tydzień uruchamia ten sam system Arch, co maszyna zainstalowana dzisiaj. AUR (Arch user repository) zawiera skrypty budowania dostarczane przez użytkowników. Są to przepisy, a nie zweryfikowane pakiety, dlatego częścią pracy administratora jest analiza pliku PKGBUILD przed jego uruchomieniem.

Model rolling release posiada jeden tryb awarii, za każdym razem wywoływany przez użytkownika. Instalacja pojedynczego pakietu za pomocą pacman -Sy foo odświeża bazę danych pakietów, a następnie instaluje nowy plik binarny powiązany z bibliotekami nowszymi niż te znajdujące się na dysku. Programy kończą wtedy działanie 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 wszystkie elementy jednocześnie. Projekt publikuje również wpisy informacyjne, w których zaznacza, że przed niektórymi aktualizacjami wymagana jest ręczna interwencja. Uruchomienie aktualizacji bez zapoznania się z nimi może doprowadzić do sytuacji, w której maszyna nie uruchomi się ponownie.

Czyni to Arch słabym wyborem dla serwera, który ma pozostać bez nadzoru. Maszyna aktualizowana co tydzień działa poprawnie. Maszyna aktualizowana raz na rok wymusza wykonanie wszystkich pominiętych interwencji w trakcie jednej sesji.

Alpine: niewielka dystrybucja spopularyzowana przez kontenery

Alpine powstało około 2005 roku jako fork LEAF (Linux embedded appliance framework), wywodzącego się z projektu Linux Router Project. Natanael Copa stworzył je z myślą o urządzeniach typu appliance, a nie o komputerach stacjonarnych. System zastępuje większość standardowych komponentów przestrzeni użytkownika: musl zamiast biblioteki GNU C, BusyBox zamiast narzędzi GNU coreutils, OpenRC zamiast systemd oraz apk jako menedżer pakietów. Wersja Alpine 3.0 z 2014 roku wprowadziła przejście na musl.

Popularność przyniosły systemowi kontenery. Warstwa bazowa Alpine stanowi ułamek rozmiaru obrazu bazowego Debian lub Ubuntu. Od 2016 roku stało się powszechnym obrazem bazowym, przez co wiele osób, które nigdy nie zainstalowały Alpine, korzysta z niego na co dzień.

Koszt tego rozwiązania wynika z faktu, że musl nie jest glibc, a różnice objawiają się błędami, które wydają się niepowiązane. Plik binarny skonsolidowany z glibc nie uruchomi się na Alpine, zwracając komunikat, który kieruje użytkownika do poszukiwania pliku, który fizycznie istnieje:

sh: ./myapp: not found

Program istnieje. Jego interpreter ELF nie, ponieważ brakuje loadera glibc. Python stanowi kolejne częste zaskoczenie: gotowe pakiety typu wheel zbudowane dla manylinux nie zainstalują się na musl, więc pip próbuje kompilować je ze źródeł i przerywa działanie, gdy w systemie nie ma kompilatora. Standard musllinux wheel wprowadzony w 2021 roku rozwiązał ten problem dla projektów, które publikują takie pakiety, ale nie dla pozostałych.

Jako system operacyjny na serwerze VPS, Alpine zajmuje mało miejsca i szybko się aktualizuje, jednak odbiega od ścieżki zakładanej w większości dokumentacji. Każdy poradnik zalecający użycie systemctl enable wymaga przełożenia na rc-update add.

Niezmienna generacja: 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 desktopy w 2018 roku, a Fedora CoreOS 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 snapshoty 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, całkowicie usuwając powłokę i 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.

Twój dostawca 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 się znajdujesz, gdy zarządzasz kilkoma serwerami Linux jednocześnie i potrzebujesz, aby każdy z nich był weryfikowalnie taki sam jak pozostałe.

Jak długo wspierane jest 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, którego nie zmieniasz. Zespół bezpieczeństwa Debian obejmuje wydanie stable wsparciem przez około 3 lata, a zespół LTS utrzymuje wsparcie dla popularnych architektur łącznie do 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 publikuje okres 10 lat, który płatny dodatek extended life cycle support wydłuża do 13. AlmaLinux 10 dorównuje okresowi RHEL wynoszącemu 10 lat bez żadnej subskrypcji, co jest głównym powodem istnienia takich rebuildów.

Arch nie posiada tutaj wiersza, ponieważ dystrybucja typu rolling release nie posiada wydań, które wymagałyby wsparcia. Liczbą istotną dla Arch 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ę bezobsługowo 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 Alpine, Arch i Fedora umieszcza w dalszej części. Gdy już wiesz, czym jest VPS i w jaki sposób obraz trafia na dysk, wzorzec staje się czytelny: dostawca wybiera systemy operacyjne, które przechodzą bezobsługową instalację i pozostają wspierane dłużej, niż przeciętny klient utrzymuje serwer.

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 oprogramowania, oraz jaki system init i biblioteka C będą wymagane przez przyszłe aplikacje.

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 spoza tych dwóch grup oznacza konieczność tłumaczenia instrukcji przez cały okres eksploatacji maszyny. Wybierz rodzinę, której polityka wydawnicza odpowiada częstotliwości, z jaką chcesz ingerować w serwer, a następnie trzymaj się jej. 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 jej rodzinę, więc maszyna z Ubuntu zwróci ID_LIKE=debian, a maszyna z AlmaLinux zwróci ID_LIKE="rhel centos fedora". Innym wskaźnikiem 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 kompilacja pod tą nazwą, zakończyła wsparcie 31 grudnia 2021 roku, a CentOS Linux 7 osiągnął koniec cyklu życia 30 czerwca 2024 roku. Pozostały projekt, CentOS Stream, jest gałęzią, na której bazują wydania minor RHEL, więc zmiany trafiają tam przed RHEL, a nie po nim. Darmowymi zamiennikami, które przejęły dawną rolę, są AlmaLinux oraz Rocky Linux, oba z dziesięcioletnim okresem 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 do wydanej wersji zamiast importować nowsze wydanie 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 jednego pakietu za pomocą pacman -Sy foo prowadzi do niedopasowania bibliotek i błędów takich jak 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 go na rok, pierwsza aktualizacja stanie się ryzykowna.

Co faktycznie zmienia dystrybucja typu immutable lub atomic?

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, a przełączenie następuje podczas restartu, przy czym poprzednie drzewo jest zachowywane jako wpis rozruchowy umożliwiający wycofanie zmian. 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 warstwowych pakietów.