Którą dystrybucję Linuksa wybrać?

Jeśli zadajesz to pytanie i oczekujesz na nie odpowiedzi od losowej osoby z internetu, z dużym prawdopodobieństwem jesteś nowicjuszem. W takim wypadku wybierz Ubuntu – głównie dlatego, że wszystko działa out-of-box, nie dostarcza większych problemów przy używaniu, ma dużo dostępnych paczek oraz jest bardzo popularne.

A co, jeśli nie jestem nowicjuszem?

Wtedy prawdopodobnie odpowiedzi będziesz w stanie udzielić sobie sam, a mój głos może być dla Ciebie co najwyżej doradczy. Być może masz na oku dystrybucję, którą właśnie chciałeś przetestować, lub masz na myśli funkcjonalność, której brakowało Ci dotychczasowych dystrybucjach? Śmiało, przetestuj ją. Jeśli boisz się problemów (np. że Twój podstawowy system stanie się nieużywalny), pamiętaj, że żyjemy w ciekawych czasach, w których prawie wszystkie procesowy dostarczają wsparcie dla wirtualizacji, więc możesz zainstalować nowy system w maszynie wirtualnej zamiast ryzykować problemów na podstawowym sprzęcie.

Jeśli nadal zależy Ci na mojej opinii, poniżej przeczytasz, co sądzę o różnych dystrybucjach, z którymi miałem do czynienia.

Mandriva

Jest to system, od którego właściwie zaczynałem przygodę z Linuksem zainstalowanym na komputerze, a nie tylko okazjonalnie uruchamiane LiveCD/pendrive. Zapamiętałem ją jako całkiem przyjazną dystrybucję dla początkującego użytkownika. Jedynym problemem wtedy dla mnie było to, że za nic nie dało się jej zaktualizować, czego nie mogłem naprawić nawet na czystej instalacji w kilka miesięcy lub rok później. W tym momencie (grudzień 2017) jej opis jest pewnego rodzaju żartem, bo Mandriva od kilku lat jest martwym projektem, a jej ostatnie wydanie miało miejsce w okolicy początku mojego zainteresowania Linuksem.

Ubuntu

Ubuntu to dystrybucja, którą zainstalowałem na moim pierwszym komputerze codziennego użytku i używam jej do dziś na kolejnych desktopach. Za co je lubię? Za to, że z każdym wydaniem było w nim coraz mniej problemów z moim sprzętem (co nie jest takie oczywiste, gdy było się właścicielem laptopa Fujitsu-Siemens Computers), a nowe programy instalowało się prostym apt-get install. Za to, że nawet jeśli czegoś nie ma w repozytoriach, prawdopodobnie istnieje do tego odpowiednie PPA, a w „najgorszym” wypadku istnieje do tego odpowiednia paczka deb na stronie projektu. Za to, że nie forsuje za wszelką cenę bycia „free and open software”, a bardziej stara się być przydatne użytkownikowi końcowemu. W szczególności widać to już przy instalacji, w której instalator proponuje instalację własnościowego oprogramowania (fanatykom przypomnę, że nawet dekoder tak popularnego formatu jak mp3 nie jest w pełni wolny; na szczęście Flash i Java coraz mniej interesują przeciętnego użytkownika). Przy takiej (olbrzymiej) popularności projektu, praktycznie nie ma szans trafić na problem, który już nie byłby wałkowany wielokrotnie w internecie, co mocno ułatwia rozwiązywanie ewentualnych problemów.

Złośliwi z przekąsem stwierdzają, że nazwa „Ubuntu” znaczy „nie umiem zainstalować Debiana”. Jeśli ktoś, żeby się dowartościować, musi wytykać innym korzystanie z graficznego instalatora, gdy on umie zainstalować system kreatorem prowadzącym go tak samo za rękę, ale w ncurses, to serio musi być smutnym człowiekiem. Tak na prawdę nazwa tłumaczy się z jednego z afrykańskich języków jako „człowieczeństwo wobec innych”.

Cykl wydawniczy Ubuntu to nowe wydanie każdego kwietnia i października. Ktoś chcący być cały czas na bieżąco na pewno bardzo się z tego cieszy, mnie natomiast zadowalają tzw. wydania LTS (long term support) o wydłużonym wsparciu, które wydawane są co dwa lata w kwietniu. Jedną z ich właściwości jest bezproblemowa aktualizacja między nimi, czyli np. z 14.04 LTS (wydanego w kwietniu 2014, co szybko można odczytać z numeru wersji) łatwo jest zaktualizować się do 16.04 LTS, w przeciwieństwie do np. 14.10, które należałoby aktualizować stopniowo przez 15.04 i 15.10.

