lunedì 30 aprile 2007

La distribuzione Linux Desktop del Futuro Parte 4

Parte 4: L'Interfaccia Desktop


Questo articolo, strutturato in quattro parti, propone alcune riflessioni su come potrebbe funzionare un futuro Desktop Linux. L’articolo non ha la pretesa di essere esaustivo, sebbene l’autore consideri “fattibili” tutti i concetti esposti.


Parte 1: Linux e il Desktop di oggi

Parte 2: Applicazioni

Parte 3: File Management

Parte 4: L’Interfaccia Desktop



Nell'ultima parte di questo articolo metterò insieme le tecnologie precedentemente trattate e spiegherò come potrebbero coesistere in un ambiente desktop semplice da usare.


Il layout


Il layout -Copyright 2005 © AKAImBatman. Tutti i diritti sono riservati.


Quando un utente cerca di essere produttivo con il proprio computer, di solito è interessato solo ad alcune tipologie di file: Applicazioni e Documenti. Le Applicazioni sono i programmi che usa per lavorare con i propri documenti, e tutto il resto del lavoro è inteso a supportare questo tipo di funzionalità. Un utente, per esempio, non ha un reale bisogno del Cestino, ma è uno strumento che gli permette di avere una seconda possibilità prima di cancellare un gruppo di file in maniera definitiva.


Di conseguenza le sole cose che dovrebbero comparire sul desktop dell'utente sono:



  1. Un'icona per accedere alle applicazioni.

  2. Un'icona per accedere ai documenti.

  3. Un'icona per accedere al cestino.

  4. Tutto ciò che riguarda il montaggio di CD-ROM, periferiche di rete, macchine fotografiche, dischi USB, e altro ancora.


Ogni altra cosa dovrebbe essere tenuta fuori dal desktop. In particolare è abbastanza importante per il sistema NON avere collegamenti sul desktop per prevenire il solito eccesso di offerte speciali e installer.


Nell’ottica di rendere più facile l'accesso ai file, è nell'interesse dell'utente permettere ai file selezionati di apparire sul Desktop. Nell'interfaccia proposta, il Desktop non sarebbe altro che un’etichetta usata dal sistema per identificare quali file dovrebbero essere mostrati. Di conseguenza, il menu che appare con un clic del pulsante destro del mouse e/o le toolbar possono fornire all'utente l'opzione per aggiungere o rimuovere file dal desktop. La differenza fondamentale tra il funzionamento di meccanismo in un DBFS, anziché in un sistema normale, è che il file non verrebbe mai trasferito in un DBFS. Se il file è già organizzato, non dovrà essere spostato per apparire sul Desktop: sarà sufficiente aggiungere un’etichetta al file, e la sua rimozione non avrebbe alcun effetto sul file se non farlo sparire dall'area desktop.


Gli altri due elementi chiave sul Desktop sono la casella di ricerca e la task bar.


Applicazioni


Applicazioni - Copyright 2005 © AKAImBatman Un clic sull’icona Applicazioni fa comparire una finestra del file browser che mostra i contenuti dell'etichetta corrispondente. Questa etichetta può teoricamente contenere qualsiasi cosa, anche sotto-etichette, ma per impostazione predefinita ospiterà tutte le applicazioni. Nella sezione dedicata ai filtri parleremo di un metodo con cui le applicazioni possono automaticamente essere dirottate in quest'area.




Documenti


Documenti - Copyright 2005 © AKAImBatman L'icona Documenti mostra una finestra del file browser del livello principale della struttura ad albero delle etichette. I file non classificati vengono visualizzati nel ramo principale, mentre qualsiasi altro file con almeno un'etichetta è posizionato al di sotto dell'etichetta, o delle etichette selezionate. Le etichette Applicazioni e Cestino sono automaticamente eliminate per non confondere l'utente. Da notare che quello che viene mostrato non è il reale livello principale della struttura del file system, ma piuttosto la root virtuale costituita unicamente da file ed etichette senza riferimenti precisi. Non esiste una vera gerarchia nel file system di un database, quindi l'informazione dell'etichetta e del file è usata per calcolarne una.


Una speciale “etichetta” chiamata “Utenti” dovrebbe apparire qua sotto, con una serie di sottodirectory per tutti gli utenti del sistema. Ogni cosa posta al di sotto del nome dell'utente fa parte dei loro file e meta-dati DBFS.


Cestino

Cestino - Copyright 2005 © AKAImBatman Come accennato in precedenza, i file che si vogliono cancellare sono semplicemente contrassegnati con l'etichetta “Trash”. A differenza delle altre etichette, comunque, ogni file con un'etichetta Trash dovrebbe essere automaticamente nascosto dal file browser a meno che il Cestino sia stato esplicitamente abilitato. Se l'utente decidesse di recuperare un file dal Cestino, il sistema si limiterebbe semplicemente a rimuovere l'etichetta Trash dal file per ripristinare tutta la serie di etichette e attributi a lui collegati. Se, invece, l'utente decidesse di svuotare il cestino, il file sarebbe definitivamente cancellato solo in quel momento.


Da notare che il file non sarebbe mai realmente spostato o modificato. Il “trasferimento” nel Cestino è una pura illusione pensata per fornire un meccanismo simile al Cestino in uso negli attuali sistemi operativi, ma molto più solido grazie alla capacità di non modificare la posizione del file.


Search Box

Search Box - Copyright 2005 © AKAImBatman La search box, posizionata a destra nella parte alta del desktop, è uno strumento di ricerca a metà strada tra Spotlight di Apple e una linea di commando. Se il box rileva che l’utente ha digitato un path assoluto, farà apparire una finestra per il browsing dei file senza tenere conto del fatto che è esterno al DBFS. Questa risposta fornisce all'utente un modo per sfogliare i file di sistema, se lo desidera, senza dover ricorrere a una console. La search box può anche ricorrere a un URL o a una URI inserita per accedere direttamente a un sito Internet o a una risorsa di rete condivisa.


In ogni altra situazione, la search box cercherà automaticamente tutti i file nel DBFS, passando al setaccio indici e meta-dati per trovare una o più corrispondenze. Poiché questa query può letteralmente spingersi nei meandri del DBFS, l’idea è che risulterebbe estremamente veloce grazie agli indici del DBFS.


