Gentoo Linux: qui mica pettiniamo le bambole

La prima parte dell'intervento è volutamente pensata per far perdere credibilità alla seconda. Non sono drobbins pertanto se ci sono cazzate non vi irritate (ma fatelo notare in modo acido).


Era un piovoso 31 febbraio di parecchi anni fa, quando un personaggio mezzo elvetico e mezzo windowsiano mi implorò di aiutarlo nell'installazione di una fantomatica distribuzione per uomini finiti (nel senso di aver finito con la vita sociale) chiamata Gentoo Linux. Una magica metadistribuzione che andava accrocata per metà. Motivazioni quali compilare fa bene ai pettorali e con gentoo dominerai il world mi convinsero a fare questa stravolgente esperienza. Dopo appena settordici ore avevamo prodotto un kernel non funzionante. Dopo altre settordici ore il kernel partiva ma non faceva una cippa lippa. Però da quel giorno qualcosa in me cambiò: il tempo di giocare con le paperelle era finito, era arrivato il momento di passare a Gentoo.

In questi giorni mi sto finalmente riavvicinando a questa distro (un anno di degno purgatorio con Ubuntu per permettere al mio melone bacato di crescere e imparare la lingua stallmaniana) e per tale motivo vorrei buttare giù qualche riga sui punti di forza dal mio punto di vista di questa distribuzione.


Ogni utente ha un proprio lavoro da compiere. L'obiettivo di Gentoo è quello di rendere questo lavoro il più piacevole ed efficiente possibile. Gli strumenti forniti con questa distribuzione devono far divertire l'utente, fargli apprezzare la ricchezza che Linux e tutto il software libero sono in grado di offrire. Se uno strumento forza l'utente ad agire in un certo modo, implicitamente sta agendo contro, e non per, esso. Se uno strumento compie il suo lavoro in modo perfetto, probabilmente l'utente neanchè se ne renderà conto della sua esistenza. E' lo strumento a servire l'utente e non l'utente a servire lo strumento.

Gentoo vuole creare ed offrire questi, quasi ideali, strumenti per l'utente.


Gentoo non è un progetto inesistente, c'è una fondazione (Gentoo Foundation, Inc.), c'è un consiglio (formato da 7 membri eletti con cadenza annuale) che guida le redine della distribuzione.

Il council:
• discute delle proposte rilanciate dei leader dei vari progetti
• fa le veci di una corta d'appello per decisioni disciplinari
• discute su eventuali rivendicazioni/opposizioni da parte dei progetti colpiti da precedenti decisioni
• può aver discussioni in pubblico (IRC) o in privato
• dopo ogni riunione mette a disposizione un log e una sintesi delle decisioni intraprese


Il progetto Gentoo attualmente conta ben 263 sviluppatori attivi (da quando se ne tiene traccia ben 450 dev hanno contribuito). Non 10 o 15 persone ma 263. I vari dev partecipano ad uno o più progetti. Tali progetti sono, per così dire, tematici: possono perciò essere correlati ad aspetti strettamente interni alla distribuzione (come il mantenimento o sviluppo di portage, gestione della documentazione, forum ufficiali, etc) od esterni a Gentoo ma fortemente incentrati nel marasma di un sistema operativo (Security, Kernel, Java, Apache e così via). Non esiste un area o aspetto della distribuzione che non è inquadrata in un progetto e per tale motivo c'è sempre qualcuno a cui far risalire la responsabilità (ergo dovere) di curare e mantenere la sua zona di competenza. Niente è lasciato al caso, se non si può star dietro ad un progetto, esso è messo fuori da Gentoo (non è ufficialmente supportato).

In Gentoo nessuno nasce sviluppatore, c'è tutto un percorso da dover seguire per poter entrare nell'olimpo. Occorre farsi notare dal sottoprogetto Recruiters, farsi affiancare da un mentore (un dev preesistente), superare vari quiz (pensati per assicurarsi da parte del neo-dev una buona conoscenza di portage e altri strumenti/policy) ed infine oltrepassare una breve incubazione (probationary period).

Sembra assurdo ma, entrar a far parte di un progetto come Gentoo, richiede un grande impegno e sforzo. E' ovvio (IMAO) che una tale selezione non può che far intuire la qualità che ci aspetta da uno sviluppatore del progetto Gentoo.


Sotto Gentoo c'è grande attenzione per la qualità e coerenza di ogni aspetto della distribuzione. Tale sensibilità si riflette in alcuni specifici progetti che in parte voglio citare.

