SystemD, pomimo wielu zalet spotyka się ze znaczym oporem wśród developerów jak i użytkowników wielu dystrybucji GNU/Linux. Problem jest na tyle poważny, że developerzy zaczynają masowo rezygnować z współtworzenia dystrybucji, choć moim zdaniem te reakcje są sporo przesadzone, a zmiana wychodzi jedynie wszystkim na dobre.
Jedną z najczęściej wymienianych wad jest brak podążania za nieformalnym standardem KISS. Według mnie jest to bzdurą, gdyż pomimo swojej złożoności za każdą jego funkcję odpowiadają osobne demony, które jednak są od początku przystosowane do wzajemnej współpracy. Podstawą dla wszystkiego jest demon o nazwie systemd, odpowiada za rozruch systemu, uruchomienie reszty demonów, dbanie o zadania wykonywane cyklicznie oraz komunikację pomiędzy resztą demonów wchodzących w skład pakietu. Do komunikacji używa znanego chyba wszystkim bardziej zaawansowanym użytkownikom protokołu DBUS. Używanie tego przez proces tak znaczący dla systemu budzi kontrowersje, jednak bezpieczeństwo jest tu na bardzo wysokim poziomie. Kontrolę dostępu regulują zarówno prawa do samego pliku unix socket, jak i reguły PolicyKita, tak więc naruszenie bezpieczeństwa całości musiałoby się wiązać z poważną luką bezpieczeństwa całego systemu, przeważnie przez nieautoryzowany dostęp do konta administracyjnego, a tu już żadne zabezpieczenia nie pomogą.
Wracając do reguły KISS, myślę, że nie ma tu odstępstw, mamy osobny demon bazowy, osobne usługi od zarządzania sesjami użytkowników, konfiguracji sieci, obsługi urządzeń, montowania systemów plików, dziennika systemowego czy nawet zarządzania i synchronizacji zegara systemowego. Całość bardzo ładnie współpracująca ze sobą, potrafiąca zareagować na odcięcie od sieci tymczasowym wstrzymaniem synchronizacji zegara czy odmontowaniem sieciowych systemów plików. Przy okazji są to rozwiązania cały czas współpracujące z dobrze znanymi rozwiązaniami jak udev czy PAM.
Kolejną wymienianą wadą jest journald — zastępujący syslog demon dziennika systemowego, przetrzymujący go w formie binarnej. Pomimo krytyki ma wiele zalet, od wygodnego narzędzia filtrującego logi, przez ich szyfrowanie, kompresję, obsługę wielu maszyn, na współpracy ze standardowym rsyslogd kończąc. I Pomimo wszechobecnie panującej opinii ten fragment, jak i każdy inny może być całkowicie wyłączony jeśli ktoś chce nadal używać jedynie sysloga. To samo jest jeśli chodzi o prace cykliczne, gdzie timery można zastąpić przez którąś z implementacji crona.
Poważną zaletą z punktu widzenia twórców dystrybucji jest zmniejszenie ilości pracy związanej z tym fragmentem systemu. Do tej pory każda dystrybucja używająca SysV Init borykała się z tworzeniem i zarządzaniem masy skryptów startowych i konfiguracyjnych tworząc kompletny interfejs na ten jakże prosty init. Wszelkie miały ogromną wadę — czas wykonywania prac przez nagminne używanie powłoki busybox/ash/bash/dash i podprogramów, grepowanie wyników pracy — słowem ogólny zamęt i trudność w komunikacji między poszczególnymi fragmentami. Wszystko to było także bardzo pracochłonne. Dodatkowo twórcy mają od razu dostęp do świetnie przygotowanych kontrolerów sieci, gotowy system prostych kontenerów w stylu LXC i każdego innego potrzebnego im narzędzia — nie muszą tworzyć ich od zera, bądź borykać się z dopasowaniem jakiegoś istniejącego rozwiązania pod swoją dystrybucję.
Z punktu widzenia użytownika/administratora natomiast zaletą jest posiadanie znanego środowiska jako podstawy, niezależnie od dystrybucji której aktualnie używa. Dodatkowo może liczyć na zunifikowane programy, nawet graficzne do konfiguracji integralnej części systemu, wpływającej na praktycznie każdy aspekt jego pracy. Jest to ogromny postęp który pozwoli mniej obytym użytkownikom na wygodną pracę, bez narzekania, że na windowsie dało się wyklikać a tu trzeba uruchomić to straszne czarne okienko z literkami.
Tak więc czy na pewno warto odrzucać zmiany tylko dlatego, że przywykliśmy do starych rozwiązań? Warto borykać się z naleciałościami powstałymi przez dekady nie zyskując przez to nic poza coraz większym nakładem pracy w opiekę nad całością, podczas gdy istnieje rozwiązanie dające nam wszystko od ręki, ale przy okazji pozwalające na wymianę każdej nielubianej części na inną? I jaki jest sens wynajdywania koła na nowo przez każdą dystrybucję, gdy jest ono gotowe, a przekierowując swoje siły na jego rozwój można zyskać narzędzie uniwersalne i odpowiadające wszystkim?
Nie będę tutaj nikomu wchodził w kompetencje, ale reakcje panów pokroju developerów Debiana (oby spłonął) masowo rezygnujących z rozwijania tego projektu, czy wręcz oburzonych decyzją o przejściu na SystemD są delikatnie przesadzone, a zatwardziałość w utrzymywaniu staroci tylko dlatego, że się je zna od podszewki świadczy tylko o ułomności takich osób i braku umiejętności adaptacji. Wstyd.