Futuri sviluppi della search box potrebbero arricchirla di funzionalità più complesse come comandi rapidi per eseguire programmi, ricerche Web, interfacce di programma, ricerche su dizionari e altre feature che ricordano molto da vicino la combinazione tra ricerca e linea di comando offerta oggi da Google.


Un'altra importante funzione da includere in Search è un sistema che permetta di salvare la ricerca come una pseudo cartella. In realtà la ricerca non sarebbe niente di più di un file su disco che porta ai risultati della finestra search, con la conseguente accettazione da parte del file dell'aggiunta di etichette e meta-dati - permettendo quindi al file di accettare le solite etichette e i meta-data aggiuntive - sebbene l'icona per il salvataggio della ricerca mostrerebbe all’utente unicamente uno speciale tipo di cartella.


Barra delle Applicazioni/Dock


Barra delle Applicazioni - Copyright 2005 © AKAImBatman

Gli esperti delle moderne UI (User Interface) sono concordi che debba esistere un sistema intelligente che permetta all'utente di vedere e accedere a tutte le finestre dei programmi in esecuzione. Per molto tempo, la Barra delle Applicazioni di Windows, che mostra un pulsante per ogni finestra aperta, è stato il più popolare di questi sistema. Fino a questo momento, niente di sbagliato è stato trovato in questa interfaccia, se si escludono i potenziali problemi legati all’usabilità quando la barra è sovraffollata. È un tipo di interfaccia ancora molto familiare per un gran numero di utenti.


Analogamente, il Dock è molto conosciuto tra gli utenti di Mac OS X. L'interfaccia di Dock offre una soluzione al problema del sovraffollamento riducendo automaticamente la dimensione delle icone in modo che possano essere tutte contemporaneamente visibili sullo schermo. Le icone non sono mai troppo piccole perché si ingrandiscono quando l'utente vi muove sopra il puntatore del mouse. Questo sistema permette all'utente di gestire centinaia di programmi con un semplice passaggio del puntatore sul Dock.


Qual è Quindi il miglior sistema? La risposta è: quello preferito. Alcune persone prediligono il metodo Windows, altre quello proposto dal Mac. Ebbene, questa è l’unica situazione in cui dare all’utente la possibilità di scegliere può fare la vera differenza. Lasciamo, per esempio, che sia l'utente a decidere quello che vuole. Si tratta di soluzioni simili che condividono gli stessi metodi di implementazione, e questo desktop non ha nessun bagaglio extra per differenziare il proprio design a livello di API.


Filtri


Chiunque abbia usato l'e-mail almeno una volta può confermare che la possibilità di gestire le regole sulla posta in arrivo è un prezioso strumento per organizzare e amministrare i proprio messaggi. Gli utenti di Gmail possono testimoniare che quando queste regole, chiamate filtri in Gmail, sono abbinate alle etichette anziché alle cartelle, diventano ancora più utili che in passato. In Gmail è possibile, per esempio, organizzare automaticamente la propria posta attraverso apposite etichette, pur continuando a vedere i messaggi nella casella “Posta in Arrivo” prima di archiviarli. Questo procedimento consente di risparmiare moltissimo tempo perché l'utente non deve controllare individualmente ogni singola cartella.


Quando applicato ai file scaricati, questo sistema solleva un'interessante questione. Perché i browser Web non dispongono di regole per organizzare automaticamente i file scaricati?

Sorprendentemente la risposta è la stessa di quella fornita per le regole della posta e le cartelle. Impostando una regola, un messaggio bypassa ogni tipo di area d’archiviazione - nella maggior parte dei casi la Posta in Arrivo - dove l'utente può essere facilmente informato della sua presenza. Gli utenti hanno già abbastanza seccature cercando di trovare i file che hanno scaricato senza doversi preoccupare anche di file che si spostano automaticamente Dio solo sa dove.


Eppure, proprio come avviene con le e-mail, il problema si può essere risolto grazie all’introduzione delle etichette. Un file può essere automaticamente organizzato tramite un’etichetta senza per questo dover rimuovere altre etichette già presenti, come “scaricato” o sul Desktop. Software intelligenti dovrebbe anche essere in grado di gestire autonomamente i download dell’utente e rimuovere i file contrassegnati da un’altra etichetta dopo un certo periodo di tempo.


La migliore implementazione per questo meccanismo è spingere le regole sino al livello del file system. Quando viene creato un nuovo file, il DBFS controllerà i filtri e, se qualcuno di essi è in funzione, li userà per applicare automaticamente etichette al file. Se creo un nuovo documento SXW, per esempio, potrei impostare una regola per assegnare automaticamente al file l'etichetta “Word Processing”. Niente mi vieta di aggiungere successivamente anche un'etichetta specifica per il progetto, ma grazie al filtro giusto so che posso sempre trovare tutti i miei documenti SXW in un posto preciso. Analogamente, posso impostare un filtro che specifichi che tutti i file MPG con le parole “Star Trek” nel nome devono essere disposti sotto le etichette “Video e “Star Trek”.


La potenza di un sistema di questo tipo sta nella possibilità di alleggerire gli utenti da alcuni compiti. Se la ricerca può ridurre il tempo che un utente passa a cercare un file, i filtri rendono quasi inutile la loro organizzazione. Inoltre, se un tipo di file non è adeguatamente classificato dal sistema, l'utente può sempre aggiungere un altro filtro.


La Finestra File Salva


Poiché questo nuovo modello di Desktop e Filesystem fa piazza pulita del procedente concetto di directory, diventa importante che la finestra di dialogo File Salva venga aggiornata per riflettere questo cambiamento. Mentre le vecchie finestre di dialogo funzioneranno bene ancora per un po' – perché vedranno le etichette come se si trattasse di directory e il DBFS assegnerà automaticamente le etichette selezionate - una valida soluzione sarebbe però una finestra Salva che mostri all’utente le etichette nel sistema, e permetta di crearne una lista, oltre ad abilitare l'assegnazione di nome e tipologia al file.


Questo sistema potrebbe essere sviluppato per molte applicazioni correnti modificando i selettori di file delle librerie GTK e QT esistenti. Sfortunatamente il resto delle applicazioni avrà bisogno di essere modificato per supportare il nuovo sistema di etichette. Non è poi così grave, in ogni caso! Perfino con le applicazioni che non sono in grado di rompere la dipendenza dai selettori di file, i filtri del file system permetteranno ancora agli utenti di organizzare automaticamente il proprio sistema malgrado malfunzionamenti di un dato programma.