Il progetto QA (Quality Assurance) si occupa di mantenere grande coerenza per tutto il portage tree (infrastruttura per la gestione dei pacchetti) anche in correlazione alle varie architettute supportate (non c'è solo x86 o amd64). Ciò si riflette in sintassi, dipendenze (sia a tempo di compilazione che runtime), dimensione dei file, changelog & metadata sempre aggiornate e il più accurate possibili. Il team si occupa di creare delle policy (che riflettono null'altro che buone pratiche) che i vari progetti devono rispettare. Inoltre è suo compito stendere della documentazione tecnica in supporto ai vari sviluppatori.

Il progetto Security ha il compito di garantire che ogni vulnerabilità (che colpisce un pacchetto residente in portage) venga sistemata il prima possibile. In aggiunta è suo dovere coordinare la stesura della GLSA (vedi seguito per saperne di più).

Il progetto PR (Public Relations) ha la mansione di mantenere viva e aperta la comunicazione con il mondo esterno a Gentoo. Questo team cerca di spiegare e sostenere pubblicamente le scelte adottate nell'ambito del progetto Gentoo.

Il progetto DevRel (Developer Relations) si occupa della gestione delle risorse umane: rimuovere sviluppatori, risolvere conflitti, recrutare nuovi dev, etc.

L'ultimo progetto che voglio citare è BugDay, team che organizza su IRC con cadenza periodica dei meeting per la risoluzione del maggior numero possibile di bug.


Gentoo ha la bella abitudine di non abbandonare a se stessi gli utenti. Li coccola e li tiene costantemente aggiornati su cosa accade intorno al progetto. Nel corso degli anni sono stati pensati e realizzati vari strumenti, alcuni (IMAO) valgono il prezzo del biglietto.

GMN (Gentoo Monthly Newsletter) è una sintesi mensile degli eventi chiave intorno a Gentoo. Muovimenti fra gli sviluppatori (ritiri, nuove acquisizioni, spostamenti), cambiamenti tecnici (non solo derivanti da scelte del council), segnalazioni articoli interessanti dal planet, ingresso/rimozioni di pacchetti dal portage tree e perchè no alcuni tips & tricks.

GWN (GeCHI Weekly Report) è una perla offerta dai GeCHI (Gentoo CHannel Italia) che si affianca alla GMN ma con cadenza settimanale (ed in italiano!). Sicuramente una grande idea che avvicina molto gli utenti gentoo italiani al progetto.

GLSA (Gentoo Linux Security Advisories) sono delle notifiche per gli utenti (soprattutto per chi non usa Gentoo per giocare a Neverball) riguardanti vulnerabilità dei pacchetti presenti in portage. Descrizione della vulnerabilità, indicazione dei pacchetti afflitti, workaround o soluzioni definitive.


Una delle principali caratteristiche di questa distribuzione è che tutto si compila ed in fase di installazione due delle principali scelte da compiere sono:
• CFLAGS
• USE

Cosa sono le CFLAGS? Semplicemente una variabile che indica al compilatore C/C++ eventuali ottimizzazioni da effettuare in fase di compilazione. Scegliere le corrette CFLAGS non è una cosa semplice, come tutte le scelte è relativa all'obiettivo che si cerca di raggiungere (stabilità Vs prestazioni). Le CFLAGS dipendono anche dall'hardware su cui si sta operando.

Molti utenti [IMAO non utenti gentoo (o almeno non in modo permanente e/o cosciente)] credono che il migliore incentivo per installare Gentoo siano queste maledette ottimizzazioni. Ognuno di noi vuole una macchina scattante e veloce, Gentoo, anche se a spesa di svariate ore di compilazione, può garantirci questa meta.

Personalmente le CFLAGS non mi giusticano il prezzo del biglietto: si può guadagnare qualcosa da questo tipo di ottimizzazione, ma, in media, il sistema non risulta molto più scattante che con una normale distro binaria. Le CFLAGS non sono l'arma segreta. Quello che secondo me fa la differenza fra Gentoo e tutte le altre distro sono le USE.

Cosa sono le USE? Si può facilmente spiegarlo con un esempio: immaginiamo di voler installare il nostro player audio preferito e si supponga che la nostra libreria di file multimediali sia composta solo da file OGG. Anche se il nostro player supporta 8500 formati audio, a noi ne interessa solo uno. Con una normale distro binaria non c'è modo di discriminare le "features" che un determinato applicativo deve garantire, su Gentoo si può. Un player audio compilato per supportare un solo formato audio (contro 8500) probabilmente risulta più scattante. Applicate questa logica a tutto il sistema e capirete che l'ottimizzazione non passa solo per le CFLAGS (o LDFLAGS/etc).

