Distro Independet Packaging [Archivio]

IngMetallo

21-06-2016, 19:32

Beh sembra finalmente arrivato il momento per cominciare a parlare di tecnologie come Snap e Flatpack che ci aiuteranno finalmente ad avere software installabili semplicemente, in maniera indipendente dalla distro su cui ci troviamo.
Una gioia per gli sviluppatori di terze parti che potranno contare su sistemi affidabili per fornire le applicazioni sul maggior numero di sistemi linux con un singolo pacchetto.
Una gioia per gli utenti che non dovranno più chiedersi: "Devo installre l'.rpm o il .deb ? Che devo farci con il .tar.gz? Make && install ?"

Ovviamente ci sono diversi svantaggi, ma di questi ne parleremo insieme magari :)

http://flatpak.org/
http://snapcraft.io/

Venendo al sodo: qualcuno li ha provati ? Cosa ne pensate ?

PS: Ops cannato il titolo :P

Slayer86

21-06-2016, 23:39

Non ho ancora avuto modo di provarli. Unica considerazione... Ovviamente ne dovevano per forza fare 2 di piattaforme...

IngMetallo

22-06-2016, 08:49

Concordo, non capisco perché Canonical debba sempre reinventarsi la ruota: è successo con Mir/Wayland, Upstart/systemd chissà per quanto continueranno :muro:

In realtà prima c'era anche limba project (https://people.freedesktop.org/~mak/limba/), ma dopo l'incontro tra Klumpp e Alexander Larsson (sviluppatori di Limba e Flatpack) si è deciso di sospendere lo sviluppo del primo.
VI lascio i punti salienti del blog post di Klumpp (http://blog.tenstral.net/2016/06/a-few-words-about-the-future-of-the-limba-project.html) di pochi giorni fa:

Alex and I had very productive discussions, and except for the modularity issue, we were pretty much on the same page in every other aspect regarding the sandboxing and app-distribution matters.

The main difference between Limba and Flatpak is that Limba allows modular runtimes, with things like the toolkit, helper libraries and programs being separate modules, which can be updated independently. Flatpak on the other hand, allows just one static runtime and enforces everything that is not in the runtime already to be bundled with the actual application. So, while a Limba bundle might depend on multiple individual other bundles, Flatpak bundles only have one fixed dependency on a runtime.

Sometimes stepping out of the way is the best way to achieve progress
I still think Limba is the superior solution for app distribution, but it is also the one that is most complex and requires additional work by upstream projects to use it properly. Which is something most projects don’t want, and that’s completely fine. 😉

[...]

An integral part of Limba is a web service called “LimbaHub” to accept new bundles, do QA on them and publish them in a public repository. I will likely rewrite it to be a service using Flatpak bundles, maybe even supporting Flatpak bundles and Limba bundles side-by-side (and if useful, maybe also support AppImageKit and Snappy). But this project is still on the drawing board.

GTKM

22-06-2016, 10:06

Le scelte di Canonical sono prima di tutto politiche. In pratica l'azienda è in guerra con Red Hat. :D

pippirimerlo

25-06-2016, 21:09

Le scelte di Canonical sono prima di tutto politiche. In pratica l'azienda è in guerra con Red Hat. :D

Canonical è una piaga dal primo giorno

Inviato dal mio iPad utilizzando Tapatalk

kernelex

26-06-2016, 08:05

Se ne sperava in queste pagine già 10 anni fa che ancora mi chiamavo maurinO_o e poi kernele.
Meglio tardi che mai, auguri linux! Ma cazzo, sono passati 10 anni :muro: :muro: :muro: :muro: :muro:

IngMetallo

26-06-2016, 11:23

10 anni fa sarebbe stato quasi inutile visto che non esisteva Wayland (o una qualsiasi alternativa sicura ad X11).
La particolarità di queste tecnologie è che permetteranno il sandboxing delle applicazioni, così da non dover compromettere la sicurezza. Ottima notizia anche per Debian Stable, visto che si potrà finalmente avere qualche applicazione nuova mantenendo un sistema di base solido e sicuro :)

pabloski

27-06-2016, 10:33

Slayer86

27-06-2016, 10:33

Penso che anche a livello di kernel la gestione dei processi all'interno di sandbox (o container) sia stata introdotta da qualche anno massimo.
Senza queste basi sarebbe stato impossibile sviluppare una tecnologia simile.