Linux Mint

Mint bazuje na Ubuntu, ale może być momentami z nim niekompatybilny. Wyróżnia się przede wszystkim innym domyślnym zestawem środowisk graficznych, co akurat – w świecie Linuksa – jest słabym argumentem za wyborem danej dystrybucji, bo w Ubuntu też da się używać MATE i Cinnamon, a instaluje się je bez problemu z repozytorium lub PPA. Podobnie jak Ubuntu – ma półroczny cykl wydawniczy, jednak nie dostarcza metod aktualizacji między poszczególnymi wydaniami (zalecana jest ponowna instalacja).

Linux Mint Debian Edition

Czyli w skrócie LMDE. Skusił mnie tym, że miał być rolling-release, czyli systemem bez wydań. Znaczy to, że wszystkie nowe (ale odpowiednio dojrzałe) pakiety od razu trafiają do repozytoriów. Idea brzmi fajnie, bazowany w dodatku jest na Debianie (sidzie?), więc tym lepiej, że nie jest kolejnym losowym systemem niekompatybilnym z niczym poza własnym światkiem. Rzeczywistość wszystko zweryfikowała – dystrybucja okazała się semi-rolling, co należy rozumieć, że po prostu w repozytoriach co około 3 miesiące lądował snapshot z najnowszym pakietami, a w międzyczasie zero/nic/NULL nowych aktualizacji. Nawet tych bezpieczeństwa! Z dystrybucją tą miałem do czynienia w momencie, w którym świat obiegła wiadomość o istnieniu dziury Heartbleed. Czekałem prawie tydzień odkąd Debian załatał swojego OpenSSLa, aż w repozytoriach pojawią się stosowne aktualizacje, ale się nie doczekałem. Jako krótkoterminowe rozwiązanie na szybko dopisałem w sources.list repozytoria któregoś Debiana, a w jakiś czas później miejsce LMDE zajęło Ubuntu.

Arch Linux

Arch kusił tym, że jest rolling-release oraz wspierał tylko i686 (dziś już nie wspiera i686) i x86-64. i686 było tu o tyle ważne, że nie było to żadne i486 lub i586, jak inne dystrybucje w tamtym czasie (2012 rok?), więc potencjalnie na każdym ze współczesnych procesorów można było wycisnąć minimalnie więcej dzięki programom kompilowanym na „najwyższe stadium rozwoju” 32-bitowego x86 zamiast procesory kompatybilne jedynie z Pentium Pro lub Pentium III. Pogoń za zyskiem wydajności przez kompilację najbliżej architektury docelowego procesora przejąłem z filozofii Gentoo, którym się zajmowałem chwilę wcześniej (przed instalacją Archa) i później. Innym autem miała być możliwie modularna i niezależna od siebie kompilacja programów, czyli że instalacja jednego wciągała tylko niezbędne zależności zamiast miliona dodatkowych paczek, jak to się dzieje w innych systemach. Moim zdaniem, to mogło być źródłem niespójności w środowisku graficznym mojego systemu, a oczywiście różnica w wydajności nie była widoczna gołym okiem. W dodatku zniechęca układ, w którym dużo przydatnego oprogramowania wypchnięte jest poza podstawowe repozytoria – konkretnie do AUR.

O ile na moim desktopie Arch nie przetrwał długo, tak musiałem go jeszcze w innym miejscu utrzymać. Niestety, ciągłe dystrybucje (rolling-release) są  przyjemne w utrzymaniu tylko wtedy, gdy same są ciągle aktualizowane. W przeciwnym przypadku, np. po roku można otrzymać system, w którym godzinę trzeba będzie będzie poświęcić na samo odpowiedzenie na początkowe pytania w stylu „usunęliśmy pakiet X, ale mamy dla niego zastępstwo w pakiecie Y; czy chcesz go zainstalować?”, a potem i tak aktualizacja się wysypuje, a pytania trzeba przejść od nowa. Jest to tym trudniejsze, gdy właśnie powszechnie dystrybucje Linuksa migrowały z SystemV na SystemD (dwa różne systemy uruchamiania systemu i usług). W związku z tym taki Arch stał się nieaktualizowalny i został zastąpiony innym systemem.

