Attachment 72468 Details for Bug 111911 – making-the-distro-p1.xml

making-the-distro-p1.xml

making-the-distro-p1.xml (text/plain), 19.94 KB, created by Paolo Palana on 2005-11-08 13:50:13 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Paolo Palana

Created: 2005-11-08 13:50:13 UTC

Size: 19.94 KB

patch

obsolete

><?xml version='1.0' encoding="UTF-8"?>
>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>
><guide link="/doc/it/articles/making-the-distro-p1.xml" lang="it" disclaimer="articles">
><title>Costruire una distributione, Parte 1</title>
>
>
><author title="Autore">
>  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
></author>
>
><author title="Traduttore">
>   <mail link="nsr2@tiscali.it">Paolo Palana</mail>
></author>
>
>
>
>
><abstract>
>Ognuno di noi ha una storia da raccontare sulla proria esperienza con Linux.
>Questa Ã¨ la storia di Daniel Robbins. In questo primo di tre articoli, lui racconta
>di come sia diventato uno sviluppatore Stampede Linux e del perchÃ¨ ha lasciato Stampede
>per dar vita ad una propria distribuzione chiamata Enoch.
></abstract>
>
>
>
><version>1.3</version>
><date>2005-10-09</date>
>
><chapter>
><title>Nascita della distribuzione Gentoo Linux</title>
><section>
><title>Linux e me</title>
><body>
>
><p>
>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 imaparare.
>E da allora fui rapito.
></p>
>
><p>
>Per prima cosa imparai le cose fondamentali: come guardasi intorno, fare un backup,
>far funzionare Samba, etc. Dopo di che feci 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. Poiche' Linux non ha nulla da nascondere, Ã¨ possibile 
>esplorare la tecnologia ed i tools che lo rendono unico mentre si accresce la propria
>abilitÃ .
></p>
>
></body>
></section>
><section>
><title>La forza di Linux risiede nelle potenzialitÃ  che offre</title>
><body>
>
><p>
>Linux offere 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. And I was along for the ride! Ero parte della 
>trasformazione. Ero fun.
></p>
>
><p>
>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 della prossima 
>grande cosa. Poi un giorno ci siamo svegliati e ci siamo accorti che quella prossima 
>grande cosa era proprio Linux e sorridendo abbiamo continuato a lavorare sul codice.
></p>
>
></body>
></section>
><section>
><title>La forza di Linux risede nelle persone</title>
><body>
>
><p>
>Come passo successivo ho imparato che cosa era Linux per la gente. Non Ã¨ rinfrescante?i
>Linux non Ã¨ solo un mucchio di codice sorgente, ma Ã¨ una comunitÃ .
>Possiamo, quindi, contare su questa comunitia' per ottenere le nostre risposte, 
>e diventiamo parte di questa comunita' quando iniziamo ad aiutare gli altri 
>contribuendo con il nostro tempo e la nostra esperienza.
></p>
>
><p>
>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 necessessitava 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 aiautavo 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.
></p>
>
></body>
></section>
><section>
><title>Rimanere Coinvolti</title>
><body>
>
><p>
>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 
>cosi dovrebbe essere.
></p>
>
><p>
>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.
></p>
>
><p>
>Gradualmente ho iniziato ad essere sempre di piÃ¹ coinvolto nello sviluppo di
>Stampede. In breve tempo diventai uno sviluppatore ufficale. 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 flessibilita' nel formato (ovvero non era possibile aggiungere
>campi addizionali al formato .slp in futuro). Ovviamente cio' cosa ha richiesto 
>revisione importante.
></p>
>
><p>
>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, 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 
>avrenne mantenuto la compatibilitÃ  con lo standard UNIX per i formati di archivio.
></p>
>
></body>
></section>
><section>
><title>Le persone possono risultare sgradevoli</title>
><body>
>
><p>
>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! 
></p>
>
><p>
>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 ai sviluppatori senior piaceva il mio lavoro 
>e volevano che io continuassi (infatti senza il loro supporto non sarei stato in 
>grado di soppotare il braccio di ferro).
></p>
>
></body>
></section>
><section>
><title>Capire "gli strani"</title>
><body>
>
><p>
>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 corregerei "uno strano" 
>senza troppo inpegno.
></p>
>
><p>
>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 maria tale che possano risolvere
>i problemi che solo loro, con i loro occhi finemente addestrati, possono
>vedere.
></p>
>
><p>
>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.
></p>
>
><p>
>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 alla "strano" le 
>chiavi per il nostro Lexus. Diverremo impotenti.
></p>
>
><p>
>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 tutto 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!
></p>
>
></body>
></section>
><section>
><title>Gestire "lo strano"</title>
><body>
>
><p>
>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.
></p>
>
><p>
>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.
></p>
>
><p>
>Mentre pensavo che lasciare un progetto a causa di due sviluppatori lower-level
>fosse una cosa un pÃ² 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.
></p>
>
></body>
></section>
><section>
><title>Iniziare di nuovo</title>
><body>
>
><p>
>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). Cosi 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 dekk'hardware su cui gira. Decisi quindi di adottare un approccio 
>olistico e di analizzare il problema delle prestazioni sotto tutti i punti di 
>vista.
></p>
>
><p>
>Purtroppo avevo una seria insufficienza di risorse, da allora io ero l'unico 
>sviluppatore della mia distribuzione! Come potervo 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 inpegnato in lavori ripetitivi. Dopo tutto, altrimenti,
>i computer che ci sono a fare?
></p>
>
><p>
>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, gcc, glibc, binutils, util-linux e cia dicendo). 
>La mia Stampede box piano piano si stava trasformando nel mio sitema, riscrissi 
>gli script di inizializzazione (basandoli susli script di inizializzazione
>che avevo progettato in precedenza per Stampede). In fine testai ed installai
>tutti i nuovi pacchetti da me creati.
></p>
>
><p>
>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.
></p>
>
></body>
></section>
><section>
><title>Risorse</title>
><body>
>
><ul>
>  <li>
>    Continua a leggere la mia storia com "Costruire una distribuzione"
>    <uri link="/doc/en/articles/making-the-distro-p2.xml">Part 2</uri>and
>    <uri link="/doc/en/articles/making-the-distro-p3.xml">Part 3</uri>".
>  </li>
>  <li>
>    Visita il <uri link="/index.xml">sito Web di Gentoo Linux Web</uri> per avere
>    piÃ¹ informazioni sulla distribuzione.
>  </li>
>  <li>
>    Conosci in maniera piÃ¹ approfondita il sistema ebuild di Gentoo Linux
>    nell'articolo di Robbins, <uri link="http://www.gentoo.org/doc/en/articles/bash-by-example-p3.xml">
>    Bash by example, Part 3</uri>.
>  </li>
></ul>
>
></body>
></section>
><section>
><title>L'autore</title>
><body>
>
><p>
>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Ã  dal secondo grado 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
><mail link="drobbins@gentoo.org">drobbins@gentoo.org</mail>.
></p>
>
></body>
></section>
></chapter>
></guide>

Actions: View

Attachments on bug 111911: 72468 | 72512 | 76103