Ma le USE ci vengono incontro anche per le dipendenze: se il mio player deve riprodurre solo MP3 probabilmente non avrà bisogno di altre librerie esterne (legate ad altri codec audio). Gentoo ti fa dimagrire il sistema.

Ma Gentoo è Gentoo e non si ferma solo qui. Non solo ci aiuta nell'applicare queste ottimizzazioni ma addirittura controlla che tutto l'accrocchio funzioni. Controllo (con eventuale risoluzione) sulle CFLAGS problematiche per alcuni applicativi, USE necessarie per una coerenza del sistema e molto altro ancora.


Molti utenti cercano sempre l'ultima versione di un software. Questo è molto comprensibile in un sistema Desktop, purtroppo, soprattutto sotto GNU/Linux, l'ultima versione non è sempre la scelta ottimale. Un sistema operativo, come un mosaico, è composto da più tasselli e se i tasselli non calzano tutti a pennello, il sistema crolla (nel nostro caso non funziona nel migliore dei modi).

Gentoo, al contrario delle normali distro binarie, garantisce un approccio misto (sistema stabile Vs sistema iper-aggiornato): l'utente può eventualmente (ma in modo ufficialmente supportato) aggiornare (ad una specifica versione od all'ultima versione in testing) solo uno o più componenti.

E' quindi possibile, in modo semplice, avere installato sempre l'ultimissima versione di GNOME ma mantenere una stabile base per il sistema.


E quando dico ciò, intendo dire che è come un software fornito con la distribuizione: è mantenuto da sviluppatori, possiede eventuali bug ed è gestita da un apposito progetto (Documentation).

Molte distro non hanno una documentazione ufficiale o almeno essa ha un binario separato dallo sviluppo della distribuzione. Su Gentoo non è così, l'handbook (manuale base per l'installazione della distro) è sincronizzato con lo stato attuale di Gentoo. Sottolineo inoltre che la documentazione è realmente tradotte nelle principali lingue (una versione in una lingua qualsiasi non sincronizzata con la versione in inglese rappresenta un bug).


Ricordate l'obiettivo di Gentoo? Bene, non è un utopia, questi maledetti ci sono riusciti. Alcuni esempi:

• baselayout: gestire i demoni del proprio sistema non è mai stato così intuitivo e semplice. Per l'utente tutto si riassume nell'usare rc-update.

• eselect: in un sistema desktop spesso accade che per una stessa libreria/applicazione siano disponibili più soluzioni. Pensiamo a Java, un utente può poter aver bisogno delle JDK/JRE 1.4, 1.5 ed 1.6. Nulla di così straordinario e per questo Gentoo non ti lascia a piedi. Eselect permette di gestire molte situazioni (binutils, editor, fontconfig, java-vm, kernel, opengl, wxwidgets, python, etc).

• etc-update: da una versione all'altra di un determinato software, i suoi file di configurazione possono mutare considerevolmente. E' chiaro che non è carino vedersi sputtanata la propria configurazione (che magari ha richiesto parecchie ore di smanettamenti) per un aggiornamento. Gentoo ha trovato il modo di gestire questo problema: ve lo fa gestire a voi ma dandovi un adeguato supporto (esempio vi mostra le differenza fra il vostro file di configurazione e quello nuovo) per prendere le opportune decisioni.

• eix: capire quale versione di un pacchetto è disponibile (od installata), se è in testing, con quali USE è compilato; con eix si rivela un operazione banale ed immediata.

• revdep-rebuild: librerie sputtanate? ci pensa revdep-rebuild a capire e risolvere la magagna.

Ed ovviamente non posso che concludere citando il gestore di pacchetti portage, un tool semplicemente magico. Finchè non lo si usa, non lo si può apprezzare, pertanto eviterò di fare una banale descrizione di cosa sia in grado di combinare.


Gentoo, al contrario di altre distro famose, ha avuto la capacità di mantenere coesa la propria utenza. Unico forum ma con il necessario e dovuto spazio per tutti (inglesi, italiani, cinesi, etc). Unico wiki (attualmente in ristrutturazione e probabilmente non al meglio delle proprie potenzialità). Unico sito.

