mini FAQ SpatialBundle

Di seguito ho condensato alcuni pensieri della serie: "fatti una domanda e datti una risposta" + opinione personale + domande esterne ricevute.
Questa pagina vuole essere una premessa ad un documento più completo che può essere sviluppato solo con le vostre domande.

1) D: I file di configurazione/personalizzazione di ogni applicazione dove saranno installati?
R: Ogni applicazine decide per se dove installare le configurazioni.
Notoriamente il 99% delle applicazioni Desktop per Linux salvano le configurazioni in una cartella nascosta nella cartella dell'utente (i famosi file e cartelle puntate).
Uno SpatialBundle offre una locazione aggiuntiva posta in $HOME/.config/Infodomestic/Objects che lo sviluppatore può usare a suo piacimento.

2) D: Gli SpatialBundle si propongono come rimpiazzo agli attuali package manager?
R: NO! uno SpatialBundle è cosi indipendente da tutto che lavora in parallelo a qualsiasi sistema di gestione pacchetti, comprese le tecnologie Klik, CNR, 0Install, AutoPackage, PBI e/o Java WebStart
Uno SpatialBundle è progettato per lavorare trasparentemente su Linux, *BSD, Solaris, OSX e Windows
Il primo utilizzo pratico che ho potuto misurare è nella distribuzione delle KillerApp da Desktop tipo firefox, openoffice, sunbird, thunderbird, skype, picasa,acrobat, realplayer etc. etc.

3) D: Che differenza c'è con un file DMG di OSX?
R: L'unica non differenza è un feedback inziale con l'utente dove questo clicca e qualcosa succede.
Un pacchetto DMG è un file immagine compresso che dopo essere stato scaricato va aperto (come fosse uno zip) e poi prelevato il contenuto al suo interno per essere ulteriormente manipolato.
In poche parole un DMG è un contenitore passivo che contiene solo dati.
Uno SpatialBundle è un oggetto vero con funzionalità e caratteristiche attivabili (tecnicamente conosciuti come metodi ed attributi).
Dopo averlo scaricato su uno SpatialBundle ci si clicca sopra e si attende il feedback totale che genericamente si riduce all'esecuzione del programma in oggetto.
Un classica sequenza analoga con un DMG si riduce ai seguenti passi:
1) Cliccare su un link di una pagina web
2) Salvare nel desktop
3) Attendere il download
4) Cliccare sul file DMG salvato
5) Attendere l'autoapertura del file che si presenterà come un'unità disco (ho misurato disorientamento su degli utenti di test)
6) Trascinare l'icona caratteristica del software contenuta nell'unità disco virtuale in una cartella di comodo (notoriamente Applications)
7) Sganciare (smontare) e chiudere l'unità disco DMG virtuale (trascinando nel cestino l'unità o cliccando sull'apposita iconcina del Finder)
8) Aprire la cartella Applications
9) Cliccare sull'icona del programma ed attendere la sua esecuzione.

Ci sono casi dove viene automatizzata la fase che va dal clic sul web all'apertura automatica del disco virtuale DMG spòecialmente se si usa Safari invece che Firefox.

Una classica sequenza con uno SpatialBundle può ridursi ai seguenti passi:
1) cliccare sul link nel web
2) Attendere
3) Usare l'applicazione che si è avviata automaticamente.

L'alternativa più lunga è
1) Cliccare sul link nel web
2) Salvare il file nel desktop
3) Attendere il download
4) Abilitare l'eseguibilità del file (disabilitata per defaults per sicurezza)
5) Cliccare sul file ed attendere l'esecuzione del programma

Come si evince dall'elenco nella peggiore delle ipotesi le operazioni sono estremamente ridotte all'osso.

Dal punto di vista della sicurezza una AppDir in qualità di cartella può essere gravemente danneggiata o modificata.
Uno SpatialBundle con un autocheck interno sha512 non permette il code injection rendendolo praticamente invulnerabile a malware e virus per non parlare di middle man o manipolazioni di qualsiasi sorta.

