OpenGL ES, ossia OpenGL for Embedded Systems è un particolare comparto del famoso framework grafico che si avvantaggia delle API messe a disposizione dai dispositivi integrati per aumentare le prestazioni, specialmente sui chipset Tegra2 e altri componenti di quel “parentado”. Kwin fa uso di tutto ciò? Dall’ultima release, certo. Possiamo quindi ricompilare un pezzo di KDE (compreso il gestore di finestre) per abilitare tutto ciò, e possiamo farlo facilmente dal momento che abbiamo ABS come nostro potente alleato. Andiamo quindi in una directory vuota che adotteremo come workspace:

$ yaourt -G kdebase-workspace

Al posto di usare yaourt potete anche sincronizzare con il comando abs tutto il tree e copiarvi il PKGBUILD a mano, ma sinceramente così è più comodo, anche se richiede che abbiate installato, ovviamente, il blasonatissimo tool.

Purtroppo dobbiamo ricompilare tutto il workspace solo per quattro cose di KWin, ma pazienza. Dobbiamo solo aspettare che il processore faccia il suo sporco lavoro per compiacerci. Intanto installatevi libgles e libegl, poi a questo punto:

$ cd kdebase-workspace && vim PKGBUILD

Al posto di vim potete usare l’editor di testo che preferite, basta che agiate con cognizione di causa :D

Dopo aver aperto il file, localizzate facilmente queste righe:

-DKWIN_MOBILE_EFFECTS=OFF \
-DWITH_OpenGLES=OFF \
-DKWIN_BUILD_WITH_OPENGLES=OFF

E tramutatele in:

-DKWIN_MOBILE_EFFECTS=OFF \
-DWITH_OpenGLES=ON \
-DKWIN_BUILD_WITH_OPENGLES=ON

Perfetto. Abbiamo abilitato ciò che ci serve. Adesso, possiamo tranquillamente lanciare il processo di build:

$ makepkg

Attendiamo. Io ho un dual core e tutto il compilame vario ha impiegato una quindicina di minuti per finire il tutto; sicuramente sul vostro esacore con hypertreading ci metterà molto meno. Appena finito, dopo una breve (spero per voi o dovete far controllare l’hard drive) fase di impacchettamento, makepkg ci sputerà fuori un pacchetto pronto per essere installato sul nostro sistema.

# pacman -U *.pkg.*

Con questo comando andiamo a sostituire il pacchetto creato dal buon Andrea ‘BaSh’ Scarpino (che ringrazio per la distribuzione di KDE che ci offre, sempre impeccabile) con il nostro. Riavviate e godetevi lo spettacolo… spettacolo che, ovviamente, per chi non gode di OpenGL ES si concluderà con un imbombamento generale del compositing di KWin. Per voi fortunati che avete schede video compatibili con queste estensioni, se non fate questo procedimento sarete passibili di pena di morte. Ché io non posso.

Semplicità prima di tutto

Pacman è un gestore di pacchetti semplice, sia come ovvio nel funzionamento e nel comportamento, che nella sintassi: è infatti molto più comodo, almeno per me, usare Pacman piuttosto che qualsiasi altro gestore di pacchetti. Appendendo infatti lettere singole alle opzioni più generali possiamo generare comandi che eseguano più di una azione, così se di solito abbiamo bisogno di più comandi o di stringhe chilometriche ed espressioni regolari lunghe un miglio, il package manager di Arch Linux ci viene incontro mettendo a nostra disposizione la possibilità di fare millemila cose con un solo, brevissimo comando.

In cosa si traduce questo? Beh, ovviamente si traduce nel fatto che possiamo usare tutte quelle ore sprecate a digitare caratteri su caratteri in qualcosa di molto più proficuo, come patchare un software o rimediare a qualche configurazione errata di sistema che sicuramente avrete dimenticato nel posto sbagliato al momento sbagliato. Quindi insomma, niente di trascendentale se uno ha le competenze, ma tutto di guadagnato.