Filter Manager/Pannello di Controllo/Network Browser


Uno dei più grandi crimini contro un buon progetto d’interfaccia utente è stato tentare di spostare le funzionalità “comuni” direttamente nella metafora del Desktop. Certe funzionalità sono solo servite a disorientare gli utenti e a complicare l'interfaccia. Eppure l’integrazione di alcune feature si è resa quasi necessaria per evitare che l’utente selezionasse dozzine di menu di scelta prima di trovare le opzioni di sistema desiderate.


Grazie alle Applicazioni come lo schema Files, l’utente non deve più sopportare oltre questa situazione. Funzionalità come il Pannello di Controllo, il Network Browser e altre feature di sistema dovrebbero apparire “solo come un'altra applicazione”. Se l'utente ha abbastanza sale nella zucca da capire che le feature hanno bisogno di queste applicazione, sarà anche in grado di cercare e di trovarle nell'etichetta Applicazioni.


Questo non significa che altri programmi non potrebbero richiamarle. La soluzione è che l'interfaccia vada fornita solo quando ha un senso e mai a sproposito. Il risultato finale di questo design è che queste interfacce possono davvero essere aggiornate in maniera indipendente dai componenti di sistema. Il che è una buona cosa quando ritenete che non sono niente di più che GUI che assistono l'utente nella gestione del sistema di configurazione. Se un utente sente la mancanza di queste opzioni disponibili dal Desktop, può semplicemente aggiungere l'etichetta Desktop alle applicazioni e ammirare come si integrano perfettamente nel loro desktop!


Assenze eccellenti


Ci sono poche cose che mancano in modo evidente dall’idea di Desktop appena proposta. La prima è che non c'è il pulsante “Start”, o simili. Questa assenza è intenzionale. Il pulsante Start è sempre stato una metafora confusa che ha visto la luce solo per nascondere l’incapacità del Desktop di funzionare in maniera coerente.


Un'altra cosa che noterete è la mancanza del concetto di shortcut. Anche questa assenza è intenzionale. Gli shortcut sono metafore pericolose perché non conservano la sincronia con il loro riferimento. Sono stati creati come metodo per sopperire alla mancanza di funzionalità sul Desktop, per esempio i collegamenti alle applicazioni accessibili dal pulsante Start, così come l’incapacità del file system di creare collegamento dinamici ai file. Pensate, per esempio, a cosa succederebbe se l’apertura di un file avvenisse tramite uno shortcut? Sarebbe un sistema di identificazione collegato al file in questione a richiamarlo, o piuttosto quello collegato ai contenuti del suo shortcut? Se la risposta è la prima ipotesi, allora come fa il sistema a editare gli shortcut? È richiesta una speciale chiamata FNCTL?


Come potete notare, escludere questi concetti dal Desktop contribuisce solo a migliorare la situazione. L'unica eccezione alla regola “niente shortcut” è l'interfaccia Dock. Se l'utente sta usando l'interaccia Dock, allora probabilmente avrà shortcut che puntano ai programmi più comuni installati sul sistema. Una possibile soluzione a questo problema è di creare una etichetta “Dock”, dove ogni applicazione così contrassegnata apparirebbe automaticamente sul Dock senza tener conto se sia in funzione o meno.


Problematiche rimaste in sospeso


Come tutte le discussioni di alto livello, anche questo articolo lascia ancora diverse problematiche senza una risposta. Come fanno, per esempio, gli utenti a condividere le applicazioni? Restano disponibili per tutto il tempo a chiunque, oppure c’è un sistema che permette alle grandi applicazioni di sistema di esistere indipendente dall'utente che le possiede? Questioni come questa sono facilmente risolvibili con la dovuta riflessione. Il segreto è di essere consapevoli del nuovo paradigma che questi cambiamenti mettono sul tavolo.

La distribuzione Linux Desktop del Futuro Parte 3

Questo articolo, strutturato in quattro parti, propone alcune riflessioni su come potrebbe funzionare un futuro Desktop Linux. L’articolo non ha la pretesa di essere esaustivo, sebbene l’autore consideri “fattibili” tutti i concetti esposti.


Parte 1: Linux e il Desktop di oggi

Parte 2: Applicazioni

Parte 3: File Management

Parte 4: L’Interfaccia Desktop



Parte 3: File Management


Quando la complessità dei sistemi dei computer aumenta, la tendenza è di trasferirla anche nel file system dell'utente, generando così una confusione tra quali file sono importanti e quali invece sono solo destinati ai dati delle applicazioni. Questa complessità disorienta l’utente sulla giusta collocazione dei propri file, e in casi limite, può addirittura far dimenticare dove siano stati salvati i propri documenti! In questa sezione vedremo in che modo il sistema Linux può aiutare a ridurre ulteriormente la complessità in queste aree.


Database File System


Raccomando vivamente a chi non avesse ancora letto il mio precedente articolo sui Database File System di farlo adesso.


Il segreto per abbassare il livello di complessità dei moderni file system è di separare i file di sistema dai documenti. Gli attuali sistemi hanno tentato in passato di risolvere questo problema incoraggiando gli utenti a salvare i proprio documenti nella loro home directory, ma seguire questo consiglio può aumentare i problemi nel caso in cui l'interfaccia utente “peschi” in directory speciali. Sotto le attuali interfacce Linux gli utenti potrebbero perfino non essere in grado di accedere ai file posizionati sul loro desktop senza il ricorso a un'interfaccia grafica!


Nella sezione precedente abbiamo diminuito la complessità delle applicazioni trasformandole efficacemente in documenti. Ma questo approccio non cancella completamente la confusione nell'utente su come organizzare i propri documenti e applicazioni tenendoli separati dai file di sistema. Per risolvere questo problema abbiamo bisogno di dividere il file system in due aree:



  1. Una partizione per le librerie principali di sistema, i file di root e /usr.

  2. Una partizione DBFS per le applicazioni e i documenti dell'utente.


Librerie del Core System


