Nella giornata di ieri 25 Ottobre 2016 Alex Larsson ha annunciato la disponibilità di Flatpak 0.6.13, un nuovo aggiornamento dell’universal binary package format per distribuzioni GNU/Linux.

Flatpak 0.6.13 arriva tre settimane dopo il rilascio di Flatpak 0.6.12. Come sapete Flatpak vi permete di pacchettizzare i vostri progetti open source per una facile distribuzione tra le varie distro GNU/Linux.

 flatpak 0.6.13

Flatpak 0.6.13

In questa versione è stato migliorato il supporto da terminale che ora permette anche ai meno esperti di installare, aggiornare o disinstallare i flatpak package. Migliorato anche il DBus proxy filtering. Aggiunti alcuni parametri che vengono ora correttamente riconosciuti dal builder:
  • “remote-add”.
  • “install –from”.
  • “–finish-only”.
  • “–allow-missing-runtimes”.

Per maggiori informazioni vi rimando al sito ufficiale dove potete anche scaricare Flatpak.

sharing-caring-1-1

Vi ricordiamo che seguirci è molto semplice: tramite la pagina Facebook ufficiale, tramite il nostro canale notizie Telegram e la nostra pagina Google Plus.

Qui potrete trovare le varie notizie da noi riportate sul blog. È possibile, inoltre, commentare, condividere e creare spunti di discussione inerenti l’argomento.

  • Mattia Dorigatti

    E io che pensavo fosse un iconpack… 😉

  • Luca Cavedale

    per i più esperti : ci sono sostanziali differenze tra flatpack e snap? quali potrebbe tra i due prendere piede maggiormente? ( sebbene comunque snappy potrebbe avere un certo vantaggio in fatto di nomina derivato da ubuntu?)

    • Sono due cose piuttosto diverse che servono alla stessa cosa. Ossia usufruire dei programmi direttamente dagli sviluppatori, senza passare dalla selezione, dal bugfixing e dal packaging delle distro.

      Snap è essenzialmente un unico file in cui lo sviluppatore può ficcarci quello che gli pare, ossia programma e dipendenze. Le funzionalità di sicurezze avanzate dipendono dall’integrazione con mir e apparmor.

      Flatpak vuole essere un contenitore repository standard per tutte le distro. Il “problema” delle dipendenze viene risolto suddividendo i repo in programmi e dipendenze (chiamate runtime). I runtime sono essenzialmente le dipendenze più “comuni”, facendo un esempio le librerie GNOME/GTK. Tutto il resto viene distribuito insieme al programma. Le funzionalità di sicurezze avanzate dipendono dall’integrazione con wayland e selinux.

      Entrambi i sistemi possono essere teoricamente installati su tutte le distro. Ma per sfruttarli a pieno occorre avere mir/apparmor per il primo e wayland/selinux. Ubuntu va per il primo ecosistema, ma praticamente tutte le altre (comprese molte derivate di Ubuntu) mi sembrano siano più inclini ad adottare il secondo.

      Entrambi i sistemi hanno più o meno lo stesso problema che si ha in Windows. Ossia tenere aggiornate le dipendenze diventa compito dello sviluppatore del programma principale, compito a cui raramente assolve con la necessaria solerzia, il che porta ad inevitabili problemi di sicurezza. Per il resto sono una semplificazione e non intendono sostituire i repository, ma al massimo estenderli.

      • Luca Cavedale

        capito, gentile e coinciso! :), diciamo che bisogna aspettare e vedere quale dei due si diffonderà maggiormente, anche se non credo ci sarà un abbandono di una o l’altra tecnologia

      • alex

        “Ubuntu va per il primo ecosistema, ma praticamente tutte le altre
        (comprese molte derivate di Ubuntu) mi sembrano siano più inclini ad
        adottare il secondo.”… strano 😀
        No ok, se snap ha bisogno di mir è chiaro che praticamente solo Ubuntu alla fine lo usa visto che è l’unica ad usare mir. Non credevo che le due soluzioni dipendessero anche da mir/wayland a seconda, perchè? a parte chiaramente dover gestire librerie diverse chiaramente.

        • Flatpat e Snap funzionano anche su Xorg.

          Tuttavia, uno degli obiettivi di entrambi questi progetti è anche il sandboxing delle applicazioni. Ed entrambi come metodo non vogliono usare “nuovi” strumenti e reinventare la ruota, ma usare funzionalità proprie del kernel o strumenti di sistema già installati di default (come systemd).

          Ora se si parla di applicazioni desktop, il sandboxing su Xorg non è possibile (a meno di usare programmi aggiuntivi e configurazioni particolari). Ad esempio su Xorg ogni applicazione aperta può leggere l’input della tastiera, il che è tecnicamente un pericolo di sicurezza.

          Wayland e Mir invece isolano le applicazioni di default permettendo il sandboxing, senza strumenti di terze parti.

          • Luca Cavedale

            immagino quindi snap abbia compatibilità anche con wayland e non soltanto con mir?

          • alex

            grazie, risposta molto chiara 🙂

      • Aury88

        da quello che ho capito da alcuni post di alcuni sviluppatori flatpack funziona sia con selinux che con apparmor, mentre per snap è di sicuro utilizzabile anche su distro con selinux ma non ho capito se sfrutta selinux come modulo o richiede comunque apparmor. il sandbox è stato raggiunto anche su arch che usa, se non vado errato, selinux, ma non ho capito se sono richieste modifiche o l’aggiunta di apparmor

        per quanto riguarda mir e wayland da quello che ho capito entrambi i sistemi di pacchettizzazione sono indifferenti al protocollo e al display server, semmai è un vincolo imposto dall’app contenuta.
        al momento attuale è in pesante sviluppo nei snap la possibilità di condividere dipendenze comuni (se lo vuole lo sviluppatore e credo anche l’utente) e quindi può essere realizzato un meccanismo simile a quello dei runtime di flatpack

      • Samael

        In entrambi i casi si ha più o meno lo stesso problema che si ha in Windows.
        Ossia tenere aggiornate le dipendenze diventa compito dello sviluppatore del programma principale, compito a cui raramente assolve con la necessaria solerzia, il che porta ad inevitabili problemi di sicurezza.

        Quindi nessuno, considerando che non ci sono macchine Windows bucate a causa di problemi di sicurezza legati alle librerie.
        Questa è una storiella che ci piace raccontare ma che non ha mai avuto un riscontro reale, perché è un attacco che ha poco senso in un ambiente desktop.
        Su Windows (ma anche su Android) il sistema viene danneggiato da malware che vengono installati dall’utente inconsapevolmente tramite inganno. Il cosiddetto “social engineering”.
        E qui non ti salva nessuno, né il repository e né il bundle. La storia delle ISO corrotte di Linux Mint insegna.

        Anzi, semmai il bundle ti evita problemi come quelli legati ad Umbreon, quel malware che corrompeva il loader e la libc e ti fregava il sistema operativo facendo leva proprio sul linking dinamico e la ragnatela delle dipendenze.

        Per il resto sono una semplificazione e non intendono sostituire i repository, ma al massimo ad estenderli.

        Assolutamente no.
        ADESSO sono un’espansione, in quanto sono tecnologie ancora in fase embrionale. Ma l’obbiettivo finale è proprio quello di eliminare il package manager come lo conosciamo noi.
        Sul desktop NON si ha bisogno dei pacchetti con le dipendenze. Per usare un’applicazione basta un bundle da posizionare in una directory e da eliminare spostandolo nel cestino. OSX insegna da una vita come si gestisce un desktop decentemente. Soltanto noi ci complichiamo la vita con pacchetti, dipendenze, apt-get e cavoli vari. Con risultati disastrosi. Vedasi i continui problemi durante gli avanzamenti delle distribuzioni e vedasi i problemi legati all’uso sfrenato di repository di terze parti.

        Sui server idem. Anche lì non serve il package manager, perché ormai si butta tutto in container Docker per evitare problemi legati alla differenza delle versioni dello stack tra l’ambiente di sviluppo e quello di produzione.

No more articles