Tab Groups

L'altro giorno, seguendo un filo logico partito dalla visione degli ennesimi presunti mockups per le future versioni di Firefox (cui pero' credo poco: cose del genere sono in giro gia' da tempo, e mai sono state implementate nella release mainstream), ho riaperto e riesaminato il ben noto browser targato Mozilla. L'ho sempre tenuto installato, e apt ha sempre provveduto ad aggiornarlo insieme al resto dei pacchetti della mia Debian, ma gia' da un pezzo ero passato a Chromium dunque non mi ero piu' curato della sua evoluzione e dei suoi progressi.
Quando l'ho avviato ho notato la sua rapidita', sia nelle fasi di caricamento che di rendering delle pagine, ma essendo gia' abituato al browser di Google non mi sono lasciato impressionare piu' di tanto. Ho apprezzato, ma nulla di piu'. Ho fatto un giretto tra le opzioni di configurazione, ho scoperto che la barra dei menu puo' essere ridotta ad un pulsantino anziche' alla solita inutile striscia che spreca spazio verticale, e... Ho trovato, in alto a destra, una inspiegabile icona. L'ho cliccata, e mi si e' aperto un mondo.
Gia' avevo letto qualcosa in merito alla funzione di "Tab Groups", ma mi era sfuggita l'informazione che e' stata inclusa in Firefox gia' dalla versione 4. O forse avevo ignorato tale dettaglio, avendo deciso di metterci una pietra sopra. Sta di fatto che venti minuti di esplorazione mi sono bastati a ri-migrare nuovamente da Chromium.
"Tab Groups" e', in breve, un metodo per aggregare le tabs aperte. Si clicca la famigerata iconcina e si apre uno spazio in cui si possono editare i propri gruppi, crearne di nuovi, spostare le tab da una parte all'altra ed altre operazioni essenziali. Si clicca su una delle tab aperte e si ritorna alla modalita' classica, ma in alto appaiono solo le linguette appartenenti a quello stesso gruppo. Detto cosi' pare semplicistico, ma dopo pochi giorni di utilizzo posso dichiarare che mi ha cambiato la vita.
Un po' per pigrizia, un po' per comodita', sono solito tenere sempre almeno 30 tab aperte. Alcune sono per le amenita' social (Facebook e Google+ in primis), alcuni sono articoli rintracciati sui feed RSS, troppo lunghi per essere letti subito e dunque tenuti da parte per i momenti di calma (qualcuno potra' dire: "Usa Read-It-Later!". Ci ho provato, finivo con l'accumulare dozzine di links ma non avendoli sempre sotto agli occhi me ne dimenticavo e non li riprendevo piu'), altre sono tabs di servizio in cui tengo permanentemente alcuni dei wiki e degli strumenti che uso per appuntarmi le cose che raccatto in giro. Si puo' immaginare quanto sia scarsamente efficiente tale comportamento in un contesto normale. Appena scoperto Tab Groups ho subito creato i miei gruppi: "Da Leggere", "Da Bloggare", "Appunti", "Social"... E ora non ho piu' di cinque/sei tab alla volta davanti, riesco a leggerci sopra i titoli delle pagine (e a identificare al volo quello che serve), non sono continuamente tentato di andare a consultare Facebook (che sta in un gruppo separato, dunque devo recuperarlo volontariamente e coscientemente) ma al contempo ogni volta che entro nella modalita' di navigazione dei gruppi inevitabilmente scorgo la lista di cose da leggere e noto se sta crescendo troppo e richiede attenzione.
Decisamente, consiglio a tutti i disordinati come me di valutare l'uso intensivo di codesta funzionalita'. Non aiutera' forse a ridurre la quantita' di ciarpame web che vi ostinate a lasciare in giro e a consultare, ma almeno servira' a tenerlo separato dalle cose piu' utili.

Social Cloud

Come in diversi altri casi passati, scrivo questo post piu' per avere un appunto personale reperibile in futuro che per condividere una idea fatta e finita: per ora si tratta solo di una meditazione, non approfondita e non documentata (e dunque potenzialmente fallace), ma chissa' che non sfoci in un (ennesimo!) progetto da sviscerare.
Tutto e' nato dalla combinazione di diversi fattori: il mio recentissimo ingresso in Google+, la mia occasionale lettura della mailing list degli sviluppatori presso la Freedom Box Foundation, e una mezza chiaccherata in chat con un amico.
Sul primo non c'e' molto da dire, bene o male e' sempre la solita frittata: si condividono le foto, lo status e commenti di ogni tipo e genere, si leggono quelli degli altri, ma il progetto non porta nulla di nuovo sul fronte dell'innovazione. Sulla seconda ci sarebbe molto piu' da riferire, ma riassumo in una semplice frase: una congrega di nerd che si fanno pippe cosmiche sulla privacy e sulla crittografia senza riuscire ad individuare i reali problemi, le reali esigenze e le reali soluzioni. Fino a qui, il punto e': sulle tecnologie "social" esiste il totale monopolio delle grandi corporation, le quali per contratto posseggono tutto quello che gli utenti pubblicano e fanno a gara per rendersi incompatibili le une con le altre ostacolando cosi' di fatto l'esplosione delle reali potenzialita' del concetto, mentre i presunti difensori delle liberta' digitali sono del tutto incapaci di fornire alternative sia perche' perdono tempo ad inveire sia perche' oggettivamente riscrivere l'intero stack di software libero orientato al web per venire incontro alle nuove prospettive non e' cosa semplice o banale.
Veniamo dunque al sodo.
La menzionata chiaccherata di ieri sera verteva sulla dispersivita' dei materiali che transitano sui social network, in quanto ognuno scrive ogni cosa ed e' difficile estrarre dal flusso costante di caotiche informazioni qualcosa di specifico. Ironicamente ho consigliato all'amico di lasciar perdere i social e procurarsi un aggregatore di feed RSS con cui seguire i blog tematici che trovava, e all'osservazione che i feed RSS non sono interattivi (un post non puo' essere commentato direttamente dal feed reader, ne' tantomeno essere "like"ato) ho replicato che esiste gia' una estensione RSS che permette di integrare i commenti. Ma, effettivamente, solo in lettura.
Alche', sorge spontanea la domanda: e se i feed RSS fossero commentabili? Cioe': se esistesse una API standard, estremamente banalizzata, che permetta di spedire un commento o una nota ad un hook indicato nel feed senza necessariamente accedere al blog/sito da cui e' stato prelevato, permettendo l'integrazione esterna dell'intero processo di comunicazione? In un colpo solo si riprodurrebbe una delle funzionalita' essenziali dei social network, ovvero la pubblicazione di testi, la loro aggregazione e la possibilita' di rispondere, ma al di fuori dei social network, percui ognuno potrebbe pubblicare usando Wordpress (su wordpress.com o hostato privatamente), o identi.ca (idem), o qualsiasi altra cosa che generi un RSS. E ci vorrebbe poco ad estendere la stessa nozione a foto (Gallery, Mediagoblin...), links (scuttle), e ogni altro genere di contenuto tipato per cui esista una piattaforma web in grado di distribuire.
Come fare a "farsi amica" una persona? La si cerca con WebFinger o si importa un file FOAF o hCard contenente l'insieme di feeds RSS che indicizzano i suoi contenuti. Come fare a seguire i contenuti generati da tale persona? Con un qualsiasi feed reader (desktop o web) arricchito con il supporto all'ipotetica nuova estensione per la scrittura dei commenti.
In un certo qual modo le Web Activities promosse recentemente da Mozilla (ed ancora in fase ultra-sperimentale) vanno in questa direzione, proponendo uno strato operativo all'interno del browser che permetta di integrare servizi web diversi cercando il minimo comun denominatore delle rispettive API ed incrociandole tra loro, ma il succo resta lo stesso: che esista un protocollo standard o un "dispatcher" estendibile per mezzo di plugins, l'obiettivo resta sempre quello di mettere insieme i vari componenti che compongono il web. Costituendo quella che potrebbe essere definita (molto fuffosamente...) "social cloud": una galassia di applicativi separati ed indipendenti tra loro, sparpagliati sull'Internet, che convettano dati ed opinioni senza alcuna forma di centralizzazione.
Gia' lo dissi, e qui lo ripeto: il segreto del successo non sta nel re-implementare daccapo Facebook (o Google+ che dir si voglia), ma nell'utilizzare in modo sensato e ponderato quel che gia' esiste.

La Sindrome di Teodoro

Qualche tempo addietro ho gia' citato su questo blog la mia esperienza con un anziano signore che ho avuto modo di assistere presso un corso di alfabetizzazione informatica. A distanza di mesi posso dire che il personaggio in questione pur non essendo diventato un sysadmin ha comunque acquisito una modesta dimestichezza col PC, tanto da passare le giornate a compilare fogli di calcolo su OpenOffice Calc per generare coloratissimi quanto inutili (ma evidentemente soddisfacenti) grafici. Mai piu' avrei creduto che, dati i forti limiti dimostrati all'inizio del corso (ed appunto elencati nel mio precedente post) e la distanza intellettuale tra la macchina da scrivere cui era abituato ed un computer moderno, sarebbe arrivato al punto cui e' arrivato, ma tant'e': tanto di cappello al signor Teodoro.

Ad ogni modo: questo articolo non parla di lui ma di me.

Da un po' ho acquistato un nuovo PC (anzi due, l'altro e' l'Abaco di cui ho gia' parlato), un desktop, e l'ho dotato di due monitor da 19 pollici in modo da sperimentare questa per me inedita' modalita' operativa e verificare se davvero impatta sulla produttivita'. La risposta e' "si", ma non e' neanche questo il tema del giorno.

Il punto e' che la presenza di due schermi ha fatto emergere una confusione inconscia dettata dall'abitudine: ci sono spesso due finestre a tutto schermo, ma il focus e' sempre uno solo. Mi spiego meglio: da sempre lavoro con le finestre massimizzate sul desktop, e switcho da una all'altra con la classica combinazione Alt+Tab. Ben rari sono i casi in cui tengo una finestra fluttuante sul monitor, un po' per non essere distratto da quelle sotto e un po' appunto per abitudine: come detto in passato, quando mi capita di aprire una nuova applicazione e vedere la finestra non massimizzata subito premo Alt+F10 per ingrandirla. Questo pero' implica che il mio cervello e' portato a pensare che la finestra che sto guardando e' anche quella che riceve gli input da tastiera, ovvero che ha il focus, ma questo non e' piu' vero nel momento in cui appunto ci sono due schermi con due diversi programmi aperti: il focus, o sta a destra o sta a sinistra.

Per quanto scontata sia questa considerazione, mai va sottovalutato il potere dell'abitudine.

A tutt'oggi, ovvero dopo un paio di mesi di utilizzo quotidiano del doppio monitor, ancora mi trovo ad essere afflitto dalla "Sindrome di Teodoro": se guardo una finestra sono convinto di poterci interagire direttamente, dimenticando di spostare il focus. Esattamente come succedeva al signore cui ho insegnato i rudimenti dell'informatica moderna, anche io mi trovo adesso nella sua condizione: sono portato a scrivere nelle caselle di testo semplicemente dopo averle individuate e guardate sullo schermo. Nel suo caso tale impostazione mentale era probabilmente dovuta all'abitudine alla carta e alla penna, in cui effettivamente la sequenza "trova il punto in cui scrivere / sposta la mano con la penna li' sopra / scrivi" e' un continuum omogeneo che si svolge usando un unico strumento (la penna) che funge sia da dispositivo di puntamento che di input, mentre come detto nel mio caso l'errore e' dettato dall'inclinazione al fatto di avere sempre e solo una finestra con cui interfacciarsi.

Da qualche giorno ho pertanto abilitato l'opzione "Select windows when the mouse moves over them" nel pannello di configurazione per le finestre di Gnome, e la situazione e' un pochino migliorata: muovere il cursore, e dunque il focus, da un monitor all'altro mi riesce in modo abbastanza naturale, dunque non devo stare troppo a pensarci e piu' raramente mi capita di pigiare i tasti giusti per la finestra sbagliata.

Dopo 10 anni di esperienza nell'uso del PC, e' incredibile constatare l'impatto distruttivo che comporta una piccola variazione nel proprio ambiente di lavoro...

In Punta di Pennino

Anni fa' - oramai ne saranno passati almeno sei - acquistai il mio primo portatile. Ed era un convertibile tablet. Piu' precisamente, un Acer C310. Ai fatti l'ho sempre usato molto poco in modalita' tablet, in quanto pesava troppo per essere davvero utilizzato a mo' di "blocco note" su cui scrivere a mano o anche solo come lettore di e-books, ma ha passivamente ispirato una gran quantita' di idee che sono poi finite in quel calderone pseudo-intellettuale che e' il Lobotomy Project.
Adesso ho acquistato il mio primo netbook. E non poteva che essere a sua volta un convertibile tablet.
L'altro giorno ho aperto la scatola dell'Abaco T102 che ho ordinato un paio di settimane fa', ed ho avuto modo di fare una prima analisi. Che adesso riporto al mondo, usando questo stesso PC.
Innanzitutto, qualche presupposto. Benche' marchiato "Abaco", trattasi questo del leggendario Intel Classmate (di cui, a quanto mi risulta, Abaco e' l'unico rivenditore italiano), ovvero la risposta del mercato all'ancor piu' leggendario progetto OLPC di Nicholas Negroponte. Quello del PC a 100 dollari, per capirsi. Che incidentalmente si e' schiantato nel momento in cui Microsoft ci ha messo lo zampino, ma sorvoliamo sulle facili polemiche. Sta di fatto che questo prodotto non e' un netbook qualsiasi, ma un computer pensato e progettato per essere usato dai bambini a scuola. A prima vista esso sembra un giocattolo particolarmente sofisticato, l'ultima versione del Sapientino Clementoni, ma dopo un po' ci si capacita che il colore azzurro dell'apparecchio e' dovuto al guscio di spessa plastica anti-scivolo applicata intorno al case ed al monitor per proteggere i componenti piu' delicati dagli urti che facilmente i poco curanti pargoli (e/o i distratti nerd) possono provocare. Partire da queste nozioni, ovvero aspettarsi a priori che aprendo la scatola ci si trovera' dinnanzi ad un apparentemente assai poco affidabile arnese, e' condizione imprescindibile per godersi da subito il proprio acquisto.

L'apparecchio ha un peso superiore agli altri netbook con analoghe specifiche video (schermo da 10 pollici widescreen), e la differenza e' probabilmente imputabile appunto alla protezione di plastica supplementare. A occhio pare che lo spazio non sia stato ottimizzato al meglio, e ad esempio sul retro sporge un pezzo (quello cui e' attaccato la simpatica maniglia di gomma) che sembra del tutto inutile ai fini della funzionalita' elettronica. C'e' una sola presa d'aria, sul lato destro, e sotto oltre alla batteria estraibile c'e' un unico pannello incastrato che copre la componentistica.

La qualita' costruttiva e', nel complesso, abbastanza mediocre. Il gia' citato guscio non sembra essere particolarmente rifinito o accuratamente applicato, in alcuni angoli sembra non aderire perfettamente al case (nel mio caso: i due lembi che circondano la webcam ruotabile posta in testa al monitor sono asimmetrici, hanno un dislivello di un paio di millimetri). Ed i simboli sulla tastiera sembrano essere appiccicati in modo grezzo, molti non sono perfettamente centrati e quasi tutti i caratteri non alfanumerici ('@', '*'...) sono veramente piccoli, a malapena leggibili.

Sempre in merito alla tastiera, ci sono luci ed ombre. In linea di massima ci si scrive molto bene, sicuramente meglio che con altri netbook che ho provato (il ben noto Asus EeePC, ad esempio), eppure alcuni tasti (in particolare il tasto 'Fn' di destra) non sono particolarmente sensibili e piu' volte capita di dover ripetere compulsivamente la loro pressione per ottenere il risultato desiderato.

Anche la configurazione "out-of-the-box" della macchina lascia un po' perplessi. Benche' il monitor ruoti correttamente e abbastanza rapidamente (ma qualche volta nella direzione sbagliata...) quando l'apparecchio viene girato o posto in modalita' slate, purtroppo basta entrare ed uscire dalla sospensione del sistema per non far piu' funzionare i tasti funzione posti attorno allo schermo (pagina su, pagina giu', home e fotografia) e neppure la rotazione automatica. La sospensione, si sa, e' da sempre una croce in ambiente Linux, ma ci si aspettava una maggiore cura nella prevenzione di questa problematica.

Lo schermo e' widescreen, e la risoluzione massima bassina: appena 1024x600. Certo una risoluzione piu' alta su 10 pollici renderebbe il tutto troppo picccolo ed illeggibile, ma occorre smanettare un po' per proprio conto per correggere la configurazione del desktop e recuperare un po' di spazio fra i pannelli di Gnome e visualizzare i propri contenuti.

Il touchscreen, essendo resistivo, non ha una grandissima precisione e va un po' calcato, ma in compenso puo' essere usato anche con le dita e non solo col pennino. Certo non basta pigiare col polpastrello, come su uno smartphone, bensi' con la punta del dito o addirittura con l'unghia, ma ammetto di averlo gia' maltrattato un pochino ed il monitor non sembra risentirne o essere incline a graffiarsi tanto facilmente.

La batteria dura un po' piu' di 4 ore con il wireless acceso e senza sforzarlo troppo, dovrei fare qualche analisi piu' approfondita ma in linea di massima mi sembra una durata accettabile.

In conclusione: l'Abaco T102 non e' un prodotto entusiasmante, e la perfezione e' tutt'altra cosa, ma trovandosi in una nicchia di mercato ove le opzioni disponibili sono estremamente limitate fa la sua porca figura. 400 euri per un netbook convertibile tablet fruibile come blocco note o e-book reader (dotandosi di qualche applicazione specializzata: leggere un PDF li' sopra rasenta l'impossibile...) e' un discreto compromesso, consigliabile per chi non ha grandi pretese e vuol provare qualcosa di inedito senza necessariamente incastrarsi sulle limitazioni di un tablet "puro" (senza tastiera QWERTY) o vendersi un rene per un Fujitsu Lifebook.

Minimi Termini

Grandi dibattiti ha generato sulla blogosfera la decisione, presa abbastanza all'ultimo momento, di rimuovere i tasti per massimizzare e minimizzare le finestre in Gnome-Shell. La discussione si e' poi persa tra i mille rivoli della polemica innescata da Shuttleworth e dal team KDE, che a sua volta abbisognava di un capro espiatorio su cui scaricare la tensione accumulata dal matrimonio Nokia/Microsoft e del conseguente sgretolamento dei sogni di gloria costruiti intorno al toolkit Qt, ma questa e' un'altra storia...
Si diceva: massimizzare e minimizzare le finistre all'interno del window manager. Sorvolando sul fatto che, come detto, questo cambiamento certamente non proprio marginale e' stato attuato in un momento decisamente sbagliato, con Gnome3 all'orizzonte e dunque poco tempo a disposizione per raccogliere il feedback necessario alla validazione dell'idea, personalmente mi ritengo favorevole alla scelta. Con tutte le precisazioni del caso.
Da una parte l'interazione che viene in questo modo promossa ed anzi forzata nei confronti dell'utente prevede un uso intensivo dei workspace virtuali, che in ambiente Linux esistono dalla notte dei tempi ma che su altre piattaforme operative o non esistono affatto o hanno fatto la loro comparsa da poco tempo. Il che' vuol dire creare diverse difficolta' a chi non e' abituato ad organizzare comodamente le proprie finestre distribuendole su piu' desktop, ed ha fatto della minimizzazione una questione di sopravvivenza digitale. Ed in questa categoria ricadono non solo gli esuli di primo pelo del mondo Microsoft, ma anche i numerosi habituee' linuxari che vuoi per zelo o vuoi per forte radicazione ai metodi passati non hanno mai fatto il callo a questa stravagante idea dei desktop multipli.
Dall'altra parte, c'e' da dire che nel momento in cui si prende un minimo di confidenza con la nozione di "workspace" i tasti per massimizzare e minimizzare le finestre sono veramente inutili.
Io, di mio, sono un grandissimo utilizzatore di desktop virtuali: ne tengo sempre almeno 10 a disposizione, e sebbene sia capitato solo rarissimamente di occuparli tutti (ma e' comunque successo...) almeno tre o quattro sono perennemente occupati da una o piu' finestre. Ho il workspace per il cazzeggio sul web, con il browser ed il feed-reader ed il client di posta, quello dedicato esclusivamente al player multimediale che riproduce la radio in streaming, e minimo minimo uno con una sessione Kate (straripante codice) ed un terminale (da cui lanciare le compilazioni di suddetto sorgente) su cui lavorare. Quando devo cercare un qualche file per mezzo del file manager, o leggere qualche documento, o editare qualche immagine con Inkscape e/o Gimp, mi sposto su un altro. Da cio' ne deriva che ogni workspace abbia al massimo quattro finestre aperte, ed essendo cosi' poche non esiste ragione alcuna per cui ne debba minimizzare una per vedere le altre. Credo di non aver usato il tasto "minimizza" per anni.
Lo stesso si puo' dire del tasto "massimizza". Tant'e' che piu' di una volta non sia riuscito a distinguerli l'uno dell'altro alla prima occhiata: essi mi sono totalmente estranei. Ma ammetto che, in questo caso, ho barato: talvolta mi capita di massimizzare le finestre, ma uso la shortcut Alt+F10 mappata di default su Gnome. Cio' accade solo perche', avendo appunto poche finestre per desktop da gestire, mi piace tenerle tutte a tutto schermo e talvolta capita che esse partano a dimensioni ridotte.
Sta di fatto che, al fin della fiera, la scelta operata e' coerente con la linea di sviluppo di Gnome-Shell, che appunto punta moltissimo sui workspaces. Dunque, la reputo immensamente condivisibile. Non ultimo perche' si risolve con la rimozione di due tasti, ed io sono quasi sempre favorevole alla rimozione degli elementi a video. Che gli utenti, aggrappati alle loro abitudini come cozze allo scoglio, si lamentino occasionalmente di qualsivoglia modifica alla loro interfaccia grafica, indipendentemente da quanto la modifica sia benefica e sensata, e' normale, endemico, inevitabile. E, per questo, ignorabile.

L'Indirizzo che non C'e'

Leggendo l'ennesimo apocalittico articolo in merito all'allocazione dell'ultimo blocco di indirizzi IPv4 disponibili, e memore di alcune osservazioni che io stesso ho fatto in un post dell'altro mio blog a sfondo "culturale", mi sono capacitato di una emergenza imminente nel campo dell'interazione uomo-macchina: quando IPv6 sara' la norma, e anche la mia LAN sara' routata su tale protocollo, come diamine faro' a ricordarmi a memoria gli astrusi ed assolutamente poco mnemonici indirizzi delle macchine di casa mia per potervi accedere? Bene o male con IPv4 ci si arrangia, assunto che la classe di una rete domestica e' quasi sempre una di quelle appositamente lasciate riservate per scopi locali (o, per meglio dire: e' quasi sempre 192.168.0.0), ed anche un identificativo arbitrario sulla Rete globale e' pur sempre costituito da soli quattro numeri che con un poco di sforzo si riescono a fissare nel cervello, ma chi mai potrebbe memorizzare la sfilza di caratteri, cifre e segni di interpunzione mescolati in un indirizzo di nuova generazione? Certo, anche in IPv6 esiste il concetto di indirizzo privato che puo' essere espresso in forma abbreviata, in cui comunque si trovano ben 10 cifre esadecimali a caso; un numero in base 10 (ad esempio: 134) si ricorda sicuramente meglio di un agglomerato impronunciabile (ad esempio: 21F4).

Il problema e' piu' grave di quanto non si possa immaginare, in quanto a tutt'oggi ci troviamo a maneggiare gli indirizzi numerici piu' spesso di quanto non si creda.

Per individuare e navigare i filesystem delle altre macchine nella rete locale, esposti con i protocolli piu' disparati (NFS, NetBIOS/Samba, SFTP...), esistono gia' fior di tools perfettamente integrati con ogni desktop environment minimamente completo (cfr. Gnome e KDE). Dunque in questo caso il dubbio non esiste. Lo stesso puo' dirsi per le stampanti (nativamente di rete, o esposte in rete per mezzo di CUPS). Ma quanti sono gli strumenti di backup, con cui periodicamente duplicare i propri dati importanti su un altro PC e/o un altro disco rigido remoto, che supportano il discovery delle istanze sparpagliate sul network? E come fare a trovare le interfacce di amministrazione web dei vari routers, access point e modem che popolano le mensole polverose delle nostre case? Senza parlare di tutte le esigenze assai piu' complesse degli utenti piu' smaliziati, i quali tanto per dirne una hanno questa fissazione di accedere ai propri PC via SSH...

Le odierne limitazioni dei meccanismi di amministrazione delle reti, unite alla crescente necessita' di essere connessi all'Internet ed alla moltiplicazione di apparecchi digitali di cui ognuno dispone (ben poche sono le case in cui ci sia un solo PC, senza contare smartphones e tablets ed altre diavolerie), implicano che l'interazione diretta con gli indirizzi IP e' oramai pratica assai diffusa e pervasiva, anche tra l'utenza di basso rango: negli ultimi mesi mi e' capitato piu' di un utonto contemplare il relativo pannello di configurazione sul proprio sistema operativo alla ricerca di una soluzione abbozzata per potersi agganciare ad un vicino access point, spinto e motivato in questa sua estemporanea avventura nerd dal desiderio di consultare la propria bacheca su Facebook.

Siamo davvero pronti a questo salto? Gli strumenti di assistenza per i quotidiani task relativi al networking (locale e remoto) sono all'altezza? Mi piacerebbe metterli alla prova, switchando la mia LAN appunto al routing IPv6, non fosse che la versione di dd-wrt flashata sulla mia Fonera non supporta tale protocollo e non riesco a fare l'upgrade alla versione successiva: partiamo subito male...

Una Mela in Testa

Da quando ho iniziato a leggere e documentarmi sul tema dell'usabilita' delle interfacce utente ho piu' volte sentito parlare nell'Apple Newton, PDA uscito agli inizi degli anni '90 e di breve vita sul mercato, indicato da molti come un ottimo esempio di efficienza e rappresentativo di alcuni concetti particolarmente interessanti. Ma ammetto di non aver mai indagato approfonditamente su tale oggetto, prendendo sempre per buone le entusiastiche dichiarazioni ma inconsciamente pensando che le funzionalita' di tale apparecchio fossero, a causa dell'evidente anzianita' del prodotto, cosi' limitate da non meritare neppure di essere prese in considerazione.

Finche' l'altro giorno mi sono trovato a leggere un articolo (peraltro generatore di infinita ispirazione, dovro' tornarci sopra in futuro), in cui viene indirettamente linkato un video su YouTube che dimostra l'utilizzo del leggendario Newton. E ne sono rimasto sbalordito.

L'utilizzo del device e' molto semplice: c'e' uno schermo completamente touchscreen, ci si scrive sopra quel che si vuole (con la tastiera virtuale o a mano: stando al video l'handwriting recognization del '90 non era cosi' tanto male, e' un peccato che nel ventennio seguente non sia piu' stata migliorata), e... il contenuto viene trasformato in un altro tipo di contenuto a seconda di quello che viene riconosciuto, o dietro suggerimento dell'utente. Insomma: se si scrive "pranzo con Mario" si puo' andare a piazzare il nuovo appuntamento nel calendar, se si scrive "chiama Pippo" viene lanciata la chiamata, se si immette un numero telefonico si apre il form per la creazione di un nuovo contatto.

Chiaramente, il primo richiamo che ho avuto e' stato il progetto Lobotomy e l'originale idea di rendere trasversali i dati indipendentemente dal formato con cui venivano trasmessi o manipolati. Anche se il concetto introdotto nel Newton e' un poco diverso: non quello di trasformare i vari contenuti in qualcos'altro, ma trasformare caso per caso un unico tipo di contenuto (la nota, atomo primario del modello di interazione) in qualcosa di piu' strutturato e specifico.

Resta il fatto che gia' allora gli ingegneri Apple avevano avuto l'illuminazione e l'avevano trasposta in un prodotto commerciale e alla portata degli utenti (si, d'accordo: solo degli utenti facoltosi, considerando il prezzo, ma ci siamo capiti...): ignorare totalmente nozioni tecniche e nerdeggianti come il "file" o il "formato", ma occuparsi in modo semi-automatizzato di tali dettagli e lasciare che l'utilizzatore si concentrasse sull'informazione nuda e cruda.

Il PDA in oggetto spari' rapidamente dal mercato, vuoi perche' le tecnologie hardware dell'epoca erano ancora troppo limitate per uno sfruttamento del concept (una agenza cartacea delle stesse dimensioni poteva tranquillamente contenere una mole di informazioni molto superiore rispetto ai suoi modesti circuiti di rame e pietra), vuoi perche' il popolo di consumatori non era ancora pronto per esso (nell'era pre-Web2.0 quanti sarebbero stati disposti a spendere quella cifra per un blocco note molto sofisticato?) e vuoi anche perche' essendo tutto il sistema integrato non c'era spazio per l'ingresso di altri vendors che fornissero applicazioni e servizi (come e' invece adesso per apparati tipo l'iPad) dunque nessuno poteva essere realmente interessato alla sua diffusione priva da sbocchi commerciali e profittevoli per chiunque altro non fosse Apple. Ma a distanza di vent'anni varrebbe la pena rivalutare e riesaminare i concetti che all'epoca sono stati compressi nello scatolotto nero, poco apprezzabili negli anni '90 ma perfettamente attuali ed anzi impellenti nel mondo di oggi.

Perche' reinventare la ruota, quando buona parte del lavoro e' gia' stata svolta?

Aggiornamento nell'Ombra

Manco il tempo di finire di scrivere il precedente post sui potenziali vantaggi di un meccanismo di aggiornamento interno alle applicazioni, in grado di pescare autonomamente informazioni sulla disponibilita' di nuove versioni da scaricare ed installare in modo trasparente e senza disturbare l'utente, che subito salgono agli onori della cronaca notizie sulle prossime evoluzioni di Chrome, il web browser targato Google.

Stando alle ultime presentazioni per il prossimo futuro di tale prodotto si prevede di soppiantare la tendenza prettamente tecnofila di rilasciare le varie versioni identificandole da un numero sequenziale, ed invece impacchettare piccoli cambiamenti ad intervalli regolari e tra loro ristretti (sei mesi) e diffonderli sui desktop del pianeta con un automatismo silenzioso. A ben guardare Chrome da sempre gestisce in questo modo gli aggiornamenti di se' stesso, addirittura compiendo un controllo sul repository centralizzato ogni cinque ore, ma evidentemente il concetto e' stato migliorato e raffinato ulteriormente. Si mormora inoltre che pure la prossima major release di Firefox, la 4 includera' tale funzionalita'.

Come intuibile, appunto, dal post pubblicato l'altro giorno su questo stesso blog questo genere di soluzioni mi garba assai. Tantopiu' per applicativi come i web browser, diventati strumenti essenziali nella vita digitale di ciascuno e cosi' frequentemente bersagliati da attacchi mirati alla loro sicurezza da patchare il piu' presto possibile a prescindere dalla noncuranza dell'utente. Certo chi sviluppa un browser non ha tutta questa urgenza di diffondere nuove features, in quanto in fin dei conti tale classe di software operativo non espone particolari funzionalita' necessariamente sempre nuove (renderizzano le pagine, salvano i bookmarks, aprono e chiudono le tabs, poco altro), ma le migliorie per quanto piccole e discrete son sempre gradite, soprattutto quando non ci si deve attivare in prima persona per ottenerle.

D'altro canto, immagino che nel momento in cui i singoli programmi provvedano per conto proprio all'aggiornamento si possano creare non pochi grattacapi per i packagers delle distribuzioni. Cosa mettere nei repository? Cosa succede se all'atto dell'invocazione di un "apt-get upgrade" la versione proposta e pacchettizzata e' piu' vecchia di quella scaricata autonomamente? Come fronteggiare eventuali aggiornamenti che richiedono librerie e pacchetti particolari, e dunque da installare o a loro volta aggiornare per il supporto di una nuova funzionalita'?

Per non parlare dei futuri (ma comunque non immediati) problemi tecnici che potrebbero sorgere qualora tale pratica dovesse diffondersi: come arginare la potenziale esplosione di comunicazioni verso l'Internet, dovute al fatto che ogni singolo programma pretenderebbe di contatterebbe ad intervalli periodici il proprio server di riferimento in cerca di qualcosa di nuovo da scaricare? E come reagirebbe quella nicchia di utenti cultori della privacy e del pieno controllo dinnanzi alla necessita' di dover disabilitare (o nella peggiore delle ipotesi filtrare con metodi piu' radicali) siffatte transazioni non richieste per ognuno dei software utilizzati?

La soluzione ad entrambi i suddetti tipi di ostacoli potrebbe stare in una evoluzione degli attuali package managers, affinche' forniscano nativamente la funzionalita' di auto-upgrade per i programmi che lo richiedono, coordinando ed ottimizzando le connessioni verso l'esterno e provvedendo un unico centro di configurazione per chi ha il tempo da perdere verificando chi sta facendo cosa. Dirottando tutto al manager centralizzato esso sarebbe sempre consapevole di quale precisa versione e' in uso in un dato momento, quali sono i pacchetti che si auto-aggiornano per fatti propri e quali devono essere allineati con i repository della distribuzione secondo lo schema classico, e come comportarsi con le dipendenze.

Forse adesso e' troppo presto per porsi questo genere di domande, in quanto appunto solo Chrome e Firefox si stanno muovendo verso la direzione dell'autogestione. Ma nel momento in cui dovesse essere osservato un trend piu' cospicuo sarebbe opportuno correre ai ripari il prima possibile, mettendosi d'accordo tutti insieme su come amministrare in modo pacifico la legittima richiesta di aggiornamenti frequenti con la necessita' di far convivere numerosi pacchetti ognuno con una propria sequenza di versioning, ed evitare che codesta emergente moda dilaghi fino a minare uno dei pilastri su cui si poggia il successo del desktop Linux, appunto il package management.

Prevenire e' meglio che curare.

I Piccoli Aggiornamenti

Tra le attivita' che maggiormente reputo degne di essere completamente delegate alla macchina in modo da non tediare l'utente c'e' sicuramente l'aggiornamento del software installato. Ad oggi qualsiasi distribuzione Linux monta di default un package manager, che si occupa automaticamente di verificare la disponibilita' di nuovi pacchetti e risolve le dipendenze in fase di installazione ed aggiornamento, ma comunque la sua esecuzione dipende dalla volonta' e dall'attenzione dell'utente che o se ne dimentica o viene periodicamente disturbato da notifiche sul suo desktop.

Ad oggi, comunque, l'esecuzione schedulata e silenziosa di un "apt-get update; apt-get upgrade", magari per mezzo di cron, e' assai poco consigliata: troppo spesso accade che tale operazione venga lanciata nel bel mezzo di un update massivo sul repository di pacchetti di riferimento, e se non ci si prende la briga di leggere cosa viene richiesto di fare basta veramente troppo poco per trovarsi, in virtu' di qualche estroso conflitto nelle dipendenze, il desktop environment o qualche driver importante disinstallato.

Ma d'altro canto c'e' un intero universo di componenti software che non sono affatto gestiti (o comunque sono solo marginalmente trattati) dai package manager, e che produrrebbero un danno limitato anche qualora per disgrazia fossero gestiti male: i plugins.

Ogni applicazione evoluta oggi esistente mette a disposizione una ricca API con cui qualsiasi developer puo' aggiungere funzionalita', a volte modeste e a volte molto pesanti, e la tendenza a distribuire in questo modo lo sviluppo tra il maintainer del core principale e gli occasionali partecipanti e' in evidente crescita (forse anche dopo aver constatato l'enorme successo avuto dal concetto di "estensione" applicato al popolarissimo Firefox).

L'unico problema e' che raramente si trovano repository unici di estensioni e plugins destinati ad una specifica applicazione, ed occorre andarsele a cercare appositamente (assumendo ovviamente che se ne conosca l'esistenza). Il mio esempio preferito e' Inkscape: sul sito esiste una raffazzonata pagina dedicata ad indicizzare alcune estensioni esistenti, ma al fondo di essa si trovano tracce di un eventuale progetto strutturato e mirato a tale scopo che risalgono a maggio 2010.

D'improvviso, leggo oggi sul blog di Aaron Seigo il proposito di fornire una sorta di protocollo di auto-discovery per i DataEngines di Plasma (che, detto terra terra, sono delle estensioni di KDE). In sostanza il personaggio descrive uno scenario che io stesso medito da tempo: utilizzare qualcosa come il formato Open Collaboration Services (da me stesso implementato per Gnome) per comunicare ai clients degli utenti variazioni sullo stato dei componenti installati, ed ai fatti provvedere ad una sorta di package management isolato e dedicato ad una nicchia precisa. In un colpo solo si bypasserebbe il management ufficiale delle distribuzioni (che tendono ad essere in ritardo rispetto alle releases dei pacchetti veri e propri), si avrebbe un sistema di aggiornamento unico per tutte le piattaforme, e si estenderebbero le potenzialita' dell'amministrazione di sistema semi-programmatica anche ai frammenti di software sinora bistrattati ed esclusi dalle cure dei packagers.

Per quanto le mire di Seigo siano di molto basso profilo (appunto, limita la sua stessa idea all'aggiornamento dei DataEngines quando potrebbe essere applicato ad ogni genere di estensione), auspico che qualcuno lo stia a sentire e provveda a studiare una soluzione al problema, da poi riutilizzare in altri contesti.

Uno dei piu' grandi vantaggi di Linux rispetto alle altre piattaforme operative e' proprio l'elevato grado di maneggiabilita' dei pacchetti software installabili; tanto vale spremere il massimo da tale concetto, usarlo per dare risalto a sempre piu' opere e farne uno dei canali di penetrazione piu' aggressivi per il software libero.

Riuso Fai-da-Te

Una delle cose che piu' amo del software libero e' la possibilita' di utilizzare e riutilizzare all'infinito frammenti e porzioni di codice, magari anche in contesti diversi rispetto a quello entro cui sono stati scritti. Spesso e volentieri io stesso mi trovo a copiare e incollare funzioni o intere classi dall'Internet, pescando dai repository, e al "costo" di poche righe di commento destinate ad indicare il copyright dell'autore originale si ottiene in pochi secondi la funzionalita' desiderata.

Tale proprieta' non e' purtroppo sempre applicabile ai componenti software complessi.

In questo periodo mi sono trovato a dover elaborare una soluzione composta, in buona sostanza, da un captive portal, un pannello per la gestione delle utenze, ed una centralizzazione degli accounts su un unico server. Scopo del gioco: esibire i documenti per l'autorizzazione alla navigazione web (grazie, Pisanu) una volta sola, e poter poi accedere a tutti i locali all'interno del network convenzionato e geograficamente sparso usando sempre la stessa utenza.

Di captive portal opensource e' pieno il web. Nessuno di questi prevede una gestione avanzata degli accounts, i quali sono sempre e solo gestiti localmente. E, anche volendo dirottare le connessioni al database con qualche hack (pericoloso, in quanto comunque deve esistere un meccanismo di validazione dei routers periferici nei confronti del server centrale), non sarebbe comunque possibile personalizzare in modo agevole le anagrafiche trattate per fargli fare quel che mi serve (banalmente: associare gli accounts ai soci dei locali nel network, con tutto quel che ne consegue in termini di scadenze delle iscrizioni).

Dopo ardue ricerche incrociate, e valutazione di diversi blocchi di codice pescati qua e la', non son riuscito ad isolare i pezzi che mi servivano ed alla fine ho ceduto ed ho ben deciso di rifare tutto daccapo prendendo ispirazione qua e la'.

Purtroppo non si puo' porre un argine a questo problema, comune a pressoche' qualsiasi applicazione complessa. Isolare in modo chirurgico i componenti e' una best practise che esiste solo sui manuali accademici di ingegneria software, nel mondo reale non si puo' fare in quanto comunque alcuni presupposti (ad esempio: la gestione e la validazione degli utenti) devono essere validi a priori in tutto il sistema ed inevitabilmente vanno a cozzare contro i presupposti usati altrove.

Quel che piu' mi perplime comunque non e' l'utilizzo di componenti separate, quanto l'utilizzo di piu' componenti insieme. In questo periodo mi sto molto interessando alla questione della legge regionale piemontese per la promozione del software libero, e spesso scopro che alcune amministrazioni in giro per l'Italia e per l'Europa hanno gia' rilasciato questo o quest'altro frammento potenzialmente utile per altre amministrazioni, ma temo il giorno in cui esse dovranno essere messe insieme e proposte a mo' di pacchetto chiavi-in-mano a qualche istituzione: ciascuna e' stata scritta con un framework diverso, in un linguaggio diverso, con specifiche ed architetture diverse, e presenta una interfaccia diversa, organizzata in modo diverso. Mettere insieme tutti questi pezzi, che presi singolarmente sono assai utili ma comunque non determinanti, si annuncia come una missione impossibile, e gia' so che il giorno in cui si prendera' di petto la questione molti di essi dovranno essere in buona parte riscritti. I sogni di riusabilita' immediata e propagazione del software pubblico sono destinati ad infrangersi contro lo scoglio del pragmatismo.

Ancora oggi la riusabilita' e' un mito. Che urge sfatare, per sbloccare finalmente in modo completo l'immenso potenziale del software libero.