Newsgroup: it.comp.os.linux.debian
Titolo: Il formato pacchetti SNAP sarà adottato anche da debian?

Visto che si affaccia sul mondo ubuntu, debian, supporterà questo
sistema di installazione dei programmi?
 

 sistema di installazione dei programmi?
 
Come puoi leggere qui
https://tracker.debian.org/pkg/snapd
 
per ora snapd resta nei repository della Debian unstable.
 

 per ora snapd resta nei repository della Debian unstable.
 
Scusate la domanda forse banale, ma già i pacchetti *.deb mi sembra 
andassero più che bene, si tratta della solita guerra di religioni tipo 
*.rpm VS *.deb etc. o c'è una reale miglioria in questo nuovo formato?
 
Saluti.
GabrieleMax
 


Ho dato un occhiata velocemente e non sembra niente di nuovo sotto il sole,
mi sembrano i vecchi programmi windows che per non farsi mancare niente si portavano dentro tutte le dll di visualbasic e
anche alcune librerie di sistema giusto per non sbagliarsi!!
 
Giulia
 
 

 ha scritto:

L'unico vantaggio è scaricare un solo file, anche se di dimensioni maggiori,
piuttosto che stare in rete collegato. Se fosse adottato da tutti i linux
sarebbe un reale vantaggio per il mondo dell'open source perchè darebbe un bel
segnale di maturità. Vedremo.
 

 segnale di maturità. Vedremo.
 
Non la vedo allo stesso modo.
 
Sto lavorando su un Mac, dove questo modo di distribuire programmi è lo 
standard, e con 16 GB di RAM a volte arrivo al limite, perché ogni 
programma ha la sua versione di ogni libreria in memoria.
 
Gli stessi software sotto Linux non arrivano a occupare 4 GB, perché le 
librerie sono condivise.
 
Capisco la comodità di aggiornare i software uno a uno senza rischi di 
conflitti, ma significa anche che molti li devi aggiornare a mano, 
perché non tutto è nello store.
 
Può andare bene per 2-3 software closed source, ma per i software open 
source, secondo me, è un passo indietro notevole.
 
Bye.
 

 source, secondo me, è un passo indietro notevole.
 
Concordo.
 
 
Ciao,
  Void

 source, secondo me, è un passo indietro notevole.
 
Questo e' da capire e valutare in Linux, potrebbe essere ottimizzato e non così.
In effetti nello scenario prospettato complessivamente le prestazioni
degraderebbero. 
 

 Perchè ne dovrebbe caricare 2 o più?
 
Per lo stesso motivo per cui certe applicazioni JAVA si portano in pancia un intero JRE,
software scritto alla cazzo che funziona "di culo" solo con quella libreria,
e devo dire tipico del close source visto che nell open c'e sempre (su 7 miliari di anime) un cretino
che va a fondo del problema e cerca di risolvere quello che il programmatore originale ha tralasciato.
 
Giulia
 

 mano...
 
No. SNAP nasce per evitare di gestire le dipendenze, inglobandole tutte 
(non solo librerie, ma anche icone, documentazione, file di config, ecc.) 
in un unico pacchetto.
 
Bye.

 in un unico pacchetto.
 
  Il che annulla la più importante funzione e ragione di esistere delle
librerie dinamiche/condivise.
 
 
  Ciao,
 
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 in un unico pacchetto.
 
  Questa cosa mi ricorda il DOS che, ai tempi, venne "superato"
nell'entusiasmo generale dai sistemi che gestivano loro le
periferiche... dall'alto della mia inesperienza mi sto sbagliando oppure
si sta tornando ai santi vecchi? 
 
  Un saluto,
 
-- 
Gianfranco Bertozzi

>  il S.O. non può sapere
 
Mi immagino che potra sempre esistere un meccanismo di deduplica se non al livello software (confrontare i manifesti di ogni 
libreria) almeno al livello di paginazione hardware della memoria,ma a questo punto io VOTO per la compilazione statica
totale (dalle libc fino a qt/vulcan/opengl) avrebbe molto piu' senso.
 
Giulia
 
 

 si sta tornando ai santi vecchi?
Il dos al massimo permetteva gli overlay (che oltretutto non mi sembra fossero gestiti dal SO),
quindi direi un bel DOS con 50000 volte piu ram.
 
Giulia
 
 

 Questo e' da capire e valutare in Linux, potrebbe essere ottimizzato e non così.
 
  Come ottimizzeresti il fatto che ogni applicativo si installa le sue
proprie librerie (=spazio su disco occupato inutilmente) e in esecuzione
si carica in RAM le sue proprie librerie (=spazio in RAM occupato
inutilmente) fregandosene della possibile presenza di librerie
compatibili già installate da altri pacchetti?



  Vero.  Se le cose stanno com'è stato scritto, la presenza delle
librerie dinamiche in ciascun pacchetto software è inutile; tanto vale
compilare tutto in un unico megablob statico.  Che è infatti quello che
Ubuntu fa con i kernel di Ubuntu Touch: non esistono moduli, tutti i
driver sono compilati staticamente nel kernel.  Quello che c'è c'è, per
il resto ti attacchi al tram.  E ovviamente non puoi più neanche
scaricare/mettere in blacklist qualche modulo che non vuoi.  Bel
"progresso".


 ram.
 
  Io mi riferivo alle installazioni, non alla gestione della memoria.
Quando usci' windows sembrava una rivoluzione il fatto che il sistema
operativo si occupava di tutto ('Finalmente! Non si deve reinstallare
la stampante ogni volta!')... mi pareva di avere inteso che ora si sta
tornando indietro. :-)


 ha scritto:

https://redtowers.org/txt/va.a.capo.dopo.72.colonne.txt
 
 

 ha scritto:

https://redtowers.org/txt/va.a.capo.dopo.72.colonne.txt
 
 

 ha scritto:

https://redtowers.org/txt/va.a.capo.dopo.72.colonne.txt
 
 

 ha scritto:

https://redtowers.org/txt/va.a.capo.dopo.72.colonne.txt