Sicuramente è una grossa innovazione che semplifica di tanto quella che è la distribuzione di applicazioni per linux. Chissa che non arrivi qualche software di qualità :rolleyes:

Slayer86

27-06-2016, 10:37

Bah, direi che a parte il sandboxing, novita' non ce ne sono.

Considerate che quello che stanno facendo, nella pratica si trasformera' nell'equivalente del linking statico ( millemila versioni degli stessi framework installate perche' ogni applicazione usa quella che piu' le aggrada ). In pratica Linsxs ( non so se si coglie l'allusione all'infamous Winsxs ).

L'unica attenuante sono i delta, per cui e' possibile ridurre un po' le dimensioni dei download.

Ma quello che mi chiedo davvero e': "era cosi' difficile usare correttamente il versioning come si fa in FreeBSD da decenni?". Capisco che l'ecosistema Linux e' estremamente frammentato, per cui mettersi d'accordo su cose come la deprecazione delle API e compagnia e' praticamente impossibile. Ma almeno provarci.

Parliamo di un mondo in cui Gimp (per cui furono create le librerie GTK!) usa ancora le GTK 2 facendo ampiamente vomitare graficamente su tutti gli schermi UHD... come fai a deprecare le librerie se ogniuno fa comunque quello che gli pare?

C'è da dire che al giorno d'oggi il peso degli applicativi è decisamente relativo sia in fase di downlaod che di installazione...

pabloski

27-06-2016, 16:14

Parliamo di un mondo in cui Gimp (per cui furono create le librerie GTK!) usa ancora le GTK 2 facendo ampiamente vomitare graficamente su tutti gli schermi UHD... come fai a deprecare le librerie se ogniuno fa comunque quello che gli pare?

Questo e' certamente un problema. Ma anche se non volessero deprecare, potrebbero benissimo infilare vecchie e nuove API negli stessi file fisici ( ovvero come funziona il versioning su FreeBSD ). In quel caso avresti sicuramente file di libreria piu' pesanti e maggiori difficolta' nel mantenere il codice delle librerie stesse. Ma avresti librerie retrocompatibili al 100%.

C'è da dire che al giorno d'oggi il peso degli applicativi è decisamente relativo sia in fase di downlaod che di installazione...

Eh infatti. L'applicativo in se' e' genericamente minuto. Sono le dipendenze ad essere mostruosamente articolate e di grandi dimensioni.

E se ognuno vuole le sue dipendenze, la cosa diventa problematica.

Slayer86

27-06-2016, 22:18

Questo e' certamente un problema. Ma anche se non volessero deprecare, potrebbero benissimo infilare vecchie e nuove API negli stessi file fisici ( ovvero come funziona il versioning su FreeBSD ). In quel caso avresti sicuramente file di libreria piu' pesanti e maggiori difficolta' nel mantenere il codice delle librerie stesse. Ma avresti librerie retrocompatibili al 100%.

Eh infatti. L'applicativo in se' e' genericamente minuto. Sono le dipendenze ad essere mostruosamente articolate e di grandi dimensioni.

E se ognuno vuole le sue dipendenze, la cosa diventa problematica.

Però è la via intrapresa dai 2 sistemi operativi più diffusi, su osx e su windows le librerie a parte quelle di sistema (librerie grafiche ecc...) sono tutte linkate in maniera statica all'interno degli applicativi e la situazione non è tanto male. Sinceramente credo sia molto più semplice per gli sviluppatori distribuire SW affidabile e ben testato indipendentemente dalla distribuzione e dalle versioni delle librerie che hanno nei repository.

Che poi a dirla tutta secondo me il futuro vero per linux sono le web app e framework tipo electron. Non mi ci vedo a studiare le librerie GTK o QT per un market share del 1/2% piuttosto o posso realizzare un'applicazione che giri su tutti i sistemi operativi oppure la faccio per Windows e OSX escludendo Linux.
È una cosa orribile da dire (dato che uso linux per lavoro) ma è la pura verità.
Non a caso le app rivelazione da quando sono tornato al pinguino sono tutte realizzate con Electron (Nylas N1, Git Kraken ed Atom.io)

IngMetallo

28-06-2016, 08:47

Non mi ci vedo a studiare le librerie GTK o QT per un market share del 1/2% piuttosto o posso realizzare un'applicazione che giri su tutti i sistemi operativi oppure la faccio per Windows e OSX escludendo Linux.

