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 2
Pubblicato d'intesa con AKAImBatman
Traduzione a cura di Mirko Spadaro e Silvia Ponzio
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
La 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:
- 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.
- 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.
- Linux non offre un buon metodo per notificare ai programmi i cambiamenti avvenuti in file e directory.
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:
0 commenti:
Posta un commento