Re: Flatpak

[rootkit]

Il Thu, 26 Jan 2023 08:08:25 -0000 (UTC), fandango ha scritto:

> ma voi cosa ne pensate di questi Flatpak, non so voi ma a me non
> piacciono molto...

è un sistema di distribuzione del software, analogamente a snap, che ha
pro e contro. i programmi così distribuiti sono portabili cross
distribuzione, non hanno dipendenze, si aggiornano indipendentemente dal
resto, girano in una sandbox con permessi controllati quindi sono
generalmente più sicuri. di contro tendono ad essere più pesanti sia come
occupazione disco che in memoria.

[Joe]

Secondo me hanno senso come "ultima spiaggia".
Quando invece hai la possibilità di un pacchetto nativo tagliato e
cucito per la tua distribuzione, o hai la possibilità e la capacità
di creartelo autonomamente, mi sembra preferibile scegliere questa
strada.
Io usavo slackware 14.2 (uscita nel 2016) fino all'anno scorso, quando
è uscita l'attuale slackware 15.0. Mi ero trovato nella necessità di
usare due software in versione recente: Gimp e Scribus.
Il sistema operativo era troppo vecchio per poter compilare quei nuovi
software e alla fine avevo fatto ricorso proprio a flatpak.
Con qualche piccola limitazione, ma roba risolvibile o accettabile
con un pizzico di pazienza, ero riuscito a tirare avanti fino all'uscita
del sistema operativo attuale in cui ovviamente non utilizzo più flatpak
per nessuna applicazione.

Soprattuto su PC non proprio attuali si sente parecchio la pesantezza
di quel pachidermico accrocchio, comunque è limitata in gran parte
all'avvio dei programmi, almeno nel caso della mia esperienza. Una
volta aperto gimp o scribus, poi non c'erano problemi di sorta.
D'altra parte è una soluzione semplice, tutto preparato e portabile,
quando serve ha il suo perché ed è un bene che esistano soluzioni del
genere, poco puriste un po' dispendiose in termini di risorse, ma
senz'altro pragmatiche direi.

[Piergiorgio Sartor]

On 26/01/2023 10.10, rootkit wrote:
[...]

> è un sistema di distribuzione del software, analogamente a snap, che ha
> pro e contro. i programmi così distribuiti sono portabili cross
> distribuzione, non hanno dipendenze, si aggiornano indipendentemente dal
> resto, girano in una sandbox con permessi controllati quindi sono
> generalmente più sicuri. di contro tendono ad essere più pesanti sia come
> occupazione disco che in memoria.

La domanda e`: quale sarebbe la differenza
con un compilato statico e non dinamico?
Non e` la stessa cosa, alla fine?

bye,

--

piergiorgio

[rootkit]

uhm, direi proprio di no.

[Piergiorgio Sartor]

On 26/01/2023 22.08, rootkit wrote:
[...]

>> La domanda e`: quale sarebbe la differenza con un compilato statico e
>> non dinamico? Non e` la stessa cosa, alla fine?
>
> uhm, direi proprio di no.

Perche` no?
Fanno la stessa cosa, in modo diverso.

bye,

--

piergiorgio

[rootkit]

Il Thu, 26 Jan 2023 22:35:07 +0100, Piergiorgio Sartor ha scritto:

> On 26/01/2023 22.08, rootkit wrote: [...]
>>> La domanda e`: quale sarebbe la differenza con un compilato statico e
>>> non dinamico? Non e` la stessa cosa, alla fine?
>>
>> uhm, direi proprio di no.
>
> Perche` no?

perché no. in primo luogo perché non è praticamente fattibile in molti
casi per motivi tecnici e legali. per esempio linkare staticamente
librerie gpl in programmi non gpl, o viceversa, è una violazione della
licenza.

[rootkit]

Il Thu, 26 Jan 2023 11:22:53 -0000 (UTC), Joe ha scritto:

> rootkit <roo...@email.it> wrote:
>> Il Thu, 26 Jan 2023 08:08:25 -0000 (UTC), fandango ha scritto:
>>
>>> ma voi cosa ne pensate di questi Flatpak, non so voi ma a me non
>>> piacciono molto...
>>
>> è un sistema di distribuzione del software, analogamente a snap, che ha
>> pro e contro. i programmi così distribuiti sono portabili cross
>> distribuzione, non hanno dipendenze, si aggiornano indipendentemente
>> dal resto, girano in una sandbox con permessi controllati quindi sono
>> generalmente più sicuri. di contro tendono ad essere più pesanti sia
>> come occupazione disco che in memoria.
>
> Secondo me hanno senso come "ultima spiaggia".
> Quando invece hai la possibilità di un pacchetto nativo tagliato e
> cucito per la tua distribuzione, o hai la possibilità e la capacità di
> creartelo autonomamente, mi sembra preferibile scegliere questa strada.

"tagliato e cucito per la distribuzione" dov'è il vantaggio? sul crearselo
autonomamente oltre alla capacità bisogna avere anche voglia e tempo,
inoltre presuppone che uno usi solo programmi che siano sui canali della
distribuzione.

> Io usavo slackware 14.2 (uscita nel 2016) fino all'anno scorso, quando è
> uscita l'attuale slackware 15.0. Mi ero trovato nella necessità di usare
> due software in versione recente: Gimp e Scribus.
> Il sistema operativo era troppo vecchio per poter compilare quei nuovi
> software e alla fine avevo fatto ricorso proprio a flatpak.
> Con qualche piccola limitazione, ma roba risolvibile o accettabile con
> un pizzico di pazienza, ero riuscito a tirare avanti fino all'uscita del
> sistema operativo attuale in cui ovviamente non utilizzo più flatpak per
> nessuna applicazione.

va beh questo perché sei tu che hai tempo e voglia di farlo :-)

> D'altra parte è una soluzione semplice, tutto preparato e portabile,
> quando serve ha il suo perché ed è un bene che esistano soluzioni del
> genere, poco puriste un po' dispendiose in termini di risorse, ma
> senz'altro pragmatiche direi.

beh questa filosofia è stata una delle basi del successo di macosx.

[Piergiorgio Sartor]

On 26/01/2023 23.35, rootkit wrote:
[...]

> perché no. in primo luogo perché non è praticamente fattibile in molti
> casi per motivi tecnici e legali. per esempio linkare staticamente
> librerie gpl in programmi non gpl, o viceversa, è una violazione della
> licenza.

Che razza di argomentazione
sarebbe questa?

Spiegami perche` *tecnicamente* non
sarebbe la stessa cosa.

Ho fatto *due* volte la domanda ed
ancora non sei stato in grado di
rispondere.

Vuol dire, volendo essere logici,
che non c'e` nessuna differenza.

Quando e` che non sarebbe praticamente
fattibile?

Se il programma e` C + Python, per esempio?
Si puo` fare anche in questo caso.

bye,

--

piergiorgio

[rootkit]

Il Fri, 27 Jan 2023 18:55:09 +0100, Piergiorgio Sartor ha scritto:

> On 26/01/2023 23.35, rootkit wrote:
> [...]
>> perché no. in primo luogo perché non è praticamente fattibile in molti
>> casi per motivi tecnici e legali. per esempio linkare staticamente
>> librerie gpl in programmi non gpl, o viceversa, è una violazione della
>> licenza.
>
> Che razza di argomentazione sarebbe questa?
>
> Spiegami perche` *tecnicamente* non sarebbe la stessa cosa.
> Ho fatto *due* volte la domanda ed ancora non sei stato in grado di
> rispondere.

intanto rilassati.

l'argomentazione non è affatto peregrina: le librerie runtime linux sono
rilasciate con licenza lgpl, vuol dire che se linkate staticamente ad un
programma quest'ultimo deve essere rilasciato con licenza gpl-compatibile,
mentre se linkate dinamicamente non è necessario.

https://copyleft.org/guide/comprehensive-gpl-guidech12.html#x15-11500011.5

capisci che in questo modo tutti i programmi closed source sarebbero
fottuti. niente spotify, niente chrome, niente dropbox, etc...

ma veniamo agli aspetti tecnici. prendi una qualsiasi applicazione gtk, è
possibile linkare staticamente gtk? forzando la mano, si. ottieni lo
stesso risultato? assolutamente no. in queste risposte trovi le
argomentazioni:

https://stackoverflow.com/questions/8229094/static-linking-working-with-
gtkmm-application-revised

> Se il programma e` C + Python, per esempio?
> Si puo` fare anche in questo caso.

dici? mi piacerebbe sfidarti a farlo.

e se è una applicazione electron, come la maggior parte delle applicazioni
desktop odierne? (https://www.electronjs.org/)
e se è una applicazione java? la jvm certo che ha delle dipendenze
dinamiche.
e se è una applicazione scritta in go?

[Piergiorgio Sartor]

On 27/01/2023 22.48, rootkit wrote:
[...]

>> Spiegami perche` *tecnicamente* non sarebbe la stessa cosa.
>> Ho fatto *due* volte la domanda ed ancora non sei stato in grado di
>> rispondere.
>
> intanto rilassati.

Vabbe`, scusa anche, ma dover continuare a
tirar fuori le informazioni con le pinze,
su questo gruppo poi, mi sembra alquanto
una forzatura non dovuta.

> l'argomentazione non è affatto peregrina: le librerie runtime linux sono
> rilasciate con licenza lgpl, vuol dire che se linkate staticamente ad un
> programma quest'ultimo deve essere rilasciato con licenza gpl-compatibile,
> mentre se linkate dinamicamente non è necessario.
>
> https://copyleft.org/guide/comprehensive-gpl-guidech12.html#x15-11500011.5
>
> capisci che in questo modo tutti i programmi closed source sarebbero
> fottuti. niente spotify, niente chrome, niente dropbox, etc...

Ma figurati, basta che facciano come
fa Nvidia, che si attacca persino
al kernel, senza dover dare i sorgenti
del driver, ma solo dell'interfaccia.

Senza contare che anche LGPL e` in
dubbio lo stesso, su questa cosa.

> ma veniamo agli aspetti tecnici. prendi una qualsiasi applicazione gtk, è
> possibile linkare staticamente gtk? forzando la mano, si. ottieni lo
> stesso risultato? assolutamente no. in queste risposte trovi le
> argomentazioni:
>
> https://stackoverflow.com/questions/8229094/static-linking-working-with-
> gtkmm-application-revised

Il fatto che gtk sia scritto con i piedi
(librerei di basso livello che dipendono
dal sistema) non e` una giustificazione.
E non vedo come possa funzionare con
flatpak che o 1) si porta appresso la
libreria sbagliata, o 2) usa la libreria
di sistema (e quindi non e` atomico).

Perche` se 1) funziona, funziona anche
il link statico.

>> Se il programma e` C + Python, per esempio?
>> Si puo` fare anche in questo caso.
>
> dici? mi piacerebbe sfidarti a farlo.

Gia` fatto, se e` per questo, proprio
appunto per avere un unico eseguibile.

Considera un programma Python che usa
TensorFlow.
E` praticamente non portabile, date le
dipendenze, tra le varie cose, da CUDA.
Eppure si riesce a fare un unico
eseguibile (nota: non un link statico,
ma un unico eseguibile) portabile (nei
limiti del driver Nvidia).

> e se è una applicazione electron, come la maggior parte delle applicazioni
> desktop odierne? (https://www.electronjs.org/)
> e se è una applicazione java? la jvm certo che ha delle dipendenze
> dinamiche.
> e se è una applicazione scritta in go?

Probabilmente, non ho controllato, possibile
in tutti i casi, cosi` come e` possibile,
con almeno 3 metodi, in Python.

bye,

--

piergiorgio

[Piergiorgio Sartor]

On 27/01/2023 22.48, rootkit wrote:
[...]

> https://stackoverflow.com/questions/8229094/static-linking-working-with-
> gtkmm-application-revised

Che poi, in quel link, citando i vantaggi
del link dinamico, menzionano riduzione di
spazio e manutentabilita`.

Tutte cose che vengono meno con il metodo
di distribuzione flatpak / snap.

Quindi, non sara` forse equivalente ad un
link statico, ma si porta appresso gli
stessi problemi.

bye,

--

piergiorgio

[rootkit]

>> capisci che in questo modo tutti i programmi closed source sarebbero
>> fottuti. niente spotify, niente chrome, niente dropbox, etc...
>
> Ma figurati, basta che facciano come fa Nvidia, che si attacca persino
> al kernel, senza dover dare i sorgenti del driver, ma solo
> dell'interfaccia.

nvidia, come chiunque compila un modulo del kernel, usa i kernel headers
non i sorgenti. d'altronde non vorrai dire che un driver ha il kernel
linkato staticamente... al limite può avvenire il contrario.

> Senza contare che anche LGPL e` in dubbio lo stesso, su questa cosa.

