[VERY LONG] Facciamo un po' di chiarezza sulla Gentoo...

yLothar ylothar a yblog.homelinux.org
Dom 16 Maggio 2004 16:59:14 UTC


Premessa 1. - 	Uso la Gentoo da ormai 2 anni, ergo SO di cosa parlo.
Premessa 2. - 	Da quello che ho letto negli interventi circa la Gentoo 		su questa ml ne devo dedurre che molti ne hanno parlato 		senza averla mai provata.
Premessa 3. -	Uso GNU/Linux da quasi 5 anni ed ho provato molte 			distribuzioni, in ordine: RedHat, Suse, Mandrake, 			Slackware, Debian, Gentoo.

Ho deciso di intervenire nella discussione circa la Gentoo non per fare la parte dell'esaltato o del difensore a spada tratta pieno di preconcetti, anzi. La mia intenzione è semplicemente quella di difendere l'ottimo lavoro (IMHO) di centinaia di sviluppatori che si sono raccolti attorno al progetto Gentoo, ed è anche quella di sfatare molti dei miti (sbagliati) che girano attorno a questa distribuzione.

A mio parere molti si fanno un'idea della Gentoo leggendone le specifiche qua e la' in rete, e rimanendo colpiti più che altro dal fatto che tutto si installa compilando da sorgenti. Vero, ma fermarsi a questa annotazione è il primo sbaglio che si compie nel giudicare la distribuzione: se questa fosse infatti l'unica "meraviglia" della Gentoo, il progetto sarebbe morto ormai da tempo.

Facciamo un passo indietro e cerchiamo di capire le linee guida che risiedono dietro al concetto di 'metadistribuzione': sì, perché anche chiamare 'distribuzione' il progetto Gentoo è un errore (va bene, qui sono pignolo, ma visto che faccio il precisino...). L'idea è molto semplice: avere uno strumento di amministrazione dei 'pacchetti' che ci permetta di installare e configurare il nostro sistema GNU/Linux in base alle nostre necessità: possiamo voler utilizzare la nostra box come workstation casalinga, come server, come desktop professionale, come stazione giochi, ecc., il tutto con la massima 'semplicità' e libertà.
E qui iniziano i problemi, come tutti possiamo immaginare. Su cosa basare un sistema di questo tipo? La scelta di utilizzare una qualche forma di pacchetti precompilati risulta subito fallimentare: che siano RPM, DEB o TGZ, la risoluzione delle dipendenze è un blocco perenne alla nostra libertà. Facciamo un esempio: immaginiamo di voler installare nel nostro sistema una serie di programmi con il supporto alle librerie grafiche (diciamo XFree) ed altri invece senza tale supporto. Un pacchetto precompilato offre solo due alternative: o è compilato con il supporto a tali librerie, o è compilato senza. Se quindi volessimo installare i programmi senza il supporto a XFree (ad esempio in ambito server, dove la modalità grafica raramente è utilizzata) dovremmo avere un sistema di pacchetti compilati opportunamente. E se poi volessimo, per qualche particolare motivo, installare dei programmi con il supporto alla grafica? Qui inizierebbero i soliti smanettamenti: inizieremmo a smanettare con i pacchetti, mischieremmo probabilmente RPM di provenienza diversa e, forse, compileremmo anche qualcosa a manina... Ci sono anche dei casi in cui i pacchetti precompilati sono 'spezzati' in modo intelligente, separando il supporto a librerie diverse: ma i casi sono decisamente troppo rari.
E se ad un certo punto volessimo fare un upgrade della nostra configurazione? Molte dipendenze dei pacchetti precompilati sono statiche, ed ecco che la nostra frustrazione crescerebbe...
Passiamo ad un altro problema. Diciamo che siamo degli sviluppatori, o che abbiamo la necessità di dover utilizzare contemporaneamente versioni diverse delle stesse librerie. Sappiamo tutti che con un sistema a pacchetti precompilati ciò è un suicidio.
Di fronte a questi problemi è evidente che la scelta debba ricadere per forza di cose su un sistema di gestione del software che passi per una compilazione da sorgenti. Bene, è facile a dirsi, ma a farsi? Dopo che ci siamo compilati il mondo intero da sorgenti chi ci aiuterà ad orientarci in mezzo al marasma di binari e librerie sparsi per il nostro disco fisso? Eh, perché noi mica siamo fessi, vogliamo che sia in ogni momento possibile, con estrema semplicità, rimuovere, upgradare, aggiungere 'pacchetti' in tutta libertà! Siamo pigri, e vogliamo anche un gestore dei 'pacchetti' che ci risolva le dipendenze in modo automatico, che ci avverta se qualche pacchetto deve essere ricompilato, che ci permetta di risalire ad ogni singola dipendenza di ogni 'pacchetto'.