Penso di non aver capito bene questa frase. Perché GTK e Qt servono proprio per sviluppare applicazioni multi-os senza doversi sbattere a studiarsi le API specifiche di OS, server grafico, ecc.
Addirittura con QML puoi fare progetti per mobile e desktop con la stessa facilità delle tecnologie web ma estendibili con C++ se necessario.

Non a caso le app rivelazione da quando sono tornato al pinguino sono tutte realizzate con Electron (Nylas N1, Git Kraken ed Atom.io)

Le app rivelazione sono funzionali ed esteticamente stupende ma hanno anche un sacco di lati negativi. Sono poco performanti, occupano molto sia su disco che in RAM, richiedono tempi biblici per la compilazione (aggiornare Atom da AUR è la cosa che richiede più tempo tra tutti i pacchetti installati sul mio sistema).

Che poi a dirla tutta secondo me il futuro vero per linux sono le web app e framework tipo electron.

Forse è così tant'è che Atom lo uso spesso quando programmo perché non ci sono alternative valide.

GTKM

28-06-2016, 09:05

Che poi a dirla tutta secondo me il futuro vero per linux sono le web app e framework tipo electron. Non mi ci vedo a studiare le librerie GTK o QT per un market share del 1/2% piuttosto o posso realizzare un'applicazione che giri su tutti i sistemi operativi oppure la faccio per Windows e OSX escludendo Linux.
È una cosa orribile da dire (dato che uso linux per lavoro) ma è la pura verità.
Non a caso le app rivelazione da quando sono tornato al pinguino sono tutte realizzate con Electron (Nylas N1, Git Kraken ed Atom.io)

Guarda che con Qt puoi scrivere software multipiattaforma, anche tenendo in considerazione il mobile.

Per me, usare le webapp per qualsiasi minchiata è una cosa insensata, onestamente. Poi, qua davvero chiedo lumi, Atom che ha di innovativo rispetto ad altri editor di testo? (fermo restando che, per chi li sa usare, prodotti come Emacs o Vim rimangono insuperabili) :D

Slayer86

28-06-2016, 09:06

Penso di non aver capito bene questa frase. Perché GTK e Qt servono proprio per sviluppare applicazioni multi-os senza doversi sbattere a studiarsi le API specifiche di OS, server grafico, ecc.
Addirittura con QML puoi fare progetti per mobile e desktop con la stessa facilità delle tecnologie web ma estendibili con C++ se necessario.

In teoria si, ma sulla carta quante app GTK o QT ci sono su Windows o OSX.

Salve qualche esempio ci sono lacune immense, per esempio non esiste un client FTP ed un client Mysql / Postgre in GTK+ 3 (ma nemmno 2).

Di fatto chi programma in GTK+ a parte il team gnome? Pochissimi.
La documentazione di ste librerie? Alquanto lacunosa e carente.

Discorso Qt leggermente diverso in quanto qualche anno fa hanno avuto un picco di popolarità (picco per modo di dire... :D ) ma la penetrazione al di fuori dell'ambiente kde è quasi 0 (tolto filezilla che comuqnue è su una versione vecchia).

Electron ha dei lati negativi oggettivi, tuttavia è anche una tecnologia super nuova che a mio avviso si integra alla perfezione con la via intrapresa con snap e flatpack e soprattutto gli sviluppatori in tutto il mondo ne hanno già decretato il successo.

Slayer86

28-06-2016, 09:09

Guarda che con Qt puoi scrivere software multipiattaforma, anche tenendo in considerazione il mobile.

Per me, usare le webapp per qualsiasi minchiata è una cosa insensata, onestamente. Poi, qua davvero chiedo lumi, Atom che ha di innovativo rispetto ad altri editor di testo? (fermo restando che, per chi li sa usare, prodotti come Emacs o Vim rimangono insuperabili) :D

CLI per qualisasi interazione con l'editor... oltre appunto ad essere disponibile per tutti i sistemi operativi.

Usi Vim, bene se ti trovi a lavorare su Windows come fai? A me piace lavorare con il terminale ma siamo nel 2016 avere tool leggermente più avanzati non mi fa poi così schifo...

GTKM

28-06-2016, 09:12

CLI per qualisasi interazione con l'editor... oltre appunto ad essere disponibile per tutti i sistemi operativi.

Usi Vim, bene se ti trovi a lavorare su Windows come fai? A me piace lavorare con il terminale ma siamo nel 2016 avere tool leggermente più avanzati non mi fa poi così schifo...

http://www.vim.org/download.php/ :D

