conundrum

Lunedì è venuta a mancare

Ne danno il triste annuncio la madre Trolltech e la sua nuova consorte, Nokia; gli utenti commerciali di Qtopia, che se producevano cellulari adesso si trovano costretti a cambiare piattaforma; gli utenti di KDE, per cui il desktop potrebbe finire in secondo piano quando l’unico provider monopolista della tecnologia su cui ti basi viene acquistato da un produttore di embedded device che intende usarti come anti-Android.

I funerali si terranno, in una data inevitabile a meno che qualcuno non tiri fuori 150 milioni di euro, a Helsinki.

Certo però, che inculata pazzesca per gli utenti: prima la Trolltech forza la mano alla comunità per rilasciare un dimostratore incompleto e instabile di QT 4.x, poi vende l’ambaradan.

Fuori di obit joke: questo succede quando tieni tutte le uova in un paniere, e ci fai pagare pure “la tassa” sopra, con tanto di benedizione di San Ignucius (a dimostrazione di quanto il buon Richard si stia rincoglionendo con l’età); se poi si guardano i quarterly report ci si accorge di come la Trolltech stesse perdendo cash dal 2006¹, e che erano appena riusciti ad arrivare a un netto tra operative costs e operative revenues nel Q3 2007. Non mi sorprende l’offerta di 100m di euro, quindi.
Adesso la palla passa alla comunità. Se la Nokia dovesse decidere in un cambio di strategia, KDE muore; se la comunità decide di forkare e rimanere sotto GPL (v3, nonetheless), KDE cessa di avere un appeal commerciale, e diventa il nuovo GNUstep.

1. Greenphone? Possibile. [↩]

Dicevo altrove di aver provato Vala, il linguaggio C#-like scritto usando GLib e GObject come base, e che viene “compilato” in C invece di usare una VM e un linguaggio intermedio¹.

Ho trovato dei difetti nel layer di traduzione, ma sono dovuti essenzialmente alla giovane età del progetto, e il team di sviluppo sta raccogliendo intorno a sé una quantità di collaboratori più o meno saltuari che fa ben sperare. In più, la mera esistenza di Vala sta spingendo a completare il supporto per l’introspezione in GObject².

Quello che più mi interessa, però, è la possibilità di avere un linguaggio a medio/alto ufficialmente sanzionato da GNOME - come Objective-C da Apple. Intendiamoci: la quantità di binding già presenti è enorme, e già oggi se volessi scrivere un’applicazione per GNOME potrei farlo in Perl, come in Java, come in C# e perfino con quel train wreck di Python³. Tuttavia, i bindings sono quello che sono: si portano dietro virtual machine, ambienti di runtime, licenze, implementazioni patent encumbered e altre amenità.

Intendiamoci: non ho nulla contro le VM - a parte l’obiezione classica: “sto già usando una macchina virtuale su una macchina reale, perché devo usarne un’altra ancora per ogni linguaggio?”; tuttavia, e specie sulle macchine su cui lavoro, una virtual machine è già sufficiente - figuriamoci quattro o cinque. Mi piacerebbe che qualcuno prendesse Mono e ci portasse più di tre o quattro linguaggi; mi piacerebbe ancora di più che qualcuno prendesse Parrot e lo completasse. Mi piacerebbe, insomma, avere una macchina virtuale per tutti i linguaggi ad alto livello. Se non posso averla, allora tanto vale usare Vala.

1. si potrebbe arguire come, in realtà, la VM usata sia il sistema operativo ospite, e che sicuramente esistono più piattaforme con un compilatore C che piattaforme che supportano Java o C# [↩]
2. ovvero la possibilità di avere meta-informazioni a runtime su una libreria, sulle API e sui tipi di dati esportati [↩]
3. che, spero, Python 3.0 affosserà definitivamente con tutte le modifiche arbitrarie alle API senza vere nuove feature; non ci resta, quindi, che sperare in IronPython per una implementazione sana di mente? non voglio pensarci [↩]

Ho passato gli ultimi tre giorni a tentare di capire perché un pezzo di codice producesse un SIGSEGV. Ho cambiato linee, logica, tipi di dato. Niente: qualunque cosa facessi, solo crash. Come al solito, gdb si rivelava poco utile, mentendo spudoratamente sul luogo della violazione di memoria.

Oggi pomeriggio ho deciso di arrendermi e ho chiesto a Kris se poteva darmi una mano (dato che il segfault si verificava nel codice del GtkTreeModelSort che lui mantiene). Stasera mi dice di aver trovato la patch:

