Pensieri e parole su HCI, home computing, tecnologie desktop e sul Progetto Lobotomy

venerdì 27 aprile 2007

O' Sole Mio

0 commenti
Una delle tecnologie a mio parere piu' innovative ed allo stesso tempo piu' snobbate dell'oramai incombente KDE 4 (il cui hype e' oramai alle stelle, sebbene gli screenshots di una distribuzione appositamente costruita per dare un assaggio del nuovo ambiente visti pochi giorni fa' lascino moltissimi dubbi sull'effettivo stato di QT4...) e' Tenor, framework per l'indicizzazione "ponderata" dei files. Al contrario di Strigi (il quale, bene o male, e' l'ennesima re-implementazione di Beagle), esso non si limita ad indicizzare il contenuto dei documenti per facilitarne la ricerca, ma li mette pure (e soprattutto) in relazione tra loro, organizzando di fatto il filesystem in un grafo che puo' essere percorso secondo innumerevoli paths.
L'idea mi sembra ottima: l'approccio e' diverso da quello adottato da un po' tutti i progetti che rientrano nella categoria "desktop search" (in cui, volenti o nolenti, rientra pure in un certo modo Synapse), e va ad aggirare il "point of failure" primario di ogni sistema di ricerca: l'utente. Poiche' una ricerca in senso classico e' condotta pur sempre da una persona, essa utilizzera' delle chiavi (rigide) per le sue interrogazioni, e non e' in alcun modo garantito che queste chiavi portino a risultati (altrettanto rigidi) attinenti a quanto desiderato; costruendo invece il result set su parametri "fuzzy", non perfettamente definiti ma con quel particolare margine di tolleranza tra "quello che vuole l'utente" e "quello che somiglia a quel che vuole l'utente", implicitamente il sistema non produce una lista statica di elementi ma piuttosto una serie di suggerimenti, i quali possono andare a coprire non solo quel che il fruitore andava cercando ma anche documenti piu' o meno attinenti di cui magari aveva perso memoria e che mai piu' avrebbe trovato rifacendosi solo ed esclusivamente ad un marmoreo indice.
Spero di poter trarre qualche ispirazione da cotanto progetto, che purtroppo, pur essendo considerato parte del gia' citato KDE 4, sembra essere defunto (ad oggi, il repository non e' aggiornato da 2 mesi...), e consiglio caldamente la lettura del paper descrittivo dell'architettura (che si trova nel sopra linkato repository, nella cartella "docs", in formato PDF).

domenica 22 aprile 2007

A passo di gambero