Una delle cose più importanti di cui un utente desktop ha bisogno di liberarsi è della manutenzione dei file di sistema. Questo tipo di operazioni si è sempre dimostrata problematica per gli utenti Windows ed non a caso è stata etichettata come “DLL Hell” (ndt Inferno delle DLL). Alla fine Microsoft ha risolto il problema apportando alcune modifiche al sistema operativo, ma anche incoraggiando gli sviluppatori a tenere le loro DLL all'interno delle directory dei rispettivi programmi. Oggi la maggior parte dei programmi Windows si installa in una cartella chiamata “Program Files”, “Programmi” nella versione italiana, senza l’aggiunta di file estranei nella directory System32.


Linux, dal canto suo, ha preferito seguire la strada del package management. Non esisteva un reale standard per il sistema base, e le librerie principali potevano essere aggiornate a piacere. Questo sistema porta una situazione in cui una data versione di distro può significare un differente assortimento di API disponibili sotto ciascuna installazione. Standard come LSB (Linux Standard Base) sono stati proposti per contribuire a migliorare la situazione, ma tali sforzi si sono concentrati più che altro nel porre un limite al numero di API a basso livello coinvolte. Quello che più conta in una distro pensata per un ambienti Desktop è che lo sviluppatore sia in grado di fare affidamento su uno specifico set di API per un dato livello di sistema.


Immaginiamo di creare, per esempio, un ipotetico sistema Linux per desktop chiamato DeskLin. Per la versione 5.0 Desklin pubblicherà API per GTK 2.1 e QT 3.2, e di conseguenza tutti i programmi basati su GTK 2.1 e QT 3.2, o sulle rispettive versioni precedenti, dovrebbero poter funzionare. Se uno sviluppatore volesse, invece, creare un programma che usa il FLTK toolkit avrà bisogno di includere gli shared object di FLTK nella cartella lib del pacchetto della sua applicazione. Ora immaginiamo invece che DeskLin Inc. noti che una grande quantità di applicazioni usa le API FLTK. Per ridurre lo spreco, potrebbe decidere di includere le FLTK come API principali in DeskLin 6.0. Questa operazione permetterebbe agli sviluppatori di applicazioni software di sfruttare queste API finché il loro obiettivo è la versione 6.0, o superiore, della distribuzione del sistema operativo DeskLin. Uno sviluppatore di programmi può comunque ancora porsi come target la versione 5.0 includendo le librerie FLTK.


Il risultato finale di questo processo è che il controllo delle API di sistema è tolto dalle mani dell'utente. Ma se molti puristi di Linux storcerebbero il naso di fronte a una simile ipotesi, è importante notare che non sto incoraggiando questa pratica per tutte le distribuzioni. Negli ambienti workstation e server può rivelarsi estremamente importante che l'utente continui a mantenere il completo controllo sul proprio sistema. Solo distribuzioni desktop-oriented, che stanno cercando di conquistare gli utenti consumer, dovrebbero cambiare rotta e considerare questo tipo di iniziative.


Gli aggiornamenti legati alla sicurezza continuerebbero a restare un problema. Sarebbe, sensato per una distribuzione orientata ad ambienti desktop, quindi, includere un sistema d’installazione come Autopackage in grado di installare le patch nel sistema in maniera semplice e veloce. Le patch dovrebbero essere automatizzate, quando possibile, e le librerie principali nascoste all'utente e impostate come read-only.



Documenti


A differenza delle librerie di sistema, gli utenti VOGLIONO poter gestire i loro documenti e sono sempre felici quando gli viene offerta la possibilità di farlo. La migliore soluzione per gli utenti è di mettere i loro documenti e solamente i loro documenti in un database file system. In molti altri sistemi operativi questo potrebbe rappresentare un problema per via della presenza di un unico filesystem tree. In Linux possiamo ottenere molto di più.


Sotto Linux possiamo infatti creare un nuovo modulo VFS in grado di gestire una partizione DBFS indipendente dalla partizione con il file system. L’integraziome del DBFS può quindi avvenire senza grandi problemi montandolo su una sottodirectory standard come, per esempio, /Documents. Da un terminale e da tipici programmi Linux, le etichette DBFS si presenterebbero con l’aspetto di normali directory, mentre i file non inclusi nella cartella /Documents non saranno scrivibili dai normali utenti. Le query inviate al file system potranno essere eseguite attraverso una speciale interfaccia /proc o /dev, permettendo al desktop di cercare velocemente e con precisione i file che l’utente ha richiesto.


Questa soluzione pone comunque alcuni problemi. In un database file system, lo stesso nome di file può presentarsi più di una volta, persino sotto la stessa etichetta. È quindi molto importante che i programmi inizino a usare un numero INode per il file invece di un percorso astratto. Sono due le soluzioni che mi vengono subito in mente per gestire i “tradizionali” programmi software:



  1. Permettere al componente finale del path di essere il numero INode. Questo risultato potrebbe essere ottenuto con nomi di file speciali come per esempio “#1234” oppure “@1234”. Nomi simili non sono di solito usati negli odierni sistemi Unix ed è quindi difficile poterli richiamare per sbaglio. Questi nomi possono essere passati ai programmi software installati per assicurare che il corretto file sia stato selezionato. Si potrebbe però ancora incorrere in qualche problema se il programma mostrasse il nome del file.

  2. Prendere una pagina dallo schema VFAT di Windows e presentare i duplicati sotto la stessa tabella con una speciale estensione per il nome del file. Due file dal nome “Bill.doc”, per esempio, potrebbero diventare “Bill #1.doc” e “Bill #2.doc”. L'unico svantaggio è che lo schema numerico potrebbe confondere l’utente, specialmente se tentasse di rinominare i file per includere un'aggiunta speciale.


File di configurazione


Il tipo di file di cui non mi sono ancora occupato è il programma di configurazione dei file. La ragione è che al momento non ho ancora individuato per loro una “buona” sistemazione. La soluzione adottata da Windows di usare un registro principale non è assolutamente una cattiva idea, sebbene non si tratti affatto di una buona implementazione, perché aggiunge un’ulteriore distrazione per l'utente che deve averci a che fare. Inoltre, è più complicato forzare i programmi di Linux a passare a una soluzione che usa un registry di quello che avviene per le applicazioni Windows. Il controllo centralizzato ha i suoi vantaggi.