Comunque, ci sarebbe pure un certo Sublime Text. :D

Slayer86

28-06-2016, 09:25

http://www.vim.org/download.php/ :D

Comunque, ci sarebbe pure un certo Sublime Text. :D

Lo conosco bene, l'ho usato per un paio di anni. Ottimo davvero ma è closed source e a dire il vero a pagamento...

Atom per me è stato un passo avanti :rolleyes:

Immaginavo che stavo per dire una cagata con Vim :D

IngMetallo

28-06-2016, 09:32

In teoria si, ma sulla carta quante app GTK o QT ci sono su Windows o OSX.
Tutte le applicazioni open source che sono eseguibili anche su altre piattaforme :mbe:

Firefox, Thunderbird, Clementine, sqlitebrowser, KeepassX, Octave, Wireshark, VLC, Krita, Inkscape, Libreoffice, qbittorrent, OBS-studio,... (sono tutte quelle che ho installato attualmente, infatti per ricordarmele stavo scorrendo il menù :D)
Telegram Desktop è stupendo, ha interfaccia responsive ed scritto con le Qt.
AMD sta usando le Qt per il suo pannello driver, Nvidia usa le GTK per il suo (almeno su linux).

Slayer86

28-06-2016, 09:49

Tutte le applicazioni open source che sono eseguibili anche su altre piattaforme :mbe:

Firefox, Thunderbird, Clementine, sqlitebrowser, KeepassX, Octave, Wireshark, VLC, Krita, Inkscape, Libreoffice, qbittorrent, OBS-studio,... (sono tutte quelle che ho installato attualmente, infatti per ricordarmele stavo scorrendo il menù :D)
Telegram Desktop è stupendo, ha interfaccia responsive ed scritto con le Qt.
AMD sta usando le Qt per il suo pannello driver, Nvidia usa le GTK per il suo (almeno su linux).

Non mi sono spiegato. Nessuna di queste applicazioni usa GTK fuori da Linux.
Solo alcune usano Qt... ma sono comunque poche... Su Osx quasi tutti usano ti Cocoa, su windows le librerie di Windows.

Qt è sicuramente un mondo interessante, e ci riporta in topic... finalmente in ambiente Gnome sarà possibile installare applicazioni Qt senza riempire il sistema di pacchetti provenienti da KDE.

pabloski

28-06-2016, 10:00

Però è la via intrapresa dai 2 sistemi operativi più diffusi, su osx e su windows le librerie a parte quelle di sistema (librerie grafiche ecc...) sono tutte linkate in maniera statica all'interno degli applicativi e la situazione non è tanto male.

E' il vantaggio di poter imporre un qualche cosa. Windows e OS X ti dicono: "io, versione X.Y.Z del sistema operativo, ti offro queste librerie con versioni A, B, C, ecc...". Il resto ce lo metti tu sviluppatore dell'applicazione, che sia linkato dinamicamente o staticamente sono affari tuoi.

Ma su Linux come fai? E soprattutto c'e' una caratteristica che Linux ha da sempre aborrito, ovvero la retrocompatibilita'. C'era un articolo di alcuni anni fa, del capo progetto di Windows prima di Sinofsky, dove descriveva i salti mortali che avevano dovuto fare per mantenere la retrocompatibilita'. Penso ci ricordiamo tutti delle funzioni dell'API Win32 che vogliono come ultimo parametro la dimensione della struct che gli stai passando.

Ovviamente ad un certo punto il sistema e' imploso e MS ha detto basta e si e' inventata WinRT.

Sinceramente credo sia molto più semplice per gli sviluppatori distribuire SW affidabile e ben testato indipendentemente dalla distribuzione e dalle versioni delle librerie che hanno nei repository.

Certamente e' un vantaggio. Pero' ci sono anche svantaggi, come la mancanza di controlli e che potrebbero portare software non proprio onesto sui pc della gente. Un maintainer alla fin fine il programma che va a pacchettizzare se lo guarda, lo usa, eventualmente riesce a scovare magagne ( che so, telemetria, attivita' sospette di manipolazione dei dati dell'utente ). Si otterrebbero tutti i vantaggi e gli svantaggi gia' noti nel mondo Windows.

Che poi a dirla tutta secondo me il futuro vero per linux sono le web app e framework tipo electron.

Le webapp purtroppo saranno un male con cui convivere, visto che i colossi ormai puntano tutti a queste. Evidentemente la NSA ha bisogno di raccogliere altri dati.