4) D: Che differenza c'è tra una directory AppDir di OSX ed uno SpatialBundle?
R: Quando un utente clicca su uno Spatialbundle o su un AppDir di OSX riceve praticamente lo stesso feedback, ovvero in genere l'avvio dell'applicazione sottesa.
La vera differenza è nella manipolazione dell'oggetto dove nel primo caso è una cartella mascherata nel caso di uno SpatialBundle è un file vero manipolabile in modo trasparente da tutti i sistemi operativi destkop attualmente in circolazione.
Un esempio su tutti: se devo inviare il programma ad un amico per posta con uno SpatialBundle è sufficiente allegare il file e spedirlo, con un AppDir no in quanto è una cartella e quindi bisogna prima creare un archivio (tipo un file compresso zip) e poi allegare il file, il ricevente in quel caso deve svolgere l'operazione simmetricamente inversa, mentre con uno SpatialBundle deve limitarsi a cliccarci sopra ed eseguirlo.
Uno SpatialBundle è molto più pratico di un AppDir.
Un'AppDir non rappresenta necessariamente tutta l'istanza dell'oggetto di interesse in quanto potrebbe essere anche funzione di un'installazione e quindi una parte dei metodi e attributi potrebbero risiedere in altre parti del filesystem.
Uno SpatialBundle è sempre un oggetto autoconsistente ed integro, completamente individuabile ed isolato dal resto del sistema.Esso sfrutta la filosofia nativa e dirompente dello stile UNIX...tutto è un file.

5) D: In Mac OSX con il tasto destro su un AppDir posso esplorare il contenuto della cartella, come entro in uno SpatialBundle?
R: Uno SpatialBundle essendo pensato come un oggetto vivo, è costituito da metodì ed attributi che si possono interrogare.
E' sufficiente eseguire: NomeBundle --help per ricevere un elenco di ulteriori informazioni che comprendono ad esempio anche tags e labels associati al bundle nonchè la capacità di estrarre l'icona rappresentativa.
Se si vuole entrare nella gerarchia dei file che rappresentano l'applicazione integrata è sufficiente entrare in /tmp/Programs per accedere in modo trasparente e senza limiti di lettura alla cache di memoria (che viene eliminata ad ogni reset forzato del Bundle o ad ogni riavvio della macchina).

6) D: Qual'è la tua visione di un ecosistema basato sugli SpatialBundle?
R: Attualmente vedo molto pratica la coesistenza tra un catalogo basato su apt come i repository offerti dall'ambiente Debian ed un catalogo web e/o locale basato su SpatialBundle indicizzati da tracker & co.
Mi piacerebbe costruire una distribuzione minimale al massimo costituita da una base LSB + X + un DE ridotto all'osso per fornire il minimo di funzionalità tutto gestito da apt sul quale poi fornire un catalogo di applicazioni SpatialBundle.
In questo modo apt può concentrarsi esclusivamente sull'aggiornamento del sistema minimo che deve essere garantito dal vendor della distribuzione e poi multipli vendor in stile AppStore che forniscono SpatialBundle indipendenti.Tutto condito e gestito da firme digitali, certificati vari, e tutto quello che serve per garantirsi l'integrità e le veridicità della sorgente del catalogo, nonchè del canale trasmissivo.
In questo modo si possono separare e redistribuire anche le responsabilità del sistema di packaging delle user applications.Complessivamente immagino un aumento sicuro di entropia nell'ecosistema, ma anche una migliore selezione darwiniana nonchè fondamentale per il mio punto di vista, un sempre più decentralizzazione e quindi redistribuzione del potere.
Oggi una distribuzione Linux (esempio Fedora o Ubuntu) opera a tutti gli effetti pratici un controllo monopolistico ed assolutistico su tutta la fase del processo che va dalla generazione della distribuzione allo sfruttamento della stessa da parte degli utilizzatori finali.
Questo sistema ha grossi vantaggi, è sufficiente controllare la qualità del codice di NetBSD o PCBSD per capire che può funzionare ma paradossalmente può considerarsi molto più democratico un qualsiasi sistema operativo Windows!!! Che praticamente, anche se in modo controproducente, permette a tutti di costruire e distribuire software e di conseguenza anche distruggere tutto il sistema in una specie di grande eutanasia digitale.
Penso che un buon equilibrio tra un gestore centralizzato ed un sistema decentralizzato ma verificato può aiutare a creare vera innovazione nel mondo dei sistema operativi liberi.

