[SpatialBundle building the FAQ ] 8 - Rendere eseguibile lo SB è cmq un passo in più, non c'è modo di avere un "repo" fidato?

Felipe Pollycoke ha posto la seguente domanda:

D: Rendere eseguibile lo SB (ndr SB=SpatialBundle) è cmq un passo in più, non c'è modo di avere un "repo" fidato?

R: La risposta è Si! Ma perchè praticamente con i bits si può fare tutto (informaticamente parlando)...diffida da chi dice no :)
Divido la domanda in due parti:

8a) "Rendere eseguibile lo SB è cmq un passo in più" ... è necessario?
Si e no.
Il concetto generale è meno clic fai meglio stai.
Quando scarico un file potenzialmente eseguibile è giusto che venga osservata un'azione responsabile ed il più cosciente possibile da parte dell'utilizzatore.L'azione di aggiungere l'eseguibilità potrebbe aiutare a riflettere.
Il problema principale è che i miei tester hanno sempre difficoltà a capire il concetto e sopratutto a trovare il modo di modificare l'attributo.Questo è un problema da risolvere.
Quando scarico un .exe su Windows posso tendenzialmente eseguirlo inpunemente, con uno SpatialBundle no.E' nativamente anti clic isterico.Le versioni di Vista che ho testato hanno introdotto una grande diga a proposito e paradossalmente è diventato quasi meno usabile di Linux, ovvero bisogna in qualche modo esplicitare l'esecuzione del file con una finestra grafica.Immagino Windows 7 ereditare questa features/bug/annoyance.
Ad esempio Nautilus quando intercetta uno script shell eseguibile opera un feedback simile fornendoti un menu più verboso dove puoi scegliere se aprire con un file testo o eseguire lo script.E' ancora una soluzione molto tecnica, però è uno sbarramento che può far riflettere (il problema è che il target di quel messaggio è una regione di popolazione informatizzata molto ristretta).
Complessivamente un file senza attributo eseguibile viene visto come un ramo secco e se questo è un file script testuale può essere anche risolto strambamente con un mime su un editor testi.
Per risolvere il problema ci vuole un supervisor fornito dal distro vendor, dal DE vendor o dal SpatialBundle vendor.
Il progetto GNOME fornisce un timido supervisor sui script eseguibili, ma non è sufficiente.
Una soluzione elegante potrebbe essere espressa da un fornitore fidato di software tramite un canale sicuro...
A titolo di esempio i "repo" di Debian e Ubuntu (esempio anche i PPA) sono fornitori fidati :)

8b) non c'è modo di avere un "repo" fidato?

Si.
Questo sarebbe il passo successivo dopo il rilascio dello SpatialBuilder 1.0
Ora a titolo sperimentale il "repo" fidato è il mio deposito su sourceforge (con i suoi limiti).
Bisognerebbe esplicitare tutti gli attributi che definiscono la parola "fidato" associato a "repository".
A tal proposito vi invito a commentare sotto e fornire elementi di discussione.
Quando immagino un deposito fidato mi vengono in mente delle persone responsabili che compilano dei sorgenti verificati.
Che impacchettano secondo delle lineee guida standard.Che espongono i pacchetti su un server sicuro.Che forniscono metodi di controllo dell'integrità dei dati.Che forniscono un canale trasmissivo sicuro.Che forniscono metodi e attributi per permettere all'utilizzatore di verificare l'autenticità della sorgente del catalogo...etc etc.
Potenzialmente un ambiente basato su apt può essere tutto questo e di più.
Immagino che quando si parla di fiducia bisogna considerare più gli aspetti scientifici verificabili che la fede basata su elementi emozionali.Anche se c'è sempre un limite a tutto ciò.
Massimizzando le tecniche verificabili rimane solo la parte legata alla fiducia (in fondo chi mi garantisce che il maintainer non introduce un piccolo spy nascosto in 30mila linee di codice?).
A titolo di esempio una parte di questo problema vuole essere risolto all'interno della comunità NetBSD dove esiste un team di revisione del codice che in qualche modo cerca di minimizzare questo potenziale latente.
Non a caso le mie prime compilazioni utilizzavano il repository dei sorgenti di NetBSD proprio perchè si possono ritenere sicuri a livello di sorgente (non al 100%).
Il problema del repo di NetBSD è che segue in parte la filosofia del live filesystem di gentoo quindi bisogna tribolare un pochino per isolare i pacchetti con le dipendenze risolte con lo stesso standard di sicurezza da loro offerto.E' un problema che loro conoscono bene e che pian piano stanno risolvendo.
E' molto probabile che nel futuro Debian dovrà in qualche modo ereditare molte delle tecnologie che verranno introdotte dall'ambiente Pkgsrc di NetBSD.

