Stavo pensando di fare un confronto tra i vari sistemi di questo tipo sul mio canale Linux. Vediamo un attimo come riesco ad organizzarmi. Per quanto riguarda, invece, la variante desktop di Core, se ne riparlerà in autunno quando, in teoria, dovrebbe finalmente uscire assieme ad Ubuntu 24.10
Sei proprio bravo! Ottima sintesi! Faccio una proposta: realizzare una rubrica con video che raccontino le novità sia in ambito embedded ma anche come questa sugli OS immutabili. Mi capita più spesso di visualizzare video come il tuoi che andare a giro per il web alla ricerca di notizie! Oggi mi è arrivata una mail di Elettronica In che mi chiedeva di partecipare al webinar GRATUITO "Jolly, il modulo rivoluzionario per l’elettronica connessa". Ho fatto una ricerca su Jolly ed ho avuto una bella sorpresa! Un modulo veramente figo! Che ne dici di una rubrica che parla di novità come questa? Grazia ancora per i video che pubblichi!
Grazie per i complimenti! Per gli Snap è da vedere: già ora (con gli ultimi update di Snapd) sono stati velocizzati un sacco. Ad esempio sul mio PC non noto più differenze con le app native, ed in generale la "lentezza" può capitare di intravederla giusto al primo lancio, poi nell'uso (anche con apri e chiudi completa dell'app) non si nota più. Sicuramente varia molto da PC e PC, quanto quest'ultimo è prestante, etc. Però, boh, sì, vediamo come evolverà...
sono curioso di questa distro immutabile Canonical ,il problema e che gli snap sono gestiti solo da Canonical mente i flatpak no, diciamo che Canonical con gli snap si isola un pò dal resto del mondo indipendentemente se siano migliori o peggiori di flatpak
Beh in realtà non è esattamente così, nel senso che Snap come architettura in generale è tutta open e può essere replicata da terzi (esistono anche progetti comunitari in merito). La differenza è che Flatpak usa un sistema decentralizzato, quindi basta aggiungere un nuovo repository (e ce ne sono già diversi disponibili, con Flathub che è quello più grande) e lo estendi, mentre Snap è fortemente centralizzato (e l'unico store al momento esistente, e probabilmente l'unico che ci sarà nel lungo periodo se non per sempre, è quello di Canonical)... Dopodiché sta alle distribuzioni decidere se passare per Canonical, farsi un proprio store Snap (anche se non dico che è improponibile, ma sicuramente è poco conveniente), oppure abbracciare Flatpak che sta lì e al massimo lo estendi con poca fatica. Va da sé che la stragrande maggioranza (se non praticamente totalità) di progetti minori hanno abbracciato o abbracceranno Flatpak, mentre le aziende concorrenti non hanno intenzione di passare per Canonical o reimplementarsi Snap quindi nuovamente al massimo punteranno a Flatpak...
@@geekonerd si è quello che intendevo dire i server per gli snap sono di canonical ed è proprietario, per distribuire uno snap bisogna passare per canonical, poi il formato snap il client è opensource, almeno cosi ho capito io
Se vuoi usare gli Snap attuali devi passare per forza per lo store di Canonical, perché come ho detto anche nel video Snapd verifica la chiave associata al pacchetto con quella registrata nell'account dello sviluppatore su Snapcraft (la parte server side è closed source, tutto il resto è open). Però puoi creare un intero Snap store alternativo e produrre nuovi Snap che possano essere certificati per quello, bypassando Canonical. Il problema è che fare una cosa del genere significa mettere in piedi/replicare tutta l'infrastruttura Snapcraft, che come dicevo nell'altro commento è praticamente irrealizzabile per i progetti comunitari più piccoli e non è particolarmente vantaggiosa per i competitor di Canonical (Red Hat, SUSE, etc). Significherebbe avere inoltre più pacchetti Snap per store diversi, e che gli sviluppatori dovrebbero creare apposta per store diversi (e chi glielo fa fare?) 🙃
@@geekonerd allora non conviene molto. snap usa app pesanti e poco performanti rispetto alle stesse identiche app degli altri pacchetti. avere un sistema container ed essere impedito di usare l'app del pacchetto "X" mi gira parecchio ed andrà a vanificare il vantaggio dei container. ubuntu è sempre meno open e più minc.hiate
Non saprei, non noto particolari differenze di prestazioni sul mio computer tra snap e pacchetti nativi (o altri formati). Inoltre, non ha molto senso paragonare snap come è implementato su Ubuntu rispetto a com'è in Core, visto che lì è componente portante di tutto il sistema, ergo difficile dire "va lento, è pesante, etc" (anche perché non c'è neache un paragone attuabile). Aggiungo che in generale non è più pesante di altre soluzioni containerizzate. Riguardo l'essere meno open, anche qui non mi pare proprio: tutto lo stack snap è open source, l'unica parte closed è lo store tramite cui gli snap sono distribuiti, ma non è che se un negozio digitale è chiuso allora lo è anche tutto quello che c'è a contorno, che infatti rimane open
@@geekonerd devi cercare... chiaramente dipende dalle varie app, ma in genere se compari la stessa APP con i 4 metodi di pacchetti, noterai le differenze sia di peso che di prestazione. esempio snap sono pacchetti + universali, quindi avranno al loro interno codice che servono un po' tutte le distro,(in un container questo ha senso? no) quindi il file peserà di +. inoltre userà più cpu e memoria. flatpak sarà meglio sia di peso pacchetto che di gestione risorse, (ma anche qui sarai relegato alla distro). appimage è quella con un peso minore, ridotto all'osso, prestazione simili a flatpak, ma tante volte non parte anche se dovrebbe partire perchè è creato per funzionare su tutte le distro. aur tutto ottimizzato al max, ma alcune volte ci sono problemi... x via delle retro incompatibilità che nel caso container non sussistono più perchè slegato dal kernel, driver etc... in definitiva per non incasinare il sistema si usa distrobox e in base a quel che ti piace di più installerai l'app da dove vorrai sul container "y". e questo mi sembra il modo più democratico. x far felici tutti quanti. purtroppo ubuntu si incapponisce su soluzioni peggiorative, per questo sono rimasto davvero sorpreso che stanno implementando in parte quello che avevo in testa non me lo sarei aspettato mai da loro. già gli utenti ubu, preferiscono usare flatpak a snap cmq.
@@duracell211 non ho molto da cercare fortuntamente perché sono abbastanza ferrato sull'argomento. Per quanto riguarda il "peso" inteso come dimensione, qualsiasi soluzione containerizzata sarà ovviamente più "pesante/grande" di una non containerizzata, perché appunto contiene tutte le dipendenze necessarie per funzionare. Questo significa, però, che quando si fa il conteggio della dimensione, anche per le app native andrebbero conteggiate le dipendenze, così da fare un confronto più veritiero. E a quel punto il discorso cambia un po'. Snap e Flatpak, inoltre, possono condividere le dipendenze in modo da non doverle necessariamente duplicare in ogni app (ovviamente non tutti gli Snap e Flatpak lo fanno), quindi il conteggio sul peso è più complesso di così. Oltretutto consentono di usare versioni diverse delle stesse librerie, cosa che con le soluzioni "native" non riesci a fare in modo altrettanto facile. Detto ciò, non è sempre vero che i Flatpak pesano meno degli Snap, anzi nella mia esperienza è spesso il contrario; ma ancora una volta sono confronti che lasciano molto il tempo che trovano perché si deve andare caso per caso. Inoltre, nel 2024 il peso su disco personalmente lo ritengo un problema molto relativo avendo facilmente a disposizione GB e GB (se non TB) di spazio. Ovvio che stiamo parlando di soluzioni che guardano al futuro e non sono ideali per PC di 10+ anni fa. Questione diversa riguarda il peso in RAM, e seppur le soluzioni containerizzate occupino più risorse, anche qui è tutto relativo: anche usare distrobox (che tra l'altro io uso quotidianamente per lavoro, più di 8h al giorno, tutti i giorni) porta ad un consumo maggiore di memoria rispetto ad utilizzare app native, ma ovviamente lo si usa perché ha tanti altri vantaggi. Ma lo stesso vale per le app containerizzate tramite Snap, Flatpak, AppImage o quel che sia. Dopodiché usare distrobox/toolbx/podman/docker o quel che si vuole ha comunque i suoi lati negativi (ad esempio sono di sicuro molto meno user-friendly rispetto ai semplici Snap/Flatpak/AppImage), oltre al fatto che stai semplicemente spostando fuori dalla base gli stessi identici problemi che hai con la distribuzione tradizionale del software. Per quanto riguarda Canonical, mi pare anche abbastanza normale che provi proprie strade, così come fanno un po' tutti del resto. Dopodiché se ci sono strade migliori e/o alternative altrettanto valide, mi sembra che Canonical sia anche sempre stata la prima a cambiare rotta. Mentre sulla questione che gli utenti ubuntu preferiscono Flatpak a Snap è abbastanza una leggenda metropolitana, che vive più che altro sui social network. La realtà dei fatti è che o 1) agli utenti non frega nulla perché tecnicamente non sanno neanche che differenza ci sia (o ancor di più, non sanno neanche dell'esistenza stessa di Snap o Flatpak), o 2) si usa quello che serve e spesso ci sono app (soprattutto closed) che sono disponibili solo come Snap. Detto ciò, Snap consente molte più cose rispetto a Flatpak ed è questo il motivo per cui Canonical continua a spingerne l'utilizzo. Con Flatpak ad esempio non sarebbe possibile realizzare la distro "immutabile" che stanno sviluppando (né sarebbe potuta mai nascere Core), senza contare che Snap esiste da prima di Flatpak
