Costruire una distribuzione, Parte 21. Da Enoch a Gentoo, attraverso piccoli contrattempi e inserimenti corporativi Nel mio precedente articolo 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). 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. 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. 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 po' 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. 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. 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 versione CVS!) 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 po' di tempo. Per scoprirlo mi scaricai gli SRPM (Source RPM) delle glibc di RedHat e cominciai a guardare le loro patch. 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. 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". E' spiacevole che alcune distribuzioni (ahem) non siano buone (RedHat) mentre altre (Debian) condividono il loro lavoro con la comunità. 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. 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 ottenemmo 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. Lasciamo che le stranezze inizino 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. 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. 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. 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. 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?) 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. 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. 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. Adesso è il caso di chiudere la parentesi e tornare alla mia storia. 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. Naturalmente la prima reazione fu quella 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. Fui estremamente sconvolto da questo, e poichè non potevo ordinare ulteriori pezzi per il PC, lo sviluppo di Gentoo subì effettivamente uno stop. Ero molto pessimistico su Linux e decisi di orientarmi verso FreeBSD. Si, FreeBSD è quello con cui concluderò questa puntata -- leggi la Parte 3. :)
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. |
|