Electron e' interessante, almeno per quanto riguarda la facilita' con cui si possono realizzare applicazioni stand-alone. Ed e' pure un vantaggio perche' l'API a cui fare riferimento diventa quella di Webkit e non piu' quella del sistema operativo.

In pratica il programma della retrocompatibilita' si sposta di un livello, ma con la certezza che chi sviluppa gli engine per il web ci tiene alla retrocompatibilita'.

Non mi ci vedo a studiare le librerie GTK o QT per un market share del 1/2% piuttosto o posso realizzare un'applicazione che giri su tutti i sistemi operativi oppure la faccio per Windows e OSX escludendo Linux.

QT e' multipiattaforma ed e' un framework decisamente di alto livello. E' un po' mancante sul versante dei controlli Qt Quick, ma il tempo sanera' anche questa pecca.

E considera che comunque Electron et similia ti fanno pagare un prezzo abbastanza alto in termini di performance. Per cui non si ritorna al problema che gli sviluppatori mobile devono affrontare costantemente, ovvero valutare il trade-off tra performance e facilita' d'implementazione.

Ci sono applicazioni che devono essere performanti, per quelle Electron non e' una soluzione accettabile, cosi' come React Native non lo e' per alcune applicazioni mobile.

Slayer86

28-06-2016, 10:11

E' il vantaggio di poter imporre un qualche cosa. Windows e OS X ti dicono: "io, versione X.Y.Z del sistema operativo, ti offro queste librerie con versioni A, B, C, ecc...". Il resto ce lo metti tu sviluppatore dell'applicazione, che sia linkato dinamicamente o staticamente sono affari tuoi.

Ma su Linux come fai? E soprattutto c'e' una caratteristica che Linux ha da sempre aborrito, ovvero la retrocompatibilita'. C'era un articolo di alcuni anni fa, del capo progetto di Windows prima di Sinofsky, dove descriveva i salti mortali che avevano dovuto fare per mantenere la retrocompatibilita'. Penso ci ricordiamo tutti delle funzioni dell'API Win32 che vogliono come ultimo parametro la dimensione della struct che gli stai passando.

Ovviamente ad un certo punto il sistema e' imploso e MS ha detto basta e si e' inventata WinRT.

Certamente e' un vantaggio. Pero' ci sono anche svantaggi, come la mancanza di controlli e che potrebbero portare software non proprio onesto sui pc della gente. Un maintainer alla fin fine il programma che va a pacchettizzare se lo guarda, lo usa, eventualmente riesce a scovare magagne ( che so, telemetria, attivita' sospette di manipolazione dei dati dell'utente ). Si otterrebbero tutti i vantaggi e gli svantaggi gia' noti nel mondo Windows.

Le webapp purtroppo saranno un male con cui convivere, visto che i colossi ormai puntano tutti a queste. Evidentemente la NSA ha bisogno di raccogliere altri dati.

Electron e' interessante, almeno per quanto riguarda la facilita' con cui si possono realizzare applicazioni stand-alone. Ed e' pure un vantaggio perche' l'API a cui fare riferimento diventa quella di Webkit e non piu' quella del sistema operativo.

In pratica il programma della retrocompatibilita' si sposta di un livello, ma con la certezza che chi sviluppa gli engine per il web ci tiene alla retrocompatibilita'.

QT e' multipiattaforma ed e' un framework decisamente di alto livello. E' un po' mancante sul versante dei controlli Qt Quick, ma il tempo sanera' anche questa pecca.

E considera che comunque Electron et similia ti fanno pagare un prezzo abbastanza alto in termini di performance. Per cui non si ritorna al problema che gli sviluppatori mobile devono affrontare costantemente, ovvero valutare il trade-off tra performance e facilita' d'implementazione.

Ci sono applicazioni che devono essere performanti, per quelle Electron non e' una soluzione accettabile, cosi' come React Native non lo e' per alcune applicazioni mobile.

Concordo praticamente con tutto, e non avevo mai considerato la problematica relativa alla possibilità di includere software malevolo, qui sarà necessario operare una serie di controlli per garantire l'affidabilità sugli "store" ufficiali... snap flatpack che sia...

Comunque sia questo a cui stiamo assistendo è un cambiamento, e notevole. Com'è stato fino ad ora non mi pare che abbia funzionato un gran che... staremo a vedere dove si andrà a finire.

pabloski

28-06-2016, 10:21