La migliore soluzione che mi viene in mente al momento è di rifarmi allo standard Unix per la configurazione dei file per creare un registry virtuale nel file system. L'idea è questa:



  • quando il DBFS rileva un file o una directory creata con il prefisso “.” - un tipo di denominazione convenzionale che nasconde un file in Unix - rintraccia immediatamente il programma che l'ha generato sul disco immagine. Anziché creare il file, il DBFS crea un collegamento al programma immagine con dei meta-dati binari. Il risultato dello pseudo file è quindi indicizzato dal DBFS in modo che un programma di gestione, tipo Regedit, possa recuperare velocemente una lista di tutte le applicazioni con quei file di configurazione.


Gli svantaggi di questo schema sono i seguenti:



  • Le impostazioni dell’applicazione sono collegati al programma in modo permanente. Se si procede alla cancellazione dell'applicazione software del disco immagine, le impostazioni saranno eliminati di conseguenza. Molti utenti potrebbero vedere in questa soluzione dei vantaggi, ma dipende dal programma. Alcune applicazioni molto voluminose sono rimosse e successivamente reinstallate dagli utenti in base allo spazio disponibile su disco. I videogiocatori, nello specifico, potrebbero non essere molto contenti di perdere la loro partita salvata in Doom III. La soluzione più ovvia sarebbe di incoraggiare il vendor a modificare il gioco salvato in un regolare documento associato all'applicazione.

  • Le comunicazioni fra programmi tramite i file di configurazione è resa più complicata. Opera, per esempio, dovrebbe supportare la necessaria API DBFS per accedere direttamente ai meta-dati che ospitano preesistenti bookmark allocati in Firefox. In un sistema Unix tradizionale Opera dovrebbe solamente aprire la sottodirectory con il prefisso “.” nel folder home dell'utente.


La Struttura DBFS


Se i dettagli tecnici su come il DBFS memorizza i file e i meta-dati sia nella maggior parte dei casi parte irrilevante, ho invece intenzione di fare una rapida panoramica sulla struttura per chiarire tutti i dubbi su cosa un DBFS possa o non possa fare.

Un DBFS, così come è stato concepito in questo articolo, farebbe a meno della tradizionale memorizzazione di INodes e directory. I dati relativi al file system, invece, ricorderebbero molto da vicino un database SQL. Nel database sarebbe presente una voce per ogni file su disco con collegamenti conformi ai meta-dati. L’elenco dei meta-dati si presenterebbe simile a una tabella a tre colonne: il nome dei meta-dati, il tipo di meta-dati e un link al valore in un'altra tabella. Sarebbero previste tabelle per String, Integer (64 bit?) e tipi Data Block.

Per il tipo
Data Block la tabella conterrebbe una lista di blocchi dei file di sistema usati da una specifica parte di meta-dati. Tutti i file includerebbero un parte di questo tipo di meta-dati per rendere possibile l’identificazione dei file contenuti, presumibilmente caratterizzato da un nome facilmente identificabile come “data”. A dire il vero, i meta-dati Data Block potrebbero comunque essere allegati, diversamente dai contenuti dei file. L’icona dell'applicazione, per esempio, potrebbe essere memorizzata in un valore meta-dati chiamato “icon”, o una miniatura di una foto archiviata sotto la voce “thumbnail”. In pratica l’unico limite alla capacità di archiviazione dei meta-dati binari pre-calcolati dipende dallo spazio su disco e dall’immaginazione dell’utente. Persino il semplice vecchio testo può essere agevolmente estratto da meta-dati in un file e archiviato nel file system per semplificarne l’accesso.

Ognuna delle “tabelle” nel DBFS sarebbe adeguatamente indicizzata per fornire dei tempi di ricerca delle informazioni più veloci possibile. È probabile che tali indici possano anche essere creati per i contenuti di un file in modo da rendere veloci la ricerca e le interrogazioni sui file.


Sintonizzatevi la prossima settimana per l’ultima parte di questo articolo in cui combinerò tutte queste feature in un'interfaccia semplice da usare!


(Continua a Pagina 4)


Riferimenti:


LSB

Autopackage

La distribuzione Linux Desktop del Futuro Parte 2

Questo articolo, strutturato in quattro parti, propone alcune riflessioni su come potrebbe funzionare un futuro Desktop Linux. L’articolo non ha la pretesa di essere esaustivo, sebbene l’autore consideri “fattibili” tutti i concetti esposti.


Parte 1: Linux e il Desktop di oggi

Parte 2: Applicazioni

Parte 3: File Management

Parte 4: L’Interfaccia Desktop



Parte 2: Applicazioni


L'uso delle odierne applicazioni è complicato non solo dal sistema a pacchetti, ma anche dallo standard Linux che riunisce in poche sottodirectory tutti i file dei programmi. Le difficoltà connesse a uno schema di questo tipo erano note già da tempo nell’ambito delle distribuzioni commerciali Unix che introdussero la directory “/opt” per consentire ai programmi di crearvi le proprie sottodirectory. Purtroppo nessun standard di questo tipo è emerso sotto Linux.


AppFolder


AppFolderLa migliore soluzione attualmente in circolazione per installare applicazioni si ricollega al concetto AppFolder di NeXT/OS X. In poche parole, l'intera applicazione è contenuta in una cartella con un'estensione speciale. Quando il file browser vede una cartella con questa estensione, la tratta come se fosse un file speciale invece di una directory. Il risultato è che l'utente non vede altro che un’unica icona per l’applicazione ed è libero di muoverla o copiarla questa icona ovunque desideri – persino su un computer remoto.

Il procedimento d’installazione è semplice come copiare una cartella e spostarla dove più si preferisce, mentre la sua disintallazione si riduce alla semplice cancellazione del folder, con la conseguenza estrazione automatica delle tonnellate di meta-info (come le associazioni) dal pacchetto.


Queste feature rendono AppFolder un’eccellente soluzione per tutti i sistemi desktop, incluso Linux. Sfortunatamente esistono alcune questioni che ne riducono l’utilità nelle attuali distribuzioni Linux:



  1. Copiare una directory su un'altra è al momento gestito a livello di singolo file anziché a livello di directory. Questo significa che se volete sostituire un’applicazione con una versione più recente, i nuovi file si sommerebbero a quelli preesistenti anziché creare una copia pulita della struttura della nuova directory.

  2. Linux già dispone di una struttura standard per le directory - per esempio $prefix/bin, prefix/lib, $prefix/man, $prefix/share, e altre ancora - e sarebbe difficile cambiarla in blocco per un gran numero di programmi.

  3. Linux non offre un buon metodo per notificare ai programmi i cambiamenti avvenuti in file e directory.