Bene, tutto ciò non è fantasia. Esiste infatti un gestore di 'pacchetti', capace di tutto ciò ed oltre, che si chiama Portage e che, guarda caso, è il cuore della distribuzione (meglio, metadistribuzione) che si chiama Gentoo.

Con un singolo file di configurazione, /etc/make.conf, possiamo essere in grado di controllare ogni singola caratteristica del nostro sistema: ottimizzazioni di compilazione, supporto a specifiche librerie, compilazione distribuita, mirror per il download dei 'pacchetti', ecc..

Ecco alcune peculiarità:

- Il concetto di 'USE FLAG': il supporto ad alcune librerie è regolato da alcune 'chiavi' di testo presenti nel make.conf. Scritte normalmente ne attivano il supporto, se scritte con un '-' davanti lo disattivano.

- Il concetto di 'SLOT': lo stesso pacchetto, ma con versioni diverse, può essere installato senza conflitti, 'inscatolandolo' in slot diversi. (possiamo avere ad esempio Gnome 1.4 e Gnome 2.X pacificamente installati senza problemi).

- Il concetto di 'PORT': questo è preso direttamente da FreeBSD. Il Portage, nell'installare un 'pacchetto', scarica i sorgenti ufficiali relativi, applica eventuali patch relative (contenute nell'albero delle dipendenze, elaborate dagli sviluppatori e responsabili del pacchetto), compila il tutto in base alle ottimizzazioni contenute nel make.conf, ed infine installa i binari tenendone un'accurata traccia.

Ma all'atto pratico?
Facciamo alcuni esempi...

Vogliamo aggiornare l'albero delle dipendenze (il Portage Tree)?
# emerge sync

Vogliamo vedere se ci sono pacchetti che si possono aggiornare?
# emerge world -Upv

	-Upv --> Upgrade, pretend, verbose
	ovvero, richiediamo al Portage di darci una lista dei 			'pacchetti' che si possono solo upgradare, ma non glieli 		facciamo subito compilare, e gli chiediamo già che ci siamo di 		darci la lista delle use flag interessate.

Ecco il risultato del comando (lanciato or ora sulla mia box):

[17:21:36] _monkey_ root # emerge world -Upv
>>> --upgradeonly implies --update... adding --update to options.

These are the packages that I would merge, in order:

Calculating world dependencies ...done!
[ebuild     UD] net-print/foomatic-filters-3.0.1 [20031018] +cups +samba  122 kB 
[ebuild     UD] net-print/foomatic-db-engine-3.0.1 [20031018]  283 kB 
[ebuild     UD] net-print/foomatic-3.0.1 [20031018]  [empty/missing/bad digest] 
[ebuild     UD] sys-apps/iproute2-2.4.7.20010824-r5 [20010824-r5] +doc  0 kB 
[ebuild  N    ] gnome-extra/at-spi-1.4.0   447 kB 
[ebuild  N    ] sys-libs/db-4.1.25_p1-r3  +doc +java +tcltk  3,008 kB 
[ebuild  N    ] media-gfx/gimp-1.2.5  +aalib +doc +gnome +jpeg +nls +perl +png +python +tiff  0 kB 
[ebuild     UD] x11-libs/openmotif-2.1.30-r4 [2.2.2-r1]  0 kB 
[ebuild  N    ] media-libs/xvid-0.9.1   457 kB 

Total size of downloads: 4,319 kB

[17:22:22] _monkey_ root #

E se volessimo ad esempio installare gimp-1.2.5 senza supporto java? Semplice, o modifichiamo il make.conf (ma ciò renderebbe il supporto a java disattivato per tutti i 'pacchetti' futuri) oppure, più semplicemente, diamo questo comando:

# USE="-java" emerge gimp

e il gioco è fatto: gimp viene compilato ed installato senza supporto a java, ma tale supporto resta valido in generale per tutto il sistema.

