Andrea Arcangeli, imolese, classe 1976, lavora per SuSe in Germania ed è uno dei principali sviluppatori del Kernel di Linux. All'interno del team di sviluppo, Arcangeli si occupa della gestione della memoria e dei sistem di I/O. Proprio recentemente, all'altezza del kernel 2.4.10, Linus Torvalds ha accettato di inserire nel nuovo kernel l'algoritmo per la gestione della memoria virtuale proposto da Arcangeli, preferendolo a quello di Rik Van Riel, adottato nel kernel di Alan Cox, "vice" dello stesso Linus.
Con lui parliamo delle recenti implementazioni del Kernel e dei futuri sviluppi.
Dopo i grandi passi in avanti fatti dal kernel 2.2 al kernel 2.4 finalmente è arrivata anche un'eccellente implementazione gestione della Virtual Memory. Alcuni però hanno storto il naso a un cambiamento così radicale da una minor release all'altra. Come mai si è deciso di sostituire la gestione della VM esistente? Non è stata forse una mossa un pò troppo azzardata?
Non è un caso il fatto che mi sia applicato per scrivere un più predicibile algoritmo di memoria virtuale a 2.4 avanzato e che tale algoritmo sia stato poi incluso e migliorato così rapidamente nel kernel ufficiale. Se è accaduto è perché anche altri core developers hanno riconosciuto che tale mossa apparentemente azzardata era necessaria. Il precedente algoritmo non era predicibile, generava numeri non ripetibili nei benchmark (di solito rallentava con l'andare del tempo) e, in alcuni casi, si comportava in modo bizzarro dopo giorni di utilizzo sotto intensivo carico di memoria virtuale (come con stormi di swapout). Un altro esempio è il fatto che kswapd poteva impazzire ed entrare in un loop infinito, rallentando il sistema.
Non si poteva utilizzare meglio la gestione della VM fatta da Rik Van Riel, adottando quella del kernel ac anche nel kernel ufficiale?
Alcuni dei problemi dell'algoritmo precendente erano problemi di design, non fissabili con la modifica di una paio di linee di codice. Di conseguenza non mi è stato possibile limitarmi a delle modifiche ristrette per raggiungere l'obbiettivo.
Ora che Alan Cox ha annunciato che utilizzerà anche nel suo kernel la tua gestione della VM, sembra essersi appianata ogni divergenza. La situazione che si era venuta a creare però poteva portare dei vantaggi: due kernel non più sostanzialmente simili potevano portare a sviluppi paralleli dai quali poi si poteva scegliere quanto di meglio dall'uno o dall'altro. Cosa ne pensi?
Personalmente (dal punto di vista della evoluzione del codice) ho trovato molto utile il fatto che Alan mantenesse la precedente VM, perché così facendo ha reso molto più semplice ottenere paragoni tra i due algoritmi. Certamente riconosco che la competizione sia molto utile per risvegliare interesse per l'innovazione. D'altra parte la comptetizione implica frammentazione delle capacità di testing dell'userbase, quindi è positivo che long term si converga tutti nella stessa più promettente direzione.
Ultimamente le release del kernel (mi riferisco in particolare al 2.4.11) hanno avuto dei problemi. Cosa è successo?
Sul 2.4.11 c'è stata evidentemente una svista dell'ultimo minuto: l'ultima 2.4.11-pre ha incluso un errato bugfix per un denial of service su symlink ricorsivi che, a causa dell'errore, poteva destabilizzare il sistema fino a corrompere il filesystem. Ho perso parecchie ore a causa di tale incoveniente; all'inizio credevo fosse una delle mie modifiche ad aver introdotto il problema poi, quando mi sono convinto che il problema non si trovava nella VM, ho dato una occhiata su linux-kernel ed ho trovato subito il fix. Il 2.4.12 è stato rilasciato dopo poche ore... Sono cose che capitano saltuariamente. Nella serie 2.2 era capitato lo stesso con il 2.2.8. Basta comparare le date di rilascio del 2.2.8 e 2.2.9 con quelle del 2.4.11 e 2.4.12 per notare la similarità; la principale differenza è che con il 2.2.8 l'userbase era molto minore e di conseguenza tale svista era meno conosciuta :).
Qualcuno ultimamente ha lamentato un calo di stabilità del kernel Linux rispetto al 2.2 e 2.0 . Sui server sono tanti quelli che utilizzano ancora il 2.2 . E l'uscita del 2.2.20 dimostra che l'interesse per questo ramo è ancora attivo. Forse la mancanza di un kernel di sviluppo porta a inserire soluzioni un pò troppo azzardate in una versione stabile? Cosa pensi a riguardo? Quali possono essere i motivi di questo (riscontrato da alcuni) calo di stabilità effettiva?
Il 2.2 è veramente stabile dal 2.2.19, le precendenti versioni hanno sempre avuto dei problemi nell' utilizzo server con workload molto intensi. Perfino il 2.2.20 ha ancora una irq race condition nella VM che ho fissato qualche settimana fa nel 2.2.20aa1 [putroppo solo pochi giorni dopo dal rilascio del 2.2.20, ma sarà certamente inclusa nei prossimi 2.2.21pre].
A mio parere, il principale motivo per cui è stata effettuate la "mossa azzardata" sulla VM del 2.4 ufficiale è proprio per riuscire a rimpiazzare il 2.2 sui server mission critical senza aspettarsi reazioni strane. Non posso assicurare che abbiamo ancora raggiunto la totale stabilità per tutti gli utenti, per esempio ho ancora un report da parte di google abbastanza serio su cui sto lavorando in questi giorni. Tale report, tuttavia, coinvolge solo macchine che si aggirano sui 4G di ram e lo stesso problema è riproducibile con la precedente VM quindi, perlomeno, non è una regression. Credo che ora siamo finalmente sulla strada giusta per riuscire a coprire anche questi casi "speciali" su macchine very high end. E' difficile effettuare migliorie quando le fondamenta non sono stabili e, a mio parere, ora le fondamenta sono stabili.
Tra poco si passerà allo sviluppo del kernel 2.5 . Perchè si è tardato tanto a creare una versione di sviluppo?
Probabilmente Linus ha preferito aspettare di essere completamente soddisfatto del kernel a livello di design generale, prima di lasciarlo in mano ad Alan.
Cosa state preparando per il kernel 2.5 e il 2.6?
Ci sono svariate patch in cantiere, a partire da block-highmem, supporto pci64 nel lowlevel drivers, async-IO, API comune per le ACL, supporto per pagetables di 4M, merging del tree x86-64, kernel preemptive, tecniche RCU, multiqueue scheduler, merging di altri filesystem journaling, RT-signal-per-fd, ornament in rimpiazzo di ptrace, e svariate altre tecnologie su cui si sta lavorando.
Personalmente ho alcune idee su possibili altri progetti, ma preferisco fare qualche esperimento per verificarne la validità prima di parlarne :).
Cosa ne pensi della decisione di non riportare nel CHANGELOG del 2.2.20pre11 le modifiche i fix di sicurezza?
La DMCA è stata chiaramente creata per proteggere i guadagni delle multinazionali statunitensi dalla trasformazione di DVD in divx e per problemi similari. Per gli stessi motivi abbiamo leggi similari in Italia per quanto riguarda il decrypt delle reti televisive satellitari. Con tali leggi le industrie cercano di proteggersi dalle perdite che potrebbero subire se tali software potessero venire legalmente distribuiti. A mio parere, Alan cerca di sensibilizzare l'opinione pubblica su tali leggi quando queste vanno ad influenzare la ricerca e l' evoluzione della sicurezza informatica. Non sta a me giudicare se tali leggi siano giuste o sbagliate, ma posso dire che ho notato la loro infuenza negli ultimi mesi, a partire da Dug Song http://www.monkey.org/~dugsong/, programmatore OpenBSD, OpenSSH, autore di Dsniff e di numerose pubblicazioni sulla sicurezza (probabilmente è l'esempio più similare alla problematica dei changelog sul kernel di linux). Basta guardare la sua homepage per capire. Al contrario, gli altri casi più eclatanti di cui sono a conoscenza, avevano in qualche modo a che fare con i guadagni dei colossi industriali.
I tragici avvenimenti in USA, le recenti disposizioni antiterrorismo, le possibili limitazioni nell'uso della crittografia, pensi che il software libero ne possa risentire? In altre parole, temi che possa essere vittima di qualche restrizione?
No, in pratica non lo temo. Moltissimi enti statali statunitensi (dalla NASA al Los Alamos National Laboratory, alla National Security Agency, quindi all'esercito degli Stati Uniti) utilizzano Linux. La NSA ha addirittura rilasciato pubblicamente la sua versione di Linux con migliorie nel campo della sicurezza ed era presente un developer della NSA anche all'ultimo meeting mondiale sul kernel developement, a cui ho partecipato qualche mese fa a San Jose. Sarebbe quindi una contraddizione se il governo degli Stati Uniti si mettesse contro Linux, dal momento che è uno dei primi utenti di Linux e che, con le tasse che pagano gli americani (Microsoft inclusa), contribuisce anche al suo sviluppo. Anche il lato "crittografia" sembra migliorato ultimamente; recentemente è diventato finalmente possibile distribuire netscape con crittografia a 128bit e openssh anche sulle distribuzioni indirizzate agli Stati Uniti, per esempio.
È, però, preoccupante che si mettano in posizione scomode developers open source come capita, per esempio, con i changelogs del kernel relativi a fix di sicurezza e condivido Alan nel prendere le leggi alla lettera in questo senso.
Cosa pensi del gran numero di distribuzioni Linux? Non c'è il rischio di creare confusione e incertezza nell'utente che vuole avvicinarsi a Linux?
Le sole reali opzioni per distribuzioni da utilizzare in production si contano sulla punta delle dita. Se possibile, l'ideale sarebbe di provare tutte quelle importanti, per notare bene le differenze.
Esiste anche l'LSB (Linux Standard Base), ente che detta alcune regole di standardizzazione, che permette di rendere l'environment Linux più standard, indipendentemente dalla distribuzione utilizzata, proprio per cercare di evitare confusione.
Quale è il ruolo che hanno le distribuzioni (sia quelle commerciali che quelle curate da volontari come Debian) nello sviluppo di Linux?
Lo sviluppo e l'evoluzione di Linux sono largamente sostenuti dalle distribuzioni commerciali, da altri enti commerciali (sia startups che colossi informatici) e da alcuni enti di ricerca statali di molto alto livello che usano linux per i loro progetti. Anche alcuni volontari Debian lavorano su Debian, in qualche modo pagati per farlo da enti commerciali.
Il ruolo delle distribuzioni (commerciali e non) è quindi fondamentale, e non è solo un ruolo di developement e di innovazione, ma anche di coordinazione con tutte le altre tessere del mosaico linux.
Secondo te quali passi sono necessari per far sì che Linux sfondi anche nel mercato desktop? Quando potr? avvenire tutto questo?
KDE2, a mio parere, dal punto di vista teorico ha già sfondato la barriera desktop, perlomeno sul lato internet e multimedia; grazie principalmente ad una sana gestione dei font true type con antialiasing e un browser integrato con supporto flash, javascript e ssl. Anche il supporto opengl (per i videogames/screensaver e la grafica 3d in generale) sembra molto efficiente sulle schede accellerate.
Ma dal punto di vista pratico per raggiungere la massa critica di utenza ci vorrebbe una marcia in più di Windows sul lato Office. Per ora StarOffice per Linux è buono e sufficientemente standard, e anche il koffice è molto promettente; tuttavia tali soluzioni office non sono esattamente un "Microsoft Office per Linux" e il loro userbase non è ancora molto elevato. La Microsoft attualmetne è ancora in tempo a rilasciare un "Microsoft Office per Linux" e a rallentare notevolmente l'interesse degli utenti per koffice. Se posso azzardarmi in una previsione lo farà, ma quando sarà troppo tardi.
Linus ha detto che non sarà più lui il mantainer del kernel 2.4, e Alan seguirà lo sviluppo del kernel 2.5. Quanto pesa lo sviluppo del kernel nella vostra vita e nel vostro lavoro?
Non ho mai mantenuto personalmente un kernel ufficiale; solo Alan e Linus lo hanno fatto fino ad ora ma, sicuramente, lo sviluppo del kernel anche da parte mia implica molte responsabilità e tempo. Tuttavia se siete appassionati dalla tecnologia e dall'innovazione come me, non c'è nulla di più divertente e di innovativo di Linux :).
