Systemd è "dannoso"? [chiuso]


11

Visitando alcuni forum online che parlano di Debian e Xubuntu, ho visto alcuni utenti che aggiungono questa riga nel campo della firma:

... Senza systemd ...

Questa linea è mostrata con orgoglio (mi sembra).

Da Wikipedia :

systemd è una suite di demoni, librerie e utility di gestione del sistema progettati come piattaforma centrale di gestione e configurazione per il sistema operativo Linux.

Quindi systemdnon sembra una brutta cosa, quindi perché le persone scrivono con orgoglio di non usarlo?

Può systemdessere pericoloso o semplicemente dannoso per te?


1
Hai letto la parte relativa all'adozione e alla ricezione di quell'articolo di Wikipedia? Ha riferimenti a più articoli sul perché ad alcune persone non piace.
Leiaz,

Risposte:


8

No, non è né pericoloso né dannoso per te. Ti sei imbattuto in una piccola battaglia delle guerre di init . Non ne parlerò in dettaglio ma, brevemente, la situazione è la seguente.

Linux ha usato sysvinit per la maggior parte della sua vita. Questo è vecchio e privo di funzionalità e l'unica cosa su cui tutti concordano è che deve essere cambiato. Tuttavia, nessuno può essere d'accordo su cosa dovrebbe essere cambiato. Sono state proposte varie alternative, tra cui - ma non solo - le seguenti:

Entrambi sono buoni a modo loro e cattivi negli altri. Come spesso accade nel mondo dei geek, la scelta di quale sistema init (o uno di quei due o un altro) da adottare è diventato qualcosa di simile a una guerra religiosa.

Quindi, ti è capitato di imbatterti in qualcuno che non piace systemde, quindi, è orgoglioso di non usarlo. Ci sono varie persone che hanno l'opinione opposta e pensano che systemdsia meraviglioso e tutto il resto terribile. Proprio come c'è su qualsiasi altro argomento nelle interwebs ampie e meravigliose.

Fortunatamente, le guerre di init stanno diminuendo e ora hanno superato il loro apice. La maggior parte delle distribuzioni Linux ha deciso di passare a systemd. Anche Ubuntu di Canonical, nonostante siano la forza dietro upstart. Quindi, oggi, systemdè in realtà il sistema di scelta init per praticamente tutte le principali distorsioni tranne Gentoo ( fonte di immagini ):

inserisci qui la descrizione dell'immagine


6

Hai letto l' articolo di Wikipedia che hai collegato? In particolare, il terzo paragrafo.

La progettazione di systemd ha generato significative polemiche all'interno della comunità del software libero. I critici sostengono che systemd è eccessivamente complesso e soffre di continui creep di funzionalità e che la sua architettura viola i principi di progettazione di sistemi operativi simili a Unix. Si teme inoltre che formi un sistema di dipendenze interbloccate, offrendo così ai manutentori della distribuzione una scelta limitata se non quella di adottare systemd man mano che un numero maggiore di software nello spazio utente dipenderà dai suoi componenti.

C'è anche una grande sezione più in basso intitolata " Storia e controversie ".


4

Dipende da ciò che consideri dannoso. Per esempio. suckless.org lo considera dannoso:

http://suckless.org/sucks/systemd

Sicuramente non sto provando ad avviare una guerra di fiamma qui e in effetti lo uso come utente Debian, ma sinceramente sono d'accordo con uno sfigato.

AGGIORNAMENTO: Sento che dovrei spiegare perché sono d'accordo con succhiare. Quindi ecco qui: penso che sia troppo complesso e fornisca un controllo troppo "centralizzato" sul sistema. Dump core, registri, ecc. Sono memorizzati nel db journald. Che cosa succede se il mio fs fallisce e il db viene danneggiato - non ci sono più registri da guardare. Niente più file core da analizzare. L'archiviazione di file semplici offre naturalmente una migliore resilienza ai guasti in questi casi. Sono personalmente d'accordo praticamente con ogni punto dell'elenco senza succhiamento, ma lascio la risposta alla domanda principale a discrezione di tutti.


4
dovresti dire perché
mikeserv,

1
@mikeserv: ci sono molti "perché" nella pagina senza succhiare. :) e nella pagina di Wikipedia (citata nella risposta di Sparhawk). Penso che sia troppo complesso e fornisca un controllo troppo "centralizzato" sul sistema. Dump core, registri, ecc. Sono memorizzati nel db. Che cosa succede se il mio fs fallisce e il db viene danneggiato - non ci sono più registri da guardare. Niente più file core da analizzare. L'archiviazione di file semplici offre naturalmente una migliore resilienza ai guasti in questi casi. Quindi sì - PERCHÉ?!?
Alex,

coredumps e log possono essere scritti su riviste e / o syslog, console, altri, non sono in disaccordo che può essere complicato , ma non penso che si traduca direttamente in dannoso e non credo che questa risposta supporti tale traduzione.
Mikeserv,

1
@mikeserv: true. Tuttavia è o db journal o collo di bottiglia aggiuntivo nella registrazione del sistema (ora la registrazione dipende da journald AND da syslogd). Per quanto riguarda il punto dannoso: quello che ho detto dipende da ciò che consideri dannoso. Se un sistema impedisce la resilienza ai guasti, è davvero dannoso per me.
Alex,

1
Non dire questo è il caso specifico di systemd, ma una combinazione di sottosistemi indipendenti può effettivamente aumentare la resistenza ai guasti . Confronta un kernel monolitico con un kernel microarchitettura. Ignoriamo le prestazioni e diamo un'occhiata alla resistenza ai guasti. Che è più resistente ai guasti: una combinazione di componenti (potenzialmente di grandi dimensioni), che interagiscono tra loro attraverso interfacce ben definite; o un'enorme massa di codice in cui tutto è libero di colpire qualcosa per caso? Penso che si possa sostenere che, se eseguita correttamente, la scelta della microarchitettura è più resistente ai guasti.
un CVn

3

Non tanto malizioso quanto forse stupido.

I progettisti sono così pieni della propria visione che non riescono a comprendere le cose che rendono grandi i sistemi di tipo POSIX.

"Coloro che non capiscono Unix sono condannati a reinventarlo, male."

          Henry Spencer
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.