Infatti, tra un impegno ed un altro, mi sono accorto sul forum di Arch Linux, e non solo, di dover fornire spiegazioni riguardo questa utility, che non è, d’altronde, ricca di documentazione e spiegata come vorrei (e come vorrebbero). :P

Innanzi tutto, una breve introduzione: chroot serve per entrare in una data directory provvista di filesystem Unix e, all’interno di questa, bash, per sfruttarla alla stregua di una vera e propria directory radice, allo scopo di eseguire programmi o riparare, come mi è successo spesse volte, problemi vari. Nello specifico, mi sono trovato a spiegare chroot nell’ambito della risoluzione di problemi legata a sistemi che, in circostanze varie, non eseguono correttamente la procedura di boot, per cui non ci si può loggare all’interno del sistema per riparare i danni.

Chroot quindi, oltre che una utility per scopi più o meno noti, può servire da trucchetto d’emergenza per riparare al fatto di aver fatto una razzata; spesso si sente dire “Linux va formattato solo in caso di problemi gravissimi”. Ebbene, questo è falso, perchè in caso di problemi gravissimi abbiamo il nostro chroot pronto a darci una mano in qualsiasi circostanza :D

Ma vediamone per bene il funzionamento: innanzi tutto, abbiamo bisogno, come ho detto su, di una subdirectory con un filesystem Unix e la bash installata; nel caso in cui dovessimo riparare dei danni, la nostra partizione target può diventare facilmente una subdirectory del sistema operativo che stiamo utilizzando tramite una semplice operazione di montaggio. Creiamo quindi il punto di aggancio:

sudo mkdir /media/target

E montiamo, finalmente, il nostro pseudo-filesystem, o la partizione bersaglio dei cambiamenti che vogliamo effettuare, legandolo in questo modo alla nostra root reale.

mount /dev/sdaX /media/target

A questo punto, se vogliamo solo modificare dei file senza compiere operazioni che interessino i dispositivi o i dati presenti in /proc, possiamo anche saltare il montaggiodi altre parti del nostro sistema base nel sistema bersaglio. Però, c’è un però.

Però, se vogliamo compiere operazioni come un aggiornamento, che interessa ovviamente alcuni dati di /dev e alcuni dati di /proc, conviene rendere disponibili queste informazioni al sistema ospite; come fare? Tramite altri due comandi di montaggio, il primo che riguardi la directory /dev, e l’altro che interessi /proc: in questa maniera rendiamo leggibili le informazioni riguardo l’hardware della macchina al sistema ospite, che potrà, in parecchi casi, averne bisogno. Per esempio per una ricompilazione del kernel. Per esempio.

Ordunque, andiamo a montare /dev con alcune opzioni che non so minimamente cosa significhino, ma dato che sono scritte sul Gentoo Handbook e le ho usate moltissime volte le prendo per buone :mrgreen:

sudo mount -o bind /dev /media/target/dev

E andiamo poi a montare uno pseudo-proc, almeno da quanto ho capito per via della sintassi di comando leggermente più articolata.

sudo mount -t proc none /media/target/proc

Per una spiegazione completa dei comandi integro il commento del buon Alex Anghelone, che ci dice a cosa serve tutto questo:

Il modulo bind di mount serve per montare un determinato percorso in più punti, un pò come il link simbolico ma molto più potente in quanto viene gestito come una specie di partizione condivisa. Per dire, il repository di arch sul portalinux risiede fisicamente sulla home del tuo utente ma viene montato col modulo bind dentro la doc root del sito per renderla visibile :)

-t proc invece monta il filesystem di tipo proc, sostanzialmente ci hai azzeccato solo che non ti monta uno pseudo-proc, ma un proc vero e proprio solo che lo fai a manella :D quando avvi la tua distribuzione gli script di init danno quel comando li per montarti /proc sul sistema.

A questo punto, siamo pronti. Possiamo tuffarci nel sistema ospite, ed iniziare riparazioni, modifiche, aggiornamenti, installazioni e quant’altro:

sudo chroot /media/target

