Re: Debian e SystemD
Alessandro Baggi writes:
> Salve ragazzi,
> da un po di tempo sembra che SystemD si stia diffondendo molto
> velocemente e molti sembrano trattarlo come una specie di malattia.
Non hanno tutti tutti i torti.
> Leggendo in rete, lo si ritiene molto buono per i desktop/workstation ma
> meno buono per server e amici ma non avendo esperienze systemD non
> riesco ad esprimere un giudizio.
Systemd ha una ragione di esistere serissima ed una seria.
Quella serissima è che oramai il problema delle dipendenze al boot è
difficile da gestire. Debian ha un sistema di controllo che per carità
funziona ma non è il massimo della maneggevolezza e comunque ha ancora
qualche pecca e mancanza (i.e. puoi dire che il processo X parte dopo
quello W, ma non che deve essere presente un qualcosa creato da W).
Quella seria è che il kernel ha una architettura ben diversa dai kernel
per cui era nato init. Per carità, con init funziona egregiamente, ma
ci sono situazioni in cui più dinamicità può servire.
E qui nasce la distinzione desktop/server: una macchina desktop, e più
ancora un portatile, si trovano a operare in "condizioni ambientali
diverse" ad ogni boot (cambio di rete, di device collegati...). Un
server con quella configurazione nasce e spesso con quella configura-
zione muore. Non ha alcuno di questi problemi di dinamicità. Anzi, un
server in teoria, fa un boot quando lo installi ed uno shutdown quando
lo dismetti, ogni altro reboot è sintomo di un 'evento traumatico'. Il
tempo di boot diventa molto meno importante rispetto ad un desktop che
viene spento spessissimo.
> Oltre alla parallelizzazione e la diminuzione del tempo di avvio di una
> macchina, quali altri vantaggi porta?
Ad esempio, alcuni servizi legati alla presenza di HW rimovibile
partiranno (e automaticamente) solo in presenza di questo HW. Ottenere
questo con l'attuale sistema è laborioso.
> Si parla anche di minor controllo e di difficoltà nel debug in caso di
> errori durante l'avvio, con il rischio di tenere la macchina down per
> più tempo prima di capire da cosa è causato il problema.
SICURAMENTE il debug di un contesto parallelo è più arduo di quello
sequenziale, e questo può essere un problema non da poco nelle
situazioni in produzione in cui occorre intervenire sul processo di
boot in una maniera che non è quella dello rc-local.
Non è il solo dei problemi che può portare.
In fase di migrazione è molto probabile che cambino i nomi di alcuni
device, ad esempio i nomi dei device di rete.
Ora per un utente comune la cosa può risultare assolutamente
ininfluente, il sistema sarà correttamente configurato.
Ma non è improbabile che utenti smaliziati ed in situazioni di
produzione ci siano tutta una serie di script e di configurazioni dove
il nome dei device è importante. A me, semplice sistemista a tempo
(altrui) perso, vengono in mente i bridge ed altre configurazioni
'strane' sulle schede di rete (vedi su Wikipedia la pagina in inglese
http://en.wikipedia.org/wiki/Link_aggregation, quella in italiano è al
momento lassativa).
Lo devi fare una volta per tutte, è vero. Ma un mio collega
certificato RH, quando ci siamo rivisti ha avuto il tono "mo' la rogna
tocca pure a voi!".
> Mi chiedo se è accettabile un tale rischio/perdita per ottenere una
> diminuzione dei tempi di avvio di un sistema.
Vogliono portare GNU/Linux sui server e per far questo copiano Windows
(di sicuro) e forse pure Mac OS X. Ma Windows di sicuro.
Signori, Windows ha fatto fortuna sui desktop perché non c'è stato
altro per gli utenti comuni e gli utonti. Adesso perde colpi, perché
c'è altro. Peccato che spesso l'altro si chiami Mac OS X e non
GNU/Linux.
Peraltro al boot capita che ci siano un tot di servizi che hanno tempi
biblici di avviamento. Da me c'era sendmail - installato da nagios. In
un contesto sequenziale sendmail ti tiene fermo, in un contesto
parallelizzato intanto fai partire anche altro. Stesso discorso per
NTP se non hai la rete (e NTP è tanto comodo per avere un orologio ben
regolato).
Altri ritardi non li eviti. Se hai un bridge (che ci mette fino a 20
secondi a venire su) tutto quello che dipende dalla rete rimane in coda.
E poi un paio di considerazioni sulla parallelizzazione.
La prima è che mi pare systemd ricalcoli ogni volta il sort topologico
del grafo. Può essere utile sui laptop, ma all'utente potrebbe venire
voglia di dirgli "salvati il risultato e non fare più il conto". È
sempre tempo risparmiato.
La seconda è che bisogna stare attenti col parallelismo e non
richiederne di più di quello che l'hw ti permette: se sulla tua
macchina i binari di sistema sono su un disco allo stato solido, non
ci sono problemi, puoi saltare da una parte all'altra del "disco" e il
tempo di accesso rimane costante.
Se invece hai dei dischi tradizionali, troppi salti possono far
diventare insopportabile la somma di tempi di seek e di rotazione
causando il cosiddetto trashing.
> Inoltre nella prossima release di Debian, verrà utilizzato come sistema
> di default?
Temo di si. Sperando che ci siano alternative.
> Quindi, alla fine, cosa ne pensate di SystemD (lato server, lato desktop)?
È la risposta sbagliata a problemi veri.
--
/\ ___ Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____ African word
//--\| | \| | Integralista GNUslamico meaning "I can
\/ coltivatore diretto di software not install
già sistemista a tempo (altrui) perso... Debian"
Warning: gnome-config-daemon considered more dangerous than GOTO
Reply to: