Sistem demistificatorD

În fiecare zi calculatoarele noastre formează o parte mai importantă a vieții noastre, dacă are un fel de problemă, ne afectează starea de spirit, umorul, hehe. Sigur, utilizatorii Windows sunt mai predispuși la atacuri de panică decât în ​​cazul în care virușii (traieste linux!), ce se întâmplă dacă se defragmentează HDD-ul, dacă se caută și se instalează Clean Master pentru PC (deși aici în Linux mai trebuie să curățăm sistemul, BleachBit este una dintre alternativele preferate). Recent utilizatorii Linux au (unii) o anumită durere de cap numită: systemd

Ei bine, am citit un articol interesant despre systemd, care pare a fi tendința nu mult timp.

SistemD, care pare unora ca (și voi folosi cuvintele unui prieten), un inel pentru a îi stăpâni pe toți ... Pentru alții pur și simplu nu vine sau nu, atâta timp cât computerul funcționează bine, nu contează dacă init face lucruri X sau Y sau dacă este folosit systemd. Celui care scrie, ei bine ... să spunem că prefer 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 în niciun moment nu intenționez să renunț la iubita mea spirală. Încerc doar asta, dacă vom discuta un subiect, cel puțin îl facem cât mai pregătit, deși nu mă consider pro-sistem. Pentru a realiza demistificarea systemd mă voi baza pe un site web unde dezvoltatorii își dau punctul de vedere care mi-a venit în mâinile unui coleg care pare a fi pro-sistem, chiar dacă nu este un utilizator Debian. Acestea fiind spuse, cred că pot trece la încercarea de a demitiza 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.

ventilatoare systemd homer simpson

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 binare individuale. Aceste binare îndeplinesc sarcini diferite și sunt separate cu grijă din mai multe motive. De exemplu, systemd a fost conceput având în vedere securitatea, prin urmare majoritatea demonilor rulează cu cel mai mic privilegiu (folosind capabilități kernel, de exemplu) și sunt responsabili doar pentru sarcini foarte specifice, pentru a minimiza amprenta lor. siguranță și impact. De asemenea, systemd paralele boot mai mult decât orice soluție anterioară. Această „paralelizare” este creată prin rularea diverse procese în paralel. Prin urmare, se vede că systemd este foarte bine împărțit în multe binare și, prin urmare, procese. De fapt, multe dintre aceste binare se separă atât de bine încât sunt foarte utile în afara sistemului.

Un pachet care conținea 69 de binare individuale cu greu putea fi apelat monolitic. Cu toate acestea, ceea ce este diferit de soluțiile anterioare este că livrăm mai multe componente într-un singur tarball și le păstrăm înlănțuite într-un singur depozit cu un ciclu de versiune 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 total neadevărat. pur și simplu Nu le folosim pentru procesul de boot, deoarece credem că nu sunt cel mai bun instrument pentru acest scop specific, dar asta nu înseamnă că systemd a fost incompatibil cu ele. Puteți rula cu ușurință scripturile shell ca servicii systemd sau demoni, puteți rula scripturi scrise în orice limbaj ca servicii systemd, deoarece systemd nu-i pasă cel mai puțin ceea ce este în interiorul executabilului său. Pe de altă parte, folosim în mare măsură scripturi shell pentru scopurile noastre proprii, pentru instalare, construire, testare systemd. Și puteți lipi scripturile în procesul de pornire timpurie, acestea sunt utilizate pentru servicii normale, pot fi rulate la ultima oprire, practic nu există limite.

În acest moment, presupun că unele dintre principalele credințe ar fi putut fi clarificate, în ciuda faptului că nu m-am simțit ca un avocat al schimbării și am avut nelămuriri despre „un demon care să le controleze pe toate„Cred că până la urmă nimeni nu va îndrăzni să spună că cel puțin nu funcționează, știu chiar și unii utilizatori care observă că cu systemd„ computerul rulează mai repede ”, dar acestea ar fi alte lucruri care ar putea fi discutate. Pentru moment, rămâne doar pentru mine să vă invit să discutați aici punctele de vedere pe care le aveți despre managerul de pornire pe care le-au adoptat multe distribuții, deși acum cele mai mari reacții se văd în cadrul comunității Debian, care chiar a luat naștere o nouă furcă cu Toate acestea. Indiferent dacă vă place sau nu, este o chestiune pentru toată lumea, din partea mea vreau doar să îmi fac un pic în demistificarea sistemului care va fi în cele din urmă prezent în Jessie, următoarea versiune stabilă a Debian.

 Am văzut articolul în GUTL (care la rândul său a fost preluat de la De la Abreus)

poetizare-1984

Sistem curent?

Sunt unul dintre cei care nu citesc prea multe știri când ceva generează atât de multe controverse, prefer să rămân cu mai multe detalii tehnice. Este asta…. Uneori simt că anumite subiecte nu mai sunt doar o discuție sau o dezbatere tehnică și devin ca una dintre acele bârfe ale vedetelor celebr

Mai întâi un rând deschis de la un utilizator la systemd numit systemd VS intelligence, apoi Linus Torvalds spunând asta systemd nu este atât de rău cum o picteazăși un motiv dacă are), o furculiță numită inutil ... Fără comentarii ... și în cele din urmă Devuan.

Nu voi spune dacă este atât de rău cum se spune, mai puțin rău sau mai rău. Sistemul funcționează pentru mine fără probleme, totuși pentru gustul personal aș prefera init, deoarece modul său de organizare a diferitelor lucruri (cum ar fi jurnalele de exemplu) îmi place mai mult, dar hei, dacă systemd ajunge să fie numit cal de curse și trebuie să înlocuiască a iniția (Ar fi catârul nostru de pachet care face totul în afară de lent) Ei bine ... omule, atâta timp cât schimbarea nu este extrem de bruscă, utilizatorii se pot adapta fără prea multe probleme și sistemul funcționează mai bine (da, mai bine, nu este suficient pentru mine!), Bine ați venit 😀


114 comentarii, lasă-le pe ale tale

Lasă comentariul tău

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *

*

