14 febbraio 2011

Puntualità

Lo sapevo. Ci doveva essere e non poteva mancare. Lo sapevo che Il Giornale non mi avrebbe deluso.

Perché se porti i bambini la domenica mattina mattina a piazza S. Pietro con in mano la bandierina di Padre|Beato|San Pio da Pietralcina o se li vesti da dentro in fuori, dalla testa ai piedi di abiti griffati A.S. Roma va bene ed è giusto e legittimo¹, ma se li porti a una manifestazione che in un certo qual modo riguarda il loro futuro e che per forza di cose è in un certo qual modo schierata allora diventa uso strumentale del minorenne e tu sei automaticamente incluso nel novero dei dittatori totalitaristi.

Che poi, giornalisticamente parlando, la notizia quale è? Che c'erano bambini e bambine e che nessuno li stava mangiando o molestando?

[1] S.S. Lazio no, mai.

10 febbraio 2011

What the ƒŰʗג

Comunicazione di servizio: unzip(1) è morto, viva unzip(1).

Se anche tu, come me, usando Linux ricevi ogni spesso archivi ZIP creati in Microsoft Windows versione QuellaCheTiPare e se i documenti ivi archiviati presentano nomi con lettere accentate o in generale non ASCII, ti sarai accorto di come tali documenti non vengano estratti in modo corretto, lamentandosi del fatto che è stata usata una codifica sconosciuta.

Il motivo? Non. Lo. So. E al momento non mi interessa investigarlo troppo, ma di certo è da qualche parte tra File Roller e unzip(1).

Ci sarà mai soluzione? Nel frattempo c'è un bug e un possibile workaround (che a me però non ha funzionato sui file di test): installate 7zip.

A quanto pare quest'ultimo è diventato da tempo il preferito tra i backend usati da File Roller per la gestione di ogni formato compresso degno di nota (vista la "svaria" di formati supportata da 7z(1)).

Meglio? Peggio? Serve? Io per ora l'ho installato e sul file di prova ha fallito, comunque aspetto aspetto fiducioso di ricevere un bel file "reale" per una controprova (e nel caso emozionarmi come un bimbo). Voi siete avvisati. Ora, chi avvisa i distributori?

7 febbraio 2011

GNOME Shell - Per molti ma non per tutti

Già sento nello orecchie la voce di Luigio Guastardo della Radica che dice "Ah, la tauromachia!"

Già sento, soprattutto, nelle orecchie i borbotti e i mugugni di chi sta pensando che questo è il solito post pieno di rantoli e lamentele inutili. Ma i fatti sono fatti e le mugugni stanno zero, per cui, principiamo.

C'era una volta un ambiente desktop di nome GNOME la cui mission, per parlare in termini moderni, era quello di mettere a disposizione di chiunque un ambiente desktop libero. Erano i tempi in cui si teneva in conto la questione del minimo comune multiplo, tempi in cui, magari per colpa di un substrato tecnologico ancora non troppo evoluto, il nobile Guastardo e l'umile Bepin avrebbero dovuto condividere la stessa esperienza utente, tarata sul sistema meno potente. Tempi in cui, se ci si accontentava, si poteva usare anche un driver vesa. Tempi in cui, per testare un nuovo rilascio alpha senza far danni al proprio computer non più in garanzia, sarebbe bastata una macchina virtuale senza fronzoli. Tempi in cui anche gli *BSD facevano parte del carrozzone.

Le cose, purtroppo, stanno cambiando. Questo è il racconto di quello che ho sperimentato dal vivo.

Tutto è cominciato qualche tempo fa, magari ve ne siete acconti leggendo lo... hmm... sì, possiamo chiamarlo "scazzo" tra me ed Emmanuele Bassi su twitter. Nel momento in cui lui gioiva per i tanti frame per secondo che era riuscito ad ottenere, io sperimentavo per la prima volta da mesi uno di quei bei crash infidi e bastardi, che cominciano, si ripetono non vanno via perché il problema non è in un qualche bit impazzito, ma nel codice. La colpa, cito a memoria, era ovviamente imputabile agli schifosi driver free Ati che la ancora più schifosa Ubuntu fornisce.

Sì, gli stessi driver che senza troppi problemi fanno fare a Compiz capriolette e swoosh e flappete alle varie finestre, sono la causa di crash in GNOME Shell quando questa tenta di disegnare su schermo le icone delle applicazioni.

Tecnicamente parlando la causa è, a quanto pare, effettivamente nei driver della scheda video, in particolare nella componente che si occupa dell'OpenGL, che restituisce qualcosa di sbagliato. La descrizione tecnica la trovate qui, qui e forse qui

Ne viene che se avete la sfortuna di avere un particola modello di scheda video e qualunque sia la vostra distribuzione preferita, per provare la GNOME Shell, sia semplice curiosità, sia interesse da "addetto ai lavori" (non necessariamente sviluppatore), dovrete prendere una decisione amletica. Installare o non installare i driver per la scheda video (tutto compreso, X11, drm e mesa) da git?

I driver proprietari lasciamoli fuori, in primo luogo per una questione "ideologica", in secondo luogo per ripicca (vedi sopra il rantolo "cacchio, compiz funziona, perché gnome-shell no???") in ultimo luogo perché li ho provati e l'effetto è... bizzarro. Non crash, ma provate voi a puntare il punto corretto.

