Ogni giorno i nostri computer costituiscono una parte più importante della nostra vita, se ha qualche tipo di problema influenza il nostro umore, il nostro umorismo eheh. Certo, gli utenti Windows sono più inclini agli attacchi di panico rispetto a se i virus (lunga vita a linux!), cosa succede se si deframmenta l'HDD, cosa succede se si cerca e installa il file Clean Master per PC (sebbene qui in Linux dobbiamo ancora pulire il sistema, BleachBit è una delle alternative preferite). Recentemente gli utenti Linux hanno (alcuni) un certo mal di testa chiamato: systemd
Bene, al punto, ho letto un articolo interessante su systemd, che sembra essere la tendenza per non molto tempo.
SistemaD, che sembra ad alcuni come (e userò le parole di un amico), un anello per domarli tutti ... altri semplicemente non si adattano né si adattano, fintanto che il computer funziona bene, a loro non importa se init fa X o Y, o se viene usato systemd. A questo che scrive, beh ... diciamo che preferisco init, lo trovo più semplice 🙂
Lascio l'articolo qui:
Prima di iniziare devo dire che non mi piace la decisione di cambiare le cose in Debian ma, in nessun momento ho intenzione di abbandonare la mia amata spirale. Provo solo a farlo, se abbiamo intenzione di discutere un argomento, almeno lo rendiamo il più preparato possibile anche se io stesso non mi considero pro-sistema. Per ottenere la demistificazione di systemd mi affiderò a un sito web dove gli sviluppatori danno il loro punto di vista che è venuto nelle mie mani da un collega che sembra essere pro-systemd anche se non è un utente Debian. Detto questo, penso di poter passare al tentativo di demistificare ciò che viene detto su systemd.
systemd è basato su binari
Forse questo è uno degli aspetti che ci scioccano di più, se tutto si basa su binario, come monitoriamo le cose che di solito facciamo attraverso i log? Non ho idea di come sia nato questo mito, ma non è assolutamente vero.
systemd è configurato quasi esclusivamente tramite file di testo semplice. Alcune impostazioni che possono essere modificate anche con la riga di comando del kernel e tramite le variabili d'ambiente. Non c'è niente di binario nella tua configurazione (nemmeno XML). Solo un file di testo semplice, diretto e di facile lettura.
Quella cosa è monolitica e controlla tutto
Prima di raggiungere il suddetto sito, confesso che io stesso la pensavo in questo modo, ma dopo aver letto cosa dicono i suoi sviluppatori, la mia opinione è cambiata qualcosa ...
Se crei systemd con tutte le opzioni di configurazione abilitate, costruirai 69 binari individuali. Questi file binari svolgono compiti diversi e sono accuratamente separati per una serie di motivi. Ad esempio, systemd è stato progettato pensando alla sicurezza, quindi la maggior parte dei demoni viene eseguita con privilegi minimi (utilizzando le capacità del kernel, ad esempio) e sono responsabili solo di attività molto specifiche, per ridurre al minimo il loro impatto sulla sicurezza e sull'impatto. Inoltre, systemd parallel si avvia più di qualsiasi soluzione precedente. Questa "parallelizzazione" viene creata eseguendo vari processi in parallelo. Quindi si vede che systemd è molto ben suddiviso in molti binari e quindi processi. In effetti, molti di questi binari si separano così bene che sono molto utili al di fuori di systemd.
Un pacchetto che includeva 69 binari individuali difficilmente poteva essere chiamato monolitico. Ciò che è diverso dalle soluzioni precedenti, tuttavia, è che spediamo più componenti in un singolo tarball e li teniamo concatenati in un unico repository con un ciclo di rilascio unificato.
Non sembra Unix
C'è sicuramente del vero in questo. I file di origine systemd non contengono una singola riga di codice dalle righe UNIX originali. Tuttavia, l'ispirazione è derivata da UNIX, e quindi c'è molto UNIX in systemd. Un esempio potrebbe essere l'idea UNIX "tutto è un file" che si riflette nel fatto che in systemd tutti i servizi sono esposti in fase di esecuzione in un file system del kernel, il cgroupfs. Quindi una delle caratteristiche originali di UNIX era il supporto multi-postazione, basato sul supporto del terminale integrato. Con systemd abbiamo portato di nuovo il supporto multi-posto in modo nativo, ma questa volta con il pieno supporto per l'hardware di oggi, che copre grafica, mouse, audio, webcam e altro. In effetti il progetto di systemd come una suite di strumenti integrati che ognuno ha i propri scopi individuali ma quando usati insieme sono più della somma delle parti, che è più o meno al centro della filosofia UNIX. Quindi il modo in cui viene gestito il nostro progetto (cioè mantenere la maggior parte del kernel del sistema operativo in un singolo repository git) è molto più vicino al modello BSD (che è un vero UNIX, al contrario di Linux) per fare le cose (dove la maggior parte del core sistema operativo è conservato in un unico repository CVS / SVN) che non è mai stato il caso di Linux.
In definitiva, la questione se qualcosa sia UNIX o meno importa molto poco. Essendo tecnicamente eccellente, non è certo unico per UNIX. Per noi UNIX è un'influenza importante (anzi, la più grande), ma abbiamo anche altre influenze. Quindi, in alcune aree systemd sarà molto UNIX, e in altre un po 'meno.
Questo è molto complesso ...
C'è sicuramente del vero in questo. I computer moderni sono bestie complesse e ovviamente lo sarà anche il sistema operativo che gira su di essi, quindi devono essere complessi. Tuttavia, systemd non è certamente più complesso delle precedenti implementazioni degli stessi componenti. È più semplice e ha meno ridondanza. D'altra parte, la creazione di un semplice sistema operativo basato su systemd richiederà molti meno pacchetti rispetto agli usi Linux tradizionali. Un minor numero di pacchetti semplifica la creazione del sistema, elimina le interdipendenze e gran parte del diverso comportamento di tutti i componenti coinvolti.
Questo non mi permette di usare script di shell
Questo è totalmente falso. semplicemente Non li usiamo per il processo di avvio, perché pensiamo che non siano lo strumento migliore per quello scopo specifico, ma ciò non significa che systemd fosse incompatibile con loro. Puoi eseguire facilmente gli script della shell come servizi o demoni di systemd, puoi eseguire script scritti in formato qualsiasi language come servizi di systemd poiché systemd non si preoccupa minimamente di ciò che è all'interno del suo eseguibile. D'altra parte, usiamo in gran parte script di shell per i nostri scopi, per installare, costruire, testare systemd. E puoi incollare gli script nel processo di avvio anticipato, vengono utilizzati per i servizi normali, possono essere eseguiti all'ultima fermata, non ci sono praticamente limiti.
A questo punto suppongo che alcune delle convinzioni principali possano essere state chiarite, nonostante non mi senta un sostenitore del cambiamento e abbia i miei dubbi su "un demone per controllarli tutti"Penso che alla fine nessuno oserà dire che almeno non funziona, conosco anche alcuni utenti che notano che con systemd" il PC gira più veloce "ma sarebbero altre cose di cui si potrebbe discutere. Per il momento non mi resta che invitarti a discutere qui i punti di vista che hai sullo startup manager che molte distribuzioni hanno adottato, anche se ora le reazioni maggiori si stanno vedendo all'interno della comunità Debian, che è addirittura nata una nuova forcella con tutto questo. Che ti piaccia o no è una questione di tutti, da parte mia voglio solo fare la mia parte nel demistificare systemd che alla fine sarà presente in Jessie, la prossima versione stabile di Debian.
Ho visto l'articolo su GUTL (che a sua volta è stato preso da FromAbreus)
Systemd attuale?
Sono uno di quelli che non legge molte notizie quando qualcosa genera tante polemiche, preferisco restare sui dettagli più tecnici. È questo…. a volte sento che certi argomenti smettono di essere una discussione o un dibattito puramente tecnico, e diventano come uno di quei pettegolezzi di celebrità 🙁
Prima viene chiamata una riga aperta da un utente a systemd systemd VS intelligenza, poi Linus Torvalds che lo dice systemd non è così male come lo dipingonoe qualche ragione se l'ha fatto), un fork chiamato inutile ... Nessun commento ... e infine devuan.
Non dirò se è così brutto come si dice, meno cattivo o peggio. Il sistema per me funziona senza problemi, tuttavia per gusto personale preferirei init, perché il suo modo di organizzare varie cose (come i log per esempio) mi piace di più, ma hey, se systemd viene chiamato cavallo da corsa e deve sostituirlo dentro (Sarebbe il nostro mulo da soma, che fa tutto tranne che lento?) Beh ... amico, finché il cambiamento non è estremamente brusco, gli utenti possono adattarsi senza troppi problemi e il sistema funziona meglio (sì, meglio, non è abbastanza per me!), Benvenuti 😀
Ottimo articolo, sto usando Linux Mint 17.1 Rebecca da alcuni giorni con systemd e mi sento molto più fluido rispetto alle versioni precedenti, non ne so molto perché sono un utente comune che lo sta imparando ma Starò all'erta, questo è il primo articolo che leggo che non parla di parassiti di systemD.
Per qualcosa, sarà il primo che leggerai che non parla di parassiti su di lui e d'altra parte, dimmi, usi la tua menta come server?, Ed è per questo che non ti dà fastidio, non Non mi piace ma nemmeno Systemd ti frega. Quando hai bug e per questo hai seri problemi in ambienti seri, ti darà fastidio.
Amico, qualche distro basata su Debian Stable che consigli? Potrei usare Debian, ma devi configurare molte cose una volta installate, codec, ecc ... Quale mi consigliate? Grazie.
E come sei riuscito a inserire systemd in Linux Mint? Volevo provare a inserirlo ma non so se sia necessario fare qualcosa in più (a cui, in teoria, Ubuntu porta già), se hai qualche guida in merito o qualcosa puoi passarmi, io lo apprezzerei
Articolo molto buono. Vediamo se i talebani anti-SystemD lo leggono (ma ne dubito)
In ogni caso tra un anno li vedrò usare SystemD e negheranno quello che hanno detto un anno fa. Così sono. Resistente al cambiamento? Sicuramente si.
Mi consideri un talebano per non voler accettare Systemd, quindi ti considero un talebano per non voler accettare che non voglio accettare Systemd. Siamo a portata di mano 😉
Tuttavia, come si dice alla fine dei tuoi articoli:
«elav: Blog personale / Twitter / G+ / Utente ArchLinux. Informatico, amante della musica, blogger e web designer. Amministratore e Fondatore di DesdeLinux.netto. »
ovvero, usi una delle prime distribuzioni che SystemD ha adottato.
saluti
Ok, ragazzo.
Senza parole !!!!, continua a giocare, quella vita è rosea.
Per commenti come il tuo, caro Giskard, questo è il motivo per cui declino SystemD e ciò che rappresenta.
E se dopo 20 anni uso e lavoro con e per Linux, sono un talebano; Bene, così sia.
Tra un anno parliamo. Ed elav, non ti ho menzionato. Ti sei ucciso come Chacumbele.
Vediamo, le persone leggono e NON leggono. Non ci sono o non ci sono talebani contro SystemD? Ci sono! E dall'altra parte c'è chi la difende con le unghie e con i denti come se fosse una panacea. Cosa sono tutti loro? No! Affatto! Ci sono quelli che simpatizzano con l'uno o l'altro e vedono il bene e il male sia del proprio che degli altri. Con quelli puoi parlare senza problemi. Ma non negheranno che ci SONO i talebani. E da un lato all'altro. E se qualcuno è stato punto da ciò senza capire che potrebbe benissimo NON essere un talebano, allora resto il mio caso perché le prove lo rendono colpevole.
Se dialoghi con qualcuno su SystemD e fin dall'inizio quella persona non lo chiama per nome ma per Systemshit o qualcosa di simile, vorrei sinceramente che mi dicessero se è possibile avere una conversazione con una persona del genere che inizialmente squalifica il avversario. Non può.
Comunque, devi leggere. Vediamo, se vengo e dico "ci sono alcuni eschejfhduf (parola inventata) che picchiano i bambini quando lasciano la scuola" e alcuni vengono a difendere l '"eschejfhduf" non è per pensare che lo siano loro stessi?
Bene, se qualcuno là fuori (non talebani, per favore, e nemmeno eschejfhduf) vuole parlare dei pro e dei contro di init e SystemD (che hanno entrambi il bene e il male) sarò felice di essere in giro.
Saluti.
L'anti sistema talebano? e dimmi, cosa sei? i talebani pro-sistema?, D'altra parte, perché presumi che non leggeremo ma commenteremo direttamente?, chi è il talebano di mentalità chiusa che non ammette discussioni e parla come LP: «È il meglio, credimi, so cosa faccio ". ?
Ho letto l'intero articolo e posso dirti:
Systemd è basato su binari: True
La demistificazione: falso
LP sta travisando ciò che viene detto, ovvero che il core di systemd è binario, molti, troppi per essere appesi a PID1, fortemente interlacciati, tanto che ti invito a guardare #devuan quanto costa pulire, ad esempio, logind systemd e il resto dei pacchetti in Debian, dato quanto sia legato il logging che sostituisce PAM al sistema.
La configurazione è concisa e non consente TUTTO ciò che non vorrei, come disattivare il journal, dal momento che non puoi né uccidere il PID, né fermarlo o altro, che è modularità ?, stesso parvenu.
===========
"Quella cosa è monolitica e controlla tutto".
È, oltre al fatto che sono 2 o 69 binari, sono interlacciati tra loro con dbus e quindi con l'intero sistema operativo, non consentendo loro di essere facilmente scollegati, il caso più chiaro è journald, che non è possibile disattivarlo, inoltre , l'avvio di daemon o servizi avviene tramite "unità" che sono file di testo, ma niente di più, analizzato da systemd e voilà, nessuna modifica o hack nei servizi oltre a quanto stabilito.
=======
"Non sembra UNIX"
Risponderò brevemente. Non è conforme a LSB, né a POSIX e oggi uno sviluppatore fedora che aiuta in #devuan, ha detto: «È vero che non lo è, non importa, ciò che conta è che può eseguire cose che sono POSIX, il resto, di certo non mi interessa quale sistema operativo o altro, purché funzioni e abbia buone caratteristiche ». E perché dovrebbe essere UNIX o simile a UNIX: fai una cosa e fallo bene, qualcosa che systemd non fa.
===========
Tuttavia, systemd non è certamente più complesso delle precedenti implementazioni degli stessi componenti. È più semplice e ha meno ridondanza »
Meno ridondanza? Ti chiedono di installare UN ALTRO syslog per il testo normale e lo hanno chiesto per il log remoto prima che ci fosse systemd-journald-remote, cioè lo hanno messo in produzione senza poter fare un log remoto senza dipendere da rsyslog , qualcosa di semplice come l'accesso centralizzato. Anche così, non ha la capacità, un semplice booleano per indicare se vogliamo l'output in binario o in testo normale e anche, se stava per usare binario, perché non qualcosa noto come berkeley DB in modo che possa essere letto da qualsiasi sistema UNIX o Linux?
Semplice? Davvero? dai un'occhiata a quanto è semplice: http://wiki.gentoo.org/wiki/Comparison_of_init_systems
Guarda la quantità di righe di codice e file.
=========================
"Questo non mi permette di usare script di shell"
Questo è falso, ma ancora una volta è travisato, non viene criticato per non consentire l'uso di script bash, ma per non utilizzarli per avviare i servizi, motivo per cui non è modificabile, hackerabile e flessibile come upstart o sysvinit. E per hackable intendo harcoded.
============================
Pensi ancora che:
1.- Non ho nessuna ragione
2.- Non ho letto niente e sono talebano?
Mi chiedo ... devo davvero fidarmi di ciò che dice Lennart? Se qualcuno neutrale mi dice che posso prendere in considerazione certe cose, ma questo ha lo stesso sapore per me dato che Red Hat pubblica qualcosa per difendere Systemd
Wow, finché qualcuno qui intorno non dice qualcosa di ragionevole e non solo paura e disinformazione.
L'articolo è la traduzione spagnola di ciò che ha scritto Lennart.
Senza offesa, ma la traduzione sembra essere stata fatta dalla versione beta di Google Translator… 🙁 Ho avuto difficoltà a capire alcuni paragrafi; comunque l'informazione è gradita.
@ Charlie-Brown, è perché Lennart non sa esprimersi molto bene in inglese. Ecco quanto è brutto leggere l'originale.
I motivi addotti sono validi, tuttavia, penso che alcuni possano generare ulteriori domande. In ogni caso, il mio consiglio a chi ne ha la possibilità: vai alla fonte originale dell'informazione http://0pointer.net/blog/projects/the-biggest-myths.html (purtroppo per alcuni è in inglese) che è molto più completo e arriva a comprovare fino a 30 ragioni per le quali l'utilizzo di SistemD è considerato favorevole.
L'articolo di cui parli è stato scritto dal creatore di Systemd. Ovviamente nessuno meglio di lui per difendere il suo lavoro, però vi invito a guardare questo video http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html e mi diranno le loro conclusioni al riguardo. Non dico altro.
elav la questione dei log dei journal che sono in un binario è uno dei punti più criticati, anche lo stesso linus lo ha sollevato, quando in un report in cui ha ammesso che systemd non era così male. Anche lo stesso linus ha spiegato che è possibile creare uno script per prendere i dati del diario e metterli in chiaro.
Inoltre systemd consente di configurare la dimensione del binario del journal, riducendo il rischio di un possibile guasto.
In realtà, l'arte che citi è molto poco seria, poiché non ha un pizzico di oggettività, e mi fa persino chiedere se il difetto che mostra è reale o è falso (fanculo il software proprietario in modo che dia l'errore).
tutti i programmi a un certo punto hanno dei bug, ma sembra che cercheranno sempre la quinta gamba del gatto per trovare qualcosa di sbagliato in systemd.
Ad esempio: in debian è stato deciso che systemd sarà l'init predefinito, ma non impedisce di usare sysvinit o openrc o upstart e mi dirai bene di sì ma non puoi rimuovere completamente systemd, e la mia risposta sarebbe che è il lo stesso che è successo in Debian wheezy dove puoi eseguire openrc, systemd o upstart ma sotto sysvinit
PS: non voglio immaginare quanto diventeranno pazzi con kdbus e la sua integrazione con systemd a livello di kernel linux http://kroah.com/log/blog/2014/01/15/kdbus-details/
Se può essere. Inoltre, ho intenzione di ritirarmi ufficialmente dalle discussioni su Systemd. Qualunque cosa debba accadere 🙂
@rolo il fallimento è documentato, gli sono state presentate diverse segnalazioni di bug, gli presentano un video e ora dicono che è truccato. Se vuoi essere sicuro, segui i passaggi e guarda cosa succede. Ora ecco maggiori informazioni sulla questione, bug inventati? Non la penso così.
https://bugzilla.redhat.com/show_bug.cgi?id=958321
https://bugzilla.redhat.com/show_bug.cgi?id=1054929
https://bugzilla.redhat.com/show_bug.cgi?id=1055570
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=74280
https://bugs.archlinux.org/task/32191
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64116 (Lennart e le sue grandi spiegazioni)
https://bugzilla.redhat.com/show_bug.cgi?id=974132
https://bugzilla.redhat.com/show_bug.cgi?id=1157350
Ciò che il video menziona è sicuramente curioso. Come sviluppatore ci viene sempre detto che un dettaglio non dovrebbe influire sull'intero sistema / programma, ad esempio se una query di selezione sul database fallisce, perché l'intero programma dovrebbe andare in crash? È lo stesso con SystemD, se fallisce perché altri falliscono, non so quanto sia ben fatto. Ovviamente, ci sono casi in cui un guasto è praticamente un guasto del sistema, ma più sono isolate internamente le proprietà del programma, migliore sarà il prodotto.
Ora, attaccare il software dal suo lato debole non è una novità, è piuttosto una pratica molto comune e che in effetti dovrebbe essere fatto con ogni programma, quindi vedere SystemD cadere per il giornalista, è una prova valida che SystemD non è ciò che è detto o indotto a credere.
Più le cose diventano interdipendenti con SystemD, peggiori saranno le cose. Se prima di montare un dispositivo non si interrompeva il sistema, ora le cose potrebbero non sembrare così buone.
SystemD non è male, non lo odio, ma non è quello che molti vorrebbero far credere. Ha dei vantaggi, ma niente che Upstart non avesse o potesse avere, ovviamente, Canonical era coinvolta e nessuno voleva più prestare attenzione.
Saluti.
ma in quel video non so mai che il sistema va in crash. il tipo quello che fa è modificare il binario delle informazioni del journal per generare l'errore, ma il punto è che ogni volta che entra in systemd.
Da quello che ho capito, se limiti la dimensione del binario del journal, quando raggiunge il limite ne crea un altro e così via. diminuendo la possibilità di danneggiare tutti i dati.
Sia chiaro ... Chi penserebbe di modificare anche il file di log? xD
@Jorgicio 4 dicembre 2014 6:03
Sia chiaro ... Chi penserebbe di modificare anche il file di log? xD
Se l'hai detto in modo ironico ... va bene, ho capito :)), ma se davvero me lo chiedi, do il mio punto di vista.
Per me è chiaro che non è un bug, è una caratteristica !! L'idea è che se c'è un'escalation dei privilegi in un accesso remoto, sarebbe molto facile per coloro che accettano di eliminare il log semplicemente modificandolo per corromperlo e per systemd eliminarlo come corrotto e quindi evitare di essere rilevato in quello accesso remoto.
Dimmi paranoico, ma non ho altro modo di pensare ... non è un bug, è una caratteristica ed è per questo che non accettano di correggere quel bug.
uff ora tutti i blog di Linux fanno 200 articoli su systemd al punto che conosco già quasi tutti gli argomenti contro e per xD.
ea poco a poco sono stato convinto da alcuni degli argomenti anti sistemd e tra i quali ho visto (se c'è qualcosa che non va correggimi)
Ho anche visto un articolo su come mandare in crash l'intero sistema durante la modifica di un registro binario e che non fornisce alcuna informazione che il file sia danneggiato.
la mancanza di chiarezza nei registri
un team di sviluppo che spesso ignora le segnalazioni di bug
Essere così grandi e includere così tante cose all'interno di un init rende il sistema molto più instabile e se aggiungiamo bug come quello menzionato sopra, rende un sistema senza la stabilità che tanto caratterizza Linux.
si dice modulare ma parti di esso non possono funzionare senza altre parti dello stesso sistemad
uno sviluppo che a lungo andare genera dipendenze durante la programmazione, rendendo il software come gnome difficilmente portabile su sistemi senza systemd.
sostituisce le parti (networkd, logind, ecc.) che funzionavano e ricevevano manutenzione da anni e le cambia con quelle nuove senza alcuna necessità che tendono ad avere molti più bug.
Da quando utilizzo distribuzioni basate su Arch (Manjaro, Bridge Linux, Antergos) che ovviamente usano systemd, devo dire che non ho lamentele riguardo al suo utilizzo e gestione. L'avvio dei servizi è semplice, ancora di più in Bridge, dove bluetooth o modemmanager sono disabilitati per impostazione predefinita. A parte un bug relativo a hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) Non ho avuto molti problemi. Ovviamente non credo sia l'opinione di tutti, ma personalmente non ho lamentele 🙂
Non mi piace l'idea che un'azienda (Red Hat) accusata di collaborare con la NSA (backdoor e controllo USA) realizzi un sistema con cui tutto è controllato. Un anello per controllarli tutti, per legarli al buio se necessario ..
D'altra parte, devo ammettere che intel IRIS PRO 5200 funziona meglio per me e quasi mai, se non più, il mio sistema grafico si rompe quando avvio openSUSE 13.1. E sì, tutto è migliore, si avvia e si spegne molto più velocemente. Come mi ha beneficiato un semplice utente.
Sottolineo la parte importante
Se qualcuno ti accusa di vendere droga, sei automaticamente uno spacciatore?
@juanfgs
Trafficante di droga no .... complice sì.
Dio ... ti insulterei ma le tue stesse parole lo fanno per te.
Chiarisci solo che systemd è scritto, ed è così che dovrebbe essere fatto.
Ortografia
Sì, è scritto systemd, non system D o System D, o anche SystemD. E non è neanche il sistema d. Perché? Perché è un demone di sistema, e sotto Unix / Linux quelli sono in minuscolo e hanno il suffisso d minuscolo. E poiché systemd gestisce il sistema, si chiama systemd. È così semplice. Ma poi di nuovo, se tutto ciò ti sembra troppo semplice, chiamalo (ma non scriverlo mai!) Sistema Cinquecento poiché D è il numero romano per 500 (questo chiarisce anche la relazione con il Sistema V, giusto?). L'unica situazione in cui troviamo OK per usare una lettera maiuscola nel nome (ma non piace neanche) è se inizi una frase con systemd. Durante le festività si può anche scrivere sÿstëmd. Ma poi di nuovo, Système D non è un'ortografia accettabile e qualcosa di completamente diverso (anche se un po 'appropriato).
http://freedesktop.org/wiki/Software/systemd/
Anche qui? Lo metti in GUTL .. ma amico, tutti dicono Linux e non GNU / Linux, quindi con SystemD lo stesso.
Ti dico che non è necessario usare il log system o il cron che systemD fornisce, puoi seguire syslog-ng e cronie per questa o altre alternative
Uso systemD in ArchLinux da quando ero in aur e sembra più semplice da gestire rispetto al modo derivato debian e redhat, ha molti comandi della console che ti salvano dalla modifica dei file di testo e semplificano l'assemblaggio della configurazione dell'installazione degli script (ricorda che in arch tutto viene installato da console)
E non ultimo il sistema si avvia velocemente, in arch potresti avviare servizi in parallelo all'avvio del sistema ma è rischioso
Quello che penso sia negativo del problema è che la maggior parte si schiera, o sei pro-systemd o anti-systemd, e penso che abbia le sue cose buone e cattive, sono un utente e ho iniziato a giocare un po 'con systemd, davvero Le cose buone sono che l'avvio è più veloce e meno complesso del resto di init, anche se anche il numero del journal mi dà molto fastidio.
Capisco che quelli che possono davvero dire se è buono o cattivo sono gli amministratori di sistema o gli esperti in materia, ma mi sembra che il trambusto del sistema qualche tempo fa abbia smesso di essere qualcosa di tecnico ed è diventato qualcosa di più "spettacolo", per da parte mia sono un po 'contro ma non mi considero anti o pro
@KZKG_Gaara
Vedo che molto di quello che dici qui è lo stesso che Lennart ha pubblicato sul suo blog, più precisamente in questa voce: http://0pointer.de/blog/projects/the-biggest-myths.html.
Certo, il post ha avuto alcuni "chiarimenti" e ha lasciato da parte alcuni contenuti tecnici, in modo da rendere le informazioni di facile digeribilità per chi lo leggerà, ma saremo seri e sinceri, anche se la verità fa male: systemd ha molte cose che Lennart nega di non avere, questo e molto di più in realtà. E in questo senso spiego per parte.
1.- Lennart dice che non è gonfio e che non ha una sindrome da NIH alta (sindrome non inventata qui). Se è così per favore qualcuno mi spieghi: Perché un init dovrebbe avere il controllo di rete (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), logs (journald), coredumps (systemd -coredump), debug (systemd-coredump e journald), acpi (logind), privilege escalation (logind), controllo di ntp (systemd-timesyncd), controllo su dev (systemd ha preso tutte le funzionalità di udev), controllo di / dev / random (numero casuale generatore) e l'ultimo controllo su TTY (systemd-consoled)? Non c'erano molti strumenti creati per tali scopi che systemd ora ne aggiunge alcuni con accesso esclusivo (caso journald)? Quale spiegazione logica e accettabile mi dai perché un init sia in grado di rompere il debug del kernel e cmdline? Aggiungete a quel controllo su kdbus, il prossimo IPC che sarà integrato nel kernel. Sicuramente qui mi diranno: «Ma puoi installare un altro strumento per controllare tutto questo». E se è vero, ma molti di questi strumenti ricevono solo un flusso di dati lanciato da systemd, come nel caso di syslog e rsyslog, che si connettono a un flusso di dati fornito da journald in modo che altri strumenti possano VEDERE cosa guida il journald , alla fine, significa solo che hai due strumenti che fanno la stessa cosa, e uno di loro è la scatola di Pandora. (Per favore, non dirmi che il codice può essere verificato, perché invito qualcuno a "fumare" il codice journald e il suo framework con systemd e altri strumenti correlati)
2.- Lennart ci dice anche che systemd offre supporto per gli script SysV e LSB. Questa è una "metà vera", una "bugia bianca" per così dire, perché la verità è che systemd-214 non offre supporto per gli script bash, SysV o LSB e ciò è correlato nelle sue note di rilascio per quella versione.
3.- Quale systemd non è portatile? È un altro punto controverso. In BSD non funziona bene, in BSD non ci sono Cgroup tra gli altri strumenti che systemd deve eseguire. Ma è per un motivo di progettazione di sistema, non perché non sia portatile. Fino a quando il kernel BSD non soddisfa il minimo per supportarlo, systemd non funzionerà su quella piattaforma e non è colpa di nessuno, solo che BSD non ha alcun interesse, né Lennart. È così semplice. Ora, il supporto per altre librerie C è un'altra cosa, ben noti sono i problemi di glibc (basta creare un kernel a mano per vedere la quantità di opzioni e soluzioni alternative che sono state fatte per evitare questi dettagli, specialmente per glibc 2.3, 2.5 e 2.11, tra gli altri difetti che glibc ha trascinato negli anni) ma non finisce qui non finisce, lo stesso Lennart ha detto di aver preferito creare una propria libreria libc, perché per il suo gruppo è molto più veloce. leggendo il codice già creato (e documentato tra l'altro), ma non si ferma qui, hanno in programma di rimuovere glibc e usano la loro libc non solo per systemd, ma anche per Fedora, rendendola standard per la costruzione di tutti i loro pacchetti. NIH Dove? Sembra che al buon vecchio Lennart piaccia troll e big.
4.- Quel systemd non è monolitico perché è diviso in 69 binari. Sì, beh, questo è discutibile. systemd ha 69 binari, che svolgono attività diverse, ma quei binari passano le informazioni sulle attività a systemd, quindi se uno fallisce, le possibilità di rompere il sistema aumentano notevolmente. Questo è ben documentato, le segnalazioni di bug abbondano di problemi come questi e anche di problemi più semplici, in realtà stupidamente semplici. systemd può essere suddiviso in centinaia di binari, ma finché il tuo kernel ha il controllo, il rischio di un'interruzione continua e aumenta, e se non mi credi, leggi le segnalazioni di bug e divertiti.
Si noti che qui non ho commentato nulla che systemd sia spazzatura, ho fatto solo commenti meramente "tecnici" (ovviamente parlare di cose tecniche diventa molto complesso) e validi, supportati da informazioni facilmente accessibili su internet. Ora: quale Linux necessita di un init standard? Sì, sarebbe sicuramente qualcosa di grande valore per la comunità. Quale systemd è la soluzione? No, sebbene sia vicino, ha sicuramente molte cose positive, ma la sua diffusione virale e il numero di cose che fa aumentano il rischio di ciò che può andare storto e finire per danneggiare la comunità.
PS: Lascio materiale dove puoi corroborare ciò che dico, leggerlo sarà abbastanza illustrativo, e vedere che non includo blog o cose del genere, pura critica personale e basata. Saluti.
http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html
http://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc
http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html
https://bugzilla.redhat.com/show_bug.cgi?id=1057883 (@elav forse ti senti identificato)
https://code.google.com/p/d-bus/source/browse/kdbus.txt
https://github.com/gregkh/kdbus
http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html
Amen fratello .. amen ..
Non vedo ancora validi motivi per non adottare systemd. Interpreti semplicemente ciò che vedi con paura, risultando in esagerazioni. Né vantaggi né svantaggi chiari e ben definiti.
Inoltre, quell'integrazione consente la standardizzazione di cui hai persino parlato. Non solo Red Hat funziona su systemd, ma diverse società e volontari di altre distribuzioni.
Penso che l'errore sia che il funzionamento di systemd non è stato studiato adeguatamente.
Vedo valide ragioni nell'analisi di Yukiteru. Notate che invece di paura vedo rigore, precisione e chiarezza. Deve essere un problema di oculista.
Non è paura (non ho paura di un pezzo di codice) e non sono nemmeno esagerazioni (tutto ciò che ho detto qui è documentato e ho passato abbastanza informazioni che lo confermano, informazioni che tra l'altro vengono fuori dagli elenchi e da la mente / la voce / la grafia di Lennart, e non dai commenti di un blogger), è LA REALTÀ.
systemd fa tutto questo e molto di più, e questo è qualcosa di PREOCCUPANTE (un concetto diverso dall'avere paura) perché certamente richiede attribuzioni e fa cose che al momento possono essere fatte con altri mezzi e che tra l'altro funzionano meglio e sono più stabili . systemd è molto simile a Windows e non può essere nascosto, basta sapere cosa fanno userinit.exe, svchost.exe, smss.exe e altre dipendenze e confrontarli con systemd, la somiglianza è così grande che è una cattiva idea. Ora, certamente systemd potrebbe avere una qualità migliore rispetto alla sua controparte Windows (o può accadere il contrario, nessuno lo sa davvero, a meno che non programmi per Microsoft) ma non puoi accusarmi di ESAGERATO e PAURA quando leggi lo stesso Lennart In una lista, parlando di creare una libreria C completamente nuova, perché è stufo di Glibc, e per napa, aggiungere il piccolo e insignificante suggerimento, che quella libc può essere usata per costruire tutti i pacchetti Fedora. E se pensi che sia una bugia e che io sia esagerato, ti lascio il messaggio a questo link: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (in inglese)
Ora dimmi se è esagerato dire davanti a tutte queste cose, che una volta che Linus decide che CONFIG_VT così com'è, deve uscire dal kernel (situazione che esiste da molto tempo) e passarlo allo userspace, non succedere una cosa folle come se systemd-consoled fosse una forte dipendenza per quasi tutte le installazioni Linux (qualcosa deve gestire i VT, non credi?), Ciò non metterebbe sotto i riflettori diverse distribuzioni non systemd per forzare un interruttore. Se pensi che sia una forzatura, lascia che ti dica che non hai idea di cosa sia capace e stia facendo Lennart, poiché le sue ultime modifiche influenzano lo sviluppo del fork udev, Gentoo eudev, e continuerà a farlo con le sue minacce da sotto il tavolo (per poi lamentarsi come ha fatto su Google+)
@xiep non posso essere più d'accordo con il tuo commento.
Che Yukiteru, la tua lunga dichiarazione omette il fatto che l'email che hai collegato su libc è una barzelletta di pesce d'aprile, guarda la nota a piè di pagina e guarda la data (31 marzo, probabilmente 1 aprile nel fuso orario di Lennart)
Pratica il tuo inglese-fu perché è acquoso e mette in discussione tutta la tua "ricerca".
@juanfgs sembri l'unico che legge, almeno lo applaudo, ma devi leggere qualcosa di molto importante che è nel mio commento, non importa, lo metto qui:
»NIH Dove? Sembra che al buon vecchio Lennart piaccia troll e big. "
Non credo che l'abbia scritto per una ragione innocente, era consapevole del fatto che era un'altra battuta di Lennart per il pesce d'aprile (cattivo umore), così come la sua passione per trasformare /, / etc e tutto il resto in / Linux. 🙂
PS: Grazie ma non ho bisogno di praticare il mio inglese, uso la lingua da quando avevo 6 anni
aaahh e tutto il resto è vero, verificalo 🙂
Questo è un vero e proprio sensazionalismo, dici di essere basato sui fatti ma in realtà segui la tua intuizione che il ragazzo è cattivo e vuole conquistare il mondo e distorci i fatti per riflettere il tuo discorso. Questo è ciò che mi infastidisce molto delle persone anti-sistema, non usano mezzi termini quando si tratta di distorcere i fatti e dire mezze verità, cariche ovviamente della loro opinione.
La mia "regola pratica" in questi casi è semplicemente la seguente scomposizione logica, partendo dal presupposto che
- Sono uno sviluppatore web / app desktop o cli
- Non ho mai scritto un sistema di inizializzazione.
- Non sono un manutentore di una distribuzione.
verificare se l'interlocutore ha:
- ha creato un sistema di inizializzazione
- è un attivo manutentore del sistema init di una distribuzione
e la realtà è che la maggior parte degli anti-systemd fallisce questo test, tuttavia sono una manciata di persone che per qualche motivo SAPERE PIÙ delle persone dietro: Debian, Fedora, Archlinux, il kernel Linux, l'intero progetto GNOME, probabilmente il Anche il progetto KDE poiché non si sono lamentati di systemd, SUSE e molto altro.
Anche così, il suo linguaggio velenoso e al vetriolo l'unica cosa che riesce a ottenere è generare disunione, problemi e altro. Questo è il punto che non vedo l'ora che passino finalmente a BSD poiché sono stati minacciosi da Xorg, NetworkManager, PulseAudio e non so se a causa della pura ignoranza tecnica o perché non se ne lamenterebbero.
@juanfgs, ti prendo in parola specificamente su questo:
«E la realtà è che la maggior parte degli anti-systemd non supera questo test, anche se ci sono un pugno di persone che per qualche motivo SAPERE DI PIÙ delle persone dietro: Debian, Fedora, Archlinux, il kernel Linux, l'intero GNOME progetto, probabilmente anche il progetto KDE poiché non si sono lamentati di systemd, SUSE e un lungo ecc.
Anche così, il suo discorso velenoso e al vetriolo l'unica cosa che riesce a ottenere è generare disunione, problemi e altro. Questo è il punto che non vedo l'ora che passino finalmente a BSD poiché sono stati minacciosi da Xorg, NetworkManager, PulseAudio e non so se per pura ignoranza tecnica o perché non se ne lamenterebbero. "
Quindi, SECONDO voi, tutti noi anti-sistema siamo velenosi e al vetriolo che l'unica cosa che otteniamo è la disunità, i problemi e così via. Lascia che ti dica che questo è il più grande oltraggio che ho potuto leggere qui intorno. Non so perché i pro-sistema si preoccupano quando vengono portati alla luce i problemi strutturali di un sistema, che ovviamente li influenzeranno a un certo punto, perché ora può non essere successo loro nulla, ma a un certo punto lo faranno. andrà bene, e poi qualche anti-sistema ricorderà loro le parole che hanno detto molte volte e nessuno li ha fermati, e forse qualche altro anti-sistema darebbe loro una mano.
Personalmente non mi piace systemd, ma questo non significa che non uso init, devo farlo, perché proprio nel mio lavoro se devo toccare una macchina con quell'init, devo sapere come gestire Esso. Inoltre, personalmente, l'ho usato anche da quando sono arrivato ad Archlinux e anche in Debian e Gentoo, quindi non dirmi che la mia visione è distorta dal non usare systemd, l'ho usato e so quanto sia noioso. , e se devo aiutare qualcuno qui nel forum DesdeLinux o su IRC o sulla lista Debian (che è la distribuzione dove sono da più tempo e la uso ancora nel mio lavoro) lo farò volentieri, perché proprio se c'è qualcosa che mi piace della comunità Linux, è che nonostante la differenza è sempre un aiuto.
Adesso passare a BSD è possibile, ma lo farò solo se systemd diventa così virulento da non permettermi di utilizzare nessun'altra opzione, nel frattempo rimango su Linux, disabilitando tutta quella follia, inclusi molti dei Cgroups cose.
!=
Ancora una volta giri le parole per adattarle al tuo discorso. Sei un ottimo materiale per un politico / giornalista.
Chiarisco, il mio problema non è che menzionano problemi tecnici di Systemd, il punto è che molte volte caricano il loro discorso di bugie, ovvero:
Che se systemd ti costringerà a utilizzare un server microhttpd (che è un modulo opzionale NON installato di default), che se systemd è un singolo binario, quel systemd verrà chiuso perché lennart è pagato da microsoft, quel registro binario Sono obbligatori. Nessuno vuole systemd e la sua adozione è da parte di una lobby politica.
Questo è ciò che sciocca, le bugie. Se fosse una discussione ragionevole ne varrebbe la pena, ma è solo il buon FUD.
Il fatto che non ti piaccia mi sembra perfetto, non mi piace molto software, anche linguaggi di programmazione, distribuzioni e altri, ma non invento cose a riguardo né sono ossequioso leggendo ciò che voglio leggere e caricare le mie dichiarazioni con sentimenti personali per danneggiare l'immagine delle persone che la sviluppano.
@juanfgs mi dispiace, ma non sono io a definire un certo gruppo di persone "velenoso e al vetriolo" semplicemente perché non gli piace un software.
Di nuovo, torcere le frasi per essere una vittima.
@juanfgs di nuovo ti dico, quello è stato detto da te, controlla le tue parole, non sto travisando le tue parole, ho solo fatto un copia / incolla delle tue parole nel commento 59.
Sto citando il mio commento testuale capo, quello che devi rileggere sei tu perché non vuoi capire, o non sai discutere. Prendi le cose fuori contesto e le interpreti come ti vengono cantate. Quindi, se vuoi scegliere di vivere in un mondo in cui ti senti insultato perché i tuoi argomenti sono controversi, Lennart, Red Hat e Microsoft ti stanno perseguitando, è perché scegli di crederci.
Breve qui perché mi rendo conto che non sei una persona ragionevole perché non vuoi capire, vuoi interpretare le cose come ritieni opportuno.
Se vuoi essere offeso, offenditi, ma è un tuo problema, non il resto del mondo.
@juanfgs Non sono infastidito dai tuoi commenti, non vedo davvero alcun motivo, stiamo litigando, le persone civili litigano senza doversi preoccupare (questo è quello che penso).
Ora, se ti piace etichettare, pregiudicare (o come vuoi chiamarlo) le persone per i loro discorsi o azioni (forse dovresti leggere il mio commento # 64 e misurarne l'ampiezza), questo è il tuo problema, limitati a quelle azioni verso te stesso e lascia gli altri fuori da quella borsa.
Saluti.
"La maggior parte dell'anti-systemd", "quasi tutti", "tutti", "una parte dell'anti-systemd" ... deviamo, Mariano, deviamo. Nel caso di specie: non vedo da nessuna parte che Yukiteru abbia fatto un discorso sensazionale basato su intuizioni (riferirsi alla sua analisi in questo modo ha qualcosa di contorto), al contrario, ha sviluppato solide argomentazioni sugli svantaggi systemd basate su appropriate domande e materiale tratto da mailing list e tracce di bug (così come in modo educato e civile). Forse per questo gli irrita un po 'e lo attaccano al primo commento, per screditarlo e squalificarlo (questa volta in modo velenoso).
Se vedi che il discorso della maggior parte degli anti-sistema è velenoso e al vetriolo, quello che vedo nel discorso di alcuni pro-sistema (non so se sono una maggioranza o una minoranza) è l'isteria e la persecuzione di coloro che, precisamente, fanno argomenti solidi in mezzo a tutto il rumore. Quello che nella mia terra chiamiamo dissenso molesto.
Systemd sta andando bene per te? Ottimo, mi sembra fantastico, ma lascia che chi non la pensa lo stesso esprima le proprie riserve (il sistema operativo potrebbe non funzionare allo stesso modo).
saluti
A proposito, perché un bug di systemd è esploso al punto da sprecare l'intero componente, ma altri come GCC, glibc o persino il kernel non sono stati criticati fino a quel punto per molti dei loro bug?
L'hai detto tu stesso, glibc ha trascinato i problemi per molto tempo. Nel tempo Llvm ha dimostrato di avere vantaggi rispetto a GCC. E qui non vedo la stessa critica.
Perché non fare lo stesso con altri progetti?
È semplicemente paura collettiva e irrazionale per me.
Glibc ha i suoi bug che nessuno può nasconderli, ci sono enormi bug di Glibc che colpiscono il kernel e centinaia di eseguibili. La differenza tra Glibc e systemd è che il primo è una base da cui MIGLIAIA di progetti software possono essere trasformati in binari, mentre systemd è un init, il cui scopo è quello di essere un pezzo stabile, collaudato e praticamente infallibile. Non solo, Glibc deve adattarsi a centinaia di diverse architetture hardware (CPU), a diversi flag di ottimizzazione e caratteristiche uniche della CPU, a diverse forme di ottimizzazione del software, un lavoro molto più arduo e difficile di quello di systemd. Non vedo davvero alcun modo per presentare un confronto tra i due progetti sulla stessa scala.
Lo stesso vale per GCC, GCC è un compilatore che tra l'altro supporta molti linguaggi (13 in totale contando quelli non ufficiali), e ha caratteristiche molto simili a Glibc, supporta molte architetture (70 architetture per la versione 4.9), ottimizzazione binaria flag, flag di ottimizzazione della CPU e molte altre funzionalità. Ora sono allo stesso livello di difficoltà, un compilatore con un init. La risposta è più che ovvia, a partire da quel systemd è in C, e gran parte del codice GCC è in assembler o devi usare assembler per far funzionare le cose in binario, qualcosa di un po '"difficile da fare".
Quali sono i difetti di GCC e Glibc? Chiaro. Anche Linus ha dato loro il suo attacco, ma in GCC e Glibc hanno qualcosa di positivo che in systemd vengono dimenticati molte volte, e cioè un bug segnalato, un bug visto, un bug corretto.
- per favore qualcuno mi spieghi: Perché un init dovrebbe avere il controllo di:
reti (systemd-networkd),
DNS (systemd-rete),
m-dns (systemd-networkd), l
ogs (giornale),
coredump (systemd-coredump),
debug (systemd-coredump e journald),
acpi (logind), escalation dei privilegi (logind),
ntp(systemd-timesyncd),
dev (systemd ha preso tutte le funzionalità da udev),
de / dev / random (generatore di numeri casuali)
TTY (console di sistema)?
Un tema 100000 ripetuto e ripetuto, quello che devi dire è che systemd può funzionare senza di loro, infatti in debian non sono nemmeno la metà di quelli che menzioni
allo stesso modo è solo una caratteristica del suo approccio ampio
lennart: Beh, systemd divide ciò che deve fare in molti componenti diversi (90+ binari in questi giorni). Ognuno funziona con il minor numero di privilegi possibili.
Immagino che questa non sia troppa differenza con coreutils, che ha anche un gran numero di componenti in un unico pacchetto. E coreutils è probabilmente uno dei principali progetti che fa sentire Linux come un sistema operativo simile a UNIX, giusto?
Ma sì, systemd è più complesso di sysvinit, senza dubbio. Negli ultimi 40 anni di informatica sono cambiate molte cose e molte di esse richiedono effettivamente un certo livello di complessità per essere gestite… C'è ben poco da fare per aggirare questo problema.
Perché non si diventa così intransigenti con freebsd, che fa esattamente la stessa cosa ma con i suoi strumenti e senza consentire l'utilizzo di altri, il che non è il caso di systemd.
- Non c'erano già MOLTI strumenti creati per tali scopi che systemd ora aggiunge i propri, alcuni con accesso esclusivo (case journald)?
Non nego che il tema del giornale salva le informazioni in un binario è la cosa più debole da difendere, ma non è la fine del mondo, possono essere salvate in testo normale
- Quale spiegazione logica e accettabile mi dai che un init è in grado di rompere il debug del kernel e cmdline?
Mmmmmmmmmmm …………………. rompere il kernel ……. 5000000 cose possono rompere il kernel
- Aggiungi a quel controllo su kdbus, il prossimo IPC che sarà integrato nel kernel.
Secondo lennart Questo ha una relazione positiva per gli sviluppatori e systemd porterà strumenti per aprire dbus agli amministratori, fornirà anche interfacce bus journal e networkd
- Sicuramente mi diranno qui: "Ma puoi installare un altro strumento per controllare tutto ciò." E se è vero, ma, molti di questi strumenti ricevono solo un flusso di dati lanciato da systemd, come nel caso di syslog e rsyslog, ... .. significa solo che hai due strumenti che fanno lo stesso, e uno di loro è un vaso di Pandora. (Per favore, non dirmi che il codice può essere verificato, perché invito qualcuno a "fumare" il codice journald e il suo framework con systemd e altri strumenti correlati)
qui entriamo nella teoria del complotto !!!!! è un software scarno, niente è nascosto
3.- Quale systemd non è portatile? È un altro punto controverso. In BSD non funziona bene, in BSD non ci sono Cgroup tra gli altri strumenti che systemd deve eseguire. Ma è per un motivo di progettazione di sistema, non perché non sia portatile. Fino a quando il kernel BSD non soddisfa il minimo per supportarlo, systemd non funzionerà su quella piattaforma e non è colpa di nessuno, solo che BSD non ha alcun interesse, né Lennart.
Beh, non è del tutto corretto, gli sviluppatori bsd fanno qualcosa di simile a systemd che lo stesso Lennart ha evidenziato nel suo account g +
https://plus.google.com/115547683951727699051/posts/g78piqXsbKG
https://www.youtube.com/watch?v=Mri66Uz6-8Y
4.- Quel systemd non è monolitico perché è diviso in 69 binari. Sì, beh, questo è discutibile. systemd ha 69 binari, che svolgono attività diverse, ma quei binari passano le informazioni sulle attività a systemd, quindi se uno fallisce, le possibilità di rompere il sistema aumentano notevolmente. Questo è ben documentato, le segnalazioni di bug abbondano di problemi come questi e anche di problemi più semplici, in realtà stupidamente semplici. systemd può essere suddiviso in centinaia di binari, ma finché il tuo kernel ha il controllo, il rischio di un'interruzione continua e aumenta, e se non mi credi, leggi le segnalazioni di bug e divertiti.
Se stai usando sysvinit e il tuo TTY dev acpi ntp rompe anche il tuo sistema, non essere terrificante.
Monolithic è freebsd e tu non dici niente
@rolo
Ora elencami quali sono le distribuzioni che hanno preso systemd e hanno creato quei 90 binari in pacchetti separati, sarebbero 91 pacchetti con systemd.
E quando installo systemd non mi chiede nessuno di quei 90 pacchetti come dipendenze.
Seriamente, e di nuovo insisto ... per favore passatemi le opzioni di –configure-help che voglio fare 91 pacchetti compilabili a mano con make.
Non c'è cieco peggiore di quello che non vuole vedere ... ragazzi questa è acqua e olio, sembra che ci siano ancora persone testarde che non vedono la realtà di quello che sta cercando.
@rolo Voglio che installi systemd e rimuova journald, systemd-udev e coredump, e usi direttamente opzioni come eudev e syslog, per vedere se puoi.
Questo commento non potrebbe farmi ridere più seriamente, sto morendo. 😀
Seriamente, si prendono davvero la briga di leggere un po ', invece di restare con il raggio negli occhi.
Inoltre, nessuno dimentica che Kay Sievers non solo ha infranto la cmdline del kernel, ma ha voluto chiuderla, dopotutto "generico è generico".
In altre parole, secondo te, il fatto che due processi passino informazioni li rende così accoppiati che il fatto che uno fallisca fa sì che l'altro abbia un'alta probabilità di fallimento ... da quale teoria di sviluppo software l'hai preso? Concordo con @pamp che parli per paura irrazionale e di parte.
E l'altra tua grande domanda, perché Systemd deve controllare così tante cose? Risposta semplice: perché con sysvinit e tutti gli altri vantaggi di init recentemente introdotti nel kernel Linux vengono sprecati, finché nessuno li mette in uso nello spazio utente, sono "incazzati" (come si dice a Cuba ... beh , sprecando) senza che nessuno li usi e danno grandi vantaggi nell'uso efficiente delle risorse hardware (CPU, RAM, I / O, ecc.) compresi i cgroup. Ciò che fa systemd è, precisamente, mettere queste buone funzionalità del kernel Linux al servizio dell'utente, ma per questo deve essere lui a dare inizio a quei demoni.
Penso che tu abbia letto e analizzato in modo sbagliato (l'analisi è importante) o semplicemente non ti sei nemmeno dato la possibilità di farlo. Il fatto che due processi passino informazioni non è un motivo per cui un sistema si interrompe, tuttavia, quando si hanno binari con azioni dinamiche come controllo di rete, log o coredump, passando le informazioni direttamente a init, le cose possono andare storte e andranno male, perché se alcuni dei binari si rompono, le possibilità di rompere il resto sono molto più alte, e questo è abbastanza realistico, ed è successo, il kernel cmdline si è arrestato di recente, i problemi acpi che gli sviluppatori di Nvidia hanno avuto grazie a systemd-212, tutto ciò è un esempio di quello che dico.
@Dariem
Se non puoi compilare ciascuno di questi binari in singoli pacchetti, lo stai forzando perché ne vuoi uno installato, devi installarli tutti, quando li installi tutti risulta che passi su altri pacchetti che non possono essere installati perché il parti di systemd stanno occupando quei posti.
Che senso ha dividere un eseguibile di grandi dimensioni in più eseguibili più piccoli se alla fine non hai un pacchetto per ognuno che ti permetta di installarli singolarmente.
Torno a fare la richiesta generale a tutti gli utenti avanzati di systemd, per dirmi come compilare quei 90 moduli e creare 90 pacchetti che se ho voglia di installarli e altrimenti uso i programmi che ho usato.
Pessimo latte tutto questo ... sembra che la gente di systemd pensi che tutti gli utenti di gnu / linux siano degli stupidi.
Per la cronaca, utilizzo i test di gentoo e alcuni mesi fa ero passato a systemd e non potevo con journald, il che mi ha fatto tornare a openrc più velocemente di quanto ci volesse per passare a systemd.
Per continuare a vedere come stanno andando le cose con systemd ho archlinux su un notebook che sarà presto rilasciato su gentoo… Sicuramente stabile.
@anonimo, voglio solo vedere come si evolverà il problema TTY in Linux. Quando esce il codice CONFIG_VT, a favore di dividere VT in due parti ben differenziate (kernelspace e userspace) avremo bisogno di qualche strumento per controllare il VT dallo userspace e lì systemd-consoled può giocare come una forte dipendenza che tira il resto di le distribuzioni alla necessità di installare i componenti systemd, solo per rendere possibile il funzionamento del sistema. Quello che sto dicendo non è un'esagerazione, è una possibilità molto, molto grande e davvero preoccupante. Ci sono altri progetti, come KMSCon, ma se la maggior parte dei desktop e delle distribuzioni va a favore di systemd, cose come KMSCon possono morire più velocemente di quanto molti pensano.
@Yukiteru 3 dicembre 2014 8:49
Non ho paura di questo, il signor Linus non rimuoverà le opzioni di default da una versione all'altra, metterà il nuovo sistema come NUOVO e ti permetterà di scegliere tra il solito e il nuovo.
Per quanto riguarda la parte userspace, puoi creare un pacchetto che lo faccia in modo indipendente, se systemd lo fa, perché non potrebbero altri 50 in più? Inoltre, i diversi modi di farlo faranno sì che i diversi terminali adottino modi diversi tutti con USE per l'attivazione e disattivarli come siamo abituati.
Lo stesso vale per kdbus, che Linus lo ammette nella 3.19 come sta dicendo, non significa che bisognerà averlo attivo sì o sì.
Sono molto contento di openbox + compton, i desktop per me possono scomparire e non mi influenzeranno minimamente.
@ anonymous la domanda è che rimuovere CONFIG_VT è qualcosa che alla fine sarà totale (da quello che ho letto), cioè nel kernel rimarranno solo le primitive, mentre il resto degli strumenti sarà nello spazio utente, questo è non male, al contrario, rimuoverà molto vecchio codice dal kernel, rendendone più facile la manutenzione e molto più configurabile (pieno supporto KMS / DRM per console). Sicuramente all'inizio ci saranno entrambi i sistemi, ma a lungo termine (15-20 rilasci) potrebbe uscire dal kernel, o anche prima, molti strumenti non supportano più tale codice a favore di codice più nuovo e meglio supportato.
Ora, dici che se systemd lo fa, perché altri 50 non possono farlo (immagino 50 applicazioni in più). Bene, se vediamo le forti dipendenze di KMSCon (il progetto più vecchio in questo senso) sono libudev (il codice che verrà unito a systemd presto, non sarà supportato e andrà in conflitto con systemd se funziona da solo), libdrm, libxkbcommon, libtsm e systemd stesso per gestire il multi-posto, quindi quando vedi questo, ti rendi conto di come le cose stanno prendendo forma prendendo per sé molti strumenti necessari affinché un sistema operativo GNU / Linux funzioni senza problemi.
@Yukiteru 3 dicembre 2014 9:46
Qui in gentoo libudev è un virtuale che punta a sys-fs / eudev, quindi la gente di gentoo si occuperà di modificare eudev per conformarsi all'API dettata dal nuovo sistema del kernel.
Quindi penso che le distribuzioni diverse da systemd (ciao devuan) useranno if o if eudev.
Quello che è successo con l'udev originale sta per succedere, systemd lo ha inghiottito, ma qui il nucleo è quello dettato dall'API per interfacciarsi con le console usando DRM / KMS .... Volevo già vedere un urxvt che usasse questo ... hehe
Quello che accetto è che chiunque stia usando systemd, non avrà la possibilità di cambiare nulla ... un'imposizione completa e dura e come ho detto prima ... di piangere al cimitero.
@ anonimo sicuramente quello che dici è l'altra possibilità, eudev prenderà maggiore forza in questo senso e manterrà aperte le opzioni per scegliere strumenti diversi.
PS: come dici tu, sarebbe interessante vedere come i VT sfruttano i vantaggi di KMS / DRM insieme a fbdev 😀
Hai ripetuto esattamente il concetto che ti ho criticato, perché in nessun momento ho parlato del sistema, ho parlato di comunicazione tra processi, e ripeto ancora, dove lo prendi perché due processi comunicano, la morte di uno implica che l'altro ha ampie possibilità di Morire? Spiegami come due processi, che risiedono in spazi di memoria separati, possono influenzarsi reciprocamente il comportamento interno dell'altro. Vediamo se mi spiego, dal punto di vista di uno di questi processi, sta accedendo solo a un meccanismo IPC (qualunque cosa sia stato definito per comunicare ai processi systemd). Se il programmatore era così cattivo nel non includere il codice che può gestire input e output imprevisti, è qualcos'altro, ma non ha nulla a che fare con un processo che influenza le parti interne di un altro. Se systemd-networkd va in crash, non deve uccidere journald o systemd, come con il vecchio sysvinit, il fatto che inetd crash non dovrebbe influenzarlo, sono processi separati.
@dariem ha spiegato in modo semplice per vedere se hai avuto l'idea:
Quello che dici è sicuramente il comportamento che ci si aspetta sempre da programmi e processi modulari. La modularità è stata implementata a tale scopo, quella di separare due processi e che occupano i propri spazi di memoria, e che comunicano in qualche modo (IPC, ecc.), In modo che nel caso in cui qualcosa vada storto, non accade nulla di male. il sistema può continuare a funzionare senza interruzioni. Una teoria che ha sicuramente avuto un grande supporto per le sue potenzialità e per l'immenso margine di affidabilità che ha dato al computing attuale. Ora, questo non è sempre vero (la vita non è sempre bella), e penso che tu sia stato sicuramente vittima di questi eventi in un'occasione o in un'altra (questo vale sicuramente per tutti indipendentemente dal sistema operativo che usi), e ti darò un paio di esempi.
Il primo va con Xorg (che è un processo modulare proprio come systemd), che a volte impazzisce con un driver e si blocca e ti lascia senza grafica, mentre il resto del sistema continua a funzionare come previsto (Blessed modularity 😀). Fin qui tutto bene, la nostra teoria secondo cui i processi modulari non devono rompere il sistema funziona bene. Ma (c'è sempre un po 'ma) a volte Xorg dà qualcosa di più della follia e per qualche strana ragione (che può variare dal controllo del mouse al driver grafico) non solo Xorg si blocca, ma ti dà anche il più bello del panico del kernel ( e un graffito sul monitor come Picasso) che puoi immaginare, e poi ti rendi conto, che non importa quanto sia modulare, se un processo intercomunica e scambia informazioni / dati con un altro e qualcosa va storto in uno di essi, e per per qualche motivo l'errore non può essere gestito correttamente, aumentano le possibilità che i processi in questione vengano influenzati, per il semplice fatto che i dati sono sbagliati o semplicemente corrotti, e poi arriva la catastrofe.
Se pensi che ciò non possa accadere, ti lascio alcune segnalazioni di bug (uno è il mio in Debian e ha un paio di fotografie) di un vecchio errore che è in Xorg, mesa, nouveau e il driver drm / kms del kernel, processi che nonostante correndo ** separatamente ed essendo modulari **, insieme non vanno molto d'accordo, almeno non in quelle circostanze.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742930
https://bugzilla.redhat.com/show_bug.cgi?id=901816
https://bugzilla.redhat.com/show_bug.cgi?id=679619
Ora l'altro esempio che ti fornirò con systemd. Il nostro vecchio Sysvinit aveva una particolarità che nonostante fosse vecchio, era molto affidabile, al punto che se il tuo / etc / fstab avesse una voce di partizione (non importante per il sistema, capisci un / mnt / Disk160GB) e non poteva ' t essere montato per qualche motivo, il montaggio è stato semplicemente saltato, ti ha dato un messaggio di avviso e ha continuato con il processo di avvio. Ora, systemd è un'altra storia, nonostante la sua modularità, se hai una voce in / etc / fstab e systemd per qualche motivo vede cheèimpossibile montarlo, non solo aspetta che la partizione sia disponibile (il normale comportamento programmato ) per il suo assemblaggio, ma se il tempo finisce, il tuo sistema si ferma e non puoi fare altro che entrare in modalità di ripristino e rimuovere quella riga da / etc / fstab, qualcosa in realtà fallisce. Quel piccolo dettaglio non è più durante il montaggio automatico all'avvio, e l'intero processo si ferma, all'inizio (systemd-) il piccolo dettaglio era più brutto, perché il dump è appena apparso e dovevi riavviare. Te lo dice qualcuno che ha esaminato i dettagli.
Un altro esempio che posso fornire è coredumpd in systemd. coredumpd di default passa tutte le sue informazioni a journald in modo che quest'ultimo scriva le informazioni catturate su disco, finora tutto bene, stiamo usando la modularità di systemd a nostro vantaggio. Ma a volte succede, quando i core sono molto grandi, solo così grandi, che possono occupare diversi GB, e nel processo di passaggio delle informazioni da coredump a journald e poi al disco, accadono cose strane come Xorg smette di funzionare e persino il kernel panico. Ciò non accade solo con systemd, ovviamente, ma il modo in cui è progettato aumenta il fattore di errore e crea altri dettagli spiacevoli (tra cui un maggiore consumo di memoria, danneggiamento dei log, dump incompleti), chi ha dovuto lavorare con un coredump di KDE, hai sicuramente passato diversi episodi come questi, e avrai capito l'importanza di avere l'opzione di sincronizzazione in / etc / fstab per la tua partizione di dump, e sicuramente odierai il fatto che non puoi usare qualche altra opzione per gestire i dump, se hai installato systemd. Un esempio di cosa può accadere con systemd-coredumpd.
https://bugs.archlinux.org/task/41728
Ora, per finire:
Non dovrebbero essere programmi e processi modulari? Sì, sono modulari. Il kernel è l'unica cosa monolitica di cui ho parlato qui, ma accetta anche moduli (LKM), quindi sarebbe una specie di kernel ibrido sebbene la sua forma di progettazione di base non sia progettata in quel tipo di struttura, e questo lo rende un un po 'instabile in determinate circostanze.
Quella modularità non dovrebbe permettermi di fare in modo che i miei processi e il mio sistema non si blocchino se qualcosa va storto? È vero, la modularità è una misura progettata per raggiungere un alto grado di stabilità e affidabilità, ma non è una misura infallibile al 100%, perché se qualcosa può andare storto, andrà semplicemente storto, non importa quanto modulare, questo è un realtà.
Quale systemd deve avere il controllo di tutto per rendere possibile l'uso di cgroup e altre opzioni aggiunte al kernel? Completamente falso. Ciò non è affatto necessario, si sarebbe potuto lasciare a systemd un'interfaccia per controllare l'avvio e l'assegnazione di cgroup ai processi e ai daemon che saranno nel sistema, senza dover prendere il controllo del numero di servizi che ha ora, e il il miglior esempio di questo è; che OpenRC è anche in grado di usare cgroups e non è per questo motivo così invadente per svolgere quel compito.
Di cosa sono prevenuto e timoroso quando parlo di systemd? Non ho idea da dove lo prenda, perché come vedete la mia risposta non ne ho paura, parlo solo di aspetti che non mi piacciono di systemd e già, senza fare affidamento sulle opinioni di terze parti.
Infine, dici che: "Se il programmatore non ha incluso il codice che può gestire input e output imprevisti, è qualcos'altro ..."
Certamente dire che il programmatore per non aver incluso un codice che gestisce TUTTI i modi possibili in cui il suo programma può essere rotto da qualche errato inserimento di dati, è MALE, mi sembra un oltraggio. Non importa quanto bravo sia un programmatore, una persona non è in grado di progettare un programma infallibile e sicuro, ci sarà SEMPRE un fallimento, che in un modo o nell'altro verrà alla luce, e quando lo farà, sarà grazie a un errore casuale durante il suo utilizzo, da parte di un hacker o cracker che sfrutta una vulnerabilità, da una revisione e verifica del codice o da qualsiasi altro mezzo su cui il programmatore può contare. Meglio misurare le parole prima di dire qualcosa del genere.
Saluti.
L'esempio che fornisci di Xorg è il meno appropriato perché tutti coloro che hanno subito il passaggio a KMS / DRM sanno che il problema è causato da bug nei moduli del kernel per controllare KMS forniti dagli sviluppatori dei driver Xorg. Un bug in un modulo KMS è lo stesso di un kernel panic, non ha nulla a che fare con la comunicazione tra i processi, perché in quel caso è Xorg che effettua una chiamata di sistema (syscall) in modo che il kernel cambi la modalità dello schermo, cioè lì è solo un processo coinvolto (Xorg) che chiama il kernel, niente a che fare con ciò di cui abbiamo a che fare qui.
Il comportamento corrente di systemd quando non trova il punto di montaggio è irrilevante indipendentemente dal fatto che si tratti di una funzionalità che a qualcuno potrebbe non piacere, che viene risolto chiedendo di supportare l'altro comportamento, quello di ignorare il montaggio fallito. Il coredump che si è verificato prima potrebbe essere dovuto a cause dissimili che possono essere solo ipotizzate, ma il fatto che l'esecuzione non sia continuata può essere dovuto a un comportamento desiderato, dal momento che dici che doveva essere riavviato, non che ci fosse un kernel panico o un riavvio automatico. Dato che non l'ho passato non posso dare un'opinione.
Per quanto riguarda il problema che hai posto con systemd-coredumpd e il collegamento alla segnalazione di bug, tutto indica che questo problema in Arch Linux era dovuto alla compressione che hanno abilitato a systemd quando lo hanno compilato per quella distribuzione. Sembra più un problema con l'algoritmo di compressione che con systemd stesso. Il sistema operativo non si blocca, piuttosto l'algoritmo di compressione utilizzato per memorizzare i core sembra prosciugare il sistema e questa è colpa degli sviluppatori di Arch Linux che hanno compilato systemd. Tuttavia, systemd dispone di impostazioni per limitare il consumo di risorse e abilitare / disabilitare l'acquisizione di tutti i core pompe segnalati dal kernel. Forse i manutentori di Arch di systemd e quelli che usano KDE dovrebbero dare un'occhiata a loro.
Dici che OpenRC utilizza anche cgroup senza essere invasivo. Il problema è questo: come fa OpenRC a riconoscere il nome degli eseguibili del demone per sapere esattamente quale allocazione di risorse è la più appropriata? Non sono proprio sicuro che questo sia uno dei motivi per cui systemd si prende cura di così tante cose, dando agli eseguibili un nome ben noto, ma sospetto che le cose stiano andando in quel modo. Inoltre, elimina l'onere di avere un trattino nel mezzo per eseguire ciascuno di questi servizi, invocando direttamente gli eseguibili.
Non negherò che systemd possa avere molti bug, ma da lì ad attribuirli tutti al modo in cui è concepito, non credo. Nel caso di sysvinit, era super stabile, un software maturo, systemd è solo all'inizio.
https://www.reddit.com/r/LinuxActionShow/comments/2nv4hp/ask_lennart_poettering_a_question/
Come fanno a scoppiare le palle con systemD, xD Se lo odi così tanto, crea la tua distribuzione, che è ciò per cui è il software libero é_é
Non si tratta di odio, si tratta di difendere la tua comunità.
A proposito, se ci sono distribuzioni "Underground" indipendente:
http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
Rispetta
perchè confronta tutto con microsoft che si comporta come windows .. se le cose funzionano bene ed è per lo sviluppo e l'evoluzione di linux qual è il problema ... ogni progetto all'inizio potrebbe avere errori di modifiche se i programmi software ecc. fossero perfetti, Siamo umani, ma è per questo che abbiamo errori.
che se systemd fallisce, il sistema andrà in crash ... e se il kernel, xorg, grub fallisce ... ci sono persone che, aggiornando il kernel sul proprio pc o laptop, perdono il sistema ... allora perché l'insistenza sul perfezione di qualcosa ...
come se qualsiasi sistema che è uscito non avesse avuto errori bug o qualcosa nei suoi inizi o anche nella sua maturità avesse fallimenti
Systemd è stato imposto come standard con il gioco sporco, è una dipendenza obbligatoria per molti pacchetti perché molti programmi sono stati assorbiti da systemd o perché li hanno mantenuti o perché li hanno eliminati lentamente poiché non erano più rilevanti perché systemd forniva già qualcosa di simile.
Questo limita la libertà di scelta, cioè le distribuzioni non possono scegliere di NON usare systemd, possono provare a resistere come gentoo, ma questa è più di una soluzione temporanea a systemd, openrc è solo un gestore di servizi supportato da sysv per init e negli initscripts della distribuzione , systemd fornisce più funzionalità di openrc e ha nuove funzionalità ogni giorno. Il nuovo software supporta systemd e richiede di implementare qualcosa di simile che finisce per rendere gli altri inits più complessi e più simili a systemd che è quello che non vuoi.
Systemd fa molte cose rispetto al vecchio init, che legge semplicemente un paio di righe da / etc / inittab e quindi carica ogni initscript e le sue impostazioni secondo il runlevel. Il vecchio approccio era molto più semplice e indipendente. Siamo in una fase di transizione verso una nuova era di omogeneità, non c'è soluzione, il modo in cui prevale è inarrestabile.
Tra pochi anni non ci sarà praticamente alcuna differenza tra usare debian, usare arch o fedora, l'identità di ogni distribuzione andrà persa se continuiamo in questo modo e systemd diventerà ogni giorno più invadente che diventerà persino parte del nome del sistema (systemd / gnu / linux)
LOL
Per gridare alla chiesa>: D
Cosa dice Don KZKG, vi lascio questo: https://blog.desdelinux.net/systemd-vs-inteligencia/#comment-127648
Il problema è che tu sei argentino (lo sono anch'io) ma il modo di esprimersi che la maggior parte degli utenti argentini di Linux che leggo è davvero preoccupante, anche se si dice anche che il mondo del software libero attiri certe persone. Quello che salvo è che tu non presumi di essere argentino, ma sfortunatamente mostra campionati.
uyyuyy .. quel ragazzo è caduto con l'artiglieria pesante ..
commento forte !!
Juju .. ..pochoclos .. xD
Da questo articolo consegue che tutto ciò che fanno è "imporre" un sistema. Non entro per valutare se è meglio (cosa che non è), o peggio. Quello che dico, ripeto, sottolineo e sottolineo, è che non voglio davvero che mi impongano nulla.
Frasi come: "Semplicemente non li usiamo per il processo di avvio, perché pensiamo che non siano lo strumento migliore per quello scopo specifico".
E chi sei tu per dirmi se voglio usare questo o quello strumento?
Ognuno. Semplicemente non lo uso, punto, e finché non posso, non lo farò.
Firmato. Un talebano.
(È che sono divertito dalle buffonate)
spesso un mal di testa con quell'argomento !!!! X_X
Gestivo server con Centos 6 e andare a 7 con systemd non mi è costato nulla, non piangere, la vita va avanti.
Mi scusi, ma sto leggendo molto che mi ricorda il classico discorso "server windows - Certified Man VS server linux - OpenSource Man".
1 ° - Vedrai, se forzi un errore è normale che fallisca. Ognuno dei video che ho visto sono errori forzati. È come se realizzassi un programma che inserisce parole chiave nel log di syslog e allo stesso tempo provo a eseguire uno script basato su grep per estrarre informazioni dal log ... certo che fallirà, l'ho causato io.
È come versare lo zucchero in un motore diesel e dire "Guarda ... la benzina è meglio !!!" o come fanno i Windows, scrivere un file di configurazione sbagliato e lamentarsi che il demone non inizia dicendo "con Windows questo non succede".
2 ° - Quel systemd incorpora molte cose che potresti non usare? Ebbene qual è il problema? È che è lo stesso argomento vuoto che Windows usa contro quelli Linux ... "Perché voglio che un testo semplice metta mille e una opzioni quando non le userai?"
Sento ancora i ragazzi dell'IBM con i loro programmi monilitici abbaiare anni fa su mysql quando leggo alcune cose. Ringrazio e applaudo la diversità di GNU / Linux e della sua comunità. Se mi dai 50 modi per fare qualcosa, sceglierò in ogni momento quello che funziona meglio per me o si adatta a ciò di cui ho bisogno. Vedi davvero un problema in questo?
3 ° - Dal livello delle conversazioni, deduco che tu abbia un livello sufficiente per lavorare con qualsiasi distribuzione o crearne una tua e mantenerla tu stesso. Perché vuoi mettere systemd e rimuovere cose da esso? Non è più facile continuare con il tuo init o openRC?
Alle persone che mi hanno chiesto di insegnare loro le basi di Linux dico sempre la stessa cosa ... GNU / LINUX non è WINDOWS, non provate a fare le stesse cose né pensate come se lo fosse. Perché assimilate che sistemd è uguale a initd o che funziona allo stesso modo? Non è più facile assimilare il funzionamento di systemd e utilizzarne le potenzialità, piuttosto che provare a creare funzioni come init o OpenRC? È normale che non ti piaccia.
4 ° - Cosa c'è di sbagliato nella complessità? Sicuramente ricordi ancora quando hai dato la programmazione lineare e che sicuramente ad un certo punto hai detto ... «E perché voglio imparare a lavorare sugli oggetti se ora posso fare tutto e altrimenti mi lasciano usare?» ... (Il facepalm un paio di mesi dopo è ottimo se xD)
Siamo chiari. L'attuale init (e includo systemd) ha molti difetti che possono essere colmati solo aggiungendo complessità. Non ce n'è altro, perché per crescere un sistema interconnesso deve crescere in complessità a rischio di avere qualche parte debole, ma è meglio che restare stagnante.
Ci vuole molta strada da fare e se… sistemd non è la soluzione a tutto. Ma nessuno dei due è rimanere con SysVinit.
PS: Notare l'ironia che ho usato il PC del mio collega "Mi aggrappo a Windows Server Defender" in modo che possa leggerlo a proposito. xD
Solo una cosa, ai difensori di altri INIT che danno dati tecnici e link… CHAPO !!! Adoro vedere argomenti e dati come questo. Solo una nota, i dati precedenti a ottobre 2014 sono puramente storici.
Molte cose di cui si discute sono già state risolte e molti banchi di prova pubblicati nel 2013 sono già stati rivisti.
@rolo
Se è vero, se hai visto il video, cosa che NON hai fatto, puoi vedere che il registro è 8 MB, niente di più e così via e tutto si danneggia, a proposito, puoi inviare l'output di journald a syslog in testo normale? Sì, ma anche così se tocchi i log creati da journald, succede, il sistema si blocca e, è comprensibile, vediamo, journal si blocca su PID1 insieme a cose complesse come systemd, fallisce, vedi che non lo fa avere una parte di codice che non consente la modifica di qualcosa di diverso dallo stesso PID di journald e non ha la capacità di continuare a scrivere oltre il registro è danneggiato, il che mostra che oltre a pensare in modalità Windows, LP è un cattivo programmatore.
Non dirmi che sarà solo in centos, la versione più stabile della distro che usa systemd, clone di RHEL7, e non segnalo né intendo segnalare l'errore.
La verità è che più leggo i commenti pro systemd, mi rendo conto che sono davvero come una religione, o tu sei favorevole o sei il nemico, ma, di quelle religioni tipo ISIL, quelle dello stato islamico, totalmente estremisti, infatti, lo so per esperienza, gli amanti del sistema, la pensano così, o sei con loro o sei il nemico. Questo è ciò che Lennart promuove con la sua arroganza e per favore, non fottermi con Linus che lo supporta, systemd non era questo, NON ERA, ho usato systemd non appena è uscito in Fedora 15 ed è stato solo un init più veloce, non ha sostituito la modularità GNU / Linux.
Se uccido rsyslog, corrompo i suoi log o lo sostituisco con un disegno, nient'altro, solo che finisco il log, niente si blocca, il sistema non è interessato.
@Rafael Mardojai
Questo è ciò che fa Devuan, questo è ciò che ha fatto Void Linux e altri che stanno alla larga da systemd.
@ Yukiteru
Sicuramente nessuno ti legge, come mi dicono i talebani, non ti leggono perché usi windows o hai commentato da esso e perché penso che pochi degli amanti del sistema capiscano la parte tecnica di quello che dici e qui sta il problema.
======
La verità è che penso ancora che una persona conosciuta nel 2006 avesse ragione su qualcosa:
"Non voglio che la gente usi Linux o lo sappia, questi ragazzi di Ubuntu hanno le palle piene"
Io- "Perché?"
"Quando qualcosa diventa noto e per le masse, fa schifo, fa una cazzata, e ci sono campioni a bizzeffe"
Io- "come quali?"
"Guarda cosa è successo a Debian, ora ha uno stupido figlio di nome Ubuntu e ricorda che tra qualche anno avremo" hacker "e" geek "che hanno succhiato Ubuntu e non sapranno come distinguere Ext3 da NTFS"
Qualcosa era giusto ... systemd trionfa tra coloro che sanno, come dice Allan McRae, perché non gli importa come avvia la sua macchina, per lui è, pulsante, magia e ho un prompt. Tra coloro che sono interessati solo a "lavorare" con caratteristiche carine, totali, per server usa davvero LFS o Gentoo o BSD e poi quelli che lo amano perché accende il proprio PC più velocemente con luci colorate, bei suoni e giochi d'azzardo, ma non sanno cosa sia un syscall.
@SynFlag se non lo leggono è per decisione propria, per quanto riguarda il sistema operativo che utilizzo, se sono al lavoro e commento da un PC Windows, è perché è l'unica cosa che ho a portata di mano, tranne il server che è in Debian Wheezy e ovviamente dal server non posso commentare qui.
Anche a casa sono stato costretto a usare il PC di mia sorella perché il mio PC è morto (il MB e il generatore hanno cospirato contro di me), e anche così quando ho tempo monto un LiveCD e uso Sabayon (con OpenRC) per commentare ecco, come sto facendo proprio mentre scrivo queste parole.
Ora, se mi dicono o pensano che io sia un talebano anti-sistema, non mi interessa. Come ho detto, ho usato systemd e so che zoppica, non solo, di solito leggo molto l'elenco di systemd per scoprire le cose che arrivano nelle nuove versioni, e anche per essere consapevole delle modifiche che vengono apportate e le discussioni che si svolgono lì. Ora, se un qualsiasi amante di systemd comprende l'aspetto tecnico di ciò di cui sto parlando e inserisco i miei collegamenti (principalmente i collegamenti al repository git di systemd), e anche così non è in grado di vedere la realtà, questo mi permette solo di pensare che vendo ai loro occhi e all'estremismo nel loro modo di vedere / pensare / sentire / amare / glorificare / lodare / adorare il systemd è così grande che non importa se anche Linus stesso caccia il **** fuori dal systemd, lo faranno essere ancora trincerato nelle loro idee che sono corrette.
Ciao! Non sono molto esperto e vorrei sapere a cosa serve questo "systemd" e perché se ne parla così tanto, qual è il problema e quale alternativa c'è? Grazie
Il commento di SynFlag! Io vengo da "smanettoni", "smanettoni" e "pro linuxeros" allo stesso modo.
E questo è il futuro che ci attende; Ubuntu anche nella zuppa; Laptop Linux per accedere a Steam e giocare all'ultimo gioco caldo. E legioni di piccoli smanettoni che non sanno di cosa tratta il branco.
Postscript: il concetto di background di systemd fa schifo.
i pulsanti adk e forum non sono visibili nella pagina principale
Quindi secondo @SynFlag ora tutti quelli che non sono anti-systemd sono un fanatico religioso estremista, n00b, e la piaga che corrompe GNU / Linux. Con un'opinione così ristretta non so se valga la pena di discutere su questo argomento. Meglio lasciar scorrere l'acqua e alla lunga ciò che deve accadere accadrà.
È vero, arriva un punto che non può più essere discusso. solo il tempo ci dirà se sytemd sarà qualcosa di positivo o meno per il mondo del software libero.
Mi dà anche l'idea che se questa distribuzione basata su Debian che non utilizzerà systemd si realizzerà, aiuterà a placare gli spiriti di coloro che non vogliono sapere nulla di systemd.
come quando è apparso gnome 3 ed è stata costruita una resistenza tremenda, fino a quando non è apparso il "fork" cannella e unità che ha permesso di continuare a utilizzare le applicazioni gnome su un desktop con più configurazioni e un design più pensato per il pc e non tanto per il touch
Forse questo, Rolo (l'apparizione di Devuan), può essere un punto di consenso. Penso che tutti ne abbiamo bisogno per contenere un'atmosfera di discussione polarizzata e bellicosa. Devuan sarà uno spazio per la creazione e la continuità di un modo di fare e questo aiuterà a calmare gli spiriti. Il processo che abbiamo vissuto in Debian è stato doloroso, tuttavia dobbiamo affrontare la situazione, non c'è altra scelta che accettare la separazione. Questo finisce per essere un po 'come i divorzi. Questa forchetta potrebbe essere la trascrizione di un trattato di pace e una parte di esso. C'erano delle alternative, ovviamente, Slackware, Gentoo, Funtoo, Crux, PCLinux OS, ora Manjaro (per citarne alcuni) ... ma la scena "deb" richiedeva un'alternativa senza systemd. Sembra chiaro che nessuno convincerà nessuno, gli argomenti sono sul tavolo e non c'è consenso (nonostante il fatto che systemd abbia buone idee e i pericoli che questo software comporta siano evidenti). È tempo di fare fork e di ottenere la libertà per l'utente (perché si tratta di Software Libero, giusto?).
Un fattore che ha influenzato il processo è stato il senso di "delusione" da parte di alcuni di noi che ripongono la nostra fiducia in Debian. Ecco perché Devuan è presentato come un fork e non un derivato. C'è tensione perché a nessuno piace quello che è successo; né il pro-systemd (quindi certi attacchi furiosi che cercano di diffamare) né l'anti-systemd (che hanno optato per il fork). Nell'ambiente c'è il "quanto talento possiamo perdere?", Sia da un lato che dall'altro.
Tutti gli utenti Debian guardano la distribuzione in "un" certo modo (questo può essere applicato anche ad altre distribuzioni). C'è chi ammira la sua qualità tecnica, altri il suo contratto sociale, la sua influenza nel mondo Linux, il rispetto che si è guadagnato negli anni, la sua stabilità in ambienti di produzione critici ... In alcuni utenti questa percezione è cambiata, con l'apparizione della delusione . Delusione, disincanto, chiamalo come vuoi. Da lì alla separazione c'è solo un piccolo passo.
Il divorzio Debian è simile a quello che è successo con NetBSD e OpenBSD. Anche se il tempo lo dirà. Vedo molte aspettative nel fork e questo mi fa pensare che non sarà una distribuzione fugace e sterile. Proprio oggi c'era un membro del team degli gnomi a commentare la mailing list di Devuan (nonostante lo abbia fatto goffamente), questo, a mio parere, fa pensare che Devuan generi interesse e voglia, in qualche modo, dialogare.
Comunque, buon fine settimana.
@rolo
Dire che il video può essere ingannato o il software è un totale errore e insulto, nella mia vita PU ** ho ingannato qualcosa per creare un mito, mai, mi vanto di aver visto quel fallimento con i miei mezzi, non con i miei trucchi. Vanno tutti al **** che al ***** e non metterò più nei dibattiti del sistema perché è totalmente per la scoreggia, nessuno vuole capire niente ed è tutto come una retrocessione, che, Odio, perché tutto è per dogma di fede. Sii felice con systemd.
@SynFlag la violenza sta mentendo
Ciò che questo video dimostra è la falsità dell'affermazione che se uno dei moduli systemd è rovinato, causa il crash di systemd, poiché ovviamente, da quello che il tuo video mostra che non è accaduto, xddddd e dal modo in cui journal viene eseguito come root, pertanto, se una terza parte entra e incasina maliziosamente il binario del registro del journal, non mi preoccuperei di systemd ma piuttosto della sicurezza del tuo computer. xdddddd. Infine sull'argomento del video, replica quanto mostrato modificando con nano il file /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal e al riavvio ti accorgi che è presente un nuovo system.journal e un sistema @@ 24f02f5b2b16758 @@ 820f6f751bXNUMXbXNUMX. Journal che è il file binario danneggiato.
In altre parole, journal si rende conto che il file è corrotto, quindi non lo rinomina e ne crea uno nuovo di nuovo, non vedo quale sia il problema in questo? Crea.
Mi chiedo cosa succederebbe se rovinassi un file di log di testo semplice con un editor esadecimale, sicuramente finché non ci si accorge che il file è danneggiato, tutti i dati verrebbero distrutti Oo
Parliamo un po 'di journal, che è una delle critiche più comuni a systemd.
journal è un componente molto importante di systemd, che cattura i messaggi Syslog, i messaggi di registro del kernel, la RAM e i messaggi di avvio iniziale, nonché i messaggi scritti in STDOUT / TDERR e rende tutte queste informazioni disponibili all'utente.
Ma soprattutto, journal può essere utilizzato in parallelo o in sostituzione di un demone syslog tradizionale, come rsyslog o syslog-ng, quindi un amministratore di sistema cauto potrebbe avere rsyslog o syslog-ng come secondo strumento di query, oltre a trasformare i record del journal in testo normale nel caso in cui il binario venga danneggiato
Un altro fatto importante su journal è che se la cartella / var / log / journal non viene creata, le informazioni vengono salvate solo temporaneamente, il che viene perso a ogni riavvio.
ad esempio, quando sono entrato in systemd in debian la persistenza del log non era attiva quindi ho dovuto creare manualmente la cartella journal
http://0pointer.net/blog/projects/journalctl.html
Chi conosce l'inglese, non può perdersi i colloqui in corso tra gli sviluppatori di devuan, jaromil dimkr max2344 tra gli altri sul canale IRC di freenode #devuan.
Molto divertente leggere le indagini sul codice systemd in quanto l'hanno versato apposta per infettare (creare dipendenze non necessarie).
Systemd mi infastidisce ... dritto ... è difficile. Poca documentazione o il fottuto slim corre solo KDM o gdm e in un sistema leggero voglio che slim lxdm non lo supporti o lo compili… .. Seriamente che anche prima… ero contento che avrebbero dovuto. La verità è che ho iniziato a usare openrc come si suol dire in gentoo e mi ha aiutato…. Tanto
@rolo
Sei un insolente e un malformatore di notizie per dirlo. È il peggior insulto che mi dici che mento o falsifico i dati, mi disgusta davvero come per difendere qualcosa attacchi persone che fanno PoC seri come me. Il registro è danneggiato, il sistema va in crash, il riavvio del servizio non funziona quindi non c'è altra scelta che riavviare la macchina, che non è la migliore in un server hackerato, mi dirai che se la sicurezza è stata compromessa, la cosa migliore è riavviare o reinstallare ed è l'unica cosa di cui dovrei preoccuparmi visto che il sistema diceva scusandosi e non facendo un'analisi a caldo di COSA È SUCCESSO? per arrivare a quel punto? Ovviamente sei un prodotto in più del nuovo amministratore di sistema se arrivi a quello che è stato generato usando Ubuntu e ha la sicurezza di un DOS 5.0 sul tuo PC, quindi quello che dici lo prendo come da chi viene, mi dà fastidio che tu dubbio anche chi falsifica sei tu, hai risposto allo stesso OS con gli aggiornamenti di QUEL giorno? Sicuramente no, quindi prova a mentire ad un altro. Che mancanza di capacità hai, vai a lavorare come tassista per più di quello dubito che ti darà, smetti di giocare con Linux e continua a cercare pr0n
Vediamo pigeon (synflag), papà ti mostrerà come far continuare a funzionare il journal dopo che il nostro file di log binario del journal è danneggiato per qualche motivo, senza dover riavviare il computer.
In questo esempio partiamo da un'installazione base di debian 8 jessie.
Per impostazione predefinita, systemd-journal.service viene fornito con la funzione "storage = auto", quindi per avere una registrazione persistente dei log, è necessario creare il file in / var / log / journal / precedentemente.
# mkdir -p / var / log / journal /
Affinché il journal inizi a scrivere i log, NON è necessario riavviare il computer, basta fare:
# systemctl ricarica systemd-journal.service
o
# systemctl ricarica forzata systemd-journal.service
### ora simuleremo che il log binario del journal è danneggiato ###
# cd / var / log / journal
#ls
24f02f5b2b19808b820ea0a980ed6efb
# cd 24f02f5b2b19808b820ea0a980ed6efb
# nanosystem.journal
### ora modifichiamo qualche riga del file per simulare che sia corrotto
#journalctl
### come previsto non succede nulla
#### il computer deve essere riavviato affinché journal possa creare un nuovo binario? NO
# systemctl ricarica forzata systemd-journal.service
#ls
system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
diario.di.sistema
#journalctl
### Come possiamo vedere, journal crea un nuovo file di log binario e ora possiamo accedere nuovamente alle informazioni senza dover riavviare il computer in qualsiasi momento
https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be
conclusione: sinflag o sei ignorante, o sei un favolista
lascia che ti guarnisca finito
per errore di digitazione e abuso di copia e incolla ho scritto systemd-journal.service quando in realtà il servizio si chiama systemd-journald.service
Pichon?, ... quanto hai torto sei magro, sul serio .. Lo sapevo già, segnala il bug in cappello rosso per vedere cosa hanno detto, ti rispondo, vedi se prendi:
Se rimuovi il file di output o sovrascrivi parti del file, il demone non può davvero fare nulla al riguardo: se un utente malintenzionato ha i permessi per modificare il file di output, ha già vinto. Il demone potrebbe controllare alcune di queste cose, ma sarebbe piuttosto inefficiente e non molto utile per nulla. Se lo desideri, puoi impostare una firma crittografica periodica con "journalctl –setup-keys". Vedere la pagina man di journalctl.
Journalctl dipende da rsyslog, non si riavvia automaticamente in caso di errore nel log, di cui rsyslog non ha bisogno, totale, devi usare fordward per inviare a rsyslog e in questo modo viene scritto nonostante tutto e il log del journal è rigenerato, è un difetto di design di journald, se non vuoi vederlo, fammi saltare.
@rolo
Nel video (non so se l'hai fatto) vedo che al minuto 2:11 viene usato ls e non ls -l che permetterebbe di vedere la dimensione che aveva originariamente il file system.journal, poi lo modificano con nano e aggiungi righe vuote, riavvia il servizio manualmente e al minuto 3:15 fanno di nuovo ls e non ls -l, poi al minuto 3:20 vedono il log con journalctl, questo mostra il log corrente che va bene.
Ora arrivano le mie domande:
1 - perché si usa ls e non ls -l, per vedere la dimensione originale del log prima di essere modificato
2 - cosa è successo al vecchio registro? dove lo ha messo systemd nel registro binario danneggiato?
3 - con quale comando systemd puoi riparare il tuo registro binario danneggiato ... che non dovresti eliminare
saluti
@anonimo
Ora arrivano le mie domande:
1 - perché si usa ls e non ls -l, per vedere la dimensione originale del log prima di essere modificato
2 - cosa è successo al vecchio registro? dove lo ha messo systemd nel registro binario danneggiato?
3 - con quale comando systemd puoi riparare il tuo registro binario danneggiato ... che non dovresti eliminare
1 la verità è che non ci ho pensato, basta usare ls per vedere quali file c'erano nella directory, ma se sei interessato puoi replicarlo, la procedura è dettagliata e lo faccio in virtualbox (installando una base debian è un gioco da ragazzi)
2 il vecchio registro rimane nella stessa directory, solo systemd lo rinomina con un mucchio di numeri e lettere (mostrato nel video)
3 In ogni caso, potresti provare a utilizzare applicazioni di terze parti (suppongo qualche editor esadecimale) poiché se systemd potesse riparare il file corrotto non lo rinominerebbe né ne creerebbe uno nuovo. In ogni caso, e come ho già accennato in altre occasioni in questo post, un amministratore di sistema prudente potrebbe utilizzare rsyslog o syslog-ng come secondo strumento di query, oltre a trasformare i record del journal in testo normale nel caso in cui il binario venga danneggiato.
Voglio dire, non è l'idea di convincere nessuno a usare systemd (mi piacerebbe persino che nell'installatore Debian ci sia la possibilità di scegliere int). ma non tacerò quando leggo persone ignoranti o favolose che continuano a ripetere bugie su systemd, come esiste un blog, quando si vede che quei detti non coincidono con la realtà. e come diceva Aristotele, l'unica verità è la realtà 😉
@rolo
Ho guardato di nuovo il video e se, lì era elencato, solo che il nome numerico era così lungo che l'ho visto, ho pensato che fosse la directory .... Nome sovrano.
Per quanto riguarda la riparazione del binario, sì, è logico quello che dici ... se potessi ripararlo non ne creerei uno nuovo.
Infine mi resta che non dovrebbe essere un binario in modo che ciò non avvenga e per poterlo vedere senza strumenti speciali con journalctl ... Continuo a non capire cosa l'abbia portato a utilizzare un formato binario.
Saluti e grazie per aver risposto
Rolo, dedicati a qualcos'altro:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Lo sapevo senza sapere che…. Come fai a notare la differenza tra uno che sta provando e un altro che fa solo video di scoregge
Vengo a chiudere l'ocote de Rolo, l'errore che si vede nel mio PoC era stato segnalato, quindi, chiudi l'ocote pichon:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Da vedere favoloso:
1 Hai affermato che affinché il journal risolva il problema era necessario riavviare il pc come in windows TOTALMENTE FALSO
Ti ho mostrato che era una bugia e nel video che hai fatto in nessun momento usi il comando systemctl force-reload systemd-journald.service perché se lo avessi usato il tuo argomento andrebbe in crash (o non sapevi il comando , che dimostrerebbe che sei un ignorante, o che intenzionalmente non l'hai usato, il che mostrerebbe che sei un narratore)
2 Dici che ci sono segnalazioni di bug, da un lato è totalmente irrilevante poiché di solito le persone segnalano un sacco di sciocchezze come bug (per farti capire, non tutte le segnalazioni di bug sono un bug reale) mi dà persino l'idea che tu lo hai segnalato tu stesso. E d'altra parte, tutti i programmi hanno bug (quanti bug segnalati ha sysvinit (un programma che ha circa 20 anni)) e la cosa buona del rapporto è che aiuta gli sviluppatori a scoprire e risolvere i problemi (alcuni più velocemente , altri più lenti)
3 Dici che con l'errore che generi in journal, quando riavvii systemd si blocca poiché nel video puoi vedere che devi riavviare forzatamente la virtualbox. COMPLETAMENTE FALSO
La verità è che systemd non si arresta in modo anomalo poiché il sistema si avvia perfettamente (se non si avviava systemd ti darebbe un panico del kernel e dovresti entrare in modalità di ripristino)
Quello che ti succedeèche il sistema viene controllato quando provi a modificare un binario con un editor di testo e i fattori possono essere molti, come la memoria allocata, lo stato del sistema operativo (nel video il sistema impiega molto tempo per avviare e disattivare ciò che suggerisce che non si tratta di un'installazione pulita di 0 (che è consigliata per questo tipo di caso)), ecc. Posso solo dirti che il binario che ho modificato circa 10 o 20 volte e non è mai stato controllato. Questo mostra anche che sei un ignorante o un narratore.
4 Ora dici che journal dipende da rsyslog TOTALMENTE FALSO, il fatto è che chiunque può verificarlo installando o disinstallando rsyslog e vedendo che journal funziona perfettamente
Apprezzerei molto se mi lasciassi quella malsana ossessione, non è colpa mia se sei ignorante o favoloso
Conclusione:
Non vuoi usare systemd, penso che sia fantastico, ora non hai bisogno di diffondere il terrore con bugie per ottenere aderenti alla tua crociata anti-systemd. Ho vissuto e lasciato vivere, che c'è un posto per tutti nel mondo del software libero 😉
un chiarimento sul punto 3, qualcuno mi direbbe che siccome systemd è in pid1 un crash della macchina implicherebbe che systemd helmet. Due cose, prima ecco quello che è stato affermato è che systemd si è bloccato a causa del fallimento del journal, ma in realtà viene prodotto un controllo per inserire un binario (che viene utilizzato in tempo reale) con un editor di testo, chiarisco anche che in tutti i i test che ho eseguito non hanno mai controllato la macchina virtuale. In secondo luogo, nessuno sano di mente può affermare che linux non è etichettato con xddd,
Fabler?, Magro, trattieniti un po ', favolista la tua vecchia che dice che lancio la gomma quando non la tocco con un bastone, torno a rispettare:
1.- Devi riavviare o forzare il riavvio del servizio, il che non è l'ideale e in CentOS 7 quando ho provato il riavvio del servizio non ho fatto nulla, non dimenticare che è la versione 208 non la nuova 217 o 216 di Fedora.
2.- Irrilevante e chi segnala bug? ... sei un idiota, non ti rispondo nemmeno
3.- UNHAPPY, la versione che ho provato quel giorno del video, che puoi vedere, l'intero sistema operativo si è bloccato, perché pensi che l'orto infelice bugia? Non sono una scimmia bugiarda, vai a prendere cindor pajero.
4.- Dipende da auto-rigenerarsi, non lo fa da solo infatti l'ho suggerito a systemd devs come funzionalità, che si rigenera senza interrompere il logging a meno che il servizio non venga riavviato, lo hanno preso come quello che loro sono da aggiungere, quindi succhiami il cazzo e dimmi grazie papà per aver collaborato mentre guardo il porno.
Ciao magra, mi sono stancata di parlare con le scimmie per questo preferisco andare allo zoo, quando sei all'altezza del mio ano chiacchieriamo.
@SynFlag mi scuso, non sapevo che fossi malato, credevo davvero che fossi un favoloso e ignorante, ma con quello che hai appena scritto mi rendo conto che in realtà sei deluso.
beh niente, spero che ti diplomerai meglio e torni alla realtà, forza! Puoi!!!
Ho letto e letto e riletto ma non ci capisco niente, so solo che da quando è uscito Xubuntu 14.04.1 non ho avuto nessun problema con il mio notebook, o con la mia stampante laser hp 1102, non lo so niente, sono un utente e non so se systemd sia peggiore o non adatto a init, ma ripeto che non ho problemi con xubuntu. 🙂
Leggo, leggo e rileggo e so solo che sto rivivendo un vecchio argomento. XD