7) D: Come si confronta complessivamente un file Klik con uno SpatialBundle?
R: Attualmente un file klik è solo un'ipotesi sul web che viene intermediata da uno script proxy locale che provvede a scaricarlo in modo pseudo trasparente e poi manipolarlo localmente.
Da questo punto di vista uno SpatialBundle è un vero file manipolabile e disponibile subito presso:
https://sourceforge.net/project/showfiles.php?group_id=199098
come un elenco discreto di files nudo e crudo da scaricare.Quando è stato scaricato si osserva e manipola un file come succede da sempre su qualsiasi desktop.Niente di nascosto, un sempice file da scaricare e da cliccare.
Dal punto di vista del design uno SpatialBundle non deve chiedere mai la password di root se lo fà rifiutatevi ed eliminatelo subito.
Uno SpatialBundle è progettato nativamente per essere eseguito in modalità non amministrativa, questo per massimizzare la garanzia di integrità del sistema ospitante.
Nel design e nello spirito dello SpatialBundle la password di root è delegata alla sola amministrazione globale del computer.
Ritengo complessivamente l'accesso come root assolutamente deprecabile.
Dal punto di vista del design di uno SpatialBundle un pacchetto Klik è visto al pari di un virus o di un pacchetto deb ovvero può essere abilitato a manipolare anche lo spazio root.
Le implementazioni dei proxy Klik generalmente richiedono un accesso iniziale root per installare il client, questo punto di vista è deprecato dal design di uno SpatialBundle.
Uno SpatialBundle si scarica e si esegue, un Klik necessita di una preinstallazione di un componente di aiuto per manipolare un file klik.
Quando eseguo uno SpatialBundle come utente normale il 99,99999% dei casi ho la certezza fisica che il filesystem root non verrà mai e poi mai toccato.Questa garanzia non viene fornita dal sistema Klik e le azioni tendono a basarsi sulla fede (ma il client installato da root installa anche librerie non previste dal repository fornito dal distro vendor?)
Uno SpatialBundle non tenta di usare prima le librerie di sistema e poi eventualmente installare le proprie.In questo caso il pachettizzatore di uno SpatialBundle è responsabile in solido della qualità del pacchetto per le distribuzioni in suo target (teoricamente un pacchetto SpatialBundle può operare in modo trasparente su BSD, Linux e altri).
Sotto questo punto di vista uno SpatialBundle si comporta molto similmente ad un Universal Binary di OSX ovvero integra in seno la soluzione trasparente senza necessità ulteriori.
Uno SpatialBundle è progettato per funzionare sempre anche in assenza di rete, un file klik potrebbe non funzionare se deve risolvere le dipendenze.
Il design Klik favorisce il minimo sforzo allo sviluppatore (dipendenze risolte a runtime autoadattandosi in funzione delle valutazioni operate in loco dagli algoritmi di risoluzione, lo sviluppatore si solleva la responsabilità di eventuali fallimenti).
Il design SpatialBundle favorisce il minimo sforzo all'utilizzatore (dipendenze soddisfatte nativamente dallo sviluppatore responsabile che risponde in solido del fallimento).
Il parco software di SpatialBundle è ridicolo se confrontato con quello di Klik ma il compilatore/builder SpatialBuilder non è stato ancora rilasciato e quindi attualmente genero in prima persona pacchetti di KillerApp per testing.
Ogni SpatialBundle viene accompagnato da 4 file checksum di integrità (cksum, md5sum, sha1sum e sha512sum).A questo va aggiunto un autochecksum con sha512sum interno ogni volta che viene eseguito (se c'è stato code injection si blocca prima di eseguire il programma incorporato).Ogni binario e libreria del programma integrato viene accompagnato dal suo equivalente file sha512um.Ho previsto in futuro l'integrazione del controllo della firma digitale di autenticità della sorgente del deposito software ed altre amenità simili.

...to be continued