Intervista a Con Kolivas

[The_ouroboros]

If there is any one big problem with kernel development and Linux it is the complete disconnection of the development process from normal users. You know, the ones who constitute 99.9% of the Linux user base.

[FONTE: http://apcmag.com/6759/interview_with_con_kolivas_part_1_computing_is_boring ]


Cosi dice lo sviluppatore..

[tutmosi3]

Volevo proprio sentire cos'aveva da dire dopo qualche tempo dal suo "gran rifiuto".
Adesso passo alla traduzione.
Ciao

[W.S.]

nel link c'è una ] troppo attaccata ;)

PS: intervista molto interessante.

[VegetaSSJ5]

si può avere una traduzione?

[tutmosi3]

si può avere una traduzione?

Io ci sto provando ma le mia velocità è paragonabile a quella di un bradipo.

Ciao

[The_ouroboros]

up

[Braccop]

gia' letto tempo fa... in pratica dice che i developer del kernel se ne sbattono del mondo desktop mentre invece corrono dietro a quello enterprise... e che se non sei della cricca dei developer non ti considerano e ti trattano da noob.


edit: ecco, dopo che ho iniziato a tradurlo mi sono accorto che qualcuno ha gia' fatto il lavoro -.-'

http://opensource2007.netsons.org/2007/2007/07/26/intervista-a-con-kolivas-tradotta-spero-bene-in-italiano/

mo' ve ne traduco un po'... pian piano se ho tempo lo traduco tutto.

APC: Come hai iniziato a sviluppare per il kernel di Linux? ti e' piaciuto? che cosa ti ha motivato?

Normalmente questa domanda avrebbe una risposta diretta.
Ma attualmente ho avuto l'opportunita' di riflettere su cosa davvero mi ha portato allo sviluppo del kernel e quindi rispondero' in modo piu' completo.
Se mi date spazio per rispondere probabilmente finiro' a rispondere anche a tutte le vostre potenziali domande. Sara' il mio punto di vista sulla storia dei personal computer.

Ebbi il mio primo vero computer 24 anni fa. Sono stato abbastanza fortunato da essere coinvolto nel mondo dei computer poco dopo la sua nascita. In tutto questo tempo ho guardato l'intero sviluppo dei PC, inizialmente con eccitazione e senza sapere che direzione avrebbe preso, poi fremendo per conoscere dove sarebbe andato e che sviluppi avrebbe avuto.

I tardi anni '80 furono l'epoca d'oro per i computer. C'erano cosi' tanti produttori che entravano nel mercato ed ognuno offriva nuovi ed eccitanti design hardware, sistemi operativi con funzioni uniche e un'enorme scelta e competizione.
Sicuramente tutti condividevano molti design hardware e software ma la maggior parte sviluppava in competizione con gli altri.
E' quasi spaventoso ricordare che a quei tempi in Australia il leader dei computer in termini di vendite e diffusione fu l'Amiga per un certo periodo.

qui continua con la sua luuunga storia dei computer di cui penso che non freghi niente a nessuno e che tradurro' poi, forse

per gli altri interessati alla faccenda kernel ecco delle anticipazioni:


APC: Quindi, i problemi di performance di Linux in ambito desktop diventarono la tua principale motivazione?

Si. Ho iniziato a "smanettare" (passatemi il termine, non conosco traduzione migliore) migliorando Linux in ambito desktop.
"Sicuramente se avessi il pieno controllo su tutto il software sarei in grado di velocizzare il tutto", pensai. Ci deve essere un modo di modificare questo, aggiustare quello, ottimizzare quest'altro ed ottenere ulteriori incrementi di velocita'?
Le migliorie nello userspace mi sono sembrate molto limitate quando ho iniziato con Linux. A malapena lavorava al desktop meta' del tempo quindi cercare di spremere un po' di velocita' sarebbe significato non farlo funzionare del tutto.
L'eredita' di Unix era evidete. Stavamo plasmando un sistema operativo mai pensato per i desktop e sarebbe stato doloroso, molto doloroso.

Le uniche aree in cui notai miglioramenti furono quelle dello sviluppo del kernel. Niente erano mai grandi migliorie, ma causavano piccoli ma notabili miglioramenti in cose come reattivita', comportamento sotto carico eccetera.
La prima patchset che ho rilasciato al pubblico non conteneva codice mio ed era per il kernel 2.4.18 nel febbraio 2002 circa. Non sapevo nemmeno com'era fatto il codice C all'ora, non avendo mai ricevuto insegnamenti di informatica.

...



APC: Quindi, cosa feci per convincere gli sviluppatori del kernel della necessita' di maggiore attenzione agli utenti finali?

Mi inventai alcuni benchmark per provare a quantificare i problemi di performance di Linux sui desktop.
Il primo benchmark che ho creato si chiamava "Contest". Era orribilmente complicato da usare e impostare
e i risultati difficili da interpretare, ma almeno ci provai. Fu d'aiuto. Alcune modifiche che feci furono il risultato di questi benchmark, ma principalmente sul fronte I/O. Quindi dovevo ancora guardare quello scattoso CPU scheduler.

Avevo un po' di esperienza nel merge di patch da kernel precedenti e ironicamente la maggior parte di esse erano codice relativo allo scheduler CPU.
Nonostante non avessi mai imparato a programmare, guardando il codice iniziai a comprenderlo.

...



APC: Quale codice e' stato incorporato nel kernel mainline?

Guardando indietro, nonostante la patchset fosse ben conosciuta, poco del codice attuale e' finito nel kernel mainline. Anche se suscito' interesse e sviluppo da parte di altre persone ai tempi. Il piu' di quello che ci e' finito dentro sono modifiche allo scheduler CPU per migliorare l'interattivita', la fairness, SMP user fairness, hyperthreaded fairness e via dicendo.
C'erano un sacco di contributi in altre aree come il sistema di memoria virtuale, sospensione software, scheduling dell'i/o del disco e bugfix vari.

...



APC: Qual'e' il motivo che ti ha spinto ad appendere al chiodo lo sviluppo del kernel e la patchset -ck?

Questa e' una di quelle domande del tipo "Se avessi 10cent per ogni volta che mi hanno fatto questa domanda..."

Come molti sanno, il mio coinvolgimento nello sviluppo del kernel era motivato da 3 cose, che non hanno niente a che fare con la mia carriera full time e la mia vita.

Primo, era molto divertente. Sono sempre stato un fanatico dei computer e mi piaceva passarci ore davanti a fare... beh, qualsiasi cosa. Quindi passare il mio tempo su qualcosa che e' diventato per me una passione era ovviamente una fonte di gran soddisfazione.

Secondo, era una sfida intellettuale. Ci sono cose che ho sempre sperato fossero fatte nel kernel di Linux, e c'erano problemi a cui nessuno importava risolvere e via dicendo. Provando a confrontarli faccia a faccia stavo facendo qualcosa che non avevo mai fatto prima in termini di programmazione d'alto livello. Ho imparato davvero un sacco sui sistemi operativi e tutta la base dell'informatica, cose di cui molti studenti sono annoiati.

...



APC: c'e' stato qualcosa che ti ha dato il "colpo di grazia" ?

Il mio primo grande rifiuto fu lo scheduler Staircase originale. Era molto migliore in interattivita' dello scheduler mainline, ma alla fine come quest'ultimo aveva dei casi limite e cio' significava che non era perfetto. Mentre lo stavo ancora sviluppando, l'attenzione si sposto' dallo scheduler in quel periodo. La ragione data da Andrew Morton (mantainer e penultimo ostacolo per il kernel mainline) fu che il kernel aveva bug e problemi piu' scottanti da sistemare.

Certo che ne aveva. C'erano cosi' tanti sottosistemi che venivano continuamente riscritti che era un "rompimento" infinito. (rompimento nel senso di broken, cioe non funzionante)
E riscrivere sottosistemi funzionanti per poi "romperli" e' molto piu' importante di qualcosa che migliora l'ambito desktop eh? Oops, e qui e' sfuggita un po' della mia amarezza. Provero' a tenere le emozioni al di fuori e raccontare il resto della storia nel modo piu' oggettivo possibile.

Il problema principale era che non c'era un modo convincente di provare che Staircase era meglio in ambito desktop. I report degli utenti non erano abbastanza. Non c'erano benchmark. Non c'era modo di provare che era meglio, e i report degli utenti facevano solo arrabbiare ulteriormente i kernel mantainers per la loro mancanza di oggettivita'.
Ho anche provato a scrivere un benchmark chiamato Interbench. Notate che interattivita' non e' responsivita'
Era codice molto migliore di quello di Contest ma anche potendo dimostrare i vantaggi del mio scheduler su Interbench, era difficile quantificare le differenze basandosi sui numeri da esso generati.

...

[benti77]

carino il pezzo che ancora non hai postato relativo alla velocità dei pc e alla lentezza degli applicativi :)
moooolto significativo del tipo di sviluppo che le software house hanno deciso per il mondo dell'informatica... Basta pensare a msn che nell'ultima versione non gira sul vecchio portatile con un celeron 1400 :) e solo 256mega di ram, ma che mia sorella pretende ;)