Comunque sia questo a cui stiamo assistendo è un cambiamento, e notevole. Com'è stato fino ad ora non mi pare che abbia funzionato un gran che... staremo a vedere dove si andrà a finire.

Di sicuro e' un enorme shift nel modello di gestione del software. Consideriamo pure cosa implica il sandboxing, ovvero una cosa a la Android, dove un word processor non puo' mettere il becco nelle foto delle vacanze. E' un bene da un lato, ma dall'altro crea barriere che possono impattare sull'esperienza d'uso dell'utente ( es: bisogna autorizzare il programma ogni volta si voglia includere una foto in un documento ).

Quel che e' certo e' che era necessario un cambiamento. Credo che invece di strillare al complotto, bisognerebbe mettersi tutti a migliorare questo nuovo modello di gestione del software, in modo da renderlo il piu' efficiente possibile.

Con assoluta certezza si eliminera' l'ultima scusa che i produttori di software avevano per non portare i loro software su Linux.

GTKM

28-06-2016, 10:24

Concordo praticamente con tutto, e non avevo mai considerato la problematica relativa alla possibilità di includere software malevolo, qui sarà necessario operare una serie di controlli per garantire l'affidabilità sugli "store" ufficiali... snap flatpack che sia...

Comunque sia questo a cui stiamo assistendo è un cambiamento, e notevole. Com'è stato fino ad ora non mi pare che abbia funzionato un gran che... staremo a vedere dove si andrà a finire.

Secondo me l'ideale sarebbe stato sfruttare il più possibile le librerie condivise, ma questo richiede alcune cose che non sono proprio facili da attuare, tra cui scriverle come si deve. :D

Slayer86

29-06-2016, 08:46

Secondo me l'ideale sarebbe stato sfruttare il più possibile le librerie condivise, ma questo richiede alcune cose che non sono proprio facili da attuare, tra cui scriverle come si deve. :D

eh bhe! :D Purtroppo l'ideale non esiste!

Detto questo, primo tentativo con snap (visto che sono su ubunut) ho provato krita, ma non funziona con i driver proprietari nvidia... :muro:

IngMetallo

05-07-2016, 08:45

Ho appena letto un articolo molto interessante, scoprendo l'esistenza di un altro software in grado di fornire pacchetti funzionanti su multiple distro. Si tratta di Appimage (http://appimage.org/) e a quanto pare è molto più maturo rispetto a Snap e Flatpack.
https://distrowatch.com/weekly.php?issue=20160704#opinion

Se volete provare qualche appimage:
https://github.com/probonopd/AppImageKit/wiki/AppImages
https://bintray.com/probono/AppImages
ho provato con successo Krita, usando Debian Testing :)

Slayer86

05-07-2016, 09:30

Chissà come mai hanno sentito il bisogno di farne altre 2 di piattaforme :muro:

pabloski

05-07-2016, 14:58

Chissà come mai hanno sentito il bisogno di farne altre 2 di piattaforme :muro:

Senza contare che offre pure maggiori funzionalita' https://github.com/probonopd/AppImageKit/blob/master/README.md

L'unica che mi pare manchi e' il sandboxing ( purtroppo ).

Il problema di Linux e' che ci sono due colossi, Redhat e Canonical, che mirano al dominio dell'ecosistema e soffrono di una fortissima sindrome NIH.

Per ora la guerra la sta vincendo Redhat, visto che e' riuscita ad imporre tecnologie chiave come Pulseaudio e Systemd.

Slayer86

05-07-2016, 15:20

Come si suol dire vittorie di Pirro...
Perchè sicuramente non è l'ambiente Linux ad averci guadagnato, basti vedere la pagliacciata per sostituire Xorg.

Ad oggi ne Mir ne Wayland sono utilizzati / supportati (ma nemmno pronti per essere distribuiti)

Il problema è che i sistemi operativi "concorrenti" sono andati avanti notevolmente negli ultmi anni mentre tra le solite spaccature e divisioni il monto Linux è rimasto parecchio indietro perdendo anche parte di quelle quote di mercato tanto faticosamente guadagnate...

Questa potrebbe diventare l'ennesima occasione sprecata :rolleyes:

Slayer86

05-07-2016, 15:27

Cmq sono curiosissimo per questo AppImage, lo proverò il prima possibile :D

IngMetallo

05-07-2016, 16:11

Senza contare che offre pure maggiori funzionalita' https://github.com/probonopd/AppImageKit/blob/master/README.md

