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

mercoledì 30 gennaio 2008

Mezzo Uovo Blu

0 commenti
Non sto a spiegare come e perche', ma e' successo: da ieri sono in possesso di un Mac.
Vabbe', non e' un Mac nuovo: e' un vecchio iMac G3 "Blueberry", il primo modello della serie di PC targati Apple da sempre in controtendenza col mercato dei soliti Intel + Windows.
Sulla macchina non so assolutamente nulla, in quanto l'ho accesa per la prima volta solo poche ore fa' trovandomi dinnanzi ad un errore del kernel, ed invece di fare quella che sarebbe forse la cosa piu' ovvia e pratica da fare, ovvero bootare con un live CD di una qualsiasi distribuzione Linux che supporti l'architettura PPC per curiosare tra le proprieta' fisiche del dispositivo, sto scaricand... Ehm... Sto attendendo che mi arrivi la licenza di Mac 8.6 per procedere poi con l'installazione.
Forse discutibile da parte di alcuni e' la scelta di adottare un sistema Macintosh (oltretutto obsoleto) in luogo di Linux, NetBSD, Darwin o qualsiasi altro sistema atto ad essere piazzato su quell'arnese, ma il proposito e' quello di mettere mano una volta tanto su qualcosa di diverso, da una parte lontano da Unix (solo la serie X di Mac e' basata su kernel FreeBSD ed anzi recentemente riconosciuta come Unix a tutti gli effetti) e dall'altra rivoluzionario, quantomeno in termini di interazione con l'utente, come e' stata (ed e') la piattaforma dei ragazzi di Cupertino.
Poi gia' lo so che per usare realmente l'apparecchio finiro' per caricare Darwin e consumare il repository di MacPorts (non posso certo mettermi a scrivere software per Mac Classic, o pretendere che su di esso ci siano tutte le applicazioni di cui abbisogno), ma finche' posso cavalco l'onda dell'entusiasmo hackish e cerco nuove fonti di ispirazione.
Questa volta, dal passato.

venerdì 25 gennaio 2008

Non aprite quel cellulare!

1 commenti
Breve post per esprimere un parere in merito ad una notizia che puo' capitarvi di leggere o che magari avete gia' letto (a me era passata tra le mani diversi mesi addietro ed oggi me la trovo riproposta): il Readius, il "telefono" arrotolabile, e' una cagata pazzesca.
E' troppo grosso per essere un cellulare (vabbe' che chiuso e' assai compatto, ma lo si dovra' pur aprire... Ed allora non lo si potra' usare con una mano sola...), potrebbe rientrare nella categoria "Internet tablets" come i vari Nokia NXXX ma non ha connettivita' wireless ne' touchscreen (mi chiedo se ci sara' la possibilita' di scrivere almeno SMS), potrebbe starci ancora ancora come e-reader ma non e' ottimizzato per tale funzione (tanto valeva togliere il modulo GSM e renderlo ancor piu' compatto e piu' economico), e' palesemente fragilissimo, non e' open (quanto ci metteranno ancora i produttori di hardware a comprendere che l'unica strategia oggi valida e' quella di entrare nelle grazie dei developers "just for fun" che producono quintalate di applicazioni aggratis e si tirano dietro il mercato?) e costera' una cifra.
Molti potrebbero pensare a codesto aggeggio come ad un esempio di apparato mobile futuribile e futuristico, un simbolo dei tempi che cambiano e del progresso che avanza, ma a me sembra solo una trovata commerciale (che si risolvera' in un flop colossale con ulteriori nuove perdite per Telecom, coinvolta nell'iniziativa ed anzi tra i principali promotori): dai dispositivi portatili di prossima generazione mi aspetto molto di piu' che non codesto obrobrio di tecnologie potenzialmente valide malamente messe insieme.
Chi vivra', vedra'.

lunedì 21 gennaio 2008

Deja vu

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

Ma dei plugins che me ne fo'?

