Se osserviamo l'hardware moderno e la sua evoluzione negli ultimi anni, noteremo che a differenza di cosa succedeva 7/8 anni fa, le frequenze dei processori non stanno più aumentando. In parole povere, se una volta un nuovo processore era più veloce del precedente, oggi questo non è più vero (in senso stretto).
La tendenza oggi è di affiancare processori invariati dal punto di vista della velocità di calcolo, ma capaci di lavorare in parallelo. Questo ha portato all'arrivo sul mercato di sistemi dual core, quad core e via dicendo...
Ma da grandi poteri derivano grandi responsabilità! La responsabilità, in questo caso, è del software: è infatti sua la responsabilità (o meglio, di chi lo progetta e sviluppa) di sfruttare tutti i core che ha a disposizione. Questo, in sostanza, vuol dire che oggi progettare software reattivo significa soprattutto progettare software in grado di parallelizzare il lavoro: solo in questo modo più core potranno lavorare in parallelo e il nostro nuovissimo PC potrà sfruttare tutta la sua "putenza".
La tendenza oggi è di affiancare processori invariati dal punto di vista della velocità di calcolo, ma capaci di lavorare in parallelo. Questo ha portato all'arrivo sul mercato di sistemi dual core, quad core e via dicendo...
Ma da grandi poteri derivano grandi responsabilità! La responsabilità, in questo caso, è del software: è infatti sua la responsabilità (o meglio, di chi lo progetta e sviluppa) di sfruttare tutti i core che ha a disposizione. Questo, in sostanza, vuol dire che oggi progettare software reattivo significa soprattutto progettare software in grado di parallelizzare il lavoro: solo in questo modo più core potranno lavorare in parallelo e il nostro nuovissimo PC potrà sfruttare tutta la sua "putenza".
Come si ripercuote quindi tutto questo su noi utenti? L'esempio lampante e più attuale, a mio avviso, è l'arrivo di systemd.
systemd (la lettera minuscola non e' un errore :) ) è il nuovo gestore di avvio ideato da Lennart Pottering, che attualmente ha rimpiazzato initd su Fedora e che si prevede diventerà il nuovo standard anche per le altre distribuzioni.
La caratteristica principale di questo nuovo sistema, l'avrete intuito, è che fa ruotare tutto attorno alla parallelizzazione dei task di boot up, con lo scopo quindi di sfruttare al 100% l'architettura dei sistemi moderni.
Che siate quindi utenti di Fedora o no, molto probabilmente da qui a qualche tempo dovrete averci a che fare. Nel seguito quindi, vorrei riassumere alcuni dei comandi principali che potete/potrete utilizzare per gestire i demoni del Pinguino.
systemd (la lettera minuscola non e' un errore :) ) è il nuovo gestore di avvio ideato da Lennart Pottering, che attualmente ha rimpiazzato initd su Fedora e che si prevede diventerà il nuovo standard anche per le altre distribuzioni.
La caratteristica principale di questo nuovo sistema, l'avrete intuito, è che fa ruotare tutto attorno alla parallelizzazione dei task di boot up, con lo scopo quindi di sfruttare al 100% l'architettura dei sistemi moderni.
Che siate quindi utenti di Fedora o no, molto probabilmente da qui a qualche tempo dovrete averci a che fare. Nel seguito quindi, vorrei riassumere alcuni dei comandi principali che potete/potrete utilizzare per gestire i demoni del Pinguino.
Il comando principale per gestire systemd è systemctl. Da bash:
systemctlSenza nessun parametro otterremo l'elenco di tutti i demoni controllati da systemd ed il relativo stato.
Se ci interessa lo stato di un servizio in particolare, ad esempio sshd:
systemctl status sshd.servicePer abilitare (o disabilitare) un servizio, possiamo usare il comando enable (o disable):
systemctl enable sshd.serviceMentre per avviarlo (o fermarlo) possiamo utilizzare il comando start (o stop):
systemctl start sshd.servicePossiamo interrogare lo stato (avviato o no) di un servizio anche usando il comando:
echo $( systemctl is-enabled sshd.service )Questi sono solo alcuni esempi ovviamente, maggiori informazioni sono disponibili sulla pagina dedicata:
http://www.freedesktop.org/wiki/Software/systemd
Una funzionalità a mio avviso utile, in particolare, è quella di analisi dei tempi di boot.
Proviamo ad usare i comandi:
systemd-analyzeE
systemd-analyze blame
Otterremo un prospetto chiaro e preciso di cosa è successo mentre la simpatica splashscreen della nostra distro ci intratteneva con la sua incomparabile bellezza ed utilità, e potremo capire ad esempio, chi è responsabile di eventuali rallentamenti.
Concludo con una piccola osservazione personale: ritengo questo il genere di progetti che, anche se fanno meno scalpore della nuovissima luccicosissima interfaccia grafica, danno valore aggiunto ad una distribuzione e portano miglioramenti tangibili ad un sistema.