Come vediamo, il PS1 è cambiato, e rappresenta il .bashrc che abbiamo impostato per l’utente root sulla directory target, nella quale adesso siamo loggati come root e possiamo effettuare ogni tipo di modifica.

Per uscire dalla nuova directory radice, ovviamente, basta un semplice comando exit ;)

In questo modo, si possono far eseguire programmi in una sandbox a prova di bomba, in quanto non condivide nulla, a parte qualche informazione, con la macchina ospitante. Godetevi il vostro chroot, e cominciate a usarlo massivamente per i compiti più disparati. Posso veramente dire: chroot, mai più senza :mrgreen:

Tutti sappiamo (ssiiiii…) che Firefox, dalla versione 3.0, utilizza sqlite per memorizzare i siti visitati e tante altre comode informazioni, che ad ogni avvio vengono ovviamente ricaricate, all’occorrenza. Per applicare perciò questo tocco di classe al nostro browser, dobbiamo installare SQlite (grazie a MaxFact per il consiglio su cosa installare):

sudo apt-get install sqlite3 iprint


e spostarci nella directory relativa al nostro profilo di Firefox:

cd .mozilla/firefox/*.default

Adesso, arriva il trucco vero e proprio. Utilizzando SQlite, possiamo ottimizzare il database riordinando le tabelle e non avere più quella pletora pietosa che causa tanta lentezza e netti cali di prestazioni, sia su Linux che su altri sistemi operativi.

Per Linux…

for i in *.sqlite; do echo "VACUUM;" | sqlite3 $i ; done

E per Windows.

for %i in (*.sqlite) do @echo VACUUM; | sqlite3 %i

Per OSX non so come si faccia, ma essendo un sistema Unix-like, provvisto di bash, mi viene il sospetto che il comando sia lo stesso che in Linux. (Confermata la mia ipotesi corretta, grazie Dreamquest!)

Tutto ciò ovviamente è preferibile farlo con Firefox chiuso ;)

Adesso avviate Firefox e… magia :)

Ho deciso quindi di dare qualche linea guida sulla compilazione in ambiente Debian et similia, quindi il procedimento che andrò a descrivere è ovviamente valido anche per Ubuntu, e tutte le sue derivate.

Innanzi tutto, installiamo un po’ di dipendenze necessarie alla compilazione. Questo serve necessariamente o la compilazione si pianta, e basta. Quindi, apriamo un terminale e diamo un bel…

sudo aptitude install automake bzr mono-gmcs libmono-cairo2.0-cil gtk-sharp2 libndesk-dbus-glib1.0-cil libndesk-dbus1.0-cil libgnome-vfs2.0-cil libgtk2.0-dev libtool intltool gnome-sharp2 ca-certificates bazaar gnome-keyring-sharp-cli gnome-desktop-sharp2 libgconf2-dev monodevelop-nunit

Beh, con questo installeremo tutto ciò che serve. Adesso, provvediamo a clonare l’ultima revisione dal Bazaar di Canonical dove è ospitata: ci basta un

bzr branch lp:do

Dopodichè, finito il checkout, troveremo nella nostra directory Home una cartella “do”. Andiamo lì dentro, quatti quatti.

cd do

E, senza indugio, provvediamo a configurare i sorgenti per essere compilati e, successivamente, installati.

./autogen.sh --prefix=/usr && ./configure --prefix=/usr

Dunque, godiamoci il terminale che ci sputa scritte a raffica, dopodichè quando smette,

make

Questo compilerà il sorgente. Ultimo, ma non per importanza, il comando per l’installazione.

sudo make install

Il quale provvederà ad installare il programma nel nostro sistema.

Una scintillante icona apparirà in Applicazioni → Accessori, e noi potremo goderci l’ultima revisione di GNOME Do correttamente compilata da BZR.

Ebbene, l’altro ieri, preso dalla mania di avventurarmi sempre di più in questo panorama sconfinato, ho aperto un account Identi.ca. Mi sono poi accorto che non esistono estensioni per Firefox o programmi decenti da usare come client per Linux, così mi sono dedicato a qualche minuto di ricerca per trovare un’applicazione recondita che facesse al caso mio.

E l’ho trovata, eccome se l’ho trovata!

Premetto che è ancora in stadio di alpha, signore e signori, ecco a voi Gwibber :D

Dopo un po’ di macello per farlo andare (alpha, ricordatelo sempre!), mi sono sistemato egregiamente su questo software che non solo mi permette di postare su network di microblogging diversi, ma posta esattamente lo stesso messaggio su tutti gli account abilitati all’invio messaggi. In poche parole, è come avere, nel mio caso, Twitter e Identi.ca sincronizzati. :)

E se rispondessi ad un twit, o ad un “dent”?

Niente paura: le risposte vengono inviate solo al network dove si trova l’utente al quale si sta rispondendo.

Insomma, non male questo Gwibber, che come si può vedere nel menù Accounts non supporta solo i più popolari servizi di microblogging, ovvero Twitter, Identi.ca, Pownce e Jaiku, ma offre la possibilità di interagire con alcuni dei più gettonati servizi web 2.0, ossia Flickr, Facebook e Digg.

L’interfaccia è disegnata in PyWebKitGTK, una bella mescolanza di elementi interessanti che contribuiscono tutti a creare quel fantastico look ‘n feel che potete ammirare nell’immagine.

Che dire, ne seguirò lo sviluppo utilizzandolo come applicazione da microblogging fissa. Non è ancora a livello del blasonato Twhirl, ma siamo sulla buona strada.

Per installare il client sulla vostra linux-box, potete usare la guida disponibile sul wiki di Ubuntu, da mettere in pratica in modo letterale se si usa la distro africana, da adattare leggermente se si usa Debian o un’altra derivata.

Per ArchLinux abbiamo, come di consueto, il PKGBUILD in AUR, che però non funziona a meno di non adattare anche lui: basta sostituire

_bzrtrunk=http://bazaar.launchpad.net/~segphault/gwibber/webkitui

con

_bzrtrunk=lp:gwibber

Semplice no? :lol:

Siccome non penso di voler mai sprecare un secondo del mio tempo a compilare sorgenti SVN di KDE, mi affido quotidianamente ad un repository altamente nocivo per Arch che ho scoperto solo di recente.

Vediamo quindi come installare KDE 4 sulla nostra Arch Linux, impacchettato quotidianamente; consiglio la lettura della procedura nel suo insieme, per evitare sorprese :D

Aggiungiamo in cima al nostro pacman.conf le seguenti righe:

[kde]
Server = http://pkg.markconstable.com/kde/i686/

Per Arch 64 basta sostituire “i686″ con “x86_64″.

Adesso, occhio: desumo dal nome dei pacchetti che si sovrascrivano a KDE 3, quindi, cari utenti Arch che avete KDE 3.5, in caso non vi piaccia KDE 4 dovrete reinstallare successivamente la versione di Arch. Per gli utenti Gnome invece non sono indicati particolari problemi.

pacman -Sy kde-svn

Questo installerà KDE 4 sulla nostra macchina. Se vogliamo tutti i frizzi e i lazzi al completo, allora il gruppo da installare è kde-svn-all.

Forse dovremo forzare addirittura l’installazione dei pacchetti per far andare alcune cose, ma non c’è da preoccuparsi; non ho riscontrato particolari malfunzionamenti.

Mentre scarica e installa, prendetevi un caffè dato che sono un bel po’ di pacchetti :D

Fatto? Fatto! Riavviamo X e godiamoci KDE 4.

Adesso non ci resta che divertirci e personalizzare un po’ il tutto, specialmente Plasma…

Tornando a Gnome e rimuovendo KDE 4, mi è successo di dover ripristinare la copia di backup fatta in precedenza del file dei menù, poichè mi era misteriosamente scomparso Applicazioni:

sudo mv /etc/xdg/menus/applications.menu.pacsave  /etc/xdg/menus/applications.menu

Beh, questo è tutto.

Spero che per gli arcieri sia stata cosa utile :D