Che problemi c'erano?
Non lo so che ancora non usavo Chakra.
- Prestazioni: i bundle erano sensibilmente più lenti rispetto ai pacchetti standard;
- Dimensioni: dovendo contenere tutto ciò che serve al software per essere eseguito, erano più pesanti dei pacchetti standard;
- Ridondanza: più bundle contenevano la stessa versione di una stessa libreria;
- Integrazione: sia dal punto di vista grafico che dell'interazione con il sistema.
Probabilmente il punto 1 sarà sempre meno un problema, considerando il trend di diffusione degli SSD e l'aumento generale delle prestazioni e per quanto riguarda il 4 gli snap dovrebbero fornire una migliore integrazione a livello di sistema (mi riferisco più che altro agli eseguibili).
Il 2 è un problema serio (rispondo anche ad @alex): per fare un esempio, lo snap di LibreOffice 5.2-beta pesa 1 Gb, contro i 229 Mb del deb: immaginate quanto potranno pesare gli snap di applicazioni già di per sé più grandi di LibreOffice. Lo spazio non è un problema se si usano dischi HDD, ma per gli SSD il prezzo/Gb è ancora troppo alto per rendere accessibile a tutto l'acquisto di dischi con capacità superiori ai 480GB.
Inoltre, tenere la cartella /tmp sulla RAM (come faccio io) diventerebbe possibile solo con enormi quantitativi di memoria.
Il 3 accadrà anche con gli snap: possiamo considerarlo un compromesso.
beh Franz, una piccola differenza c'è: i bundle erano un mondo chiuso e a parte di Chakra. Gli snap sembra che al momento stiano riscontrando molto interesse in tutta la comunità linux, arcieri compresi (fatto fondamentale).
Chiuso non direi, visto che il codice è sempre stato (ed è ancora) a disposizione di tutti.
Chakra, te lo ricorderai, era nota per il sistema dei bundle, ma non mi pare che venissero considerati una gran cosa; adesso invece sembrano l'invenzione del secolo.
Tra parentesi, Arch non li supporta ufficialmente: il porting è stato fatto da alcuni utenti e, infatti, è su AUR.
Avere quindi un'infrastruttura in grado di gestire gli snap (come sta cercando di fare gnatyle) renderà la vita facile a chi vorrà installare pacchetti di terze parti o pacchettizzarsene uno.
A prescindere dal fatto che alcuni GTK vengano messi o meno in snap, il fatto di poterli utilizzare IMHO è fondamentale per mantenersi al passo con altre distro molto utilizzate.
Questo indubbiamente, non sto mettendo in dubbio l'utilità del lavoro di gnastyle.
Quello che non mi convince è il sistema in sé e personalmente non credo che Chakra dovrebbe supportarlo ufficialmente
Ma se le applicazioni sono rese più indipendeti dal resto del sistema serve comunque metterci mano?
Se vuoi applicare delle patch o delle ottimizzazioni che chi ha realizzato lo snap non ha previsto, sì.
Ad esempio, noi applichiamo una serie di patch a Firefox per l'integrazione con KDE, il motore di ricerca, ecc., che sicuramente Mozilla non includerà.
Stesso discorso per LibreOffice, o per altre applicazioni nelle quali disabilitiamo i componenti gtk. Per tutte queste andrebbero comunque ricreati gli snap.
leggevo che se delle librerie sono già usate da uno snap non vengono aggiunte di nuovo ma solo linkate. Non so però se attualmente già lo faccia o se è una cosa che si vuole implementare in futuro.
Se le librerie sono incluse nello snap, questo deve essere montato perché un altro snap possa utilizzarne le librerie, quindi o avvii due snap per usarne solo uno o ne crei uno apposta per la libreria (ma a quel punto non ha più senso lo snap); a meno che gli snap non vengano montati automaticamente all'avvio.
Personalmente penso che sarà difficile implementare questa funzione, ma magari mi sbaglio.
Qui mi sa che è il punto debole per un eventuale adozione da parte di tutto il mondo linux, che diventerebbe troppo ubuntucentrico. Una specie di market gestito da Canonical....
Questo sì che sarebbe un problema, anche considerando che Canonical non sempre si comporta bene con il mondo del software libero