La Soluzione


La Soluzione La soluzione proposta è la seguente: i programmi sarebbero compilati normalmente, ma con l'opzione “--prefix” assegnata alla nuova cartella. Un'ottima scelta sarebbe, per esempio, /usr/src/build/$APPNAME. Una creazione standard produrrebbe di norma solo la sottodirectory /bin, e in via opzionale anche /lib, /man e /share. Da questa cartella sarebbe così possibile eseguire il programma modificando il PATH e l’LD_LIBRARY_PATH. Aggiungendo come standard anche uno script di shell eseguibile (per esempio /execute), potremmo ottenere un sistema per avviare qualcosa all’interno di una data directory.


Il compito dello script execute sarebbe quindi di analizzare con cura il suo ambiente di riferimento, e di avviare tutte le variabile necessarie al programma. Molte applicazioni, per esempio, dispongono di variabili proprie per identificare dove le informazioni allocate in /share sono memorizzate nel file system. Una volta che lo script execute ha configurato l'ambiente, lancerà l'eseguibile principale. È da notare, inoltre, che questo metodo permette alle applicazioni non native, come per esempio WINE e Java, di condividere senza grandi problemi lo stesso sistema.


File singolo vs directory


Non esiste ovviamente ancora una soluzione per tutti i problemi elencati in precedenza. Se il punto 2 è stato efficacemente affrontato, le questioni relative ai punti 1 e 3 restano tuttora ancora aperte. Contro ogni aspettativa, il punto 1 potrebbe essere risolto abbastanza facilmente preferendo l’uso di un singolo file a quello delle cartelle.


Se quest’ultima frase vi ha fatto vacillare, non è il caso di preoccuparvi. Non sono impazzito. C'è infatti un metodo che consente di avere un singolo file per applicazione senza dover rinunciare al concetto di AppFolder di cui abbiamo appena discusso. Considerate per un momento se avessimo creato un'immagine disco della cartella che ospita l’applicazione. Avremmo adesso un singolo file, un file portabile che potrebbe essere spostato su qualsiasi sistema Linux. Il sistema in oggetto può montare l'immagine ed eseguire l'applicazione richiamando lo script /execute.


Lo script execute diventa ancora più importante in presenza di file binari multi-piattaforma perchè è in grado di rivelare il tipo di architettura e di eseguire il file più appropriato. Il vantaggio di questo metodo, rispetto a quello fornito da ELF (Executable and Linking Format), è che non sono necessari compilatori multi-piattaforma. I file binari possono essere compilati su ogni sistema e poi riuniti in un singolo AppFolder/Disk image.


Non sono sempre rose e fiori purtroppo. Se abbiamo intenzione di adottare un design sullo stile di AppFolder avremmo allora anche bisogno di trovare un metodo per caricare le informazioni che riguardano il file. Quale icona dovrebbe essere mostrata, per esempio, per l'immagine del disco? La soluzione più ovvia sarebbe di scoprire quando il file appare per la prima volta sul sistema. Che l’individuazione avvenga attraverso il desktop grafico o tramite un sistema più avanzato come dnotify (Linux directory notification support), il file dovrebbe essere visto, montato, le meta-informazioni lette, e quindi smontato. Nel prossimo articolo approfondiremo la questione su dove le meta-informazioni potrebbero essere archiviate.


Feature extra


Dando per scontato che una routine sia usata per individuare il tipo di disk image prima del montaggio, un gran numero di feature del file system possono essere supportate. CramFS potrebbe essere usato per un’immagine disco compressa disponibile in sola lettura, mentre ext2fs utilizzato per un'immagine riscrivibile, perfetta per software a tempo limitato. Si potrebbe anche pensare di sviluppare un formato immagine che supporti la crescita del sistema image/file system, la protezione tramite password per un disco criptato e altre funzioni disponibili solo per questo tipo di formato. Persino la possibilità di bloccare un software – per impedirne la manomissione da parte degli utenti - e di portare in giro le informazioni, insieme alle applicazioni che le hanno generate, sono feature molto potenti, non ancora viste su altri sistemi.


Progetti esistenti


Come era da immaginare qualcosa è stato già fatto in quest'area. Rox Filer ha incorporato AppFolder da un po' di tempo, anche se la selezione delle applicazioni è ancora piuttosto ridotta. Klik è leggermente più recente e ha introdotto i file CMG – un’applicazione integrata in un file system CramFS. Ultimo ma non meno importante, GoboLinux ha accettato la sfida di creare un sistema Linux stabile che separi tutti i file binari in folder per ogni singolo programma. La speranza è che questo articolo porti un po' di visibilità a questi progetti e fornisca al tempo stesso anche delle utili spunti per il loro futuro sviluppo.


(Continua a Pagina 3)


Riferimenti:


Rox Filer

Klik

CramFS

GoboLinux

Spiegazione di un Database File System

Uno degli argomenti più caldi sul mercato odierno sono i Database File System. Tra Gnome Storage, WinFS e ora Apple Spotlight sembra che ognuno stia investendo su queste feature. Ma cos'è un database file system e perché è così importante? Cercherò di rispondere a queste domande e fornire una buona spiegazione su come un moderno Database File System possa essere strutturato.



Definire il Problema


Nella vita di tutti i giorni tendiamo a tenere traccia delle cose tramite associazione. Per esempio io so che il conto che ho ricevuto dalla compagnia della carta di credito è sia una bolletta e che una ricevuta dalla compagnia della carta. Quindi se io volessi trovare quella ricevuta ancora, ma non mi ricordassi che cosa ne ho fatto? Allora probabilmente andrei a controllare le mie bollette per prima cosa, poi forse guarderei in un raccoglitore dove tengo le mie vecchi carte di lavoro, poi sul mio tavolo, poi forse in qualche posto che posso aver accidentalmente dimenticato. Notate le associazioni qui:



  1. Tutte le bollette

  2. Carte del lavoro archiviate

  3. Documenti recenti sul tavolo (Recent Desktop Documents)

  4. Ricerca in aree usuali


Queste associazioni sono una forma di “meta-dati” o “dati riguardanti dati”. Di solito non consideriamo questa informazione importante come i dati stessi, ma senza non potremmo neanche trovarli i dati!