Index: gtk/gtkfilechooserdefault.c
==============================================================
--- gtk/gtkfilechooserdefault.c (revision 17846)
+++ gtk/gtkfilechooserdefault.c (revision 17848)
@@ -9508,7 +9508,7 @@ recent_column_path_sort_func (GtkTreeMod
   if (!name_a)
     return 1;

-  if (!name_b);
+  if (!name_b)
     return -1;

   if (is_folder_a != is_folder_b)

Penso che i miei moccoli siano arrivati vicinissimi al Moccolo a Delta di Dirac (dieci alla ventottesima madonne in un microsecondo).

Va da sé che Kris si vedrà offrire una birra al GUADEC.

segue

GTK+

Per mancanza di tempo, negli ultimi mesi ho dovuto lasciare a metà alcuni miei lavori sulle GTK+. Fortunatamente ogni tanto si è aperto qualche spiraglio di tempo libero, e quando ho potuto ritornare alla libreria che (ricordiamolo) ha consentito all’avere di che mangiare non mi sono certo fatto scrupoli.

Le GTK+ sono piagate, da tempo ormai, da una cronica mancanza di sviluppatori nel core team; il flusso di patch in Bugzilla è più o meno costante (anche se non altissimo), ma le persone in grado di fare una revisione delle patch e in generale dei bug segnalati sono poche, e nessuno lavora a tempo pieno sulle GTK+. A questo si aggiunge un’inerzia proveniente dalle compagnie che lavorano con le GTK+ nei confronti di una (ormai inevitabile) rottura della compatibilità binaria e, possibilmente, delle API. Il quadro è complesso, e meriterebbe un post di analisi dei fattori pro e contro una tale rottura di compatibilità all’indietro; sfortunatamente è sabato mattina e non ho molta voglia di farlo - considerate la questione solo rimandata.

Cosa si muove, quindi, nelle GTK+? Cosa ci sarà nella prossima minor release, la 2.12.0? E cosa ci aspetta nel futuro?

Cominciamo con le cose già in trunk:

Supporto Quartz e DirectFB

Il lavoro sui backend per GDK continua; il backend per Quartz è mantenuto dagli sviluppatori della Imendio ed è quasi stabile; mancano ancora feature, e molto dipende dalla stabilità del backend Quartz di Cairo, ma comincia ad essere usabile. Il backend DirectFB è invece portato avanti dal team per l’installer grafico della Debian, e ha ricevuto molte attenzioni in occasione del rilascio di Etch. Alcune delle funzionalità sono state aggiunte alla branch stabile, ma trunk è il posto dove la magia avviene.

Rimosso il supporto a Windows 9x/ME

Il supporto per i sistemi operativi giocattolo della casa di Redmond era già cessato con la release 2.10; adesso è stato completamente rimosso dalla code base. Chi vuole, può fare un diff tra 2.10 e trunk, procurarsi un incudine e un martello e prepararsi per un’intensa sessione di martellate sui gioielli di famiglia.

Nuova API per le tooltip

Kristian Reitveld ha creato una nuova API per gestire le tooltip sui vari widget. D’ora in poi, niente più GtkTooltips da tenere in giro per tutta la durata dell’applicazione, ma una semplice proprietà che contiene il testo della tooltip (con supporto per il markup). Se si vuole modificare la finestra stessa usata per la tooltip, basta fare l’override di una funzione virtuale della class GtkWidget e si può usare la finestra che si preferisce. Questo, tra l’altro, permette finalmente di poter usare tooltip con GtkTreeView e GtkComboBox.

File recenti

Una delle cose che ho scritto io. Finalmente è possibile infilare la lista dei file recenti in un menu costruito usando GtkUIManager. Per la disperazione (di uno) degli autori di gedit, niente menu “in linea” (come Windows, per intenderci) ma solo come sotto-menu (come OS X). Scrievere una version in linea non è complicato (se volete, trovate una implementazione qui). Ho anche aggiunto la possibilità di inserire elementi del menu prima e dopo la lista dei file recenti nel GtkRecentChooserMenu, così da renderlo più simile a un GtkMenu (quale è).

FileChooser migliorato

Una delle cose che mi fanno aumentare la misantropia e, in generale, il desiderio di vedere la razza umana estinguersi sono le flame sul selettore di file delle GTK+. Seriamente: ogniqualvolta arriva qualche sedicente esperto di usabilità che urla ai quattro venti come il GtkFileChooserDialog sia “inusabile” io spero solo che si tratti di qualcuno che vive vicino ad una costa marittima, e aspetto che il riscaldamento globale faccia il resto. Due settimane fa ho fatto il commit della patch (non scritta da me) che aggiungeva il supporto per la ricerca di file usando (indirettamente) Beagle, Tracker o una semplice ricerca per nome. La patch aveva ancora dei problemi, con funzionalità non implementate o comportamenti non consistenti, quindi ho passato questa settimana a scrivere patch per chiudere il bug #435343 e intanto che c’ero anche il bug #435342 (se volete vedere come appare il selettore file adesso, ci sono degli screenshot qui e qui) per aggiungere la lista dei file recenti direttamente nel selettore di file e chiudere così integrazione iniziata con la scorsa versione delle GTK+ - quasi due anni dopo il GUADEC che ha iniziato tutto quanto.

Ovviamente, le novità non sono solo queste. C’è stato un gran lavoro nel portare alcune feature sviluppate per piattaforme embedded, come la navigazione via tasti oppure il metodo di inserimento per tastiere solo numeriche. In più, ci sono nuove feature in fase di valutazione e di revisione che non sono ancora “atterrate” in trunk, come il supporto per il tap-and-hold per i menu contestuali (usato dai touchscreen o più in generale da chi ha puntatori con un tasto solo, come Mac o tablet). Infine, c’è la grossa feature rappresentata dal GtkBuilder, ovvero la possibilità di creare interfacce utente usando XML - come libglade ma integrato ed esteso.

Cosa ci attende nel post-2.12 non si sa. Le GTK+ avranno finalmente un canvas? E come impatterà questo oggetto con la struttura dei widget? In più, avremo finalmente una class GtkApplication per scrivere applicazioni in maniera più semplice, lasciando che siano le GTK+ a gestire le sessioni e lo stato (liberandoci di un bel pezzo di libgnome e libgnomeui)? Avremo un layer per VFS finalmente usabile senza una lobotomia parziale? E una piattaforma per la configurazione che non sia ferma al 2001?

Infine, quando avremo le GTK+ 3.0, con una ripulitura generale del codice?

Non so dare risposte; so solo che chi vivrà, vedrà.

continua…

A tirare su il bilancio di una discreta settimana del cavolo ci pensa eBay, grazie alla quale ho potuto mettere le mani su un Super Nintendo d’occasione, completo di una decina di giochi tra cui Starwing, Sensible Soccer e una valanga di Super Mario.

Sul fronte più interessante dell’hacking, sto finendo la riscrittura di gnome-screenshot; ho rimpiazzato buona parte del codice con oggetti, rimosso l’uso diretto delle Xlibs in favore delle più compatte e utili GDK (tagliano circa l’80% di fuffa, garantendomi una certa qual sanità mentale), e aggiunto il code path per scattare screenshot su compiz/beryl/vattelapesca (che non fanno il reparenting delle finestre con il frame aggiunto dal window manager - come chiunque abbia tentato di usare gnome-screenshot sotto compiz avrà notato).

Un altro fronte sul quale ho lavorato nelle ultime due settimane è stata la separazione di backend in Clutter; adesso Clutter si può usare sia in ambienti desktop con GL che in ambienti embedded con GL-ES; in più, il codice è molto migliorato e la gestione degli eventi pure.

Infine, qualche tempo fa ho incontrato Neil Patel dal vivo. Trattasi di ragazzo particolarmente in gamba impegnato nella realizzazione di bling vario e utile per il desktop. A quanto pare, si è interessato a Clutter per scrivere una specie di media center. Il suo unico difetto è che gli piace Tracker, ma non temete: con un po’ di convincimento da parte del sottoscritto potrebbe lasciar perdere quell’aggeggio senza speranze.

Sto attraversando un momento di pura e distillata misantropia. Oppure, più semplicemente, non capisco che strano processo mentale (?) porta certa gente a proporre cose come:

Gli utenti si apettano tutte le funzionalità del file manager dalla finestra di dialogo per salvare un file […] quindi se Nautilus è installato le GTK+ dovrebbero eseguire Nautilus [al posto della GtkFileChooserDialog].

Sicuramente, ha a che fare con della droga - crack, nel caso specifico. Lasciamo perdere l’evidente caso di inversione (perché le GTK+, che sono un toolkit multipiattaforma, dovrebbero dipendere da Nautilus, albeit opzionalmente?), e concentriamoci sull’idiozia di poter effettivamente modificare file, directory ed eseguire applicazioni mentre si sta salvando un file. Ottimo se hai un attention deficit disorder e non riesci a fare a meno di lavarti i denti mentre bevi il caffé, tirandoti su i pantaloni alla fermata dell’autobus.

Oppure no.

La missione, se deciderete di accettarla, sarà di trovare la playlist nel prossimo Amarok:

Se verrete catturati, uccisi oppure vi butterete dalla finestra dall’orrore, il dipartimento negherà di essere a conoscenza della vostra missione.

Poi, a che diavolo serve il menu Engage? Cos’è, l’Enterprise?

Le motivazioni per utilizzare Amarok stanno scivolando sempre più verso il lombrosiano.

Attenzione: post ad elevato livello di sarcasmo

È bello vedere gli amici di KDE pensare agli utenti, e passare a Dolphin. Certo che, potendo scegliere, non sarebber convenuto loro usare un file manager che non assomigliasse a Nautilus com’era cinque anni fa?

Ad ogni modo, il cerchio si chiude e si ritorna al 1999: KDE torna ad essere l’ambiente per i corporate user, transfughi di Windows, mentre GNOME torna ad essere il desktop environment pieno di crack.

… and back

Il FOSDEM di quest’anno è stato interessante; i talk erano come al solito troppi, e troppo sparsi, per essere seguiti - ma in generale il FOSDEM non è una conferenza a cui si partecipa solo per seguire demo e sentire gente che parla davanti a slide. Ho ritrovato volti noti e conosciuto di nuovi. Ho parlato di nuovi “giocattoli”, sviluppi futuri di alcune librerie e architetture, bevuto birra in quantità, dormito poco e riso molto.

Il viaggio a Helsinki è stato più stancante, e non posso dire molto: solo per entrare al research centre devi firmare un NDA. Sono stati comunque due giorni interessanti in una nuova città, per il sottoscritto.

Dal FOSDEM. Più precisamente: dalla GNOME dev room del FOSDEM, una volta tanto che la connessione funziona.

Parrà incredibile, ma le conferenze di hacker, programmatori e più in generale smanettoni, hanno la peggior connettività del mondo; forse è perché tutti i partecipanti hanno almeno un computer acceso e in procinto di fare un sync con venti repository

Nel frattempo, uno screenshot di quello su cui sto lavorando:

Directory speciali nel file chooser, caricate da un file esterno e traducibili.

Ovvero, l’implementazione di DesktopPlaces.

Fine settimana: a Bruxelles per il FOSDEM 2007. Direttamente da lì, fino a martedì, si finisce ad Helsinki.

A fine aprile si vola a Copenhagen, per due talk da tenere al Nordic Perl Workshop 2007.

A inizio luglio (ovviamente) il GUADEC 2007 a Birmingham. Ed è la conferenza a minor distanza da casa.

A fine agosto mi piacerebbe andare alla YAPC::Europe in quel di Vienna.

Purtroppo dovrei rifare il passaporto per poter andare negli States, quindi con ogni probabilità il Summit a Boston salterà anche per questo anno.

Panacea
\Pan`a*ce”a\, n.
[L., fr. Gr. pana`keia fr. panakh`s all-healing; pa^s pa^n, all + ‘akei^sqai to heal.] [1913 Webster]
1. A remedy for all diseases; a universal medicine; a cure-all; catholicon; hence, a relief or solace for affliction. [1913 Webster]
2. (Bot.) The herb allheal. [1913 Webster]
3. (Programming) Tracker. [2007 Gnome]

Okay, adesso si è andati talmente oltre il ridicolo che non è neppure più divertente. Gli autori ci si sono messi per la loro parte, ma adesso i droni stanno diventando davvero fastidiosi.

Di solito non accendo flame: ci partecipo solo (grazie ai poteri della I-can-t-believe-it-s-not-Asbestos tuta che mi è servita per anni su Usenet) perché mi diverte vedere le buffe reazioni degli esseri umani (misantropo umanista? You bet!).

Stavolta, però, me la stanno tirando fuori dalle carni.

Chiunque segua desktop-devel-list sarà al corrente che non nutro grande simpatia per Tracker, il calderone di indexer/database/interfaccia grafica/kitchen sink/quello che sarà questa settimana che alcuni vorrebbero avere una maggiore integrazione con GNOME.

Premetto subito che io non odio Tracker: mi stanno cordialmente sulle balle le modalità con cui viene evangelizzato e, soprattutto, sviluppato. Dopo un anno e rotti in cui è stato riscritto almeno tre volte, cambiato il database, cambiato l’indexer, aggiunte feature e realizzato poco testing, ancora manca una cazzo di API decente per permettere a me, sviluppatore, di poterlo utilizzare. Si, perché il fine ultimo di Tracker è, evidentemente, immagazzinare il maggior numero di informazioni sui vostri file e poi non utilizzarle, dato che esiste solo una serie di remote procedure calls per D-Bus e nient’altro. Ma certo, se ho bisogno di estrarre dati mi basta usare Python. Solo che non io posso riscrivere GNOME in Python (o C++, o C#, o D, o COBOL o ${WHATEVER_LANGUAGE_ZEALOTS_WILL_PROPOSE_NEXT} - in fondo, abbiamo milioni di linee di codice da riscrivere da capo, che sarà mai), e gli utenti non hanno un cazzo di Cray su cui far girare uno GNOME scritto in Python (i requisiti di memoria dopo otto ore di utilizzo sono quelli). By the way: menarmi il torrone su quanto Tracker sia buono con la mia CPU e la mia RAM e poi dirmi che se voglio usarlo devo ridurmi a scrivere un’applicazione in Python è prendermi per culo - puro e semplice; e io non sopporto quando mi prendono per il culo.

Prendiamo HAL, l’Hardware Abstraction layer scritto per evitare di dover pasticciare con device, permessi e stronzate varie; è composto da RPC ma ha anche ben due librerie che mi permettono di non dover usare D-Bus direttamente. Perché? Perché HAL è scritto da qualcuno sano di mente, probabilmente, che pensa che l’utente non se ne fa una sega di HAL in quanto tale - l’utente è esposto ad applicazioni che usano HAL a loro volta; gli utenti di HAL sono gli sviluppatori, e se non do agli sviluppatori un’API sensata come diavolo faranno a scrivere applicazioni? Tracker occupa una nicchia analoga: gli utenti non sanno cosa sia Tracker, a cosa serva o come lo faccia; sanno solo che possono aggiungere una tag a un file e cercare file usando lo stesso tag. Se un utente si eccita con il fatto che esista Tracker è un cazzo di geek, e non è per loro che io contribuisco a GNOME.

Quindi, prego qualcuno di mettersi a scrivere un’API coi contro cazzi per permettermi di scrivere applicazioni con Tracker; non widget: voglio scrivermi i miei widget senza aspettare sei mesi che qualcuno ne aggiunga uno che mi serve. Perché sono io che scrivo applicazioni per GNOME, non “gli utenti”; e se io non sono in grado di scrivere applicazioni per GNOME usando Tracker vorrà dire che sarò costretto a reinventarlo tra sei mesi.

Giuro, mi basta qualcosa che mi dia un GObject a cui far eseguire un match, e abbia segnali che mi dicono cosa la mia richiesta ha trovato. Perché non c’è ancora? Perché gli sviluppatori e chi contribuisce a Tracker ha deciso di perdere il suo tempo per scrivere front-end per la Deskbar applet, mantenere branch parallele di Nautilus e violentare il Search Tool invece di permettere ai maintainer di questi progetti di fare il loro lavoro?

</rant>

Questo è ancora il blog di un geek che sviluppa su GNOME, quindi ogni tanto vi tocca. ;-)

Con un grassissimo anticipo di trentacinque (si, 35) secondi sull’ora della deadline per effettuare una release, ieri notte ho impacchettato la version 2.17.1 delle GNOME Utilities, nome in codice Cast no Shadow. Dalle undici di sera fino al momento in cui make distcheck ha completato il suo lavoro, ho implementato una delle due feature richieste per questo ciclo di sviluppo per l’utility che prende screenshot del desktop (l’altra, ovvero la nuova finestra di dialogo per il salvataggio dell’immagine, ahimé, dovrà attendere GNOME 2.20, dato che non l’ho completata in tempo - penso che finirà in una branch, dato che è quasi finita e manca solo il codice per il drag and drop):

Questa finestra di dialogo apparirà solamente se gnome-screenshot verrà invocato dal meno oppure usando lo switch --interactive da linea di comando; ovviamente, la finestra di dialogo terrà conto delle opzioni da linea di comando, quindi:

$ gnome-screenshot --window --delay=5 --interactive

modificherà il RadioButton selezionato e il valore nello SpinButton. Purtroppo non sono riuscito ad infilare dentro una ComboBox per l’effetto (bordo o ombreggiatura), e dato che siamo in UI freeze dovrò chiedere il permesso prima di inserirlo. In più, c’è un bug: non appare l’icona dell’applicazione nella parte sinistra della finestra - probabilmente, l’icona non è installata correttamente grazie a Dennis Cranston, il bug è stato rimosso.

Riassumendo, le feature mancanti in questo ciclo di gnome-utils sono:

• usare GtkPrint nel dizionario [da fare];
• supporto per dizionari locali [includere il parser e il backend];
• speller nell’applet del dizionario - o rimozione dell’applet in toto, in favore di deskbar-applet; [da fare]
• plug-in nel visualizzatore di log - e, in generale, pulizia del codice [quasi completo, da pulire];
• nuova finestra di dialogo per il salvataggio degli screenshot [quasi completo];

Adesso che GNOME è passato a SVN potrei finalmente sfruttare l’occasione e aprire qualche branch per gli esperimenti.

Ai lettori più attenti di questo blog non sarà sfuggito il fatto che il sottoscritto non ha scritto alcunché riguardo l’accordo tra Novell e Microsoft. Ho deciso di non scrivere nulla un po’ per pigrizia - in fondo, non scrivo anche di quella tragicommedia che sono diventati i processi della SCO; un po’ perché volevo prima vedere cosa succedeva; infine, un po’ perché non voglio rendermi ridicolo sparando giudizi basati sul vuoto pneumatico del fanboism oppure su quello che io credo vogliano dire le millantamila leggi sul copyright e sui brevetti. Insomma, non voglio fare la figura di tutti quelli che - senza aver fatto la law school - hanno espresso il loro parere (scarsamente richiesto) e sul web, e su Usenet e sulla stampa specializzata.

Seriamente: potrei scrivere come l’accordo non riguardi in alcun caso Mono; come, in buona sostanza, la Microsoft abbia pagato la Novell per permettersi di usare i brevetti che la Novell possiede; come alla Microsoft abbiano fatto intendere fischi per fiaschi alle altre aziende con business Linux-oriented; come l’accordo stia facendo un favore all’open source, spingendo da un lato verso l’adozione della GPLv3 e dall’altro aumentando la cognizione di causa delle aziende. Non lo farò scendendo nei dettagli - sono solo mie valutazioni grossolane di persona che non si è fatta tre anni di law school. Quello che è certo è che l’accordo andrà valutato tra sei/dodici mesi per vedere cosa ha portato alla comunità.

Ieri sera ho deciso di provare Xgl+Beryl (il fork di Compiz) sul portatile. L’installazione su Ubuntu Edgy sarebbe anche andata a buon fine, e il sistema sembra reggere - non fosse che devono esistere delle incompatibilità tra Xgl e l’ultima release delle librerie per la gestione dei layout della tastiera che fanno entrare in un loop infinito gnome-settings-daemon (consumando tutta la CPU). Mi ritrovo, quindi, con una tastiera mappata US e il tema di default delle GTK+, niente tasto Compose mappato su Caps Lock e niente impostazioni.

Ma ho le wobbly windows (queste), ombre in alpha blending e quattro workspace mappati sulle facce di un cubo (tra l’altro, è uno shock piuttosto pesante per il sottoscritto, abituato a dodici workspace - mi sento lievemente castrato nell’utilizzo del computer).

Update 20061031T19:22Z: Beryl è stato tolto dopo un giorno continuato di utilizzo. Molto bello, molto figo, sorprendentemente stabile e non così affamato di risorse; tuttavia, mi mancavano la mia tastiera inglese con il tasto compose e i miei dodici workspace. Se future versioni non faranno inchiodare gnome-settings-daemon e mi ridaranno il maltolto, allora tornerò sicuramente a utilizzarlo (magari con il driver open source e Aiglx, e non con quello della ATi e XGL).

La quantità di fuffa cazzara espressa in questo scritto è talmente tanta che non è neppure divertente. La quote migliore, tra le tante, è questa:

Equally ridiculous is telling someone who spent four years at University obtaining a degree using Photoshop to ‘switch’ to The Gimp which is ’similar’.

Evidentemente allo scribacchino manca il senso del ridicolo: se ho speso anni per prendere una laurea e non so imparare ad usare un altro programma[1] allora tanto valeva andare a zappare.

Ma la parte migliore arriva subito dopo:

Someone needs to raise the bar and sink some cash in to Wine so that MS Office (All versions) and Photoshop (All versions) will run on Linux as if they were native Linux apps.

Invece di chiedere un vero porting, usiamo WINE e tanti saluti a policy di installazione, compatibilità, interoperabilità e integrazione. Meraviglioso: trasformiamo Linux in Windows.

Until these issues are addressed no distribution of Linux will ever threaten the big boys in the Desktop arena.

Traduzione: fino a quando Linux non sarà diventato Windows ma gratuito, allora io non lo filerò nemmeno di striscio.

Lo sapevo, non dovevo leggerlo: adesso ho una voglia matta di prendere questa maglietta.

[1] Volutamente tralascio il fatto che Gimp (non “The Gimp”) sia diverso da Photoshop anche per quantità di feature a disposizione; lo so, e purtroppo quello che manca è coperto da brevetto, licenza capestro oppure non lo so implementare; ciò non toglie l’idiozia alla base della frase di cui sopra. Tra l’altro chi è che prende una laurea per usare Photoshop? Quelli della Scuola Radio Elettra?

While Gentoo comes with extensive documentation covering most aspects of using Portage, the techniques described in Gentoo’s handbook and other documentation are not always the most effective ones. Here are some insider tips that can greatly increase your productivity.

Consiglio numero uno per aumentare la produttività: smettila di farti le seghe e installa un’altra distribuzione.
Consiglio numero due per aumentare la produttività: quale parte del consiglio uno non ti è chiara?

Dopo OSSblog, adesso anche GNOME Journal decide di intervistarmi. Va da sé che li ho avvisati di quanto io sia noioso se lasciato parlare.

La quantità di crack espressa dal sottoscritto è da prendersi con le molle: non avevo ancora bevuto il mio caffè mattutino.

Anche quest’anno, come l’anno scorso, il sottoscritto andrà al GUADEC, da domenica 25 a venerdì 31 giugno, a Vilanova (Barcellona).

La differenza principale è che, quest’anno, il sottoscritto terrà anche un tutorial su GtkRecent e su come aggiungere il supporto per i file recenti e i bookmark nelle applicazioni GNOME, alla fine del Warm Up Weekend.

Per il resto, saranno cinque giorni di conferenze, talk, hack fest, discussioni, incontri e battute tra geek.

Ikitt, su autopackage (in particolare, penso si riferisca a questa pagina.

Il vero problema di autopackage non è l’attitudine dei programmatori di autopackage - in fondo, progetti F/OSS portati avanti da persone che non riescono a comportarsi come degli adulti razionali ne abbiamo avuti e ne avremo ancora; pensiamo a MPlayer: nato male, portato avanti con arroganza e spocchia, sta finalmente per finire nel dimenticatoio, sorpassato da soluzioni tecnicamente superiori e sviluppate da gente che, almeno, non dice che tutto il resto fa schifo. Questo perché MPlayer copriva una nicchia nell’ecosistema del free software che doveva essere coperta.

Autopackage, al contrario, non risponde ad alcuna esigenza vera e propria, se non al bisogno di alcuni sviluppatori per Windows (che non hanno ancora capito come funzionano le cose sotto *nix e Linux) di avere un unico pacchetto da installare su tutte le macchine che hanno sotto mano. È un’esigenza sentita da qualcuno? Si - ovviamente. È un’esigenza rilevante? No, altrettanto ovviamente. Altrimenti avremmo molti altri progetti simili ad autopackage - mentre l’unico che mi viene in mente è Klik, ovvero un altra soluzione messa a punto da e per programmatori per Windows.

Secondo gli sviluppatori di autopackage l’onere di far funzionare il proprio software con tutte le distribuzioni dovrebbe ricadere sugli sviluppatori delle applicazioni; questo non solo è dimostrabilmente inutile, ma pure dannoso. Io uso Ubuntu e conosco il sistema di pacchettizzazione della Debian a sufficienza per poter fare pacchetti .deb; tuttavia, uno sviluppatore Debian che abbia finito la NM ne sa indiscutibilmente più di me riguardo alle policy della Debian; stesso discorso vale per pacchetti RPM e per uno sviluppatore della Fedora Core 5. Anche se quelli di autopackage mi forniscono un’API per astrarmi dal lavoro pesante di aver ca che fare con relocation di librerie e binari, le minutie del package management non le posso (e non le voglio) imparare. In più, a meno di non ricorrere alla Fatina dai Capelli Turchini, e di sostituire tutto l’installato planetario con pacchetti basati su Autopackage in un microsecondo, avremo sempre a che fare con pacchetti autopackage che rompono inesorabilmente i pacchetti legittimi delle distribuzioni.

Quindi, il vero e serio problema di autopackage è la completa inutilità del fine prefisso (”un solo package manament system per tutte le distribuzioni gestito dagli sviluppatori stessi”); a questo si deve aggiungere una ignoranza di base sui meccanismi delle distribuzioni e dei loro package manager; poi, ma solo alla fine, una manifesta arroganza da “noi abbiamo la soluzione per tutti i vostri problemi, e tutti gli altri sono solo dei perfetti stronzi”, che fa risultare gli sviluppatori di autopackage automaticamente dalla parte del torto.

Dopo una nottata e una mattinata dedicate al sonno dei giusti, ecco qui qualche noticina sparsa sul FOSDEM.

Day one

Sono arrivato tardi, come previsto, e ho saltato il talk di Stallman, come previsto. Da quanto ho saputo dagli altri si è trattato del discorso quadratico medio di Stallman, con l’aggiunta del mantra il DRM è il Male.

Girando tra i boot, le cose più belle che ho visto sono state le ragazze di Ekiga (l’ex GnomeMeeting), il nuovo installer grafico della Debian (basato su GTK e DirectFB), gli effetti di VideoLAN (il frontend per HTTP è particolamente interessante) e il fatto che molti hacker avessero il Nokia 770.

Principalmente, ho bazzicato intorno alla room dedicata a GNOME; non fosse che l’hanno spostata da una parte all’altra del campus dell’ULB, probabilmente non mi sarei mosso molto di mio.

Per prima cosa, c’è stata la presentazione dei partecipanti, tenuta da Jeff Waugh (sempre divertentissimo); poi, Damien Sandras ha mostrato lo stato di Ekiga (e ha spiegato il nome, e devo dire che sono d’accordo con lui: GnomeMeeting faceva onco, mentre Ekiga è un nome molto più azzeccato e interessante).

Ho seguito con grande interesse il talk di Tor Lillqvist sul porting delle applicazioni scritte per GNOME su piattaforma win32; per chiunque fosse interessato, molto si riduce a: usate GLib e fate attenzione al fatto che alcune cose sono implementate solo nella libreria C e non nel sistema stesso. Altro talk interessante è stato quello di Philip Vanhoof sui design pattern con GObject; Philip ha mostrato come l’object orientation con il C sia una cosa assolutamente naturale e potente, e intanto che c’era, ha mostrato come caricare un GtkTreeModel da tre milioni di righe in un GtkTreeView senza che ci volessero dieci minuti per il ridisegno dell’interfaccia, o senza che il sistema si sieda senza molta pietà: davvero ottimo per chi ha esigenza di mostrare molti dati in una lista/albero.

Mi sono perso il talk sul XGL, mannaggia, ma essere in due posti contemporaneamente è ancora una feature che mi manca.

Day two

La giornata inizia presto, con il talk di Tommi Komulainen sulla piattaforma Maemo e su cosa bisogna ricordarsi quando si sviluppa per il Nokia 770, ovvero: la CPU è poca e fa poche cose, la memoria è meno, il display è meraviglioso. La CPU è un’ARM senza FPU, quindi scardati Cairo; la memoria è composta da 64 MB, quindi solo un’istanza di un’applicazione per volta, e se sei in background salva il tuo stato perché verrai segato senza pietà alcuna; il display ha qualcosa come 200-e-rotti dpi, quindi la resa è decisamente migliore dell’LCD del vostro laptop.

Altri talk interessanti della giornata sono stati quello su Subversion e su Valgrind. GNOME tutto verrà migrato da CVS a SVN dopo la release 2.14 e volevo sentire qualcosa in più, dato che conosco poco CVS (pure utilizzandolo da qualche anno), ma ancora meno di SVN. Perché CVS non sia una grande scelta per grossi progetti è ovvio (impossibile copiare/spostare file, branching, tagging e diffing sono operazioni lente come la morte, richiede di essere connesso per troppe operazioni), tuttavia dopo aver avuto a che fare con sistemi di versioning distribuiti (Arch e bazaar su tutti), volevo vedere se SVN era effettivamente una buona scelta per GNOME, e Greg Stein mi ha convinto (specie quando ha detto che ci sono piani per implementare il merging intelligente e l’offline commit, togliendo parte dell’edge dai sistemi di versioning distribuiti). Anche il talk su Valgrind è stato interessante: sarebbe meglio che tutti quanti noi sviluppatori passassimo più tempo a tu per tu con questa suite di programmi.

Ovviamente, non potevo perdermi il talk di Kristian Reitveld sul Project Ridley e sulla release 2.10 delle GTK. Kris è stato perfetto, c’è decisamente interesse per le nuove feature delle prossime GTK. Una domanda dal pubblico è stata interessante: dato che ci saranno nuovi widget, ci sarà supporto per la stampa, per i file recenti, per un canvas (forse) e tonnellate di nuovo codice, le GTK non diventeranno troppo ingombranti - specie per i sistemi embedded? La risposta è: si, le GTK diventeranno più “grandi” di adesso; bisogna anche capire, tuttavia, cosa significhi “più grandi”. La piattaforma base (glib, atk, pango, gtk+) al momento occupa qualcosa tra i cinque e i sei MB di librerie dinamiche; tuttavia, non è tanto la memoria occupata a rappresentare un serio problema: è il caricamento di librerie ad esserlo. Ovvero: se le GTK avranno il supporto per la stampa, io non dovrò caricare anche libgnomeprint e libgnomeprintui - ovvero, non avrò dei seek su disco per cercare i .so, non avrò il caricamento in memoria dei simboli e non avrò dei salti avanti e indietro per eseguire le funzioni: le GTK saranno già in memoria, e quindi avrò già a disposizione quelle funzioni. Certo, se la mia applicazione non stampa, non usa i file recenti, non ha un canvas e non usa molti widget allora avrò tempi di caricamento più lunghi. È un trade off tra spazio e tempo, come al solito.

Per finire, il talk di chiusura di Jeff è stato davvero divertente e interessante. Non posso spiegarlo: dovevate esserci. Quindi, vedete di venire a Barcellona a fine giugno per il GUADEC 2006.

Grazie per il vostro mojo: è davvero servito (i dettagli non adesso, ma presto).

A proposito, sto pensando di andare al FOSDEM di quest’anno, a Brussels (perché “a proposito”? Ve l’ho detto: i dettagli non adesso, ma presto).

Update 2006-02-18@00:20: è ufficiale, il prossimo week-end qui si va a Bruxelles per un paio di giorni di hacking, di conferenze e di incontri con gente con la mano aperta; la fiancée ha deciso di venire pure lei e di vedersi un po’ della città.

Nonostante i miei avvertimenti su quanto io possa essere noioso, sono stato intervistato da ossblog: si parla del mio lavoro su GNOME, della nuova release e di come contribuire ad un progetto F/OSS.