Tocmai am aflat că furie din partea multor utilizatori a dus la crearea inutilului, un nou daemon inițial bazat pe systemd care încearcă să-l elimine de „cantitatea inutilă de funcționalitate pe care o încorporează”. Alegerea numelui este interesantă, care, în limba engleză, poate fi citită ca „sistemul inutil” sau „să folosim mai puțin systemd”.
În primele sale etape de dezvoltare, Uselessd nu este altceva decât o furcă de sistem redusă la cea mai simplă formă. În cuvintele dezvoltatorilor săi, este „un demon inițial de bază (initd), un monitor de proces și un sistem de dependență tranzacțională, care minimizează intruziunea și izolaționismul”. Printre funcționalitățile eliminate au fost: journald, libudev, udevd și anumite tipuri de unități considerate inutile, și anume dispozitive, temporizatoare, swap, monturi și montaje automate.
De parcă acest lucru nu ar fi suficient, au adăugat deja suport pentru a-l compila sub MUSL și uClibc, ca alternative la utilizarea glibc. Uselessd este, de asemenea, în fazele incipiente de a fi portat pe FreeBSD, în timp ce systemd are doar suport Linux.
Oricum, nu este clar cum se vor termina „războaiele inițiale” și dacă inutilul va genera un înlocuitor cu adevărat funcțional, dar cei care doresc să afle mai multe despre acest proiect pot vizita site-ul oficial.
Știam că există cineva care nu ar rămâne pur și simplu și nu va supăra SystemD.
Acum, pentru a-l susține, doar.
Care este diferența dintre systemd .... CLI ... ..GUI?
systemd gestionează pornirea și aplicațiile sistemului.
Cli provine din interfața liniei de comandă, adică din comenzile pe care le utilizați pentru a gestiona programele
Și GUI este despre interfața grafică.
Ai putea să-l cauți pe internet, îți spun
Încărcați un tuto pentru noobs
Nu înțeleg, ca utilizator, această campanie anti-sistem
Mi-a fost ușor, ca simplu utilizator, să mă adaptez la utilizarea acestuia la activarea sau dezactivarea serviciilor, o știu deja pe de rost, ceea ce cu ceea ce aveam înainte nu mi se întâmplase.
Nu am nimic împotriva syetmd și văd disprețul lor absurd. Vorbind ca utilizator final.
A face o furcă pentru a elimina funcțiile mi se pare o prostie. Oamenii se plictisesc.
Înțeleg oamenii care sunt noi în GNU / Linux și nu pot vedea diferențele fundamentale dintre ceea ce a fost întotdeauna și ceea ce systemd încearcă să ne strecoare.
Linux este o clonă a Unix și Unix a fost creat cu un singur lucru în minte, faceți câte un lucru la un moment dat și faceți-l bine, acest lucru nu a fost un capriciu, din cauza eșecului răsunător al Multics am încercat să fac multe lucruri și le-a greșit sau nu le-a putut controla așa cum ar fi trebuit.
Deci, ei nu numai că au contrazis numele Multics folosind Unix (ceva asemănător cu mulți împotriva celor puțini sau unici), dar au creat și conceptul de țevi și concatenare de procese care oferă o flexibilitate imposibil de realizat prin alte mijloace ... asta a fost ceea ce a dat răsunătorul succesul Unix.
Acum, cu systemd, vor să venim din nou cu povestea Multics ... .nicio persoană, respingerea bazei Unix pe Linux se întoarce la Multics, unde știm (istoria a arătat asta de câteva ori) că am garantat eșecul.
Dacă tocmai ați ajuns la GNU / Linux, vă rugăm să citiți un pic de istorie și să aflați de ce lucrurile se fac în acest fel pe Unix și GNU / Linux.
Bine spus, și celor care spun că în lumea de astăzi lucrurile nu mai funcționează așa, vă dau un exemplu, un browser, una dintre cele mai complexe piese de software care există, totuși, acestea sunt construite prin instrumente care, fiecare , face o sarcină specifică și poate funcționa în afara setului. Un motor javascript, unul HTML, SSL, http ...
Doar pentru că nu a funcționat în trecut nu înseamnă că nu va funcționa acum. Au trecut 20 de ani de la asta, poate este timpul să ne schimbăm, nu?
Mi-ar plăcea să fiu un nou venit la Linux, am participat la asta din 2004 și da, știu ce sunt Linux și systemd și totuși văd systemd mai confortabil.
Acest comentariu pe care îl voi lăsa mai jos este de la un coleg, nu este al meu, dar este un comentariu pe care îl subscriu și eu.
[…] Respingerea sistemului pe care o atribuiesc «neofobiei», frica de nou. Dezactivarea unui script SysVinit implică o bună înțelegere a sistemului de niveluri de execuție și a dependențelor care ar putea exista în /etc/init.d ... și în fiecare distribuție au făcut-o într-un mod diferit. Cu systemd este suficientă dezactivarea systemctl și atât.
Cei care se plâng că systemd încalcă filosofia UNIX sunt că nu au aflat ce este filosofia UNIX sau cum funcționează systemd. Prin aceeași regulă generală, nucleul Linux ar fi cel mai puțin UNIX din lume. Ceea ce se întâmplă este că systemd schimbă funcția în PID 1, așa cum am explicat într-o intrare în acel moment: este un daemon de sistem, nu doar ceva care execută scripturi.
Singurul lucru pe care îl recunosc că systemd nu respectă filozofia UNIX este să folosim jurnale binare, dar este justificat să grăbim interogarea prin indexare. [...]
@yoyo: Ce se întâmplă este că, din moment ce ești un student lent, oricine ar spune că ești un n00b, hahahaha.
@ yo-yo:
Citat foarte bun. În plus, gluma este că SystemD are un defect în bug-uri, deși are propriul său mod de a afișa astfel de „jurnale” blobbed.
Ceea ce mă interesează despre această furcă este modul în care vor adapta viteza SystemD la alte medii UNIX, cum ar fi BSD.
GNU's Not Unix, așa cum a spus un casetist ricardito
Cel mai consecvent comentariu din ultima vreme despre motivul pentru care systemd este gunoiul. Multics, windows…. Sună defectarea totală a unei componente?
Asta s-ar întâmpla cu systemd care este traversat în întregime de dbus, dacă unii daemonii săi eșuează, ar fi necesar să reporniți sistemul sau totul s-ar putea prăbuși. Mi s-a întâmplat deja în centos 7 ca un demon sau o unitate să rămână la fel de moartă și să nu repornească pentru mai multe reporniri pe care le faceți voi. Mă frânge foarte mult dacă utilizatorii finali cred o bucată de cunoștință și apără ceva ce nici măcar nu știu pentru că este atacat. Cum spunea bunica mea, dacă nu știi, nu-ți da părerea, mai bine taci și întreabă fără să te întrebi, atunci când știi, atunci pune întrebări.
Multă gândire ubunuser, marele suport pentru systemd l-a adus într-o mare măsură, paradoxal una dintre companiile care l-au criticat, canonică, inundând lumea Linux cu utilizatori care nu văd dincolo de ls -l lor.
Tipul de la inutil este o singură persoană care deține domeniul boicotului, așa că, cu excepția cazului în care alți dezvoltatori îl susțin, văd puțin viitor pentru el. Sper că dev-ul mai multor distracții geek vă va ajuta ca arch, gentoo sau Slackware.
.. Nu mă consider un „utilizator avansat” Nu-mi plac titlurile de nobilime, nu sunt un administrator, dar am trecut prin toate acele distrosuri care menționează (Slack (foarte puțin), Arch de câțiva ani și Gentoo da câțiva ani (de asemenea, furculița dvs. Funtoo)) Înțeleg punctul dvs. de vedere ca sysadmins, dar mă întreb, și dacă nucleul eșuează? Totul merge dracului, așa că spun, de ce nu se plâng de nucleu? Pentru că nu folosesc Minix sau un fel de sistem de operare cu „server de reîncarnare”? Uneori mi se pare că furia provine mai mult din atitudinea lui Lennart (ceea ce nu pare potrivit), dar permiteți-mi o generalizare, domnilor (și bineînțeles că o veți face) vă apărați munca și ne lasă utilizatorii de desktop „aruncați”, le pasă doar că serverul lor este „bine”, chiar dacă sysv folosește o „paradigmă de pornire” destul de arhaică (subiectul Ținta și dorit de systemd este bine ...), spun că severul dvs. va funcționa perfect cu sysv, dar între timp utilizatorii de desktop folosesc un dbus în spațiunumele de utilizator …… ce idee grozavă ………
Repet această bifurcație, așa cum s-au spus în altă parte, până acum văd doar un nume „drăguț” și un systemd plafonat, care, apropo, BINE AȚINUT la Systemd, Systemd haters ... Văd mulți care se plâng de systemd, dar vor ... pentru că? OpenRC nu face lucrurile bine? sau Upstart? sau orice altceva? …. Doamne ... până acum am văzut 2 tipuri de haters, sysadmins cu elemente fundamentale, și cele pe care le descriu în acest paragraf care par mai degrabă „posers” ....
Revenind la subiectul sysadmins, nici măcar nu aveți nevoie de o interfață grafică, nu știu de ce vă plângeți de systemd (ați putea susține cu ușurință că Gnome Shell necesită Systemd (ceea ce nu este în totalitate adevărat deoarece Funtoo îl lucrează cu OpenRC )) dar NU AVETI NEVOIE de interfețe grafice ar trebui să se plângă la distribuțiile respective, Centos și Debian. În special Centos, dacă Systemd aduce atâtea probleme, nu ar fi trebuit să migreze (deși era evident că urma să migreze sub mâna RedHat) și Debian, îmi pare rău să vă spun, dracu, asta a fost decis de echipa Debian, în dorința lor de a fi «distro universal" ... dar repet folosesc FreeBSD sau un "Distro pentru servere" care înțelege cât de "rău" este Systemd și folosește sysvinit period ..
Poate că x11tete11x problema nu este că nucleul eșuează, ci că eșuează și se poate ști ce a cauzat eșecul. Este ceea ce mă deranjează cel puțin despre SystemD ..
@elav ai dreptate în privința asta, cu systemd, multe erori de sistem se încadrează între nuanțele de gri și negru și totul pentru că journald arată ca o „cutie magică” care transformă jurnalele într-un fișier binar nesigur și când vorbesc despre fiabilitate Mă refer la nebunia dovedită (există deja un raport de erori) conform căruia dacă un jurnal journald este deteriorat (ceea ce se poate întâmpla din mai multe motive) este pur și simplu aruncat și se începe unul nou, lăsând acel jurnal practic ilizibil de multe ori, a raportat o eroare în freedesktop și din care Poettering însuși l-a oprit. Ca să nu mai vorbim de problema de depanare, dar bine, asta este deja cunoscut (dacă nu știți despre ce vorbesc, vă reamintesc că opțiunea de depanare a liniei de nucleu și „remedierea ulterioară” a fost motivul pentru care au eliminat Kay nu are permisiuni pentru comitere în nucleu).
@ x11tete11x să nu comparăm dezvoltarea kernel-ului cu dezvoltarea systemd. systemd este un software care este încă la început, dacă îl comparăm cu nucleul, de asemenea, nu văd că Linus aprobă patch-uri experimentale în stânga și în dreapta, în timp ce schimbă ABI-urile și API-urile nucleului.
@joakoej Multics a eșuat din mai multe motive, inclusiv: având o complexitate mai mare în ceea ce privește codul, fiind lent în multe sarcini comune în comparație cu alte sisteme deja dezvoltate și fiind excesiv de scump pentru ceea ce a fost gestionat în mod normal în proiecte de aceeași dimensiune.
Este un fork, deci nu are toate funcțiile, un sistem init nu poate acționa astfel, vezi sysvinit. sysvinit, deși învechit, avea doar o singură sarcină de bază, și anume aceea de a porni sistemul de operare, orice altceva ar avea grijă de alții (syslog și nu journald, openrc și nu systemctl, consolekit și fără logind ...), deoarece sysvinit este depășit și că de fiecare dată, dar mai multe proiecte depind de despărțire de systemd, această inițiativă mi se pare grozavă. Prefer syslog decât journal, dar logind (pe lângă faptul că este o cerință pentru gnome) bate consolekit cu o alunecare de teren. De asemenea, această furcă ar trebui să fie mai sigură, mai portabilă și, sperăm, compatibilă cu ulibc.
Compa, nici eu nu am avut nimic împotriva Systemd până ieri. Din anumite motive, laptopul meu durează mult să se închidă, iar singurul lucru care iese este (la nesfârșit):
[ 9064.808526] systemd-journald[150]: Failed to write entry (13 items, 351 bytes), ignoring: Bad addressEste ca o nenorocită de eroare în Windows, că nu știi nimic.
Și fără jurnale este destul de dificil să poți urmări baza problemelor. Systemd mă deranjează și pe mine pentru genul acesta de lucruri. Este posibil să nu cunoașteți foarte bine software-ul, dar cel mai puțin cer este claritatea în jurnale.
Și încă o dată [Inserați stereotipul dvs. preferat aici] au avut dreptate. 🙂
Dar atenție, să nu menționăm ferestrele, poate că suntem unul dintre acei pacienți care au fost infectați cu noua patologie pe care domnul Linus și-a propus să o adauge la CIE, urăsc windowsita, cred că se numește. 🙂
@Staff și care este greșeala lui Elav? De la Windows 8 și mai multe lucruri au fost ascunse (chkdsk la boot, informații tehnice BSOD, msconfig „decorativ”). Totul pare să meargă în acea direcție. Sper să nu ajungem la „mac-ul trist” și la ferestrele sale corelative și să nu avem informații utilizatorului.
@Mario
Nu am spus niciodată că elav greșește.
Observați emoticonul de la sfârșitul celor două paragrafe ale mele.
Oh!! @Staff că nu puneți unul ... Mă refer la Windows pentru afișul său tipic în stil:
Windows a întâmpinat o problemă. Codul problemei este 0x1123df2982, contactați Centrul de asistență pentru mai multe informații ...
pe scurt, pentru / dev / null
Elav, imaginează-ți o eroare ca aceasta pe un server de producție. Nu este admisibil. Doar un administrator de sistem înțelege de ce systemd este atât de rău. Nu este pentru a desconsidera pe nimeni, dar este necesar să înțelegem cum funcționează un procesor, un sistem de operare, un nucleu, un proces etc. pentru a înțelege problemele de nivel scăzut pe care le ridică sistemul. Trece dincolo de filozofia UNIX, discutăm despre stabilitatea unui sistem.
Sysadminii sunt confortabili cu Debian 6/7 și CentOS 5/6 fără sistem, dar când se termină suportul pentru Debian 7 și CentOS 6, adevăratul amestec va începe doar acolo (dacă există o alternativă viabilă precum cea descrisă în acest articol).
Imaginați-vă chiar pentru un administrator de sistem, să înceapă traducerea și testarea scripturilor care au funcționat o viață întreagă cu comanda „service” la systemd.
Și eroarea pe care o afișezi dezvăluie o altă margine a systemd, ai spus-o foarte clar, că nivelul de ascundere a informațiilor este „foarte Windows”.
Salutări.
Uite, nu sunt sigur despre asta, dar cred că exagerezi puțin, am avut mai multe erori în Gnu / Linux care nu se explică de la sine și mă îndoiesc că toate s-au datorat systemd. Mă înșel?
@Emiliano Poate ai dreptate. Oricum, deși nu sunt un expert, mi se pare că este un pic senzațional. Mi se pare că este o chestiune de obișnuință mai mult decât orice și dacă administratorul de sistem dorește, cu siguranță învață cum funcționează systemd, chiar i se pare mai ușor, spun dacă ceea ce face este să centralizeze totul, cu siguranță în unele sau mai multe aspecte lucrurile sunt mai rapide.
Din ceea ce am văzut, are mai multe avantaje în această privință, cum ar fi timpul de pornire, nu necesită ca unele programe să înceapă înainte ca altele să pornească corect, nu trebuie să modificați un fișier rc.conf sau ceva de genul acesta, deoarece gestionează totul de la mai automat, puteți rula aplicații chiar dacă unele dependențe nu sunt îndeplinite etc. Aceste lucruri sunt câteva dintre avantajele pe care le-am văzut pe internet, corectează-mă dacă greșesc
Acum, cu siguranță vor avea unele dezavantaje, ca orice altceva, dar ar fi bine, dacă știi cum funcționează și ai timp să-l clarifici, îți cer ca o favoare să știi pe ce se bazează opinia ta. Din ceea ce am văzut, poate exista un dezavantaj că mai multe programe vor trebui patch-uri pentru a funcționa corect cu systemd, dar nu știu dacă asta afectează în vreun fel alte sisteme init.
@Emiliano Ah M-am înșelat că fișierul nu era rc.conf, erau / etc / inittab și /etc/init.d/rc
Se pare că există o versiune a acelui fișier pentru systemd, dar centralizată într-un singur fișier / etc / systemd, care este gestionat de programul sytemctl.
Cred că înțeleg de ce spuneți că unui administrator de sistem s-ar putea să nu-i placă, deoarece se pare că, cu init, a avut mai mult control și a făcut lucrurile doar atunci când l-a indicat.
Pe de altă parte, systemd poate fi un pic mai intruziv, dar mi se pare și repet, că este o chestiune de a învăța cum funcționează și cu siguranță că cineva cu capacitatea de a fi administrator îl poate realiza.
Ei bine, am încercat să închid Debian Jessie cu comenzile SysVinit toată viața, dar nu știam că folosește SystemD, așa că a trebuit să folosesc ghidul lui Arch pentru a ști cum să gestionez SystemD și systemctl puțin mai bine.
În cazul meu, SystemD îmi oprește computerul desktop destul de repede când folosesc Chromium / Chrome / Opera Blink intens.
@ eliotime3000 aici aveți un wiki systemd bun pentru debian cu multe informații http://www.esdebian.org/wiki/systemd desigur, wiki-ul arch este foarte bun, dar systemd în debian nu este implementat în același mod ca și în arch, deci există multe comenzi, soluții etc. care nu vor funcționa pentru dvs. fiecare distribuție are lucrurile ei mici 😉
LOL
Chipul fericit nu a fost suficient, poate că ar trebui să folosesc ghilimele, cu faptul că acum ghilimelele clarifică totul 🙂 // Sarcasm (pentru a vedea dacă cu acea etichetă înțelegeți deja).
Arată că nici tu nu mi-ai citit răspunsul la mario.
Cele două paragrafe ale mele erau sarcastice.
Primul, încercând să sublinieze ironia că, atunci când oamenii ne spun despre deficiențele unui proiect, îi etichetăm nebuni și alte mii de lucruri dacă nu suntem simpatizanți cu ideologia lor, dar când deja experimentăm problemele în propria noastră carne. nu ne mai rămâne decât să înghițim cuvintele.
Și al doilea, că ÎN EFECT ESTE CA WINDOWS, dar că mulți nu-l acceptă și spun că este pentru că Windows este urât și este folosit fără discriminare pentru a ataca tot ceea ce nu miroase a FSF.
Dar oricum, criteriul este ceva greu de găsit în această lume.
@Staff, om să folosească sarcasmul într-o formă de comunicare la fel de rece ca aceasta, trebuie să lucrezi puțin mai mult 😛
@elav:
Eu vin aici, Las acest link către comentariul meu, iar eu fug. : v
Am observat la fel, dar la început…. timp de câteva zile computerul durează pentru totdeauna să pornească și primul rând spune ceva legat de Systemd. Ce se întâmplă?
La fel este elav, precum și ferestrele în sine. Am avut acea eroare, ștergeți întregul fișier din jurnal și atât. În curând va trebui să reinstalăm hahaha.
Hahaha, dar dacă am instalat Antergos nu acum o lună hahaha
Imaginați-vă cum mă simt cu un nenorocit de Arch care durează aproximativ 30 sau chiar 40 de secunde pentru a porni mai mult decât Windows, da, instalez o mulțime de rahat în yaourt, dar nu încep nimic (este ceea ce încerc cel mai mult) cel mai nebunesc lucru pe care îl am este serviciul CUPS și cred că este ssh pentru terminalele de la distanță. Din păcate, după un an fără formatare, cred că voi reconsidera ideea de a o face din nou 🙁
Din păcate, am observat că în ultimii 2 ani ne-am apropiat de distribuțiile în stil Windows care încearcă să ascundă informații, să automatizeze rapoartele de erori, să automatizeze operațiunile în care utilizatorul ar trebui să intervină și chiar să aibă control.
Din moment ce mi-e dor de distrosurile de acum 3-4 ani cu SysVinit, a fost distractiv să blufez cu un „init 0” la școala XD. În plus, deși nu totul a fost atât de aprobat, controlul a fost extrem de utilizator și nu de sistem. Da, există multe facilități, dar cu prețul ...
Puteai vedea că vine. Nu am nimic împotriva systemd, ca utilizator obișnuit, îmi ușurează lucrurile, iar comenzile pentru activarea sau dezactivarea serviciilor sunt destul de simple. Va trebui să vedem cum se termină acest război inițial.
SystemD este ca un inel pentru a le controla pe toate. Poate fi un troian NSA. SystemD poate compromite securitatea noastră de confidențialitate, deoarece intră în multe servicii. Și și mai rău, dacă distribuția mea a gestionat foarte bine energia, ce se va întâmpla acum? Nu voi putea să mă schimb în altă parte.
Nu la fel de mult ca un troian, dacă controlează multe lucruri, dar este totuși software gratuit, puteți vedea ce face codul cu informațiile dvs.
Deci, dacă SystemD are probleme (și dacă are), acestea trebuie rezolvate și nu doar aruncate, deoarece are și multe lucruri bune și necesare.
Un lucru este sigur, știu doar că nu știu nimic. Sunt un începător, dar după ce am citit multe opinii ale unor oameni care știu infinit mai mult decât mine, opuși sau neutri, concluzia la care pot ajunge este să fiu suspect și nimic nu mă face să nu mă opresc. Nimic nu mă face să am încredere, deocamdată.
Folosesc openSUSE pentru că îmi place și ar putea să se strecoare pe mine ... De fapt, ar putea să se strecoare peste tot ... Și acolo apare Stallman, el veghează asupra confidențialității noastre, oricât ar cântări mulți.
NSA nu și-a băgat ghearele în RedHat ????
Cât de exagerat, de ce ți-aș compromite confidențialitatea?
Pentru a încălca securitatea și a nu anunța pe nimeni, trebuie să agraveți jurnalele sistemului, să le complicați, să le faceți binare, să le ignorați pe cei care raportează defecțiuni, să nu permiteți syslog-ng și journald să coexiste în același timp.
Dacă adăugăm la această gestionare automată a rețelei de către dhcp, avem terenul plantat pentru intruziuni fără a lăsa urmele „celui mai mic bug încă nedescoperit”, într-adevăr cel care nu vede acest lucru se datorează faptului că este orb, surd și mut. .. acum mai bine de 2000 de ani, cineva spunea ... după fructele lor îi vei cunoaște și, bine, eu văd deja fructele și sunt când sunt coapte.
Ceea ce este atribuit systemd nu este doar îndeplinirea sarcinii care îi corespunde, ci s-a amestecat în tot pentru a pervertit securitatea și a crea instrumente învechite care își fac treaba bine, nepermițând coexistența ambelor în același timp.
Cum am mai spus, cât de exagerat.
Te-aș crede atât timp cât SystemD a fost programat de Microsoft, Apple și / sau o altă companie care nu a distribuit codul sursă. Din fericire, nu este așa și el este recunoscător că cel puțin există cineva care nu a fost doar în criză.
Pe de altă parte, când Linus Trovals a fost întrebat despre sistemul algoritmului SELinux, el a răspuns cu o soluție destul de simplă (și asta fără să menționăm că tatăl lui Linus a mărturisit că NSA a încercat să pună mâna în dezvoltarea nucleului, deși singurul lucru rămânea de făcut a fost lansarea nenorocitei componente cu tot și cod sursă).
Realizați că ignoranța este adesea principalul flagel uman.
Bine, tocmai am câștigat 10 euro la un pariu 😛. La fel de previzibil ca întotdeauna ... Mi se pare bine, nu prea îmi place systemd din cauza filozofiei sale de proiect și a lipsei totale de comentarii în cod (la OpenSSL). Dar recunosc că este superior din punct de vedere tehnic. Mă întreb dacă ar putea fi un înlocuitor pentru sysvinit pentru Openrc. În acest caz voi migra.
De asemenea, în software-ul gratuit, din anumite motive, este necesar să existe două implementări ale acelorași, de ce, competiția (Libreoffice, Openoffice) și securitatea (OpenSSL).
există un lucru pe care nu îl înțeleg, dacă designul systemd se bazează pe cgroups, care este o caracteristică exclusivă Linux.
Pentru a transfera utilizarea furcii systemd în FreeBSD Hurd, etc, fie adăugați cgroup-uri la aceste nuclee, fie eliminați cgroup-urile din proiectarea furcii respective.
dar dacă eliminați cgroup-urile din furculița systemd, este greu să vă gândiți la Uselessd ca la o adevărată alternativă la systemd.
De asemenea, consider că această inițiativă este foarte pozitivă, deoarece concurența este întotdeauna bună, deoarece îi obligă să se străduiască să fie mai buni și rezultatul îi aduce beneficii utilizatorilor.
* garegan = add
pur și simplu nu ar folosi cgroup-uri sau ar face cgroup-uri opționale. În teorie nu este atât de dificil. ceea ce trebuie să faceți este pur și simplu să proiectați și să scrieți o modalitate de a susține alte metode de control al proceselor care există în toate sistemele de operare actuale. În practică, acest lucru este plictisitor și costisitor, deoarece înseamnă că, de exemplu, aveți 8 ore pentru a lucra la program, în loc să folosiți cele 8 ore pentru a îmbunătăți și a lustrui ceea ce vă oferă o singură opțiune, trebuie să împărțiți acel timp în 6 ( păstrați cele 3 sisteme + 3 moduri de schimb între ele). în acest fel, întreținerea și dezvoltarea devin mult mai grele și mai lente. Adică, fie sprijiniți mai multe obișnuite, fie susțineți unul bine.
Și fără a menționa că BSD are o cerere foarte mică de la administratorii de sisteme și chiar UNIX însuși o vede cu aceiași ochi ca la Windows XP.
punctul este că grupurile c: „sunt utilizate pentru a urmări procesele de servicii, în loc de PID-uri. Aceasta înseamnă că demonii nu pot „scăpa” de systemd chiar dacă sunt dublu-furcați. » http://es.wikipedia.org/wiki/Systemd
Deși acesta este unul dintre punctele care critică systemd, deoarece se spune că începe în pid 0 și că acesta este un risc, deoarece dacă systemd se sparge, acesta sparg sistemul, ceea ce, așa cum a spus linus, este o prostie, deoarece dacă sparge nucleul sau alte procese, de asemenea, sparge sistemul. adevărul este că, dacă furculița nu folosește grupuri c, folosește pids și nu va avea controlul deplin al demonilor. cu asta nu va fi niciodată mai bun decât systemd pe Linux
Există mai multe furci înrudite, dar acesta este primul care s-a sistemat în sine. În Gentoo pentru udev (care a fost combinat cu cele menționate anterior), există libgudev și libeudev. În caz contrar, este ciudat să mergi cu OpenRC și să vezi în procesele „systemd / udev” cum se întâmplă în anumite instalații curente. Personal, nu-mi place ideea de a adăuga un client DHCP (sper că nu au făcut-o încă). Cred că există software dovedit și excelent în această sarcină, nu este nevoie să reinventăm roata.
Corect, gudev este și systemd, în ultimele versiuni.
Răspund la comentariul despre DHCP în systemd.
systemd nu numai că are un DHCP încorporat (încorporat ca parte a rețelei), are și un rezolvator DNS și o memorie cache DNS, precum și caracteristici moștenite de la Avahi (un alt monstru creat de Poettering).
Azi am luat cartofi și friptură la cină, nu mi-a plăcut, voi crea o furculiță. Și așa pentru tot.
Este inutil o operațiune falsă elaborată de pavilion fals de către Red Hat pentru a-și discredita adversarii și a instala o nouă ordine mondială?
… La dracu.
Bine acoperit din spatele acestui proiect
TRADUCERE:
Îmi spun asta
1) creează un sistem amputat fără niciunul dintre instrumentele lor și fără niciunul dintre avantajele pe care standardizarea îl aduce împreună cu faptul că nu rezolvă niciuna dintre problemele pe care sistemele le rezolvă sau rezolvă vechile probleme tradiționale. Da, sigur. dă-mi 3
2) Îmi spun că este un systemd fără „bloat”, dar se dovedește că systemd este modular și puteți folosi systemd fără niciunul dintre demonii săi. Prin urmare, îndepărtarea balonării este aceeași în practică (cu excepția faptului că nu va păstra multe dintre cele mai bune instrumente de sistem, cum ar fi jounalele)? bine. perfect. Dă-mi 20 chiar acum.
3) Îmi spun că această furcă care nu rezolvă nicio problemă, că nu rezolvă problema încadrării la nivel scăzut, că nu oferă avantaje tehnice de niciun fel, dar că înainte de a ne lua înapoi 5 ani în gestionarea serviciilor în Linux. concurați cu singura speranță de standardizare? . bine. Îl iubesc. dă-mi 2161816814168 distrosuri cu asta. Vă rog. acum!!
pentru cei care nu au înțeles. este sarcasm 🙂
și acesta este motivul pentru care Linux nu va triumfa niciodată pe desktop, când pazos-urile încep în sfârșit să fie oferite pentru a crea o infrastructură care să facă posibilă un desktop funcțional pentru toate publicurile. Mamertii ies cu muiile lor. ok lasă-i să facă ce vor, au dreptul, dar adevărul este că nu te aștepta să fie luate foarte în serios.
http://hackingthesystem4fun.blogspot.mx/2014/09/linux-no-triunfa-en-el-escritorio.html
http://linuxito.com/gnu-linux/nivel-alto/431-por-que-systemd-es-una-mierda
Ca să spun adevărul, gluma este că SystemD mă ajută foarte mult, chiar și oprește PC-ul foarte repede atunci când ai mult timp folosind Chrome pe partițiile Ext4. În cazul în care încerc Debian Jessie cu XFS și SystemD - și, mai presus de toate, îmi oferă rezultate mai bune decât cu SysVinit - voi îngenunchea în fața lui.
Cel mai amuzant lucru este că încearcă să creeze un SystemD cu capacitatea de a adăuga funcții SysVinit la acesta, chiar dacă o astfel de muncă este complet provocatoare (cum ar fi furca OpenSSL a lui Theo de Raadt).
Această furcă rezolvă problema luării frâielor de la Lennart și tatăl său RedHat pentru a încerca să le dea dezvoltatorilor independenți
pentru a elimina urâciunea systemd de a deranja cu lucruri care nu sunt și nu ar trebui niciodată să facă parte din sistemul de boot. Sunt clar?
Acum, dacă pentru unii acest lucru pare un motiv mic ... care nu poate fi rezolvat de nimeni, acestea sunt doar opinii și puncte de vedere personale.
dar este că systemd nu este un simplu sistem de pornire, systemd este mai mult de 70 de binare diferite, dintre care doar 1 este pid 1 și acest lucru are grijă doar de 1 lucru, pornind și oprind alți demoni. toate sistemele bloat sunt de fapt opționale, cu excepția journald. deci nu văd cu adevărat ce face sistemul de boot pe care nu ar trebui să-l facă dacă face un lucru. după cum am spus, restul proceselor și serviciilor sunt tratate separat de alți demoni, majoritatea putând fi utilizate separat chiar. singura diferență este că acești demoni opționali sunt scrise de aceeași echipă, în același calendar și în același git (așa cum face BSD în mod similar)
lennart malefic și han roșu? iluzii de persecuție și puțin altceva.
@Mirage, dar este că systemd nu este un simplu sistem de pornire ...
Aceasta este problema, au început ca un simplu sistem de pornire și au reușit să convingă multe distrosuri și apoi să nu mai fie un simplu sistem de pornire și să se răspândească ca un cancer.
Îl voi picta mai bine, vreau systemd, dar nu vreau niciun alt modul systemd ... dar când spun că nu vreau, nu vreau să fie instalat pe hard diskul meu ... nu-mi este suficient să-l dezactivez ... Nu am încredere în lucrurile automate care pot fi activate de ele însele, de exemplu, atunci când protectorul de ecran este activ.
Deci, spuneți-mi ce distribuție îmi oferă o versiune de systemd care nu are aceste module în programul de instalare.
În prezent folosesc linux mint 17 și nu folosește systemd (cred că doar unele dintre dependențele sale), deși în distribuțiile care îl folosesc funcționează perfect pentru mine, folosesc linux timp de aproape 2 ani și îi dau o utilizare de bază (surfing Internet, editarea documentelor într-un mod simplu, etc) și atunci când folosesc systemd nu dau greș, de asemenea, că la nivel tehnic se observă o îmbunătățire și o mare parte din ură mi se pare nejustificată, mulți spun că este pentru ceva mai degrabă etic decât tehnic, dar mi se pare prea mult, deși aș dori, de asemenea, să văd o alternativă că asta la nivelul dvs., deși nu am încredere în asta (deocamdată este practic un sistem mai „subnutrit” și numele pare deja prea ridicol pentru fii ceva serios)
Și de ce nu folosiți în continuare scripturile BSD? Sau openRC de la echipa Gentoo? Sau uitați de toate cele de mai sus, inclusiv SystemD și utilizați Ubuntu Upstart?
Deoarece SystemD accelerează procesul de pornire și oprire a sistemului GNU / Linux.
În plus, ceea ce doriți să salvați este că, viteza de pornire a SystemD fără a fi nevoie să utilizați modulele SystemD și să le utilizați pe cele ale OpenRC, SysVinit și chiar scripturile BSD, evitând astfel pâlpâind a buștenilor.
Ei bine, sunt mulțumit de systemd.
Văd chiar mai multe avantaje decât orice altceva.
Am citit multe comentarii și aparent systemd ... nu merge cu filosofia a 90% din utilizatorii de sistem Linux care sunt împotriva ei, ... mă întreb ... de ce interesele ambelor systemd în dorința de a controla totul ... este este ca ferestrele? ... Nu-i așa că în spatele lor există planuri sinistre de a controla pe toată lumea și guvernul mondial? În prezent, sistemul Linux Mint funcționează minunat aproape totul automat și nu necesită systemd. Dacă reușiți să preluați sistemul Linux ... .. nu aveți de ales decât să migrați către BSD UNIX și derivatele sale.
Ce alte distribuții funcționează ca Linux Mint, indiferent dacă au Systemd sau nu?
Uită-te în Windows nu există nimic ca systemd din câte am înțeles.
Acest lucru face să pară un lucru rău că este centralizat, atunci când singurii cărora le pasă sunt cei care lucrează cu sistemul, care sunt de obicei experți, pentru noi, utilizatorii obișnuiți systemd este mult mai bun, chiar și unii administratori îl laudă, așa că rețineți că totul este legat de gust.
Systemd este foarte bun, dar despre ce se plâng mulți oameni este că există mai multe programe care vor avea nevoie de noi dependențe pentru a funcționa, deoarece systemd este mai intruziv și depășește puțin ceea ce ar fi un sistem bootstrap. De asemenea, se plâng că face anumite sarcini în mod automat, dar sunt sigur că, dacă înveți să îl folosești, îl poți configura după bunul plac.
De aceea spun: SystemD este destul de simplu de gestionat, deși de fiecare dată mă detașez de ceea ce făceam în SysVinit (nu ca să scădem de SystemD, dar SysVinit mi-a salvat necazul de a face dmesg să văd dacă este ceva ce am înșelat).
Scopul efectuării pașilor de pornire la Windows este să vă scutiți de problemele legate de editarea scripturilor. Cu alte cuvinte, acest lucru ar economisi mult timp pentru cei care nu sunt atât de buni.
Pentru perfecționiști și / sau administratori superiori, este preferabil vechiul SysVinit și Gentoo OpenRC (în cazul meu, aș dori ca SysVinit să aibă viteza de pornire a SystemD, așa că UselessD servește ca un plug-in suplimentar pentru SysVinit sau OpenRC au puterile că foarte SystemD).
Presupun că ați încercat rc_parallel = »DA» în /etc/rc.conf.
Este încă puțin mai lent decât systemd, dar doar câteva secunde și din moment ce durata de funcționare zilnică în cazul meu nu este niciodată mai mică de 14 ore ... diferența de 8 secunde nu mă afectează.
Cred că cu această bifurcație va fi posibil să se schimbe cursul și sper că dezvoltatorii independenți se vor alătura pentru a uni binele inițiaticilor cu systemd
și bineînțeles că logica unei singure sarcini este urmată și realizată bine.
@ eliotime3000 sunt lucruri mult mai importante decât timpul de boot, de asemenea, acest factor nu este că este o mare problemă, cel puțin în cazul meu, timpii de boot între systemd și OpenRC (folosind Gentoo), nu sunt foarte diferiți, câștigând systemd pentru mai puțin de 4 secunde și fără a utiliza rc_parallel = yes în OpenRC.
NOTĂ: De aici înainte, oricine citește, vă rugăm să faceți acest lucru cu atenție și să mă iertați pentru unele expresii, de asemenea, să arate clar că este opinia mea personală.
Ceea ce nu-mi place la systemd este faptul că vreau să fac lucruri care au fost deja făcute, pentru că reinventarea roții mi se pare stupidă și inutilă.
Ce dracu face un init cu demoni luks, lvm, dns, dhcp, funcționalități avahi, jurnale, coredump, devfs, printre altele? Poate că demonii cu toate acele funcționalități nu mai există.
De ce naiba ai nevoie de acces root pentru a gestiona jurnalele și coredump-ul? (Acest lucru l-am putut verifica personal în Debian și Gentoo).
De ce dracu 'trebuie să-mi repornesc computerul dacă există vreo schimbare la systemd, este că nu poate reporni repede? Geys-ul SysVinit o poate face și, cel mai important, o face bine. Ei spun că systemd o poate face, dar faceți testul și veți vedea că nu reușește și nu există altă opțiune decât să reporniți.
Nu se termină aici, dar systemd a cunoscut erori și pur și simplu nu sunt remediate, și totul pentru că echipa (Poettering care conduce taxa) preferă pur și simplu să le ignore și să le marcheze WONTFIX sau doar să le ignore. Chiar și unele dintre acele bug-uri sunt deja clasice, cea de revistă, cea de auto-asamblare și hai, domnilor, sunt din anul 2011 și 2012 și încă nu pot fi remediate, și nu pentru că nu sunt cunoscute (are un raport și totul) sau nu sunt ușor reproductibile, ci pentru că doar NU VOR SĂ LE REPARE. Acest comportament nu vine cu systemd, Poettering a fost ÎNTOTDEAUNA așa, Avahi (una dintre creațiile lor) a avut, de asemenea, probleme similare, mai ales cu scurgeri de memorie și consum excesiv de CPU, dintre care multe continuă. Vrei mai multe dovezi? Pulseaudio este o altă nebunie de acest tip, care, deși era ceva la care mulți așteptau cu nerăbdare, a adus mai multe probleme decât soluții și abia de curând multe dintre problemele sale au fost rezolvate, asta dacă, departe de mâinile Poettering-ului.
Yukiteru +100
Este evident, poate că un simplu utilizator începător nu își dă seama, dar RedHat este o companie și știu că singurul lucru care interesează fiecare companie este să câștige bani, dacă adăugăm la aceasta că pot exista anumite oferte ale agenților guvernamentali că „încetul cu încetul să se schimbe”, cred că totul este posibil ... banii domnului DUMNEZEU pot face totul.
Dorința de putere a tuturor guvernelor și companiilor mari nu are nicio limită, o citim zilnic, se dovedește că sistemul de operare care rezistă este gnu / linux, utilizatorii săi tind să fie mai bine informați despre securitate și confidențialitate.
Cu systemd au început mici, de la început a fost totul frumos și au reușit să cucerească principalele distrosuri pentru a le schimba, apoi încetul cu încetul au fost adăugând module pentru a înlocui ceea ce exista deja și a funcționat întotdeauna, pot spune că dacă ești Nu sunt interesat să nu instalați aceste module .... dar hoo surpriză, toate distribuțiile îl instalează complet și utilizatorii obișnuiți nu știu cum să compileze manual și să le elimine.
Cel mai pervers modul este journald, pe care l-am citit într-un mesaj că se spunea că nu este opțional, că este obligatoriu și că nu poate fi eliminat.
Este evident că nu va putea fi eliminat, intenția nu este de a funcționa bine și de a nu lăsa syslog-ng să funcționeze bine, nici de a asista la reclamațiile utilizatorilor care raportează aceste erori.
Tehnica este de a acoperi, astfel încât să nu poată fi văzută, apoi de a gestiona rețeaua automat, astfel încât, într-un viitor nu prea îndepărtat, să piardă controlul manual total al ceea ce se întâmplă cu rețeaua și cu jurnalele a ceea ce s-a întâmplat cu rețeaua.
Va fi inutil să citiți codul systemd, totul face ceea ce ar trebui să facă și o face foarte bine „pentru ei”, ceea ce este greșit este funcționalitatea combinată care reprezintă un risc total de „bug nedeclarat”.
Prin urmare, systemd nu este greșit, ceea ce este greșit sunt creatorii săi care trebuie schimbați.
Cât de exagerat. Te-a atras faptul că este software gratuit și ce se întâmplă dacă sunt lucruri ciudate? și mai mult într-un proiect la fel de controversat ca acesta, credeți că nu sunt sute de geeks care caută să scoată piciorul de la pisică? senzaționalismul pff vinde întotdeauna mai mult
Pentru că Systemd este de fapt Skynet ... hahahaha
iar această bifurcație presupun că este condusă de canonică?
@emilian
Ce zici de Linux, din păcate ai dreptate și, cu mai mult regret, că există puțini administratori, mai puțin de 1/4 din utilizatori ... Deci, să sperăm că lucruri ciudate continuă să se întâmple așa:
systemd-journald [150]: Nu s-a reușit scrierea intrării (13 articole, 351 octeți), ignorând: Adresă greșită
Pentru a arăta că nu suntem nebuni, nici pentru puristi, ci pentru probleme tehnice.
Puteți vedea eroarea în acest cgit folosind ctrl + f, dar, bineînțeles, deoarece Lennart nu comentează de obicei, o altă practică proastă pe care o are, ei nu vor ști care este acea eroare:
http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-server.c
Nu ești singurul elav:
https://bbs.archlinux.org/viewtopic.php?id=150704
Există multe postări cu asta, dar nu văd niciunul care să spună cu adevărat ce este, mi se pare un bug și mi se pare cele de la PulseAudio cu polenul său care l-au trezit și evenimentele suprimate
Teribil!!
Și, deși este posibil să nu o credeți, există multe altele care raportează această eroare, se pare că provine dintr-o altă eroare și că este un simptom, dar, de asemenea, că este propria eroare, pe scurt, systemd este plin de erori, cel puțin sysv nu a avut erori, atât de mult timp, care s-a dovedit a fi super lustruit. Astăzi am încercat să dezactivez Journald într-o mașină virtuală, nu mă lasă, este imposibil, singurul lucru pe care îl poți face este să pui syslog și să-l faci pe Journald să-ți trimită lucruri astfel încât să le scrie, dar, dacă Journald eșuează? ... De când nu poți dezactiva o autentificare daemon în Linux? ... Lucrul cu Windows, atunci ei spun că este modular, dacă văd
Nici el dmesg îi salvează. La ochi observ că JournalD este blocat.
Sper că OpenBSD sau Fundația Apache își vor arăta sprijinul pentru o astfel de furcă.
@elav
Aveți companie, alăturați-vă raportului de erori pentru a vedea dacă lennart funcționează puțin:
https://bugzilla.redhat.com/show_bug.cgi?id=1069828
Este un bug.
Am adăugat că este un Bug generat de altceva doar că este un „alt” simptom conform celor ale fedorei, dar cu aceeași origine:
https://bugzilla.redhat.com/show_bug.cgi?id=1043212
TRĂIEȘTE DMESG!
Acum, serios, datorită eșecului epic al JournalD, îmi voi arăta sprijinul pentru furculita SystemD, deoarece cu JournalD nu înțeleg prea multe (cu DMESG vedeți destul de multe erorile de boot ale kernel-ului și chiar și demonii chiar și din SystemD ).
Mulți oameni resping systemd deoarece nu respectă filosofia Unix. Domnilor, Unix este pe moarte și este în pericol de dispariție, există momente în care trebuie să renunțați puțin la legăturile din trecut și să încercați să faceți ceva mai bun chiar dacă se rupe de vechea filozofie. Lasă conservatorismul și dacă systemd îți dă o problemă, atunci raportează eroarea și ajută la testarea patch-urilor care o rezolvă. În opinia mea, inutil nu va ajunge nicăieri, așa că numele său vine la îndemână, inutil, inutil, o pierdere totală de timp și efort care ar putea fi cheltuită făcând ceva mai bun.
Omule, dar nu ai văzut linkurile din aceeași postare către RedHat Bugtracker? Creatorul Systemd nu răspunde și nu comentează niciunul dintre ele. La ce folosește raportarea erorilor dacă tipul le trece prin linie?
În acest moment, SystemD a raportat 240 numai în bugzilla RedHat (cu rapoarte și pe alte pagini):
https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&component=systemd&product=Fedora
Cu maximum 3 sau 4 persoane care lucrează, conform Wikipedia:
https://en.wikipedia.org/wiki/Systemd
Trebuie să lucrați cu erori care pot dura de la câteva zile la câteva luni pentru a fi remediate. Și la asta trebuie să adăugați că trebuie să adauge funcții noi și să elimine codul vechi.
Crezi că au timp să răspundă la fiecare dintre rapoarte?
Aici mai mulți cred că au dreptul să comenteze munca programatorilor de sisteme, când cel mai mult au făcut este să scrie un script în Bash sau Python și să pună o temă WordPress, dar își coboară picioarele dacă trebuie să mențină un nivel ridicat -program de calibr.
Marea majoritate a celor care se plâng de SystemD nu au nicio idee despre ce vorbesc. Este doar o grămadă de găini care scârțâie.
Pentru inceput hypersayan_xDacă aș lansa o aplicație precum SystemD, primul lucru pe care l-aș face în primul rând ar fi să documentez cât mai bine care sunt specificațiile sale, posibilele sale probleme, semnificația jurnalelor sale etc. Cu aceasta, s-ar evita supărări ca ale mele, unde încă nu știu ce naiba înseamnă eroarea fericită (sau mesajul):
systemd-journald[150]: Failed to write entry (13 items, 351 bytes), ignoring: Bad addressÎn plus, consider că, dacă vrei să te dedici creării unei aplicații, ar trebui să petreci cel puțin 1 oră din timpul tău răspunzând la bug-urile prezentate de persoanele care o utilizează. Dacă nu vă descurcați, lăsați măcar un mesaj sau anunțați-mă, dar dacă nu răspundeți, ne lăsați în incertitudine.
Fiecăruia după munca sa ... și fiecare este responsabil pentru ceea ce face. Nu înțeleg ce înseamnă această parte a comentariului, pentru simplul fapt că un designer de teme WordPress (sau un utilizator care instalează pur și simplu o temă) sau o persoană care programează un script Bash sau Python nu este obligat să mențină un program „de mare calibru”, departe de el. Așa cum ar spune unchiul Ben: "Cu o mare putere vine o mare responsabilitate", care o duce la subiectul care ne ocupă: «Un program grozav are o mare responsabilitate«, Și pe răspundere înțeleg totul: Asistență, Dezvoltare etc.
Dacă sunteți atât de amabili încât să explicați în detaliu și cu date tehnice cum funcționează Systemd, astfel încât aceia dintre noi care ne fac să ne oprim sau pur și simplu să înțelegem mai bine, vă mulțumesc la infinit.
În ceea ce priveşte
Este perfect documentat:
http://www.freedesktop.org/wiki/Software/systemd/
Secțiuni: Manuale și documentație pentru utilizatori și administratori y Documentație pentru dezvoltatori
Ti se pare putin?
Iată linia acelui mesaj:
http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-server.c#n513
Și codul relevant apare în L448, deci totul depinde de ce mesaj ți-am dat înainte.
Așa funcționează toate forumurile de pe internet, pot să vă răspundă sau nu, dacă nu răspund, se poate datora faptului că nu au răspuns, nu sunt interesați de mesajul dvs., au alte priorități sau lucrează la altele lucruri și nu au timp pentru tine. Acceptați că nu sunteți centrul universului, în plus față de faptul că nu primesc nimic de la dvs. pentru a remedia o eroare care vă afectează în mod special.
manual acolo. este o chestiune de citire, poate problema este că mulți oameni nu o citesc, nu sunt pe debian. dar nu mă limitez doar la omul care este împachetat http://www.freedesktop.org/software/systemd/man/systemd.html,
Am citit blogul lui http://en.wikipedia.org/wiki/Lennart_Poettering există un ciclu foarte bun de (tutoriale) http://0pointer.de/blog/projects/systemd-for-admins-1.html
@hipersayan_x Chiar prieten? Vă invit (încă o dată) să traduceți pentru mine ce înseamnă linia 513 din link-ul pe care l-ați pus pentru mine, pentru că nu văd cum explică asta problema care este faptul că acest mesaj aruncă.
Nu este vorba despre mine, este vorba despre o mulțime de oameni .. Vezi link-ul din comentariul # 66. 😉
@elav, repet, în funcție de ceea ce poate fi citit în CF, înainte de acel mesaj trebuie să apară un alt mesaj care să indice de ce nu a fost posibil să scrieți în jurnal și, prin urmare, aceasta ar fi adevărata problemă.
Este bine că lucrurile sunt bifurcate, este un mod de măsurare a eficienței, mă face să râd, că dezactivează caracteristicile pe care le folosesc zilnic și accelerează experiența utilizatorului sau, în alt mod, servesc la automatizarea sistemului, îl consider ca apreciere a unui utilizator începător în ceea ce privește gradul de utilizare a sistemului. Este o problemă de creștere (maturizare) în ceea ce privește aprecierile de utilizare a sistemului, poate pentru că îmi place mai mult să le văd ca seturi de ordine într-un script, în loc de oglinzi colorate. Poate că este mai util să citiți manualul mai des și să faceți propuneri despre cum să creați un sistem mai automat, dar într-un cadru logic, definit de utilizator (care nu este întotdeauna în fața terminalului).
În ceea ce priveşte
@STARE BRUTĂ
Automatizarea lucrurilor, îndepărtarea flexibilității și generarea impunerii, nu puteți pune pe toți în aceeași pungă, definind ceva automat căutați furcile care vor fi generate, deoarece vor exista mai mulți oameni nemulțumiți care nu vor sta așezat în jurul lor creați o fereastră nouă.
Câteva comentarii de mai sus, am întrebat dacă știți de vreo distribuție care are pachetul systemd fără „modulele opționale”, dar se pare că nu există ... nu mi-a răspuns nimeni.
În cazul meu nu am nevoie, am trăit fericit cu gentoo de mai bine de 5 ani cu eudev și openrc, dar am un notebook pe care îl folosesc puțin, care încă mai are archlinux, îl actualizez în continuare pentru a vedea cum merg lucrurile și să nu-ți dai o părere după auzul a ceea ce spun alții.
Să le atingem! @ # $% Tocmai am luat micul dejun că în ArchLinux nu există crontab, cron este tratat cu Systemd .. Grrrr
https://wiki.archlinux.org/index.php/Systemd/cron_functionality
@elav
Distribuțiile care nu utilizează systemd trebuie promovate, nu există altă cale.
Știu, nu vor fi cele mai ușor de instalat, dar au văzut direcția tuturor acestor lucruri
Cred că vor începe să apară mai multe distrosuri născute din LFS-uri, cum ar fi acest lucru
a fost mama archlinux și înțeleg că încă folosesc init.
Pot apărea și distrosuri în stil Sabayon care nu sunt altceva decât fotografii
gentoo pe binare i686.
Systemd este ca tema AC / DC „Got You By The Balls”
https://www.youtube.com/watch?v=2ICWCMaRypI