C’è poi un discorso di funzionamento di base, che almeno a me è molto comodo: se altri gestori complicati incorrono per esempio in problemi di dipendenze e configurazioni lasciate in sospeso, grazie al fatto che la configurazione viene svolta in gran parte dall’utente e c’è molta poca dinamicità in fase di installazione, comunque una volta dato un comando di gestione dei pacchetti è veramente molto difficile se non impossibile che il package manager si pianti a metà del lavoro dicendo che c’è quel pacchetto non configurato e quell’altro in attesa di cose mistiche. Altro tempo libero dunque, che possiamo dedicare a leggere un buon libro, ad esempio L’Etica Hacker di Pekka Himanen.

Flessibilità quanto basta (cioè molto)

Sicuramente Pacman è concepito in maniera tale da risultare molto flessibile. Il suo concetto di semplicità fa si che con un comando io possa agire chirurgicamente sui pacchetti installati, rimuovendone alcuni senza compromettere il funzionamento del sistema di gestione del software, fregandomene poi di tutto ciò che è il sistema di dipendenze. Questo significa che per sostituire un pacchetto dipendenza di altri, mi basta rimuoverlo e, facendo un po’ d’attenzione, inserire il mio nuovo pacchetto non dando troppo fastidio ai software in esecuzione: in questo modo avrò personalizzato il sistema senza dover scoperchiare necessariamente tutto; la magia è resa possibile dal fatto che Pacman viene distribuito insieme ad un set di script che lo completano e che sono il suo vero punto di forza.

Se infatti la gestione del software risulta semplice ed agevole, comunque la flessibilità estrema (anche se non quanto Portage ovviamente) viene raggiunta concependo Pacman non come un sistema di gestione dei pacchetti, ma come un sistema di ibridazione tra la manutenzione tradizionale dei programmi tramite il paradigma a pacchetti, e la gestione dei ports. I ports sono quella cosa che ha reso tanto famosi BSD e Gentoo: file di testo addetti a istruire un sistema di script su come compilare ed installare un determinato tarball. Assieme a Pacman abbiamo quindi makepkg che si occupa di creare pacchetti dai PKGBUILD, ossia i file testuali che noi o altri scriviamo per compilare un software senza problemi. E assieme a Pacman e makepkg, ci viene fornito l’ABS, ossia l’Arch Build System, il quale consiste di tutti i file PKGBUILD dei pacchetti presenti nei repository ufficiali.

Avete capito bene. Questo significa che se non ci sta bene come è stato compilato un pacchetto dagli sviluppatori della distro, possiamo prenderci il PKGBUILD, personalizzare tutto in base alle nostre esigenze, dai metadati di pacchetto alle flag, al processo di build, e poi darlo in pasto a makepkg che ci sputerà fuori dopo la fase di compilazione e impacchettamento, un pacchetto fatto da noi secondo le nostre esigenze. Questa modularità fa si che Pacman possa essere utilizzato in maniera assolutamente proficua anche per server, o per configurazioni particolari che magari hanno bisogno del tale software compilato in una certa maniera (flag particolari, e quant’altro).

In aggiunta a questo, è anche semplicissimo e facilissimo mantenere un repository per Pacman, soprattutto con l’ausilio di un paio di scriptini editi dalla comunità, ma di questo magari ve ne parlo un’altra volta.

Pacman sa farsi da parte

Volete il pezzo forte? Il bello di Pacman è che se non ci sta bene come funziona, possiamo sostituirlo. Ebbene si, possiamo mandarlo a quel paese allegramente e gestire il nostro software in mille altre maniere :D

Questo è possibile grazie alle libalpm, ossia le LIBraries for Arch Linux Package Management, scritte in maniera separata da Pacman, il quale è solo un wrapper di questi file: esistono package manager alternativi, come il famosissimo Clyde, che purtroppo è defunto da poco per mancanza di tempo da parte dello sviluppatore principale; tra l’altro, essendo stato io un utente di Clyde in passato, invito fortemente chi sa programmare (non io che sono, detto chiaramente, una pippa come developer) a prendere in mano il progetto. Insomma, Pacman sa fare le cose in maniera semplice, pulita, non sporca, mangia poco e disturba ancora meno, come abbiamo visto. Ma vale veramente la pena passare ad Arch Linux (e a Pacman) se si vive bene senza?

Pacman VS The Others

Non ho molte parole da spendere in questo caso. Posso dire che, sicuramente, utilizzare una distro come Arch Linux che ha un approccio radicale e assolutamente nuovo al software, è un’esperienza di vita. Se quindi siete un po’ annoiati una domenica pomeriggio, anzichè sbragarvi sul divano a fare niente, prendetevi Virtualbox e mettete su una bella macchina virtuale con l’ultimo media di installazione di Arch impostato per il boot. Sicuramente, non solo vi divertirete un mondo, ma forse vi piacerà così tanto come è fatta la distribuzione, e come è fatto Pacman, da dargli una chance sulla vostra workstation.

Sicuramente il buon Pacman manca di un’interfaccia grafica adeguata; APT possiede ad esempio Synaptic, ma proprio per questo, se per fare operazioni complesse con APT abbiamo bisogno del suo blasonato frontend, grazie alla semplicità di cui sopra Pacman non ha bisogno di queste cose: dalla CLI abbiamo tutto ciò che ci serve, senza doverci complicare ulteriormente la vita.

Che la Forza sia con voi.

Fabio ha dato una sua opinione su Ubuntu, e sul perchè tende a creare come dice lui “utenti lobotomizzati”. In realtà, la distro africana non fa niente di più di ciò che fa un OS con vari meccanismi di astrazione e automatizzazione dei processi di gestione: rende all’utente più facile la vita, non mettendolo al corrente di ciò che accade a basso livello. Ora, per carità, opinione legittima, ma paragonare Ubuntu a Windows, caro Fabio, mi sembra un’evidente forzatura. E ti spiego anche perchè, senza la minima presunzione, sia chiaro, di darti lezioni su cose che già sai: esprimo solo il mio punto di vista.

Ubuntu VS Windows – La differenza sostanziale

Le parole che sono volate sono state immense, e magari per un magazine più settoriale sarebbero state meno generiche, comunque si è detto che Ubuntu contribuisce a creare utonti, cosa che reputo assolutamente non vera; Ubuntu infatti mette a disposizione dell’utente una comunità, un wiki (seppur non il più fornito), e soprattutto è Linux: un sistema, ovvero, che non nasconde affatto le sue meccaniche al curioso, bensì lo sprona ad addentrarsi. File di configurazione ben commentati, una base Unix, e un approccio al software comunque sempre molto open fanno di Ubuntu una distribuzione che difficilmente può essere equiparata a Windows in quanto a lobotomizzazione dell’utente: se qualcosa non funziona o non piace, si è liberi di modificare il sistema in ogni suo aspetto, ovviamente seguendo il manuale o, con un po’ più di fantasia, avendo le determinate competenze.

Per questo motivo quindi reputo che, in un’ottica end-user Ubuntu vada bene per la maggior parte degli utenti; l’utente smaliziato ha a disposizione Vi, la Bash, ed un “framework” che gli consente di essere piuttosto libero nelle scelte, anche se ovviamente Ubuntu si presta meno di Sabayon o Arch alla flessibilità estrema.

Usare un computer != essere hacker

Quando vengono fatte affermazioni sull’utenza di un determinato OS, e sul suo target, bisogna stare sempre piuttosto attenti a definire ciò di cui si parla, per non rischiare di fare, come si suol dire, di tutta l’erba un fascio: certo, Sabayon e Ubuntu (contestualizzando) sono due sistemi operativi basati su Linux con delle interfacce grafiche e una riga di comando, ma ci sono differenze sostanziali tra i due; la principale è che in realtà si rivolgono a due target differenti. Per quanto infatti una distribuzione che metta a nudo le sue meccaniche sin dall’inizio possa risultare affascinante anche per persone non propriamente addentro, comunque l’utente tipo, la persona comune, vuole utilizzare il proprio PC installando software ed eseguendo programmi senza incorrere nel minimo problema; già il meccanismo di copia-incolla è qualcosa che mia nonna di 75 anni fatica a capire.

