Z każdym dniem nasze komputery stają się coraz ważniejszą częścią naszego życia; każdy problem z nimi wpływa na nasz nastrój, humor, haha. Oczywiście użytkownicy Windowsa są bardziej podatni na ataki paniki: wirusy ( niech żyje Linux! ), defragmentacja dysku twardego, znalezienie i instalacja Clean Mastera na PC ( chociaż tutaj, w Linuksie, również musimy oczyścić system; BleachBit jest jedną z preferowanych alternatyw ). Ostatnio niektórzy użytkownicy Linuksa doświadczają pewnego rodzaju bólu głowy zwanego systemd.
Wracając do tematu, przeczytałem ciekawy artykuł o systemd , który ostatnio staje się niezwykle popularny.
Systemd , który niektórzy uważają ( i użyję słów znajomego ) za „jeden pierścień, który rządzi wszystkimi ”... dla innych, którzy są po prostu obojętni; dopóki komputer działa poprawnie, nie obchodzi ich, czy init wykonuje X czy Y, ani czy używany jest systemd. A ja, cóż... powiedzmy, że wolę init; uważam go za prostszy.
Artykuł zostawiam tutaj:
Zanim zacznę, muszę powiedzieć, że bardzo nie podoba mi się decyzja o zmianach w Debianie, ale nie mam zamiaru porzucać mojej ukochanej spirali. Staram się po prostu zapewnić, że jeśli mamy dyskutować na jakiś temat, robimy to jak najlepiej przygotowani, mimo że sam nie uważam się za zwolennika systemd. Aby rozwiać wszelkie wątpliwości dotyczące systemd, posłużę się stroną internetową, na której programiści dzielą się swoimi poglądami . Na tę stronę zwróciłem uwagę dzięki koledze, który wydaje się być zwolennikiem systemd, mimo że nie jest użytkownikiem Debiana. Mając to na uwadze, myślę, że mogę spróbować rozwiać wszelkie wątpliwości dotyczące systemd.
systemd jest oparty na systemie binarnym
Być może jest to jeden z aspektów, który najbardziej nas szokuje, jeśli wszystko opiera się na plikach binarnych, w jaki sposób monitorujemy rzeczy, które zwykle robimy za pomocą dzienników? Nie mam pojęcia, jak narodził się ten mit, ale nie jest to do końca prawdą.
systemd jest konfigurowany prawie wyłącznie za pomocą zwykłych plików tekstowych. Niektóre ustawienia, które można również zmienić za pomocą wiersza poleceń jądra i zmiennych środowiskowych. W twojej konfiguracji nie ma nic binarnego (nawet XML). Po prostu prosty, nieskomplikowany i łatwy do odczytania plik tekstowy.
Ta rzecz jest monolityczna i kontroluje wszystko
Zanim trafiłem na w / w serwis, przyznaję, że sam tak myślałem, ale po przeczytaniu tego, co mówią jego twórcy, moja opinia coś zmieniła ...
Kompilacja systemd z włączonymi wszystkimi opcjami konfiguracji spowoduje utworzenie 69 oddzielnych plików binarnych . Pliki te realizują różne zadania i są starannie rozdzielone z kilku powodów. Na przykład systemd został zaprojektowany z myślą o bezpieczeństwie; dlatego większość demonów działa z minimalnymi uprawnieniami (wykorzystując na przykład możliwości jądra) i odpowiada tylko za ściśle określone zadania, minimalizując ich obszar bezpieczeństwa i wpływ na bezpieczeństwo. Ponadto systemd bardziej niż jakiekolwiek wcześniejsze rozwiązanie paralelizuje rozruch. Ta „paralelizacja” jest realizowana poprzez równoległe uruchamianie wielu procesów . Widać zatem wyraźnie, że systemd jest bardzo dobrze podzielony na wiele plików binarnych, a co za tym idzie, procesów. W rzeczywistości wiele z tych plików binarnych jest tak dobrze rozdzielonych, że są bardzo przydatne również poza systemem systemd.
Pakiet zawierający 69 pojedynczych plików binarnych trudno nazwać monolitycznym. Różnica w stosunku do poprzednich rozwiązań polega jednak na tym, że dostarczamy więcej komponentów w jednym pliku tarball i przechowujemy je połączone w jednym repozytorium z ujednoliconym cyklem wydań.
To nie wygląda jak Unix
Z pewnością jest w tym trochę prawdy. Pliki źródłowe systemd nie zawierają ani jednej linii kodu z oryginalnych linii systemu UNIX. Jednak inspiracja wywodzi się z systemu UNIX, a zatem w systemd jest dużo UNIX. Przykładem może być idea systemu UNIX „wszystko jest plikiem”, co znajduje odzwierciedlenie w tym, że w systemd wszystkie usługi są ujawniane w czasie wykonywania w systemie plików jądra, cgroupfs. Tak więc jedną z oryginalnych cech systemu UNIX była obsługa wielu stanowisk, oparta na wbudowanej obsłudze terminala. Wraz z systememd ponownie wprowadziliśmy natywną obsługę wielu stanowisk, ale tym razem z pełną obsługą dzisiejszego sprzętu, obejmującą grafikę, myszy, dźwięk, kamery internetowe i nie tylko. W rzeczywistości zaprojektowanie systemd jako zestawu zintegrowanych narzędzi, z których każde ma swoje indywidualne przeznaczenie, ale używane razem stanowią więcej niż sumę części, co jest mniej więcej podstawą filozofii UNIX. Więc sposób, w jaki nasz projekt jest obsługiwany (tj. Utrzymywanie większości jądra systemu operacyjnego w jednym repozytorium git) jest znacznie bliższy modelowi BSD (który jest prawdziwym UNIXem, w przeciwieństwie do Linuksa), aby załatwić sprawy (gdzie większość podstawowy system operacyjny jest przechowywany w jednym repozytorium CVS / SVN), co nigdy nie miało miejsca w Linuksie.
Ostatecznie pytanie, czy coś jest UNIXem, czy nie, ma bardzo małe znaczenie. Będąc technicznie doskonałym, rzadko występuje w systemie UNIX. Dla nas UNIX jest ważnym czynnikiem (w rzeczywistości największym), ale mamy też inne wpływy. Stąd w niektórych obszarach systemd będzie bardzo UNIXowy, aw innych trochę mniej.
To bardzo złożone ...
Z pewnością jest w tym trochę prawdy. Współczesne komputery to złożone bestie, a system operacyjny, który na nich działa, oczywiście też taki będzie, więc muszą być złożone. Jednak systemd z pewnością nie jest bardziej złożony niż poprzednie implementacje tych samych komponentów. Jest prostszy i ma mniejszą nadmiarowość. Z drugiej strony, zbudowanie prostego systemu operacyjnego opartego na systemd będzie wymagało znacznie mniej pakietów niż tradycyjne zastosowania Linuksa. Mniejsza liczba pakietów ułatwia budowanie systemu, eliminuje współzależności i wiele różnych zachowań wszystkich zaangażowanych komponentów.
To nie pozwala mi używać skryptów powłoki
To całkowita nieprawda. Po prostu nie używamy ich w procesie rozruchu, ponieważ uważamy, że nie są najlepszym narzędziem do tego konkretnego celu, ale to nie znaczy, że systemd był z nimi niezgodny. Można łatwo uruchamiać skrypty powłoki jako usługi lub demony systemd; można uruchamiać skrypty napisane w dowolnym języku jako usługi systemd, ponieważ systemd w najmniejszym stopniu nie przejmuje się zawartością pliku wykonywalnego. Co więcej, szeroko wykorzystujemy skrypty powłoki do własnych celów: do instalowania, kompilowania i testowania systemd. Można wklejać skrypty do wczesnego procesu uruchamiania, używać ich do normalnych usług, uruchamiać je podczas końcowego zamykania systemu – praktycznie nie ma żadnych ograniczeń.
W tym momencie przypuszczam, że niektóre z głównych przekonań mogły zostać wyjaśnione. Chociaż nie uważam się za zwolennika zmian i mam pewne zastrzeżenia co do idei „ jednego demona, który wszystkimi rządzi ”, myślę, że ostatecznie nikt nie odważy się powiedzieć, że to w ogóle nie działa. Znam nawet użytkowników, którzy zauważają, że z systemd „komputer działa szybciej”, ale to już temat na inną dyskusję. Na razie mogę jedynie zaprosić Was do dyskusji na temat systemu init, który wdrożyło wiele dystrybucji, choć najsilniejsze reakcje obserwujemy obecnie w społeczności Debiana, która z tego powodu stworzyła nawet nowy fork. To, czy Wam się to podoba, czy nie, to kwestia osobista; ja ze swojej strony chcę po prostu dołożyć swoją cegiełkę do odczarowania systemu systemd, który ostatecznie pojawi się w Jessie, kolejnej stabilnej wersji Debiana.
Widziałem artykuł na GUTL (który z kolei został zaczerpnięty od DesdeAbreus )
Obecny system?
Należę do tych, którzy nie czytają zbyt wiele wiadomości, gdy coś budzi tak duże kontrowersje, wolę pozostać przy bardziej technicznych szczegółach. Rzecz w tym, że…. Czasami mam wrażenie, że pewne tematy przestają być czysto techniczną dyskusją czy debatą, a stają się jedną z tych plotek o showbiznesie
Najpierw otwarta wypowiedź użytkownika na temat systemd zwana systemd VS intelligence , potem Linus Torvalds stwierdzający, że systemd nie jest taki zły , jak go przedstawiają ( i ma rację ), rozwidlenie zwane uselessd ... brak komentarzy... i w skrócie, na koniec Devuan.
Nie powiem, czy jest tak źle, jak mówią, czy mniej źle, czy gorzej. System działa u mnie dobrze, jednak osobiście wolałbym init, ponieważ podoba mi się jego sposób organizacji różnych rzeczy (na przykład logów). Ale hej, skoro systemd ma być nazywany koniem wyścigowym i musi zastąpić init ( czyżby był naszym koniem roboczym, robiąc wszystko, ale powoli? ), cóż... dopóki zmiana nie będzie zbyt drastyczna, użytkownicy będą mogli się bez problemu przystosować, a system będzie działał lepiej (tak, lepiej, może to mi nie wystarczy!), to witajcie! 😉