Preimenovanje mrežnih sučelja u Arch Linuxu

"To je samo u modi, jer počinje za 3 ili 4 sekunde brže."
Zapravo nije tako, zapravo glavni programer systemda izričito objašnjava u e-poruci svog ML-a da nikada nisu sistemd smatrali sustavom za brzi start, da je to samo posljedica rada systemda - što je stvarno sočno razmišljajući o tome što bi se moglo postići ako odluče optimizirati sustav kako bi bio brži ...

"Prednost systemd-a u odnosu na sysvinit / openrc ili upstart nije u tome što je toliko velik"
U odnosu na SysV init prednost je VELIKA u odnosu na Upstart ne toliko.
SysVinit je catramina, kolica pored Porschea.
Iako je SysVinit svoju svrhu služio dugi niz godina, stvarnost je takva da su implicitna ograničenja softvera napravljena, smišljena i dizajnirana prije mnogo godina i za taj trenutak sve primjetnija.
Neki od problema sa SysV-om, pored sporog vremena pokretanja, su i uvjeti utrke koji se uglavnom javljaju u različitim okruženjima, njegova struktura za aktiviranje i deaktiviranje demona i koliko je složeno dodavanje novih aplikacija i demona u ovu strukturu bez prekida sekvence. Od početka.

systemd sve to rješava na čist, praktičan, standardiziran i dobro dokumentiran način - kada je u SysV-u općenito da ga svaka distribucija primjenjuje kako najviše voli.

O Upstartu ne znam puno više od njegovih konfiguracijskih datoteka, koje su strogo govoreći, Grozne, kineski je, mučiti ih je uređivanje i vrlo je lako pogriješiti ako niste ludi i napravite nered.
S druge strane, čini se da je Upstart doista učinkovit jer su se najnovije verzije Ubuntua na mom stroju pokrenule i gotovo trenutno ugasile - prekrasno.
Međutim, na pitanje Poetteringa trebaju li stvarno sistematizirati i ne analiziraju li druge opcije kao što je Upstart, odgovorio je da jesu, analizirali su ih, da ima mnogo stvari koje su im se svidjele i da je zapravo u planovima da implementirati u systemd, ali da prema njima strukturna baza Upstarta nije bila dobra i da je bilo vrlo moguće da će u budućnosti imati problema koji iz toga proizlaze.

Sjetite se da je systemd rođen iz Red Hat inicijative iz dva važna razloga:
1. Zbog _vastisima_ iskustva koje tvrtka ima u tisućama rasporeda, došli su do zaključka da trebaju napraviti određene temeljne promjene u svom sustavu kako bi udovoljili njihovim zahtjevima, promjene koje logično uznemiruju više od jednog veterana - kao i svi duboki promjene.
2. Nikome nije tajna da Red Hat nastoji biti Red Hat, a ne GNU + Linux.

Osim arabeski i drugih distrakcija, činjenica je da GNU + Linux zajednica sve više usvaja systemd, a to je nužno dobro iz nekoliko razloga:
1. razvoj je ubrzan pa se bolji proizvod može postići za manje vremena
2. Uključivanjem potreba različitih distribucija i suradnjom s glavnim programerima tih distribucija sa systemd-om i interakcijom s programerima iz drugih distribucija koji raspravljaju o zakrpama i značajkama, beskrajno je lakše postići kvalitetan proizvod
3. Agnostično je za distribuciju u kojoj se provodi (vrlo važno!) I konsolidirano je kao standard (kao što je i POSIX) nešto što će administrator koji mora raditi u heterogenim okruženjima sastavljenim od različitih distribucija, ali koji dijele bazu upravljanja, sigurno vrednuju sličan sustav.
$ systemctl će raditi isto na Fedori kao openSUSE ili Arch ili Chakra ili Red Hat ili Kali Linux ili bilo koja druga distribucija koja koristi systemd i to je sjajno.
4. Imati velik broj prikladnih ljudi koji rade na istom PID1 koji koristi i sam distro program, olakšava posao samim programerima pri rješavanju problema ili traženju pomoći ili ideja kako implementirati jednu ili drugu funkciju.
5. Budući da je systemd otvoren i vrlo važan interdisciplinarni projekt, stopa usvajanja i poboljšanja projekta čini ga jednim od najviših FLOSS projekata.
Na primjer, kada održavatelj paketa bilo koje distribucije, koji uključuje pokretanje demona na početku, predstavi svoju verziju usluge na systemd mailing listi tražeći komentare i prijedloge, događa se da je nakon opće suradnje moguće neka ta usluga na najbolji mogući način usmjeri onu koja ne koristi samo programera koji je otvorio temu, već šalje UPSTREAM programerima same aplikacije kako bi mogli odlučiti žele li tu uslugu učiniti dijelom svog vlastiti paket i s tim ga čine 100% kompatibilnim sa sistemom OOTB.
6. systemd ima stotine stotina novih značajki koje administraciju sustava kojima upravlja čine mnogo lakšim i glatkijim. Na primjer, zadužen je za upravljanje PAM modulom za upravitelje prijava, upravljanje udaljenim vezama na sustav, učitavanje usluga na zahtjev koje preslušavaju utičnice umjesto da ima uspavani demon u memoriji i krađu CPU-a i memorije koji čekaju da se aktiviraju, upravljanje na pouzdan način mrežna sučelja i uređaji priključeni u sustav ... to je stvarno čudovište, ogromni Levijatan, ali za razliku od ostalih sustava ove veličine djeluje agilno, brzo i vrlo glatko i mislim da je jedini razlog tome što je to tako je za VELIKI sustav kao što je systemd (mislite da će u kratkom vremenu upravljati cijelim sustavom) dizajniran da bude učinkovit, modularan i skalabilan od samog početka.

Osobito ono što najviše trpim od korištenja systemd-a je što moram ponovno naučiti sve ono što sam do sada koristio za upravljanje svojim strojem.
Razumljivo je da su se neke prapovijesti navikavale na određenu metodologiju dugi niz godina opirati se takvoj promjeni ... ali hej! Ovo je informatika, ovdje se jedino što se ne mijenja jest da je promjena kontinuirana 😉

Pozdrav.