Tra le altre cose, se volessimo avere più versioni di java installate contemporaneamente sulla stessa box, non ci sarebbe alcun problema: potremmo switchare da una all'altra in ogni momento, anche a livello utente!

Ora, cerchiamo un caso rognoso... bene, prendiamo ad esempio il caso openssl. Lo abbiamo appena upgradato, ma ciò rompe le dipendenze con tutti i pacchetti che usavano la versione precedente (non è un caso generale, ma sappiamo che per certe librerie di sistema a volte questo succede). Che facciamo, ci spariamo in testa? Neanche per idea, ecco la soluzione:

# revdep-rebuild -pv

Questo comando analizzerà tutte le dipendenze dei pacchetti attualmente installati (ci metterà qualche minuto, eh!), scoverà le eventuali incongruenze, e ci darà una lista di eventuali pacchetti da reinstallare, calcolando tutte le dipendenze da rispettare. Diamo allora:

# revdep-rebuild -v

e lasciamo compilare. Al termine dell'operazione avremo un sistema perfettamente in ordine, senza librerie sparse qua e là, o incongruenze nascoste.

Ok, ma così è troppo facile, noi vogliamo poter fare lo stesso anche nel caso in cui ci sia solo una libreria che è stata aggiornata. Ok, basta fare così:

# revdep-rebuild --soname libreria.XXX.so -pv

ed il gioco è fatto!

Mmm... vediamo, e se volessimo sapere che use flags usa un 'pacchetto'?

# etcat uses vim
[ Colour Code : set unset ]
[ Legend   : (U) Col 1 - Current USE flags        ]
[          : (I) Col 2 - Installed With USE flags ]

 U I [ Found these USE variables in : app-editors/vim-6.2-r8 ]
 - - selinux    : !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
 + + ncurses    : Adds ncurses support (console display library)
 + + nls        : unknown
 - - acl        : Adds support for Access Control Lists
 - - cscope     : Enables cscope interface -- in vim for example
 + + gpm        : Adds support for sys-libs/gpm (Console-based mouse driver)
 + + perl       : Adds support/bindings for the Perl language.
 + + python     : Adds support/bindings for the Python language
 - - ruby       : Adds support/bindings for the Ruby language
 - - vim-with-x : Enables linking the console vim against X libs to enable some features in xterms
 - - minimal    : Build vim with minimal features, resulting in a ~430K binary

E se volessimo sapere che pacchetti dipendono da openssl?

# qpkg -q openssl

dev-libs/openssl-0.9.7d *
DEPENDED ON BY:
        qca-tls-1.0
        mysql-4.0.18-r1
        python-2.2.3-r5
        python-2.3.3-r1
        pwlib-1.6.3-r1
        Crypt-SSLeay-0.49
        gnustep-make-1.6.0
        gnome-vfs-1.0.5-r3
        gnome-vfs-2.4.2-r1
        ORBit2-2.8.3
        kdebase-3.2.2
        kdelibs-3.2.2
        ethereal-0.10.3
        ettercap-0.6.11
        tcpdump-3.8.3-r1
        ftp-0.17-r2
        gftp-2.0.16-r1
        gnomemeeting-1.00
        psi-0.9.1
        xchat-2.0.8-r1
        c-client-2002d
        libsoup-1.99.28
        libwww-5.4.0-r2
        linc-1.0.3
        openh323-1.13.2-r1
        ssmtp-2.60.7
        sylpheed-claws-0.9.10
        curl-7.11.0
        ntp-4.2.0-r2
        openssh-3.8_p1
        wget-1.9-r2
        cups-1.1.20-r1
        dillo-0.7.3-r5
        links-2.1_pre11
        lynx-2.8.5
        screem-0.8.1

Ecco, queste sono solo ALCUNE delle meraviglie del Portage.

Ma allora la Gentoo è così 'sfavillante' come sembra?

No.

