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...

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.

Vapore Multitouch

Risale a qualche settimana fa' il meme del tablet targato Microsoft, chiamato Courier. Molti hanno detto la propria, io (sebbene con un poco di ritardo) dico la mia: secondo me, e' una bufala.
Le motivazioni di un gesto di tal fatta sono scontate: rosicchiare un poco della attenzione e della visibilita' offerte sull'argomento "tablet" a seguito dei reiterati rumors in merito ad un nuovo prodotto Apple, destinato (vuoi per tendenza modaiola, vuoi per effettivo grado innovativo tradizionalmente iniettato sul mercato dall'azienda di Cupertino) a ridare nuova vita ad un settore esistente da anni ma che non ha mai scalfito l'interesse del grande pubblico consumer.
Ma la mia affermazione non e' fondata solo sulla pura intuizione (oltretutto neanche tanto originale) e sul pregiudizio nei confronti di Microsoft, ma su riflessioni indotte dalla visione del video di introduzione al suddetto Courier. Osservando quei quattro minuti di filmato, spacciati per tech demo dell'imminente prodotto, a me sembra abbastanza evidente che il modello di interazione e' cosi' artefatto da non poter essere reale: comportamenti grafici diversi, ovviamente sempre i piu' adatti alla regia, si ottengono a seguito delle medesime operazioni dell'utente, ed il pannello giallo che ogni tanto appare (e non ho neanche capito a cosa serva...) sembra dotato di una propria coscienza tanto da apparire solo quando scenicamente opportuno. Per non parlare delle barre in cui si scrive a mano per raggiungere un dato contenuto (bella forza immettere l'URL "afi.com" nel browser, ma come ce lo faccio stare "slashdot.org"?), le tabelline che magicamente vengono estratte e trascinate senza manco sapere qual'e' la porzione di interesse per l'utente, il tratto dello stilo che diventa testo o evidenziatura gialla in modo totalmente arbitrario...
Insomma, piu' che un prototipo di interazione a me sembra un film di azione, in cui i cattivi sparano dozzine di proiettili senza mai neppure ferire i buoni e l'eroe fa di ogni colpo un centro: molto divertente da vedere, ma non credibile. Poi, per la carita', qualcosa di interessante lo si trova anche, come il concetto di piazzare i contenuti di traverso tra le due pagine per, all'atto pratico, metterlo in clipboard, ma cio' non toglie nulla alla mia incredulita' di vedere davvero questo arnese sugli scaffali nei prossimi mesi.
Al contrario, sono ben contento di vedere che una fascia di prodotti su cui da tempo ripongo la mia attenzione stia in qualche modo uscendo dalla nicchia in cui e' stata relegata per anni ed i grandi produttori nel bene e nel male procedano con sperimentazioni e ricerche: continuo a ritenere l'idea del tablet una direzione quasi obbligata per gli sviluppi tecnologici futuri, in virtu' del rapporto dati esposti / superficie ingombrante di cui tali dispositivi godono, e nella speranza di poter presto trovare un degno sostituto al mio Acer C310 (quattro anni fa' il miglior convertibile che ho trovato sulla piazza, e da allora rimasto tale a causa della scarsita' di alternative) continuo a seguire gli sviluppi.

Piastrelle Semantiche

Su questo blog e altrove ho piu' volte criticato le tecnologie semantiche. Ma forse sarebbe bene fare distinzione tra "semantico" e "semantico".

Non tutte le tecnologie etichettate con tale altisonante classificazione, cosi' di moda oggi e dunque cosi' abusata e di cui in fin dei conti in pochi (non me) hanno ben chiaro il significato, offrono infatti gli stessi vantaggi a fronte dello stesso impegno. Si va dall'estremo del "desktop semantico" - l'attuale KDE4, che implementa lo stack Nepomuk e che incentra buona parte delle sue funzionalita' intorno alla capacita' dell'utente di assegnare tags ai suoi propri files - all'opposto del "web semantico", ovvero la "Rete di dati" cui gia' qualcuno arditamente (o stupidamente) appunta la nomea di "Web 3.0". Mentre la prima categoria di applicazione e' lungi dal ricevere un mio consenso, soprattutto a questo stadio di sviluppo ed alla luce del fatto che esse sono completamente inutili se non manipolate a dovere dall'utilizzatore finale (che, per definizione, non usa mai le cose come dovrebbe), la seconda classe e' motivo di discreto interesse, almeno dal punto di vista del potenziale in campo. In generale non vedo troppo di buon occhio la frammentazione (seppur controllata e documentata) dell'informazione in dialetti e sottodialetti, come appunto si vuole fare con l'iniezione di una quantita' infinita di "ontologie" da applicare ad informazioni diverse a seconda del loro contesto, ma certamente se sufficientemente diffusi e propagati tali mezzi risulterebbero di infinita utilita'.

Purtroppo il grande difetto del "semantic web" e', paradossalmente, la sua stessa community di sostenitori, costituita in larga parte da accademici esaltati che amano riempirsi la bocca con nozioni di filosofia spiccia e produrre i piu' stravaganti ed incomprensibili formati e protocolli per il solo gusto di constatare poi quanto siano stati bravi nel far delle cose cosi' complesse, pertanto ho sempre osservato da lontano l'ambiente senza approfondire piu' del tanto necessario a comprendere il senso delle occasionali news che capitano sotto gli occhi. Ma qualcosa potrebbe forse cambiare nel prossimo futuro.
Tra le news di Techmeme trovo un riferimento all'intenzione del team di Twine (scarsamente conosciuto servizio di social bookmarking a la del.icio.us) di piazzare online un "editor di ontologie", ovvero una applicazione che faciliti la produzione, la pubblicazione e la condivisione di "descrizioni" di oggetti da impiegare poi per marcare i dati sull'Internet ed implementare poi all'interno dei programmi che potranno cosi' interpretare il dato e miscelarlo e/o presentarlo in modi nuovi. Sinora la tecnologia (o quantomeno: la discussione di essa, e qualche basilare applicazione) e' stata confinata nelle aule accademiche o sui blog tecnofili da geek, dunque impiegata al piu' in nicchie ben lontane dal mondo dei comuni mortali, ma se davvero si riuscisse a coinvolgere individui non-tecnici nella definizione di nuove astrazioni semantiche pronte per essere adottate in campi di pubblico interesse e fruizione sarebbe forse la volta buona per radicare lo strumento ed iniziare davvero a sfruttarlo.
Io stesso qualche tempo addietro stavo meditando sull'utilita' che avrebbe un web service esposto da GTT (l'azienda di trasporto pubblico torinese; ovviamente il discorso si applica anche a tutte le altre citta') per reperire in un formato programmaticamente trattabile le informazioni relative al traffico urbano, che al momento sono completamente raccolte e gestite dall'ente ma divulgate per mezzo di canali scarsamente riconducibili a qualsiasi forma riutilizzabile, ma dopo rapida ricerca ho notato la mancanza di una specifica adeguata a tale esigenza e che potesse realmente essere definita standard. Di casi simili ne esistono a volonta' e Swoogle non e' di particolare aiuto, ma cosi' come Wikipedia e' la piu' grande enciclopedia del mondo grazie anche e soprattutto al contributo di persone specializzate in settori non necessariamente legati alla tecnologia che hanno imparato quelle poche operazioni richieste per editare il wiki e riportare la loro conoscenza, allo stesso modo puo' esistere la possibilita' di far convergere nozioni ed esperienze diverse per costruire il substrato di interoperabilita' necessario ed indispensabile ad ogni altro futuro sviluppo del web semantico.

Un Futuro che Non C'e'

L'altro giorno mi e' passato sotto gli occhi un bellissimo filmato che, strano a dirsi, viene da Microsoft: esso rappresenta la "vision" dell'azienda per l'adozione massiccia di tecnologie oggi esistenti solo in forma prototipale e sperimentale, e piu' precisamente in previsione di cio' che gli utenti potrebbero avere a disposizione nel 2019. Superfici tattili di ogni tipo, interfacce completamente touch che mutano a seconda del dato presentato o del device su cui vengono impiegate, carta elettronica su cui viene proiettata l'informazione...
Certamente affascinante. Un ottimo cortometraggio di fantascienza.
Con cio' non voglio assolutamente dire che quanto espresso sia irrealistico ed infondato, anzi ho precisato fin dall'inizio che in fin dei conti questa non e' che una artistica raffigurazione di strumenti hardware e software gia' oggi esistenti ed in fase di piu' o meno avanzato sviluppo, ma tra il dire (non senza un pizzico di ingenuita', perdonata per le evidenti esigenze di copione) ed il fare vi e' il baratro dell'interpretazione dell'informazione.
Splendido sarebbe copiare una porzione di un grafico da un device all'altro semplicemente puntando e guardando attraverso l'apposito vetrino, ma per far cio' i tre componenti (mittente, destinazione, e chi trasporta il dato) devono comunicare nello stesso linguaggio, secondo lo stesso protocollo, scambiando bytes di cui conoscono il significato; impagabile sarebbe variare l'informazione numerica in un documento tabellare girando la manopolina virtuale proiettata sulla scrivania, ma per fare cio' chi proietta suddetta manopola e chi traduce il numero prodotto in barretta colorata devono condividere la nozione su come trattare l'input; meraviglioso sarebbe "esplodere" il disegno tecnico pigiando il ditino sulla scrivania su cui e' appoggiato il mazzo di chiavi, ma per far cio' la scrivania deve sapere cosa c'e' scritto nel suddetto schema ed in che modo i componenti rappresentati sono interagibili o meno.
Insomma: il semplice "pezzo di ferro", per quanto sofisticato, semi-trasparente, mobile e reattivo al tocco, non serve a nulla se chi lo gestisce non sa cosa fargli visualizzare, e come. Questo popo' di apparecchiature e' perfettamente inutile se non esiste una capillare ed universale adozione di standard aperti, che possano essere trattati in modo univoco all'interno dell'intera infrastruttura integrata. Che lo si voglia o no, finche' l'informazione e' tenuta prigioniera all'interno di files Office, o Photoshop, o AutoCAD, solo Office, Photoshop ed AutoCAD potranno accedervi. Non il vetrino da puntare, non la manopolina proiettata, non la scrivania.
E il problema non e' certo rimandabile al 2019, ma va affrontato subito, per il semplicissimo fatto che prima di arrivare allo scenario dipinto nel filmato in oggetto sara' necessaria una graduale migrazione dalle tecnologie odierne a quelle prossime venture: e' chiaro che coloro che inizieranno a commercializzare i singoli prodotti che compongono il puzzle dovranno avere la possibilita' in prima istanza di interagire in qualche modo con l'informazione esistente e farsi strada poco alla volta nella vita di tutti i giorni, sia essa quella casalinga o produttiva, ma fintantoche' tale informazione non e' accessibile e manipolabile all'interno di tali nuove interfacce le possibilita' di concretizzazione entro tempi umanamente accettabili sono estremamente scarse.
Dunque: se il video vi e' piaciuto, e non vedete l'ora di utilizzare quotidianamente strumenti di tal fatta, assicuratevi di lasciare campo aperto all'innovazione ed alla penetrazione di tali tecnologie. Pensateci due volte prima di bloccare la vostra informazione (o peggio ancora, l'informazione da condividere con altri) all'interno di files chiusi e non interoperabili.
Partecipate alla costruzione di un futuro che non c'e', ma con il buon senso di tutti potra' essere.