*

  1. Responsabil pentru date: Miguel Ángel Gatón
  2. Scopul datelor: Control SPAM, gestionarea comentariilor.
  3. Legitimare: consimțământul dvs.
  4. Comunicarea datelor: datele nu vor fi comunicate terților decât prin obligație legală.
  5. Stocarea datelor: bază de date găzduită de Occentus Networks (UE)
  6. Drepturi: în orice moment vă puteți limita, recupera și șterge informațiile.

  1.   întuneric el a spus

    Articol foarte bun, am fost cu Linux Mint 17.1 Rebecca cu systemd de câteva zile și mă simt mult mai fluid decât în ​​versiunile anterioare, nu știu prea multe despre asta pentru că sunt un utilizator obișnuit care învață despre asta, dar voi fi conștient, acesta este primul articol pe care l-am citit care nu vorbește dăunători ai sistemuluiD.

    1.    SynFlag el a spus

      Pentru ceva, el va fi primul pe care l-ați citit, care nu vorbește despre dăunători despre el și, pe de altă parte, spuneți-mi, utilizați Mint-ul dvs. ca server? Adică, nu v-ar deranja dacă are un bug de la Din când în când, nu? De aceea folosești Mint și de aceea nu te deranjează, nu-ți place, dar nici sistemul nu te înșurubează. Când aveți erori și din această cauză aveți probleme grave în medii grave, vă va deranja.

      1.    Carlos el a spus

        Omule, orice distribuție bazată pe Debian Stable pe care o recomandați? Aș putea folosi Debian, dar trebuie să configurați multe lucruri odată instalate, codecuri etc ... Pe care le recomandați? Mulțumiri.

    2.    santiago burgos el a spus

      Și cum ați reușit să introduceți systemd în Linux Mint? Am vrut să încerc să-l introduc, dar nu știu dacă mai este ceva de făcut (la ceea ce, teoretic, aduce deja Ubuntu), dacă aveți vreun ghid în această privință sau ceva ce mi-l puteți transmite, eu ar aprecia

  2.   giskard el a spus

    Articol foarte bun. Să vedem dacă talibanii anti-SystemD l-au citit (dar mă îndoiesc)

    În orice caz, peste un an de acum îi voi vedea folosind SystemD și vor nega ceea ce au spus acum un an. Așa sunt. Rezistent la schimbare? Cu siguranță da.

    1.    plin de viață el a spus

      Mă considerați un taliban pentru că nu vreau să accept Systemd, apoi vă consider un taliban pentru că nu doriți să acceptați că nu vreau să accept Systemd. Suntem la îndemână 😉

      1.    jlbaena el a spus

        Cu toate acestea, după cum se spune la sfârșitul articolelor:

        «elav: Blog Personal / Twitter / G+ / Usuario de ArchLinux. Informático, melómano, blogger y diseñador web. Administrador y Fundador de DesdeLinux.net. »

        adică utilizați una dintre primele distribuții adoptate de SystemD.

        În ceea ce priveşte

    2.    George Robles el a spus

      OK, copilule.
      Fără cuvinte !!!!, continuă să te joci, că viața este roz.

    3.    Tito el a spus

      Pentru comentarii ca ale tale, dragă Giskard, acesta este motivul pentru care renunț la SystemD și la ceea ce reprezintă.
      Și dacă după 20 de ani folosind și lucrând cu și pentru Linux, sunt taliban; Ei bine, așa să fie.

    4.    giskard el a spus

      Peste un an vorbim. Și elav, nu te-am menționat. Te-ai sinucis ca Chacumbele.

    5.    giskard el a spus

      Să vedem, oamenii citesc și NU citesc. Există sau nu există talibani împotriva SystemD? Sunt! Și sunt alții de cealaltă parte, cei care îl apără pe dinți și unghii ca și cum ar fi un panaceu. Ce sunt toți cei care sunt? Nu! Deloc! Există cei care simpatizează cu unul sau cu celălalt și văd binele și răul atât al lor, cât și al celorlalți. Cu aceștia poți vorbi fără probleme. Dar nu vor nega că există talibani. Și dintr-o parte în alta. Și dacă cineva a fost înțepenit de asta fără să înțeleagă că ar putea foarte bine să nu fie talibani, atunci îmi odihnesc cazul, deoarece dovezile îi fac vinovați.
      Dacă vorbesc cu cineva despre SystemD și de la bun început acea persoană nu îl numește pe numele său, ci Systemshit sau ceva similar, aș vrea sincer să-mi spună dacă este posibil să purtăm o conversație cu o astfel de persoană care inițial descalifică oponentul. Nu poate.
      Oricum, trebuie să citești. Să vedem, dacă vin și spun „sunt niște eschejfhduf (cuvânt inventat) care bat copiii când pleacă de la școală” și câțiva vin să apere „eschejfhduf” nu este să credem că ei înșiși sunt?
      Ei bine, dacă cineva acolo (nu talibanii, vă rog, și nici eschejfhduf) vrea să vorbească despre avantajele și dezavantajele init și SystemD (care au ambele bune și rele), voi fi cu bucurie în jur.
      Salutări.

    6.    sinflag el a spus

      Antisistemul taliban? și spune-mi, ce ești? talibanii pro-sistem?? Pe de altă parte, de ce presupuneți că nu vom citi, ci vom comenta direct?, cine este talibanul cu minte închisă, care nu admite discuții și vorbește ca LP :: «Este cel mai bun, credeți-mă, Știu ce fac ”. ?

      Am citit întregul articol și vă pot spune:

      Systemd este binar: True
      Demitificarea: falsă

      LP denaturează ceea ce se spune, care este că nucleul systemd este binar, multe, prea multe pentru a fi atârnate de PID1, puternic întrețesute, atât de mult încât te invit să te uiți la #devuan cum costă curățarea, de exemplu, logind systemd și restul pachetelor din Debian, având în vedere cât de legată este logarea care înlocuiește PAM de sistem.

      Configurația este concisă și nu permite TOT ce nu aș vrea să dezactivez jurnalul, deoarece nu poți nici să omoare PID, nici să-l oprești sau altceva, adică modularitate? Cu sysvinit cel puțin, ai putea ucide totul până când nu ai rămas decât cu init , același parvenit.

      ===========
      „Acel lucru este monolitic și controlează totul”.

      Dincolo de faptul că sunt 2 sau 69 de binare, ele sunt întrețesute între ele cu dbus și, prin urmare, cu întregul sistem de operare, nepermițându-le să fie ușor fără legătură, cel mai clar caz este journald, că nu îl puteți dezactiva, de asemenea, începutul demonilor sau serviciilor se face prin „unități” care sunt fișiere text, dar nimic mai mult decât atât, analizate de systemd și voila, fără modificări sau hacks în servicii dincolo de ceea ce este stabilit.

      =======

      „Nu arată ca UNIX”

      Îi voi răspunde pe scurt. Nu respectă LSB, nici POSIX și astăzi un dezvoltator fedora care ajută în #devuan a spus: „Este adevărat că nu este și nici nu contează, ceea ce contează este că poate rula lucruri care sunt POSIX, odihnă, cu siguranță nu mă interesează sistemul de operare sau orice altceva, atâta timp cât funcționează și are caracteristici bune ». Și de ce ar trebui să fie UNIX sau UNIX: Faceți un lucru și faceți-l bine, ceva ce systemd nu face.

      ===========

      „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ță »

      Mai puțină redundanță? Vă cer să instalați ALTE syslog pentru text simplu și au cerut-o pentru înregistrarea la distanță înainte de a exista systemd-journald-remote, adică au pus-o în producție fără a putea face o înregistrare la distanță fără a depinde de rsyslog , ceva de bază, cum ar fi autentificarea centralizată. Chiar și așa, nu are capacitatea, un simplu boolean de a indica dacă dorim ieșirea în binar sau în text simplu și, de asemenea, dacă va folosi binar, de ce nu ceva cunoscut sub numele de berkeley DB, astfel încât să poată fi citit din orice sistem UNIX sau Linux?

      Simplu? arata putin cat de simplu este: http://wiki.gentoo.org/wiki/Comparison_of_init_systems

      Uită-te la cantitatea de linii de cod și fișiere.

      =========================

      „Asta nu mă va permite să folosesc scripturi shell”

      Acest lucru este fals, dar din nou este denaturat, nu este criticat pentru faptul că nu permite utilizarea scriptului bash, ci pentru că nu le folosește pentru a porni servicii, deci nu este modificabil, hackabil și flexibil precum upstart sau sysvinit. Și prin hackable vreau să spun harcodat.

      ============================

      Încă mai crezi că:

      1.- Nu am deloc motive
      2.- Nu am citit nimic și sunt taliban?

      1.    Richard el a spus

        Mă întreb ... chiar trebuie să am încredere în ceea ce spune Lennart? Dacă cineva neutru îmi spune că pot lua în considerare anumite lucruri, dar acest lucru are același gust pentru mine că Red Hat publică ceva pentru a apăra Systemd

  3.   ArthurShelby el a spus

    Uau, până când cineva de pe aici spune ceva rezonabil și nu doar frică și dezinformare.

    1.    plin de viață el a spus

      Articolul este traducerea în spaniolă a ceea ce a scris Lennart.

      1.    Charlie Brown el a spus

        Fără supărare, dar traducerea pare să fi fost făcută de versiunea beta a Google Translator ... 🙁 Mi-a fost greu să înțeleg unele paragrafe; oricum informațiile sunt apreciate.

      2.    Martin el a spus

        @ Charlie-Brown, pentru că Lennart nu știe să se exprime foarte bine în engleză. Așa este de urât citind originalul.

  4.   Charlie Brown el a spus

    Motivele prezentate sunt valabile, cu toate acestea, cred că unele pot genera mai multe întrebări. În orice caz, recomandarea mea celor care au ocazia: mergeți la sursa originală a informațiilor http://0pointer.net/blog/projects/the-biggest-myths.html (din păcate pentru unii, este în limba engleză), ceea ce este mult mai complet și ajunge până la a susține până la 30 de motive pentru care utilizarea SistemD este considerată favorabilă.

    1.    plin de viață el a spus

      Acest articol pe care îl menționați este scris de creatorul Systemd. Evident, nimeni nu este mai bun decât el pentru a-și apăra munca, totuși, vă invit să urmăriți acest videoclip http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html și îmi vor spune concluziile lor despre asta. Nu spun mai multe.

      1.    Rolo el a spus

        elav problema jurnalelor de jurnal care sunt într-un binar este unul dintre cele mai criticate puncte, chiar și linus însuși a ridicat-o, atunci când într-un raport în care a admis că systemd nu era atât de rău. De asemenea, linus însuși a explicat că puteți crea un script pentru a prelua datele jurnalului și a le pune în text simplu.
        Systemd vă permite, de asemenea, să configurați dimensiunea binarului jurnalului, reducând riscul unei eventuale eșecuri.

        De fapt, arta pe care o citați este foarte neserioasă, deoarece nu are un indiciu de obiectivitate și mă face chiar să mă întreb dacă vina pe care o arată este reală sau este falsificată (dracu software-ul proprietar astfel încât să dea eroarea).

        toate programele au erori la un moment dat, dar se pare că vor căuta întotdeauna cea de-a cincea parte a pisicii pentru a găsi ceva în neregulă cu systemd.

        De exemplu: în debian s-a decis că systemd va fi inițialul implicit, dar nu împiedică utilizarea sysvinit sau openrc sau upstart și îmi vei spune bine da, dar nu poți elimina în totalitate systemd, iar răspunsul meu ar fi că este același lucru cu ceea ce sa întâmplat la debian wheezy unde puteți rula openrc, systemd sau upstart, dar sub sysvinit

        PS: Nu vreau să-mi imaginez cât de nebuni vor deveni cu kdbus și integrarea acestuia cu systemd la nivelul kernel-ului Linux http://kroah.com/log/blog/2014/01/15/kdbus-details/

        1.    plin de viață el a spus

          Dacă se poate. Mai mult, intenționez să mă retrag oficial din discuțiile referitoare la Systemd. Orice trebuie să se întâmple 🙂

      2.    yukiteru el a spus

        @rolo eșecul este documentat, i s-au prezentat mai multe rapoarte de bug-uri, i-au prezentat un videoclip și acum spun că este fals. Dacă doriți să fiți siguri, urmați pașii și vedeți ce se întâmplă. Iată acum mai multe informații despre această problemă, bug-uri inventate? Eu nu cred acest lucru.

        https://bugzilla.redhat.com/show_bug.cgi?id=958321
        https://bugzilla.redhat.com/show_bug.cgi?id=1054929
        https://bugzilla.redhat.com/show_bug.cgi?id=1055570
        https://www.libreoffice.org/bugzilla/show_bug.cgi?id=74280
        https://bugs.archlinux.org/task/32191
        https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64116 (Lennart și marile sale explicații)
        https://bugzilla.redhat.com/show_bug.cgi?id=974132
        https://bugzilla.redhat.com/show_bug.cgi?id=1157350

      3.    Emmanuel el a spus

        Ceea ce menționează videoclipul este cu siguranță curios. Ca dezvoltator ni se spune întotdeauna că un detaliu nu ar trebui să afecteze întregul sistem / program, de exemplu, dacă o interogare selectată către baza de date eșuează, de ce ar trebui să se blocheze întregul program? Este la fel cu SystemD, dacă eșuează pentru că alții eșuează, nu știu cât de bine este făcut. Evident, există cazuri în care o defecțiune este practic o defecțiune a sistemului, dar cu cât proprietățile programului sunt mai izolate intern, cu atât produsul va fi mai bun.
        Acum, atacarea software-ului din partea sa slabă nu este nouă, este mai degrabă o practică foarte obișnuită și că, de fapt, ar trebui să fie făcută cu fiecare program, așa că a vedea SystemD căderea pentru jurnal, este o dovadă validă că SystemD Nu este ceea ce se spune sau se face să creadă.
        Cu cât lucrurile devin mai interdependente cu SystemD, cu atât lucrurile se vor înrăutăți. Dacă înainte de a monta un dispozitiv nu dădea jos sistemul, acum lucrurile ar putea să nu arate atât de bine.
        SystemD nu este rău, nu îl urăsc, dar nu este ceea ce mulți ar vrea să crezi. Are avantaje, dar nimic din ceea ce Upstart nu a avut sau ar putea avea, desigur, Canonical a fost implicat și nimeni nu a mai vrut să fie atent.
        Salutări.

      4.    Rolo el a spus

        dar în acel videoclip nu știu în niciun moment că sistemul se blochează. ceea ce face tipul este să modifice binarul informațiilor jurnalului pentru a genera eroarea, dar ideea este că de fiecare dată când intră în systemd.
        Din ceea ce am înțeles, dacă limitați dimensiunea jurnalului binar, atunci când atinge limita creează alta și așa mai departe. diminuând posibilitatea corupției tuturor datelor.

      5.    Jorge el a spus

        Să fim clari ... Cine s-ar gândi să modifice și fișierul jurnal? xD

      6.    anonim el a spus

        @Jorgicio 4 decembrie 2014 6:03
        Să fim clari ... Cine s-ar gândi să modifice și fișierul jurnal? xD

        Dacă ai spus-o într-un mod ironic ... totul bine, am înțeles :)), dar dacă chiar ai întrebat, îmi dau punctul meu de vedere.

        Pentru mine este clar că nu este un bug, este o caracteristică !! Ideea este că, dacă există o escaladare a privilegiilor într-un acces la distanță, ar fi foarte ușor pentru cei care sunt de acord să șteargă jurnalul pur și simplu editându-l pentru a-l corupe și pentru systemd să-l șteargă ca fiind corupt și astfel să scape de a fi detectat în acel acces la distanță.
        Spune-mi paranoic, dar nu am alt mod de gândire ... nu este un bug, este o caracteristică și de aceea nu acceptă să remedieze acel bug.

  5.   Daryyo el a spus

    uff acum toate blogurile Linux fac 200 de articole despre systemd până la punctul în care știu deja aproape toate argumentele împotriva și pentru xD.

    și încetul cu încetul am fost convins de unele dintre argumentele anti sistem și dintre cele pe care le-am văzut (dacă este ceva în neregulă, vă rog să mă corectați)

    Am văzut chiar un articol acolo despre cum se poate bloca întregul sistem atunci când editați un jurnal binar și că acesta nu oferă nicio informație despre faptul că fișierul este corupt.

    lipsa de claritate în bușteni

    o echipă de dezvoltare care ignoră adesea rapoartele de erori

    Fiind atât de mare și incluzând atât de multe lucruri într-un init face sistemul mult mai instabil și dacă adăugăm erori precum cel menționat mai sus, acesta face un sistem fără stabilitatea pe care linux o caracterizează atât de mult.

    se spune că este modular, dar părțile acestuia nu pot funcționa fără alte părți ale aceluiași sistem

    o dezvoltare care, pe termen lung, generează dependențe atunci când programează, făcând software ca gnome greu portabil pentru sistemele fără systemd.

    înlocuiește părți (networkd, logind etc) care funcționau și primeau întreținere de ani de zile și le schimbă pentru altele noi, fără nici o nevoie care tind să aibă multe alte erori.

  6.   mat1986 el a spus

    De când foloseam distrosuri bazate pe Arch (Manjaro, Bridge Linux, Antergos) care folosesc în mod evident systemd, trebuie să spun că nu am reclamații cu privire la utilizarea și manipularea acestuia. Pornirea serviciilor este ușoară - cu atât mai mult în Bridge, unde Bluetooth sau modemmanager sunt dezactivate în mod implicit. În afară de o eroare legată de hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) Nu am avut multe probleme. Evident, nu cred că este părerea tuturor, dar personal nu am plângeri 🙂

  7.   Solrak Rainbow Warrior el a spus

    Nu-mi place ideea că o companie (Red Hat) acuzată că a colaborat cu NSA (ușile din spate și controlul SUA) realizează un sistem cu care totul este controlat. Un inel pentru a le controla pe toate, pentru a le lega în întuneric, dacă este necesar ..

    Pe de altă parte, trebuie să recunosc că Intel IRIS PRO 5200 funcționează mai bine pentru mine și aproape niciodată, dacă nu, sistemul meu grafic se rupe când încep openSUSE 13.1. Și da, totul este mai bun, începe și se oprește mult mai repede. Cum m-a beneficiat un simplu utilizator.

    1.    johnfgs el a spus

      acuzat să colaboreze cu NSA

      Subliniez partea importantă

      Dacă cineva te acuză că vinzi droguri, ești automat traficant de droguri?

      1.    anonim el a spus

        @juanfgs
        Traficant de droguri nu .... un complice da.

      2.    johnfgs el a spus

        Traficant de droguri nu .... un complice da.

        Doamne ... te-aș insulta, dar propriile tale cuvinte o fac pentru tine.

  8.   Rafael Castro el a spus

    Clarificați doar că systemd este scris și așa ar trebui făcut.

    Ortografie

    Da, este scris systemd, nu sistemul D sau System D, sau chiar SystemD. Și nici nu este sistemul d. De ce? Pentru că este un daemon de sistem, iar în Unix / Linux acestea sunt în minusculă și sunt sufixate cu minuscule d. Și din moment ce systemd gestionează sistemul, se numește systemd. Este atat de simplu. Dar, din nou, dacă tot ceea ce vi se pare prea simplu, numiți-l (dar nu-l scrie niciodată!) Sistem Cinci Sute, deoarece D este cifra romană pentru 500 (acest lucru clarifică și relația cu Sistemul V, nu?). Singura situație în care găsim OK să folosim o literă majusculă în nume (dar nici nu-i place) este dacă începeți o propoziție cu systemd. În zilele de sărbătoare înaltă, s-ar putea să-l și scrii sÿstëmd. Dar, din nou, Système D nu este o ortografie acceptabilă și ceva complet diferit (deși cam potrivit).

    http://freedesktop.org/wiki/Software/systemd/

    1.    plin de viață el a spus

      Și aici? Ai pus asta în GUTL .. dar omule, toată lumea spune Linux și nu GNU / Linux, deci cu SystemD la fel.

  9.   Germán el a spus

    Vă spun că nu este necesar să utilizați sistemul de jurnal sau cronul pe care îl oferă systemD, puteți urmări syslog-ng și cronie pentru această sau alte alternative
    Folosesc systemD în ArchLinux de când eram în aur și pare mai ușor de manevrat decât modul derivat debian și redhat, are o mulțime de comenzi de consolă care te scutesc de editarea fișierelor text și simplifică asamblarea scripturilor configurarea instalării (amintiți-vă că în arch totul este instalat de consolă)
    Și nu în ultimul rând, sistemul pornește rapid, în arc puteți începe serviciile în paralel la pornirea sistemului, dar este riscant

  10.   santiago el a spus

    Ceea ce cred că este rău în ceea ce privește problema este că majoritatea iau parte, sau sunteți pro-systemd sau anti-systemd și cred că are lucrurile sale bune și rele, sunt utilizator și am început să mă joc puțin cu systemd, într-adevăr Lucrurile bune sunt că pornirea este mai rapidă și mai puțin complexă decât restul inițierii, deși și problema jurnalului mă deranjează foarte mult.
    Înțeleg că cei care pot să spună cu adevărat dacă este bine sau rău sunt administratorii sau experții pe această temă, dar mi se pare că sistemul care s-a descurcat cu ceva timp în urmă a încetat să mai fie ceva tehnic și a devenit ceva mai „show-stopping”, din partea mea sunt în putin impotriva dar nu ma consider anti sau pro

  11.   yukiteru el a spus

    @KZKG_Gaara

    Văd că o mare parte din ceea ce comentați aici este același ca și Lennart a publicat pe blogul său, mai exact în această postare: http://0pointer.de/blog/projects/the-biggest-myths.html.

    Desigur, postarea a avut anumite „clarificări” și a lăsat deoparte anumite conținuturi tehnice, pentru a fi ușor de digerat informațiile pentru cei care urmează să le citească, dar vom fi serioși și sinceri, chiar dacă adevărul doare: systemd are o mulțime de lucruri pe care Lennart neagă că nu le are, asta și multe altele. Și în acest sens explic parțial.

    1.- Lennart spune că nu este balonat și că nu are un sindrom NIH ridicat (sindromul neinventat aici). Dacă da, vă rog cineva să-mi explice: De ce un init ar trebui să aibă controlul rețelei (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), jurnale (journald), coredumps (systemd -coredump); dev / random (generator de numere aleatorii) și cel mai recent control asupra TTY (consolat de sistem)? Nu au existat o mulțime de instrumente create în astfel de scopuri, care acum systemd adaugă propriile lor cu acces exclusiv (caz Journal)? Ce explicație logică și acceptabilă îmi oferiți pentru o inițiativă pentru a putea sparge nucleul de depanare și cmdline? Adăugați la acel control asupra kdbus, următorul IPC care va fi integrat în nucleu. Cu siguranță îmi vor spune aici: «Dar puteți instala un alt instrument pentru a controla toate acestea». Și dacă este adevărat, însă, multe dintre aceste instrumente primesc doar un flux de date aruncat de systemd, ca în cazul syslog și rsyslog, care se conectează la un flux de date / flux pe care journald îl oferă astfel încât alte instrumente să poată VEDE ce journald conduce, în cele din urmă, asta înseamnă doar că aveți două instrumente care fac același lucru, iar unul dintre ele este o cutie pandora. (Vă rog să nu-mi spuneți că codul poate fi auditat, deoarece invit pe cineva să „fumeze” codul jurnal și cadrul său cu systemd și alte instrumente conexe)

    2.- Lennart ne mai spune că systemd oferă suport pentru scripturile SysV și LSB. Acesta este un „jumătate de adevăr”, o „minciună albă”, ca să spunem așa, pentru că adevărul este că systemd-214 nu oferă suport pentru script-uri bash, SysV sau LSB și acest lucru este relatat în notele sale de lansare pentru acea versiune.

    3.- Ce sistem nu este portabil? Este un alt punct discutabil. În BSD nu funcționează bine, în BSD nu există Cgroups printre alte instrumente pe care systemd trebuie să le ruleze. Dar este pentru un motiv de proiectare sistematică, nu pentru că nu este portabil. Până când kernel-ul BSD nu îndeplinește minimul pentru a-l suporta, systemd nu va funcționa pe platforma respectivă și asta nu este vina nimănui, doar că BSD nu are niciun interes și nici Lennart. Este atât de simplu. Acum, suportul pentru alte biblioteci C este un alt lucru, bine cunoscute sunt problemele glibc (faceți un kernel manual pentru a vedea cantitatea de opțiuni și soluții care au fost făcute pentru a evita aceste detalii, în special pentru glibc 2.3, 2.5 și 2.11 , printre alte defecte pe care glibc le-a tras de-a lungul anilor), dar nu se termină acolo, nu se termină, Lennart însuși a spus că a preferat să-și creeze propria bibliotecă libc, pentru că pentru grupul său este mult mai rapid. decât citirea codului deja creat (și documentat de altfel), dar nu se oprește aici, intenționează să elimine glibc și își folosesc libc-ul nu numai pentru systemd, ci și pentru Fedora, făcându-l standard pentru construirea tuturor pachetelor lor . NIH Unde? Se pare că bătrânului bun Lennart îi place să troleze și să fie mare.

    4.- Sistemul respectiv nu este monolitic deoarece este împărțit în 69 de binare. Da, bine, acest lucru este discutabil. systemd are 69 de binare, care îndeplinesc sarcini diferite, dar aceste binare transmit informațiile despre sarcină către systemd, deci dacă unul nu reușește, șansele de a sparge sistemul cresc destul de dramatic. Acest lucru este bine documentat, rapoartele de erori abundă în astfel de probleme și chiar și în probleme mai simple, de fapt simple. systemd poate fi împărțit în sute de binare, dar atâta timp cât nucleul dvs. controlează, riscul unei pauze continuă și crește și, dacă nu mă credeți, citiți rapoartele de erori și distrați-vă.

    Rețineți că aici nu am comentat nimic despre faptul că systemd este gunoi, am făcut doar comentarii care sunt doar „tehnice” (evident că vorbind despre lucruri tehnice devine foarte complex) și valabile, susținute de informații ușor accesibile pe internet. Acum: Ce Linux are nevoie de o inițiativă standard? Da, ar fi cu siguranță ceva de mare valoare pentru comunitate. Ce sistem este soluția? Nu, deși este aproape, cu siguranță are multe lucruri pozitive, dar răspândirea sa virală și numărul de lucruri pe care le face crește riscul a ceea ce poate merge prost și poate ajunge să dăuneze comunității.

    PS: Las material în care poți corobora ceea ce spun, citesc că va fi destul de ilustrativ și văd că nu includ bloguri sau ceva de genul acesta, critică personală și bazată pură. Salutari.

    http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html
    http://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc
    http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html
    https://bugzilla.redhat.com/show_bug.cgi?id=1057883 (@elav poate te simți identificat)
    https://code.google.com/p/d-bus/source/browse/kdbus.txt
    https://github.com/gregkh/kdbus
    http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html

    1.    plin de viață el a spus

      Amin frate .. amin ..

    2.    PAMP el a spus

      Încă nu văd motive valabile pentru a nu adopta systemd. Pur și simplu interpretați ceea ce vedeți cu frică, rezultând în exagerări. Nici avantaje și dezavantaje clare și bine definite.
      În plus, această integrare permite standardizarea despre care ați vorbit chiar. Nu numai Red Hat funcționează pe systemd, ci diferite companii și voluntari din alte distribuții.
      Cred că eroarea este că funcționarea systemd nu este studiată corect.

      1.    xiep el a spus

        Văd motive valide în analiza lui Yukiteru. Observați că în loc de frică văd rigoare, precizie și claritate. Trebuie să fie o problemă a medicului ochi.

      2.    yukiteru el a spus

        Nu este frică (nu mă tem de o bucată de cod) și nici nu sunt exagerări (tot ceea ce am spus aici este documentat și am transmis o mulțime de informații care o coroborează, informații care apropo ies din liste și din minte / voce Scrisul de mână al lui Lennart, și nu din comentariile unui blogger), este REALITATEA.

        systemd face toate acestea și multe altele, iar acest lucru este ceva ÎNGRIJĂTOR (un concept diferit de a te teme), deoarece cu siguranță ia atribuții și face lucruri care în acest moment pot fi realizate prin alte mijloace și care, de altfel, funcționează mai bine și sunt mai stabile. systemd este foarte asemănător cu Windows și nu poate fi ascuns, trebuie doar să știți ce fac userinit.exe, svchost.exe, smss.exe și alte dependențe și să le comparați cu systemd, asemănarea este atât de mare încât este o idee proastă. Acum, cu siguranță, systemd poate avea o calitate mai bună decât omologul său Windows (sau se poate întâmpla contrariul, nimeni nu știe cu adevărat, cu excepția cazului în care programați pentru Microsoft), dar nu mă puteți acuza de EXAGERAT și FERABIL atunci când citiți însuși Lennart Într-o listă, vorbind despre crearea unei noi biblioteci C, pentru că este sătul de Glibc și pentru ñapa, aruncând sfatul mic și nesemnificativ, că acel libc poate fi folosit pentru a construi toate pachetele Fedora. Și dacă credeți că este o minciună și că sunt exagerat, vă voi lăsa mesajul în acest link: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (in engleza)

        Acum spuneți-mi dacă este o exagerare să spun în fața tuturor acestor lucruri, că odată ce Linus decide că CONFIG_VT așa cum este, trebuie să părăsească nucleul (situație care există de mult timp) și să-l treacă în spațiul utilizatorilor, nu se întâmplă un lucru nebunesc ca dacă systemd-consoled este o dependență puternică pentru aproape orice instalare Linux (ceva trebuie să se ocupe de VT-uri, nu crezi?), asta nu ar pune diferite distrosuri non-systemd în centrul atenției pentru a forța un comutator. Dacă credeți că acest lucru este deasupra, permiteți-mi să vă spun că habar nu aveți de ce este capabil și face Lennart, deoarece ultimele sale modificări afectează dezvoltarea furcii udev, Gentoo eudev, și el va continua să facă acest lucru cu amenințările sale de către sub masă (pentru a vă plânge ulterior, așa cum a făcut-o pe Google+)

      3.    yukiteru el a spus

        @xiep Nu pot fi mai de acord cu comentariul tău.

      4.    johnfgs el a spus

        Che Yukiteru, declarația dvs. lungă omite faptul că e-mailul pe care l-ați conectat pe libc este o glumă a proștilor din aprilie, uitați-vă la nota de subsol și priviți data (31 martie, probabil 1 aprilie în fusul orar Lennart)

        [1] Putem adăuga un nucleu mai târziu, după succesul GNU / Hurd
        abordare.

        Exersează-ți engleza-fu, deoarece este apos și pune la îndoială toată „cercetarea” ta.

      5.    yukiteru el a spus

        @juanfgs pari singurul care citește, măcar eu te aplaud pentru asta, dar trebuie să citești ceva foarte important care este în comentariul meu, nu contează îl voi pune aici:

        »NIH Unde? Se pare că bătrânului bun Lennart îi place să troleze și să fie mare. "

        Nu cred că a scris-o dintr-un motiv nevinovat, era conștient de faptul că era o altă glumă a lui Lennart pentru April's Fool Day (proastă dispoziție), precum și pasiunea pentru conversia /, / etc și orice altceva în / Linux. 🙂

        PS: Mulțumesc, dar nu trebuie să-mi exersez limba engleză, folosesc limba de la 6 ani
        aaahh și orice altceva este adevărat, verifică-l 🙂

      6.    johnfgs el a spus

        Nu cred că l-am scris dintr-un motiv nevinovat, știam faptul că era o altă glumă de la Lennart pentru April's Fool Day (proastă dispoziție) nalist nebun

        Acesta este un senzaționalism direct, spui că te bazezi pe fapte, dar în realitate îți urmezi prezența că tipul este rău și vrea să preia lumea și răsuciți faptele pentru a reflecta discursul tău. Aceasta este ceea ce mă deranjează foarte mult despre oamenii antisistem, ei nu scot cuvinte când vine vorba de răsucirea faptelor și de a spune adevăruri pe jumătate, încărcate cu părerea lor, desigur.

        „Regula mea” în aceste cazuri este pur și simplu următoarea defalcare logică, pornind de la premisa că
        - Sunt dezvoltator web / aplicații desktop sau cli
        - Nu am scris niciodată un sistem inițial.
        - Nu sunt menținerea unei distro.

        verificați dacă interlocutorul are:
        - a creat un sistem init
        - este un activ care menține sistemul inițial al unei distro

        și realitatea este că majoritatea antisistemelor nu reușesc acest test, totuși sunt o mână de oameni care, dintr-un anumit motiv, ȘTII MAI MULTE decât oamenii din spate: Debian, Fedora, Archlinux, nucleul Linux, întregul proiect GNOME, probabil și proiectul KDE, deoarece nu s-au plâns de systemd, SUSE și de mult etc.

        Chiar și așa, discursul său otrăvitor și vitriolic singurul lucru pe care îl realizează este să genereze dezunități, probleme și altele. Acesta este punctul în care abia aștept să treacă în cele din urmă la BSD, deoarece au amenințat de la Xorg, NetworkManager, PulseAudio și nu știu dacă din cauza ignoranței tehnice sau pentru că nu s-ar plânge de asta.

      7.    yukiteru el a spus

        @juanfgs, te cred în cuvântul tău în mod special în acest sens:

        «Și realitatea este că majoritatea antisistemelor nu trec acest test, chiar și așa există o mână de oameni care, dintr-un anumit motiv, ȘTII MAI MULTE decât oamenii din spate: Debian, Fedora, Archlinux, nucleul Linux, întregul proiect GNOME Probabil și proiectul KDE, deoarece nu s-au plâns de systemd, SUSE și de mult etc.

        Chiar și așa, discursul său otrăvitor și vitriolic singurul lucru pe care îl realizează este să genereze dezunități, probleme și altele. Acesta este punctul în care abia aștept să treacă în cele din urmă la BSD, deoarece au amenințat de la Xorg, NetworkManager, PulseAudio și nu știu dacă din cauza ignoranței tehnice sau pentru că nu s-ar plânge de asta. "

        Așadar, conform Dvs., toți antisistemii suntem otrăvitori și vitriolici, încât singurul lucru pe care îl realizăm este dezunitatea, problemele și așa mai departe. Permiteți-mi să vă spun că aceasta este cea mai mare indignare pe care am putut să o citesc aici. Nu știu de ce deranjează pro-sistemele, când problemele structurale ale unui sistem sunt scoase la lumină, ceea ce, evident, le va afecta la un moment dat, pentru că s-ar putea să nu li se fi întâmplat nimic acum, dar la un moment dat, o vor face. o va face, și apoi unii anti-systemd le vor aminti de cuvintele pe care le-au spus de multe ori și nimeni nu i-a oprit și poate că un alt anti-systemd le va ajuta.

        En lo personal, no me gusta systemd, pero eso no significa que no use el init, tengo que hacerlo, porque precisamente en mi trabajo si tengo que tocar alguna maquina con ese init, debo tener conocimiento de como manejarlo. Además en lo personal también lo he usado desde que llego a Archlinux e incluso en Debian y Gentoo, así que no me venga a decir que mi visión es sesgada por no hacer uso de systemd, yo le he usado, y se de que pata renquea, y si tengo que ayudar a alguien acá en el foro DesdeLinux o en IRC o la lista de Debian (que es la distro donde yo más tiempo he estado y aún uso en mi trabajo) lo haré con gusto, porque precisamente si algo me agrada de la comunidad Linux, es que pese a la diferencia siempre se ayuda.

        Acum, pentru a trece la BSD, este posibil, dar o voi face doar dacă systemd devine atât de virulent încât nu îmi permite să folosesc nicio altă opțiune, între timp rămân pe Linux, dezactivând toată nebunia, inclusiv multe dintre lucrurile Cgroups .

      8.    johnfgs el a spus

        iar realitatea este că majoritatea antisistemelor

        !=

        Așa că, în funcție de voi, toți anti-systemd

        Din nou răsuciți cuvintele pentru a se potrivi discursului dvs. Ești un material foarte bun pentru un politician / jurnalist.

      9.    johnfgs el a spus

        Clarific, problema mea nu este că menționează probleme tehnice ale Systemd, ideea este că de multe ori își încarcă discursul cu minciuni, și anume:

        Că dacă systemd vă va forța să utilizați un server microhttpd (care este un modul opțional NU instalat implicit), că dacă systemd este un singur binar, acel systemd va fi închis deoarece lennart este plătit de Microsoft, că jurnalele binare Sunt obligatorii. Nimeni nu dorește sistem și adoptarea sa se face de către un lobby politic.

        Asta șochează, minciuna. Dacă ar fi fost o discuție rezonabilă, ar merita, dar este doar FUD-ul bun.

        Că nu-ți place mi se pare perfect, nu-mi plac multe software-uri, nici măcar limbaje de programare, distrosuri și altele, dar nu inventez lucruri despre asta și nici nu sunt supus citind ceea ce vreau să citesc și încărcând declarațiile mele cu sentimente personale pentru a deteriora imaginea a oamenilor care o dezvoltă.

      10.    yukiteru el a spus

        @juanfgs îmi pare rău, dar nu eu sunt cel care numește un anumit grup de oameni „otrăvitor și vitriolic” pur și simplu pentru că nu le place un software.

      11.    johnfgs el a spus

        Chiar și așa discursul lui otrăvitor și vitriolic singurul lucru pe care îl realizează este să genereze dezunități, probleme și altele.

        Din nou, răsucind propozițiile pentru a fi o victimă.

      12.    yukiteru el a spus

        @juanfgs din nou îți spun, asta ai spus-o, verifică-ți cuvintele, nu îți denatur cuvintele, tocmai am făcut o copie / lipire a cuvintelor tale în comentariul 59.

      13.    johnfgs el a spus

        Citez comentariul meu text capo, cel pe care trebuie să-l citești din nou ești tu pentru că nu vrei să înțelegi sau nu știi cum să dezbate. Scoți lucrurile din context și le interpretezi așa cum ți se cântă. Deci, dacă vrei să alegi să trăiești într-o lume în care te simți insultat pentru că argumentele tale sunt contestate, Lennart, Red Hat și Microsoft te persecută, este pentru că alegi să crezi asta.

        Scurt aici pentru că îmi dau seama că nu ești o persoană rezonabilă pentru că nu vrei să înțelegi, vrei să interpretezi lucrurile după cum consideri potrivit.

        Dacă vrei să fii jignit, ofensează-te, dar este problema ta, nu restul lumii.

      14.    yukiteru el a spus

        @juanfgs Nu mă deranjează comentariile voastre, într-adevăr nu văd niciun motiv, ne certăm, oamenii civilizați se ceartă fără să trebuiască să se deranjeze (asta cred eu).

        Acum, dacă îți place să etichetezi, să prejugezi (sau cum vrei să-i spui) oameni pentru discursurile sau acțiunile lor (poate ar trebui să citești comentariul meu # 64 și să măsoare lățimea acestuia), aceasta este problema ta, limitează-te la aceia acțiuni față de tine și lasă-i pe ceilalți în afara acelui sac.

        Salutări.

      15.    xiep el a spus

        „Majoritatea antisistemului”, „aproape tuturor”, „tuturor”, „o parte a antisistemului” ... ne abatem, Mariano, ne abatem. În cazul de față: nu văd nicăieri că Yukiteru a rostit un discurs senzațional bazat pe intuiții (referindu-se la analiza sa în acest fel are ceva răsucit), dimpotrivă, el a dezvoltat argumente solide despre dezavantaje de sistem bazat pe întrebări și materiale adecvate preluate din listele de corespondență și urme de erori (precum și într-un mod politicos și civilizat). Probabil din acest motiv îi irită pe unii și îl atacă la primul comentariu, pentru a-l discredita și descalifica (de data aceasta, într-un mod otrăvitor).

        Dacă vedeți că discursul celor mai mulți antisistem este otrăvitor și vitriolic, ceea ce văd în discursul unor pro-sistemi (nu știu dacă sunt majoritari sau minoritari) este isteria și persecuția celor care, tocmai ei fac argumente solide pe fondul întregului zgomot. Că în țara mea numim disidență hărțuitoare.

        Systemd merge bine pentru tine? Grozav, mi se pare grozav, dar lăsați-i pe cei care nu gândesc la fel să își exprime rezervările (este posibil ca sistemul de operare să nu funcționeze în același mod).

        În ceea ce priveşte

    3.    PAMP el a spus

      O, apropo, de ce este vreo eroare de sistem explodată până la risipa întregii componente, dar altele precum GCC, glibc sau chiar nucleul nu au fost criticate până în acel moment pentru multe dintre bug-urile lor?
      Ai spus-o singur, glibc trage probleme de multă vreme. Llvm a dovedit de-a lungul timpului că are avantaje față de GCC. Și aici nu văd aceeași critică.
      De ce nu facem același lucru cu alte proiecte?
      Este pur și simplu frică colectivă și irațională pentru mine.

      1.    yukiteru el a spus

        Glibc are bug-urile sale pe care nimeni nu le poate ascunde, există bug-uri Glibc uriașe care afectează nucleul și sute de executabile. Diferența dintre Glibc și systemd este că prima este o bază din care MII de proiecte software pot fi transformate în binare, în timp ce systemd este un init, al cărui scop este să fie o piesă stabilă, dovedită și practic infailibilă. Nu numai că, Glibc trebuie să se adapteze la sute de arhitecturi hardware diferite (CPU), la diferite steaguri de optimizare și caracteristici unice ale procesorului, la diferite forme de optimizare software, o muncă mult mai dificilă și mai dificilă decât cea a systemd. Nu prea văd nicio modalitate de a prezenta o comparație între cele două proiecte pe aceeași scară.

        Același lucru este valabil și pentru GCC, GCC este un compilator care, de altfel, acceptă multe limbi (13 în total numărându-le pe cele neoficiale) și are caracteristici foarte asemănătoare cu Glibc, suportând multe arhitecturi (70 arhitecturi pentru versiunea 4.9), semnalizatoare de optimizare binară , Steaguri de optimizare a procesorului și multe alte caracteristici. Acum sunt la același nivel de dificultate, un compilator cu un init. Răspunsul este mai mult decât evident, începând cu acel systemd este în C, iar o mare parte din codul GCC este în asamblare sau trebuie să utilizați asamblorul pentru ca lucrurile să funcționeze în binar, ceva cam „greu de făcut”.

        Ce este în neregulă cu GCC și Glibc? Clar. Chiar și Linus le-a dat atacul său, dar în GCC și Glibc au ceva pozitiv că în sistem sunt adesea uitate și adică un bug raportat, un bug văzut, un bug remediat.

    4.    Rolo el a spus

      - vă rog, cineva să-mi explice: de ce un init ar trebui să aibă controlul asupra:
      rețele (systemd-networkd),
      dns (systemd-networkd),
      m-dns (systemd-networkd), l
      ogi (journald),
      coredumps (systemd-coredump),
      depanări (systemd-coredump și journald),
      acpi (logind), escaladare de privilegii (logind),
      ntp(systemd-timesyncd),
      dev (systemd a luat toate funcționalitățile de la udev),
      de / dev / random (generator de numere aleatorii)
      TTY (consolat de sistem)?

      O temă 100000 repetată și repetată, ceea ce trebuie să spuneți este că systemd poate funcționa fără ele, de fapt în Debian nu există nici măcar jumătate din cele pe care le menționați

      în mod similar, este doar o caracteristică a abordării sale largi

      lennart: Ei bine, systemd împarte ceea ce trebuie să facă în multe componente diferite (peste 90 de binare în zilele noastre). Fiecare rulează cu cele mai puține privilegii posibile.
      Îmi imaginez că nu este o diferență prea mare de coreutils, care are, de asemenea, un număr mare de componente într-un singur pachet. Și coreutils este probabil unul dintre proiectele majore care fac ca Linux să se simtă ca un sistem de operare asemănător UNIX, nu?
      Dar da, systemd este mai complex decât sysvinit, fără îndoială. În ultimii 40 de ani de calcul, multe lucruri s-au schimbat și multe dintre ele necesită de fapt un anumit nivel de complexitate pentru a face față ... Există foarte puțin mod de a rezolva acest lucru.

      Pentru că nu devii atât de fără compromisuri cu freebsd, care face exact același lucru, dar cu instrumentele sale și fără a permite folosirea altora, ceea ce nu este cazul cu systemd.

      - Nu au existat o mulțime de instrumente create în astfel de scopuri pe care systemd le adaugă acum propriile lor, unele cu acces exclusiv (caz Journal)?

      Nu voi nega că tema jurnalului salvează informațiile într-un binar este cel mai slab lucru de apărat, dar nu este sfârșitul lumii, ele pot fi salvate în text simplu

      - Ce explicație logică și acceptabilă îmi dați că o inițiere este capabilă să rupă depanarea kernelului și cmdline?

      Mmmmmmmmmmm …………………. sparge nucleul ……. 5000000 de lucruri pot sparge nucleul

      - Adăugați la acel control asupra kdbus, următorul IPC care va fi integrat în kernel.

      Potrivit lui lennart, acest lucru are o relație pozitivă pentru dezvoltatori, iar systemd va aduce instrumente pentru a deschide dbus administratorilor, va oferi, de asemenea, jurnale și interfețe de magistrală de rețea

      - Cu siguranță îmi vor spune aici: „Dar puteți instala un alt instrument pentru a controla toate acestea”. Și dacă este adevărat, însă, multe dintre aceste instrumente primesc doar un flux de date aruncat de systemd, ca în cazul syslog și rsyslog, ... .. asta înseamnă doar că aveți două instrumente care fac același lucru, iar unul dintre ele este un Cutia Pandorei. (Vă rog să nu-mi spuneți că codul poate fi auditat, deoarece invit pe cineva să „fumeze” codul jurnal și cadrul său cu systemd și alte instrumente conexe)

      aici intrăm în teoria conspirației !!!!! este un software gratuit slab, nimic nu este ascuns

      3.- Ce sistem nu este portabil? Este un alt punct discutabil. În BSD nu funcționează bine, în BSD nu există Cgroups printre alte instrumente pe care systemd trebuie să le ruleze. Dar este pentru un motiv de proiectare sistematică, nu pentru că nu este portabil. Până când kernelul BSD nu îndeplinește minimul pentru a-l suporta, systemd nu va funcționa pe acea platformă și nu este vina nimănui, doar că BSD nu este interesat și nici Lennart nu este.

      Ei bine, acest lucru nu este pe deplin corect, dezvoltatorii de BSD fac ceva similar cu systemd pe care Lennart însuși l-a evidențiat în contul său g +

      https://plus.google.com/115547683951727699051/posts/g78piqXsbKG

      https://www.youtube.com/watch?v=Mri66Uz6-8Y

      4.- Sistemul respectiv nu este monolitic deoarece este împărțit în 69 de binare. Da, bine, acest lucru este discutabil. systemd are 69 de binare, care îndeplinesc sarcini diferite, dar aceste binare transmit informațiile despre sarcină către systemd, deci dacă unul nu reușește, șansele de a sparge sistemul cresc destul de dramatic. Acest lucru este bine documentat, rapoartele de erori abundă în astfel de probleme și chiar și în probleme mai simple, de fapt simple. systemd poate fi împărțit în sute de binare, dar atâta timp cât nucleul dvs. controlează, riscul unei pauze continuă și crește și, dacă nu mă credeți, citiți rapoartele de erori și distrați-vă.

      Dacă utilizați sysvinit și TTY dev acpi ntp sparg și sistemul dvs., nu semănați teroarea.

      Monolitic este freebsd și nu spui nimic

      1.    anonim el a spus

        @rolo
        Acum enumeră-mi care sunt distribuțiile care au luat systemd și au creat acele 90 de binare în pachete separate, ar fi 91 de pachete cu systemd.
        Iar la instalarea systemd nu îmi cere niciunul dintre cele 90 de pachete ca dependențe.

        Serios, și insist din nou ... vă rog să-mi transmiteți opțiunile –configure-help pe care vreau să le fac 91 pachete compilând manual cu make.

        Nu există un orb mai rău decât cel care nu vrea să vadă ... băieți, asta este apă și ulei, se pare că există încă oameni încăpățânați care nu văd realitatea a ceea ce urmărește redhatul.

      2.    yukiteru el a spus

        @rolo Vreau să instalați systemd și să eliminați journald, systemd-udev și coredump și să utilizați direct opțiuni precum eudev și syslog, pentru a vedea dacă puteți.

        Acest comentariu nu m-a putut face să râd mai serios, mor. 😀

        Serios, ei chiar se apucă să citească puțin, în loc să rămână cu bârna în ochi.

      3.    yukiteru el a spus

        În plus, nimeni nu uită că Kay Sievers nu numai că a rupt linia de bază a nucleului, dar a vrut să o închidă, până la urmă „genericul este generic”.

    5.    Dariem el a spus

      Cu alte cuvinte, potrivit dvs., faptul că două procese transmit informații le face atât de cuplate încât faptul că unul eșuează face ca celălalt să aibă o mare probabilitate de eșec ... din care teorie a dezvoltării software ai obținut asta? Sunt de acord cu @pamp că vorbești din frica irațională și părtinitoare.

      Și cealaltă întrebare mare, de ce trebuie să controleze sistemele atât de multe lucruri? Răspuns simplu: pentru că cu sysvinit și cu toate celelalte avantaje inițiale introduse recent în kernel-ul Linux sunt irosite, atâta timp cât nimeni nu le pune să le folosească în spațiul utilizatorului, acestea sunt „supărate” (așa cum spunem în Cuba ... ei bine, irosire) fără nimeni Le folosesc și oferă avantaje foarte bune în utilizarea eficientă a resurselor hardware (CPU, RAM, I / O etc.), inclusiv grupuri c. Ceea ce face systemd este, tocmai, să pună aceste bune funcționalități pe kernel-ul Linux în slujba utilizatorului, dar pentru asta el trebuie să fie cel care pornește acei demoni.

      1.    yukiteru el a spus

        Cred că ai citit și analizat greșit (analiza este importantă) sau pur și simplu nu ți-ai dat șansa să faci asta. Faptul că două procese transmit informații nu este un motiv pentru care un sistem se sparge, totuși, atunci când aveți binare cu acțiune dinamică, cum ar fi controlul rețelei, jurnale sau coredump, transmiterea informațiilor direct la init, lucrurile pot merge prost și vor merge prost, deoarece dacă Unele dintre binare se rup, șansele de a sparge restul sunt mult mai mari, și asta este destul de realist, și s-a întâmplat, kernel-ul cmdline s-a prăbușit recent, problemele acpi pe care le-au avut dezvoltatorii Nvidia datorită systemd-212 , toate acestea sunt un eșantion din ceea ce spun.

      2.    anonim el a spus

        @Dariem
        Dacă nu puteți compila fiecare dintre aceste binare în pachete individuale, forțați acest lucru deoarece doriți să fie instalat unul, trebuie să le instalați pe toate, atunci când le instalați toate se dovedește că călcați pe alte pachete care nu pot fi instalate deoarece piesele din systemd ocupă acele locuri.
        Ce sens are să împărțiți un executabil mare în mai mulți executabili mai mici dacă la final nu aveți un pachet pentru fiecare care vă permite să le instalați individual.
        Mă întorc să fac cererea generală tuturor utilizatorilor avansați de sistem, să-mi spui cum să compilez cele 90 de module și să creez 90 de pachete care, dacă îmi vine să le instalez și altfel folosesc programele pe care le-am folosit.
        Lapte foarte rău toate astea ... se pare că oamenii din systemd cred că toți utilizatorii de gnu / linux sunt proști.
        Pentru înregistrare, folosesc testarea gentoo și în urmă cu câteva luni trecusem la systemd și nu puteam cu journald, ceea ce m-a făcut să revin la openrc mai repede decât a fost nevoie pentru a trece la systemd.
        Pentru a vedea în continuare cum merg lucrurile cu systemd am archlinux pe un notebook care în curând va fi lansat pe gentoo .... Sigur sigur.

      3.    yukiteru el a spus

        @anonim, vreau doar să văd cum va evolua problema TTY în Linux. Când va apărea codul CONFIG_VT, în favoarea împărțirii VT în două părți bine diferențiate (kernelspace și userpace) vom avea nevoie de un instrument pentru a controla VT din spațiul utilizatorilor și acolo consolat de sistem poate juca în a fi o dependență puternică care atrage restul distrugerile cu privire la necesitatea de a instala componentele systemd, doar pentru a face posibilă funcționarea sistemului. Ceea ce spun nu este o exagerare, este o posibilitate foarte, foarte mare și chiar îngrijorătoare. Există și alte proiecte, cum ar fi KMSCon, dar dacă majoritatea desktopurilor și distribuitoarelor sunt în favoarea systemd, lucruri precum KMSCon pot muri mai repede decât cred mulți.

      4.    anonim el a spus

        @Yukiteru 3 decembrie 2014 8:49
        Nu mă tem de asta, domnul Linus nu va elimina opțiunile implicite dintr-o versiune în alta, va pune noul sistem ca fiind NOU și vă va permite să alegeți între obișnuit și nou.
        În ceea ce privește partea din spațiul utilizatorilor, puteți crea un pachet care face asta independent, dacă systemd o face, de ce nu ar mai putea încă 50? În plus, diferitele moduri de a face acest lucru vor face ca diferitele terminale să adopte diferite moduri, toate cu USE de a activa și dezactiva așa cum suntem obișnuiți.
        Același lucru este valabil și pentru kdbus, că Linus o admite în 3.19, așa cum spune, nu înseamnă că va trebui să fie activ da sau da.
        Sunt foarte mulțumit de openbox + compton, desktopurile pentru mine pot să dispară că nu mă vor afecta cel puțin.

      5.    yukiteru el a spus

        @ anonim, întrebarea este că eliminarea CONFIG_VT este ceva care la final va fi total (din ceea ce am citit), adică în nucleu vor rămâne doar primitivele, în timp ce restul instrumentelor vor fi în spațiul utilizatorilor, acest lucru nu este rău, dimpotrivă, va elimina o mulțime de cod vechi din nucleu, va face mai ușor de întreținut și mult mai configurabil (suport complet KMS / DRM pentru consolă). Cu siguranță, la început, vor exista ambele sisteme, dar pe termen lung (15-20 de versiuni) poate ieși din kernel sau chiar mai devreme, multe instrumente nu mai acceptă un astfel de cod în favoarea unui cod mai nou și mai bine acceptat.

        Acum, spui că dacă systemd o face, pentru că încă 50 nu o pot face (îmi imaginez încă 50 de aplicații). Ei bine, dacă vedem dependențele puternice ale KMSCon (cel mai vechi proiect în acest sens) acestea sunt libudev (cod care va fi asociat la systemd în curând, nu va fi acceptat și va intra în conflict cu systemd dacă funcționează singur), libdrm, libxkbcommon, libtsm și systemd în sine pentru a gestiona mai multe locuri, așa că, atunci când vedeți acest lucru, vă dați seama de modul în care lucrurile se conturează luând pentru ele o mulțime de instrumente necesare pentru ca un sistem de operare GNU / Linux să funcționeze fără probleme.

      6.    anonim el a spus

        @Yukiteru 3 decembrie 2014 9:46
        Aici, în gentoo libudev este un punct virtual către sys-fs / eudev, astfel încât oamenii gentoo se vor ocupa de modificarea eudev pentru a se conforma API-ului dictat de noul sistem de nucleu.
        Deci, cred că alte distribuții decât systemd (salut devuan) vor folosi dacă sau dacă eudev.
        Ce s-a întâmplat cu udev-ul original se va întâmpla, systemd l-a înghițit, dar aici nucleul este cel dictat de API pentru interfața cu consolele folosind DRM / KMS .... Am vrut deja să văd un urxvt folosind asta ... hehe
        Ceea ce accept este că oricine folosește systemd nu va avea opțiunea de a schimba nimic ... impunere completă și dură și, așa cum am spus mai înainte ... să plângă la cimitir.

      7.    yukiteru el a spus

        @ anonim, cu siguranță ceea ce spuneți că este cealaltă posibilitate, eudev va lua o forță mai mare în acest sens și va menține opțiunile deschise pentru a alege diferite instrumente.

        PS: După cum spuneți, ar fi interesant să vedeți cum VT ia avantajele KMS / DRM împreună cu fbdev dev

      8.    Dariem el a spus

        Ați repetat exact conceptul pe care v-am criticat-o, pentru că în niciun moment nu am vorbit despre sistem, am vorbit despre comunicarea dintre procese și repet din nou, de unde obțineți acest lucru deoarece două procese comunică, moartea unuia implică faptul că celălalt are posibilități largi de A muri? Explicați-mi cum două procese, care locuiesc în spații de memorie separate, pot influența reciproc comportamentul intern. Să vedem dacă mă explic, din punctul de vedere al unuia dintre aceste procese, accesează doar un mecanism IPC (orice ar fi fost definit pentru a comunica proceselor systemd). Dacă programatorul a fost atât de prost în a nu include cod care poate face față intrărilor și ieșirilor neașteptate, asta este altceva, dar nu are nimic de-a face cu un proces care influențează internele altui. Dacă systemd-networkd se blochează, nu trebuie să omoare journald sau systemd, ca și în cazul vechiului sysvinit, faptul că blocările inetd nu ar trebui să îl afecteze, sunt procese separate.

      9.    yukiteru el a spus

        @dariem a explicat într-un mod simplu pentru a vedea dacă ai ideea:

        Ceea ce spuneți este cu siguranță comportamentul care este întotdeauna așteptat de la programe și procese modulare. Modularitatea a fost implementată în acest scop, acela de a separa două procese și că acestea își ocupă propriile spații de memorie și că comunică prin anumite mijloace (IPC etc.), astfel încât în ​​cazul în care ceva nu merge bine, atunci nu se întâmplă nimic rău. iar sistemul poate continua să funcționeze fără întrerupere. O teorie care a avut cu siguranță un mare sprijin datorită potențialului său și a marjei imense de fiabilitate pe care a acordat-o calculelor actuale. Acum, acest lucru nu este întotdeauna adevărat (viața nu este întotdeauna frumoasă) și cred că ați fost cu siguranță victima acestor evenimente cu o ocazie sau alta (acest lucru este valabil pentru toată lumea, indiferent de sistemul de operare pe care îl utilizați) și vă voi da câteva exemple.

        Primul merge cu Xorg (care este un proces modular la fel ca systemd), care uneori înnebunește cu un driver și doar se blochează și te lasă fără grafică, în timp ce restul sistemului continuă să funcționeze așa cum era de așteptat (Blessed modularity 😀). Până acum, bine, teoria noastră conform căreia procesele modulare nu trebuie să spargă sistemul funcționează bine. Dar (există întotdeauna unele dar) uneori Xorg oferă ceva mai mult decât nebunia și dintr-un motiv ciudat (care poate varia de la controlul mouse-ului la driverul grafic) nu numai că Xorg se blochează, dar vă oferă și cel mai frumos a panicii kernelului (și a unui graffiti pe monitor ca Picasso) pe care ți-l poți imagina și apoi îți dai seama că, oricât de modular este, dacă un proces intercomunicează și schimbă informații / date cu altul și ceva nu merge bine în una dintre ele și, dintr-un anumit motiv, eroarea nu poate fi tratată corect, șansele ca procesele în cauză să fie afectate cresc, pentru simplul fapt că datele sunt greșite sau pur și simplu corupte, și apoi vine catastrofa.

        Dacă credeți că acest lucru nu se poate întâmpla, vă las câteva rapoarte de erori (una este a mea în Debian și are câteva fotografii) despre o eroare veche care se află în Xorg, mesa, nouveau și driverul drm / kms al nucleului, procese care, în ciuda faptului că rulând ** separat și fiind modulare **, împreună nu se înțeleg foarte bine, cel puțin nu în circumstanțe.

        https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742930
        https://bugzilla.redhat.com/show_bug.cgi?id=901816
        https://bugzilla.redhat.com/show_bug.cgi?id=679619

        Acum celălalt exemplu pe care îl voi da cu systemd. Vechiul nostru Sysvinit avea o particularitate că, în ciuda faptului că era vechi, era foarte fiabil, până la punctul că, dacă / etc / fstab avea o intrare de partiție (nu este importantă pentru sistem, înțelegeți un / mnt / Disk160GB) și este nu a putut fi montat dintr-un anumit motiv, suportul a fost pur și simplu omis, v-a dat un mesaj de avertizare și a continuat cu procesul de boot. Acum, systemd este o altă poveste, în ciuda modularității sale, dacă aveți o intrare în / etc / fstab și systemd vede din anumite motive că este imposibil să o montați, nu numai că așteaptă ca partiția să fie disponibilă (comportamentul normal programat) pentru asamblarea sa, dar dacă timpul se termină, sistemul dvs. este oprit și nu puteți face altceva decât să intrați în modul de recuperare și să eliminați acea linie din / etc / fstab, ceva chiar eșuează de fapt. Acest mic detaliu nu mai este în timpul montării automate în boot și întregul proces se oprește, la început (systemd-) micul detaliu a fost mai urât, deoarece tocmai a apărut și a trebuit să reporniți. Cineva care a trecut prin detalii îți spune.

        Un alt exemplu pe care îl pot da este coredumpd în systemd. În mod implicit, coredumpd transmite toate informațiile sale către journal pentru ca acesta din urmă să scrie informațiile captate pe disc, până acum, bine, folosim modularitatea systemd în avantajul nostru. Dar se întâmplă uneori, când coredumps sunt foarte mari, atât de mari, încât pot ocupa câțiva GB, iar în procesul de transmitere a informațiilor de la coredump la journald și apoi pe disc, se întâmplă lucruri ciudate, cum ar fi Xorg nu mai funcționează și chiar nucleul panică. Asta nu se întâmplă numai cu systemd, desigur, dar modul în care este proiectat crește factorul de eșec și creează alte detalii neplăcute (printre care consum crescut de memorie, corupție jurnal, depozite incomplete), oricine a trebuit să lucreze cu un KED coredump, cu siguranță ai ați trecut prin mai multe episoade ca acestea și veți fi înțeles importanța de a avea opțiunea de sincronizare în / etc / fstab pentru partiția de dump și cu siguranță veți urî faptul că nu puteți utiliza o altă opțiune pentru a gestiona dumpurile, dacă ați instalat systemd. Un exemplu de ceea ce se poate întâmpla cu systemd-coredumpd.

        https://bugs.archlinux.org/task/41728

        Acum, pentru a termina:

        Nu ar trebui să fie programe și procese modulare? Da, sunt modulare. Nucleul este singurul lucru monolitic despre care am vorbit aici, dar acceptă și module (LKM), deci ar fi un fel de nucleu hibrid, deși forma sa de proiectare de bază nu este concepută în acel tip de structură și asta îl face un puțin instabil în anumite circumstanțe.

        Modularitatea respectivă nu ar trebui să-mi permită să-mi păstrez procesele și sistemul să nu se blocheze dacă ceva nu merge bine? Este adevărat, modularitatea este o măsură concepută pentru a obține un grad ridicat de stabilitate și fiabilitate, dar nu este o măsură 100% infailibilă, deoarece dacă ceva poate merge prost, pur și simplu va merge prost, oricât de modular ar fi, este o realitate.

        Ce sistem trebuie să aibă controlul asupra tuturor pentru a face posibilă utilizarea cgroup-urilor și a altor opțiuni adăugate la nucleu? Complet fals. Acest lucru nu este deloc necesar, systemd ar fi putut rămâne cu o interfață pentru a controla pornirea și atribuirea cgroupurilor la procesele și demonii care vor fi în sistem, fără a fi nevoie să preia numărul de servicii pe care le are acum și cele mai bune un exemplu în acest sens este; că OpenRC este, de asemenea, capabil să utilizeze grupuri de grupuri și nu din acest motiv invadează așa pentru a îndeplini această sarcină.

        Ce sunt părtinitor și temător când vorbesc despre systemd? Habar n-am de unde obține asta, pentru că, pe măsură ce vedeți răspunsul meu, nu mă tem de asta, vorbesc doar despre aspecte care nu-mi plac despre systemd și deja, fără să mă bazez pe opiniile unor terți.

        În cele din urmă, spuneți că: "Dacă programatorul a fost atât de prost în a nu include cod care poate face față intrărilor și ieșirilor neașteptate, asta este altceva ..."

        Cu siguranță, a spune că programatorul pentru faptul că nu include un cod care gestionează TOATE modalitățile posibile prin care programul său poate fi rupt de o anumită introducere de date eronată este RĂU, mi se pare o revoltă. Indiferent cât de bun este un programator, o persoană nu este în măsură să proiecteze un program infailibil și sigur, va exista întotdeauna un eșec, care într-un fel sau altul va ieși la lumină și, atunci când va fi, va fi datorită unei eșecuri aleatorii în timpul utilizarea, de către un hacker sau cracker care exploatează o vulnerabilitate, printr-o revizuire și audit de cod sau prin orice alte mijloace pe care programatorul se poate baza. Mai bine să măsoare cuvintele înainte de a spune așa ceva.

        Salutări.

      10.    Dariem el a spus

        Exemplul pe care îl dați despre Xorg este cel mai puțin adecvat, deoarece toți cei care au suferit tranziția la KMS / DRM știu că problema este cauzată de erori în modulele kernel pentru a controla KMS furnizate de dezvoltatorii driverelor Xorg. O eroare într-un modul KMS este aceeași cu o panică a nucleului, nu are nimic de-a face cu comunicarea între procese, deoarece în acest caz Xorg efectuează un apel de sistem (syscall), astfel încât nucleul să schimbe modul de ecran, adică există un singur proces implicat (Xorg) care apelează nucleul, nimic de-a face cu ceea ce avem de-a face aici.

        Comportamentul actual al systemd atunci când nu găsește punctul de montare este irelevant, indiferent de faptul că este o funcționalitate pe care cineva ar putea să nu-i placă, care se rezolvă cerând să sprijine celălalt comportament, acela de a ignora montarea eșuată. Coredump-ul care a avut loc anterior s-ar putea datora unor cauze diferite despre care s-ar putea specula doar, dar faptul că execuția nu a continuat se poate datora unui comportament dorit, din moment ce spuneți că a trebuit repornită, nu că a existat o panica kernelului sau o repornire automată. Deoarece nu am trecut prin asta, nu-mi pot da o părere.

        În ceea ce privește problema pe care ați pus-o cu systemd-coredumpd și legătura către raportul de eroare, totul indică faptul că această problemă în Arch Linux s-a datorat compresiei pe care au activat-o systemd când au compilat-o pentru distribuția respectivă. Arată mai mult ca o problemă cu algoritmul de compresie decât cu systemd în sine. Sistemul de operare nu se blochează, mai degrabă algoritmul de compresie folosit pentru a stoca coredump-urile pare să dreneze sistemul și aceasta este vina dezvoltatorilor Arch Linux care au compilat systemd. Cu toate acestea, systemd are setări pentru a limita consumul de resurse și pentru a activa / dezactiva captarea tuturor coredump-urilor raportate de nucleu. Poate că ar trebui să aruncăm o privire asupra celor care întrețin sistemele Arch și cei care folosesc KDE.

        Spuneți că OpenRC folosește și cgroupuri fără a fi invaziv. Problema este următoarea: cum recunoaște OpenRC numele executabilelor daemon pentru a ști exact care alocare de resurse este cea mai potrivită? Nu sunt foarte sigur dacă acesta este unul dintre motivele pentru care systemd se ocupă de atâtea lucruri, oferind executabililor un nume bine cunoscut, dar bănuiesc că lucrul merge așa. În plus, elimină povara de a avea liniuță la mijloc pentru a rula fiecare dintre aceste servicii, invocând direct executabilele.

        Nu voi nega faptul că systemd poate avea multe bug-uri, dar de acolo pentru a le atribui pe toate modului în care este conceput, nu cred. În cazul sysvinit, a fost foarte stabil, un software matur, systemd tocmai a început.

  12.   Rafael Mardechai el a spus

    Cum sparg bilele cu systemD, xD Dacă îl urăști atât de mult, creează-ți propria distribuție, ceea ce este software-ul gratuit pentru é_é

    1.    Alexandru cel Mare el a spus

      Nu este vorba de ură, ci de apărarea comunității tale.
      Apropo dacă există distribuții „Subteran” independent:
      http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
      Respectă

  13.   wows el a spus

    pentru că comparați totul cu Microsoft că se comportă ca Windows .. dacă lucrurile funcționează bine și este pentru dezvoltarea și evoluția linux care este problema ... fiecare proiect la început poate avea erori de schimbare dacă programele software etc. ar fi perfecte, Suntem oameni, dar de aceea avem greșeli.

    că dacă systemd eșuează, sistemul se va prăbuși ... și dacă nucleul, xorg, grub eșuează ... există oameni care, actualizând nucleul de pe computer sau laptop, pierd sistemul ... atunci pentru că insistența asupra perfecțiunea a ceva ...

    ca și cum orice sistem care a ieșit nu ar fi avut erori bug-uri sau ceva la începuturile sale sau chiar în maturitate ar avea eșecuri

  14.   lf el a spus

    Systemd a fost impus ca standard cu joc murdar, este o dependență obligatorie pentru multe pachete, deoarece multe programe au fost absorbite de systemd fie pentru că le-au întreținut, fie pentru că le-au eliminat încet, deoarece nu mai erau relevante, deoarece systemd a furnizat deja ceva similar.
    Acest lucru limitează libertatea de alegere, adică distribuțiile nu pot alege să nu folosească systemd, pot încerca să reziste ca gentoo, dar aceasta este mai mult o soluție temporară la systemd, openrc este doar un manager de servicii acceptat de sysv pentru init și în distro initscripts, systemd oferă mai multe funcționalități decât openrc și are funcționalități noi în fiecare zi. Noul software acceptă systemd și necesită implementarea a ceva similar, care ajunge să facă celelalte inits mai complexe și mai asemănătoare cu systemd, ceea ce nu doriți.
    Systemd face multe lucruri în comparație cu vechiul init care pur și simplu citește câteva linii din / etc / inittab și apoi încarcă fiecare dintre initscripts și configurațiile lor în funcție de nivelul de execuție. Vechea abordare era mult mai simplă și mai independentă. Suntem într-o etapă de tranziție către o nouă eră a omogenității, nu există nicio soluție, modul în care predomină este de neoprit.
    În câțiva ani nu va exista practic nicio diferență între utilizarea debian, utilizarea arch sau fedora, identitatea fiecărei distro se va pierde dacă vom continua astfel și systemd va deveni mai intruziv în fiecare zi, încât va deveni chiar parte a numelui sistemului (systemd / gnu / linux)

    1.    MSX el a spus

      LOL

      A plânge către biserică>: D

  15.   MSX el a spus
    1.    lf el a spus

      Problema este că sunteți argentinian (la fel și eu), dar modul de exprimare a faptului că majoritatea utilizatorilor argentinieni de Linux pe care i-am citit este cu adevărat îngrijorător, deși se spune și că lumea software-ului liber atrage anumite persoane. Ceea ce salvez este că nu vă presupuneți că sunteți argentinian, dar, din păcate, arată ligile.

    2.    x11tete11x el a spus

      uyyuyy .. băiatul acela a căzut cu artilerie grea ..

    3.    WACOS el a spus

      comentariu puternic !!

    4.    rawBasic el a spus

      Juju .. ..pochoclos .. xD

  16.   Tito el a spus

    Din acest articol rezultă că tot ceea ce fac este să „impună” un sistem. Nu intru pentru a evalua dacă este mai bine (ceea ce nu este) sau mai rău. Ceea ce spun, repet, subliniez și subliniez, este că nu vreau cu adevărat să mi se impună nimic.
    Expresii precum: „Pur și simplu nu le folosim pentru procesul de pornire, deoarece credem că nu sunt cel mai bun instrument pentru acest scop specific”.
    Și cine ești tu să-mi spui dacă vreau să folosesc acest instrument sau altul?
    Acolo fiecare. Pur și simplu nu îl folosesc, punct și, deși nu pot, nu o voi face.
    Semnat. Un taliban.
    (Mă amuză clovnul)

  17.   kuktos el a spus

    de multe ori o durere de cap cu acel subiect !!!! X_X

  18.   tabris el a spus

    Gestionam servere cu Centos 6 și mergeam la 7 cu systemd nu mă costa nimic, nu plânge, viața merge mai departe.

  19.   glume el a spus

    Scuzați-mă, dar citesc o mulțime de lucruri care îmi amintesc de discursul clasic „Windows Server - Certified Man VS server Linux - OpenSource Man”.

    Primul - Veți vedea, dacă forțați o eroare, este normal să eșueze. Fiecare dintre videoclipurile pe care le-am văzut sunt erori forțate. Parcă fac un program care introduce cuvinte cheie în jurnalul syslog și în același timp încerc să execut un script bazat pe grep pentru a extrage informații din jurnal ... bineînțeles că va eșua, am provocat-o.

    Este ca și cum ai turna zahăr într-un motor diesel și ai spune „Uite ... benzina e mai bună !!!” sau la fel ca Windows, scrieți un fișier de configurare greșit și plângeți-vă că demonul nu începe să spună „cu Windows acest lucru nu se întâmplă”.

    Al doilea - Sistemul respectiv încorporează multe lucruri pe care poate nu le veți folosi? Ei bine, care este problema? Este că este același argument gol folosit de Windows față de Linux ... „De ce vreau ca un text simplu să pună o mie și una de opțiuni atunci când nu le veți folosi?”

    Încă îi aud pe băieții IBM cu programele lor monilitice latrând cu ani în urmă despre mysql când am citit câteva lucruri. Mulțumesc și aplaud diversitatea GNU / Linux și a comunității sale. Dacă îmi dai 50 de moduri de a face ceva, voi alege în fiecare moment cea care funcționează cel mai bine pentru mine sau se potrivește cu ceea ce am nevoie. Chiar vedeți o problemă în asta?

    În al treilea rând - După nivelul conversațiilor, deduc că aveți un nivel suficient pentru a lucra cu orice distribuție sau pentru a vă configura propria dvs. și a o menține singur. De ce doriți să puneți systemd și să eliminați lucrurile din acesta? Nu este mai ușor să continuați cu init sau openRC?

    Oamenilor care mi-au cerut să-i învăț elementele de bază ale linuxului le spun mereu același lucru ... GNU / LINUX nu este WINDOWS, nu încercați să faceți aceleași lucruri sau să gândiți parcă ar fi fost. De ce asimilezi că sistemd este același cu initd sau că funcționează la fel? Nu este mai ușor să asimilezi funcționarea systemd și să-i folosești potențialul decât să încerci să faci funcții precum init sau OpenRC? Este normal să nu vă placă.

    4 - Ce este în neregulă cu complexitatea? Cu siguranță vă mai amintiți când ați dat programare liniară și cu siguranță că la un moment dat ați spus ... „Și de ce vreau să învăț să lucrez la obiecte dacă acum pot face totul și altfel mă lasă să folosesc?” ... (facepalmul câteva luni mai târziu este minunat dacă xD)

    Să fim clari. Initul curent (și includ systemd) au multe neajunsuri care pot fi completate doar prin adăugarea de complexitate. Nu există altul, deoarece pentru ca un sistem interconectat să crească, acesta trebuie să crească în complexitate cu riscul de a avea o parte slabă, dar este mai bine decât să rămână stagnat.

    Este nevoie de un drum lung de parcurs și dacă ... sistemd nu este soluția la toate. Dar nici unul nu rămâne cu SysVinit.

    1.    glumele el a spus

      PS: Observați ironia că am folosit computerul colegului meu „Mă agăț de apărătorul Windows-Server”, astfel încât acesta să-l poată citi de altfel. xD

      Un singur lucru, apărătorilor altor INIT-uri care oferă date tehnice și linkuri ... CHAPO !!! Îmi place să văd argumente și date de genul acesta. Doar o notă, datele anterioare lunii octombrie 2014 sunt doar istorice.

      Multe lucruri despre care se discută au fost deja remediate și multe teste publicate în 2013 au fost deja revizuite.

  20.   SynFlag el a spus

    @rolo

    Dacă este adevărat, dacă ai văzut videoclipul, ceea ce NU ai făcut, poți vedea că jurnalul este de 8 MB, nimic mai mult și așa mai departe și totul este corupt, apropo, poți trimite rezultatul journald către syslog in text simplu? Da, dar chiar și așa dacă atingeți jurnalele create de journald, asta se întâmplă, sistemul se blochează și, este de înțeles, să vedem, jurnalul se blochează pe PID1 împreună cu lucruri la fel de complexe ca systemd, eșuează, vedeți că nu au o parte din cod care nu permite editarea pentru altceva decât același PID al revistei, precum și nu are capacitatea de a continua să scrieți dincolo de jurnal, este corupt, ceea ce arată că, pe lângă gândirea în modul Windows, LP este un programator prost.

    Nu-mi spuneți că va fi doar în centos, cea mai stabilă versiune a distro care folosește systemd, clona RHEL7 și nu raportez sau intenționez să raportez eroarea.

    Adevărul este că, cu cât citesc mai mult comentariile pro sistem, îmi dau seama că ele sunt într-adevăr ca o religie, sau că sunteți în favoarea sau că sunteți dușmanul, dar, dintre acele religii de tip ISIL, cele ale statului islamic, total extremist, de fapt, știu din experiență, iubitori de sisteme, ei cred asta, sau ești cu ei sau ești dușmanul. Asta este ceea ce Lennart promovează cu aroganța lui și vă rog, nu mă jucați cu Linus care îl susține, systemd nu era acesta, NU A FOST, am folosit systemd imediat ce a apărut în Fedora 15 și a fost doar un init mai rapid, nu a înlocuit modularitatea GNU / Linux.

    Dacă ucid rsyslog, îi corup jurnalele sau îl înlocuiesc cu un desen, nimic altceva, doar că am rămas fără jurnal, nu se blochează nimic, sistemul nu este afectat.

    @Rafael Mardojai

    Asta face Devuan, asta a făcut Void Linux și alții care stau departe de systemd.

    @Yukiteru

    Cu siguranță nimeni nu te citește, așa cum îmi spun talibanii, nu te citesc pentru că folosești Windows sau ai comentat din asta și pentru că eu cred că puțini dintre iubitorii de sistem înțeleg partea tehnică a ceea ce spui și acolo se află problema.

    ======

    Adevărul este că încă mai cred că o persoană cunoscută în 2006 avea dreptate în legătură cu ceva:

    „Nu vreau ca oamenii să folosească Linux sau să-l știe, acești tipi Ubuntu au mingile pline”

    Eu- "De ce?"

    „Când ceva devine cunoscut și pentru masă, se cade, se fute și există o mulțime de mostre din el”

    Eu- "care?"

    „Uite ce s-a întâmplat cu Debian, acum are un fiu prostesc numit Ubuntu și amintește-ți în câțiva ani că vom avea„ hackeri ”și„ geeks ”care au supt Ubuntu și nu vor ști cum să distingă Ext3 de NTFS”

    Ceva era în regulă ... systemd triumfă printre cei care știu, așa cum spune Allan McRae, pentru că nu-i pasă cum pornește mașina sa, pentru el este, butonul, magia și am o solicitare. Printre cei care nu sunt interesați de mai mult decât să „lucreze” cu funcții frumoase, total, pentru server, utilizează LFS sau Gentoo sau BSD într-adevăr și apoi cei care îl adoră, deoarece pornesc mai repede computerul cu lumini colorate, sunete frumoase și jocuri de noroc , dar nu știu ce este un apel.

    1.    yukiteru el a spus

      @SynFlag, dacă nu o citesc, este din proprie decizie, în ceea ce privește sistemul de operare pe care îl folosesc, dacă sunt la munca mea și comentez de pe un PC cu Windows, este pentru că este singurul lucru pe care îl am la îndemână, cu excepția serverului care este în Debian Wheezy și evident de pe server nu pot comenta aici.

      Chiar și acasă am fost forțat să folosesc PC-ul surorii mele pentru că PC-ul meu a murit (MB și sursa de alimentare au conspirat împotriva mea) și chiar și atunci când am timp, montez un LiveCD și folosesc Sabayon (cu OpenRC ) să comentez aici, așa cum fac exact când scriu aceste cuvinte.

      Acum, dacă îmi spun sau cred că sunt un taliban antisistem, asta nu contează pentru mine. După cum am spus, am folosit systemd și știu că piciorul șchiopătează, nu numai asta, de obicei citesc mult lista systemd pentru a afla lucruri care vin în versiuni noi și, de asemenea, pentru a fi conștient de modificările care se fac și a discuțiilor care au loc acolo. Acum, dacă vreun iubitor de sistem înțelege aspectul tehnic despre ceea ce vorbesc și am pus în link-urile mele (linkurile către repo sistem git repo), și chiar și atunci nu poate vedea realitatea, asta îmi permite doar să cred că vând în ochii lor și extremismul în modul lor de a vedea / gândi / simți / iubi / glorifica / lăuda / închina sistemul este atât de grozav încât nu contează dacă chiar Linus însuși dă afară din sistem ****, ei vor să fie încă înrădăcinați în ideile lor că sunt corecte.

  21.   Ezechiel el a spus

    Salut! Nu sunt foarte expert și aș vrea să știu la ce servește acest „systemd” și de ce se vorbește atât de mult, care este problema și ce alternativă există? Mulțumiri

  22.   Tito el a spus

    Comentariul SynFlag! Sunt de la „geeks”, „geeks” și „pro linuxeros” la același lucru.
    Și acesta este viitorul care ne așteaptă; Ubuntu chiar și în supă; Laptopuri Linux pentru a accesa doar Steam și a juca cel mai recent joc fierbinte. Și legiuni de mici geeks care nu știu despre ce este păstăia.
    Postscript: conceptul de fundal al lui systemd e de rahat.

  23.   Hannibal Smith el a spus

    butoanele adk și forum nu sunt vizibile pe pagina principală

  24.   Dariem el a spus

    Deci, conform @SynFlag, acum toți cei care nu sunt anti-systemd sunt un fanatic religios n00b, extremist și ciuma care corupe GNU / Linux. Cu o părere la fel de îngustă ca aceasta, nu știu dacă merită dezbătută această temă. Mai bine lăsați apa să curgă și pe termen lung se va întâmpla ceea ce trebuie să se întâmple.

    1.    Rolo el a spus

      Este adevărat, vine un punct care nu mai poate fi discutat. numai timpul ne va spune dacă sytemd va fi ceva pozitiv pentru lumea software-ului liber sau nu.

      De asemenea, îmi dă ideea că, dacă această distribuție bazată pe debian, care nu va folosi systemd, se va realiza, va ajuta la calmarea spiritelor celor care nu vor să știe nimic despre systemd.

      ca atunci când a apărut gnome 3 și s-a construit o rezistență extraordinară, până când a apărut scorțișoara „furculiță” și unitatea, permițând continuarea utilizării aplicațiilor gnome pe un desktop cu mai multe configurații și un design mai gândit pentru computer și nu atât pentru atingere

      1.    xiep el a spus

        Poate că asta, Rolo (apariția lui Devuan), poate fi un punct de consens. Cred că toți avem nevoie de el pentru a conține o atmosferă de discuție polarizată și belicoasă. Devuan va fi un spațiu pentru crearea și continuitatea unui mod de a face și care va ajuta la calmarea spiritelor. Procesul pe care l-am trăit în Debian a fost dureros, cu toate acestea trebuie să ne confruntăm cu situația, nu există altă opțiune decât să acceptăm separarea. Acest lucru ajunge să fie un pic ca divorțurile. Această forță poate fi o transcriere a unui tratat de pace și o parte a acestuia. Existau alternative, desigur, Slackware, Gentoo, Funtoo, Crux, PCLinux OS, acum Manjaro (pentru a numi câteva) ... dar scena „deb” necesită o alternativă fără systemd. Se pare clar că nimeni nu va convinge pe nimeni, argumentele sunt pe masă și nu există un consens (în ciuda faptului că systemd are idei bune și pericolele pe care le presupune acest software sunt evidente). Este timpul să bifurcați și să obțineți libertatea utilizatorului (pentru că este vorba despre software-ul liber, nu?).

        Un factor care a influențat procesul a fost sentimentul „dezamăgirii” din partea unora dintre noi care ne punem încrederea în Debian. De aceea Devuan este prezentat ca o furculiță și nu ca un derivat. Există tensiune pentru că nimănui nu-i place ce s-a întâmplat; nici pro-systemd (de aici anumite atacuri furioase care încearcă să defăimeze) și nici anti-systemd (care au optat pentru furcă). În mediul înconjurător este „cât talent putem pierde?”, Atât pe de o parte, cât și pe de altă parte.

        Toți utilizatorii Debian privesc distro într-un anumit mod (acest lucru poate fi aplicat și altor distribuții). Există cei care îi admiră calitatea tehnică, alții contractul său social, influența sa în lumea Linux, respectul pe care l-a câștigat de-a lungul anilor, stabilitatea sa în mediile critice de producție ... La unii utilizatori această percepție s-a modificat, apărând dezamăgirea. Dezamăgire, dezamăgire, numiți-o așa cum doriți. De acolo până la separare există doar un mic pas.

        Divorțul Debian este similar cu ceea ce s-a întâmplat cu NetBSD și OpenBSD. Deși timpul ne va spune. Văd o mulțime de așteptări în furcă și asta mă face să cred că nu va fi o distribuție trecătoare și sterilă. Chiar astăzi a existat un membru al echipei gnome care a comentat lista de discuții a lui Devuan (chiar dacă a făcut-o stângaci), acest lucru, în opinia mea, sugerează că Devuan generează interes și vrea, într-un fel, să dialogheze.

        Oricum, weekend bun.

      2.    SynFlag el a spus

        @rolo

        Pentru a spune că videoclipul poate fi păcălit sau software-ul este o eroare totală și o insultă, în viața mea PU ** am păcălit ceva pentru a crea un mit, niciodată, mă laud că am văzut acel eșec prin mijloacele mele, nu prin trucurile mele. Toți merg la **** decât la ***** și nu am de gând să pun mai mult în dezbateri sistematice pentru că este total la fart, nimeni nu vrea să înțeleagă nimic și totul este ca o relegie, ceea ce, urăsc, pentru că totul este prin dogma credinței. Fii fericit cu systemd.

      3.    Rolo el a spus

        @SynFlag violența minte

        Ce demonstrează acest videoclip este falsitatea afirmației că, dacă unul dintre modulele systemd este distrus, acesta face ca systemd să se blocheze, deoarece evident, din ceea ce arată videoclipul dvs. care nu s-a întâmplat, xddddd și apropo jurnalul rulează ca root, prin urmare, dacă un terț intră și aruncă cu răutate binarul jurnalului jurnalului, nu m-aș îngrijora de sistem, ci mai degrabă de securitatea computerului. xdddddd. În cele din urmă, la subiectul videoclipului, reproduceți ceea ce este afișat editând cu nano fișierul /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal și când reporniți, constatați că există un nou sistem.journal și un sistem @@ 24f02f5b2b16758edQ820b @6. jurnal care este binarul corupt.

        Adică, jurnalul își dă seama că fișierul este corupt, deci nu îl redenumește și creează unul nou, nu văd care este problema ?, La fel ca și dacă fișierul system.journal este șters, jurnalul îl întoarce la crea.

        Mă întreb ce s-ar întâmpla dacă aș ruina un fișier jurnal text simplu cu un editor hexazecimal, cu siguranță până când cineva își dă seama că fișierul a fost corupt toate datele ar fi distruse Oo

        Să vorbim puțin despre jurnal, care este una dintre cele mai frecvente critici la adresa systemd.
        jurnalul este o componentă foarte importantă a systemd, care captează mesajele Syslog, mesajele jurnalului kernel-ului, RAM și mesajele inițiale de boot, precum și mesajele scrise în STDOUT / TDERR și pune toate aceste informații la dispoziția utilizatorului.

        Dar cel mai important, jurnalul poate fi folosit în paralel sau ca înlocuitor pentru un daemon syslog tradițional, cum ar fi rsyslog sau syslog-ng, prin urmare un sysadmin prudent ar putea avea rsyslog sau syslog-ng ca al doilea instrument de interogare, în afară de transformarea înregistrărilor jurnalului în text simplu, în cazul în care binarul se deteriorează

        Un alt fapt important despre jurnal este că, dacă folderul / var / log / journal nu este creat, informațiile sunt salvate doar temporar, care se pierd cu fiecare repornire.
        de exemplu, când am introdus systemd în debian, persistența jurnalului nu era activă, așa că a trebuit să creez manual folderul jurnal

        http://0pointer.net/blog/projects/journalctl.html

  25.   anonim el a spus

    Cei care știu limba engleză nu pot rata discuțiile care au loc între dezvoltatorii de devuan, jaromil dimkr max2344, printre altele, pe canalul IRC freenode #devuan.
    Foarte distractiv citind investigațiile codului systemd, deoarece l-au răspândit intenționat pentru a infecta (crea dependențe inutile).

  26.   sircacaroto el a spus

    Systemd mă deranjează ... chiar din față ... e greu. Puțină documentație sau nenorocitul de subțire rulează doar KDM sau gdm și într-un sistem ușor vreau ca lxdm subțire să nu o suporte sau să o compileze ... Serios că, chiar înainte, eram fericit că ar trebui. Adevărul este că am început să folosesc openrc așa cum se spune în gentoo și a ajutat ... Mult

  27.   sinflag el a spus

    @rolo

    Sunteți un jignitor insolent și de știri care spune asta. Este cea mai gravă insultă pe care mi-o spui că mint sau falsific datele, chiar mă dezgustă cum, pentru a apăra ceva, ataci oamenii care fac PoC serios ca mine. Jurnalul este corupt, sistemul se blochează, repornirea serviciului nu funcționează, deci nu există altă opțiune decât să reporniți mașina, care nu este cea mai bună într-un server piratat, îmi veți spune că, dacă securitatea a fost compromisă, cel mai bun lucru este să reporniți sau să reinstalați și este singurul lucru pe care ar trebui să-mi fac griji, deoarece sistemul spune că se scuză și nu fac o analiză fierbinte a CE S-A ÎNTÂMPLAT? pentru a ajunge la acel punct? Evident că sunteți încă un produs al noului sysadmin dacă ajungeți la ceea ce a fost crescut folosind Ubuntu și are securitatea unui DOS 5.0 pe computerul dvs., așa că ceea ce spuneți îl iau de la cine provine, mă deranjează că vă îndoiți de asemenea Cel care falsifică ești tu, ai răspuns la același sistem de operare cu actualizările din acea zi? Sigur că nu, așa că încearcă un alt mincinos. Ce lipsă de capacitate aveți, mergeți la muncă ca șofer de taxi pentru mai mult decât atât, mă îndoiesc că vă va oferi, nu mai jucați cu Linux și continuați să căutați pr0n

    1.    Rolo el a spus

      Să vedem porumbel (synflag), tată vă va arăta cum să obțineți jurnalul să continue să funcționeze după ce fișierul nostru jurnal de jurnal binar este corupt din anumite motive, fără a fi nevoie să reporniți computerul.

      În acest exemplu pornim de la o instalare de bază a debian 8 jessie.

      În mod implicit, systemd-journal.service vine cu funcția „storage = auto”, prin urmare, pentru a avea o înregistrare persistentă a jurnalelor, este necesar să creați fișierul în / var / log / journal / anterior.

      # mkdir -p / var / log / journal /

      Pentru ca jurnalul să înceapă să scrie jurnalele, NU trebuie să reporniți computerul, trebuie doar să faceți:

      # systemctl reîncarcă systemd-journal.service
      o
      # systemctl force-reload systemd-journal.service

      ### acum vom simula că jurnalul binar al jurnalului este deteriorat ###

      # cd / var / log / journal
      #ls
      24f02f5b2b19808b820ea0a980ed6efb
      # cd 24f02f5b2b19808b820ea0a980ed6efb
      # nano system.jurnal
      ### acum modificăm o linie a fișierului pentru a simula că este corupt
      # jurnalctl
      ### așa cum era de așteptat nu se întâmplă nimic
      #### computerul trebuie repornit pentru ca jurnalul să creeze un nou binar? NU
      # systemctl force-reload systemd-journal.service
      #ls
      system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
      sistem.jurnal
      # jurnalctl
      ### După cum putem vedea, jurnalul creează un nou fișier jurnal binar și acum putem accesa din nou informațiile fără a fi nevoie să reporniți computerul în orice moment

      https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be

      concluzie: synflag sau ești ignorant sau ești un fabler
      lasa-l sa te garniseasca finit

      1.    Rolo el a spus

        pentru erori de tastare și abuz de copiere și lipire am scris systemd-journal.service când în realitate serviciul se numește systemd-journald.service

      2.    SynFlag el a spus

        Pichon?, ... cât de greșit ești slab, serios .. Știam deja asta, raportează bug-ul cu pălărie roșie pentru a vedea ce au spus, voi da răspuns, să văd dacă prindeți:

        Dacă eliminați fișierul de ieșire sau suprascrieți părți ale fișierului, demonul nu poate face cu adevărat nimic în acest sens: dacă un atacator are permisiunile de a modifica fișierul de ieșire, ea a câștigat deja. Demonul ar putea verifica unele dintre aceste lucruri, dar acest lucru ar fi destul de ineficient și nu ar fi cu adevărat util pentru nimic. Dacă doriți, puteți configura o semnătură criptografică periodică cu „journalctl –setup-keys”. Consultați pagina manuală journalctl.

        Journalctl depinde de rsyslog, nu se repornește singur în cazul unei erori în jurnal, de care rsyslog nu are nevoie, total, trebuie să folosiți fordward pentru a trimite rsyslog și în acest fel este scris în ciuda a tot și jurnalul de jurnal este regenerat , este un defect de design al revistei, dacă nu vrei să-l vezi, suflă-mă.

      3.    anonim el a spus

        @rolo

        În videoclip (nu știu dacă ați făcut-o) văd că la minutul 2:11 se folosește ls și nu ls -l ceea ce ar permite să vedeți dimensiunea pe care a avut-o inițial fișierul system.journal, apoi îl editează cu nano și adaugă Linii goale, reporniți serviciul manual și la minutul 3:15 fac din nou ls și nu ls -l, apoi la minutul 3:20 văd jurnalul cu journalctl, acesta arată jurnalul curent, care este bine.

        Acum vin întrebările mele:
        1 - deoarece ls este folosit și nu ls -l, pentru a putea vedea dimensiunea originală pe care jurnalul o avea înainte de a fi editată
        2 - ce s-a întâmplat cu vechiul buștean? unde l-a pus systemd în jurnalul binar corupt?
        3 - cu care comandă systemd puteți repara jurnalul binar corupt ... pe care nu ar trebui să îl ștergeți

        În ceea ce priveşte

      4.    Rolo el a spus

        @anonim

        Acum vin întrebările mele:
        1 - deoarece ls este folosit și nu ls -l, pentru a putea vedea dimensiunea originală pe care jurnalul o avea înainte de a fi editată
        2 - ce s-a întâmplat cu vechiul buștean? unde l-a pus systemd în jurnalul binar corupt?
        3 - cu care comandă systemd puteți repara jurnalul binar corupt ... pe care nu ar trebui să îl ștergeți

        1 Adevărul că nu m-am gândit la asta, folosiți doar ls pentru a vedea ce fișiere erau în director, dar dacă sunteți interesat, îl puteți replica, procedura este detaliată și o fac în virtualbox (instalarea unei baze debian este o bucată de tort)
        2 vechiul jurnal rămâne în același director, doar systemd îl redenumește cu o grămadă de numere și litere (prezentate în videoclip)
        3 În orice caz, ați putea încerca să utilizați aplicații de la terți (presupun un editor hexagonal), deoarece dacă systemd ar putea repara fișierul corupt, nu l-ar redenumi sau nu ar crea unul nou. În orice caz, și așa cum am menționat deja cu alte ocazii în această postare, un administrator sysad poate folosi rsyslog sau syslog-ng ca un al doilea instrument de interogare, în afară de transformarea înregistrărilor jurnalului în text simplu, în cazul în care binarul se deteriorează. .

        Adică nu este ideea de a convinge pe cineva să folosească systemd (chiar mi-ar plăcea să am posibilitatea de a alege int-ul în programul de instalare debian). dar nu voi rămâne tăcut când citesc ignoranți sau fabuloși care repetă minciuni despre systemd, deoarece există un blog, când se vede că acele ziceri nu coincid cu realitatea. și, așa cum a spus Aristotel, singurul adevăr este realitatea 😉

  28.   anonim el a spus

    @rolo

    M-am uitat din nou la videoclip și dacă, acolo a fost listat, doar că numele numeric a fost atât de lung încât l-am văzut, am crezut că acesta este directorul ... Numele suveran.
    În ceea ce privește repararea binarului, da, este logic ce spui tu ... dacă aș putea repara nu aș crea unul nou.
    În cele din urmă, am rămas cu faptul că nu ar trebui să fie un binar, astfel încât acest lucru să nu se întâmple și să îl pot vedea fără instrumente speciale cu journalctl ... încă nu înțeleg ce l-a determinat să utilizeze un format binar.

    Salutări și mulțumiri pentru răspuns

    1.    SynFlag el a spus

      Rolo, dedică-te altceva:

      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393

      Știam asta fără să știu că ... Cum observați diferența dintre unul care încearcă lucruri și altul care face doar videoclipuri de tip fart

  29.   SynFlag el a spus

    Am venit să închid ocote de Rolo, eroarea care se vede în PoC-ul meu a fost raportată, așa că, închideți pichonul ocote:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393

  30.   Rolo el a spus

    Să vedem fabulos:
    1 Ați declarat că, pentru ca jurnalul să rezolve problema, a fost necesar să reporniți computerul ca în Windows TOTAL FALS
    Ți-am arătat că asta a fost o minciună și în videoclipul pe care l-ai făcut în niciun moment folosești comanda systemctl force-reload systemd-journald.service deoarece, dacă l-ai fi folosit, argumentul tău s-ar prăbuși (sau nu știai comanda) , care ar arăta că sunteți un ignorant sau intenționat nu l-ați folosit, ceea ce ar arăta că sunteți un povestitor)

    2 Spuneți că există rapoarte de erori, pe de o parte este total irelevant, deoarece de obicei oamenii raportează o mulțime de prostii ca o eroare (astfel încât să înțelegeți că nu fiecare raport de eroare este o eroare reală) îmi dă chiar ideea că a raportat și tu același lucru. Și, pe de altă parte, toate programele au erori (câte erori raportate are sysvinit (un program vechi de aproximativ 20 de ani)) și lucrul bun al raportului este că ajută dezvoltatorii să descopere și să rezolve problemele (unele mai rapide , altele mai încet)

    3 Spuneți că, cu eroarea pe care o generați în jurnal, când reporniți systemd, se blochează, deoarece în videoclip puteți vedea că trebuie să reporniți cu forță caseta virtuală. COMPLET FALS
    Adevărul este că systemd nu se blochează, deoarece sistemul pornește perfect (dacă nu pornește systemd, ți-ar da o panică de nucleu și ar trebui să intri în modul de recuperare)
    Ceea ce vi se întâmplă este că sistemul este verificat atunci când încercați să editați un binar cu un editor de text și factorii pot fi mulți, cum ar fi memoria alocată, starea sistemului de operare (în videoclip sistemul durează mult pentru a porni și opri ceea ce sugerează că nu este o instalare curată de 0 (ceea ce este recomandat pentru acest tip de carcasă) etc. Pot să vă spun doar că binarul pe care l-am editat de aproximativ 10 sau 20 de ori și nu a fost niciodată verificat. Acest lucru arată, de asemenea, că sunteți fie un ignorant, fie un povestitor.

    4 Acum spuneți că jurnalul depinde de rsyslog TOTAL FALS, adevărul este că oricine îl poate verifica instalând sau dezinstalând rsyslog și văzând că jurnalul funcționează perfect

    Aș aprecia foarte mult dacă lăsați acea obsesie nesănătoasă cu mine, nu este vina mea că sunteți ignorant sau fabulos

    Concluzie:
    Nu doriți să utilizați systemd, cred că este minunat, acum nu mai aveți nevoie să răspândiți teroarea cu minciuni pentru a obține adepții cruciadei dvs. anti-systemd. Am trăit și am dat viață, că există un loc pentru toată lumea în lumea software-ului gratuit 😉

    1.    Rolo el a spus

      o clarificare la punctul 3, cineva mi-ar spune că, deoarece systemd este în pid1, un accident al mașinii ar implica că casca systemd. Două lucruri, mai întâi aici, ceea ce s-a afirmat este că systemd s-a prăbușit din cauza eșecului jurnalului, dar în realitate există o verificare pentru introducerea unui binar (care este utilizat în timp real) cu un editor de text, de asemenea, clarific că în toate testele pe care le-am efectuat nu au verificat niciodată mașina virtuală. În al doilea rând, nimeni în mintea lor dreaptă nu poate pretinde că Linux nu este etichetat xddd,

    2.    SynFlag el a spus

      Fabulos?, Slab, reține-te puțin, fabulos bătrâna ta care spune că arunc cauciucul când nu îl ating cu un băț, mă întorc la respect:

      1.- Trebuie să reporniți sau să forțați repornirea serviciului, ceea ce nu este ideal și în CentOS 7 când am încercat, repornirea serviciului nu a făcut nimic, nu uitați că este versiunea 208 nu noua 217 sau 216 de Fedora.

      2.- Irelevant și cei care raportează erori? ... ești un idiot, nici măcar nu-ți răspund

      3.- UNHAPPY, versiunea pe care am încercat-o în acea zi a videoclipului, pe care o puteți vedea, întregul sistem de operare sa prăbușit, de ce credeți că mintea orto nefericită? Nu sunt o maimuță mincinoasă, du-te să iau Cindor pajero.

      4.- Depinde să se autoregenereze, nu o face de la sine, de fapt l-am sugerat către dev-urile systemd ca o caracteristică, că se regenerează singur fără a opri înregistrarea, cu excepția cazului în care serviciul este repornit, l-au luat ca ceea ce sunt pentru a adăuga, așa că suge-mi penisul și spune-mi mulțumesc tati că ai colaborat în timp ce mă uit la porno.

      La revedere slab, m-am săturat să vorbesc cu maimuțele pentru asta prefer să merg la grădina zoologică, când ești la nivelul anusului nostru discutăm.

      1.    Rolo el a spus

        @SynFlag Îmi cer scuze, nu știam că ești bolnav, chiar am crezut că ești un fabulos și ignorant, dar cu ceea ce tocmai ai scris îmi dau seama că ești de fapt delirant.

        Ei bine, nimic, sper să-ți absolvi medicamentul mai bine și să revii la realitate, forță! poti!!!

  31.   Pedro el a spus

    Citesc, citesc și recitesc, dar nu înțeleg nimic, știu doar că de când a apărut Xubuntu 14.04.1 până în prezent, nu am avut nicio problemă cu notebook-ul sau cu imprimanta laser HP 1102, nu știu orice, sunt utilizator și nu știu dacă systemd este mai rău sau nu este potrivit pentru init, dar repet că nu am probleme cu xubuntu. 🙂

  32.   Realul el a spus

    Citesc, citesc și recitesc și știu doar că retrăiesc un subiect vechi. XD