L'unica che mi pare manchi e' il sandboxing ( purtroppo ).

Se leggi il readme verso la fine, dice proprio che per il sandboxing si può usare Firejail: https://github.com/probonopd/AppImageKit/blob/master/README.md#sandboxing

Ovvio che poi rimane sempre il problema Xorg.

Chissà come mai hanno sentito il bisogno di farne altre 2 di piattaforme :muro:

Beh di differenze implementative ce ne sono molto, Flatpack sarà sicuramente più efficiente grazie ai runtime.
Snap, da quando ho scoperto che la parte server è closed-source, rifiuto di prenderlo in considerazione. Canonical mi sta deludendo anno dopo anno.
Di fatto però AppImage è l'unico che funziona, quindi rappresenta sicuramente il presente :D a proposito, anche Atom 1.8 ha funzionato a primo colpo!

Slayer86

05-07-2016, 17:19

Lo stai provando su Ubuntu?
Servono repo extra immagino...

Slayer86

05-07-2016, 17:30

Ok, capito... in pratica scarichi solo il file .appimage gli dai i permessi di esecuzione e sei pronto! Non c'è una sorta di store da cui scariare i file... cmq ottimo davvero Krita parte senza problemi!

pabloski

05-07-2016, 18:40

AppImage mi ricorda tantissimo Slax/Porteus. E parliamo di roba che si faceva gia' nel 2007. Potere di squashfs :D

Slayer86

05-07-2016, 23:09

Non le conosco come distro.
Comunque sia senza un mezzo (portale web o applicazione) centralizzato da cui scaricare i pacchetti è un disastro maggiore rispetto alla gestione classica da repository XD

Per esempio oggi cercavo Atom.io ma non l'ho trovato.

IngMetallo

06-07-2016, 09:27

Vero, infatti avrebbero dovuto pensare anche ad una soluzione centralizzata con relativo tool per scaricare i binari ufficiali. Attualmente puoi trovare i binari qui: https://github.com/probonopd/AppImageKit/wiki/AppImages. In pratica sono tutti link che portano al profilo bintray.com di probono (https://bintray.com/probono/AppImages) (lo sviluppatore di AppImage).

A proposito di "probono", ha appena scritto qualcosa di interessante riguardo Electron e AppImage, appena ho letto ho pensato subito a te Slayer :D
https://plus.google.com/105493415534008524873/posts/C1Mo1m5Muin

Lo stai provando su Ubuntu?
Servono repo extra immagino...

Non uso Ubuntu. Solo Arch e Debian sui pc di casa :p

Slayer86

06-07-2016, 14:34

I programmi realizzati con Electron ne gioveranno tantissimo di questo nuovo modo di distribuire il software. Se si affermerà una piattaforma unica gli sviluppatori saranno estremamente agevolati anche nella creazione dei pacchetti finali da distribuire.

Detto questo, ho appena creato un nuovo repo privato su bitbucket con git kraken ed è fantastico, funziona meglio si Source Tree su Osx!

Ha ancora qualche problema di gioventù e su Osx (non so su windows) è lentissimo (colpa di electron credo) ma ragazzi che SW che hanno sfornato. Spero non lo facciano diventare a pagamento in futuro.

p.s. mi sa che a breve piallo il pc in ufficio e passo (torno) ad Arch con KDE...

Slayer86

08-07-2016, 09:12

Tra l'altro ragionadoci... AppImage lo usavo da tempo con Franz.
Franz è sempre un'app electron che in un'unico contenitore permette di aprire le web app di tutti i più comuni servizi di chat (messenger, whatsapp, telegram...)

Ci ho ragionato ieri, mi sono chiesto come facesse a funzionare ed ho fatt 1+1 :)

Ho poi provveduto a configurare un link in gnome-shell... ecco questa è un'altra parte carente.

Le mancanze cruciali di appimage sono 2:

distribuzione dei programmi centralizzata
Installazione nei più comuni DE

IngMetallo

15-07-2016, 21:29

Slayer86

20-07-2016, 11:06

Non conoscevo Franz, sembra carino ma se non sbaglio è closed-source vero? Come Git Kraken che sembra molto carino, ma per il mio semplice workflow continuo a preferire git (da terminale) + gitg :)

Comunque sono felice di vedere che AppImage sia realmente utile per la distribuzione del software!
Ai punti negativi che hai citato, aggiungerei che di fatto è ancora poco utilizzato :confused:

Riguarda il link in Gnome a cosa ti riferisci di preciso ? Vorresti aggiungere un'icona avviabile nel menù ?

Si esatto ho aggiunto una cartella Apps nella mia home, ho poi creato il file .desktop e l'ho copiato nella cartella da cui gnome shell va a pescare (non ricordo quale sia...).

Concordo poi sul fatto che non sia diffuso, ma cacchio nemmeno lo conoscevo non è stato spinto per nulla! In pieno stile linux hanno semplicemente copiato l'idea in altri 2 o 3 progetti che si fanno la guerra tra loro...:muro:

IngMetallo

23-07-2016, 17:23

Si esatto ho aggiunto una cartella Apps nella mia home, ho poi creato il file .desktop e l'ho copiato nella cartella da cui gnome shell va a pescare (non ricordo quale sia...).
Io non faccio così, sfrutto il pacchetto alacarte (nel menù viene chiamato semplicemente "Main Menu") che permette di aggiungere/rimuovere icone avviabili :D
In realtà amo Cinnamon e KDE perché hanno questa funzionalità integrata nel sistema, basta cliccare con il destro sul menù e modificare a piacimento le varie voci.

Concordo poi sul fatto che non sia diffuso, ma cacchio nemmeno lo conoscevo non è stato spinto per nulla! In pieno stile linux hanno semplicemente copiato l'idea in altri 2 o 3 progetti che si fanno la guerra tra loro...:muro:
Ok che non l'hanno spinto ma non direi che hanno "copiato l'idea" e ora si fanno guerra. Anzi mi pare che ci sia rispetto tra le parti (eccetto Canonical e la sua testardaggine).
Sono progetti diversi con finalità diverse, il migliore sopravviverà. È una questione di selezione naturale applicata al mondo software ;)

IngMetallo

20-01-2017, 12:14

https://solus-project.com/2017/01/18/adopting-flatpak-to-reassemble-third-party-applications/

Snap (snapd and snapcraft) represents the biggest integration challenge. To correctly and fully integrate it would require modification of the build system (which disables networking by default for security!) to provide a full set of builds for the packages and their dependencies. Additionally, AppArmor (not used by Solus) is also required.

On the other hand, integrating Flatpak into Solus was as trivial as packaging ostree and flatpak, barring some minor changes which we’re already upstreaming.

[...]

You get the picture, we’re going with Flatpak. It’s a great solution, and in terms of the future, the most suitable route we can take. There is a responsive, engaging community, and it ticks all the boxes for what we want.

Additionally, Flatpak supports AppStream, which Solus already makes use of, so it’s an instant fit in terms of integration into our Software Center.

Gran bel lavoro dei ragazzi dietro Solus, sono molto curioso di vedere come sfrutteranno Flatpak :)

PS: entro Marzo aprirò un thread su Solus, perché è la distro che sta più progredendo negli ultimi mesi, riuscendo anche a collaborare con molti progetti upstream (quindi le migliorie apportate in Solus, sono facilmente sfruttabili da chiunque non come fa Ubuntu con le proprie soluzioni).

pabloski

21-01-2017, 11:41

Sicuramente quelli di Solus hanno agito dopo aver ponderato pro e contro di entrambe le soluzioni.

Comunque a me stona una cosa dell'affaire della containerizzazione/sandboxing delle applicazioni, ovvero la parta relativa ai "portals" ( flatpak li chiama cosi' ).

Cioe' sono delle "aperture" verso l'esterno della sandbox, il che pero' e' alquanto curioso, nel senso che abbiamo fatto il giro lungo per chiudere il cancello e adesso lo stiamo riempendo di buchi perche' necessari?

Temo che quei buchi verranno ampiamente sfruttati per rendere inutili l'intera infrastruttura di sandboxing.

Ok, capisco, che nel mondo pc/workstation e' logico che un programma X possa avere accesso a tutti i file dell'utente A, ma il punto e' proprio quello di negare questo accesso per evitare che un malware possa leggere i file dell'utente A. Si sta creando un paradosso.

Almeno nel mondo mobile hanno imposto un modello totalmente diverso, alla cui base c'e' il concetto che ogni applicazione e' proprietaria solo dei suoi dati, a meno di usare strumenti per richiedere altri dati ( ma sotto lo stretto controllo dell'utente ). Cioe' se basta che un'applicazione dichiari di aver bisogno di accesso ad un certo portal perche' le sia garantita, beh, la conclusione mi pare ovvia...