Scelta non facile. Perché in fin dei conti il computer che ho davanti è mio, l'ho pagato con soldi miei, serve a me per il mio lavoro e se volessi avere un qualcosa che rischia di andare in freeze ogni 3x2 userei Windows. È una macchina di produzione e nessuna azienda, Canonical, RedHat, Novell o altro verrà a offrirmi "supporto materiale" in caso di problemi. Non che tale supporto ci sia anche per la versione stabile, ma di certo le probabilità che siano stati eseguiti maggiori controlli prima del rilascio sono maggiori.

Ma ci sono cose che un uomo deve fare, gesti magari folli che servono alla propria crescita così come è prendere il mare su una barca pirata in un romanzo di formazione. Arrrrr!

OK, ho aggiunto il PPA di xorg-edgers alle mie sorgenti apt, ho dato update e upgrade ad apt-get, ho riavviato... e adesso?!?!? Perché glxinfo mi dice che sto ancora usando i driver vecchi? Riavvia, riparti, riprova, ricontrolla, riaggiusta, riavvia, e ancora, di nuovo, un'ultima volta. Fatto. Funziona. Evvai. Momento! Perché? Ma come? Da quando? ... aggiornamento ... Controllo! Oh no! Da capo: prova, aggiusta, è cambiato, controlla, adatta, riparti e ancora di nuovo.

Debbo dire che in tutto ciò la parte più stabile è stata il driver gallium in sé (le ultime parole famose? speriamo di no) che è rimasto sorprendentemente funzionale. Purtroppo in questi due mesi è cambiato diverse volte il substrato, per cui dapprima i driver gallium non erano predefiniti e bisognava modificare /etc/environment per dichiarare una variabile ambientale che avrebbe dato precedenza alla directory in cui si trovavano, poi è stato introdotta l'opzione ForceGallium (che però all'inizio era bellamente ignorata), poi.. poi.. poi...

Adesso, alla fine della fiera, ho la mia bella build di GNOME da git, comprensiva della innovativa GNOME Shell (sì, quella roba che alcuni di voi hanno visto a Fermo), ho perso un sacco di tempo a risolvere un problema che, dal mio punto di vista, non mi competeva ("voglio compilare un DE, non capire come funzionano i driver Ati in sviluppo").

Certo, sono anche fortunato. Se avessi scelto di affidare la mia vocazione *NIX a *BSD ora mi troverei con una mano davanti e una di dietro, e non solo perché non potrei avere driver video accelerati, ma magari anche perché il mio kernel non-Linux non supporterebbe evdev/udev o altre novità. Il rilascio 3.0 di GNOME segnerà quindi definitivamente la fine della sua iniziale mission ("free desktop for everyone") e vedrà sorgere il nuovo "GNOME OS²"?

A questo punto mi rimane solo un altro dubbio nella mente, un tarlo che mi rode alla luce della recente rivolta utenti vs designer (volete sapere la mia anche su questa? cioè tutto ciò che non ho detto sul post internazionale? sicuri?). Il fatto che abbia compiuta questa complicata procedura mi qualifica come "geek" e in quanto tale il feedback mio e di altre 99 persone come me è inutile perché replicabile con una palla magica?

Ma soprattutto... intendevi la palla magica 8, vero?

[1] sì, se siete arrivati fino all'ultimo link, a quanto pare questo rognoso problema personale è stato innescato per velocizzare il caricamento e la comparsa di un pulsante dalla dimensioni 22x22 pixel.
[2] se non ricordo male qualcuno ne ha già parlato in questi termini, credo Jon McCann

4 febbraio 2011

Welcome back xorg.conf

A chi non se ne fosse accorto, negli ultimi tempi l'utilità dello storico file /etc/X11/xorg.conf è diventata così marginale e nulla da essere rimosso in toto dai sistemi Linux, tutto a vantaggio dei meccanismi di autoconfigurazione di Xorg stesso.


OK, se ne sono accorti in pochi, ossia tutti quelli che avuto la necessità di passare qualche paramentro particolare al buon caro vecchio server grafico (ditemi quello che vi pare, ma spero che sia impedito a wayland di occupare le macchine di un qual si voglia utente prima che sia garantito il funzionamento di ssh -X hostname).

Poniamo il caso che vogliate provare la futura e futuribile GNOME Shell, poniamo il caso che il vostro hardware sia una scheda grafica Ati abbastanza recente, poniamo il caso che la vostra distribuzione sia una di quelle stabili (una a caso, almeno in questo l'una vale l'altra) uscite recentemente in autunno/inverno 2010, ebbene sappiate che avrete bisogno di installare driver grafici (e in particolare le librerie mesa) più nuove possibili. Per esempio, in Ubuntu dovrete attivare il famoso repository PPA xorg-edgers¹ per fare in modo che sia usato il nuovo driver Gallium.

E come fare per usare 'sto driver Gallium? Ebbene, dicendo a xorg.conf di usarlo... Beh, non proprio a TUTTO xorg.conf, basta semplicemente creare una directory /etc/X11/xorg.conf.d/ e all'interno di essa un mozzicone del vecchio file, magari con nome 00-gallium.conf, con unico contenuto qualcosa del genere
Section "Device"
   Identifier "generic"
   Driver     "radeon"
   Option     "ForceGallium" "True"
EndSection
Sapevatelo!

[1] maggiori spiegazioni nel post "GNOME Shell: per molti ma non per tutti" che aspetta di essere pubblicato da circa un paio di mesi