semmai ci fosse un dubbio sarebbe in senso restrittivo, non certo
espansivo a consentire l'inclusione di codice gpl/lgpl nel compilato
distribuito con licenza non compatibile.

> Il fatto che gtk sia scritto con i piedi (librerei di basso livello che
> dipendono dal sistema) non e` una giustificazione.

questa è una tua opinione. fatto sta che è un limite, che è quello che
chiedevi.

> E non vedo come possa funzionare con flatpak che o 1) si porta appresso
> la libreria sbagliata, o 2) usa la libreria di sistema (e quindi non e`
> atomico).

flatpack e snap installano un sottosistema e i programmi usano quello.

>> e se è una applicazione electron, come la maggior parte delle
>> applicazioni desktop odierne? (https://www.electronjs.org/)
>> e se è una applicazione java? la jvm certo che ha delle dipendenze
>> dinamiche.
>> e se è una applicazione scritta in go?
>
> Probabilmente, non ho controllato, possibile in tutti i casi, cosi` come
> e` possibile, con almeno 3 metodi, in Python.

"possibile" != "praticabile". le applicazioni electron ad esempio si
appoggiano sul runtime di node, quindi dovresti metterti all'anima di
ricompilare il runtime. lo stesso dicasi di java. certo, se uno ipotizza
risorse illimitate niente è impossibile, anche riscrivere tutto, ma siamo
nel mondo reale.

ti ricordo inoltre che stiamo parlando di un sistema di pacchettizzare e
distribuire programmi esistenti, non di come sia possibile realizzare
programmi che non facciano uso di librerie dinamiche. se un programma
esistente referenzia e carica una libreria by code a runtime hai voglia di
linkarlo staticamente, continuerà a dipendere da librerie dinamiche.

[rootkit]

Il Fri, 27 Jan 2023 23:51:34 +0100, Piergiorgio Sartor ha scritto:

> On 27/01/2023 22.48, rootkit wrote:
> [...]
>> https://stackoverflow.com/questions/8229094/static-linking-working-
with-
>> gtkmm-application-revised
>
> Che poi, in quel link, citando i vantaggi del link dinamico, menzionano
> riduzione di spazio e manutentabilita`.
>
> Tutte cose che vengono meno con il metodo di distribuzione flatpak /
> snap.

in parte. il maggior uso di risorse l'ho citato fra i "contro", però va
ricordato che sia flatpack che snap installano e usano un sottosistema
runtime comune, quindi se hai 10 applicazioni il consumo non si moltiplica
per 10.

[rootkit]

Il Sat, 28 Jan 2023 07:29:20 -0000 (UTC), fandango ha scritto:

> però non so perchè ma sti flatpak me li sento meno sicuri che i repo,
> sarà perchè mi ricordano gli exe di winzzowzz

ok, ma se devi installare un programma che non è nei repository ufficiale
della distribuzione come fai?

[Joe]

rootkit <roo...@email.it> wrote:
> Il Thu, 26 Jan 2023 11:22:53 -0000 (UTC), Joe ha scritto:
>
>> rootkit <roo...@email.it> wrote:
>>> Il Thu, 26 Jan 2023 08:08:25 -0000 (UTC), fandango ha scritto:
>>>
>>>> ma voi cosa ne pensate di questi Flatpak, non so voi ma a me non
>>>> piacciono molto...
>>

>> Secondo me hanno senso come "ultima spiaggia".
>> Quando invece hai la possibilità di un pacchetto nativo tagliato e
>> cucito per la tua distribuzione, o hai la possibilità e la capacità di
>> creartelo autonomamente, mi sembra preferibile scegliere questa strada.
>
> "tagliato e cucito per la distribuzione" dov'è il vantaggio?

Gira tutto in modo visibilmente più reattivo, soprattutto in fase
d'avvio, occupa meno risorse perché flatpak per far girare ad esempio
Scribus deve caricare in memoria tutto il necessario, non è quindi
solo una pesantezza maggiore in termini di spazio su disco, che a meno
di certe situazioni "strette" sarebbe anche passabile, ma anche in
termini di infrastruttura in più che gli serve. Il pacchetto progettato
per essere integrato nella distribuzione nativamente sfrutta
direttamente quello che c'è sul sitema senza doversi tirare dietro
una marea di altre librerie ecc...
Da questo punto di vista, prendi un PC vecchio e fai la prova in
pratica, ti accorgerai ad occhio del vantaggio. Con un PC nuovo tutto
ciò è un po' meno evidente.
Altro vantaggio è l'integrazione con altri pezzi nativi del sistema
operativo.

In generale non è che ci sia tanto da spiegare: se la tua distribuzione
ti offre il pacchetto di scribus fai il solito apt install scribus o
sbopkg -i scribus o quel che è, e di flatpak non se ne sente
assolutamente il bisogno. Si fa anche molto prima.

> sul crearselo
> autonomamente oltre alla capacità bisogna avere anche voglia e tempo,
> inoltre presuppone che uno usi solo programmi che siano sui canali della
> distribuzione.

Non stiamo parlando di mille pacchetti.
A me ad esempio ne servivano 2 e finché ho potuto ho tentato di
compilarmeli autonomamente cambiando VERSION=2.5.1 con VERSION=2.5.2
ad esempio e lanciando ./scribus.SlackBuild.
Tempo uomo poco, tempo macchina non è un problema...
D'altra parte il ciclo di svilupop di slack-14.2 era stato un caso
molto eccezionale avendo una base in gran parte con 6 anni sulle
spalle.

L'altra affermazione "che usi programmi che siano sui canali della
distribuzione" non l'ho capita, in generale no, puoi compilarti qualsiasi
cosa in proprio, ma più probabilmente uno slackbuild da usare come base
lo si trova quasi sempre, per cui il lavoro si restringe ad un breve
controllo (è uno script bash... niente di ché bastano pochi rudimenti)
e lo si lancia per creare il pacchetto. Poi lo si installa con
installpkg.

Ti garantisco che se lo devi fare per pochi programmi il tempo dedicato
alla cosa è veramente poco e se l'operazione riesce poi per mesi non ci
metti più mano.
Se invece parliamo di un utente che vuole provare diverse distribuzioni
a settimana allora è un altro discorso, ma lì il tempo e la voglia non
è un problema direi.

>> Io usavo slackware 14.2 (uscita nel 2016) fino all'anno scorso, quando è
>> uscita l'attuale slackware 15.0. Mi ero trovato nella necessità di usare
>> due software in versione recente: Gimp e Scribus.
>> Il sistema operativo era troppo vecchio per poter compilare quei nuovi
>> software e alla fine avevo fatto ricorso proprio a flatpak.
>> Con qualche piccola limitazione, ma roba risolvibile o accettabile con
>> un pizzico di pazienza, ero riuscito a tirare avanti fino all'uscita del
>> sistema operativo attuale in cui ovviamente non utilizzo più flatpak per
>> nessuna applicazione.
>
> va beh questo perché sei tu che hai tempo e voglia di farlo :-)

Non ti seguo, "questo perché"... ma "questo" cosa?

[ ] Tempo e voglia di usare flatpak?

[ ] Tempo e voglia di accettare qualche piccolo problema estetica di
integrazione?

[ ] Tempo e voglia di compilare i nuvoi software su sistema tropo vecchio?

>> D'altra parte è una soluzione semplice, tutto preparato e portabile,
>> quando serve ha il suo perché ed è un bene che esistano soluzioni del
>> genere, poco puriste un po' dispendiose in termini di risorse, ma
>> senz'altro pragmatiche direi.
>
> beh questa filosofia è stata una delle basi del successo di macosx.

Non lo conosco, sono ignorantissimo in materia, sebbene sia stato se
ben ricordo uno dei primi sistemi che avevo usato milioni di anni
fa o almeno il computer era un vecchissimo mac col simbolo della mela
arcobaleno e il mouse con un solo tasto, per me andava bene non avendone
mai usato uno diverso con 2 o tre tasti. :)
Probabilmente non era macosx comunque non ricordo e non ne ho idea.

[rootkit]

Il Sun, 29 Jan 2023 12:28:20 -0000 (UTC), Joe ha scritto:


>> "tagliato e cucito per la distribuzione" dov'è il vantaggio?
>
> Gira tutto in modo visibilmente più reattivo, soprattutto in fase
> d'avvio, occupa meno risorse perché flatpak per far girare ad esempio
> Scribus deve caricare in memoria tutto il necessario, non è quindi solo
> una pesantezza maggiore in termini di spazio su disco, che a meno di
> certe situazioni "strette" sarebbe anche passabile, ma anche in termini
> di infrastruttura in più che gli serve. Il pacchetto progettato per
> essere integrato nella distribuzione nativamente sfrutta direttamente
> quello che c'è sul sitema senza doversi tirare dietro una marea di altre
> librerie ecc...

perdonami ma per correttezza di informazione devo limare diverse
imprecisioni, poi per carità ognuno rimanga del suo parere.

sulle prestazioni è visibilmente meno reattivo non "soprattutto in fase
d'avvio" ma *solo* in fase di avvio. e ti dirò di più: in fase di avvio
della prima applicazione di quel tipo, perché le successive l'overhead
sostanzialmente si annulla. durante l'esecuzione non puoi aver osservato
differenze perché non ce ne sono.

un'altra precisazione: non è proprio esatto dire che il pacchetto si tira
dietro tutte le sue librerie, sia flatpak che snap installano un
sottosistema grazie al quale le applicazioni che girano in
quell'ecosistema condividono i runtime. quindi se hai 10 pacchetti non hai
risorse x10, questo è bene chiarirlo.

> Da questo punto di vista, prendi un PC vecchio e fai la prova in
> pratica, ti accorgerai ad occhio del vantaggio. Con un PC nuovo tutto
> ciò è un po' meno evidente.

guarda, non penso proprio. se il pc "vecchio" è adeguato a far girare un
dato programma al netto di quanto detto sopra non ci sono differenze.
facile semmai che su un pc vecchio uno sia vincolato a software vecchio,
quindi ci siano problemi ad aggiornarlo ad una versione recente, ma questo
è un altro problema.

in generale, ritengo ingiusto relegare linux a sistema adatto ad hw
obsoleto. certo, è un sistema adattabile a risorse minime, ma è anche e
soprattutto un sistema moderno che sfrutta meglio dei concorrenti
l'hardware di ultima generazione.

> Altro vantaggio è l'integrazione con altri pezzi nativi del sistema
> operativo.

uhm, anche questo è un falso mito. quali sono questi altri pezzi nativi
con cui non si integrerebbero? il sandboxing è ottenuto tramite cgroup,
non ci sono strati ulteriori è il kernel che controlla. se il programma
necessita di integrarsi con qualcosa avrà i permessi per farlo e non avrà
problemi.

> In generale non è che ci sia tanto da spiegare: se la tua distribuzione
> ti offre il pacchetto di scribus fai il solito apt install scribus o
> sbopkg -i scribus o quel che è, e di flatpak non se ne sente
> assolutamente il bisogno. Si fa anche molto prima.

va bene, è una scelta.

>>> Io usavo slackware 14.2 (uscita nel 2016) fino all'anno scorso, quando
>>> è uscita l'attuale slackware 15.0. Mi ero trovato nella necessità di
>>> usare due software in versione recente: Gimp e Scribus.
>>> Il sistema operativo era troppo vecchio per poter compilare quei nuovi
>>> software e alla fine avevo fatto ricorso proprio a flatpak.
>>> Con qualche piccola limitazione, ma roba risolvibile o accettabile con
>>> un pizzico di pazienza, ero riuscito a tirare avanti fino all'uscita
>>> del sistema operativo attuale in cui ovviamente non utilizzo più
>>> flatpak per nessuna applicazione.
>>
>> va beh questo perché sei tu che hai tempo e voglia di farlo :-)
>
> Non ti seguo, "questo perché"... ma "questo" cosa?
>
> [ ] Tempo e voglia di usare flatpak?
>
> [ ] Tempo e voglia di accettare qualche piccolo problema estetica di
> integrazione?
>
> [ ] Tempo e voglia di compilare i nuvoi software su sistema tropo
> vecchio?

diciamo la terza. in generale impegnare tempo e risorse per manutenere un
sistema così vecchio lo trovo un esercizio inutile. ma è un'opinione.

[Enrico Maria Chellini]

Il giorno Thu, 26 Jan 2023 08:08:25 -0000 (UTC)
fandango <fa...@ngo.invalid> ha scritto:

> ma voi cosa ne pensate di questi Flatpak, non so voi ma a me non
> piacciono molto...

Su mageia li uso parecchio, e per fortuna che ci sono.

Enrico

[Paul]

Enrico Maria Chellini <bi...@bitit.it> ha scritto:

Io uso flatpak per installare Qgis su Openmandriva e mi trovo bene.
My 2 cents
Paolo
--
Linux User from South Tyrol