Un Castello tra le Nuvole

Da qualche tempo mi son reso conto di essere talvolta un po' troppo influenzabile dalle tendenze (anzi, chiamiamole pure "mode") tecnologiche, ed ora, dopo aver immaginato una interfaccia web based per Lobotomy quando la parola "ajax" veniva menzionata in ogni articolo di blogs ed aggregatori, il mio inconscio geek sta valutando le potenzialita' di quello che e' chiamato "cloud computing".
Non e' nuova l'idea di integrare all'interno del futuro (futurissimo...) Lobotomy strumenti per la distribuzione del calcolo necessario per l'estrazione automatica dei metadati ed altri task con forti richieste computazionali, ma nuove porte si aprono se si gettano nel calderone anche le possibilita' della distribuzione dello storage.
Espandendo il filesystem e e copiando (e ridondando) i files su piu' macchine, all'interno della propria LAN domestica o appunto nella Cloud, in un colpo solo si ottiene il duplice risultato di condividere i contenuti affinche' siano fruibili su piu' devices (il desktop di casa, il portatile, il MID...) e di mantenerne copie di sicurezza da sfoggiare in caso di catastrofe - evento neppure cosi' sporadico data la sempre maggiormente scarsa qualita' dei componenti hardware - mentre applicando lo stesso concetto direttamente al database responsabile di indicizzare i metadati che descrivono ogni elemento si riuscirebbe ad esportare le proprieta' tipiche di Lobotomy anche laddove non sarebbe altrimenti possibile: sugli apparati mobili, che non sarebbero in grado di contenere fisicamente (e dunque usare) tale immensa mole di informazioni, e sul web, al fine di condividere i dati tra piu' utenti (i propri amici e conoscenti, ma anche tutto il resto del mondo).
Proprio con questo secondo obiettivo ho iniziato a documentarmi un pochino su HBase, Hypertable e prodotti analoghi: certamente e' molto presto per mettersi a progettare un sistema cosi' complesso, ma e' bene comunque valutare a priori questa direzione per poterla successivamente integrare nel modo piu' pulito e rapido possibile a tempo debito.

