Attachment 76107 Details for Bug 117654 – [it] translated making-the-distro-p2.xml

[it] translated making-the-distro-p2.xml

making-the-distro-p2-pubblico.xml (text/plain), 20.47 KB, created by Paolo Palana on 2006-01-03 12:52:31 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Paolo Palana

Created: 2006-01-03 12:52:31 UTC

Size: 20.47 KB

patch

obsolete

><?xml version='1.0' encoding="UTF-8"?>
>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>
><guide link="/doc/it/articles/making-the-distro-p2.xml" lang="it" disclaimer="articles">
><title>Costruire una distribuzione, Parte 2</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>
>Nel suo precedente articolo Daniel Robbins ha raccontato la storia di come Ã¨
>diventato uno sviluppatore Stampede Linux e del perchÃ¨ alla fine abbia lasciato
>Stampede per dar vita alla distribuzione Enoch. In questa seconda parte ci fa
>partecipi degli strani eventi che sono successi dopo che il team di sviluppo di
>Enoch ha scoperto un compilatore, poco conosciuto, ma molto veloce.
></abstract>
>
>
>
><version>1.2</version>
><date>2005-10-09</date>
>
><chapter>
><title>Da Enoch a Gentoo, attraverso piccoli contrattempi e inserimenti
>corporativi</title>
><section>
>
><title>I primi passi di Enoch</title>
><body>
>
><p>
>Nel mio <uri link="/doc/it/articles/making-the-distro-p1.xml">precedente articolo</uri>
>ho raccontato i giorni, poco piacevoli, passati con il team di sviluppo
>Stampede e il perchÃ¨ me ne andai (per scappare da quei "strani" lower-level,
>politicamente-portati e progetto-controllori). A causa delle interferenze di
>queste inopportune persone, pensai fosse piÃ¹ semplice mettere insieme una
>mia distribuzione Linux piuttosto che continuare a lavorare su Stampede a
>queste condizioni!
>Fortunatamente portai con me un considerevole bagaglio di esperienze basate sul
>mio (posso dire sostanziale?) lavoro per Stampede, incluso anche il
>mantenimento di molti dei loro packages, la progettazione degli script di
>inizializzazione, e le attivitÃ  principali di slpv6 (progetto per una nuova
>generazione del gestore di pacchetti).
></p>
>
><p>
>La distribuzione sulla quale iniziai a lavorare, nome in codice Enoch, stava
>cominciando a diventare molto veloce dato che il processo di creazione ed
>aggiornamento dei pacchetti era completamente automatizzato.
>Devo ammettere che questo Ã¨ successo, in larga parte, perchÃ¨ ero l'unico membro
>del mio team e non potevo permettermi di spendere il mio tempo con del lavoro
>ripetitivo che la mia macchina di sviluppo poteva svolgere, in maniera
>automatica, al posto mio. Progettai cosÃ¬ una distribuzione completamente da zero
>(piuttosto che "girare intorno" ad alrte tipo RedHat), avevo il lavoro adatto a me
>e adesso avevo bisogno di tutto il tempo libero che riuscivo a trovare.
></p>
>
><p>
>Non appena riuscii a rendere il mio sistema Enoch, basilare, perfettamente
>funzionante, tornai su irc.openprojects.net e diedi vita al mio canale
>chiamato #enoch. Dopo questo, gradualmente, sono riuscito ad assemblare un
>team di una diecina di sviluppatori. In quei primi giorni "abitavamo" su IRC e
>lavoravamo alla distribuzione nel tempo residuo.
>Mentre noi, in maniera comune e cooperativa, lavoravamo su Enoch, cercando e
>facendo il fix di nuovi bug, Enoch cominciava ogni giorno ad avere sempre
>piÃ¹ funzionalitÃ  ed ad essere sempre piÃ¹ professionale.
></p>
>
></body>
></section>
><section>
><title>Il primo ostacolo</title>
><body>
>
><p>
>Un giorno, inevitabile, Enoch ebbe il suo primo blocco. Dopo aver aggiunto
>Xfree86, glib, e gtk+ decisi di installare xmms (un player MP3/CD basato su
>X11/gtk+). Avevo pensato che fosse arrivato il momento di festeggiare con un
>pÃ² di musica! Quando perÃ², dopo l'installazione di xmms, tentai di
>avviarlo.......X si bloccÃ²!
>In un primo momento pensai che il blocco di xmms fosse dovuto all'utilizzo di
>ottimizzazioni di compilazione insane ("-O6 -mpentiumpro", giusto per stupire).
>La mia prima idea fÃ¹ quindi quella di ricompilare xmms con ottimizzazioni
>standard, ma questo non risolse il problema. Iniziai cosÃ¬ a cercare altrove la
>soluzione. Dopo avre speso un'intera settimana di tempo di sviluppo per
>cercare di risolvere il problema, ricevetti una e-mail da un utente Enoch,
>Omegadan, che diceva che anche lui aveva avuto lo stesso problema con xmms.
></p>
>
><p>
>Intanto ci tenevamo in contatto, e dopo diverse ore di test eravamo riusciti a
>determinare che il problema era dovuto ai thread POSIX. Per qualche ragione la
>funzione pthread_mutex_trylock() non ritornava nella maniera in cui avrebbe
>dovuto. Come creatore di una distribuzione questi sono proprio quei tipi di
>problemi che non avrei mai voulto incontrare.
>Io avevo contato su quei sviluppatori per realizzare codice sorgente
>funzionante, in maniera tale che io potessi concentrarmi sull'accrescere
>l'usabilitÃ  di Linux, piuttosto che debuggare codice per renderlo operativo.
>Naturalmente mi resi ben presto conto che questa aspettativa era del tutto
>non realistica e che problemi simili di tanto in tanto si sarebbero manifestati.
></p>
>
><p>
>Come Ã¨ risultato, il problema non era con xmms, gtk+ o glib. Non era nemmeno
>dovuto ad un problema con Xfree86 3.3.5 non ancora thread-save (il termine
>thread-save Ã¨ usato per indicare una porzione di programma o di funzione che
>puÃ² essere chiamato da piÃ¹ thread senza avere interazioni indesiderate tra
>questi N.d.t.) e si bloccava.
>Sorprendentemente trovammo il bug nell'implementazione stessa dei thread POSIX,
>parte delle librerie C GNU (glibc) versione 2.1.2. Rimasi scioccato nello
>scoprire che una componente critica di Linux potesse avere un simile bug.
>(E in Enoch non avevamo usato una prerelease o una veresione CVS!)
>
>
></p>
>
><p>
>Come risolvere il problema allora? In quel momento, non saremmo mai riusciti
>a forinre una soluzione al bug, ma ad un certo punto incappai in un paio di
>mail, sulla maling list dei developer di glibc, di persone che avevano lo
>stesso problema. Gli sviluppatori postarono una patch che risolveva il problema
>dei thread, ma io ero curioso di sapere perchÃ¨ la mia RedHat 6 (che usava anche
>lei le glibc 2.1.2) non soffrisse del problema, visto che la patch era appena
>stata postata, mentre RedHat 6 era disponibile giÃ  da un pÃ² di tempo.
>Per scoprirlo mi scaricai gli SRPM (Source RPM) delle glibc di RedHat e
>cominciai a guardare le loro patch.
></p>
>
><p>
>RedHat aveva una propria patch alle glibc che risolveva il problema di
>pthread_mutex_trylock(). Apparentemente lamentavano lo stesso problema e
>crearono la propria soluzione. Disgraziatamente, perÃ², questi non trasmisero
>la patch in "upstream" verso gli sviluppatori di glibc e quindi non potÃ¨ essere
>condivisa con il resto del mondo. Oppure chi sÃ , forse RedHat ha spedito la
>patch e per qualche ragione gli sviluppatori di glibc non l'accettarono.
>O magari quel particolare bug veniva generato solo da una specifica
>combinazione di compilatore e versione di binutils, e RedHat non incorse in
>questo (anche se avevamo una patch nel loro SRPM). Ho la sensazione che non
>sapremo mai come sono andate realmente le cose, ma ho scoperto che gli SRPM di
>RedHat contengono molte soluzioni "private" ai bug e che incredibilmente nessuno
>ha mai spedito tali soluzioni agli sviluppatori originali. Per un istante
>rimasi sconvolto da questo.
></p>
>
></body>
></section>
><section>
><title>Declamazione</title>
><body>
>
><p>
>Una volta assemblata una bistribuzione Linux Ã¨ veramente importante che ogni
>fix creata per i vari bug sia spedita agli sviluppatori originali. Per come la
>vedo io, questa, Ã¨ una delle principali maniere in cui, un creatore di una
>distribuzione, puÃ² contribuire a Linux. Noi siamo i tipi che realmente
>riescono ad ottenere che molti programmi differenti lavorino insieme come un
>tutt'uno. Dovremmo quindi spedire le nostre soluzioni per unificarle e
>affinchÃ¨ altri utenti ed altre distribuzioni possano beneficiare delle nostre
>scoperte.
>Qualora si decidesse di tenere le proprie patch per se, non si sarebbe di aiuto
>a nessuno, ma si sarebbe solo sicuri che molte persone perdano molto tempo nel
>coreggere lo stesso problema piÃ¹ e piÃ¹ volte. Una simile politica va contro
>tutti i principi etici dell'open source e frena lo sviluppo di Linux.
>Forse dovrei dire che questo Ã¨ il "bug di noi tutti".
></p>
>
><p>
>E' spiacevole che alcune distribuzioni (ahem) non siano buone (RedHat) mentre
>altre (Debian) condividono il loro lavoro con la comunitÃ .
></p>
>
></body>
></section>
><section>
><title>Dramma del Compilatore</title>
><body>
>
><p>
>Mentre eravamo impegnati nel cercare di correggere il problema dei thread di
>glibc, contattai via e-mail Ulrich Drepper (una delle persone di Cygnus
>maggiormente coinvolte nello sviluppo di glibc). Gli dissi che problema con
>i thread POSIX stavo avendo e che Enoch usava pgcc per avere prestazioni
>migliori. Questi mi rispose con qualcosa di simile a questo (lo sto
>parafrasando): "Il nostro compilatore incluso nel prodotto CodeFusion ha un
>eccellente backend per x86 che produce eseguibili ben piÃ¹ veloci di quelli
>prodotti con pgcc." Ovviamente fui molto interessato nel testare questo
>misterioso "turbo compilatore" che quelli di Cygnus avevamo creato.
></p>
>
><p>
>Richiesi subito una copia dimosrtativa di Cygnus Codefusion 1.0 per poterlo
>testare, sia Omegadan che io rimanemmo stupiti nel verificare che questo
>compilatore era proprio quello che Ulrich aveva detto. Il backend per x86
>incrementava le prestazioni degli eseguibili CPU-intensivi (tipo bzip2) anche
>del 90%! Tutte le applicazioni sembravano trarne vantaggio, beneficiando di un
>aumento reale delle prestazioni di almeno il 10%, era il caso di cambiare
>compilatore. Enoch si avviÃ² con una velocitÃ  supriore del 30 - 40%. Il guadagno
>in termini di prestazioni era ben piÃ¹ grande del guadagno che otenemmo nel
>passare da gcc a pgcc. Naturalmente, dopo averlo sperimentato cercammo di
>usare questo compilatore per Enoch. Fortunatamente il codice era incluso nel CD
>di CodeFusion ed era rilasciato sotto GPL, cosÃ¬ eravamo pienamente autorizzati
>ad usare il compilatore.......o almeno cosi pensavamo.
></p>
>
></body>
></section>
><section>
><title>Lasciamo che le stranezze inizino</title>
><body>
>
><p>
>Spedii una mail al direttore commerciale di Cygnus per fargli sapere le nostre
>intenzioni, mi aspettavo una risposta simile a "yeah, va bene, grazie per aver
>usato il nostro comiplatore". La risposta, invece, fu che eravamo
>(tecnicamente) autorizzati ad utilizzare il compilatore Cygnus, ma eravamo
>stati fortemente invitati a non usare o includere il sorgente del compilatore
>in Enoch. Gli risposi chiedendogli il perchÃ¨ avessero rilasciato
>il codice sotto GPL, se era il caso. La mia opinione Ã¨ che se avessero avuto
>una possibilitÃ  di scelta, non avrebbero optato per usare la licenza
>GPL, ma siccome il loro compilatore deriva da egcs (rilasciato sotto GPL) non
>avevano alternative.
></p>
>
><p>
>Questo Ã¨ un ottimo esempio di una situazione in cui GPL ha impedito ad una
>compagnia di creare prodotti proprietari basandosi sull'open sources. La mia
>ipotesi, plausibile, Ã¨ che Cygnus fosse intimorita dal fatto che se avessimo
>usato il loro compilatore avremmo potuto compromettere le vendite dei loro
>prodotti, cosa che sarebbe davvero bizzara visto che nessuno dei loro prodotti
>di vendita (ne la rassegna di InfoWorld) menzionava il nuovo compilatore
>incluso con CodeFusion. CodeFusion era commercializzato solamente come un
>"ambiente di sviluppo IDE" e non come un compilatore.
></p>
>
><p>
>Nel tentativo di calmare alcune delle loro paranoie, mi offrii di appoggiare
>CodeFusion e palesare tale approvazione sul nostro sito web con un link per
>essere da impulso alle vendite di CodeFusion stesso. Personalmente non pensavo
>che un Enoch "turbo" potesse incidere negativamente sulle loro vendite, anche
>perchÃ¨ CodeFusion era etichettato come IDE, insomma non feci altro che tentare
>di convencerli. Il componente IDE di CodeFusion, perÃ², era un prodotto
>commerciale e non avevano ne il desiderio, ne l'intenzione di distribuilo con
>Enoch.
></p>
>
><p>
>Inviai via e-mail la mia (generosa?) offerta alla Cygnus e ricevetti
>un'altra strana risposta. Volevano il controllo su tutto il nostro "materiale
>commerciale" (apparentemente questo includeva anche i contenuti del sito web!).
>Un'altro shock. Sembrava che il team commerciale di Cygnus non avesse ben
>chiaro come la comunitÃ  Linux o GPL lavorasse. Decisi quindi di troncare le
>comunicazioni con Cygnus a tempo indeterminato. Nel frattempo avevamo creato
>una versione privata "turbo", e una pubblica "non-turbo" di Encoh, lasciando la
>decisione finale a dopo.
></p>
>
><p>
>Dopo diversi mesi integrarono il backend x86 di CodeFusion in gcc 2.95.2.
>Adesso tutti potevano trarre beneficio dal nuovo e performante backend, non
>solo la gente che era a conoscenza del "compilatore segreto GPL" incluso nel CD
>di CodeFusion. CosÃ¬ decidemmo di passare a gcc piuttosto che usare il
>compilatore di CodeFusion. Oltre che ad essere piÃ¹ stabile gcc 2.95.2 adesso 
>era dotato anche di Cygnus, che era stato comprato da RedHat per una somma
>ridicola. (Nota: il backend x86 di gcc 2.95.2 Ã¨ stato quello che ha dato alle
>distribuzioni Linux il maggiore incremento di velocitÃ  che sia mai stato
>sperimentato. Esso ha anche dato a FreeBSD un incremento di prestazioni
>considerevole sopra la 3.3.6. Notate la differenza?)
></p>
>
></body>
></section>
><section>
><title>Breve Parentesi</title>
><body>
>
><p>
>Grazie a questa ed ad altre esperienze, imparai molto sulle compagnie open
>source "for-profit". Non cÃ¨ assolutamente niente di male se una compagnia open
>source vuole realizzare del profitto, nÃ¨ Ã¨ moralmente ingiusto produrre
>software proprietario closed-source, se questo Ã¨ ciÃ² che si vuole fare. Ma
>non ha alcun significato per le compagnie open source sovvertire o rifiutare
>la collaborazione con il resto del mondo open source, ad esempio non sostenendo
>la GPL o in qualsiasi altra maniera. Questo Ã¨ un punto pratico che ha
>chiaramente il significato di affari.
></p>
>
><p>
>Le compagnie open source dovrebbero capire che il libero scambio di idee e di
>codice Ã¨ una cosa dalla quale trarre profitto. Opponendosi a cose come le
>regole standard GPL, minano l'ambiente sul quale contano per svilupparsi e
>prosperare. Se l'open source Ã¨ il terreno sul quale il vostro business ha
>fiorito Ã¨ sensato mantenere tale terreno sano.
></p>
>
><p>
>E' comprensibile che ci sia la tentazione di mantenere alcune informazioni
>segrete per garantirsi vantaggi economici nel breve periodo. Codice avanzato o
>speciali tecniche costituiscono un ambito vantaggio competitivo, che puÃ²
>potenzialmente trasformarsi in un incremento delle vendite e dei profitti. Se,
>perÃ², l'obiettivo Ã¨ quello di essere il solo fornitore di un prodotto allora
>questo dovrebbe essere un prodotto commerciale piuttosto che open source.
>L'open source non prevede l'accesso esclusivo ai funzionamenti interni di una
>qualsiasi cosa. Questa Ã¨ la sua idea.
></p>
>
></body>
></section>
><section>
><title>Tornando ad Enoch</title>
><body>
>
><p>
>Adesso Ã¨ il caso di chiudere la parentesi e tornare alla mia storia.
></p>
>
><p>
>Man mano che Enoch cominciava a diventare sempre piÃ¹ raffinata, decidemmo che
>era necessario cambiarle nome, nacque cosi "Gentoo Linux". Nel frattempo avevamo
>giÃ  rilasciato un paio di versioni di Encoh (ora Gentoo), e stavamo forzando i
>ritmi per rilasciare la versione 1.0 di Gentoo Linux. Quasi contemporaneamente
>decisi di aggiornare il mio vecchio Celeron 300 (overcloccato a 450 Mhz e
>solido come una roccia) con un Abit BP6 (una piastra dual Celeron che era
>appena uscita sul mercato). Vendei il mio vecchio pc e contestualmente
>acquistai il mio sistema dual Celeron 366. Dopo aver overcloccato i processori
>per portarli a circa 500 Mhz, viaggiavo. Notai, perÃ², che la mia nuova
>macchina non era molto stabile.	
></p>
>
><p>
>Naturalmente la prima reazione fu quello di riportare tutto a 2x366 Mhz.
>Nonostante ciÃ², perÃ², continuavo a sperimentare continuamente un comportamento
>anomalo. Fino a che la macchina aveva la CPU sotto carico non si bloccava, ma
>se lasciavo la macchina scarica c'erano buone possibilitÃ  che il sistema si
>bloccasse completamente. Si, un idle bug -- argh! Dopo molte ricerche, trovai
>molti altri utenti Linux che avevano lo stesso problema con questa particolare
>scheda madre. Sembrava che un chip sul BP6 (era il controller PCI?) avesse un
>comportamento anomalo o fuori dalle specifiche e questo era la causa per cui
>Linux si bloccava in condizioni di macchina scarica.
></p>
>
><p>
>Fui estremamente sconvolto da questo, e poichÃ¨ non potevo ordinare
>ulteriori pezzi per il PC, lo sviluppo di Gentoo subÃ¬ effettivamente uno stop.
>Ero piÃ¹ e piÃ¹ pessimistico su Linux e decisi di orientarmi verso FreeBSD. Si,
>FreeBSD Ã¨ quello con cui concluderÃ² questa puntata -- leggi la Parte 3. :)
></p>
>
></body>
></section>
><section>
><title>Risorse</title>
><body>
>
><ul>
>  <li>
>    Inizia dall'inizio della mia storia con "Costruire una distribuzione" <uri
>    link="/doc/it/articles/making-the-distro-p1.xml">Parte 1</uri>, e finisci 
>    con <uri link="/doc/en/articles/making-the-distro-p3.xml">Part 3</uri>. 
>  </li>
>  <li>
>    Cerca Maggiori informazioni su <uri link="/index.xml">Gentoo Linux</uri>
>    nel suo sito Web.
>  </li>
>  <li>
>    Verifica la competizione a <uri
>    link="http://www.freebsd.org/">FreeBSD</uri>.
>  </li>
>  <li>
>    Leggi a proposito di <uri link="http://www.gnu.org/copyleft/gpl.html">GPL</uri>.
>  </li>
>  <li>
>    Dai un'occhiata al sito ufficiale di <uri link="http://www.stampede.org/">Stampede</uri>.
>  </li>
>  
>  <li>
>    Cerca maggiori informazioni sul progetto<uri link="http://www.xfree86.org/"> Free X86</uri>.
>  </li>
>  <li>
>    Scarica la  <uri link="http://developer.gnome.org/doc/API/gtk/">Documentazione di riferimento
>    di GTK+</uri>.
>  </li>
>  <li>
>    Prova <uri link="http://www.xmms.org/">XMultiMedia System</uri>, una applicazione
>    X11/gtk+-based per la lettura di CD e MP3.
>  </li>
>  <li>
>    Inizia con i threads con <uri
>    link="http://www.math.arizona.edu/swig/pthreads/threads.html">POSIX Threads
>    tutorial</uri> dal sito dell'UniversitÃ  dell'Arizona.
>  </li>
>  <li>
>    Scarica l'ultima versione di <uri link="http://www.rpm.org/">RPM Packaging
>    Tool</uri>.
>  </li>
>  <li>
>   Visita della barva gente:<uri link="http://www.debian.org/">Debian</uri>.
>  </li>
>  <li>
>   Visita il sito ufficiale di <uri link="http://gcc.gnu.org/">GCC</uri> site.
>  </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Ã  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
><mail link="drobbins@gentoo.org">drobbins@gentoo.org</mail>.
></p>
>
>
></body>
></section>
></chapter>
></guide>

Actions: View

Attachments on bug 117654: 76107