[gentoo-docs-it] terminato making-the-distro-p2.xml

public inbox for gentoo-docs-it@lists.gentoo.org
 help / color / mirror / Atom feed

* [gentoo-docs-it] terminato making-the-distro-p2.xml
@ 2006-01-03 20:55 Paolo Palana
  2006-01-10 19:07 ` Stefano Rossi
  0 siblings, 1 reply; 2+ messages in thread
From: Paolo Palana @ 2006-01-03 20:55 UTC (permalink / raw
  To: gentoo-docs-it

[-- Attachment #1: Type: text/plain, Size: 135 bytes --]

 Ho finito di tradurre making-the-distro-p2.xml, il relativo bug è:i

Bug 117654
<http://bugs.gentoo.org/show_bug.cgi?id=117654>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: making-the-distro-p2-pubblico.xml --]
[-- Type: text/xml; name="making-the-distro-p2-pubblico.xml", Size: 21420 bytes --]

<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header: /var/www/www.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/articles/making-the-distro-p2.xml,v 1.4 2005/10/09 17:13::23 rane Exp $ -->
<!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>

<!--<author title="Editor">
  <mail link="fox2mike@gentoo.org">Shyam Mani</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>
  Hang out on <uri
  link="http://irc.openprojects.net/">irc.openprojects.net</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>
<!--<title>About the author</title>
<body>

<p>
Daniel Robbins lives in Albuquerque, New Mexico. He was the President/CEO of
Gentoo Technologies Inc., the Chief Architect of the Gentoo Project and is a
contributing author of several books published by MacMillan: Caldera OpenLinux
Unleashed, SuSE Linux Unleashed, and Samba Unleashed. Daniel has been involved
with computers in some fashion since the second grade when he was first exposed
to the Logo programming language and a potentially lethal dose of Pac Man. This
probably explains why he has since served as a Lead Graphic Artist at SONY
Electronic Publishing/Psygnosis. Daniel enjoys spending time with his wife Mary
and his new baby daughter, Hadassah. You can contact Daniel at
<mail link="drobbins@gentoo.org">drobbins@gentoo.org</mail>.
</p>-->

</body>
</section>
</chapter>
</guide>

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [gentoo-docs-it] terminato making-the-distro-p2.xml
  2006-01-03 20:55 [gentoo-docs-it] terminato making-the-distro-p2.xml Paolo Palana
@ 2006-01-10 19:07 ` Stefano Rossi
  0 siblings, 0 replies; 2+ messages in thread
From: Stefano Rossi @ 2006-01-10 19:07 UTC (permalink / raw
  To: gentoo-docs-it

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

Paolo Palana wrote:

> Ho finito di tradurre making-the-distro-p2.xml, il relativo bug è:i
>
>Bug 117654
><http://bugs.gentoo.org/show_bug.cgi?id=117654>
>
>  
>

online

-- 
Gentoo Documentation Project
Italian Follow-Up Translator 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2006-01-10 19:08 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-03 20:55 [gentoo-docs-it] terminato making-the-distro-p2.xml Paolo Palana
2006-01-10 19:07 ` Stefano Rossi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox