Sembra che dopo tutto non sia il solito caso di "Che vuoi che ne sappiamo noi di un sistema operativo usato si e no da un utente su cento": nel forum delle Pagine Gialle c'è chi si lamenta che non funziona neanche con Windows...
A questo punto la domanda diventa: ma visto che la prima beta di Flash 10 era uscita a maggio, è possibile che alla SEAT in cinque mesi non se ne sia accorto nessuno?
PackageKit mi avverte che c'è un aggiornamento - controllo di cosa si tratta - ah! - è uscito Flash 10 per Linux - ma pensa te, stavolta si sono degnati di farlo uscire assieme alla versione Windows e Mac - via installo - peggio del vecchio non può essere - oppure si?
Ritorno sull'argomento boot con un po' di ritardo, anche per fare in modo che l'articolo di LWN che ne parla sia accessibile a tutti (appena usciti sono riservati agli abbonati).
Per prima cosa, un chiarimento doveroso: a meno di "miracoli", è improbabile che i nostri laptop riusciranno a fare un boot in 5 secondi (e neanche in 10...) troppo presto; le modifiche apportate ai vari componenti del sistema lo hanno reso un Eee-PC da Formula 1, e come (purtroppo) sappiamo, non tutte le meraviglie che si trovano nelle monoposto da F1 sono trasportabili nelle macchine di serie.
Detto questo, vediamo alcuni dettagli. Per iniziare, gli sviluppatori hanno investigato i tempi di boot del sistema con diverse distribuzioni, utilizzando il tool Bootchart.
La prima scoperta è che i tempi originali, per la cronaca intorno ai 45-50 secondi, sono appesantiti da voci quantomeno "curiose": as esempio, Fedora spende due secondi per far partire sendmail e altri 5(!!!) per il demone setroubleshootd. Ubuntu non è da meno, bruciando 2.5 secondi di sola CPU per mostrare l'immagine di sfondo per GDM e altrettanti per caricare il tool di gestione dei driver proprietari.
In ogni modo è chiaro che anche risolvendo questi problemi il target dei 5 secondi è inarrivabile senza un approccio radicalmente diverso. L'idea è stata quella di invertire l'approccio, assegnando a priori un "budget" ad ogni componente del boot e lavorando poi sulle componenti per rientrare in quanto stabilito.
La ripartizione è: un secondo per caricare kernel, un altro secondo per gli script di init, un secondo per X e due per l'ambiente desktop.
Per raggiungere tale risultato le principali modifiche hanno interessato:
kernel, compilando i driver necessari non come modulo
kernel, patch per l'inizializzazione asincrona di alcuni sottosistemi
kernel, salvataggio della lista dei blocchi letti al boot (per sReadAhead)
sReadAhead, che permette di creare una cache dei dati letti al boot da usare nei successivi
Per la cronaca sReadAhead è già in review e speriamo entri presto in Fedora, per le patch del kernel pare che dovremo aspettare la 2.6.28 (a meno che i maintainer del kernel non decidano di includere la patch nell'RPM).