Questa coesione spesso si riflette in una grande capacità di assistenza per il singolo utente. Tanta esperienza (e competenza, vista il livello dell'utenza di Gentoo) al servizio di molti.


Gentoo Linux non è perfetta e come tutte le cose reali, ha conosciuto i suoi momenti critici. Le cause di queste crisi sono state molteplici, un giro per forum e mailing-list può (a lungo andare) chiarirvi un po' le idee su questo punto.

Sinceramente so troppo poco di Gentoo per dare giudizi, spiegarvi il perchè e il per come si è arrivati dove si è arrivati. Sicuramenti c'è stato (e c'è) molto acido intorno a Gentoo, almeno per certi aspetti. Però di una cosa sono sicuro: Gentoo ha superato questi momenti critici e ne ha saputo trarre insegnamento.

Una delle tante critiche rivolte (internamente ed esternamente) a Gentoo riguarda portage, c'è chi vorrebbe maggior innovazione, chi alcune strabilianti features o chi semplicemente pretende qualcosa per cui emerge non è stato originalmente pensato. Tanti gestori di pacchetti sono stati proposti alla comunity nel corso degli anni (uno su tutti è paludis) e per risolvere parte delle dispute (lunghe e dolorose) si è cercato di creare uno standard (PMS, Package Manager Specification) a cui tutti i gestori dei pacchetti dovrebbero far riferimento (e possibilmente implementarlo!).

Può sembrare un aspetto tecnico e poco interessante all'utente finale ma, in realtà, ci svela l'approccio costruttivo che si sta tentando di importare (e/o amplificare) per rendere sempre più Gentoo un progetto serio ed affidabile.


Ogni utente gentoo, usando questa distro, non può negare di aver appreso qualche nuova nozione su come funziona un sistema operativo. La sola procedura d'installazione manuale (semplice ma laboriosa) può farci imparare più di un quanto 3/4 anni di una normale distro possano fare (ovviamente dipende da cosa si fa).

Gentoo sprona (in modo violento direi) l'utente ad essere cosciente di cosa accade nel proprio sistema. Non possiamo dire che spiega il come accade (aver installato gentoo non rende l'utente un sysadmin o sviluppatore di sistema), ma certamente ci da modo di approfondire qualche aspetto.


Penso che Gentoo sia un'ottima distro, incontra perfettamente le mie necessità e richieste. Ovviamente ciò non vuol dire che Gentoo sia la soluzione ideale per ogni utente. In ogni caso spero di aver fornito alcune (valide) motivazioni per invogliarvi a provare questa distribuzione GNU/Linux.

Sleep display under GNOME

Se state sbattendo il muso contro questo bug (presente almeno fino a GNOME 2.26 sulla maggior parte di distribuzioni) potete creare uno script in /usr/bin/set-sleep-display con:

Il comando xset imposta un timeout di 180 secondi prima di attivare lo stato di poweroff per il display. Lo sleep è necessario perchè, all'avvio di GNOME, gnome-power-manager resetta i timeout.
Rendiamolo eseguibile:

E aggiungiamo una entry per l'avvio di questo script in GNOME > System > Preferences > Startup Applications.

Saluti.

MacBook & Gentoo Linux

Ecco i dettagli per installare Gentoo su un MacBook Unibody (la prima serie), ossia:





Ho optato per un sistema x86 (anche se nell'arch amd64 stanno arrivando interessanti novità, vedi nuova multilib ABI):

Dove -march=native (supportato da >=gcc-4.2) si rivela (al momento) in:



Per non aver noie con il reboot, è necessario installare un kernel della serie >=2.6.31, nel mio caso ho optato per (ancora in ~x86):

Ecco il relativo config da me usato:
• config-2.6.31-5
• config-2.6.31-10 (versione migliorata basata su gentoo-sources-2.6.31-r6)

Che, a parte qualche opzione non indispensabile (nelle prossime settimane con più calma farò un po' di pulizia) riesce a supportare le seguenti caratteristiche:
• framebuffer (UVESA)
• sensori ventole e temperature (applesmc, coretemp, i2c-nforce2)
• suspend on ram (hibernate non mi interessa)
• FS ext3, ext4, NTFS, FAT
• bluetooth (btusb, rfkill, bluetooth, rfcomm, bnep, l2cap)
• * regolazione luminosità (backlight)
• accelerometro (applesmc, joydev)
• ethernet (EISA, VLB, PCI and on board controllers > forcedeth)
• * wireless (lib80211, lib80211_crypt_* [N.B. occorre abilitare driver come HOSTAP per abilitarli implicitamente])
• IR (uinput)
• webcam (v4l1_compat, uvcvideo, videodev)
• * scheda grafica Nvidia (agpgart)
• trackpad (Apple USB BCM5974 Multitouch trackpad support)
• scheda audio (snd_hda_intel, snd_hda_codec, snd_hda_codec_realtek, snd_pcm_oss, snd_pcm, snd_seq, snd_timer, snd_hwdep, snd_mixer_oss,snd_seq_oss, seq_device, soundcore, snd)

Fra le parentesi ho indicato il componente (spesso ho indicato il nome del modulo) fondamentale da abilitare per ottenere un corretto rilevamento e funzionamento della specifica caratteristica. Le voci che sono precedute da un * richiedono dei moduli esterni al kernel (in seguito trattati).


Per far caricare il mio sistema correttamente ho adottato i seguenti parametri:

In particolare:
• rootfstype=ext4 per eliminare un warning durante il boot (erroneamente il kernel tenta di accedere ala partizione root ext4 come ext3)
• video=uvesafb:1280x800-32,mtrr:3,ywrap parametri per configurare UVESA


Per ottenere il 3D è necessario installare i driver binari Nvidia (x11-drivers/nvidia-drivers). Consiglio versione >=190.42-r3 (attualmente in ~x86).


I driver binari Nvidia non forniscono la dovuta infrastruttura per poter regolare la luminosità, pertanto è necessario installare un modulo ad-hoc. Il modulo mbp_nvidia_bl (incluso nel kernel vanilla), per motivi a me non chiari, non permette di regolare la luminosità sotto X (ma ad esempio con un MacBook Pro non si riscontra lo stesso problema) e quindi è necessario appoggiorsi al modulo esterno nvidia_bl (realizzato dal MacTel Team ed in particolare da Mario Schwalbe).

Essendo quest'ultimo non incluso in portage, ho dovuto creare un ebuild amatoriale (in realtà ho praticamente copiato da altri ebuild) e reimpacchettare il sorgente (modificando il Makefile) del modulo per agevolarne l'installazione. L'ebuild non è assolutamente testato e ne sconsiglio l'adozione ma, se stato con l'acqua alla gola e non sapete fare meglio di me, potete scaricarlo da:
• nvidia-bl-0.14-r1.ebuild
• nvidia-bl-0.14-r2.ebuild

Nelle prossime settimane cercherò di migliorare l'ebuild. Eventuali nuovi rilasci del modulo da parte del MacTel Team verranno sincronizzati con esso.

Personalmente inserisco in /etc/conf.d/local.start:

Per abbassare all'avvio la luminosità. Inoltre se vi interessa regolare la luminosità attraverso i classici tasti anche sotto VT/tty (intendo non sotto X) è opportuno installare app-laptop/pommed (aggiungerlo al runlevel).


E' necessario installare i driver proprietari net-wireless/broadcom-sta (attualmente in ~x86). Per connettermi alla mia rete domestica mi sto appoggiando a wpa_supplicant con la seguente configurazione:



Non volendo però rinunciare a NetworkManager o Wicd, mi è sufficiente eseguire i seguenti passi per poterli usare:
• eliminare eventuali link net.eth*
• rimuovere dai runlevel net.eth*
• in /etc/conf.d/rc inserire RC_PLUG_SERVICES="!net.eth0 !net.eth1"
• inserire nel runlevel NetworkManager o wicd
• avviare in GNOME nm-applet o wicd-client

In particolare per NetworkManager ho modificato /etc/NetworkManager/nm-system-settings.conf con:


N.B. come fa correttamente notare emerge per eseguire correttamente NetworkManager è necessario dare:



Sono riuscito ad inviare e ricevere files via bluetooth sfruttando net-wireless/bluez-gnome (per eseguire correttamente il pairing con il dispositivo) e net-wireless/blueman (scambio file).


Dal kernel >=2.6.30 è stato rimosso il driver appleir ed è necessario sfruttare uinput che però presenta alcuni svantaggi (no auto-repeat, need to wait a couple of seconds between key presses to register two key presses).

Installiamo Lirc (aggiungendolo al runlevel) e editare /etc/conf.d/lircd con:

Per il /etc/lirc/lircd.conf potete usare quello standard (/usr/share/lirc/remotes/apple/lircd.conf.macmini) o questo (adattato alle mie necessità):



Una configurazione che trovo equilibrata:

Inoltre sono solito eseguire in GNOME:



Editare /etc/asound.conf con:



Installare sys-power/pm-utils.


Installare ed aggiungere al runlevel: sys-power/acpid, sys-power/acpi, sys-power/acpitool, app-laptop/laptop-mode-tools, sys-power/cpufrequtils, sys-apps/lm_sensors.

Inoltre in /etc/pm/sleep.d/ e /etc/pm/power.d/ ho inserito il seguente script:

Con questi accorgimento la batteria ha una durata di ~3 ore (contro le 4-5 ottenibili con Mac OS X).

Saluti.