Nella tana del Leopard

Come si poteva pretendere che su questo blog non si facesse almeno un cenno alla recente performance di Steve Jobs (CEO di Apple, per chi fosse appena giunto sul pianeta Terra e non lo sapesse...) al WWDC 2007? Inutile dilungarsi ulteriormente in merito all'evento in se' (tutta l'Internet ne parla, come spesso accade per le iniziative della casa di Cupertino...), ed andiamo direttamente al sodo: MacOS X Leopard.
Annunciato come una grande evoluzione del sistema operativo con la Mela, il quale e' a sua volta universalmente riconosciuto come il piu' innovativo ed usabile sistema desktop, la keynote sull'imminente rilascio ha allo stesso tempo stupito e deluso molti: niente ZFS, ma un file manager estremamente potente e flessibile; la Time Machine ridotta ad una mera funzionalita' di backup, ma lo Spotlight potenziato per l'individuazione delle funzionalita' all'interno delle applicazioni.
Assunto che una buona parte delle "innovazioni" sembra poco piu' che un pretesto per sfoggiare orpelli grafici sbrilluccicosi e di scarso interesse pratico (come del resto gia' e' accaduto con Windows Vista...), e che una ulteriore vagonata di effetti speciali fini a loro stessi e' prevista per la presentazione ufficiale di Core Animation, mi permetto di fare qui un compendio di quelli che, a parer mio e a poche ore dalla fine della conferenza che tanti clamori ha provocato e molti altri e' destinata a provocare, sembrano gli aspetti piu' interessanti dell'approccio di interazione offerti da MacOS 10.5:

• il Quick Look e' una funzione avanzata di preview dei files: ottima l'idea di mostrare le anteprime in un frame posto in primo piano, certamente piu' comodo ed efficiente che non le striminzite iconcine cui siamo abituati
• il gia' citato potenziamento di Spotlight, che consente ora di cercare anche le funzionalita' piu' avanzate e nascoste delle varie applicazioni, e' davvero notevole: sebbene sia deplorevole il fatto che esistano programmi cosi' complessi che non si sappia dove andare a cercare il pulsante per attivare una particolare opzione, mi rendo conto che in taluni casi (come nei software di edit grafico avanzato) non si possa fare altrimenti, dunque ben venga un supporto universalmente accessibile e riconoscibile
• gli Stacks sul desktop sono veramente graziosi: permettono di avere a portata di mano un gruppo di files, direttamente nel docker e senza aprire il file manager. Quantomeno sembra di veloce accesso, sebbene temo non scali molto bene su quantita' crescenti di elementi... Ci hanno provato...
• la Time Machine avrebbe potuto essere una buona idea, e sarebbe anche stato assai facile implementarla appoggiandosi sullo ZFS di Sun, ma a quanto pare non verra' sfruttata come sperato: certamente il versioning dei files utente e' da tenere in considerazione, e gia' contemplato per le futur(issim)e versioni di Hyppocampus

Al solito, nel bene e nel male Apple si rivela costante fonte di ispitazione (non a caso sono stati loro a concepire l'attuale paradigma del desktop e delle finestre...): auguro a Leopard di essere un grande successo commerciale, per intanto mi limito ad ammirare e a meditare...

0.2.3

Sono infine riuscito a rilasciare la versione 0.2.3 di Synapse e di Hyppocampus, nonche' la 0.4.2 di SCD (prima o poi faro' riallineare sti' numeri...): nonostante il ritardo rispetto alla classica roadmap (cerco sempre di distribuire nuove releases con cadenza quanto piu' mensile possibile), le nuove features proposte non sono moltissime, a causa anche della immensa quantita' di tempo che sto' impiegando nel progetto precedentemente annunciato.
Ho dovuto lasciare le modifiche in Kiazma (finalizzate all'implementazione dell'environmental mapping) un po' a meta', dunque l'aspetto di Synapse e' assai peggiorato (non ci sono piu' icone, solo rettangoli neri... D'oh!), ma l'importante e' sapere che questa e' solo una fase transitoria.
Mezzo implementato il meccanismo di plugging automatico, prima introduzione delle VIEWs in Hyppocampus (e' possibile "salvare" le queries ed esplorarle successivamente accedendo al nome assegnato), numerose sistemazioni nella modalita' "shell" dell'On-Mouse Shell (ora i files selezionati in Synapse sono listati in una variabile di ambiente nella consolle che si apre nel rettangolo di selezione)...
Le cose da fare sono ancora molte. Moltissime.

Mnemonics VS Staminal

Sono infine riuscito a pubblicare il tanto menzionato brano sulla manipolazione dei tipi di files in Hyppocampus, e, sebbene il testo sia assai limitato (ma presenti un bel mockup :-P ), illustra un poco meglio cosa si intende con gli appellativi "Staminal" e "Axiom" che compaiono nella pagina dei TODO di Lobotomy.
Quel che vorrei qui meglio approfondire e' la differenza che intercorre tra il concetto di mnemonic box, illustrato a suo tempo nell'apposito articolo e gia' in fase di implementazione da qualche mese, e Staminal; fondamentalmente si tratta di due modi diversi di scomporre (e ricomporre) un file che viene immesso nel filesystem, e di trattare le informazioni da esso ricavate.
La mnemonic box altro non e' che un file (uno ed uno solo, identificato da un nome ben specifico, ognuno dei quali gestito da un plugin) che, se consultato, attiva una procedura di recupero e formattazione dei dati in funzione del file stesso. Se, ad esempio, con un plugin gestisco il file std.vcf (che contiene le informazioni trattate solitamente con KAddressBook, di cui si e' gia' fatto cenno), tale plugin si occupera' di raccogliere i dati sui vari contatti sparpagliati nel filesystem e di formattarli appropriatamente al momento dell'apertura, e di riscomporli in unita' atomiche quando il file viene chiuso. Diciamo che questa applicazione di primitivo data mining e' orientata piu' alla compatibilita' con le applicazioni non direttamente sviluppate nel contesto del progetto Lobotomy, e rappresenta una prima forma di sperimentazione sul trattamento on-the-fly dei contenuti che transitano per Hyppocampus.
Staminal, di contro, non e' orientato ai singoli files ma al loro tipo: quel che si vorrebbe fare (e si fara', nel prossimo futuro) sara' tradurre ogni segmento di informazione creato in Hyppocampus in un formato universale ed unico, si' da poterlo poi facilmente tradurre in qualsiasi altra cosa.
Rimando alla lettura dei due articoli sopra linkati per maggiori informazioni sui due concetti, diversi ma in qualche modo correlati, e raccomando di seguire gli sviluppi di quella che, a parer mio, e' una tecnologia che potrebbe trasformare il modo in cui l'utente si relaziona coi propri dati.

Giustificazione di ritardo

Ultimamente ho lavorato poco, molto poco, su Lobotomy. O quantomeno, sul codice. Ma mi posso giustificare.
Innanzitutto, ho quasi pronto un simpatico articolino preannunciato (piu' volte) tempo addietro in merito all'astrazione dei tipi dei files manipolati da Hyppocampus e dalle applicazioni che per mezzo di esso operano, conto di pubblicarlo nel giro di poco. Al solito, man mano che lo scrivevo mi venivano nuove idee da aggiungere nelle gia' infinite todolists ;-P
Ma, soprattutto, in questo periodo sto giocando... al sistemista :-P
Nelle ultime settimane ho molto lavorato (ed ancora molto mi resta da lavorare) su BarberaWare, che nei prossimi giorni (spero) sara' annunciato ufficialmente ma di cui riporto qui in anteprima mondiale per i lettori del blog qualche cenno. Si tratta fondamentalmente di un "contenitore" destinato ad ospitare progetti free (as in speech) prodotti dagli sviluppatori indipendenti del territorio di Torino (di cui mi ritengo cittadino per adozione) e dintorni, un "SourceForge de' noiartri" che mira a valorizzare soprattutto i giovani che, nonostante gli impegni di tutti i giorni e la "mercificazione" del software libero, trovato ancora la passione e l'ispirazione (nonche' la capacita' tecnica) di arricchire il patrimonio comune di codice ed idee. Un sito non per la promozione del freesoftware, ma di chi il freesoftware lo fa.
Al momento raccomando tutti coloro che leggeranno questo brano nei giorni immediatamente successivi alla pubblicazione di limitarsi al piu' a sbirciare quel che si trova all'altro capo dell'URL sopra linkato, essendoci ancora numerosi elementi da sistemare e rifinire; provvedero' nel prossimo futuro a notificare il reale ingresso in scena della piattaforma.
Con ogni probabilita', io stesso "sfruttero'" i servizi offerti dal sito (e da me stesso configurati :-P ) per hostare qualche componente minore di Lobotomy (quelli listati al fondo della pagina dei TODO), ed avrete dunque modo di capitare nel vortice di BarberaWare.

Webmaster si nasce

Dietro suggerimento del buon HS1 (mio affezionato lettore, e potenziale prossimo developer del team di Lobotomy ;-P ) stasera gioco al webmaster, modificando il template del qui presente blog. Sinora ho usato uno degli schemi standard di Blogger, leggermente modificato, ma mi e' stato appunto segnalato che il testo chiaro su sfondo scuro risultava di difficile gestione per coloro (e sono tanti, me compreso) che saltano da una pagina all'altra nel browser e sono abituati ad un abbinamento inverso di colori. Non so pero' se cosi' sia meglio: gli accostamenti cromatici non sono mai stati il mio forte, spero di non aver creato ancor piu' danni di quanti gia' non ce ne fossero ;-P. Domani provvedero' magari anche a realizzare un loghino un po' piu' carino da piazzare in cima alla pagina...
Ultima nota, ben poco attinente: un paio di ore fa' ho avuto una (ennesima) ispirazione per un tool che si integrerebbe perfettamente con lo spirito di Lobotomy, e su cui mi prodighero' un giorno o l'altro. Spesso mi capita di avere qualche piccola illuminazione su utility e strumenti secondari che potrebbero essere inclusi nel progetto, presto o tardi dovro' dedicarvi una pagina sul sito principale...

Lobotomia a la carte

Lobotomy cresce. E, con esso, la difficolta' di eseguire la procedura di build dai sorgenti.
La prossima release di Hyppocampus avra' come dipendenza la libreria che verra' distribuita con SubConsciousDaemon (che contiene le funzioni per le notifiche di creazione e modifica dei files contenuti nel filesystem), la quale pero' dipende dalla libreria LibHyppo distribuita con Hyppocampus stesso. Questa si potrebbe definire una dipendenza ciclica, oppure (in modo piu' naive) una gran seccatura per coloro che vogliono compilarsi il sistema sulla propria macchina.
E nel prossimo futuro le parti potrebbero incastrarsi ancora di piu', data l'imminente (!) ripresa dei lavori su BrainTop.
Da qui, l'idea di adottare la stessa soluzione prevista dai teams di GNOME e di XFCE: una utility standalone che scarichi dall'Internet i diversi pacchetti di cui Lobotomy si compone, permetta di eseguire una sommaria configurazione, e li compili nel corretto ordine.
Con ogni probabilita' la prima versione di questo tool sara' esclusivamente destinata all'utilizzo da linea di comando, non esistendo al momento particolari configurazioni attuabili in fase di compilazione e data l'urgenza di uno strumento di tal fatta, ma prossimamente potrei dedicare un poco di tempo alla creazione di un wizard grafico che assista l'utente in questa delicata fase.
Non mi resta che trovare un nome adatto ed in tema per questo (ennesimo!) componente della famiglia Lobotomy ;-P

Tre dimensions is megl' che two!

Da qualche tempo vado meditando su un uso concreto del 3D sul desktop casalingo. Sorvolando sugli affascinanti ma ben poco pratici Compiz e compagnia cantante, credo che la possibilita' di disporre informazioni su tre anziche' due dimensioni possa solo potenziare l'ambiente grafico.
Giusto per fare un esempio: per il prossimo futuro avrei intenzione di abbozzare un RSS reader che disponga le news in una struttura tridimensionale "pesata" in funzione dell'importanza assegnata (secondo espressioni regolari) alle notizie disposte sui vertici, si' da poterne visualizzare un maggior numero nella stessa schermata ed incrementare le possibilita' di poggiare lo sguardo su qualcosa di interessante (essendo io iscritto ad una quindicina di feed, ben difficile mi e' leggere proprio tutto tutto, e non posso far altro che discriminare il materiale che puo' fare al caso mio scorrendo le voci alla ricerca di parole chiave).
Proprio oggi le mie velleita' di grafico 3D si son ravvivate scoprendo per caso VTK, ed ora ero alla ricerca di qualche applicazione che sfrutti GtkGLExt per sopperire alla mancanza di documentazione. Vedremo se nel prossimo futuro saltera' fuori qualcosa di interessante...

Parallelizzazione: Architettura Futura

Da due giorni, sul Web si propaga l'eco della notizia del rilascio di GCC 4.2, quello che probabilmente e' il compilatore C piu' usato ed apprezzato al mondo. Le nuove release di questa cruciale ed indispensabile applicazione sono sempre accompagnate da un notevole riscontro, ma questa volta in particolare una nuova feature or ora introdotta rende l'evento ancora piu' interessante: l'implementazione di OpenMP.
Che e' sta' roba? La spiegazione su Wikipedia e' abbastanza chiara, ma la riassumo qui: si tratta di uno standard, che si materializza in forma di librerie e (soprattutto) micro-istruzioni per il processore, che facilita estremamente la gestione della parallelizzazione all'interno del proprio codice. Ovviamente la piu' immediata (e piu' succulenta) applicazione di questa tecnologia sta nello sfruttamento dei processori multi-core, che attualmente sono quasi la norma per quanto riguarda il mercato dell'home computing.
La parallelizzazione e' destinata a divenire il prossimo modello di riferimento per lo sviluppo del software (quantomeno, quello destinato all'ambito desktop. In altri contesti e' cosi' gia' da tempo...), ed oserei aggiungere "era ora": sinora abbiamo avuto nelle nostre case computers estremamente potenti ma abili a svolgere un solo compito alla volta (molto velocemente, certamente, ma uno solo alla volta, avendo un solo processore ed un'unica unita' dedicata alla computazione), ed il fatto di avere piu' cores incrementa implicitamente le prestazioni della macchina (basti pensare a come venga drasticamente ridotto l'overhead dovuto al content switching) e, dal punto di vista operativo, permette alle applicazioni di svolgere piu' tasks nel medesimo istante. L'estrazione dei metadati dai files, ad esempio, o il data mining su di essi, o l'accelerazione delle procedure di formattazione e renderizzazione della grafica. Le possibilita' sono infinite, e personalmente vedro' di esplorarne il maggior numero nel contesto del progetto Lobotomy ;-P
Mi spiace assai non possedere una macchina multi-core su cui sperimentare, ma vedro' di provvedere a qualche test al piu' presto.

Trasloco

Basta! BerliOS fa schifo, e' lentissimo, o almeno e' lentissimo le rare volte che e' online! Gli strumenti fanno pena, il tracker fa pena, le statistiche fanno pena, lo sconsiglio fortissimamente a tutti coloro che hanno un pezzetto di software da rilasciare... Ho gia' avviato la procedura di registrazione di Synapse presso Savannah!
Le copie sinora rilasciate rimarranno nel repository originario, ma tra un mese o due vedro' di cancellare la pagina presso BerliOS: non vorrei mai occupargli risorse preziose, a quei fagnani!
Gia' che son qui, qualche news sul filemanager ufficiale del progetto Lobotomy: ho buttato l'ultima settimana per modificare la IconView inclusa in Kiazma, con l'idea di astrarre meglio le rappresentazioni dei files e wrapparle in widgets/contenitori dedicati anziche' spatarrare le informazioni nel GtkTreeModel usato originariamente dalla struttura, ma
1) sono troppo pigro per perfezionare il meccanismo, che allo stato corrente, dopo giorni, ancora lascia moltissimo a desiderare e, quando va bene, mostra rettangoli neri al posto delle icone
2) mi sono illuminato d'immenso scoprendo che avrei ottenuto lo stesso risultato con molto meno sforzo, mascherando le informazioni nel GtkTreeModel stesso e provvedendo ad una funzione di rendering composito delle icone