Lo so, la mia affermazione è un po’ da bastardo, però reputo vero quanto ho detto: pretendere che ogni individuo vada a smanettare nel proprio sistema operativo installato è un po’ come pretendere che, guidando un’automobile, siamo tutti meccanici. Arrenditi all’evidenza Fabio: per quanto un automobilista possa interessarsi di motori e possa essere bravo, se gli si ferma la macchina in piena autostrada non può fare altro che chiamare il carro attrezzi. Certo, c’è da dire che Ubuntu potrebbe mettere a disposizione qualche tool in più, magari sviluppato in maniera comunitaria, per esplorare il sistema più a fondo e analizzarlo in maniera meno macchinosa (APT non aiuta), cosa che invece le distro user-centriche fanno, ma giustappunto perchè mettono l’utente al centro del processo di manutenzione del sistema, non per altri motivi.

Il fatto quindi che Ubuntu mantenga coperto da un velo il suo basso livello è solo un’accortezza, uno stratagemma per non spaventare il potenziale utente e, perchè no, il potenziale hacker: nonostante la curva d’apprendimento altissima di Arch e Gentoo mi abbia salvato molte volte dalla piatta noia giornaliera, comunque io ho apprezzato i sistemi Linux arrivando da Ubuntu e Mandriva, ossia due distribuzioni che ti si “aprono” solo se lo desideri. [Ok, al tempo dovevi aprirle per forza tra ndiswrapper e altro]

RTFM ma con moderazione

Ubuntu quindi produce lobotomizzati? Ma no, gli smanettoni ci sono ancora e ci saranno sempre, solo che questo processo di brandizzazione e di maschera delle meccaniche alla base del sistema è un ammiccare alle masse del kernel Linux, ecco.

Tuttavia, Fabio, hai anche un po’ ragione. Non riguardo i potenziali hacker, che continuo a dire che sono una razza assolutamente non in via di estinzione, anche se quelli migliori si sono un po’ sedati negli ultimi tempi, ma riguardo proprio l’utente di tutti i giorni, e non parlo di riga di comando o cose astruse: parlo di consapevolezza. Se infatti è vero che un utente tipico vuole solo usare la macchina, senza preoccuparsi dell’OS, è vero però che deve esserne sensibilizzato all’uso, deve capire cosa diamine fa quando preme un tasto sulla sua tastiera, deve fare un uso consapevole del mezzo che, ad oggi, non è più solo un elaboratore di uni e zeri, ma un HUB di condivisione di contenuti.

Peccato che io non abbia ancora visto in giro un insegnante di informatica disposto a scendere dal suo ridicolo piedistallo fatto di tracotanza e presunzione, per abbracciare un utente e dirgli, veramente, col cuore: “Vieni, ti insegno io come si fa”.

Oddio, è vero anche che non ho visto nemmeno così tanti utenti ben disposti nei confronti di “quell’ammasso di ferro”, come lo denominano piuttosto generosamente i meno abbienti.

Comunque… questo post avrebbe dovuto essere molto più lungo, ma credo di essermi lasciato andare abbastanza.

A proposito, alla fine di questo delirio senza capo nè coda, voglio cogliere l’occasione per fare i complimenti a Fabio per la sua prima patch sul GIT di kernel.org… già che si parlava di kernel :D

Sebbene sia anch’io molto tentato dalla distro di Canonical, comunque resto ad Arch per tutta una serie di motivi che sono perfettamente elencati nelle righe scritte con la mente ma soprattutto col cuore da Pierluigi. E il mio commento è: vai Pierlo, io ti seguo a ruota :P

Questa release porta notevoli cambiamenti (miglioramenti?) per quanto riguarda la struttura della distro; se infatti prima si dovevano eseguire a mano i vari script in /etc/rc.d/ relativi ai demoni per le azioni di start|stop|restart o altre varie ed eventuali, adesso tramite l’applicazione rc, appunto, residente in /sbin, possiamo listare, far partire e stoppare i vari servizi in maniera molto più comoda ed elastica.

Questo proprio per tornare a bomba su quello che ho scritto in coda al mio ultimo post: chi ha detto che la consolle dev’essere un luogo scomodo e freddo? ;)

E dunque gli sviluppatori ci hanno donato questa piccola perla, che ci permette di amministrare il nostro sistema con maggiore scioltezza, con uno stampo tipicamente improntato alla facilità di controllo dal lato prettamente sistemistico, come se dell’approccio BSD-like in Arch non ce ne fosse abbastanza (cosa che ovviamente a me non dispiace affatto).

Go go go!