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
Copyright 2005 © AKAImBatman. Tutti i diritti sono riservati.
Titolo originale dell'opera: The Linux Desktop Distribution of the Future Part 3
Pubblicato d'intesa con AKAImBatman
Traduzione a cura di Mirko Spadaro e Silvia Ponzio
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:
- Una partizione per le librerie principali di sistema, i file di root e /usr.
- 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:
- 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.
- 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:
0 commenti:
Posta un commento