Sorvolando sulla mia scarsa lungimiranza: lo scopo finale di tutto questo lavoro e' quello di avere delle icone che vengono realizzate al volo, visualizzando le informazioni esplicitamente richieste dall'utente nella query di interrogazione al filesystem relazionale (nello statement di SELECT), e di poter nel prossimo futuro implementare la tecnologia di mappatura dell'ambiente grafico proposta qualche tempo fa'. C'e' ancora molto da fare...

Plugging Plugins

L'ultima sballata idea che giusto quest'oggi e' affiorata dalla mia mente rientra perfettamente entro gli scopi della serie 0.2.X di Lobotomy: l'espandibilita' dei componenti del progetto mediante plugins.
Cos'e' un plugin? Esso e' un file (un modulo, in C e' un oggetto linkabile dinamicamente esattamente come una libreria) che va piazzato nella cartella predefinita per l'applicazione che si vuole estendere; generalmente, all'avvio l'applicazione cerca in suddetta cartella, si linka ai moduli, e parte.
Perche' non permettere il link "a caldo" dei componenti esterni?
Due sono le soluzioni che al momento mi sovvengono (probabilmente ne esistono altre): inotify o DBus. La prima si concretizza con un file descriptor aperto sulla cartella dedicata ad ospitare appunto i plugins, il quale, grazie all'aiuto del kernel e una callback registrata sul mainloop di glib, permette di rilevare automaticamente la creazione di un nuovo file e la conseguente procedura di verifica/caricamento; la seconda con la presenza di un daemon presso cui le applicazioni si registrano e che, dato in ingresso un file, chiede a tutte (attraverso DBus) se il plugin avanzato e' di loro proprieta'.
Quest'ultima opzione e' quella che richiede maggiori risorse (e' per l'appunto un processo in esecuzione, un componente attivo del sistema) ma che garantisce la maggiore trasparenza per l'utente, il quale ha un'unica interfaccia per il caricamento di nuovi plugins e non ha da sapere dove piazzare il file sul filesystem. Teoricamente, sarebbe possibile aggiungere un nuovo plugin trascinando il link al file dal browser ad una icona nella traybar.
Prossimamente meditero' ancora sulle potenzialita' dell'idea, che spero di implementare al piu' presto onde permettere una facile e veloce estendibilita' dei vari componenti di Lobotomy.