În fiecare zi, computerele noastre devin o parte din ce în ce mai importantă a vieții noastre; dacă au vreo problemă, ne afectează starea de spirit, umorul, haha. Desigur, utilizatorii de Windows sunt mai predispuși la atacuri de panică: viruși ( trăiască Linux! ), defragmentarea hard disk-ului, găsirea și instalarea Clean Master pentru PC ( deși aici, în Linux, trebuie să curățăm și sistemul; BleachBit este una dintre alternativele preferate ). Recent, unii utilizatori de Linux au avut o anumită bătaie de cap numită systemd.
În fine, ca să trec la subiect, am citit un articol interesant despre systemd , care pare să fie la mare căutare în zilele noastre.
Systemd , pe care unii îl consideră ( și voi folosi cuvintele unui prieten ) „un singur inel care să-i conducă pe toți ”... pentru alții, care sunt pur și simplu indiferenți; atâta timp cât computerul funcționează corect, nu le pasă dacă init face X sau Y sau dacă se folosește systemd. Cât despre mine, ei bine... să spunem doar că îl prefer pe init; mi se pare mai simplu.
Las articolul aici:
Înainte de a începe, trebuie să spun că nu-mi place deloc decizia de a schimba lucrurile în Debian, dar nu am nicio intenție să abandonez spirala mea iubită. Încerc pur și simplu să mă asigur că, dacă vom discuta un subiect, o vom face cât mai pregătiți posibil, chiar dacă eu însumi nu mă consider pro-systemd. Pentru a demitiza systemd, mă voi baza pe un site web unde dezvoltatorii își împărtășesc perspectivele , care mi-a atras atenția prin intermediul unui coleg care pare a fi pro-systemd, chiar dacă nu este utilizator Debian. Acestea fiind spuse, cred că pot continua să încerc să demitizez ceea ce se spune despre systemd.
systemd este bazat pe binar
Poate că acesta este unul dintre aspectele care ne șochează cel mai mult, dacă totul se bazează pe binar, cum monitorizăm lucrurile pe care le facem de obicei prin jurnale? Nu am nicio idee despre cum s-a născut acest mit, dar nu este absolut adevărat.
systemd este configurat aproape exclusiv prin fișiere text simplu. Unele setări care pot fi, de asemenea, modificate cu linia de comandă a nucleului și prin intermediul variabilelor de mediu. Nu există nimic binar în configurația dvs. (nici măcar XML). Doar un fișier text simplu, direct și ușor de citit.
Acest lucru este monolitic și controlează totul
Înainte de a ajunge pe site-ul menționat mai sus, mărturisesc că am gândit eu așa, dar după ce am citit ce spun dezvoltatorii săi, părerea mea a schimbat ceva ...
Dacă construiți systemd cu toate opțiunile de configurare activate, veți construi 69 de fișiere binare individuale . Aceste fișiere binare deservesc sarcini diferite și sunt separate cu atenție din mai multe motive. De exemplu, systemd a fost proiectat având în vedere securitatea; prin urmare, majoritatea daemonilor rulează cu privilegii minime (folosind capabilitățile kernelului, de exemplu) și sunt responsabili doar pentru sarcini foarte specifice, minimizând suprafața și impactul lor asupra securității. De asemenea, systemd paralelizează bootarea mai mult decât orice soluție anterioară. Această „paralelizare” este creată prin rularea mai multor procese în paralel. Astfel, este clar că systemd este foarte bine împărțit în multe fișiere binare și, în consecință, procese. De fapt, multe dintre aceste fișiere binare sunt atât de bine separate încât sunt foarte utile în afara systemd.
Un pachet care conține 69 de fișiere binare individuale cu greu ar putea fi numit monolitic. Ceea ce diferă de soluțiile anterioare, însă, este faptul că livrăm mai multe componente într-un singur tarball și le păstrăm legate într-un singur depozit, cu un ciclu de lansare unificat.
Asta nu arată ca Unix
Există cu siguranță un adevăr în acest sens. Fișierele sursă systemd nu conțin o singură linie de cod din liniile UNIX originale. Cu toate acestea, inspirația este derivată din UNIX și, prin urmare, există o mulțime de UNIX în systemd. Un exemplu ar fi ideea UNIX „totul este un fișier” care se reflectă în faptul că în systemd toate serviciile sunt expuse în timp de rulare într-un sistem de fișiere kernel, cgroupfs. Deci, una dintre caracteristicile originale ale UNIX a fost suportul pentru mai multe locuri, bazat pe suportul terminalului încorporat. Cu systemd am adus din nou suport multi-seat nativ, dar de data aceasta cu suport complet pentru hardware-ul de astăzi, acoperind grafică, șoareci, audio, camere web și multe altele. De fapt, proiectarea systemd ca o suită de instrumente integrate care fiecare are scopurile lor individuale, dar atunci când sunt utilizate împreună sunt mai mult decât suma pieselor, ceea ce este mai mult sau mai puțin la baza filozofiei UNIX. Deci modul în care este gestionat proiectul nostru (adică păstrarea majorității nucleului sistemului de operare într-un singur depozit git) este mult mai aproape de modelul BSD (care este un adevărat UNIX, spre deosebire de Linux) pentru a face lucrurile (unde majoritatea sistemul de operare de bază este păstrat într-un singur depozit CVS / SVN) ceea ce nu a fost niciodată cazul pe Linux.
În cele din urmă, întrebarea dacă ceva este UNIX sau nu contează foarte puțin. Fiind excelent din punct de vedere tehnic, este cu greu unic pentru UNIX. Pentru noi, UNIX este o influență importantă (de fapt, cea mai mare), dar avem și alte influențe. Prin urmare, în unele zone systemd va fi foarte UNIX, iar în altele puțin mai puțin.
Este foarte complex ...
Există cu siguranță un adevăr în acest sens. Calculatoarele moderne sunt fiare complexe și sistemul de operare care rulează pe ele va fi, de asemenea, prea, așa că trebuie să fie complexe. Cu toate acestea, systemd nu este cu siguranță mai complex decât implementările anterioare ale acelorași componente. Este mai simplu și are mai puțină redundanță. Pe de altă parte, construirea unui sistem de operare simplu bazat pe sistem va implica mult mai puține pachete decât utilizările tradiționale Linux. Mai puține pachete ușurează construirea sistemului, scapă de interdependențe și de mult comportamentul diferit al tuturor componentelor implicate.
Asta nu mă va lăsa să folosesc scripturi shell
Acest lucru este complet fals. Pur și simplu nu le folosim pentru procesul de bootare, deoarece credem că nu sunt cel mai bun instrument pentru scopul respectiv, dar asta nu înseamnă că systemd a fost incompatibil cu ele. Puteți rula cu ușurință scripturi shell ca servicii systemd sau daemoni; puteți rula scripturi scrise în orice limbaj ca servicii systemd, deoarece systemd nu-i pasă deloc ce se află în executabilul dvs. Mai mult, folosim pe scară largă scripturi shell pentru propriile noastre scopuri: pentru instalarea, compilarea și testarea systemd. Și puteți lipi scripturile în procesul de pornire timpurie, le puteți utiliza pentru servicii normale, le puteți rula la închiderea finală - practic nu există limite.
În acest moment, presupun că unele dintre principalele convingeri s-ar putea să fi fost clarificate. Deși nu mă consider un susținător al schimbării și am rezervele mele cu privire la ideea „ un singur demon care să-i conducă pe toți ”, cred că, în cele din urmă, nimeni nu va îndrăzni să spună că nu funcționează deloc. Cunosc chiar și câțiva utilizatori care observă că, cu systemd, „PC-ul rulează mai repede”, dar acesta ar fi un alt subiect de discuție. Deocamdată, vă pot invita doar să dezbateți aici punctele voastre de vedere despre sistemul init pe care multe distribuții l-au adoptat, deși cele mai puternice reacții se observă în prezent în cadrul comunității Debian, care a generat chiar și o nouă bifurcație din cauza tuturor acestor lucruri. Fie că vă place sau nu, este o chestiune personală; din partea mea, vreau doar să-mi aduc contribuția la demitizarea systemd, care va fi prezent în cele din urmă în Jessie, următoarea versiune stabilă de Debian.
Am văzut articolul de pe GUTL (care la rândul său a fost preluat de pe DesdeAbreus )
Sistem curent?
Sunt unul dintre cei care nu citesc multe știri când ceva generează atât de multe controverse, prefer să rămân cu mai multe detalii tehnice. Chestia este... Uneori simt că anumite subiecte încetează să fie o discuție sau dezbatere pur tehnică și devin ca una dintre acele bârfe din showbiz
Mai întâi, o tiradă deschisă din partea unui utilizator despre systemd numită systemd VS intelligence , apoi Linus Torvalds spunând că systemd nu este atât de rău pe cât se spune ( și are dreptate ), o bifurcație numită uselessd ... fără comentarii... și, ca să pe scurt, în final Devuan.
Nu voi spune dacă e atât de rău pe cât se spune, mai puțin rău sau mai rău. Sistemul funcționează bine pentru mine, însă, personal, aș prefera init, deoarece îmi place modul în care organizează diverse lucruri (cum ar fi jurnalele, de exemplu). Dar hei, dacă systemd va fi numit un cal de curse și trebuie să înlocuiască init ( oare ar fi calul nostru de bătaie, făcând totul dar încet? ), ei bine... atâta timp cât schimbarea nu este prea drastică, utilizatorii se pot adapta fără prea multe probleme, iar sistemul funcționează mai bine (da, mai bine, poate că asta nu va fi suficient pentru mine!), atunci bine ai venit! 😉