Ora supponiamo per un momento che la nostra mitica ricevuta delle carta di credito ci sia stata consegnata elettronicamente, se inoltre supponiamo che l'abbiamo tenuta in un file su un disco allora la domanda che sorge spontanea è: Dove la mettiamo così che è facile trovarla?


Opzioni incluse:



  1. Nella cartella “Bollette” è probabilmente una buona idea tenere tutte le bollette insieme. In questo modo sappiamo dove trovarne una quando ne abbiamo bisogno

  2. In una una cartella “Documenti Archiviati” la bolletta sarà già sistemata e pagata. Perché non archiviarla solamente e tenerla alla larga?

  3. Sul Desktop. Dopotutto è un file importante, giusto? Così questo file importante andrebbe in qualche posto dove si nota.


Come hai potuto notare tutto ciò è molto simile alle problematiche che affrontiamo nel mondo reale. La differenza è che un computer dovrebbe essere in grado di fare molto di più per aiutare ad organizzare l'informazione che stiamo semplicemente piazzando da qualche parte dove speri sia ovvio.


Sino a un certo punto il il computer può aiutare. Se perdo traccia di ciò che ho fatto con la bolletta, poi posso tentare di cercarla. Il computer allora cercherà attraverso ogni file nel sistema cercando di trovare cosa abbiamo perso. Il problema con questo tipo di ricerca è che comunque il search può solo funzionare quando ho il nome del file. Se sono stato pigro e ho chiamato il file “Bolletta C.C.” allora no mi tornerà come risultato in una ricerca per “Carta di Credito”.


Meta-Data


E se potessimo migliorare la situazione presentata precedentemente? Per esempio se potessimo mettere la ricevuta nella cartelletta Bollette, nella cartella Documenti Archiviati e sul desktop simultaneamente? Che ne dite se potessimo cercare dentro il documento per le informazioni che contiene? E se il computer potesse intelligentemente dare dei punteggi ai file che trova in una ricerca e ordinarli in base ai file che pensa possano essere i più indicati? Con i meta-dati estratti da un database file system tutto ciò diventa possibile.


Parlando genericamente ci sono tre tipi di meta-data che un sistema è in grado di supportare:



  1. Meta-dati intrinseci

  2. Meta-dati applicati dagli utenti

  3. Meta-dati organizzativi


I Meta-dati intrinseci sono dati che possono essere derivati dall'esistenza stessa del file. A livello più semplice questo include cose come il dato che fu creato e le sue dimensioni. Schemi di meta-dati più complessi possono attualmente immergersi nel flusso dei dati di un file binario e estrarre ulteriori meta informazioni assegnate a quel file. Questo dovrebbe essere semplice come il testo di un documento di un word processing o complesso come il nome di un film o l'artista di una canzone. Senza dubbio migliore è il sistema a capire i file, più utile sarà l'informazione che potrà estrarvi.


I Meta-dati applicati dagli utenti sono dati che il computer ha aggiunto al file in modo esplicito. Per esempio io potrei scrivere una nota in un campo meta-data dicendo che ho bisogno di ricordare che questa bolletta scade il 28 febbraio anziché dell'usuale 30 del mese. Questa informazione può essere spesso molto utile ma può essere difficile convincere gli utenti a perdere tempo per applicarla.


I Meta-dati organizzativi sono una via di mezzo tra due tipi precedenti di meta-data. E' il tipo di dato che un utente potrebbe aggiungere al file con lo scopo di una migliore organizzazione e in questo modo diventa un attributo organizzativo che può essere interrogato. Per esempio diciamo che io voglia ordinare le bollette sotto un meta-tag chiamato “Bollette”. E diciamo che io abbia un tag per ogni compagnia di carta di credito così che io possa facilmente trovare corrispondenze con loro. Adesso ho aggiunto i meta-dati al file che dicono al sistema che il documento è una Bolletta che proviene da una Azienda di una Carta di Credito A!


Via il Vecchio, Dentro col Nuovo


La chiave di un database file system è che i meta-dati attaccati ai file ci forniscono un metodo migliore per cercare le cose. La teoria è che se le ricerche diventano abbastanza buone i metodi tradizionali per accedere ai file possono sparire tutti insieme. Invece di sfogliare tra i folder l'utente può semplicemente digitare “Bollette” e ottenere una lista di tutte le bollette memorizzate nel sistema. O l'utente può restringerla e chiedere “Bollette dalla Carta di Credito della Compagnia A” e ricevere una lista di risultati più specifici. La chiave che la ricerca riporterà sempre ciò che l'utente necessita, ma in un modo molto più veloce di una ricerca manuale da parte dell'utente.


Questo significa che i folder spariranno tutti insieme? La risposta è sì e no. No, i folder tradizionali non saranno così, utili ma allo stesso tempo è occasionalmente bello essere in grado di sfogliare le informazioni contenute sul proprio sistema.


La sostituzione ha due facce. La prima parte della soluzione è permettere all'utente di salvare le interrogazioni di ricerca in uno pseudo-folder. Questo fornisce all'utente una facile e automatica organizzazione dei suoi file. Per esempio potrebbe salvare una interrogazione di ricerca per cercare tutti i film. Così quando desidera sapere quali film esistono sul suo sistema può semplicemente aprire questo pseudo-folder e vedere i risultati della ricerca!


L'unico problema nell'usare interrogazioni salvate è che senza i folder regolari sarebbero persi fino a quando si è in grado di creare un'interrogazione per trovarli. Quindi un'altra soluzione è necessaria.


La seconda parte è un concetto conosciuto come Etichette. Le etichette sono un tipo di meta-data che ricade nella categoria Organizzativa. L'idea è che tu puoi creare quante Etichette vuoi nel tuo sistema e applicarle individualmente ai file. Come i file saranno muniti di etichetta appariranno automaticamente in uno pseudo-folder che mostra il nome dell'etichetta. I file senza una etichetta appariranno in un'area che mostra file non collegati. Questa lista non solo assicura che l'utente non perderà mai i suoi file, ma anche lo incoraggia ad etichettarli propriamente. E siccome un utente può applicare e togliere quante Etichette vuole ci sarà meno bisogno di assicurare in anticipo un'accuratezza organizzativa.