1 commenti
Ci avevo pensato qualche giorno fa', ma avevo dimenticato di riportare la cosa su questo blog e solo ora, aggiustando qualche bug in Hyppocampus, mi e' tornato in mente.
La domanda e': serve ancora a qualcosa tenere la gestione dei plugins in Hyppocampus? L'idea era fondata sul desiderio di sfruttare la base dati con applicazioni comuni gia' esistenti, quali clients di posta ed altro, ma oggi che l'intera struttura di Lobotomy e' stata rivalutata in direzione di un completo desktop environment fine a se' stesso il fatto di mantenere compatibilita' con sistemi esistenti comporta solo un aumento nella complessita' della piattaforma ed un tempo considerevole di sviluppo (ricordiamo che, originariamente, ogni formato esterno in cui si volevano esportare i dati sul filesystem doveva essere gestito da un plugin dedicato) e mantenimento.
Assunto che in ogni caso il sistema avrebbe dovuto essere rivisto pesantemente (diciamocelo: il meccanismo di matching tra le richieste avanzate ed il reperimento del plugin adatto per soddisfarle era piuttosto abbozzato...) e che comunque e' stato sospeso nella release 0.3rc1, mi sa che e' la volta buona che scarto completamente questa funzionalita' dalla roadmap e dal codice.
Tanto ho gia' abbastanza materiale su cui lavorare ;-)

Piccola parentesi di aggiornamento: oggi ho constatato il funzionamento dell'implementazione del meccanismo degli observers del VFS, c'e' ancora qualche correzione strutturale da fare ma il piu' dovrebbe essere a posto. Ho individuato qualche bug in Hyppocampus, soprattutto nella gestione delle query che contengono stringhe, e li sto correggendo aiutandomi a tracciarli con qualche programmino di test che lascero' poi nella release finale in funzione di "unit tests".
Speravo di rilasciare questo weekend ma mi tocca rimandare di almeno un'altra settimana, in quanto altri impegni tengono occupato il mio tempo libero nei giorni lavorativi.
E poi, vorrei allegare al pacco finale un po' di documentazione in merito al nuovo VFS implementato in LibHyppo. Con tanti begli schemini sul trattamento interno degli eventi :-P

domenica 20 gennaio 2008

LSQL?

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

sabato 19 gennaio 2008

XML vs JSON

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

mercoledì 16 gennaio 2008

FREE++