Co trzeba mu przyznać, rzeczywiście ma najnowsze pakiety (czasem serio bleeding edge). Linus Torvalds wydał kilka dni temu nową linię jądra? Nie ma problemu, jest już w repozytorium. Jedyny problem, jaki może z tego wynikać to to, że paczki mogą być krótko testowane. W szczególności czytałem dawno temu o aktualizacji kernela, która położyła ludziom maszynki, bo się przestały uruchamiać.

Gentoo

Jeśli w ogóle myślisz o Gentoo, to pewnie już jesteś bardziej świadomym użytkownikiem Linuksa i będziesz z niego zadowolony tylko dlatego, że będziesz miał okazję poznać Linuksa jeszcze bardziej dogłębnie. Uważam, że Gentoo to Linux From Scratch z managerem pakietów (no, i w stage3 dostaje się gotowy kompilator i takie bajery). I chyba jedynie w porównaniu do LFS (i być może Slackware) Gentoo będzie lepszym wyborem. Bo, powiedzmy sobie szczerze, kompilacja każdego programu ze źródeł przy każdej aktualizacji jest bardzo zasobochłonna, a zysk wydajnościowy jest naprawdę pomijalny.

Gdy zacząłem się interesować wsparciem dystrybucji dla bezpieczeństwa systemu, okazało się, że w Gentoo bardzo długo trwa zanim informacja o dziurawym pakiecie trafi do odpowiedniej systemowej bazy. Spowodowane jest to tym, w drzewie Portage musi się znaleźć nowszy pakiet, który zostanie przetestowany i uznany jako stabilny – dopóki tak się nie stanie, w GLSA nie pojawi się informacja. Prowadzi to do takich patologii, że w losowym miesiącu dopiero od jego połowy w GLSA zaczynają się pojawiać informacje o dziurawych pakietach.

Za to na plus jest na pewno mechanizm slotów, który pozwala na zainstalowanie np. trzech wersji kompilatora czy interpretera ulubionego języka i korzystanie z nich na raz oraz płynne przełączanie się aktualnej systemowej wersji.

A co na serwer?

Jak pewnie już zauważyłeś, moja działalność na desktopie przede wszystkim orbituje wokół systemów debianopochodnych. Jako system serwerowy jednak króluje u mnie czysty Debian. Czemu nie Ubuntu Server? Pewnie dlatego, że na serwerze nie potrzebuję wszystkiego tego, co więcej oferuje Ubuntu, czyli niewolnego oprogramowania oraz interface’u graficznego. Internet wskazuje, że Ubuntu Server LTS ma 5 lat wsparcia, gdy Debian ma gwarantowane około 2 lata, ale prawda jest taka, że wydanie oldstable trafia pod opiekę zespołu Debian LTS, który dostarcza krytyczne dla bezpieczeństwa aktualizacje przez kolejne 3 lata, więc de facto łączny czas wsparcia jest bardzo zbliżony. Co więcej, w obu przypadkach na końcu wsparcia danego wydania, aktualnie najnowszym będzie to z numerem o dwa wyższym, więc i tak nie należy oczekiwać bezpośredniej aktualizacji do najnowszego wydania, a trzeba będzie ją przeprowadzać stopniowo. Co naprawdę różni te dystrybucje to świeżość paczek – Debian, jak już zostanie zamrożony przed wydaniem, to potem jego podwydania (np. 9.2) niewiele zmieniają wersję zainstalowanych programów, tak Ubuntu nie ma z tym problemu i podwydania (np. 16.04.3) zmieniają trochę więcej. Oczywiście, nie pozostaje to bez wpływu na stabilność – po Debianie należy się spodziewać, że będzie stabilny jak skała, natomiast Ubuntu mogą się zdarzyć różne wpadki.

A coś poza Debianem?