0 commenti
Mi accorgo (adesso!) di aver adottato un approccio sbagliato per quanto riguarda il set di tools che accompagnano e avrebbero dovuto accompagnare la release di Hyppocampus: l'idea di base era quella di fornire strumenti che facilitassero l'accesso da linea di comando al filesystem, ma appare evidente il fatto che e' impossibile mettersi a re-implementare tutti i classici ls, rm, touch et similia.
Pertanto, dalla prossima release (su cui ho gia' iniziato a metter le mani, pur avendo rilasciato la 0.2.2 ieri!), hls e hattr non ci saranno piu', ed allo stesso modo non ci saranno hrm, htouch..., ma il tutto sara' sostituito da un unico eseguibile (dal nome provvisorio di "htrad") il cui output potra' essere usato come parametro per tutti i comandi cui tutti siamo abituati. Sostanzialmente non sara' altro che un implicito link alle funzioni di traduzione in LibHyppo, percui sara' possibile specificare i nomi dei metadati con una stringa anziche' con l'identificativo numerico.
ls `htrad "SELECT META_NAME WHERE META_ID > "`
Al piu', potra' esserci uno strumento addizionale per creare nuovi files, in quanto al momento l'interfaccia, essendo POSIX, fa riferimento agli elementi in base al nome, e siccome in Hyppocampus possono esserci files con lo stesso nome spesso non si ottiene il risultato sperato.

0.2.2

0 commenti
Ho or ora rilasciato la release 0.4.1 di SubConsciousDaemon, la 0.2.2 di Hyppocampus, e molto volentieri avrei fatto altrettanto per Synapse se non fosse che, tanto per cambiare, BerliOS e' offline (fate un favore a voi stessi: se avete qualcosa da rilasciare, evitate questa piattaforma: io stesso ambisco a spostare il mio pacchetto altrove)...
Le novita' non sono di particolare spicco ma comunque interessanti.
Nel pacchetto di Hyppocampus sono state aggiunte un paio di utility, le prime di una (si spera) lunga serie, che permettono un piu' facile e trasparente accesso al filesystem relazionale dall'interfaccia a linea di comando. Esse saranno estremamente utili nel momento in cui mi decidero' a sviluppare un testbed per valutare prestazioni e stabilita' del prodotto...
In LibHyppo (che si trova nel pacchetto di Hyppocampus) si trova la funzioncina di traduzione precedentemente menzionata, prontamente sfruttata in Synapse e nei tools commandline sopra citati: grazie ad essa ora e' un poco meno complesso navigare i contenuti della base dati, ma ancora numerose euristiche di traduzione sono da includere (manca ancora totalmente la gestione delle date).
In Synapse (e soprattutto in Kiazma) fa ora bella mostra di se' la modalita' "shell" dell'OnMouse-Shell: abilitandola dal pannello di configurazione, cliccando e trascinando il cursore del mouse tenendo premuto il tasto centrale si apre un terminale in cui viene eseguita una bash. Al momento non fa un gran che' (o meglio: non fa quello che si desidera faccia; per il resto e' una comune shell, dunque esegue tutti i comandi che si desiderano!), ma per il prossimo futuro e' schedulata una maggiore integrazione tra il widget di formattazione in icone (attualmente derivato da GtkIconView, prossimamente riscritto da zero partendo da Cairo) e l'OnMouse-Shell.
SubConsciousDaemon, eletto a pacchetto standalone (prima era incluso in Synapse), e' stato arricchito da una API per la creazione di plugins che estendano le possibilita' di estrazione automatica dei metadati dai files: e' ancora ampiamente da rivedere (temporaneamente si trova in LibHyppo, dalla prossima versione sara' tutto spostato in una nuova LibSubconscious), ma la sua funzionalita' e' dimostrata dall'allegato plugin dedito all'identificazione del linguaggio di ogni file testuale aggiunto nel filesystem.
L'annuncio l'ho fatto. Non mi resta che definire per bene cosa includere nella roadmap per la release 0.2.3 ...

martedì 17 aprile 2007

XFCE

0 commenti
Ultimamente sono stato piacevolmente sorpreso dai grandi progressi fatti da XFCE, che nelle ultime releases ufficiali (un po' tutte quelle della serie 4.0) ha presentato innovazioni su innovazioni dimostrando quanto la definizione "window manager leggero per computers obsoleti" ben si addicesse ma stesse un poco stretta.
Esso e' (o quantomeno, punta a diventare) un desktop environment completo, con tutta la sua serie di applicazioni integrate in un'unico ambiente operativo, e non solo i pilastri del sistema sono stati da tempo eretti (con il filemanager Thunar ed il texteditor Mousepad) ma si e' gia' iti ben oltre con una piccola suite multimediale, un manager per gli archivi compressi (ad opera di un italiano ;-) ), un calendar... ed il supporto per le estensioni grafiche composite di X.org!
Gia' in passato ho preso a piene mani dal progetto, tanto che lo stesso BrainTop (correntemente in fase di standby) e' in sostanza un fork dello stesso e Synapse molto si ispira al gia' citato Thunar, e fortemente spero che il progetto possa continuare con lo stesso ritmo dimostrato nell'ultimo anno. Anzi, diro' di piu': essendo implicitamente BrainTop compatibile con esso (partendo dalla stessa base di codice) prometto che avro' un occhio di riguardo per far si che quanto piu' possibile di quanto da me sviluppato possa andare ad arricchire la base del sorgente originario, si da supportare non solo con le parole ma anche con un po' di sano lavoro la monumentale opera.
Ci tengo a sottolineare per la seconda volta il supporto all'estensione Composite (quella comunemente identificata col nome di AIGLX) integrato nel window manager: grazie ad esso si potranno facilmente implementare soluzioni grafiche "esoteriche", non comuni e non senza un tocco di eye-candy (che "fa figo e non impegna"), soprattutto per mezzo di Cairo; non appena avro' imparato a padroneggiare meglio quest'ultima libreria vedro' di implementare qualche widget all'interno di Kiazma, bypassando l'ottima ma rigida (come tutti i toolkits) GTK+ e sperimentando per davvero qualcosa di nuovo...

sabato 14 aprile 2007

Plumb inverso

0 commenti
Negli ultimi due giorni sono stato nuovamente attratto nel "vortice" di Wikipedia: leggo, seguo links di ogni sorta, e con la scusa di tradurre due o tre articoletti dall'edizione anglo-americana a quella italiana leggo apprendo talune preziose informazioni. Come spesso accade, anche questa volta mi sono soffermato sui brani riguardanti Plan9, il sistema operativo sviluppato nei Bell Labs come alternativa distribuita a Unix: mi affascinano molti aspetti della sua organizzazione, e l'innovazione e la creativita' permeano ogni piccolo particolare.
In particolare, questa volta ho approfondito la nozione del plumber: esso e' un demone che si occupa di gestire automaticamente la clipboard, selezionando in modo autonomo in base ad un set di regole predefinite le applicazioni disposte ad accogliere il dato "plumbed" dall'utente come alternativa al piu' classico "copia&incolla" (ove e' necessario esplicitare l'applicazione di destinazione).
Ho meditato, ed ho concepito l'idea del plumb inverso: invece di avere un demone che sceglie l'applicazione in base all'informazione, perche' non selezionare l'informazione in base all'applicazione? Questa domanda puo' apparire priva di significato se si pensa alla classica modalita' di interazione col PC cui siamo abituati, ma acquista nuovo valore se contestualizzata in Lobotomy ed ancor piu' se ci si rifa' al proposito di astrarre, per mezzo del filesystem relazionale Hyppocampus, i dati e la loro formattazione.
Immaginiamo di avere il client di posta, con la sua bella rubrica, ed un editor grafico. Se io selezionassi un singolo contatto (che, come descritto non molto tempo addietro, viene trattato come un singolo elemento nel filesystem e puo' essere pertanto singolarmente trattato nell'interfaccia grafica) da una parte e lo trascinassi dall'altra, chiaramente l'informazione non avrebbe senso per il programma abituato a vedersi arrivare immagini e foto. Ma qui interverrebbe il "plumb inverso": intercettando l'operazione, potrebbe cercare nel filesystem le immagini che hanno come metadato META_PEOPLE_INTO_PICTURE (ebbene si: e' mappato pure questo parametro nella lista inclusa in LibHyppo :-P ) il riferimento al contatto appeso al cursore del mouse dell'utente, farne scegliere una a quest'ultimo (con una interfaccina temporaneamente messa in primo piano, simile ad Expose'), e sostituire prontamente l'elemento in clipboard, si' da far arrivare all'applicazione destinataria una informazione consona al suo utilizzo.
Gli utilizzi sono infiniti: potrei trascinare file di testo sul player musicale e sentirlo recitare, trascinare un file sul programma di archiviazione ed avere un riferimento al .tar.gz in cui si trovava originariamente, un documento PDF sul browser ed essere diretto alla pagina web da cui lo avevo scaricato, la foto di un amico sul tool di instant messaging ed aprire una sessione di chat con lui...
Probabilmente nei prossimi giorni scrivero' un paper descrittivo con qualche mockup da pubblicare sul sito primario del progetto: rimanete in linea ;-P !

venerdì 13 aprile 2007

Fatto a mano

0 commenti
Tra i sotto-obiettivi di Lobotomy si trova la volonta' di creare una interfaccia completamente fruibile per mezzo di touchscreen e/o di tablet (di cui sono fortunato possessore ;-P ), e tale progetto si concretizzera' con Thalamus e Stirnbein. Non mi dilungo ulteriormente su questi ultimi due (anche perche' ancora poco definite sono le idee in merito), ma mi soffermo sulle idee scaturite nel corso di quest'ultima settimana.
Avrei intenzione di includere in Kiazma una API che estenda i widgets di input testuale, per fare in modo che alla selezione di essi compaia una comoda finestrella in cui immettere il testo per mezzo dello stylus: essa potrebbe ospitare, in due tabs, sia una tastiera on-screen minimale (simile a quella inclusa in gok, ma limitata ai soli tasti delle lettere e dei numeri) che un campo ove tracciare liberamente la stringa e da parsare con un algoritmo di riconoscimento. Purtroppo al momento il software di handwrite recognization disponibile sotto licenza aperta non e' moltissimo, e spesso si limita all'identificazione di glifi o, peggio ancora, di semplici gestures: a me piacerebbe molto implementare qualcosa di piu' "user-centric", per riconoscere intere parole rappresentate con un singolo tratto, come sulla carta, sebbene sia perfettamente a conoscenza della complessita' dell'impresa.
Qualche idea e' comunque sorta in merito: primo tra tutti, si potrebbe usare una versione modificata della LibStroke che operi su un reticolato piu' fitto (attualmente, la libreria usa una matrice 3x3 per identificare i tratti: bene per le gestures, meno bene per delle lettere in corsivo) e per cui non sia necessario "mappare" ogni singolo glifo riconosciuto in modo esplicito ma che si appoggi ad una rete neurale che si autoadatti automaticamente in funzione dell'uso dell'utente e delle parole che via via vengono identificate in un modo e corrette in un'altro. In secondo luogo, sarebbe bene fare largo, larghissimo uso (soprattutto nella fase di apprendimento della sopra menzionata rete neurale) degli algoritmi comunemente usati nei tools di correzione automatica (come quello della distanza di Levenshtein): il risultato estratto dalla rete in base al tratto dell'utente puo' essere facilmente validato su un dizionario, per verificare che effettivamente la parola indovinata abbia un senso o per trovarne una realmente esistente quanto piu' simile ad essa; in tal senso, ho immesso nella mia interminabile lista di TODO l'implementazione di una versione di dictd la cui lista di parole sia automaticamente popolata e costantemente arricchita per mezzo di dizionari online (come Wiktionary) compilati dalla community.
Quest'ultima sara' ovviamente una applicazione usabile anche in contesti diversi a Lobotomy (essendo niente piu' e niente meno che una implementazione del protocollo DICT), stavo pensando di nominarla Broc@ in onore di Paul Broca...

lunedì 9 aprile 2007

Lobotomia via ethernet

0 commenti
Questo e' un periodo molto fertile per quanto riguarda le elucubrazioni sullo sfruttamento della rete in Lobotomy.
Da tempo vado meditando ad una implementazione networked di Hyppocampus, nominata Serine (dal nome di un neurotrasmettitore...), e, sebbene sia un progetto ancora assai fumoso, si vanno delineando taluni aspetti. Per intanto, sara' costruito su avahi: il che vuol dire che sara' per lo piu' dedicato alle LAN, con la rilevazione automatica dei peers che montano lo stesso servizio, anche se ovviamente sara' possibile comunicare anche con altre macchine attraverso l'Internet. Sara' possibile *non* copiare un file da una macchina all'altra, ma semplicemente crearne una rappresentazione il cui metadato "path" indichi (con una URI) il sistema su cui risiede: questo per evitare la ridondanza di molteplici copie di uno stesso elemento sparpagliate su una LAN di cui si detiene il controllo (quella domestica, ad esempio), e per mantenerne comunque una referenza, si' da sapere dove andare a pescare un dato elemento e fingere che si trovi sul disco locale, mascherando la sua locazione effettiva a chi lo sta consultando e per coinvolgerlo comunque nell'esecuzione delle query SQL di ricerca.
Ma Serine non e' l'unica applicazione di rete prevista in Lobotomy: anche per SCD sono previste funzionalita' che sfruttano largamente l'interconnessione di macchine. Ho schedulato proprio oggi un task in cui si fa cenno ad una alternativa al multithreading (studiato per lo piu' per i potenti processori multicore di oggi) per l'estrapolazione di metadati da un file, basato sul paradigma di distribuzione del calcolo facilmente implementabile con Boinc: questo per venire incontro a chi vuole spremere ancora qualche ciclo di clock dal proprio hardware obsoleto, si da dedicarlo ad esempio all'analisi semantica dei documenti aggiunti nel filesystem e permettergli di "contribuire" all'arricchimento della base relazionale, ma anche con l'idea di integrare un tool di "estrazione collaborativa" (ispirato vagamente all'Xgrid di Apple) per cui gli utenti in una LAN potranno mettere a disposizione la potenza di calcolo del loro laptop per contribuire a quelle operazioni di analisi computativamente pesanti richieste da un singolo.

domenica 8 aprile 2007

Umano-Hyppocampus / Hyppocampus-Umano

0 commenti
Lo sviluppo della release 0.2.2 procede piuttosto speditamente, anche perche' gli obiettivi prefissi sono di minore complessita' rispetto a quelli delle precedenti versioni ma comunque di notevole impatto.
Tra tutte le nuove features, spicca la routine di "traduzione" umano-Hyppocampus. Che cos'e'? E' una funzione che, data in ingresso una query scritta dall'utente nella maniera a lui piu' congeniale (con i metadati espressi con il loro nome tradotto nella locale corrente, le date nel classico formato DD/MM/YY o comunque come definito dalle impostazioni locali...), restituisce una query pronta per essere sottoposta al parser ben piu' restrittivo del filesystem (il quale accetta solo metadati espressi con il loro ID univoco, date in Unix time...). Questo e' un discreto ed ovvio passo avanti in termini di usabilita': certamente sono ancora ben lungi dall'intepretare il linguaggio umano in toto, ma e' pur sempre un progresso...

martedì 3 aprile 2007

Il Desktop Semantico

0 commenti
Diverso tempo addietro lessi, tra i moltissimi altri articoli riguardanti KDE e la sempre piu' imminente release 4, qualcosa in merito all'integrazione di NEPOMUK nel noto desktop environment. Tralasciando i negativi commenti sull'ingiustificato hype creato intorno alla prossima versione del suddetto KDE (le aspettative sono oramai altissime, le promesse tante e difficilmente soddisfacibili, temo che per molti la delusione sara' grande...), assai incuriosito sono rimasto dall'altro esotico (ed esoterico) nome che lo ha accompagnato: dopo breve ricerca, si scopre che NEPOMUK e' un baldanzoso progetto relativo al "desktop semantico", la cui pagina di riferimento pullula di belle frasi dallo scarso significato e taluni documenti il cui grado di fuffosita' si mantiene alto dalla prima all'ultima pagina. Di software non se ne vede manco di lontano.
In particolare, leggendo il paper che descrive la relazione tra i due progetti si capisce (o quantomeno si intuisce) quello che dovrebbe essere il significato dell'altezzosa polirematica "desktop semantico": un normalissimo desktop environment che permette all'utente di assegnare tags (e tengo a precisare: tags, non metadati nel senso "lobotomystico" del termine) ai files.
Personalmente trovo i tags, ovvero quelli che per definizione sono ne' piu' ne' meno che parole assegnate a qualcosa, sostanzialmente inutili, in quanto impossibili da catalogare e relazionare tra loro: un singolo lemma porta con se' ben poca informazione, senza considerare che, ad esempio, "Lobotomy Project" e "lobotomy" sono due entita' distinte e separate sebbene indichino la stessa cosa. Proprio per questo Hyppocampus contiene metadati, ovvero coppie chiave-valore ben definite e mappate secondo uno schema unico ed univoco per tutti.
Tornando al NEPOMUK: il sopra linkato paper non solo dice veramente poco in merito al progetto in se' (per i primi tre quarti riassume i componenti "legacy" di KDE), ma quel poco e' pure mescolato ad una serie di termini e sigle il cui significato rimane oscuro (o comunque assai poco chiaro) pure dopo visione delle pagine e pagine web che si aprono dopo una breve ricerca, tra cui spicca l'acronimo RDF.
Che e' RDF? In una parola: XML. In due parole: zozzerie XML. A quanto leggo nella relativa pagina su Wikipedia (l'unica che contiene effettivamente qualche indizio accessibile all'intuizione umana, al contrario della serie di pagine dedicate allo stesso argomento sul sito di W3C) altro non e' che una formalizzazione dei metadati in un formato XML, che consta in un tag all'inizio, uno alla fine, e ben poco altro. Chi mi conosce lo sa: solitamente poco apprezzo queste pseudo-tecnologie le cui specifiche consistono in "Wow, e' una figata pazzesca!" e nulla piu', spesso poco utilizzate per il semplice fatto che non sono comprensibili.
Insomma, per farla breve: a quanto mi e' dato di capire, i sostenitori del cosiddetto desktop semantico, modernissimo paradigma di interazione, fanno dell'imprecisione e dell'imperfezione dell'utente (ovvero: colui che definisce i tags per i singoli oggetti) il proprio vessillo, dimentichi del fatto che se siamo qui a discutere del desktop di domani e' proprio perche' quello di ieri era succube dell'utente stesso, incentrato sull'organizzazione gerarchica a directory (sempre definita appunto dall'utente), e non riesce piu' a rispondere alle esigenze di ordinamento e ricerca dettate dalla mole sempre piu' imperiosa di dati da trattare.