0 commenti
Essendo io artefice dell'iniziativa, non posso certo esimermi dal parteciparvi per mezzo del mio blog...
Su BarberaWare e' stato avviato il progetto FREE++, una campagna di sensibilizzazione degli sviluppatori freeware al freesoftware. Il fulcro dell'iniziativa sta in una sorta di lettera aperta (sebbene sia forse piu' corretto chiamarlo appello) che si vorrebbe vedere pubblicata in lungo ed in largo, al fine di essere letta ed illuminare qualche sviluppatore apportando nuova linfa al sempre piu' ricco panorama di software disponibile in forma di codice libero.
Non aggiungo altro in quanto la lettera, sotto riportata, gia' contiene pressoche' tutto; invito tutti a riprodurre a loro volta il testo sui siti e sui blogs di competenza, si' da propagare il messaggio quanto piu‘ lontano possibile.

Agli sviluppatori di software freeware,

questo messaggio, questo appello, e‘ a voi rivolto: rivolto a coloro che distribuiscono le proprie produzioni software gratuitamente, per mezzo dell‘Internet, in modo che tutti possano fruirne pur senza pagare per ottenere una licenza d‘uso; a chi e‘ mosso da passione e curiosita‘ nella realizzazione di un‘opera; alle persone che provano soddisfazione (ed anche, diciamocelo pure, divertimento) nel costruire qualcosa di utile, talvolta anche complesso, solo perche‘ appunto utile; a chi, per necessita‘ personale o per diletto, raccoglie la quotidiana e sempre rinnovata sfida degli addetti ai lavori in campo informatico: risolvere problemi.

Il punto cruciale che viene qui presentato e‘: perche‘ limitare le possibilita‘ di utilizzo, miglioramento e gradimento della propria produzione? Perche‘ confezionare una applicazione senza considerare l‘opportunita‘ di fare in modo che tutti possano trarre il massimo beneficio da essa? Perche‘ impedire a quelli con cui si spartiscono gli stessi interessi e le medesime passioni di apprendere il modo in cui si e‘ aggirato un problema e riutilizzarlo in altre opere? In poche parole: perche‘ non rendere il software non solo gratis, ma libero, un po‘ piu‘ "free"?

Inevitabile al giorno d‘oggi non aver mai sentito parlare di "freesoftware", o "software libero", ovvero di quella particolare modalita‘ di distribuzione del software secondo cui il programma viene accompagnato dal codice sorgente da cui si ricava poi il binario da eseguire. La variazione tra freeware a freesoftware e‘, sul piano pratico, minima: insieme all‘eseguibile compilato, pronto per essere eseguito dalla fascia di utenza che vuole usarlo per quel che fa, si distribuisce pure il codice sorgente che si e‘ amorevolmente steso, corretto e perfezionato per il programma stesso. Tale piccola accortezza porta ad una differenziazione assai piu‘ profonda tra i due approcci: l‘atto di pubblicazione del sorgente apre infinite strade a futuri sviluppi dello stesso, che potra‘ cosi‘ essere modificato, piu‘ facilmente perfezionato ed arricchito anche da terzi, ammirato e studiato da quelli che in esso trovano ispirazione o l‘agognata risoluzione di un proprio problema. Tutte attivita‘ che non potrebbero svolgersi se il software fosse si‘ gratuito ma pur sempre chiuso, segreto, inaccessibile. Tutte attivita‘ che non potrebbero svolgersi se si decidesse di condividere solamente lo strumento finale, la funzionalita‘, anziche‘ la conoscenza, il funzionamento.

Spesso l‘argomento "freesoftware" e‘ associato al mondo di GNU/Linux, il piu‘ conosciuto (ma non il solo) sistema operativo realizzato secondo i canoni dello sviluppo collaborativo, e ci si dimentica (o si ignora) che il principio base di questo approccio trascende ogni piattaforma, linguaggio e ambiente operativo. La concezione di freesoftware come lo si intende oggi nasce storicamente ben prima del fenomeno Linux e ne e‘ causa, non effetto, ed e‘ agnostica rispetto a qualsiasi tecnologia: nulla, ne‘ di carattere tecnico ne‘ legale ne‘ retorico, impedisce che un programma che si intende possa essere diffuso con una licenza libera sia scritto su un sistema operativo che di libero ha ben poco, o con strumenti proprietari e chiusi. La distinzione tra una applicazione ed un applicazione libera sta nella modalita‘ di distribuzione, non nel suo target o nella sua origine.

L‘invito che qui si vuole rivolgere ai tanti che amano realizzare cose utili per se‘ stessi e per il prossimo e‘ di valutare la possibilita‘ di renderle ancora piu‘ utili, andando al di la‘ della loro funzionalita‘ palese. La piena transazione dal modello freeware a quello freesoftware puo‘ essere piu‘ o meno indolore a seconda di come ci si vuol relazionare con chi si trovera‘ tra le mani il prodotto pubblicato: e‘ possibile impacchettare brutalmente il binario, il sorgente, la licenza preferita, e mettere il tutto a disposizione per il download su un qualsiasi sito web, oppure si puo‘ cogliere appieno lo spirito ed affrontare l‘avventura dello sviluppo collaborativo sfruttando la visibilita‘ di uno dei tanti portali che offrono spazio e risorse a chi vuole portare avanti un lavoro coinvolgendo altre persone in giro per il mondo, facendo crescere costantemente l‘opera. Per compiere un qualsiasi passo in direzione del software libero e‘ sufficiente volerlo, informandosi oggettivamente ed al riparo da ogni pregiudizio presso uno dei molti luoghi virtuali di dialogo e confronto sull‘Internet ed avanzare richieste di delucidazioni ai tanti che gia‘ hanno operato una scelta, oppure molto piu‘ semplicemente leggere il testo della licenza che piu‘ si gradisce e che meglio rappresenta le proprie esigenze: gli aspetti pragmatici da considerare immediatamente stanno tutti li‘, senza infarciture dialettiche soggettive e talvolta opinabili.

Gratis e‘ bene per molti, libero e‘ meglio per tutti.

lunedì 14 gennaio 2008

Pipelines Grafiche

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

domenica 13 gennaio 2008

Campa Draghetto che l'Erba Cresce...

0 commenti
L'annuncio ha gia' fatto il giro del web, e non poteva essere altrimenti considerando l'hype generato intorno all'evento, ed ora ho letto la prima review in merito al neo rilasciato KDE 4.0. Il riassunto: una zozzeria.
Come gia' ampiamente previsto le promesse non solo non sono state tutte mantenute, ma pure le funzionalita' presenti sono lasciate un po' a meta'. E gia' si parla di aspettare KDE 4.1 per vedere qualcosa di piu' vicino a quanto strombazzato negli ultimi mesi.
Sorvoliamo sui commenti fini a se' stessi ed osserviamo il fenomeno da un punto di vista piu' ampio, facendo onore alla sempre efficace e moderna saggezza popolare che tra i suoi innumerevoli detti menziona anche il noto "chi si loda, si imbroda".
Negli ultimi mesi i casi di prodotti annunciati come rivelazioni apostoliche, attesi, spiati, bisbigliati, chiaccherati, rilasciati e buttati nel cestino sono stati numerosi, da Windows Vista (ci hanno messo 6 anni a fare XP con le finestre semitrasparenti?) all'Android di Google (che non e' proprio stato cestinato, anzi continua a far parlare di se', ma si e' tirato dietro non poche critiche ed ha comunque fatto scappare una buona maggioranza di coloro che non dormivano piu' la notte attendendo il cosiddetto "GPhone"). Solo Apple riesce a non tradire (quasi) mai, ma e' appunto l'eccezione che conferma la regola.
Tanto quanto, da prodotti commerciali con interessi finanziari alle spalle ci si puo' anche aspettare questo atteggiamento da "io ce l'ho piu' grosso di tutti, aspettate un attimo che lo tiro fuori e ve lo faccio vedere", ma... Da un progetto free come KDE??? Mi sta bene la stimolante e benefica concorrenzialita' con Gnome, mi sta bene che ci tengano a fare qualcosa che sia usato da tante persone, mi sta bene tutto, ma la campagna di marketing stona un poco... Tantopiu' quando poi finisce come le campagne di marketing vere: tanto fumo e niente arrosto.
Chiudo questo intervento un po' OT rispetto alle tematiche abituali del blog augurandomi comunque, come l'autore dell'articolo sopra linkato, che la gente di KDE sistemi i numerosi problemi ancora esistenti al piu' presto in modo che la smettano di farci restare volenti o nolenti sulle spine con sta' benedetta serie 4.x...

sabato 12 gennaio 2008

In salute ed in malattia

0 commenti
Ed eccomi tornato alla mia postazione dopo tre settimane di medicine, brodino caldo e lunghi pomeriggi davanti alla TV: le mie vacanze di Natale sono state pessime, rovinate da una pesante bronchite accompagnata da qualche tacca di febbre che mi ha impedito pressoche' ogni attivita' intellettuale ivi compresa la programmazione. Come ogni anno contavo molto su questa pausa dal lavoro, che insieme a quella estiva rappresenta il periodo di massima produzione sui vari fronti di sviluppo amatoriale, ma quest'anno e' andata cosi'.
Solo nell'ultima settimana, piu' col pretesto di riattivare la corteccia cerebrale dopo il periodo di inattivita', ho avuto modo di tornare sul codice di Lobotomy, correggendo pesantemente l'ultimo componente che manca prima del rilascio di LibHyppo 0.3, ovvero il sistema di observers gia' qui menzionato in passato: la soluzione finale che ho adottato (ma che devo ancora perfezionare) e' forse meno efficiente rispetto a quella inizialmente (e precipitosamente) ponderata, ma certamente implica un netto miglioramento sulla quantita' di memoria primaria impiegata ed e' assai piu' semplice da implementare.
Prima: in Subconscious Daemon si replicavano tutti i result sets aperti dalle varie applicazioni che richiedevano il monitoraggio del filesystem e la notifica automatica dei cambiamenti, e quando qualcosa avveniva su Hyppocampus tutti gli insiemi venivano controllati per vedere se tale evento ne modificava il contenuto. Pro: una sola applicazione che esegue i controlli, notifiche inviate solo quando necessario. Contro: ridondanza, dati da tenere allineati in piu' processi, difficolta' nel tenere sincronizzate le varie copie.
Adesso: Subconscious Daemon funge da ripetitore degli eventi che arrivano dal filesystem (interpretandoli occasionalmente a sua volta per piccole operazioni di manutenzione ed estrazione automatica dei metadati) ed ogni applicazione controlla per conto suo se tale evento influisce sui suoi dati locali, emettendo nel caso i giusti signals interni. Pro: piu' elegante, molto piu' semplice e compatto da realizzare nel codice, mitigati gran parte dei problemi di consistenza dei dati. Contro: quantita' di computazione sprecata per eseguire controlli non necessari nelle singole applicazioni, ma che essendo appunto su piu' processi puo' essere implicitamente parallelizzata.
Al momento mi sto muovendo sulla seconda via e credo (spero!) di rimanerci, ho ancora qualche dubbio sulla granularita' e sull'interfaccia con cui distribuire i diversi eventi ma nulla di impossibile. Chiaramente, oltre che su LibHyppo sto lavorando pure su SCD, componente essenziale del sistema senza il quale il sistema di monitoraggio non ha ragione d'essere: la nuova release di questo pacchetto (che, a causa di un errore di valutazione risalente a molto tempo fa', segue una numerazione tutta sua...) accompagnera' quella di Hyppocampus 0.3.
E poi tocchera' a Kiazma/Synapse... Spero di non ammalarmi di nuovo...