Costruire una distribuzione, Parte 11. Nascita della distribuzione Gentoo Linux Per ogni fanatico di Linux c'è un momento in cui questo diventa molto di più che un semplice nome e si rivela come la cosa più bella, potente e stimolante che qualsiasi sviluppatore abbia mai incontrato. La mia folgorazione avvenne mentre lavoravo presso l'Università del New Mexico come amministratore di sistema. Il nostro server NT stava funzionando abbastanza bene e quindi avevo molto tempo libero. Cosi installai Debian su un server dotato di un Pentium 166 ed iniziai ad imparare ... e imparare e imparare. E da allora fui rapito. Per prima cosa imparai le cose fondamentali: come guardarsi intorno, fare un backup, far funzionare Samba, etc. Dopo di che ho fatto il set up di qmail e Apache, imparai python e la programmazione di shell, quindi realizzai una intranet dipartimentale. Mi installai Linux a casa ed iniziai a provare più distribuzioni diverse. Alla fine ho optato per Stampede Linux. Sappiamo tutti come vanno le cose: all'inizio si lotta per apprendere i principi fondamentali di Linux non appena, però si ha una conoscenza decente, si personalizza la propria distribuzione e si continua ad imparare mentre si procede. Poichè Linux non ha nulla da nascondere, è possibile esplorare la tecnologia ed i tools che lo rendono unico mentre si accresce la propria abilità. La forza di Linux risiede nelle potenzialità che offre Linux offre delle cose che non avevo mai visto prima. Se dovessi mettere quel magico qualcosa nelle parole, lo chiamerei potenziale: il potenziale per cambiare, per migliorare, per riparare le cose, e si, persino per romperle. Ogni volta che aggiornavo la versione del kernel vedevo migliorare Linux davanti ai miei occhi e trasformarsi quasi quotidianamente. Io ero avanti nella corsa! Ero parte della trasformazione. Ero divertito. Se sei come me, prima di aver conosciuto Linux e il software libero avrai sicuramente visto quelle grandi compagnie di Redmond e Cupertino fornire dei sistemi operativi, di ultima generazione, che finalmente lavoravano esattamente come vuoi te. Quel sogno però non si è mai trasformato in realtà e mentre stavamo aspettando, Linux si è fatto avanti. Sebbene all'inizio avesse contorni poco definiti ha dato a noi hacker, uomini e donne, qualche cosa su cui lavorare mentre rimanevamo in attesa del prossimo grande passo. Poi un giorno ci siamo svegliati e ci siamo accorti che il prossimo grande passo era proprio Linux e sorridendo abbiamo continuato a lavorare sul codice. La forza di Linux risede nelle persone Come passo successivo ho imparato che cosa era Linux per la gente. Non è rinfrescante? Linux non è solo un mucchio di codice sorgente, ma è una comunità. Possiamo, quindi, contare su questa comunità per ottenere le nostre risposte, e diventiamo parte di questa comunità quando iniziamo ad aiutare gli altri contribuendo con il nostro tempo e la nostra esperienza. IRC (Internet relay chat) è un bel posto dove incontrare gente e sprecare un bel mucchio di tempo. Il canale #stampede su irc.openprojects.net è diventato il mio ritrovo ufficiale. E' il posto dove ho fatto le mie domande su Linux e dove ho iniziato ad aiutare altre persone. #stampede necessitava disperatamente di utenti Linux esperti per aiutare i neofiti che avevano appena installato la distribuzione. Come spesso accade in IRC molte delle persone esperte in Stampede avevano perso il loro zelo nel rispondere alle domande di un (ulteriore) neofita. Ero cosi eccitato dal fatto che conoscessi le risposte alle domande dei principianti che non potei desistere dall'aiutarli! E fu cosi che iniziò il mio coinvolgimento con Stampede. Ero solo un'altra persona a cui piaceva rispondere alle domande. Naturalmente il mio intento non era del tutto altruistico visto che aiutavo anche me stesso a diventare un esperto di Linux attraverso l'esperienza che le persone più esperte del canale (per non citare gli sviluppatori stessi di Stampede) hanno potuto offrire. Quando la gente mi chiede come possa essere stato coinvolto in un progetto open source, dico loro di trovare un posto in cui possano risultare utili, anche se solo con domande basilari su Linux. Un sincero desiderio di aiutare gli alri è un buon biglietto da visita nella comunità Linux, visto che questo sentimento è il cuore di tutto lo sviluppo open source (incluso Linux quindi), o almeno così dovrebbe essere. Durante il proprio cammino è inevitabile incorrere in persone che ne sanno più di noi, allora impariamo da loro proprio come un neofita continua ad imparare da noi. Poichè è probabile che si acquisisca sempre più esperienza è altresi probabile che avremo maggiori opportunitià per offrire il nostro aiuto in nuove situazioni. Forse alcuni sviluppatori di progetti avranno da suggerire qualcosa, oppure chiederanno a loro volta aiuto. Potrebbero anche invitarti a far parte di un team di sviluppo. Se il tuo obiettivo principale è aiutare gli altri, sarebbero sciocchi ad allontanarti da li. Se hai aiutato molte persone allora sarai sicuramente notato dalla comunità e ciò è proprio quello che è successo tra Stampede e me. Gradualmente ho iniziato ad essere sempre più coinvolto nello sviluppo di Stampede. In breve tempo diventai uno sviluppatore ufficiale. Con la benedizione di skibum (Matt Wood, capo di Stampede honcho) ho iniziato a lavorare ad una nuova versione del formato primitivo dei pacchetti .slp. A quel tempo il formato .slp era formato da un archivio .tar.bz2 con una parte finale di lunghezza fissa in coda che conteneva informazioni sull'autore del pacchetto, una descrizione dei contenuti, il creatore del pacchetto ecc. Questo approccio aveva principalmente due problemi: i campi erano di lunghezza fissa e la parte finale non era poi cosi grande, inoltre non c'era flessibilità nel formato (ovvero non era possibile aggiungere campi addizionali al formato .slp in futuro). Ovviamente cio' ha richiesto una revisione importante. Lavorando insieme agli sviluppatori senior di Stampede ho scritto una proposta su come eliminare tali problemi. Dopo di che ho iniziato a codificare il prototipo del tool in Pyton. Il nuovo formato (che aveva nome in codice slpv6) era piuttosto simile al formato di file IFF del mondo Amiga. Questa nuova generazione del formato .slp forniva 2 32 campi, 2 32 categorie di campi e una lunghezza massima del campo dati di 2 32 bytes. Non solo il formato era molto flessibile, ma era anche piu' compatto del plain-text e facile da analizzare. Il formato poteva memorizzare sia i dati in formato testo che dati binari, il che offriva maggiori possibilità per il futuro. L'idea era quella di porre questa nuova generazione di header dinamico alla fine del file di archivio producendo quindi una nuova generazione di formato .slp che avrebbe servito gli utenti Stampede per gli anni a venire e allo stesso tempo avrebbe mantenuto la compatibilità con lo standard UNIX per i formati di archivio. Le persone possono risultare sgradevoli Lo sviluppo di slpv6 era iniziato bene e tutti gli sviluppatori senior erano felici dei miei progressi. Sfortunatamente, però, due sviluppatori Stampede lower-level desideravano controllare il progetto slpv6. Loro non gradirono la direzione che avevo preso e persero molto del loro tempo a denigrare il sistema. Benchè passassi ore in discussioni di sviluppo infuocate difendendo la mia proposta contro i loro attacchi non fummo in grado di risolvere niente. Naturalmente ben presto fu chiaro che erano in polemica con me e che non sarebbero stati contenti fino a che il loro scopo non fosse stato raggiunto. Per mia fortuna il progetto ebbe l'approvazione degli sviluppatori senior. Queste discussioni, però, iniziarono a pesarmi veramente molto e resero lo sviluppo di Stampede sgradevole. Ugh! Purtroppo, non potendo evitare questi individui su #stampede, non ho potuto più utilizzare questo canale per chattare con gli sviluppatori higher-level. Ogni volta che entravo questi mi aggredivano e tentavano di insidiare il mio lavoro. Usavano anche metodi più subdoli, come convocare delle riunioni di sviluppo con il solo scopo di denigrare il mio lavoro davanti agli sviluppatori senior. Hanno anche provato a richiedere delle votazioni, nel tentativo di prendere il controllo su Stampede. Ovviamente richiedevano il voto solo quando era loro opinione di essere riusciti a convincere un numero sufficiente di persone ad essere d'accordo con loro. Dall'inizio alla fine di queste vicende ho sempre continuato lo sviluppo del mio slpv6. Era inutile dire che agli sviluppatori senior piaceva il mio lavoro e volevano che io continuassi (infatti senza il loro supporto non sarei stato in grado di sopportare il braccio di ferro). Questi due individui, che appartenevano alla categoria degli sviluppatori, a me piace chiamarli "gli strani". Sebbene tali persone mi resero lo sviluppo un lavoro assai pesante, devo ammettere che ho anche imparato molto durante i nostri confronti. A questo punto mi fa piacere proporre una sorta di descrizione completa su "gli strani": le qualità che rendono "uno strano", il modus operandi di "uno strano" e come sia possibile, per un capo progetto, affrontare e possibilmente corregere "uno strano" senza troppo impegno. Per evitare danni emotivi, c'è bisogno di un prerequisito: spina dorsale. Se non si è in grado di confrontarsi con "uno strano" in maniera rispettosa, ma ferma, non ci sono speranze. L'obiettivo di "uno strano" è controllare il più possibile del tuo progetto cosi che lui, o lei, si senta importante. "Uno strano" può usare più tecniche per realizzare ciò. Per prima cosa comincia a criticare ingiustamente o a protestare vibratamente nei confronti del progetto e/o nei confronti degli sviluppatori che vi lavorano. Successivamente si asterranno dal fornire una soluzione costruttiva ed inoltre non saranno disposti a collaborare al progetto in nessuna altra maniera se non attraverso la loro promozione a project manager. Il loro scopo è convincere a dargli più autorità possibile in maniera tale che possano risolvere i problemi che solo loro, con i loro occhi finemente addestrati, possono vedere. Se il criticare ed il protestare non risultano sufficienti, loro chiederanno una riunione di sviluppo. Questo gli darà la possibilità di provare a dividere il team in due fazioni. Quando poi penseranno di aver attirato dalla loro parte un sufficiente numero di persone chiederanno il voto (essendo sicuri di vincere). Se non vincono le votazioni, oppure se queste non vengono prese in considerazione spingeranno per una nuova riunione per la prossima settimana e cercheranno ancora di spaccare il team e ripeteranno questo processo sino all'infinito. Se l'approccio basato sulle riunioni non funziona, "gli strani" diventeranno i riformatori. Assumendo questa posizione e proveranno a migliorare (leggi minare) il processo decisionale/esecutivo ritenuto oppressivo e ingiusto, tentando di sostituirlo con qualche cosa di più democratico (leggi: facilmente manipolabile). Ciò spesso coinvolgerà il convincervi che dovreste fare qualsiasi cosa la maggior parte dei vostri sviluppatori vogliano. "Gli strani" adorano ciò in quanto non si potrà non tener conto dei voti delle riunioni per sempre (muhahaha!). Se una cosa del genere dovesse accadere, avremmo fornito allo "strano" le chiavi per il nostro Lexus. Diverremo impotenti. Seguendo un'altro approccio "gli strani" faranno prima indisporre e poi porteranno via i vostri sviluppatori più produttivi. Successivamente condurranno l'intero team nella frenesia mentre tenteranno con tutte le loro forze di sovvertire la struttura gerarchica del progetto. Alla fine se i loro sforzi dovessero risultare ancora vani cercheranno di raggruppare il più alto numero di "disertori" possibile e creeranno un fork del progetto. Ouch! Questo genere di individui sono identificabili piuttosto facilmente, sono quelli che non hanno scritto nemmeno una linea di codice (e nemmeno hanno l'intenzione di farlo). Piuttosto passeranno la maggior parte del loro tempo nel parlare di cose più importanti. Sapete, quei problemi organizzativi..... Se si è capo progetto è abbastanza facile trattare con loro. Potremmo dirgli che non vogliamo prendere in considerazione nessuna delle loro proposte a meno che non producano del codice operativo, oppure insistere sul fatto che il loro aiuto costruttivo al progetto corrente include anche l'obbedienza al capo progetto, prima di dare loro la possibilita' di offrire qualsiasi critica (costruttiva). Se iniziano a scrivere del buon codice o iniziano ad essere veramente di aiuto bene, altrimenti è meglio chiedergli di andarsene. A questo punto o lascieranno il progetto (se li ignoriamo abbastanza a lungo) oppure cominceranno ad agire iniziando a scrivere codice e generalmente diventeranno anche più amabili. Sfortunatamente, però, gli sviluppatori senior di Stampede non gestirono a dovere "gli strani", e diedero loro la possibilità di tormentare me (ed altri) fino all'infinito. Mentre, da una parte, gli sviluppatori senior erano favorevoli al mio lavoro di sviluppo, dall'altra non fecero molto per tenere questi tizi sotto controllo. Cosi un giorno decisi che sarebbe stato più facile creare una distribuzione tutta mia piuttosto che continuare a tollerare quei due "strani". Mi sono dimesso da sviluppatore Stampede ed ho iniziato a progettare la mia distribuzione. Mentre pensavo che lasciare un progetto a causa di due sviluppatori lower-level fosse una cosa un po' strana, il fatto che quelli non si erano occupati di quello che realmente era indicato nel progetto aveva avuto seri problemi di gestione. Se gli sviluppatori higher-level non potevano o non volevano garantire che lo sforzo degli sviluppatori Stampede fosse piacevole e ripagante allora io non volevo più collaborare con loro. Una volta che me ne ero andato tirai un gran sospiro di sollievo. Wow! Finalmente, le cose erano calme e quiete. Adesso era giunto il momento di decidere che cosa la mia distiribuzione sarebbe stata ed in che modo avrebbe contribuito al panorama delle distribuzioni Linux. Una delle cose che mi attrassero verso Stampede furono le sue grandi prestazioni (grazie all'uso del compilatore sperimentale pgcc ottimizzato per il pentium). Così decisi di focalizzarmi per prima cosa sulle prestazioni. Oltre a voler minimizzare l'utilizzo di CPU volevo anche cercare di minimizzare lo spreco di risorse. Moltissime distribuzioni (specialmente quelle più popolari) avviano di default moltissimi demoni e cosi ci si ritrova ad avere a malapena la RAM per aprire un xterm. La mia distribuzione, invece deve essere snella e deve consumare le risorse indispensabili, cercando di massimizzare le prestazioni dell'hardware su cui gira. Decisi quindi di adottare un approccio olistico e di analizzare il problema delle prestazioni sotto tutti i punti di vista. Purtroppo avevo una seria insufficienza di risorse, da allora io ero l'unico sviluppatore della mia distribuzione! Come potevo creare qualche cosa di comparabile con Caldera o RedHat tutto da solo? La risposta fu: automazione. Cominciai a scrivere scripts per far combaciare ogni cosa, cosi da avere il minor tempo possibile impegnato in lavori ripetitivi. Dopo tutto, altrimenti, i computer che ci sono a fare? Ben presto, però, mi accorsi che scrivere semplici script per favorire l'automazione non era abbastanza. Avevo bisogno di progettare un sistema completo che mi permettesse di creare una distribuzione Linux da zero. Chiamai tale sistema ebuild ed iniziai a lavorare. Il sistema ebuild doveva essere in grado di creare automaticamente tutti i file binari necessari per una distribuzione, automatizzando ogni cosa, dallo "spacchettamento" al patching del software, all'installazione fino alla creazione di nuovi pacchetti. Dopo aver creato un prototipo eseguibile del sistema ebuild iniziai a creare gli script per i componenti essenziali per una distribuzione (come ad esempio gcc, glibc, binutils, util-linux e via dicendo). La mia Stampede box, piano piano, si stava trasformando nel mio sistema, riscrissi gli script di inizializzazione (basandoli sugli script di inizializzazione che avevo progettato in precedenza per Stampede). In fine testai ed installai tutti i nuovi pacchetti da me creati. Pochi mesi dopo avevo ultimato una distribuzione Linux autosufficiente. La chiamai Enoch, mi rilassai e risi, appagato. Ma cosa si è trasformato in Enoch, e come è evoluta in Gentoo Linux? Questo lo potrai scoprire leggendo il mio prossimo articolo nel quale racconto come Enoch sia poi diventata Gentoo Linux e le principali modifiche apportate lungo la strada.
Daniel Robbins vive a Albuquerque, New Mexico. E' stato presidente/CEO di Gentoo Technologies Inc., Chief Architect del progetto Gentoo ed ha contribuito come autore a molti libri pubblicati da MacMillan: Caldera OpenLinux Unleashed, SuSE Linux Unleashed, and Samba Unleashed. Daniel ha avuto a che fare con i computer in diverse maniere, già dalle scuole supriori quando fù dapprima esposto al linguaggio di programmazione Logo e poi a dosi potenzialmente letali di PacMan. Questo probabilmente spiega perchè da allora ha lavorato come Lead Graphic Artist presso SONY Electronic Publishing/Psygnosis. Daniel ama passare tempo con sua moglie Mary e con la sua bambina, Hadassah. Puoi contattare Daniel all'indirizzo drobbins@gentoo.org. |
|