Na pewno nie Gentoo. Nie nadaje się ono na produkcyjny serwer, który ktokolwiek będzie miał potem utrzymywać (no chyba że za karę). Z pozostałych systemów serwerowych miałem do czynienia z CentOSem. CentOS jest właściwie bezpłatnym Red Hatem bez wsparcia. Objawia się to m.in. tym, że podstawowe repozytoria systemu nie dostarczają metadanych „errata” informujących, czy dane aktualizacje są krytyczne dla bezpieczeństwa. W związku z tym przez dobrych kilka lat można (jakoby) nie zainstalować ani jednej aktualizacji bezpieczeństwa. Z drugiej strony CentOS przychodzi z domyślnie zainstalowanym i sensownie skonfigurowanym SELinuksem. Mam też podobną uwagę jak do Archa – dużo oprogramowania zostało wyrzucone z podstawowych repozytoriów do zewnętrznych (tutaj nazywa się to „epel”). Dużą zaletą Red Hata jest to, że jest wspierany m.in. przez producentów sprzętu podobnie jak Debian, czyli np. istnieją paczki dedykowane el6/el7, które działają również na CentOSie 7. Inną zaletą CentOSa jest abstrakcyjnie długie wsparcie pojedynczego wydania – około 10 lat. System (gdy już trochę okrzepnie) cechuje się dużą stabilnością, a podwydania podnoszą wersje pakietów bardziej niż te z Debiana. To powoduje, że po tych dziesięciu latach serwer nie będzie tak do tyłu za światem, jak jest Debian nawet po trzech latach od instalacji.

Czemu więc Debian, a nie CentOS? Dużą rolę na pewno odgrywa przyzwyczajenie. Ważnym czynnikiem również jest bezpieczeństwo systemu, które w CentOSie – niestety – jest na niskim poziomie przez brak informacji „errata”; za to Debian Security Team reaguje na zdarzenia szybko oraz da się łatwo sprawdzić, czy wymagają zainstalowania aktualizacje bezpieczeństwa. SELinux to może i przydatna funkcjonalność, ale pod wpływem goniących terminów do uruchomienia usługi prostsze staje się wpisanie „setenforce 0” zamiast szukania problemu w logach.

Mimo to nie uważam czasu spędzonego na instalacji, konfiguracji i administracji serwera z CentOS za stracony. Na pewno warto poznać „wroga”, a przy okazji zupełnie nowy ekosystem – RPM, yum, czy mnóstwa konfiguracji przeniesionej do katalogu sysconfig. Pozwala to też nabrać dystansu do ulubionego systemu i spojrzeć z perspektywy „inne dystrybucje robią to lepiej, natomiast tamto sporo gorzej”.

A co do wirtualizacji?

Najdłuższą ciągłą przygodę z wirtualizacją miałem z projektem XEN. Pierwsze, co dostałem pod opiekę, był XEN zainstalowany na Debianie 6. Przeżyłem z nim kilka aktualizacji, ale ogólnie mówiąc – nie tykać póki działa (na szczęście najczęściej działał).

Drugim był XenServer od firmy Citrix, odkąd projekt został „uwolniony”. Sam XenServer bazuje na – wymienionym już wcześniej – CentOSie z wyłączonymi systemowymi repozytoriami i często bleeding edge hypervisorem. Obsługa z konsoli takiego serwera jest możliwa, jednak dużo wygodniejszym narzędziem do 99% zadań jest Windowsowy XenCenter. Dla porównania – dołożenie kolejnego interface’u sieciowego do maszyny wirtualnej często oznacza konieczność wykonania trzech poleceń z zestawu narzędzi (ang. toolstack) xe często jako parametr wymagających różnych UUIDów, podczas gdy w XenCenter temat załatwia jedno okienko dialogowe. Na wirtualizowanych systemach Windows można zainstalować narzędzia gościa (na Linuksach oczywiście też), które zwiększają integrację Dom0 z DomU (np. wyłączanie z przycisku w XenCenter może wysłać sygnał wyłączania do maszyny wirtualnej zamiast od razu ubić proces qemu) oraz zmieniają niektóre urządzenia z w pełni wirtualizowanych na parawirtualizowane, na czym na pewno zyskuje wydajność całego serwera. Migracja maszyn wirtualnych (między identycznymi sprzętami) działa bajecznie łatwo i przyjemnie – przeciągnij i upuść. Nawet mimo bycia wersją darmową, XenServer otrzymuje aktualizacje od Citrixa. Jedynym minusem może być to, że podniesienie wersji systemu jest bardzo zbliżone do czystej instalacji od zera i nie zachowuje żadnych danych ani ustawień na Dom0, więc instalację snmpd/nrpe i pluginów trzeba wykonywać po każdej aktualizacji.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *