Distro Independet Packaging

[IngMetallo]

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]

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

[IngMetallo]

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

In realtà prima c'era anche limba project, 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 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]

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

[pippirimerlo]

Originariamente inviato da GTKM

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

Canonical è una piaga dal primo giorno


Inviato dal mio iPad utilizzando Tapatalk

[kernelex]

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

[IngMetallo]

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]

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.

[Slayer86]

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à

[Slayer86]

Originariamente inviato da pabloski

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]

Originariamente inviato da Slayer86

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

Originariamente inviato da Slayer86

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]

Originariamente inviato da pabloski

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]

Originariamente inviato da Slayer86

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.

Originariamente inviato da Slayer86

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

Originariamente inviato da Slayer86

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]

Originariamente inviato da Slayer86

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)

[Slayer86]

Originariamente inviato da IngMetallo

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... ) 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]

Originariamente inviato da GTKM

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)

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]

Originariamente inviato da Slayer86

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/

Comunque, ci sarebbe pure un certo Sublime Text.

[Slayer86]

Originariamente inviato da GTKM

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

Comunque, ci sarebbe pure un certo Sublime Text.

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

Immaginavo che stavo per dire una cagata con Vim

[IngMetallo]

Originariamente inviato da Slayer86

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

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ù )
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]

Originariamente inviato da IngMetallo

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

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ù )
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.