News,Development Resources,Featured Content

receive news by mail:

Loading SpatialBundles Download list...

[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.

blog comments powered by Disqus

Etichette

Latest Releases

Starred items

Flash On The Air

Subscribe to Mailinglist

Panel

.

HCCard OpenID ClaimID

Contact Infodomestic | Terms of Use | Privacy Policy

Copyright © 1994-2011 Infodomestic.com All rights reserved.