Touch Me

Periodo assai magro per lo sviluppo di Lobotomy, essendo io estremamente impegnato su un numero infinito di fronti ed impiegando ogni momento libero per portare avanti una applicazione web commerciale che mi e' stata commissionata (sviluppata per mia volonta' con GWT, al fine di acquisire maggiore dimestichezza con tale strumento e riusare l'esperienza accumulata al servizio del freesoftware).
Ma riuscendo finalmente ad intravedere una luce in fondo al tunnel, e pregustando il giorno in cui potro' tornare a dedicarmi integralmente al mio amato progetto, nel substrato cognitivo di background sono tornato a meditare a funzionalita' e perfezionamenti da apportare. Primo tra tutti (oltre chiaramente all'implementazione del nuovo Synapse in forma di interprete per i templates delle applicazioni interne al desktop environment) lo sfruttamento dei dispotivi di puntamento touchscreen.
Sembra proprio che il mondo abbia finalmente scoperto l'esistenza dei touchscreen (devo considerarmi un precursore, avendo investito gia' tre anni addietro nell'acquisto di un tablet?), e le tecnologie desktop molto puntano su tali apparati: si puo' facilmente prevedere l'uscita di una nuova schiera di tablet PC a partire dal prossimo anno, con l'avvento di Windows7 (di cui l'unica cosa che e' stata mostrata sinora e' appunto il supporto al multitouch), e gia' oggi i piu' moderni laptop targati Apple supportano gestures sul touchpad.
Proprio a proposito dell'uso del comune touchpad presente su ogni portatile in commercio (non solo quelli Mac), ho scoperto che gia' molti di essi sono in grado di identificare il tocco di piu' dita contemporaneamente: stando a questo illuminante articolo le proprieta' di tali device non sono particolarmente precise ed avanzate, ma con un poco di fantasia qualcosa si potrebbe comunque cavare: allo stadio attuale tali funzionalita' sono totalmente inutilizzate (ed ai piu' sconosciute), ed il mio personale obiettivo e' quello di provare ad implementare una sorta di piccola libreria standalone per Linux che faciliti la definizione di gestures elementari da riusare poi nel contesto di Lobotomy.
Chissa' che non riesca a rilasciare qualcosa profittando del tradizionalmente prolifico periodo estivo...

Quattro chiacchere su ItsMe

Da taaanto tempo non aggiorno codesto mio blog, ma tra il lavoro regolare e le altre attivita' non solo non trovo tempo di commentare qui le ultime news a tema ma neppure riesco a meditare piu' approfonditamente sul Progetto Lobotomy.
Sta di fatto che qualche giorno addietro son riuscito a fare un salto a Milano presso l'Universita' Bicocca per scambiare quattro chiacchere con il prof. De Michelis, fautore del progetto ItsMe di cui ho gia' fatto cenno in passato; ebbene, devo dire di aver solo adesso compreso in cosa consiste l'attuale sviluppo del progetto, e tra qualche perplessita' ma anche molta curiosita' lo reputo quantomeno interessante.
Sostanzialmente, diversamente da quanto immaginavo, al momento i ragazzi della neonata azienda meneghina stanno implementando una sorta di layer di astrazione del filesystem che si occupa di filtrare i contenuti scritti e letti operando qualche piccola opera di organizzazione degli stessi in funzione dell'attivita' dell'utente, che di volta in volta si trova a lavorare in un workspace dedicato ad un suo particolare task. Operando al livello del filesystem il sistema puo' essere usato con i normali applicativi software cui tutti siamo abituati, anche se "inconsapevoli" della struttura ponderata che ci sta sotto, e, almeno in questa fase dell'implementazione, non sono previste bizzarre interfacce grafiche o modelli di disposizione degli elementi sullo schermo, se non forse una sorta di "desktop esteso" che permetta di navigare i dati appunto secondo la nuova organizzazione non gerarchica.
Mi ha (piacevolmente) stupito il forte peso che si vuole dare alle interazioni "sociali" dell'utente, al pesante utilizzo delle mail come criterio di discriminazione tra i contenuti per la manipolazione: dall'analisi off-line delle comunicazioni fatte tra persone diverse si vuole fare in modo di "intuire" i nuovi task che ci si trova ad affrontare o le interazioni con essi, in modo da suggerire a chi si trova dinnanzi al monitor correzioni e perfezionamenti al modello.
Forse a questo punto sarebbe d'uopo un confronto tra questa opera ed il Progetto Lobotomy, ma credo che un diretto accostamento sia impossibile: i due lavori partono da presupposti molto diversi tra loro e fungono in maniera quasi opposta (ma non totalmente), mentre ItsMe punta ad un "caos ordinato" tagliato a misura dell'utente che lo usa (e che dunque fallisce se l'utente non segue certe regole) il mio progetto verte sull'immediata richiesta e necessita' (e dunque fallisce sul lungo termine non avendo una visione di insieme); ad ogni modo, loro arriveranno certamente prima di me ad avere qualcosa di usabile, dunque il problema non si pone...
Non ho ben capito a quale grado di sviluppo siano gia' giunti gli sviluppatori di ItsMe, ma mi e' stato riferito che entro non troppo tempo (subito dopo l'estate?) potrebbe essere disponibile online un simulatore atto a far toccare con mano la tecnologia e le implicazioni di un manager automatico per le informazioni: per intanto mi frego le mani in vista di metterci le mani sopra, si' da diventar membro della community e collaborare quantomeno in veste di tester, e vedro' di tenermi aggiornato in merito alle prossime news a riguardo.

Scritture (molto) asincrone

Ho appena aggiunto nella lista dei TODO per il progetto Hyppocampus la menzione al prossimo sistema di schedulazione delle scritture che vorrei implementare per supportare l'API di salvataggio "discreto".
Non ricordo se ne ho gia' fatto cenno qui, ma un riassuntino non guasta mai: l'idea e' quella di fornire in LibHyppo un set di funzioni che permettano di aggiungere ed eliminare dati pure nel mezzo di un file esistente, in modo da poter poi includere in Kiazma tutto il necessario per eseguire sempre e comunque salvataggi automatici a bassa latenza (nell'ordine di secondi) dei contenuti editati dall'utente all'interno dei widgets.
Il problema sta ovviamente nel fatto che le operazioni di scrittura nel mezzo di un file implicano lo spostamento sequenziale di tutti i blocchi che seguono, e sarebbe assai poco conveniente procedere con la riscrittura completa ad ogni byte cambiato; introducendo in Hyppocampus una sorta di coda di richieste, che scheduli i dati e le posizioni in cui vanno scritti, si dovrebbe riuscire a raggruppare ed ordinare tali dati ed eseguire accessi al disco un po' piu' consistenti ed efficaci, si' da sfruttare l'operazione di memorizzazione effettiva su ROM per far transitare piu' materiale in una volta sola.
L'effetto di tutto cio' sarebbe la disponibilita' di un sistema di salvataggio automatico in tempo reale, per cui ogni modifica ai contenuti viene mantenuta senza esplicita richiesta da parte dell'operatore: niente piu' pulsanti "Salva" o "Salva con nome", solo un costante salvataggio.
Maggiori dettagli a seguire.

Modularizzare Kiazma?

Da qualche giorno galleggiava nella mia testa l'idea, e per coincidenza giusto pochi minuti fa' ho scoperto che forse la cosa si puo' fare senza particolare sforzo.
L'idea consiste nel permettere l'estendibilita' di Kiazma con moduli esterni: definendo a priori una interfaccia cui devono aderire i widgets rappresentanti ad esempio un result set sarebbe possibile implementare un proprio elemento grafico e piazzarlo in un plug-in, da linkare a runtime a Synapse ed usare quando direttamente menzionato da un viewer. In questo modo sarebbe facile ad esempio costruire un widget che rappresenti un result set come una struttura tridimensionale, o che evidenzi le relazioni di un certo tipo tra gli elementi coinvolti, o in forma di acquario in cui gli items galleggiano (e' solo un esempio, se qualcuno si azzarda a fare una porcata simile gli mozzo le gambe...), ed arricchire le applicazioni costruite per Lobotomy.
Ebbene: trovandomi per non so piu' quale ragione sul sito di GTK ho trovato un breve tutorial su come usare GTypeModule per gestire per l'appunto GTypes dinamici usando l'astrazione dei GModules (inclusa in Glib). Come parte integrante del documento viene fornito anche un simpatico esempio di cui devo ancora esplorare attentamente il codice, ma che in linea di massima sembra fatto apposta per venire incontro alla mia necessita'.
Devo ancora meditare sulle solite implicazioni "tecniche" che si aprirebbero offrendo questa possibilita' agli sviluppatori esterni (come gia' detto tante volte: meno liberta' viene garantita, piu' coerente e' il sistema nel suo complesso), ma e' una idea che andra' analizzata in futuro.

Un Toolkit in 47 Righe

Questa sera, dopo lunghe e difficili elucubrazioni, sono riuscito ad ottenere un risultato per lo schema XML di cui vado parlando da qualche giorno (e non solo): un DTD di 47 righe, che include quasi tutto quello di cui ci sara' bisogno per definire "applicazioni" nel prossimo Lobotomy.
Manca ancora la definizione di un micro linguaggio di scripting che permetta di aggiungere controlli condizionali e fare qualche minima trasformazione al volo sui contenuti, e chiaramente la lista di funzionalita' che sara' possibile invocare dalla "viewer" verso la componente "controller" del nuovo sistema (ovvero: alla serie di daemons che dovrebbero girare indipendentemente dall'interfaccia grafica), ma almeno gli elementi di formattazione ci sono.
Come e' possibile formalizzare un toolkit in 16 tags e qualche attributo XML? La risposta e' semplice: la stragrande maggioranza delle rappresentazioni e' implicito. Sapendo a priori come trattare un certo metadato (in funzione del suo tipo, definito nella lista in LibHyppo: stringa, numero, o booleano che sia) non c'e' necessita' di esporre ad alto livello text entries, checkboxes o altro; c'e' bisogno solo dell'identificativo univoco di tale metadato. E un riferimento al file da cui tale valore si vuole prelevare.
Ora vorrei scrivere il solito paper informale di presentazione del primissimo draft (che sara' di certo pesantemente rielaborato prossimamente) per meglio illustrare i principi su cui si fonda il tutto, e preannuncio che ho gia' definito un prototipo di client di posta in un paio di files XML da 50 righe l'uno da usare come esempio.

L'Imbuto

Si sa che maggiore e' l'integrazione software che si vuole raggiungere piu' ricca e flessibile deve essere l'API di riferimento, che deve considerare quanti piu' casi possibile in modo da unificare il comportamento delle applicazioni e convogliare l'informazione in un numero limitato di punti cruciali per poterla smistare e manipolare facilmente.
Sempre nell'ottica di tagliare al massimo lo schema XML per le "view" che dovranno essere rappresentate in Synapse, e lasciare all'interprete (o meglio, al compilatore: sto accarezzando l'idea di compilare i templates descritti, per ovvi motivi di efficienza...), ho buttato un occhio alla lista di idee e propositi per funzionalita' da includere prima o poi direttamente nel framework (se non addirittura nei reconditi meandri del sistema, ad uso implicito per tutti) e mi sono accorto di avere in passato gia' pensato ad alcune cosucce che torneranno utili.
Riporto qui copia di tale lista, commentando gli elementi che maggiormente necessitano di delucidazioni, con la speranza di ottenere un poco di feedback sulla bonta' dell'API e su eventuali side effects non precedentemente previsti.

• scritture a blocchi mirate. Questo sarebbe da includere in qualche modo nell'interfaccia verso Hyppocampus (ovvero: girando attorno all'attuale interfaccia POSIX che passa per il VFS del kernel), e servirebbe a facilitare ed accelerare la scrittura su supporto permanente di ogni modifica apportata dall'utente a qualunque metadato e soprattutto ai contenuti dei files, si' da eliminare completamente il concetto di "salvataggio" esplicito. Le scritture dovrebbero avvenire ad ogni singolo cambiamento apportato (al piu' schedulando temporaneamente i contenuti e ripetere il ciclo solo ogni N millisecondi), ma il problema sta' nella necessita' di esprimere la posizione assoluta della modifica (ad esempio, se correggo il testo nel mezzo di un file) senza spostare gli altri contenuti che vi stanno attorno (si ricorda che l'interfaccia POSIX nasconde il partizionamento dei files in blocchi e fa apparire il tutto contiguo: se si aggiungono N bytes, gli altri vengono shiftati e dunque riscritti...)
• attivazione dei processi batch quando il PC e' in idle. Chiaramente questo meccanismo dovrebbe permettere di sfruttare il clock inutilizzato della macchina per procedimenti impliciti (ad esempio l'estrazione automatica dei metadati, o magari anche il fetching della posta e dei feeds RSS), e dovrebbe essere tarato per bilanciarsi autonomamente entro intervalli di tempo brevi: insomma, va bene fare questo genere di operazioni quando ad esempio parte il salvaschermo (come fa Seti@Home), ma personalmente credo che questo sia un approccio molto rudimentale al problema...
• Staminal. Su questo mi sono gia' espresso in un paper apposito
• estrazione dei metadati in funzione del contesto ambientale. Largamente ispirato dal gia' menzionato splendido articolo "Magic Ink", ritengo sia una idea potenzialmente buona quella di categorizzare (= popolare di metadati mirati) i contenuti in funzione del luogo, del tempo e, piu' in generale, del contesto in cui sono creati e manipolati. Sarebbe necessario ponderare sulle euristiche da adottare

Ci sarebbe forse altro da segnalare ma per ora mi fermo qui, anche perche' e' venuto tardi e tra l'inizio e la fine di questo post ho mandato una mezza dozzina di mail.
Di materiale su cui concentrarsi ce n'e' a iosa. Tutto sta nel trovare il tempo...

Deja vu: il paper

Ho or ora finito e pubblicato un documento che mira a descrivere meglio l'idea della taskbar cronologica, presentata qui qualche tempo fa'.
Piu' ci penso e piu' il concetto mi garba, credo che lo terro' nel cassetto per un po' prima di arrivare al (lontano, lontanissimo...) momento in cui potro' implementarlo in Synapse.

Per la cronaca: in questi giorni, nonostante i diversi impegni collaterali, mi sto occasionalmente concentrando sul modello da adottare per la gestione della componente "viewer" del sistema che si intende costruire nel prossimo desktop manager / ex file manager Synapse, ed al momento sono particolarmente orientato per l'implementazione di un interprete di "views" espresse in XSLT cui sottoporre i result set estratti da Hyppocampus in XML. Come gia' parzialmente anticipato vedro' di creare una sorta di descrizione JSON dei widgets che andro' a ricostruire in Kiazma, si' da sfruttare almeno un po' la gia' esistente interfaccia ClutterScript e risparmiarmi un po' di lavoro, e dovro' inventarmi una formalizzazione per l'invocazione delle API di sistema rivolte al "controller" dal template XSLT.
In poche parole: non aspettatevi una imminente release...

Everything is Unix

Nonostante il mio proposito dell'altro giorno, non essendo riuscito a scaricar... ehm... acquistare regolarmente una licenza di Mac 8, sono passato direttamente all'installazione di Darwin sull'iMac G3 che mi e' capitato tra le mani. (Nota per i lettori occasionali: la maledetta immagine .cdr per PPC che si scarica dal sito si masterizza molto banalmente con il comando cdrecord nome_file.cdr, alla faccia di K3B ed analoghi che si rifiutano di trattare questo formato...).
Sono molto curioso di testare con mano se la ricca documentazione pubblicata sul sito di riferimento fa fronte ad una API effettivamente completa come quella promessa o se e' tutto fumo e niente arrosto...
Mentre la procedura di installazione prosegue, leggo un articoletto sulla seconda development release del Project Indiana, il progetto volto a rendere piu' user-friendly il notoriamente ostico e serioso Solaris: pare che, un poco alla volta, in Sun stiano cavando qualcosa di effettivamente usabile pure da comuni utenti desktop, e sebbene al momento il sistema non goda di una popolarita' neppur paragonabile a quella di Linux, di cui pretende di essere un rivale, c'e' da credere che, essendo esso supportato e spinto da un colosso che ha fatto e fa a tutt'oggi la storia dell'informatica e guida una torma di sviluppatori assai nutrita (del resto, sono sempre loro che lavorano su Java, OpenOffice e diversi altri pilastri), diverra' discretamente utilizzato da qui a qualche anno.
Cosa viene da pensare mentre si legge da una parte cotanto brano e dall'altra si installa la componente free del sistema operativo piu' innovativo della storia? Non voglio avanzare conclusioni, ma dal canto mio credo che prossimamente saro' un poco piu' attento alla portabilita' del mio codice ed all'aderenza alla specifica POSIX: con tanta carne al fuoco le possibilita' (e le alternative) sono tante, e tutte valide, meglio non focalizzare l'attenzione su un'unica piattaforma ma spaziare per quanto possibile.
In ogni caso, tutti e tre i sistemi menzionati in questo post sono piu' o meno derivati da Unix, ovvero *IL* sistema di ieri, di oggi, ed evidentemente di domani.

Deja vu

Da parecchio tempo un processo in background nella mia mente elaborava il seguente quesito: "Nella futura interfaccia di Lobotomy come potra' l'utente gestire piu' applicazioni insieme?". Ieri sera, poco prima di addormentarmi, una possibile risposta. Assai inattesa.
La versione breve e' "Non lo potra' fare": nella sintesi e' corretta, ma fuorviante... Indi vediamo di fare ordine.

Riferimento: oggi, in un qualunque desktop environment, le diverse applicazioni aperte sono contenute dal window manager ed "indicizzate" per mezzo della taskbar, la classica barra che risiede lungo uno dei margini dello schermo (solitamente in basso) ed ospita un pulsantino per ogni finestra. Clicco sul pulsantino, e la relativa finestra del programma viene portata in primo piano. In questo modo posso avere piu' applicazioni aperte e saltare da una all'altra comodamente, accedere ad esse anche quando la loro finestra e' sovrapposta da altre, ed avere sempre sott'occhio l'insieme.

Osservazione 1: come gia' piu' volte detto, uno dei propositi per le prossime evoluzione di Lobotomy e' l'astrazione delle applicazioni (*tutte* le applicazioni) in quanto "modalita'" di visualizzazione ed interazione con un dato item preso dal filesystem o su un result set. Ogni modalita' (view) descrive come tale elemento o gruppo di elementi (model) debba essere rappresentato ed ordinato sul monitor basandosi sulle proprieta' comuni di tutti gli elementi (controller), e quali operazioni possono essere su di esso intraprese. In questa ottica ogni lavoro dell'utente e' formalizzabile in modo elementare secondo lo schema
result set + eventuale item nel result set attivo + modalita' di visualizzazione
Se sto manipolando il sorgente di Hyppocampus avro'
tutti i files .c nel gruppo 'Hyppocampus' + solver.c + editor di testo
Se sto leggendo i feed RSS
tutti i feed RSS ordinati per data + (nessuno) + feed reader

Osservazione 2: meditiamo sulle azioni che comunemente compie l'utente davanti al PC. Con quante applicazioni egli interagisce contemporaneamente? Una. E quando ha finito con essa, che fa? Mediamente torna su una di quelle con cui ha operato piu' di recente.
Il player audio si apre all'avvio del PC e lo si lascia in esecuzione da una parte, idem dicasi per il client di instant messaging, nel mio caso abbandono pure il calendar, basket, e spesso la moltitudine di applicativi (editor di testo col codice su cui lavoro, browser aperto sulle pagine di documentazione, console, filemanager...) che lascio salvati nella sessione trattata dal session manager essendo troppo pigro per riaprirli ogni volta. Quante finestre rimangono? Un numero compreso tra tre e dieci. A che mi serve averle tutte a portata, se non le uso? Ben poco...

Osservazione 1 + osservazione 2: se io posso risalire a qualunque condizione di utilizzo da parte dell'utente con un insieme ridotto di informazioni, ed osservato che l'utente ha un, passatemi il termine, working set limitato a cio' che ha fatto nell'ultimo periodo di tempo, posso mettere insieme le due cose? Se si, come?

L'idea e' quella di una sorta di pannello per mezzo del quale accedere alle ultime azioni intraprese, in ordine cronologico, chiuse quando vengono abbandonate e ricostruite ad ogni nuovo ingresso. Possiamo chiamarla "taskbar temporale". Io preferisco chiamarlo piu' romanticamente "deja vu".
A questo punto, l'utente non salta piu' tra una applicazione e l'altra ma naviga (come in un browser...) attraverso le sue proprie operazioni: sta editando del codice (condizione 1), non ricorda i parametri da passare ad una syscall, ricerca la pagina di manuale che la descrive e la apre nel terminale (chiudendo la condizione 1 ed aprendo la condizione 2), legge, e torna indietro all'editor (ovvero, viene chiusa la condizione 2 e ricostruita la gia' esistente condizione 1).
Questa impostazione e' assai piu' vicina a quello che ai fatti e' il modo di operare comune, prendendo come riferimento quel che fa chi si trova dinnanzi al monitor piuttosto che l'innaturale astrazione delle singole applicazioni e delle singole finestre.

Mi rendo conto che, cosi' spiegata, la cosa poco si comprende e possa pure apparire astrusa, ma io sono molto soddisfatto di questa illuminazione. Faro' in modo di descrivere il meccanismo nel classico documentuccio informale, aiutandomi con qualche mockup.
Ulteriori delucidazioni ed elucubrazioni a seguire...

LSQL?

Gia' avevo avuto in passato questa sensazione, ma stasera essa si e' fortemente rafforzata: il SQL non mi basta.
Sto scrivendo la routine che verifica se un item sul filesystem Hyppocampus rientra o meno nel result set specificato da una query, permettendo dunque un controllo senza obbligatoriamente andare a consultare il database (che altrimenti sarebbe interrogato da tutti i processi che fanno uso degli observers ogni volta che un metadato viene creato, rimosso o modificato) e mi rendo conto che, allo stato attuale, alcune particolari interrogazioni non sono possibili.
Non e' possibile confrontare due metadati per lo stesso item (data ultima modifica = data creazione + N), malamente sono trattati i metadati con valori multipli (quando ne testo uno confronto tutti i valori assunti o basta che uno solo soddisfi la condizione?), nessun controllo a priori viene fatto sul tipo di metadato e sul valore con cui viene confrontato...
Per la prossima release di Hyppocampus (non in questa, la 0.3rc2, che e' gia' sufficientemente in ritardo) vedro' di fare mente locale sulla situazione, e credo che finiro' a definire un mio proprio dialetto SQL con qualche operatore in piu' rispetto a quello tradizionale; gia' adesso alcune interrogazioni non sono possibili a causa della natura della base dati (non esiste DISTINCT, non sono selezionabili funzioni di aggregazione nella query primaria...), ma forse sarebbe opportuno porre dei paletti ben fissati e documentati sulle modalita' di ricerca.
Gia' oggi il parser che verifica e trasforma le query ha numerose lacune (gestito poveramente e' ad esempio l'operatore IN), provvedero' a ritoccarlo prossimamente e, soprattutto, a pubblicare una ricca specifica di riferimento.

XML vs JSON

Nello scorso post ho fatto cenno alla possibilita' di non usare XML e XSLT per descrivere le applicazioni che dovranno essere (meglio usare il condizionale: "dovrebbero forse essere un giorno") integrate in Lobotomy, ma qualcos'altro.
Cosa?
Da un paio di versioni Clutter, quello che al momento e' il toolkit candidato per essere usato per l'implementazione della componente grafica del sistema, include una sorta di interprete JSON: dando in pasto ad un oggetto di tipo ClutterScriptable la descrizione di una scena formalizzata in tale linguaggio gli elementi vengono trattati e visualizzati, pure applicando effetti e cose graziose. Sembra proprio quel che ci vuole per l'"interprete" di programmi in Lobotomy ;-).
Il punto e' che la descrizione JSON e' statica, non prevede variabili come ad esempio il set di items estratti dal filesystem cui applicare l'effetto, ed urge trovare un compromesso tra la precedente proposta (result sets in XML e trasformazioni XSLT) con i nuovi orizzonti aperti da codesto strumento gia' bello che pronto.
La soluzione forse piu' ovvia e' quella di usare comunque XML e XSLT, ma per produrre un JSON da convogliare direttamente in Clutter ed ottenere l'elaborazione e la renderizzazione. Al momento mi sfugge come potra' essere possibile intervenire sulla "scena" astratta (e mascherata) dal ClutterScriptable per effettuare al volo i ritocchi dovuti a variazioni del result set rappresentato (la faccenda degli observers, gia' trattata), dunque esistono ancora margini di ripensamento e/o miglioramento.
Mi sa che alla fine l'interprete me lo devo scrivere da me...

Pipelines Grafiche

Leggendo questo articolo, e piu' in particolare il punto 7 della lista (che recita "Unless interface designers manage to offer the same functionality as the command line, that's not going to change -- and, frankly, not many are trying to do so."), mi torna in mente un vecchio proposito, diciamo "figlio" della gia' antica idea dell'OnMouseShell che si prevede per la componente applicativa di Lobotomy: riprodurre la funzionalita' della pipe (il carattere '|') caratteristica della shell Unix nell'interfaccia grafica.
Tutti sappiamo che la pipe nella linea di comando serve a usare l'output di un programma come input di un'altro, concatenando dunque piu' comandi in uno solo. Come interpretare questa funzione in un ambiente grafico, ove non esiste un output vero e proprio di un programma se non quello che viene disegnato nella sua finestra?
Per comprenderlo occorre fare un passo indietro, andando a ripescare il concetto per cui le applicazioni proprie del desktop environment Lobotomy non dovrebbero essere altro che trasformazioni di un result set estratto dal filesystem Hyppocampus; nel documento sopra linkato si parla di risultati in XML e programmi in XSLT, ultimamente sto un pochino rivalutando il formato da usare (e prossimamente esprimero' qui le mie elucubrazioni) ma la sostanza rimane la stessa. Se dunque riduciamo gli applicativi utente a manipolazioni di dati di formato universale e compatibili tra loro (o comunque artificiosamente resi compatibili), le cose si fanno un poco piu' strutturate: in questo contesto, la pipe dovrebbe permettere di presentare gli stessi dati in modalita' diverse, secondo schemi diversi, lasciandone invariate le proprieta'.
Facciamo il classico esempio chiarificatore: l'utente consulta la posta elettronica usando l'applicazione rivolta alla consultazione della posta elettronica (ovvero quella che dispone gli elementi a video con una lista di messaggi, lo spazio per la preview ed i pulsanti per comporre una nuova mail) cui viene passato l'insieme degli items presenti sul filesystem marcati come messaggi di posta. Poi pigia una shortcut (che potrebbe pure essere Win+Ctrl+\ , ovvero Win+| , cosi' si sfrutta pure quel che sarebbe altrimenti un tasto inutilizzato della tastiera...) e seleziona un'altra applicazione, ad esempio quella che funge da calendar, ed ecco che quegli stessi dati vengono presentati divisi per giorno di ricezione nella consueta griglia da calendar. Seleziona un singolo giorno, ovvero un sottoinsieme del gruppo di partenza (quello delle mail ricevute), di nuovo Win+| , seleziona il programma per l'instant messaging, ed ecco la buddy list delle persone che hanno inviato le mail di cui sopra.
Come concetto puo' forse apparire astruso, io stesso lo devo bene esplorare, ma una cosa e' evidente: in uno scenario del genere l'integrazione tra le diverse applicazioni sarebbe completa ed implementata ad un livello logico al di sotto delle singole applicazioni stesse (nel layer di trasformazione XML -> XSLT -> videata), e dunque implicita e trasparente.
Chi segue questo blog o ha comunque gia' letto qualche post puo' forse ricordare la precedente idea del plumb inverso: ebbene, questo qui illustrato ne sarebbe un utilizzo ideale (la trasformazione dalla lista di mail alla lista di persone da mettere nella buddy list nell'esempio sopra ne e' un dimostrazione), una funzionalita' basilare su cui le pipelines sarebbero costruite.
Un altro passo verso la convergenza tra la potenza della linea di comando e la semplicita' dell'interfaccia grafica...

Magic Ink

Negli scorsi giorni ho avuto modo di leggere questo paper.
Nonostante sia stato scritto da una persona senza particolari referenze o titoli, ottimamente rappresenta quello che e' e quello che dovrebbe essere l'interfaccia utente di un PC: oggi abbiamo a che fare con lo strascico di vent'anni di pigrizia ed abitudine, durante i quali sono stati usati, riusati , abusati ed edulcorati concetti creati agli albori del personal computing per ovviare alla scarsita' di risorse dei sistemi dell'epoca, mentre la strada dovrebbe essere quella dell'integrazione e dell'automatizzazione.
La prima parte splendidamente riassume i principi intorno a cui dovrebbe essere costruita una interfaccia non solo "usabile" ma anche comoda ed intuitiva con un poco di buon senso e di stile, mentre nella seconda (dopo una lunga divagazione dell'autore un po' fuori tema, sull'implementazione di un tool per designers...) sono illustrati esempi di come i piu' forti progressi potrebbero essere raggiunti sfruttando al meglio la potenza delle macchine odierne per prevenire ed anticipare le esigenze dell'utente e limitare al massimo la fase di interazione col sistema (ovvero: la fase piu' critica, noiosa ed error prone).
Ammetto di essere stato fortissimamente influenzato da questa lettura e dalle perle di ingenua saggezza che riserva (alla fine, non dice nulla di nuovo. Semplicemente lo dice molto bene...), ho rafforzato alcune idee per lo sviluppo di Lobotomy, scartatene altre ed introdotte un paio di nuove. Mentre occasionalmente continuo il perfezionamento del VFS object oriented in LibHyppo di quando in quando mi fermo a meditare su come potrebbe apparire il prossimo Synapse soprattutto nella sua nuova prossima incarnazione di desktop manager.
Dovro' decidermi a scrivere una paginetta di documentazione preventiva prima o poi...

Cambiare, dalle fondamenta

Ieri sera, dopo aver scritto il precedente post, mi sono auto-ispirato e sono andato a leggere qualche articolo online del gia' menzionato Raskin e da altre fonti correlate, per rinfrescarmi la memoria.
La convinzione generale che mi sono fatto e' che i commenti di Raskin, correttissimi e sacrosanti, implicherebbero uno stravolgimento completo non solo del concetto di interfaccia utente, ma di tutto il sistema operativo a partire dal kernel.
Gia' da tempo il ben noto Tanenbaum sostiene il fatto che un PC deve essere stabile e sicuro per essere usabile, esattamente come... un televisore (che, notoriamente, non crasha, non reboota ed e' usabile da chiunque), ma oltre a cio' occorrerebbe forse rivedere il modo in cui le applicazioni interagiscono con il resto del sistema.
Per fare un esempio: a detta di Raskin (e non solo) non dovrebbe mai esserci bisogno di salvare i documenti o i files che si stanno elaborando. Sfido chiunque a dire che sia una cosa sbagliata. Ma come implementare cio'? L'applicazione deve costantemente tenere traccia delle operazioni che esegue l'utente, bufferizzarle e sbatterle permanentemente sul disco, ma... Ad oggi, nella specifica POSIX non e' minimamente prevista una cosa del genere, ed un file deve sempre essere scritto per intero (o comunque: a partire da dove e' stata eseguita la modifica in poi, tutto). Manca una syscall per dire al filesystem "salvami questi tot dati a partire dalla posizione X, ma non al posto di quelli esistenti: nel mezzo!".
Nei prossimi giorni leggero' (o ri-leggero') qualcosa in piu' di quanto scritto da Tanenbaum (o, piu' in generale, in merito a Minix3) per trovare qualche punto di contatto tra le visioni di alto (l'interfaccia utente) e di basso livello (il kernel) dei due personaggi, in costante ricerca di ispirazione.