Il problema della compilazione da sorgenti rimane: e rimane in quanto il lavoro del processore e il tempo necessario non sono fattori così trascurabili. Ma non è così tutto negativo come potrebbe sembrare.
Prima di tutto cerchiamo di tener presente che il piccì medio di questi tempi è abbastanza veloce da permettere tale mole di compilazione. Io personalmente ho un Athlon 1200 Thunderbird e mi nuovo abbastanza agilmente, figuriamoci con un Pentium IV o un Athlon XP...
E per le macchine vecchiotte?
Ci sono due opzioni, una di compromesso ed un'altra più sofisticata.
La prima è quella di utilizzare, almeno in fase di installazione, un insieme di pacchetti precompilati. E allora tutto il discorso fin qui fatto??? Bé, è una solizione 'spuria': mi permette di installare velocemente e poi di 'ricamare' in seguito. I pacchetti precompilati sono infatti totalmente compatibili con il sistema del Portage e quindi si inseriscono nell'albero delle dipendenze senza creare problemi: in un secondo tempo posso compilare da sorgenti senza intaccare la pulizia del sistema (qui inserisco una postilla: il Portage mi permette di installare i miei 'pacchetti' e di farne una 'copia' in forma di pacchetto precompilato, che posso in seguito spostare su altre macchine. Immaginiamo di avere un laboratorio con N macchine uguali: faccio il lavoro su una, magari sfruttando le altre con distcc, e poi aggiorno tutto in un baleno...).
La seconda è quella di utilizzare le meraviglie della compilazione distribuita: ovvero installo una macchina ma faccio fare il lavoro sporco ad un'altra più potente, il tutto in maniera trasparente ed efficacie. Certo, devo avere una seconda macchina da utilizzare, ma se voglio recuperare un Pentium I anche io dovrò mettermi nell'ottica di fare qualche piccolo sacrificio... Dico così perché personalmente ho tirato su da zero un Pentium II 300 senza troppi problemi (di tempo, intendo). E tenete presente che i livecd della Gentoo contengono il supporto al distcc: ergo, li faccio bootare da una macchina Windows e la uso per compilare senza troppi problemi!

Altro problema: la compilazione da sorgenti è così indispensabile? Bé, se si guarda ai vantaggi offerti da un sistema come il Portage è indubbio che ciò sia stravero. Ma in termini di guadagno di prestazioni? Bé, qui è un'altra storia. Ci sono, IMHO, punti pro e contro. Ovvero esiste, ed è indubbio, un certo margine all'interno del quale la potenza di un processore sopperisce alla scarsa ottimizzazione del compilatore. Ma ci sono anche ambiti in cui ciò non è più vero. Penso ad esempio all'encoding video ed audio, o a certe applicazioni 'pesanti'. Io ho provato personalmente ad encodare DivX su distribuzioni precompilate (per 386, 586 e 686) e sulla mia Gentoo, con ottimizzazione 'spinta' di:

CFLAGS="-march=athlon-tbird -O3 -pipe -fomit-frame-pointer -ffast-math -fforce-addr -falign-functions=4"

Non è l'ottimizzazione più spinta per Athlon 1200 ma già così vi assicuro che solo con XviD guadagno quasi 10 fps in fase di encoding!!! (a parità di filmato, box, ecc.)

Credo quindi che la questione ottimizzazione dipenda un po' dall'ambito in cui si lavora, e qui ognuno ha i propri parametri di giudizio: io personalmente penso che a volte mi fa comodo, altre meno. Una cosa però è certa: se ho un Athlon 1200 voglio che lavori come un Athlon 1200, non come un 386... (altrimenti gli sviluppatori del gcc che ci stanno a fare!?!?)

Passiamo ad altro campo. La stabilità del sistema.
Qui spesso se ne sentono delle belle... voglio dire, io faccio (e vorrei continuare a fare, se Dio vuole...) il sysadmin. E ritengo (a buon senso, spero) che non ci sia bisogno della voce di una distribuzione (leggasi Debian...) per decidere se un software è stabile o meno. E poi c'è il gusto personale: se a me piacesse lavorare con una versione specifica di un 'pacchetto'? Devo upgradarlo o meno a seconda del parere (tutto fuorché che omniscente) di qualcuno? Non mi pare il caso. La mia buona Gentoo mi permette di fare le scelte che mi piacciono, senza problemi di dipendenze o quant'altro, nemmeno di licenze (leggasi ancora Debian...). In pratica sono io, per davvero, l'unico e il solo amministratore della mia macchina: io decido, e se IO sbaglio, bé, scusate, ma son davvero (e senza scherzare) c###i miei!!!

Per il tema sicurezza non credo che la cosa sia sensibilmente diversa dal tema stabilità, per cui si veda sopra.

