Ogni giorno i nostri computer diventano una parte sempre più importante delle nostre vite; se hanno un qualsiasi problema, questo influisce sul nostro umore, sul nostro umorismo, ahah. Certo, gli utenti Windows sono più inclini agli attacchi di panico: virus ( lunga vita a Linux! ), deframmentazione dell'HDD, ricerca e installazione di Clean Master per PC ( anche se qui in Linux abbiamo bisogno di pulire il sistema; BleachBit è una delle alternative preferite ). Recentemente, alcuni utenti Linux hanno avuto un certo mal di testa chiamato systemd.
Comunque, per venire al dunque, ho letto un interessante articolo su systemd , che sembra essere molto in voga ultimamente.
Systemd , che alcuni considerano ( e userò le parole di un amico ) "l'anello che li domina tutti "... per altri, invece, è semplicemente indifferente; finché il computer funziona correttamente, non importa se init fa X o Y, o se si usa systemd. Quanto a me, beh... diciamo solo che preferisco init; lo trovo più semplice.
Lascio l'articolo qui:
Prima di iniziare, devo dire che non apprezzo affatto la decisione di cambiare le cose in Debian, ma non ho alcuna intenzione di abbandonare il mio amato sistema a spirale. Voglio semplicemente assicurarmi che, se dobbiamo discutere di un argomento, lo facciamo il più preparati possibile, anche se io stesso non mi considero un sostenitore di systemd. Per fare chiarezza su systemd, mi affiderò a un sito web dove gli sviluppatori condividono le loro opinioni , che mi è stato segnalato da un collega che sembra essere a favore di systemd, pur non essendo un utente Debian. Detto questo, credo di poter procedere cercando di fare chiarezza su ciò che si dice riguardo a 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 si compila systemd con tutte le opzioni di configurazione abilitate, si otterranno 69 singoli file binari . Questi file binari svolgono compiti diversi e sono accuratamente separati per una serie di motivi. Ad esempio, systemd è stato progettato pensando alla sicurezza; pertanto, la maggior parte dei daemon viene eseguita con privilegi minimi (utilizzando, ad esempio, le funzionalità del kernel) ed è responsabile solo di compiti molto specifici, minimizzando la loro superficie di sicurezza e il loro impatto. Inoltre, systemd parallelizza l'avvio più di qualsiasi soluzione precedente. Questa "parallelizzazione" viene creata eseguendo più processi in parallelo. È quindi chiaro che systemd è ben suddiviso in molti file binari e, di conseguenza, processi. In effetti, molti di questi file binari sono così ben separati da risultare molto utili anche al di fuori di systemd.
Un pacchetto contenente 69 singoli file binari difficilmente potrebbe essere definito monolitico. Ciò che lo differenzia dalle soluzioni precedenti, tuttavia, è che distribuiamo più componenti in un unico archivio tarball e li manteniamo raggruppati 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 è completamente falso. Semplicemente non li usiamo per il processo di avvio perché crediamo che non siano lo strumento migliore per quello specifico scopo, ma ciò non significa che systemd fosse incompatibile con essi. È possibile eseguire facilmente script di shell come servizi o daemon di systemd; è possibile eseguire script scritti in qualsiasi linguaggio come servizi di systemd poiché a systemd non importa minimamente cosa ci sia all'interno dell'eseguibile. Inoltre, utilizziamo ampiamente script di shell per i nostri scopi: per installare, compilare e testare systemd. E si possono incollare gli script nel processo di avvio iniziale, usarli per i servizi normali, eseguirli nello spegnimento finale: non ci sono praticamente limiti.
A questo punto, suppongo che alcuni dei principali presupposti siano stati chiariti. Sebbene non mi consideri un sostenitore del cambiamento e nutra qualche riserva sull'idea di " un unico demone che li domina tutti ", credo che alla fine nessuno oserà affermare che non funzioni affatto. Conosco persino alcuni utenti che notano che con systemd "il PC è più veloce", ma questo è un altro discorso. Per ora, posso solo invitarvi a discutere qui i vostri punti di vista sul sistema di init adottato da molte distribuzioni, anche se le reazioni più forti si stanno attualmente registrando all'interno della comunità Debian, che ha persino dato vita a un nuovo fork proprio a causa di tutto ciò. Che vi piaccia o no è una questione personale; da parte mia, voglio solo dare il mio contributo per demistificare systemd, che sarà infine presente in Jessie, la prossima versione stabile di Debian.
Ho visto l'articolo su GUTL (che a sua volta era tratto da DesdeAbreus )
Systemd attuale?
Io sono uno di quelli che non legge molte notizie quando qualcosa genera tante polemiche, preferisco restare su dettagli più tecnici. Il fatto è…. A volte ho la sensazione che alcuni argomenti smettano di essere una discussione o un dibattito puramente tecnico, e diventino come uno di quei pettegolezzi del mondo dello spettacolo
Innanzitutto, uno sfogo pubblico di un utente su systemd intitolato systemd VS intelligence , poi Linus Torvalds che afferma che systemd non è così male come si pensa ( e in effetti ha ragione ), un fork chiamato uselessd ... nessun commento... e per farla breve, infine Devuan.
Non dirò se è così male come dicono, meno male o peggio. Il sistema funziona bene per me, tuttavia, personalmente preferirei init, perché mi piace il suo modo di organizzare le varie cose (come i log, per esempio). Ma ehi, se systemd deve essere chiamato cavallo da corsa e deve sostituire init ( che sarebbe il nostro cavallo da lavoro, che fa tutto ma lentamente? ), beh... finché il cambiamento non è troppo drastico, gli utenti possono adattarsi senza troppi problemi e il sistema funziona meglio (sì, meglio, forse non mi basterà!), allora benvenuto! 😉