L'utilizzo di apt attualmente richiede root.Ho provato in vari modi a scardinare apt da root ma è nativamente e fisiologicamente progettato per funzionare da root (per certi versi questo volere è intrinsecamente hardcoded), tutti i miei tentativi hanno prodotto fork (concetto DEPRECATED per me).
Se dovessi immaginare un ambiente misto con un repo fidato di SpatialBundle basato su apt, cercherei di limitare al massimo l'intervento root a questi passi:
1) Uso da parte dell'utente di un catalogatore tipo synaptic o forse meglio qualcosa di simile a Gnome App Install (immagno anche un fantascientifico addon/plugin di songbird).
2) Scelta dello SpatialBundle
3) Clic + password di amministrazione (tipo sudo con Ubuntu)
A questo punto il deb dovrebbe semplicemente memorizzare lo SpatialBundle in un punto di ingresso esplicito comune a tutti tipo: /home/Applications
quindi cambiare l'owner del SB in Applications , aggiungere il bit eseguibile allo SpatialBundle e permettere a tutti nel gruppo Applications di eseguirlo.
Immagino quindi che nelle home di ogni utente venga prodotto un link simbolico alla folder /home/Applications
Qui finisce l'intervento di apt e di root.Che si è limitato a scaricare in modo "fidato" e presentare in modo consistente ed usabile lo SpatialBundle agli (ma alla fine al) utenti(e) del computer.
Consistente perchè gli SpatialBundle del catalogo "fidato" sono in /home/Applications (utente di comodo ristretto), perchè lo script di post install nel deb provvede in modo "fidato" ad aggiungere il bit eseguibile e verificare e/o costruire il link simbolico dalle cartelle utenti al deposito locale.Tutto questo mantenendosi largamente isolati dal filesystem root (no /usr no usr/bin etc etc) e rispettando sicuramente lo standard del UNIX FHS (nelle $HOME faccio quello che mi pare in fondo).In questo modo comunque si preserva l'intervento di root eseguendo lo SpatialBundle con i diritti di gruppo dell'utente Applications.Rimane consistente perche lo SpatialBundle in qualità di singolo file può essere clonato nel proprio spazio dei file (la $HOME o una chiavetta USB o un CDROM o via mail o altro).
Gobo Linux, ROX, OSX e altri hanno dimostrato che questa strada in qualche modo e con le dovute riserve è percorribile.
Una volta in qualche lista avevo proposto una soluzione al pari di itunes per il software Linux basandolo su apt, sono stato largamente ignorato e deprecato (in ubuntu brainstorm ampiamente votato contro).Poi son usciti fuori Gnome App Install ed in giro tutta la serie degli AppStore a partire dal famigerato telefono della mela morsicata.Oggi un App Store associato ad un software di presentazione è la cosa più naturale che ci si aspetta su un dispositivo...quando noi viviamo da sempre in questo ambiente controllato, verificato e fidato (tutti i repository Linux/BSD sono degli appstore a costo zero).
A mio avviso oggi più che mai un repo "fidato" di oggetti come gli SpatialBundle hanno un grande senso, mentre perde sempre più senso un catalogo come apt per le applicazioni desktop che sporca il filesystem root.

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

NOMINATE COMMUNITY CHOICE AWARDS