Prima di chiudere, alcune annotazioni di carattere puramente personale, che spero servano per rendere un po' più credibili le mie affermazioni, fin qui esposte.
Ho iniziato dalla RedHat 7.X. Quando, per esigenze di personalizzazione, sono arrivato al punto di farmi da solo gli RPM ho capito che c'era qualcosa che non andava... Sono così passato in rapida successione dalla Mandrake alla Suse. Della Mandrake ho un ricordo pessimo (ora non so a che punto è arrivara, mai più usata...), della Suse invece ero rimasto quasi soddisfatto, sistema degli RPM a parte. Ho così provato brevemente la Slackware e in seguito, per più di un anno, la Debian. La Slackware e la Debian sono un mito, niente da dire. Ma non mi hanno mai convinto fino in fondo. La Slackware ha una pulizia di sistema incredibile, ma una duttilità nella gestione dei pacchetti IMHO discutibile. La Debian ha una gestione dei pacchetti molto buona, e una cura nella loro ottimizzazione (di gestione, non di compilazione) incredibile. Ha però tutta una serie di limitazioni nella gestione che trovo assurdi (giustificabili forse in parte, ma proprio se uno è buono...). La classificazione in stable, testing e unstable la trovo poi tutta da ridere (in senso buono, s'intende!). Più che altro, seriamente parlando, la trovo pressoché inutile, forse più scomoda che altro. Comunque sia ci ho lavorato, con la Debian, per un pezzo, ma alla fine l'ho trovata poco snella per le mie esigenze.
Alla fine sono approdato con molta diffidenza alla Gentoo, alla ricerca disperata di ciò di cui avevo bisogno.
Che dire, dopo che ho compilato XFree, Gnome, KDE, Mozilla e quant'altro senza la minima difficoltà, dopo che ho imparato a sfruttare la potenza del Portage, dopo aver visto la quantità impressionante di documentazione, dopo aver sfruttato i mille forum ufficiali di discussione, ecc., ho capito che era la distribuzione per me.

Come concludere allora? Che io sono bravo e sono il migliore perché uso Gentoo!?!? Ma per l'amor del cielo!

Ho esposto, credo e spero, in maniera abbastanza chiara e dettagliata, i pregi e i difetti di questa distribuzione e, ripeto, con l'intenzione di dare un taglio a tutti quei pregiudizi che continuo a leggere qua e là, ogni tanto, su questa ml.
Al di là della bontà o meno di alcune soluzioni che la Gentoo usa, non credo di essere nel torto nel dire che questa distribuzione, attualmente, sia l'unica che lasci un grado così alto di libertà di ottimizzazione (non solo del processore, spero sia chiaro...) al suo utilizzatore. Il prezzo da pagare non è trascurabile, ma IMHO accettabile.

La questione della difficoltà di installazione non la prendo neanche in considerazione. Primo perché esiste un handbook di guida che è a prova di ritardato mentale. Secondo perché non mi aspetto (e non lo consiglierei mai) che un n00b parta dalla Gentoo per avventurarsi nel mondo GNU/Linux.

Finisco qui. Rimarcando le mie convinzioni, compresa quella (spero si sia capito tra le righe) che chi usa Debian o Slackware non ha il 'verbo' in mano, anzi. Il mondo GNU/Linux si evolve costantemente, e non è assolutamente detto che le nuove soluzioni siano peggiori delle vecchie (e viceversa). Ma almeno lasciatemi fare un appello: smettiamola di difendere per preconcetti le distribuzioni che usiamo e, soprattutto, non parliamo di certi argomenti se prima non siamo sicuri di conoscerli abbastanza: ho sempre considerato molto triste (e sintomo di pazzia) vedere in televisione persone parlare e commentare un film o un libro che non hanno, per loro stessa ammissione, mai letto o visto...

Che ognuno provi e sperimenti ciò che lo interessa e poi scelga in base alle proprie esigenze ed ai gusti personali.

Per tutto il resto... c'è Mastercard :-)

Ciao a tutti, Teo.

p.s. Mi aspetto una valanga di ribattute, spero che si crei un dialogo intelligente, e non una sassaiola... alle schermaglie verbali fini a se stesse non prendo parte, ai confronti interessati e motivati partecipo invece attivamente, con la massima disponibilità. A buon intenditore...
-- 
  __ ____   ___  _______  ___  ____
 / // / /__/ _ \/ __/ _ \/ _ `/ __/
 \_, /____/\___/\__/_//_/\_,_/_/   
/___/ «at» yblog.homelinux.org  



More information about the Talking mailing list