Zmiana nazw interfejsów sieciowych w Arch Linux

„Jest po prostu fajny, ponieważ uruchamia się o 3-4 sekundy szybciej”.
W rzeczywistości tak nie jest, w rzeczywistości główny programista systemd wyraźnie wyjaśnia w e-mailu od swojego ML, że nigdy nie myśleli o systemd jako o szybkim systemie startowym, że jest to tylko konsekwencja działania systemd – co jest naprawdę soczyste myślenie o tym, co można by osiągnąć, gdyby zdecydowali się zoptymalizować systemd, aby był szybszy…

„Przewaga systemd nad sysvinit/openrc lub upstart nie polega na tym, że jest świetny”
W odniesieniu do SysV init, przewaga jest OGROMNA w porównaniu do Upstart, nie tak bardzo.
SysVinit to catramine, wózek obok Porsche.
Chociaż SysVinit spełniał swoje zadanie przez wiele lat, rzeczywistość jest taka, że ​​ukryte ograniczenia oprogramowania stworzonego, przemyślanego i zaprojektowanego wiele lat temu i na ten moment stają się coraz bardziej zauważalne.
Niektóre problemy z SysV, oprócz wolnego czasu uruchamiania, to wyścigi, które zwykle występują w różnych środowiskach, jego struktura aktywacji i dezaktywacji demonów oraz złożoność dodawania nowych aplikacji i demonów do tej struktury bez przerywania sekwencji. początek.

systemd rozwiązuje to wszystko w czysty, praktyczny, ustandaryzowany i dobrze udokumentowany sposób – w SysV generalnie rzecz biorąc, każda dystrybucja implementuje to tak, jak chce.

Nie wiem zbyt wiele o Upstart poza jego plikami konfiguracyjnymi, które są naprawdę STRASZNE, jest chiński, edytowanie ich jest torturą i bardzo łatwo jest popełnić błąd, jeśli nie jesteś canchero i narobisz bałaganu.
Z drugiej strony Upstart wydaje się być naprawdę wydajny, ponieważ najnowsze wersje Ubuntu na moim komputerze uruchamiały się i wyłączały niemal natychmiast - cudownie.
Jednak gdy Poettering został zapytany, czy sysmted jest naprawdę potrzebny i czy nie przeanalizowali innych opcji, takich jak Upstart, odpowiedział, że tak, przeanalizowali je, że jest wiele rzeczy, które im się podobają i że w rzeczywistości planowano wdrożenie systemd, ale według nich baza strukturalna Upstart nie była dobra i że jest bardzo prawdopodobne, że w przyszłości będą mieli z niej problemy.

Trzeba pamiętać, że systemd narodził się z inicjatywy firmy Red Hat z dwóch ważnych powodów:
1. Ze względu na _ogromne_ doświadczenie, jakie firma ma w tysiącach wdrożeń, doszli do wniosku, że muszą dokonać pewnych fundamentalnych zmian w swoim systemie, aby spełniał ich wymagania, zmian, które logicznie denerwują niejednego weterana – jak każda głęboka zmiana.
2. Nikomu nie jest tajemnicą, że Red Hat stara się być Red Hatem, a nie GNU+Linux.

Poza arabeskami i innymi zakłóceniami, faktem jest, że systemd jest coraz częściej adoptowany przez społeczność GNU+Linux i jest to z konieczności dobre z kilku powodów:
1. rozwój jest przyspieszony, dzięki czemu można uzyskać lepszy produkt w krótszym czasie
2. uwzględnienie potrzeb różnych dystrybucji i współpraca głównych programistów tych dystrybucji z systemd oraz interakcja z programistami innych dystrybucji w celu omówienia poprawek i funkcji jest nieskończenie łatwiej uzyskać produkt wysokiej jakości
3. Jest niezależny od dystrybucji, w której jest zaimplementowany (bardzo ważne!) i skonsolidowany jako standard (podobnie jak POSIX), coś, czego administrator musi pracować w heterogenicznych środowiskach składających się z różnych dystrybucji, ale którzy dzielą base z pewnością doceni podobny system.
$ systemctl będzie działać tak samo w Fedorze jak openSUSE, Arch, Chakra, Red Hat, Kali Linux lub każda inna dystrybucja, która używa systemd i to jest świetne.
4. Posiadanie dużej liczby odpowiednich osób pracujących na tym samym PID1, którego używa sama dystrybucja, znacznie ułatwia pracę samych programistów podczas rozwiązywania problemów lub szukania pomocy lub pomysłów, jak zaimplementować tę lub inną funkcję.
5. Ponieważ systemd jest projektem otwartym i - co bardzo ważne - interdyscyplinarnym, wskaźnik adopcji i doskonalenia projektu jest jednym z najwyższych wśród projektów FLOSS.
Na przykład, gdy opiekun pakietu dowolnej dystrybucji, który polega na uruchamianiu demonów przy starcie, przedstawia swoją wersję usługi na systemowej liście mailingowej z prośbą o uwagi i sugestie, zdarza się, że po ogólnej współpracy udaje mu się w najlepszy możliwy sposób wskazać ten, z którego korzysta nie tylko programista, który otworzył motyw, ale także wysłał UPSTREAM do twórców samej aplikacji, aby zdecydowali, czy chcą, aby ta usługa była częścią własny pakiet i dzięki temu robią to w 100% zgodne z systememd OOTB.
6. systemd ma setki nowych funkcji, które znacznie ułatwiają i usprawniają administrowanie systemami, którymi zarządza. Na przykład odpowiada za zarządzanie modułem PAM dla menedżerów logowania, zarządzanie zdalnymi połączeniami z systemem, ładowanie usług na żądanie przez nasłuchiwanie na gniazdach zamiast uśpienia demona w pamięci i kradzieży procesora i pamięci w oczekiwaniu na aktywację, niezawodne zarządzanie interfejsami sieciowymi i urządzeniami podłączonymi do systemu… to naprawdę potwór, ogromny Lewiatan, ale w przeciwieństwie do innych systemów tej wielkości działa zwinnie, szybko i bardzo płynnie i myślę, że jedyny. systemd (myślę, że w krótkim czasie będzie zarządzać całym systemem) jest to, że od samego początku ma być wydajny, modułowy i skalowalny.

Najbardziej cierpię z powodu używania systemd, ponieważ muszę ponownie nauczyć się wszystkiego, czego do tej pory używałem do zarządzania moją maszyną.
Zrozumiałe jest, że niektórzy prehistorycy, przyzwyczajeni do stosowania określonej metodologii przez wiele lat, opierają się takiej zmianie… ale hej! To jest informatyka, tutaj jedyne co się nie zmienia to to, że zmiana jest ciągła 😉

Pozdrowienia.