Astăzi citind RSS-ul meu am aflat o veste interesantă că Blog Aspectul replicatoruluiși este că în Comunitatea Manjaro au fost lansate mai multe ISO-uri cu particularitatea pe care nu o folosesc systemd ca init, altfel OpenRC, sistemul de pornire utilizat de Gentoo.
Nu știu despre tine, dar tema Systemd deja îmi atinge mult mingile și, cu cât citesc mai mult, cu atât îmi dau seama că, deși pentru utilizatorul final (sau pentru mulți) nu reprezintă nimic super relevant, la cel puțin pentru mine, nu-mi place calea pe care o ia aceasta. Cred că vine un sezon negru în lumea GNU / Linux, unde furcile și nemulțumirea vor izbucni chiar și în deșerturile aride.
Dar să trecem la treabă. În forumul Manjaro au publicat, așa cum am spus mai înainte, câteva isos pe care OpenRC le folosește. Și pentru cei cărora le este frică să instaleze aceste versiuni, las videoclipul despre cum să o faci.
Descărcați ISO-uri cu OpenRC
Primul ISO pe care îl vom vedea este versiunea NetInstall. Această ISO are următoarele caracteristici:
- Pe baza profilului Manjaro-Net (nu este preinstalat niciun mediu desktop)
- Bazat pe ramura Testare.
- Numai drivere gratuite
- Utilizați nucleul Linux seria 3.14
- Nu folosește Plymouth
- A fost testat în Virtualbox
Limba poate fi selectată la început apăsând tasta F2. Odată ce procesul de boot este terminat, vom găsi promptul, unde vom folosi pentru a accesa:
- Utilizator: root
- Parolă: manjaro
Pentru a începe instalarea așa cum se arată în videoclipul anterior, vom scrie:
setup
Linkuri pentru descărcarea ISO-urilor
manjaro-net-0.8.11-openrc-i686.iso (32 biți)
(md5sum: 80be54ecfb0360b2a8e544344f72113c)
manjaro-net-0.8.11-openrc-x86_64.iso (64 biți)
(md5sum: ef205f70f3b3428545fdf1420db10b74)
Instrucțiuni post-instalare
În Forum Manjaro Acestea ne oferă câteva date pentru post-instalare:
Adăugăm depozitul openrc-eudev urmând aceste instrucțiuni.
1) Adăugăm următoarele la finalul /etc/pacman.conf
[openrc-eudev] SigLevel = Server opțional TrustAll = http://downloads.sourceforge.net/project/mefiles/Manjaro/$repo/$arch
Adăugăm și importăm cheile:
sudo pacman-key -r 518B147D sudo pacman-key --lsign-key 518B147D
2) Actualizăm sistemul
sudo pacman -Syu
3) Instalăm mediul nostru desktop preferat, exemplul îl folosește lxde
sudo pacman -S lxde
Informații despre instalarea mediilor desktop pot fi găsite în Wiki.
4) Instalăm un Session Manager:
sudo pacman -S lxdm-consolekit
5) Instalăm unele pachete precum applet-ul pentru networkmanager
sudo pacman -S network-manager-applet
6) Repornim sistemul
sudo reboot
Cred că este de la sine înțeles că pentru aceasta trebuie să fim conectați la Internet printr-un cablu. Dacă folosim WiFi, puteți vedea cum să o faceți acest link.
ISO Manajaro cu OpenRC și OpenBox
În cazul ISO Openbox, trebuie luate în considerare unele lucruri:
- Obiectivul principal este de a face procesul de instalare mai ușor și permiteți înființat formă grafic rețeaua (folosind wicd) și partiționarea utilizând GParted opțional.
- Configurarea include Openbox WM, LXTerminal, PCMan și Browser Web NetSurf (a căuta informații în Wiki o google), etc
- Utilizați programul de instalare a consolei.
Link-uri pentru a descărca ISO-urile cu OpenRC:
manjaro-openbox-openrc-2014-11-13-i686.iso (32 biți)
(md5sum: 9be7e75c75ab296f955a3396386c4764)
manjaro-openbox-openrc-2014-11-13-x86_64.iso (64 biți)
(md5sum: 07fd57df022118dfc9e2794a0ca3d26e)
Manjaro XFCE ISO cu OpenRC
Numai experimental și pentru 64 de biți, există și un ISO cu XFCE:
manjaro-xfce-openrc-2014-11-14-x86_64.iso (64 biți)
(md5sum: e132f294f2ffd99c6cbc371d1e7a6d72)
Ai dreptate, problema systemd începe să dea un anumit suflet, deoarece OpenRC este succesorul natural al inițiativei actuale. Vom vedea unde se termină această poveste.
„Deși pentru utilizatorul final (sau pentru mulți) nu reprezintă nimic super relevant”
Cred la fel, nu este relevant deoarece, ca utilizatori, nu ne-a afectat în funcționarea sistemului de operare în sine.
De fapt, singurul mare (debian), a dat știri despre „scandal” pe această temă și, deși spun că există și alte motive, toate sistemele conexe (și nu ar trebui).
Celelalte distribuții mari, nu au făcut o problemă (sau cel puțin s-au manifestat cu pică și făclii), Fedora, Ubuntu și OpenSUSE.
Îmi dă impresia că este o luptă între programatori, deoarece, de exemplu, opensuse 13.2 are o bună acceptare / critică și nimeni din recenzii nu vorbește despre systemd (chiar dacă este pentru a stabili dezbateri)
Acum, de ce toată agitația de a trece de la systemd la OpenRC, dacă nu le afectează până la urmă.
Personal, chestia cu sistemul mă face să mă neliniștesc, am nesiguranță, postare bună.
În Fedora a existat o anumită dezbatere despre systemd atunci când s-a decis punerea acestuia ca init, au existat unii detractori ai sistemului, în principal pentru că nu au fost de acord să-l folosească ca init în mod implicit, deoarece era foarte proaspăt și avea multe defecte, totuși Majoritatea dezvoltatorilor majori fac parte din echipa de dezvoltare principală și au fost legate de systemd, așa că înlocuirea Upstart cu systemd a fost un semn de o anumită impunere, pe lângă problema că Upstart a fost o dezvoltare Ubuntu și are un CLA destul de încruntat, ceea ce la final a ajutat pe toată lumea să accepte systemd fără nicio întrebare. La acel moment, OpenRC nu era pus în discuție, deoarece nu avea multe dintre caracteristicile pe care le are acum, inclusiv paralelizarea și suportul grupului.
Vesti bune! o distribuție binară care va elibera openrc .... este ca o mână de Dumnezeu.
Este calea pe care ar fi trebuit să o parcurgă archlinux de la început, îmi amintesc când a trebuit să susțin archlinux pentru a merge la systemd. Acum am posibilitatea de a retesta o distro binară cu openrc + eudev care este exact ceea ce folosesc aici în gentoo.
Mulțumesc oamenilor din Manjaro !!!
# eix -Ic openrc
[I] sys-apps / openrc (0.13.6@24/11/14): OpenRC gestionează serviciile, pornirea și oprirea unei gazde
# eix -Ic eudev
[I] sys-fs / eudev (2.1.1@31/10/14): suport dinamic și persistent pentru denumirea dispozitivelor Linux (alias devfs spațiu utilizator)
Mulțumim pentru informații, elav!
Îmi împărtășesc părerea cu privire la systemd și sunt, de asemenea, îngrijorat de deriva pe care Linux a luat-o de la apariția acestui nou init. Dacă Wheezy îmbătrânește înainte de sosirea furcii Debian, mă voi gândi să încerc Manjaro OpenRC, deoarece nu am timp liber să pregătesc un sistem Gentoo (am apreciat acest lucru, dar cu siguranță timpul de compilare a Gentoo este prea extins pentru situația mea personală).
Salutări!
Elav îl poți descrie în mai puțin de 10 cuvinte pentru un utilizator care nu înțelege prea mult „controversa”, au existat o vreme mai multe articole pe blog care sunt foarte tehnice și nu termină de explicat contextul pentru „neinițiați” ... vreodată Mi-au spus că, indiferent de tehnică, o explicație trebuie înțeleasă chiar de bunica ta ca fiind bună.
De fapt, în Fedora, cu ceva timp în urmă, problema devenea insuportabilă, atât de mult încât mai mulți utilizatori de desktop se gândeau să treacă la centos, pentru a ocoli problema.
Mă înscriu pentru solicitarea respectivă.
Systemd funcționează bine pentru mine. Care este problema care provoacă atât de multe mișcări?
Să spunem că nu știu.
systemd este programul însărcinat cu pornirea sistemului, dar dezvoltatorii acestuia au decis să îl extindă și acum nu se ocupă doar de pornire, ci și de lucruri precum cron (programul care rulează automat programele), rețeaua, jurnalele de sistem care, de altfel, sunt binare, printre altele
Mulți nu privesc favorabil o astfel de schimbare bruscă, mai ales că este un software nou, prin urmare, cu multe mai multe bug-uri decât programe care au funcționat toată viața lor, pe lângă generarea de dependențe atunci când programează și, de exemplu, gnome este din ce în ce mai legat de acest sistem. Făcându-l mai puțin portabil pentru alte platforme Unix.
Nu știu dacă celălalt comentariu al meu nu a trecut de moderare, dar a spus că mi-a plăcut systemd, dar nu ar trebui să-l lase să monopolizeze toate distribuțiile și să lase alternative așa cum sa făcut întotdeauna în Linux pentru cei care au nevoi diferite.
Trebuie să spun că înainte de programul însărcinat cu pornirea sistemului la pornire era sistemul v, care funcționa de mult timp până când a fost înlocuit în majoritatea distribuțiilor cu systemd xD.
La ceea ce spune @daryo adaug următoarele (care este și părerea mea):
Întotdeauna mi-a plăcut filosofia Unix în care un program face doar un singur lucru, dar o face bine. Când Systemd vrea să controleze tot ceea ce ți-a spus @daryo, am o mică îndoială și ce s-ar întâmpla dacă Systemd este cumva compromis? Ei bine, ar trage cu el tot ce controlează.
La asta adaug (și poate asta este mai mult din obișnuință), că mi-a plăcut întotdeauna că jurnalele mele de sistem sunt fișiere text pure, dar cu Systemd totul este binar și comenzi precum:
cat log.txto
tailf log.txtUnde am putea folosi alte opțiuni precum GREP pentru a filtra anumite conținuturi, dar Systemd folosește o comandă numită jurnalctl.
În plus față de cele menționate anterior, trebuie să spun că fiind RedHat principalul exponent din spatele Systemd, primesc o alertă pe care nu o pot opri. Poate mă înșel, dar acest lucru nu arată bine .. Și mă tot întreb ce nevoie are de a controla boot-ul, cronul, rețeaua și cât de mult serviciu există? Ce înseamnă prin asta?
Datorită comentariului dvs. și a ceea ce am cercetat, vă pot confirma suspiciunile, că alerta este corectă, Broder.
Vei vedea că am citit despre TCP Stealth, este o teză germană în care acuză Red Hat că facilitează spionajul industrial către sistemele de ascultare ale celor 5 ochi:
Am scris deja despre acest lucru, dacă aveți talentul necesar, știu că îl aveți, puteți ajunge la propriile concluzii:
https://gnunet.org/sites/default/files/ma_kirsch_2014_0.pdf
http://heise.de/ct/artikel/GCHQ-NSA-El-programa-HACIENDA-2293098.html#TCP Stealth
Doar pentru a completa comentariul tău frumos @elav, systemd este NIH atât de mare încât acum pretinde că controlează următoarele:
1.- Gestionarea conexiunilor la internet cu IPv4 și IPv6, folosind systemd-networkd și systemd-nspawn.
2.- Gestionarea DNS printr-un cache DNS intern, sistem-rezolvat.
3.- Gestionarea DNS multicast în rețelele interne, folosind systemd-networkd.
4.- Gestionarea terminalelor TTY în Linux, utilizând sistem consolat. (La revedere KMScon?)
5.- Gestionarea sesiunilor și privilegiilor prin logind.
6.- Controlul Coredump, folosind fișiere binare și omiterea directivelor kernel-ului.
7.- Controlul jurnalelor, folosind fișiere binare și omiterea directivelor kernelului.
8.- Controlul evenimentelor ACPI folosind logind. (Systemd-212 a adăugat mai multe dureri de cap la dezvoltatorii Nvidia cu diverse erori care au făcut ca sistemul să fie inutil)
9.- Suport PPPoE pentru networkd, o lucrare care este încă în desfășurare.
10.- Suport pentru DHCP în client și server. (Ce fac cu asta? Fără idee)
11.- Suport pentru sisteme cu resetare din fabrică, care de altfel este strâns legat de BTRFS (Nu vă mirați dacă BTRFS devine mai târziu o dependență de systemd, Lennart bun îl iubește)
12 ..- Suport pentru containere virtualizate (Xen și KVM în principal)
13.- Suport pentru manipularea și inițializarea dispozitivului (ce face udev)
14.- Manipularea sistemelor de criptare a discurilor.
15.- Încărcarea modulelor firmware și kernel.
16.- Manipularea numelui de gazdă (creează un identificator unic pentru computerul dvs.), local, ora, sincronizare NTP, sysctl (variabile de control ale nucleului) și chiar generatorul de numere aleatorii (Foarte WTF și crește multe suspiciuni)
17.- Manipularea sistemelor de fișiere temporare.
Pe scurt, sunt lucrurile pe care știu că le face systemd, dacă cineva știe mai mult decât să le spună :).
PS: systemd nu mai oferă suport pentru scripturile LSB și SysV de la systemd-214, deci nu știu cât de adevărat este suportul lor „moștenit” acum sau cât de conforme sunt standardele. Spun că LSB este încă standardul în Linux sau mă înșel?
Mulțumesc că mi-ați anunțat, mă gândeam să merg la BTRFS, dar știind că Lennart îl place, poate știți că trebuie să fie oribil și să spioneze NSA-IBM
Există puțin spațiu pentru a rezuma și a explica atât de multe ... este un cal troian uriaș, pe care nici măcar nu încearcă să-l arate. Ce face un sistem de pornire punând servicii de rețea, dhcp dns și chiar cred că avahi ... în systemd? Puterea de decizie se pierde prin imposibilitatea de a gestiona serviciile
care nu sunt dorite și că nu vin la mine care pot fi dezactivate, nu le vreau în pachetul systemd!
În OpenRC, unul este cel care decide ce lucruri sunt pornite în fiecare nivel de rulare, unele servicii au dependențe de alte servicii, dar sunt foarte puține și sunt listate ... în timp ce în sistem orice face tot ce vrea în acest moment Are chef ... să câștige aproximativ 5 secunde la boot și să fie rapid la oprire.
Systemd este atât de complex încât este imposibil să știi ce face, trebuie să te resemnezi să crezi că este stăpânul tău și nu îți face nimic rău.
Systemd încalcă conceptul că lucrurile ar trebui să fie ușoare și ușor de înțeles în termeni de demoni sau servicii și niveluri de rulare, nimeni care folosește systemd nu știe pe deplin ce se întâmplă în serviciile lor în orice moment.
Systemd nu permite utilizarea syslog-ng în mod nativ, au făcut-o pe Journald să-l pășească și nu-l lasă să funcționeze, adică sau folosiți Journald sau naninga! Jurnalul de sistem este fundamental pentru securitatea și auditul a ceea ce s-a întâmplat și se întâmplă cu conexiunile locale și la distanță, dar journald folosește un format binar pe care doar jornalctl îl poate vedea .... Foarte des journald se corupe „misterios” fișierul său binar și ca îl vede corupt, îl șterge o dată și începe cu unul nou, uitând de toate jurnalele care existau deja.
Pot continua ore în șir, dar cea mai gravă problemă este că Lennart nu dă mingea celor care raportează acele erori și, din câte am citit, nu acceptă patch-uri de la nimeni.
M-am gândit că, intrând în systemd, vor raporta bug-uri și patch-uri, pe care systemd ar trebui să le accepte ... dar sincer cred că Lennart și RedHat au un alt plan pentru restul distrosurilor ... așa cum am spus mai înainte, CAL DE TROYA de la RedHat.
Sincer pentru mine systemd nu se poate rezolva, ideea din spatele designului său este rău, este mai bine să porniți un sistem bootabil de la zero decât să încercați să remediați acel frankestein.
AMIN!! @anonim..
Folosesc systemd (Fedora) de câțiva ani și am ajuns la asta:
Problema miroase ciudat, deoarece mai multe lucruri adaugă mai mult dezactivare / redirecționare
Jurnalul pe care l-am îndreptat direct către rsyslog. Câteva jurnale binare ale dvs. au fost deja sparte.
Din dns folosesc bind, dacă îl integrează în systemd voi continua să-l folosesc la fel, chiar dacă trebuie să modific totul.
Folosesc XFCE, așa că mă economisește mult din ceea ce vrea să integreze gnome.
Este ca un elefant într-un magazin de porțelan.
Adevărat; chiar și ei nu știu cum să-i spună. Ieșim să actualizăm zilnic, corectând bug-uri și alte prostii. Este un subiect care mă enervează destul; dar nu numai din cauza faptului că SystemD este un rahat suveran; dacă nu cum au făcut-o.
Este clar că în lumea Linux există mai multe companii care încearcă să controleze totul; vezi Canonical, RedHat și Gnome (chiar și Miguel de Icaza a părăsit Gnome).
Dacă folosesc Linux, este pentru că îl controlez și aceasta este baza și filosofia acestuia; Pentru a nu ști ce face, montez mașini cu W Server deja rulat.
Îmi pare rău că Debian a cedat. De fapt, se are în vedere posibilitatea creării unei furci paralele fără SystemD.
Să sperăm că lucrurile nu se înrăutățesc; sau mă văd migrând toate mașinile la BSD.
@ anonim, comentariu, omule, nu poți avea mai multă dreptate.
systemd este un lucru nebunesc care nu are nicio explicație în multe lucruri, adevărul este foarte suspect de tot ceea ce face și nu permite altor instrumente să o facă, adevărul este că nu știu cum oamenii Debian își permit să pună acest lucru, dar în cele din urmă au luat deja acea decizie , și pentru prima dată în mulți ani am încetat să folosesc Debian ca SO principal și voi continua să fac acest lucru până când systemd părăsește Debian pentru o opțiune mai transparentă.
Pe scurt. SystemD e de rahat.
Stochează jurnalele în format binar, este executat ca proces părinte al tuturor celorlalte, (Pid 1), astfel încât, dacă se sparge unul, sistemul devine nerecuperabil; Merge împotriva a tot ceea ce reprezintă Linux, adică fișierele text simplu (ce naiba este fișierele binare ??, fișierele text simplu! Ca toată viața lui Dumnezeu.)
Haide, asta e o porcărie. Nu-mi place deloc nimic.
Dar datorită unor companii precum Canonical, Gnome și Red Hat; o vom mânca cu cartofi.
Asta dacă, în timp ce există alte opțiuni; Nu îl voi folosi, nici pe serverele pe care le administrez, nici pe mașinile mele personale.
Aceasta devine deja o sucursală a companiei Redmond.
Nu vreau să apăr pe nimeni, dar îmi amintesc bine că canonicul era total împotriva systemd în favoarea parvenitului. când debian a cedat la systemd a ajuns să se tragă pe Ubuntu.
În plus, aceste bug-uri pot compromite securitatea sistemului și stabilitatea unui server, de exemplu, de aceea cei care se plâng cel mai mult de aceste lucruri sunt administratorul sys.
Și ce zici de Mageia, este incredibil că un KDE poate rula pe 512 MB de RAM, impecabil.
http://mirror.cedia.org.ec/mageia/iso/cauldron/
cateva intrebari; Cât de ușor este să gestionezi serviciile în OpenRC? și cât de ușor este de instalat folosindu-l implicit într-o instalare Manjaro cu systemd? ceea ce îmi place la systemd este că, cu simpla comandă systemctl enable (service) .service sau un systemctl disable (service) .service îmi pot gestiona serviciile cu ușurință, DACĂ sunt interesat să aflu despre OpenRC și mai ales dacă îmi miroase puțin ciudat toate acestea de la systemd, apropo; Sunt un utilizator novell
Apropo; Se spune că sunt pe Windows, deoarece folosesc overrider agent de utilizator
OpenRC este foarte ușor de manevrat, vă dau un exemplu cu serviciul de tipărire cupsd.
Pentru a-l începe.
# rc-service cupsd start
* Începând cupsd .. [ok]
Pentru a o opri.
# rc-service cupsd stop
* Oprirea cupsd ... [ok]
Pentru a-l reporni.
# rc-service cupsd reporniți
* Oprirea cupsd ... [ok]
* Începând cupsd .. [ok]
Pentru a-l pune să înceapă în nivelul de rulare implicit.
# rc-update add cupsd implicit
* cupsd de serviciu adăugat la nivelul de execuție implicit [ok]
Pentru a-l elimina din nivelul de rulare implicit.
# rc-update din cupsd implicit
* cupsd de serviciu eliminat din nivelul de execuție implicit [ok]
Pentru a vedea starea tuturor serviciilor în toate nivelurile de rulare.
# rc-status -a
Pentru a vedea starea unui nivel de rulare, în acest exemplu implicit.
# rc-status implicit
Aici, în gentoo, OpenRC este sistemul de pornire implicit și va rămâne așa pentru totdeauna, avem sistem în portare pentru sinucigași, care din fericire sunt puțini ...
Pentru a înlocui journald, folosim syslog-ng și logrotate, aici în gentoo jurnalul sistemului iese prin consola virtuală vt12 care este control + alt + F12, sau îl puteți vedea continuu în orice terminal grafic ca utilizator root cu:
# tailf / var / log / messages
Și să-l instalez pe Manjaro?
Spun; Nu voi pierde toate fișierele și frumoasa mea XFCE doar pentru trecerea la OpenRC RC
Gata; L-am instalat folosind sudo pacman -S manjaro-openrc bluez-openrc (acesta din urmă pentru că am bluetooth)
Acum problema mea este că managerul de alimentare XFCE4 nu funcționează cu upower-pm-utils 🙁 și nu am opțiunile tipice de suspendare și hibernare
OpenRC este foarte simplu, gestionarea serviciilor este o bucată de tort, doar pentru a da un exemplu:
Activați un serviciu: rc-update adăugați cronie implicit
Porniți un serviciu: /etc/init.d/cronie start sau rc-config start cronie
Opriți un serviciu: /etc/init.d/cronie stop sau rc-config stop cronie
Simplu și deloc complex.
@elav, ceea ce ne așteaptă este pentru cursa lungă, variind de la furtuni de nisip, ploi ale trolilor, furci în vrac, divizări ale grupurilor de dezvoltatori și mulți care se întreabă dacă migrarea la BSD este o opțiune mai bună decât blocarea în systemd, pentru că da.
Personal, aplaud această inițiativă a lui Manjaro, este o opțiune pentru cei care nu doresc să rămână cu systemd, lucru care îmi place, în acest moment sunt în Gentoo și îmi place, mă simt confortabil cu libertatea pe care mi-o oferă , dar acum Mi-a trecut prin minte de mai multe ori să fac schimbarea la FreeBSD și poate să fac saltul luna aceasta, totul depinde de timpul meu și de a comanda anumite lucruri pentru a efectua migrarea cu succes.
Argumentele împotriva systemd au fost mult timp respinse. Citiți încă ceva, vă rog.
http://0pointer.de/blog/projects/the-biggest-myths.html
http://diegocg.blogspot.mx/2014/02/la-sombras-de-sysyinit.html
http://diegocg.blogspot.mx/2014/02/por-que-kdbus.html
Nimic din toate acestea nu infirmă realitatea systemd, Lennart se pricepe foarte bine la evitarea lucrurilor și responsabilităților, vă recomand să în loc să citiți articole, să citiți codul systemd sau cel puțin să citiți lista de dezvoltare a systemd, veți afla despre lucruri care resping ceea ce spun aceste trei articole care s-au întâmplat și susțin mai mult detractorii sistemului.
Argumentul său este de a stabili că există cunoștințe care resping ceea ce am arătat, dar nu prezintă niciodată dovezile, așa că nu pot avea încredere în existența sa.
https://lists.debian.org/debian-ctte/2013/12/msg00234.html
@pamp argumentul meu este un pic mai mult de sprijin, deoarece l-am explicat mai sus în comentariul 25 din aceeași intrare și l-am expus în multe alte intrări referitoare la systemd, pe lângă expunerea acestuia în Debian irc și lista acestei distribuții, De asemenea, invitația mea este că vă creați propriile opinii și pentru aceasta trebuie doar să citiți o mică listă de dezvoltare sistemică. De asemenea, doar pentru a vă stârni curiozitatea, vă dau acest link în care spun clar că systemd-214 nu mai oferă suport pentru scripturile SysV și LSB, cu scuza „curățării codului”.
http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html
Acum spuneți-mi: Unde este suportul pentru standardul LSB care trebuia creat pentru a crea o bază comună pentru toate distribuțiile? Pentru că permiteți-mi să vă spun ceva, nimic altceva în primul său link, Lennart se plictisește, se laudă și își umple gura spunând că systemd acceptă utilizarea scripturilor SysV și LSB, atunci când adevărul este că suportul este abandonat și înlocuit cu un generator de init-files, care, apropo, are mai multe bug-uri și, în cele din urmă, nu există altă opțiune decât să faci un fișier init complet.
Salutări.
Părerile, sunt ca fundul, cu toții avem una.
Ceea ce spune acest bărbat poate merge foarte bine pentru el, dar nu este cazul meu. Iar opinia unui om care scrie pe un portal web nu este că este vorba de cuvântul lui Dumnezeu. Este părerea ta, punct.
Deci „infirmat”, nimic.
Lucrul bun care ne-a rămas este că putem folosi orice vrem cu adevărat; fără a încerca să fim „talibani” și să impunem criteriile noastre altora.
Pentru mine SystemD este un adevărat rahat. Și există oameni care îl iubesc. Bine ați venit!
Nici părerea mea nu este bună, nici cea a celor care nu gândesc ca mine este un rahat; ele sunt pur și simplu diferite.
Iată ce ne deosebește de alte sisteme de operare; putem alege.
Să nu intrăm în lupte inutile care nu duc nicăieri.
@Titus
Nu ai fi putut spune asta mai bine ... amin.
Trebuie să fii orb pentru a nu-ți da seama de perversitatea pe care o conduce sistemul pentru a acoperi totul, călcând, acoperind și deplasând proiecte care funcționează perfect, înlocuindu-le cu versiuni care nu ajung niciodată sau nu devin stabile, chiar dacă nu există compatibilitate între nuclee și mai mult de două versiuni înapoi ale systemd.
Se pare că Debian a avut cutremurul și au reușit să se trezească, sper doar să se aplece spre eudev și openrc, astfel încât dezvoltarea gentoo debian manjaro și a altor alții care folosesc openrc ar fi unificată, ceea ce l-ar îmbunătăți foarte mult pe scurt timp, câștigând întreaga comunitate.
Îți secundez cuvintele.
Există oameni care citează alți oameni (opiniile care îi interesează, în general) și îi folosesc drept dovezi.
La rândul meu, nu am nici o părere cu privire la systemd. Nu știu dacă este mai bun din punct de vedere tehnic decât upstart sau openrc, dar ceea ce pare clar este că posibilitatea sysvinit este exclusă de TOATE distribuțiile, Debian fiind singurul care încă l-a păstrat în Wheezy datorită politicii sale. Dar următorul Debian stabil, Jessie, avea să fie un Debian fără sysvinit.
Ceea ce este clar este că din punct de vedere etic este un software 100% gratuit; În ceea ce privește partea sa tehnică, nu am studiat nici codul, nici nu l-am comparat cu alternativele sale, deci nu am o opinie motivată. Dar chiar și astăzi Ubuntu folosește părți din systemd, deși încă au început, și mă îndoiesc că au făcut-o pentru că Canonical este „cumpărat” de Red Hat.
Systemd nu este „malefic”, vă rog, nu ne luptăm cu Skynet (Terminator) sau HAL9000 („Odiseea spațială din 2001”) și nici nu este partea întunecată a Forței care caută să domine Jedi. Și nici prin stabilirea într-o echipă preia totul și face să dispară chiar și produsele alimentare din cămară.
Și că „mută proiectele care funcționează perfect” (comentariul 52), am avut probleme cu o rețea NFS de acasă în computerele care accesează serverul, deoarece procesul de închidere a computerului client deconectează rețeaua înainte de a demonta sistemul NFS, iar închiderea ar îngheța, singura soluție fiind să apăsați butonul de pornire / oprire pentru a-l opri cu forța (eroare raportată de diverși utilizatori); A trebuit să creez un script care demontează fișierele NFS pentru a rula înainte de a opri computerul client. Pe de altă parte, computerul server NFS se conectează prin wifi și, din când în când, conexiunea se pierde: nu știu dacă problema este administratorul de rețea sau dacă este în dhcpd sau unde.
Nu spun că aceste probleme dispar cu systemd; O ignor, pentru că nu am folosit-o. Este doar un eșantion care spune că proiectele pe care systemd le înlocuiește funcționează perfect este o exagerare.
Un lucru este o opinie și altul este un argument, cu siguranță primul este foarte variat cum spui @Tito, dar al doilea este ceva mai concis și mai concentrat, nu este ceva care poate fi manipulat atât de ușor, cel puțin, nu în cazul software-ului gratuit, unde avem codul la îndemână pentru a fi revizuit.
@pamp ne spune că argumentele arătate au fost infirmate de mult timp și, ca prim test, ne aduce la curent cu opiniile lui Lennart (nu cu argumentele). Dar ceea ce spune acest tip în comentariile sale este un lucru (numerele 4 și 8 sunt doar pentru a muri pentru râs), iar ceea ce face în codul systemd este altul. O atitudine pe care am văzut-o în mod repetat în Lennart de când am început să dezvolt lucruri precum Avahi și Pulseaudio și care poate fi pur și simplu coroborată citind listele de dezvoltare și rapoartele de erori ale ambelor software.
@ Dah65, cu siguranță, mulți oameni folosesc dovezi folosind opiniile unor terți, un obicei prost pentru cei care nu pot investiga ei înșiși problemele să aibă propria lor opinie personală și chiar să creeze argumente valide cu care să participe la o discuție constructivă.
În cazul meu, mă țin la curent cu schimbările din systemd datorită listei de dezvoltare, deși nu îmi place instrumentul, nu-mi place total, dar nu mă opresc să citesc despre el la nivel de utilizator și tehnic, și motiv pentru care este foarte simplu, dacă trebuie să particip la un client care folosește inițiativa respectivă, știu ce ar trebui să fac și cum să mă ocup de orice situație.
Acum despre ceea ce serviciile rulează fără probleme, adică o eroare, există multe scripturi SysV cu probleme și același lucru se întâmplă în systemd, dar cel puțin atunci când raportați o eroare într-un SysV acestea sunt corecte sau puteți face acest lucru într-un mod simplu, așa cum ați comentat , în systemd, după ce faceți un raport de erori, puteți găsi un WONTFIX sau ÎNCHIS, datorită lui Lennart sau Kay, după caz, și nu exagerez când spun acest lucru, un exemplu aici:
https://bugzilla.redhat.com/show_bug.cgi?id=753882
Citiți comentariul 48, nu aveți nicio pierdere. Clement's 53 este un altul care nu are pierderi, mai ales pentru soluția sa arhaică, dar funcțională, la problema pe care Lennart nu vrea să o rezolve și care, incidental, a fost raportată în 2011.
Acei „mituri” care i-au stabilit? Unele sunt eliminate din galerie deoarece „systemd nu este portabil fără niciun motiv”. Este complet adevărat că nu este portabil (și recunoaște că spune că este foarte personalizat pentru Linux)
Presupune erori, ca și presupunerea că BSD nu este interesat (băieții BSD spun altfel: "Jordan Hubbard - FreeBSD: The Next 10 Years (MeetBSD 2014)"), chiar dacă ar fi portabil, nu l-ar adopta și așa ceva ( mit 13,14,15).
Dacă intenția Poettering este ca noi să rescriem scripturi, exclusiv pentru sistemul dvs. (http://0pointer.de/blog/projects/systemd-for-admins-3.html) vom merge prost. În principiu, unui script inițial clasic nu îi pasă unde te duci. Se fac modificări minime pentru a funcționa pe GNU, UNIX sau BSD. Ei bine, asta a fost până acum (dacă nu se folosește OpenRC). Oricum, cred că astfel de lucruri vor produce o schismă între Linux pentru desktop și servere. Utilizatorii Ubuntu și cei derivați vor vedea modificările doar la sfârșitul anului viitor.
@ Dah65
Ei bine, din moment ce spuneți că systemd nu este perversitate personificată, atunci spuneți-mi de ce nu pun opțiuni în Makefile pentru a dezactiva toate modulele sale la momentul compilării, astfel încât aceia dintre noi cărora nu le place să aibă acele „module opționale” "acel pas pe alte pachete, astfel încât să le putem compila și să creăm propriile noastre versiuni de sistem cu limită!
Știi de ce nu? deoarece forma sa de dezvoltare se numește impunere forțată și întrucât 95% dintre utilizatori nu au NPI, profită de valoarea implicită, am refuzat-o pentru voi toți.
Așa funcționează software-ul gratuit sau open source sau orice vor să-l numească, acum mă face să râd, pentru că odată cu noua bifurcație pentru Debian mulți oameni vin să creadă că este o pierdere de forță și mă întreb mereu cât de dificil a fost să pun opțiuni de compilare suplimentare la Makefile?
Subiectul nu dă pentru mai mult, este ca și cum ai vrea să amesteci apa cu ulei, de aceea vor exista furci nesfârșite în fiecare dezvoltare unde există o impunere de câteva pentru restul.
@mario este exact ceea ce spui. Jordan Hubbard și-a dat seama, de asemenea, că inițiativa BSD trebuie actualizată nu numai pentru a se adapta la noile tehnologii, ci și pentru a sprijini noile caracteristici care sunt acum posibile, dar el ocolește conceptul pe care îl are acum systemd despre cum ar trebui să fie realizate. lucruri și o simplifică la filozofia care a predominat întotdeauna în UNIX, „Faceți un program care face un lucru și îl face bine”, și că într-un inițiu este extrem de important, deoarece nu vorbim despre încă un demon, noi vorbesc despre inițierea unui sistem de operare, pe lângă faptul că este o măsură de securitate, în comparație cu ceea ce mulți specialiști încep deja să discute despre systemd și este demonstrabil, systemd seamănă mult cu svchosts.exe din Windows, făcând din inițierea serviciilor de control al rețelei printre multe alte lucruri.
Băieți, este într-adevăr înfricoșător.
Este foarte complicat să elimini din ArchLinux ????
Voi căuta informații, dar nu îndrăznesc să ating acest gen de lucruri, ca să nu mă înșel și să-mi pierd sistemul.
????
https://abchk1234.wordpress.com/2014/06/03/using-openrc-on-arch-archbang-manjaro-linux/
Din numeroasele comentarii pe care le-am citit, SYSTEMD este un adevărat CAL TROIAN ....
Există puține informații în limba spaniolă - despre configurarea desktopului în FreeBSD și pregătirea sistemului pentru a fi utilizată.
Slab sistem, lasă-l să fie. xD
Acest sistem de ură nu va fi viral ???? Arch a mers grozav pentru mine ... dacă este adevărat că acoperă mai mult, nu știu dacă este bun sau rău! dar poate există deja vulnerabilități de preluat controlul sau vreun virus care distruge sistemul din cauza asta ... dacă este stabil și sigur nu văd problema ... oricum voi vedea dacă am timp și studiez subiectul și fac niște teste cu openrc
nu atât de stabil. și este mult mai nesigur decât sistemul v. Pentru un utilizator desktop ca mulți dintre noi (eu) nu reprezintă nici o problemă, o pornire mai rapidă funcționează bine și de obicei nu citesc jurnalele, deci nu contează cât de clare sunt sau dacă este în format binar.
Am o teorie Linux va crește pe desktop-uri (și guverne) și va pierde teren pe servere (în loc să ia OS ca freebsd)
Pe esdebian Wiki publică cum se instalează SysVinit pe Debian Jessie. http://www.esdebian.org/wiki/sysvinit
Citind despre securitate, aflu că pe partea intel, există plăci de bază cu chipset-uri, în general în Northbridge, implementează ceva numit AMR Intel Active Management Technology .... interesant, din fericire nu am intel, dar eu ' Voi începe să-l caut pe partea AMD, nu există așa ceva.
Ei își imaginează o combinație de intel + AMR + systemd, Doamne ferește.
https://en.wikipedia.org/wiki/Intel_AMT_versions
Nu e de mirare că paranoicul lui Stallman strigă după biografii gratuite.
Liniște; Intel renunță la fabricarea plăcilor de bază.
http://www.infoworld.com/article/2612845/computer-hardware/intel-refocuses-and-exits-motherboard-business.html
În primul rând, nu folosesc systemd pentru că încă nu este încorporat în Kubuntu (sunt cu Netrunner 14, derivat din Kubuntu 14.04).
După ce am clarificat acest lucru, trebuie specificate mai multe lucruri:
1- systemd este adoptat de dezvoltatori / împachetatori de mai multe distribuții diferite (Debian, openSUSE, Arch, Fedora ...), dar acum se dovedește că cititorii acestui blog știu mai mult decât știu despre avantajele și dezavantajele sistemului.
2- systemd este un software gratuit, al cărui cod poate fi citit (și înțeles), de către cei care au timp și cunoștințe (acei dezvoltatori / ambalatori despre care vorbeam înainte). Dacă ascunzi ușile din spate, acestea ar fi descoperite. Câți dintre cititori folosesc un firmware propriu sau un driver, al cărui cod nu l-ați citit și nu îl puteți citi? Cred că are mai mult sens să te temi de asta decât de systemd.
3- Cu toții lucrăm cu pachete binare, deoarece atunci când descarc un .deb din depozite pentru a-l instala, nu descarc un fișier text simplu. Deci, acest argument este destul de paradoxal.
4- În GNU / Linux există deja programe care fac multe lucruri: același nucleu, care integrează din ce în ce mai mulți drivere și chiar firmware proprietar (mai bine să pui o ușă din spate în firmware-ul închis decât într-un program al cărui cod este publicat). Există, de asemenea, Xorg, care se ocupă nu numai de serverul grafic, ci și de tastatură, mouse și alte lucruri; Nimeni nu spune că Xorg „trădează” filosofia UNIX pentru asta, vor să-l retragă pentru că a fost deja depășit de alte proiecte.
5- „Linux este alegerea”, desigur, dar este libertatea de a alege dacă vreau să citesc codul, să-l modific, să îl distribui etc. Nu că sunt necesare distribuții pentru a da toate opțiunile (toate arhitecturile procesorului, toate mediile desktop, toate formatele de pachete etc.)
6- Pentru cei care se gândesc să treacă la un BSD, îmi amintesc că am citit știri că în unele sisteme BSD NSA americană își pusese deja ghearele. Dacă această veste a fost corectă, nu știu pentru că nu am urmat subiectul. Dar este ironic că fug de ceva „pentru că este în spatele lui Red Hat și poate ...” să intru în ceva care „poate că NSA este în spatele lui ....”
Pe lângă utilizarea GNU / Linux, BSD, Windows sau orice vrei să folosim, putem folosi și logica și capacitatea noastră de a raționa
Cu alte cuvinte, cititorii acestui blog, fiind doar cititori, nu au capacitatea de a-și da seama dacă ceva este bun sau nu, pentru că trebuie să fim ghidați de judecata, cunoștințele și experiența bună ale ambalatorilor și dezvoltatorilor.
Este adevărat, este software gratuit și, dacă apare ceva ciudat, super-oamenii despre care ați vorbit înainte și în care trebuie să avem încredere vor putea să-l observe și să-l anunțe, sau poate nu, pentru că poate, fiind oameni, vor fi tentați a taci în schimbul a ceva.
Când descărcați un .deb, tot ce faceți este să descărcați un fișier comprimat, pe care îl puteți dezarhiva și, prin urmare, să vedeți ce este în interior și ce este posibil, care este locul în care se află binarul. 😉
Nu știu cine sunt utilizatorii care vor fugi de Linux pentru a merge la BSD, dar, de exemplu, nu ar trebui să părăsesc Linux, ar trebui să las doar o distribuție care pune Systemd în spatele tău da sau da.
Pe scurt, cei dintre noi care comentăm, citim și folosim GNU / Linux în acest blog nu motivăm. Asta vrei să spui? Oricum vă voi spune din experiența mea personală și din raționamentul meu (fie că este logic sau nu):
Systemd este un rahat blocat pe un băț. Am citit că există alte Inits care încep mult mai repede și, prin urmare, nu trebuie să controleze DNS, RED, CRON și orice altceva Systemd vrea să controleze. Poate pentru un utilizator final, căruia îi pasă doar să pornească computerul, să deschidă un browser și să trimită e-mailuri, nu contează dacă folosesc Systemd sau Systemx, dar pentru cei dintre noi care gestionăm servere este o durere în fund. Și vă pun aceeași întrebare pe care o întreb mereu ce se va întâmpla dacă Systemd este compromis și merge în iad? Ne-a rămas fără RED, fără CRON, fără DNS, fără Init și orice altceva face? Acolo o las pentru tine.
Și ai grijă, îți spun toate astea fără acrimonie Acestea fiind spuse, bine ați venit în aceste părți.
Multumesc pentru primire.
Răspunzând fără acrimenie, clarific că nici nu dezvolt sistem și nici nu sunt plătit să îl promovez. Și că nu mă afectează deloc dacă alte persoane îl folosesc sau nu, este decizia lor.
Dar ceea ce văd cu această chestiune pare, uneori, o isterie și citesc păreri ale unor oameni care, fără să fi studiat codul sau să-l fi folosit, îl etichetează ca gunoi, impunere, trădare și nu știu câte alte lucruri. Îmi amintește de o situație pe care am trăit-o acum câteva zile, când o persoană care a recunoscut că nu a instalat niciodată Windows sau a știut să partiționeze un hard disk a început să spună că Linux este foarte dificil ... fără să fi încercat vreodată și, de asemenea, să aibă Android pe smartphone-ul său.
Ați comparat systemd cu sysvinit, cu upstart și cu openrc? Super, poți lua o decizie pe baza propriei experiențe. Este cel mai bun, pentru că știi, de asemenea, că distribuția care funcționează pe un computer poate fi utilă pe un altul și de aceea cei dintre noi care au o experiență în GNU / Linux spun că cea mai bună distribuție este cea cu care utilizatorul se simte confortabil. gust.
1- «Cu alte cuvinte, cititorii acestui blog, deoarece sunt doar cititori, nu au capacitatea de a-și da seama dacă ceva este bun sau nu, pentru că trebuie să fim ghidați de judecata bună, cunoștințele și experiența ambalatorilor și dezvoltatorilor »
Citesc acest blog de ceva timp (veți vedea comentariile mele în știrile vechi), așa că sunt inclus în pachet. Și răspunsul este că nu: a fi cititor al acestui blog sau al oricărui blog nu mă permite (cel puțin eu) să judec binele sau răul unui software pe care nu îl cunosc. Pot să citesc ce spun alții și, în acest caz, există poziții atât pentru, cât și împotriva systemd; de fapt, de fiecare dată când subiectul este ridicat în Phoronix există multe dezbateri, dar chiar și acolo argumentele sunt rare. Mă refer la argumente precum „când systemd apelează procesul X apare o buclă infinită, făcând sistemul inutilizabil”.
Și adevărul este că, folosind o distro sau una diferită, sunteți ghidați de judecata, cunoștințele și experiența ambalatorilor și dezvoltatorilor. Utilizarea oricărui sistem de operare sau program implică parțial bazarea pe judecata și experiența altora; de exemplu, cu Linux acceptați decizia de a utiliza un nucleu monolitic în loc să utilizați un microkernel ca Hurd. Decizia a fost a lui Linus Torvalds și tu o accepți folosind nucleul lui.
2- «Este adevărat, este software gratuit și, dacă apare ceva ciudat, super-oamenii despre care ai vorbit înainte și în care trebuie să avem încredere vor putea să-l observe și să-l anunțe, sau poate nu, pentru că poate, fiind oameni se va simți tentat să tacă în schimbul a ceva ".
Ei bine, suspect, de ce să ai încredere în Linus Torvalds și Richard Stallman și în proiectul GNU? Nu m-am uitat la codul programelor lor, așa că poate mă înșală.
3 - «Și îți pun aceeași întrebare pe care o pun mereu, ce se va întâmpla dacă Systemd este compromis și merge în iad? Ne-a rămas fără RED, fără CRON, fără DNS, fără Init și orice altceva face? O voi lăsa acolo. »
Ce se întâmplă dacă OpenRC este compromis într-un fel? Sau Upstart? Sau nucleul? Mi s-a întâmplat, după o actualizare „normală” în Debian Testing, am rămas fără grub, nu puteam intra în Debian sau Windows și, în acel moment, ignoranța mea însemna că aveam doar opțiunea de a reinstala.
4- «Pe scurt, cei dintre noi care comentăm, citim și folosim GNU / Linux în acest blog nu motivăm. Asta vrei să spui? "
Nu, nu vreau să spun asta; Nu intenționez să generalizez de la o anumită situație concretă la totalitatea comportamentului unuia sau al unei mii de oameni. Dar cred că în cazul systemd se vorbește de multe ori fără a face o analiză obiectivă și senină; s-a întâmplat și cu Wayland-Mir, făcându-se multe afirmații nefondate, atât împotriva lui Wayland, cât și Canonical.
De asemenea, repet că am citit și comentat pe acest blog (ca în altele) și că folosesc GNU / Linux.
Și repet, de asemenea, ceea ce am spus înainte: să ne folosim creierul, să analizăm ceea ce auzim și citim, să luăm perspective diferite pentru a încerca să respingem atât A, cât și non-A și, dacă este posibil, să obținem propria noastră experiență pentru a ne baza concluziile pe fapte . Și apoi să folosim tot ceea ce ni se pare potrivit.
umm .. Ei bine, faptul că a fi compromis este o ipoteză este ca totul ... întrebarea mea a trecut deja? .. Poate că bug-urile nu se găsesc în toate software-urile și sunt corectate dacă există bug-uri în sistem, o corectează și, după cum poate avea orice program bug-urile sale .. problema nu este că poate eșua, este dacă doriți să facă sau să controlați ceea ce face, dar nu în ipoteza că poate eșua orice poate eșua într-un moment ... fan de systemd deloc, este doar părerea mea.
O eroare poate apărea pe computerul utilizatorului și nu se poate întâmpla nimic, dar pe un server lucrurile sunt foarte, foarte diferite.
@waco cu siguranță, dacă primiți erori într-un software, ar trebui să le corectați. Problema este că systemd are o mulțime de bug-uri vechi (unele datând din 2010 și grave) și încă nu sunt remediate astăzi, sau pur și simplu minimizate sau pur și simplu marcate de Lennart ca ÎNCHIS sau WONTFIX.
comentariul tau este foarte reusit! Nu putem cădea cu toții după systemd, deoarece este la modă și a fost creat ca o campanie de frământare în acest sens ... fiecare schimbare are o respingere.
Răspund la argumentele tale:
1.- Utilizatorii serioși și care solicită întrebări, precum și dezvoltatorii știu deopotrivă avantajele și dezavantajele adoptării systemd în orice mediu de dezvoltare și de lucru, punctele slabe și punctele forte ale systemd nu se modifică datorită faptului că au o perspectivă sau alta.
2.- Cu siguranță systemd este software gratuit și poate fi auditat. Problema nu este că are uși din spate ascunse, problema este că face lucruri pe care o inițiativă nu ar trebui să le facă (controlul rețelei, dns, console TTY etc.), că are o mulțime de servicii care se presupun altora, că face lucrurile într-un mod complet diferit de modul în care se așteaptă să fie făcute, ceea ce încalcă regulile kernel-ului Linux în sine (coredump), că mulți dintre dezvoltatorii săi nu prea au grijă să rezolve problemele structurale pe care systemd le are (coredump și debug sunt dintre cele mai serioase încă nerezolvate).
3.- Un lucru este să descărcați un binar care se dovedește a fi un program a cărui CONFIGURARE și JURNALE sunt încă în text simplu, iar un alt lucru este să descărcați un binar a cărui CONFIGURARE și alte informații sunt stocate în binar și sunt accesibile numai prin anumite instrumente, Aici se schimbă lucrurile. Un jurnal binar nu oferă securitate (dacă doriți cu adevărat securitate, criptați partiția cu AES-256), este doar o cutie neagră din care nu știți nimic despre ceea ce se întâmplă și se pretează la multe lucruri, de exemplu : Imaginați-vă că aveți un troian care exploatează o vulnerabilitate de sistem și, prin intermediul acestuia, obține acces complet la sistem, inclusiv serviciul jurnal și escaladarea privilegiilor. Nu este o problemă serioasă? Jurnalele binare gestionate direct de systemd nu s-ar întoarce împotriva dvs., fiind inaudabile fără a ajunge la punctul în care au fost deja modificate fără să știe? Există punctul și diferența dintre un program și un fișier de configurare / jurnale / dumpuri în binar.
4.- Nucleul este un software conceput în acest sens, este conceput de la început pentru a controla totul de pe computer, nu un init. O inițiere este dedicată numai pentru a face sistemul să ridice nucleul și să poată fi utilizat, deoarece este primul lucru care trebuie pornit și ultimul lucru care trebuie terminat. De aceea se numește init (inițializare), deoarece pornește sistemul și nu face nimic altceva, iar motivul este foarte simplu, init trebuie să fie cea mai stabilă și perfectă piesă de software posibilă, pentru a evita acest lucru dintr-un anumit motiv Aceasta ajunge să spargă întregul sistem, este vorba de stabilitate și securitate. Xorg, este o altă voce, face multe lucruri, este adevărat, dar nimic atât de riscant încât să te lase cu un sistem complet inutilizabil și, de asemenea, configurarea sa se face încă în fișiere text simple.
5.- Cu siguranță distrosul nu este obligat să ofere libertate în sens larg și tocmai din acest motiv este prezentată tirada actuală. Dar suntem utilizatori și comunitate și mulți dintre noi pur și simplu nu suntem de acord cu implementarea acestui sistem, de aceea ne facem să ajungem la voce, indiferent dacă îl ascultă sau nu, este o problemă a celor care dezvoltă distro, iar decizia lor va avea un impact asupra celor care decid să folosească sau nu distro-ul lor, iar acest lucru, în mod clar, poate duce la eșecul mai multor distribuții în funcție de modul în care merg lucrurile și un exemplu acum este Debian și furculita Devuan.
6.- Știrile BSD se datorează celor întâmplate în OpenSSH și în stiva IP OpenBSD, o ușă din spate care, de altfel, a afectat nu numai BSD, ci și Linux (în cazul OpenSSH) și care a fost remediată. Situația este atribuită BSD, deoarece BSD (Theo de Raadt din OpenBSD) este cel care se ocupă de dezvoltarea acestui instrument (OpenSSH) și situația a apărut deoarece anumiți dezvoltatori care nu mai sunt activi în proiect au plantat ușa din spate. Situația a fost rezolvată și măsurile pertinente care trebuie luate au fost declarate în cazul în care această situație ar putea afecta cei care au folosit software-ul. Acum: Această situație poate apărea în systemd? Răspunsul este simplu și rezultatul este catastrofal, deoarece systemd gestionează escaladarea privilegiilor printre multe alte lucruri, o ușă din spate în systemd înseamnă acces total la sistem, lucru care nu s-a întâmplat cu ușile din spate menționate în BSD.
Acestea returnează furca Debian fără ca systemd să aibă deja o pagină web. Se pare că proiectul merge și foarte serios. https://devuan.org/
ISO-uri actualizate și câteva încărcări noi.
https://forum.manjaro.org/index.php?board=50.0
Programul de instalare nu este foarte clar, nu pot urma pașii lor, mai ales în partea partițiilor, nu știu de ce insistă asupra acestor lucruri confuze.
Există ceva care îmi atrage atenția despre netinstall-ul cu Openrc, undeva în instalare văd în continuare mesajul că configurați systemd, vor fi cu adevărat liberi de systemd sau de utilizarea acestuia?
Bună ziua Manuel, observ și eu același lucru în timpul instalării, trebuie să fie o problemă a instalatorului, deoarece ceea ce nu există nicio îndoială este că systemd nu este instalat, confirmi în terminal astfel: pacman -Qs openrc
În ceea ce priveşte
Salut, Keos, în primul rând îmi cer scuze pentru că nu am mai răspuns. Apreciez răspunsul dvs., sunt fericit să știu că Manjaro oferă această opțiune; imediat ce suportul Ubuntu Precise se termină (sau poate mai repede) îl voi instala. Salutari.
Post bun
Voi aștepta în Manjaro cu Systemd în timp ce versiunea OpenRC se maturizează puțin mai mult, vreau să ies din systemd ... (Îl transpire)