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 -- Per REVOCARE l'iscrizione alla lista, inviare un email a [email protected] con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a [email protected] To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
