systemd, choć ma już dziesięć lat, wciąż budzi kontrowersje wśród społeczności Linuksa. Mimo że jest szeroko stosowany w wielu popularnych dystrybucjach, opór wobec niego pozostaje silny.
Proces uruchamiania systemu Linux
Po włączeniu komputera jego sprzęt uruchamia się, a następnie, w zależności od używanego sektora rozruchowego, następuje wykonanie głównego rekordu rozruchowego (MBR) lub Zunifikowanego Rozszerzalnego Interfejsu Oprogramowania Układowego (UEFI). Ostatecznym krokiem tych procedur jest załadowanie Jądra Linux.
Jądro jest wczytywane do pamięci, a następnie dekompresowane i inicjalizowane. Utworzony zostaje tymczasowy system plików w pamięci RAM, zazwyczaj dzięki narzędziu znanemu jako initramfs lub initrd. Umożliwia to identyfikację i załadowanie niezbędnych sterowników, co z kolei pozwala na załadowanie systemu plików dla przestrzeni użytkownika oraz przygotowanie do stworzenia środowiska użytkownika.
Tworzeniem tego środowiska zajmuje się proces init, który jest pierwszym procesem uruchamianym przez jądro w przestrzeni użytkownika i ma identyfikator procesu (PID) równy 1. Wszystkie inne procesy są bezpośrednimi lub pośrednimi dziećmi procesu init.
Przed wprowadzeniem systemd, głównym mechanizmem init w systemie Linux był przerobiony plik Init Unix System V. Choć istniały inne opcje, Init System V był standardowym rozwiązaniem w wielu dystrybucjach pochodnych Berkeley Software Distribution (BSD). Ze względu na swoje korzenie w Uniksie System V, wielu ludzi uznaje go za „oficjalny sposób” na wykonanie inicjalizacji.
Proces init uruchamia wszystkie niezbędne demony oraz usługi, które zapewniają sprawne działanie systemu operacyjnego. Te demony zajmują się m.in. obsługą sieci, zarządzaniem sprzętem oraz wyświetlaniem ekranu startowego.
Wiele z tych procesów w tle kontynuuje działanie po ich uruchomieniu, rejestrując zdarzenia, monitorując zmiany sprzętowe oraz zarządzając logowaniem użytkowników. Dlatego system init ma również funkcje do zarządzania usługami.
Aby sprawdzić, jaki proces ma PID 1, można użyć polecenia ps z opcjami f (pełny format) oraz p (PID):
ps -fp 1
Widzimy, że proces z PID 1 to systemd. Uruchomienie tego samego polecenia w systemie Manjaro Linux pokazuje inny wynik, gdzie proces z PID 1 to /sbin/init. Szybka analiza tego pliku ujawnia, że jest to dowiązanie symboliczne do systemd:
ps -fp 1
ls -hl /sbin/init
Wykorzystując opcję ppid (identyfikator procesu nadrzędnego) w poleceniu ps, możemy zobaczyć, które procesy zostały uruchomione bezpośrednio przez systemd:
ps -f --ppid 1
Jak widać, lista jest dość obszerna.
Alternatywy dla systemd
Oto kilka przykładów takich projektów:
Upstart: Stworzony przez Canonical, był używany w Ubuntu 9.10, Red Hat, Red Hat Enterprise Linux (RHEL) 6, CentOS 6 oraz Fedora 9.
Runit: Działa na FreeBSD oraz innych pochodnych BSD, macOS i Solaris, a także na systemach Linux. Jest to domyślny system startowy w Void Linux.
s6-linux-init: Ta alternatywa dla Systemu V jest ściśle zgodna z filozofią Uniksa, która kładzie nacisk na realizację jednej funkcji dobrze.
Istnieje wiele innych systemów, które różnią się funkcjonalnością oraz wyglądem. Mimo to, żaden z nich nie wzbudził takiej kontrowersji jak systemd.
Wprowadzenie systemd
systemd został zaprezentowany w 2010 roku, a jego implementacja miała miejsce w Fedorze w 2011 roku. Od tego czasu wiele dystrybucji przyjęło ten system. Został opracowany przez Lennarta Poetteringa oraz Kaya Sieversa, inżynierów oprogramowania pracujących dla Red Hat.
systemd to znacznie więcej niż tylko mechanizm inicjalizacji. To kompleksowy zestaw około 70 plików binarnych, które zarządzają nie tylko inicjalizacją systemu, ale także demonami, usługami, logowaniem i innymi funkcjami, które wcześniej były obsługiwane przez dedykowane moduły w systemie Linux. Wiele z tych funkcji nie dotyczy inicjalizacji.
Niektóre z demonów dostępnych w systemd to:
- systemd-udevd: zarządza urządzeniami fizycznymi.
- systemd-logind: odpowiada za logowania użytkowników.
- systemd-resolved: zapewnia rozpoznawanie nazw sieciowych dla lokalnych aplikacji.
- systemd-networkd: zarządza i wykrywa urządzenia sieciowe oraz ich konfigurację.
- systemd-tmpfiles: tworzy, usuwa i zarządza tymczasowymi plikami i katalogami.
- systemd-localed: odpowiada za ustawienia regionalne systemu.
- systemd-machined: monitoruje maszyny wirtualne oraz kontenery.
- systemd-nspawn: pozwala na uruchamianie poleceń w lekkim kontenerze przestrzeni nazw, co daje funkcjonalność podobną do chroot.
To tylko część jego funkcji, która ilustruje, jak systemd wykracza poza klasyczne funkcje inicjalizacji, co według jego przeciwników stanowi przykład „pełzania zakresu”.
„Jest za duży. To za dużo”
Przeciwnicy systemd wskazują na jego niezwykle rozbudowaną funkcjonalność, która obejmuje wiele aspektów, które wcześniej istniały w Linuksie. Chociaż niektóre z tych funkcji mogłyby potrzebować modernizacji, ich połączenie w jednym systemie inicjalizacji budzi kontrowersje pod względem architektonicznym.
systemd został określony jako pojedynczy punkt awarii zbyt wielu istotnych funkcji, co może budzić obawy. Warto zauważyć, że jego podejście odbiega od filozofii Uniksa, która promuje tworzenie małych narzędzi współpracujących ze sobą, zamiast dużych aplikacji, które wszystko robią samodzielnie. Choć systemd nie jest ściśle monolityczny (składa się z wielu plików binarnych), to jednak gromadzi wiele narzędzi i poleceń pod jednym dachem.
Wielkość systemd jest znacząca. Aby zobaczyć jego skalę, porównaliśmy liczbę linii kodu w jądrze 5.6.15 oraz w głównym repozytorium systemd na GitHubie.
To porównanie, choć dość surowe, daje pewien wgląd: liczono wszystkie linie tekstu, w tym komentarze i dokumentację. Jądro zawiera niemal 28 milionów (dokładnie 27 784 340) linii tekstu, podczas gdy systemd ma 1 349 969, co stanowi prawie 1,4 miliona. W naszych obliczeniach systemd zajmuje około 5% rozmiaru jądra, co jest dość zaskakujące!
Na przykład nowoczesna implementacja init Systemu V w dystrybucji Arch Linux ma jedynie 1721 linii.
Poettering wydaje się nie przejmować standardami IEEE ani POSIX. W rzeczywistości, jak sam przyznał, namawia programistów do ignorowania POSIX:
„Zdobądź kopię Linux Programming Interface, zignoruj wszystko, co mówi o zgodności z POSIX i zhakuj swoje niesamowite oprogramowanie Linux. To przynosi ulgę!”
Niektórzy krytycy twierdzą, że systemd jest projektem Red Hat, który korzysta tylko na tym, że jest implementowany w szerszym świecie Linuksa. Tak, jego rozwój miał miejsce w Red Hat i jest przez tę firmę zarządzany, jednak z 1321 współpracowników, jedynie część z nich pracuje dla Red Hat.
Jakie korzyści odnosi więc Red Hat?
Jim Whitehurst, prezydent IBM, a także były prezydent Red Hat, powiedział:
„Red Hat rozważył wiele dostępnych opcji, w tym Upstart Canonical dla Red Hat Enterprise Linux 6. Ostatecznie wybraliśmy systemd, ponieważ oferuje najlepszą architekturę, która zapewnia rozszerzalność, prostotę, skalowalność oraz dobrze zdefiniowane interfejsy, które pozwalają rozwiązywać problemy, z jakimi się borykamy i przewidywać przyszłe wyzwania.”
Whitehurst dodał także, że widzą korzyści w systemach wbudowanych. Red Hat współpracuje z „największymi światowymi dostawcami rozwiązań wbudowanych, zwłaszcza w telekomunikacji i branży motoryzacyjnej, gdzie stabilność i niezawodność mają kluczowe znaczenie.”
Te techniczne powody wydają się uzasadnione. Zrozumiałe, że firma chce zapewnić sobie niezawodność, ale czy inne dystrybucje powinny podążać za tym przykładem?
Picie Kool-Aid?
Niektórzy krytycy systemd twierdzą, że dystrybucje oraz użytkownicy po prostu bezrefleksyjnie podążają za Red Hat i przyjmują ten system.
Jednak określenie „picie Kool-Aid” nie jest do końca trafne. Termin ten powstał po tragicznym wydarzeniu w 1978 roku, kiedy Jim Jones, lider sekty, zmusił swoich zwolenników do popełnienia samobójstwa przez wypicie napoju z dodatkiem cyjanku. W rzeczywistości grupa piła Flavor Aid, ale od tego czasu Kool-Aid stał się terminem pejoratywnym.
Co więcej, dystrybucje Linuksa nie podążają ślepo za Red Hat; po długich dyskusjach decydują się na implementację systemd. Na przykład w 2014 roku społeczność Debiana głosowała na przyjęcie systemd jako domyślnego systemu init, ale nadal obsługują alternatywy.
Debian jest istotnym przykładem, ponieważ nie wywodzi się z Red Hat, Fedory ani CentOS. W Debianie nie ma wpływów z Red Hat, a społeczność ma pełną kontrolę nad swoimi decyzjami.
Decyzje podejmowane przez społeczność Debiana mają dalekosiężne konsekwencje. Są one także dokładnie omawiane i głosowane z zastosowaniem metody głosowania Condorcet. Społeczność nie podejmuje takich decyzji lekko.
W grudniu 2019 roku odbyło się kolejne głosowanie, które skupiło się na systemd i badaniu alternatyw. W przeciwieństwie do ślepego naśladowania, jest to rzeczywisty przykład demokratycznych procesów i wolności wyboru.
Ograniczenia wyboru
Ogólnie rzecz biorąc, nie masz możliwości wyboru, czy chcesz używać systemd w konkretnej dystrybucji Linuksa. To dystrybucje decydują, czy go przyjąć, a ty możesz wybrać swoją preferowaną dystrybucję. Może się zdarzyć, że dystrybucja, którą lubisz, przeszła na systemd, co może być irytujące, jak zmiana ulubionego artysty muzycznego.
Osoby korzystające z Debiana, Fedory, CentOS, Ubuntu, Arch, Solus oraz openSUSE, którzy są przeciwni wprowadzeniu systemd, mogą czuć, że nie mogą korzystać z wybranej przez siebie dystrybucji. Jeśli są wystarczająco zaniepokojeni decyzjami architektonicznymi, mogą uznać, że dalsze korzystanie z tej dystrybucji jest nie do przyjęcia.
Oczywiście istnieje spektrum. Z jednej strony są osoby, które nie rozumieją problemów (a nawet ich nie obchodzą), a z drugiej zapaleni przeciwnicy. W środku znajdują się ci, którzy nie lubią zmian, ale nie są na tyle zaniepokojeni, by przestać korzystać z danej dystrybucji. Jakie mają możliwości osoby, które nie mogą pozostać w swojej preferowanej dystrybucji ze względu na wprowadzenie systemd?
Niestety, nie jest to tak proste, jak po prostu zainstalowanie dowolnego systemu init, który chcesz. Nie każdy ma odpowiednie umiejętności techniczne, a wiele aplikacji i środowisk graficznych, takich jak GNOME, ma zależności od systemd.
Czy myślisz o przejściu do innej dystrybucji? Niektóre dystrybucje, takie jak Devuan, zostały stworzone jako rozwidlenia (forki) dystrybucji, które przyjęły systemd. Korzystanie z Devuana powinno być podobne do korzystania z dystrybucji macierzystej, jednak nie dotyczy to wszystkich rozwidleń, np. przechodząc z Fedory do AntiX, Gentoo lub Slackware, doświadczysz zupełnie innego środowiska.
Bez przyszłości?
Doceniam, co systemd wnosi (proste i ustandaryzowane mechanizmy zarządzania procesami). Nie do końca rozumiem niektóre jego aspekty (np. binarne logi), a część z działań, jak przebudowa folderów domowych, wydaje się niepotrzebna.
Dystrybucje takie jak Debian prowadzą mądre działania, badając alternatywy, aby pozostawić sobie otwarte opcje. Jednak wydaje się, że systemd będzie obecny w dłuższym okresie.
Jeśli zarządzasz systemami Linux dla innych, warto znać zarówno systemd, jak i Init System V. W ten sposób, niezależnie od napotkanych trudności, będziesz w stanie wypełniać swoje obowiązki.
Jeśli używasz systemu Linux w swoim domu, wybierz dystrybucję, która odpowiada zarówno twoim wymaganiom technicznym, jak i ideologii Linuksa.
newsblog.pl
Maciej – redaktor, pasjonat technologii i samozwańczy pogromca błędów w systemie Windows. Zna Linuxa lepiej niż własną lodówkę, a kawa to jego główne źródło zasilania. Pisze, testuje, naprawia – i czasem nawet wyłącza i włącza ponownie. W wolnych chwilach udaje, że odpoczywa, ale i tak kończy z laptopem na kolanach.