Il concetto può anche essere esteso nelle comuni metafore in uso oggi. E se il Desktop non fosse più un folder per i file, a solamente una serie di etichette standard? I file potrebbero essere facilmente messi sul desktop e rimossi solamente rimuovendo l'etichetta! I file potrebbero essere cestinato con una'Etichetta chiamata “Trash”. Centinaia di usi potrebbero saltare fuori per facilitare l'interfaccia utente solo perché un miglior metodo organizzativo esiste! Questa è la ragione per cui i database file system sono considerati il futuro dei file system.


Riferimenti:


Wikipedia: File Systems

Practical File System Design with the Be File System (1999)

Spotlight Technology Brief

DBFS for KDE

Microsoft WinFS

La distribuzione Linux Desktop del Futuro Parte 1

Questo articolo, strutturato in quattro parti, propone alcune riflessioni su come potrebbe funzionare un futuro Desktop Linux. L’articolo non ha la pretesa di essere esaustivo, sebbene l’autore consideri “fattibili” tutti i concetti esposti.


Parte 1: Linux e il Desktop di oggi

Parte 2: Applicazioni

Parte 3: File Management

Parte 4: L’Interfaccia Desktop




Parte 1: Linux e il Desktop di oggi


Malgrado annunci del tipo “Questo sarà l'anno del Desktop Linux” si susseguano ormai da tempo, questi auspici non si sono ancora trasformati in realtà. Le motivazioni sono numerose, ma tutte si ricollegano al fatto che Linux nasce come sistema operativo per server e workstation piuttosto che come soluzione per uso domestico. Questo articolo si occuperà nel dettaglio di come una distribuzione potrebbe essere progettata per rendere competitiva una soluzione Linux Desktop, ma anche come spingerla a diventare leader nel mercato dei computer casalinghi.


Le debolezze di Linux

Una veloce occhiata alle feature di Linux permette di stilare una lista delle problematiche che rendono di Linux una scelta inadeguata per un uso generico in ambiente desktop:



  1. Installare applicazioni è complicato

  2. La struttura delle directory rende la navigazione poco agevole

  3. L'interfaccia è disordinata e incoerente

  4. La comprensione delle funzioni di sistema richiede una curva di apprendimento troppo elevata


Il primo punto è una questione complessa, ma dipende soprattutto dall'uso dei package manager tipici di Linux. La gestione dei pacchetti è uno di quei concetti che sembra grandioso all’inizio, ma che poi fallisce nella pratica. Il problema è che ogni pacchetto ha una complessa quanto specifica catena di dipendenze, e per garantirne la compatibilità con tutte le installazioni è necessario seguire test su tutte le possibili combinazioni! È quindi improbabile che tutti gli utenti siano disposti ad affrontare così tanti problemi, le incompatibilità tra i pacchetti si accumulano, e alla lunga il sistema di gestione dei pacchetti rifiuta le nuove installazioni. Dando ovviamente per scontato che sia disponibile un'interfaccia grafica per le installazioni!


Qualora non fosse presente un installer grafico, la vita per l’utente finale potrebbe complicarsi ulteriormente. Invece di lanciare una GUI (Graphical User Interface) e selezionare le applicazioni desiderate, l'utente dovrebbe aprire un terminale e iniziare a digitare oscuri comandi per i quali non ha nessuna preparazione.


Molti sostenitori dei sistemi a pacchetti minimizzano questo tipo di problema affermando che non esistono gli errori di pacchettizzazione sul sistema XYZ - nonostante l’evidenza dimostri l’esatto contrario - e che se un l'utente sta usando Linux dovrebbe anche essere sufficientemente ”sveglio” per operare da linea di comando. Si tratta di affermazioni semplicemente prive di logica. Gli utenti pretendono che un computer semplifichi loro la vite, e ogni ostacolo che si presenta sulla loro strada non farà altro che condurli verso un'altra piattaforma. La maggior parte delle distribuzioni Linux per desktop sono purtroppo ancora oggi gestite da package manager.


Una certa disorganizzazione nella disposizione dei file di sistema di Linux è la causa della problematica numero due. Il sistema scelto mira a semplificare l'aspetto multi-user dei sistemi Unix, ma sfortunatamente contribuisce a complicare di molto la visualizzazione del sistema da parte dell’utente. Chi ha una certa dimestichezza nell’uso del computer, sa di doversi occupare della directory sulla root e delle sue due cartelle di sistema, ma per utenti alle prime armi anche la presenza di un solo system folder può rappresentare un enorme problema. Sono sicuro che tutti abbiano visto, o sentito parlare almeno una volta di qualcuno che, dopo aver cancellato la sua cartelletta Windows, si aspettasse di vedere l’intero sistema funzionare ancora correttamente. Pretendere che questi stessi utenti siano in grado di capire il significato oscuro di cartelle come “usr”, “bin” e “etc” è forse chiedere troppo. OS X Finder, in effetti, le nasconde alla vista degli utilizzatori.


I problemi collegati ai punti tre e quattro sono invece una conseguenza di alcune decisioni piuttosto interessanti prese nell’ambito della comunità OSS (Software Open Source), delle continue discussioni riguardo al design dell'interfaccia, e delle qualità delle versioni beta dei software da includere nelle release delle distro in cui è coinvolta in prima persona Red Hat. In Windows, per esempio, è presente un’unica cartella non nascosta che raccoglie tutti gli shortcut del menu Start Avvio. L’accesso a questa cartella avviene con un clic del pulsante destro del mouse su Start e quindi sul comando “Esplora”. Sebbene il progetto grafico dell’interfaccia utente di Windows non brilli certo per chiarezza, almeno è coerente. In GNOME e KDE, invece, la cartella che ospita il menu è stata spostata più volte, sballottata a turno tra il GUI Tree, il File Explorer e l’interfaccia Drag/Drop-on-the-menu responsabile delle modifiche, e ogni ambiente proponeva le sue regole su quali specifiche voci di menu potevano essere create dall’utente. Molte di queste controversie sono state in parte appianate, senza però migliorare lo stato di confusione in cui si trova a operare l’utente.


Alla luce ci queste problematiche, ecco alcune considerazioni su come potrebbero essere risolte.


(Continua a Pagina 2)


Riferimenti:


Making desktop Linux software installation easy

The Year of the Linux Desktop: 2003

2004: The Year of the Linux Desktop?

2004 Won't Be the Year of the Linux Desktop

2005 Will Be the Year of the Linux Desktop

Desktop Linux News, Articles, and Forums