Le piccole dev-board a bassa potenza sullo stile di Raspberry Pi stanno cavalcando l’onda del successo e Canonical ha intenzione di dare una spinta in più.

Uno degli aspetti da migliorare nel campo dev-board è l’assistenza post-vendita all’utente finale. Sappiamo quanto sia importante la componente software in questo settore, ce lo ha dimostrato proprio Raspberry Pi.

App store per le Orange Pi

orange pi

In mancanza di un gruppo di coders volontari, quindi, il team di Orange Pi ha deciso di collaborare con Canonical creando un App Store per tutte le board Orange Pi basate su Ubuntu Linux.

Tecnicamente la maggior parte dei sistemi operativi GNU/Linux ha un suo “app store”, seppur sotto forma di pacchetti/repository, che permette di scaricare e installare software utilizzando comandi da riga di comando come apt-get o strumenti GUI come Synaptic. Il nuovo Orange Pi App Store sarà completamente basato sul sistema Snap.

Al di là dei metodi di scaricamento, comunque, va preso atto che Shenzhen Xunlong Software e Canonical hanno lavorato insieme per far crescere sia la community delle Orange Pi sia quella di Ubuntu, quindi per un vantaggio reciproco. Ricordiamo che le dev board della società supportano anche altri sistemi operativi, come Android, Debian e Raspbian.

Sharing is Caring

Vi ricordiamo che seguirci è molto semplice: tramite la pagina Facebook ufficiale, tramite il nostro canale notizie Telegram e la nostra pagina Google PlusDa oggi, poi, è possibile seguire il nostro canale ufficiale Telegram dedicato ad Offerte e Promo!

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

  • sinceramente preferirei un raspberry 3, almeno ha un quad core cortex A53 e non un vecchio cortex A7, e poi la community che c’è dietro è molto maggiore.
    tante board anche più potenti del raspberry 3 poi all’atto pratico risultano meno performanti, perchè non si riesce a sfruttare l’accelerazione 3d (per esempio).
    quindi tanto vale buttarsi su un rpi3 o in futuro sul 4 (sperando che finalmente avrà 2GB di ram)

    • Maddo

      Per il Raspberry Pi 4, stando alle parole del founder, non arriverà prima del tardo 2019 a quanto pare, semplicemente perché devono passare a un processo produttivo a 28nm, contro gli attuali 40nm, essendo arrivati al limite come temperature e tecnologia(si è inoltre detto che l’rpi3 avrà un ciclo di vita di almeno 3 anni).

      • capisco.. allora per il 2019 mi auguro che mettano una connessione cigabit almeno una usb 3.0 e 2/3 gb di ram, tanto per il tardo 2019 ci sono ancora più di 2 anni e da qui a 2 anni penso che un hardware del genere riescano a venderlo al solito prezzo (che è l’obbiettivo dei raspberry mantenere sempre lo stesso prezzo)

        • Maddo

          Esattamente, e anch’io mi associo al voler 2GB di RAM, e mi spingo pure oltre dicendo che vorrei un modello B con 4GB di ram. Come chip si vocifera che sarà il BCM4908, quad-core 1.8GHz a 28nm, con 2.5Gbps Ethernet, wifi 802.11ac con un processore integrato capace di permettere l’offload dei processi di rete dalla CPU principale, liberando risorse(cosa che può solo fare piacere).

      • giacomiX11

        Rpi3 ha il soc a 40nm?

        • Maddo

          Sì, l’rpi4 si vocifera farà il salto a 28nm.

    • Kim Allamandola

      Posso chiedere per cosa vuoi usare una miniboard?

      Personalmente le vedo bene come router, le poche che han abbastanza porte e performance adatte
      anche a connessioni moderne, non tipo le ADSL italiche per capirci, miniserver locali (es. MediaGoblin
      per ospiti/bambini in/di casa) o appliance per farsi degli stb (decoder sat/terrestri) personali/usabili
      visto quel che gira di pronto in commercio. Per tutti questi usi l’accelerazione 3D serve a ben poco o
      a nulla, mentre la ram può far anche molto comodo, anche in “pezzature” da 4G e più, le porte eht,
      espansioni MiniPCIe ecc idem… Sono curioso più che altro perché al di la di usi giocattolo (cluster,
      e altre cose “didattiche” o del tipo che vorrei io non l’ho mai veramente sentite usare né RPi né altri…

      • se ne prendessi una vorrei usarla, come server casalingo (torrent, apache, mysql) nas (quindi anche come server ftp) per i backup via LAN, e come mediacenter per vedere film (ovviamente anche in alta qualità), per questo necessito anche dell’accelerazione 3d, altrimenti fanno fatica a far girare film pesanti

        • Kim Allamandola

          Quindi vorresti la miniboard collegata, per dire, all’hdmi della tv del salotto, mentre fa anche da server domestico. Interessante, non avevo pensato a questo scenario, grazie.

          Ma come backup che storage ci colleghi su una miniboard?

          • non avendo un collegamendo sata, l’unica è collegarci un HDD tramite usb

          • comunque si l’idea è quella di collegare la miniboard al tv, alla lan, così posso usarlo contemporaneamente sia per vedere film, sia per fare il backup dei pc di casa, sia per farci girare il server LAMP.
            però per fare queste cose, un rpi è ancora troppo limitato, magari un futuro rpi4 sarà migliore, inoltre per fare questo mi serve pure l’accelerazione 3d.
            se magari un rpi4 riuscirà ad avere almeno 3gb di ram, una connessione gigabit e magari un connettore sata, allora sarebbe perfetto, ma il loro obbiettivo è mantenere sempre lo stesso prezzo, e non so se per quel prezzo riusciranno per il prossimo raspberry a fornire tutte queste cose

          • Kim Allamandola

            Per un stb + mediagoblin per i vari “guest” dotati dei più svariati dispositivi mobili che più o meno
            è quel che vuoi tu stò usando un minipc assemblato con una mobo ASRock j3455m, 8Gb di ram
            1 SSD e 1 HD (la parte tv è una scheda TBS gestita con tvheadend&c), è certo un po’
            sovradimensionato e la mia configurazione sw è tutto fuorché tune-ata per esser efficiente ma…
            se per dire guardi un canale HD e fai streaming di un po’ di contenuti mediagoblin e/o un altro
            canale anche non HD il systemload sale, l’OS resta ben responsivo ma comunque carico.

            Sul Pi2 avevo provato a piazzare Yate per far un minicentralino (essendo emigrato ho un po’ di
            numeri VoIP italici per i contatti italiani, più francesi e svedesi e mi piaceva sperimentare un po’)
            e reggeva ma di misura, già con Asterisk era praticamente inusabile.

            Ora non è ho mai fatto veramente nulla con cura: Ubuntu desktop appena strippata sul miniPC,
            raspbian sul raspi, tutto o quasi dai repo, ma anche a lavorarci parecchio non so quanto in più
            ci tiri fuori… Per questo ero curioso di sapere come fai 🙂

      • Maddo

        Server casalingo(non LAMP però, preferisco nginx+jekyll per il mio blog, semplice, veloce, sicuro, niente grane di db), repo slackbuild locale(avendo slackware), seedbox, capper TV(per registrare quei pochi programmi che mi interessano e che non ho il tempo di vedere causa orari, motivo per cui ho anche acquistato la licenza mpeg-2 per pochi soldi), gestore di rete locale e tutto ciò collegato a un NAS casalingo via rete(molto meno sbatti di qualsiasi hdd esterno via usb).

        • Kim Allamandola

          Per l’uso TV non ho praticamente esperienza: ho dato una googlata generica e delle varie soluzioni trovate mi son fermato su TVHeadend anche perché non uso telecomandi, ho messo una minitastiera BT con touchpad integrato da una parte ed un monitor Asus VT207N dalla seconda postazione, almeno l’uso “computer” è passabilmente umano. Lato backup un miniserver Supermicro, non voglio i miei dati su NAS proprietari per quanto GNU/Linux based!

          Ma come ferro che usi? Un PC, sia pur mini, o qualche “board” preconfezionata?

          • Maddo

            Il primo RPi, che penso pensionerò in futuro per un’altra board ARM, poiché per quanto l’abbia overclockata non poco, è comunque una board soft-float, con processore scarso e ormai deprecata come supporto(uso slackware ARM sulla board, più o meno replicando il setup che ho sul fisso dove ho slackware 14.2).

          • Kim Allamandola

            ? Fai girare su un singolo raspi 1 nginx più tutto il resto ?
            O veramente non mi son mai curato di ottimizzare le risorse o non oso immaginare il systemload!!!

          • Maddo

            nginx deve servire due cose soltanto, la webui di rtorrent e un blog jekyll(che è statico a differenza di wordpress e soci che son CMS dinamici). Non so se hai presente la differenza tra sito statico e sito dinamico, ma sostanzialmente il sito dinamico è pre-compilato e servito a mo’ di file, quindi anche nei suoi momenti peggiori sarà sempre e comunque più veloce di qualsivoglia sito dinamico. Inoltre non c’è nessun database ad esso legato, quindi a maggior ragione. Conta che di default non ho sessioni X su rpi, perché appunto mi serve come server quindi faccio tutto tramite cli via ssh. Ah dimenticavo, anche se è un’operazione assolutamente a costo zero come risorse, ho uno pseudo-bot IRC sempre sull’rpi, che mi fa da logger per i canali che frequento con un cronjob ogni primo del mese che prende i vecchi log, li divide per canale, li comprime in un archivio che viene nominato nomecanale_mese_anno e li butta su nas. Con l’rpi, anche l’1, si possono fare tante cose, il punto è se queste cose poi servono o son solo divertenti come esperimenti.

          • Kim Allamandola

            Yep, ho usato Jekyll via org-mode tempo fa, ma il solo nginx che serve l’index.html di default non è
            proprio leggero (ram) per una board di quel genere… Se poi ci metti anche un client torrent (che per
            leggero che sia lui di CPU ne vuole, idem di storage e anche di ram), poi ci metti anche uno streaming
            server che non è pesantissimo ma la sua massa la fa… ‘Somma non riesco a immaginare quanto sia
            carica la tua rpi 😀

          • Maddo

            Streaming server? No l’rpi lo uso come capper, non streama nulla, deve solo riprodurre e registrare i programmi televisivi(che sono in formato .ts MPEG-2, che se compri il codec viene decodificato via GPU, con la CPU sola non regge a meno che non si parli di SD).

  • Kim Allamandola

    Canonical da tempo ha un negozio di oggetti fisici (magliette&c brandizzate, penne usb, mug&c brandizzati ecc)
    dunque perché no. Anzi se Canonical “sovraintende” spedizioni, gestione garanzie ecc ben venga.

    Ad oggi la maggior parte dei vendor sono hw-centrici, data l’importanza del software avere vendor incentrati
    sul software open che offrono anche hw testato è un’ottima cosa. Solo su snap ho MOLTE riserve.

    • Maddo

      Ehm, si sta sparlando del software center, non di canonical che fa rivenditore di orange pi.

      • Kim Allamandola

        Ops, ho letto dentro elfeed il sommario, guardato l’immagine con la striscia led…
        aspergo il capo di cenere.

    • Aury88

      che riserve per gli snap?
      Purtroppo l’articolo parla solo di store software, niente hardware. concordo comunque che la vendita diretta di hardware supportato-certificato e con magari preinstallato ubuntu (vista la natura di queste board è una cosa però inutile…il so è su un sd card) ed esteticamente ribrandizzati sarebbe stato un ottimo completamento dello store di canonical che al momento, a parte le chiavette USB, vende praticamente solo abbigliamento e poco altro (che è un po’ un assurdità)…penso sia fatto però in maniera voluta per non indisporre alcun produttore/rivenditore mettendosi a fare concorrenza…se si volesse un aggiunta del genere forse conviene solo mostrare l’hardware e poi dare un link diretto allo store del produttore/rivenditore oppure fare solamente da intermediario nella vendita

      • Kim Allamandola

        Il riassunto è che gli snap sono un’ennesimo workaround limitato, limitante
        e problematico il cui scopo è evitare di affrontare un problema architetturale.

        Motivazione (scusate la lunghezza)… In ambito *nix si scelse eoni fa di
        compilare dinamicamente anziché staticamente principalmente per:
        – maggiori review del codice: i programmatori sviluppano, i packagers di
        ogni distro prendono il codice, compilano/impacchettano (ovvero si guardano
        il codice, per lo meno se non compila, per studiare che opzioni ha ecc).
        – maggior sicurezza: se una libreria molto usata ha una vulnerabilità
        il suo packager è facile che lo sappia rapidamente e rapidamente impacchetti
        l’update. Tutti gli altri packagers non han niente (o quasi) da fare, l’utente
        si riscarica la libreria e basta.
        – forza sviluppatori e packagers a stare al passo coi tempi/coi loro upstream
        poiché se una libreria cambia le API e questa è gestita da altri o il tuo
        programma smette di funzionare o devi svegliarti e aggiornare. I packagers in
        genere patchano l’upstream nell’interim, l’upstream si trova varie patch e
        quindi varie “idee” di come evolvere ecc. ‘Somma c’è un maggior lavoro lato
        distro (se hai mai usato FreeBSD con un po’ di ports o Gentoo con un po’ di
        ebuild ti è certamente capitato di dover imprecare perché l’agg. di una
        libreria ha rotto qualche port/ebuild, perché hai problemi con le
        useflags/vars, perché scopri una dipendenza circolare ecc) ma un miglior
        sistema per tutti.

        La soluzione statica toglie gran parte del lavoro: gli sviluppatori stessi
        impacchettano la distro e gli utenti li usano. Fine. Le distro diventano solo
        “fornitrici” d’un os “di base” e gli sviluppatori diventano i soli a
        controllare le loro applicazioni. Mancano quindi le patch e le review dei
        packagers, vi sono rischi di sicurezza perché se una libreria molto usata ha
        una vulnerabilità l’unico modo per averla aggiornata è aspettare che tutti
        gli sviluppatori, anche quelli del piccolo client di chat che usa quella
        libreria ma non la conosce minimamente, si aggiornino. Devi ovviamente agg.
        uno stuolo di applicazioni ecc. In sintesi: meno lavoro, più problemi.

        Lato commerciale si è arrivati al “DevOps”: ovvero giacché gli admin si son
        rotti e rompone le scatole di mostri scritti alla $OrganoRipMaschileDiCanide
        e son iperlenti ad aggiornare li si toglie dai piedi dando potere agli
        sviluppatori che di operation nulla sanno e ragionano non in termini di
        infrastruttura ma della loro workstation personale, lato open si è arrivati
        a MAAS, agli snap ecc.

        Qual’è in effetti il problema di fondo? IMVHO è che non abbiamo storage
        adeguato alle necessità attuali. Se lo zfs fosse andato avanti, se oltre allo
        zpl avesse sviluppato altri layer sopra lo storage, potremmo avere pkg-man e
        installer umani, questo toglierebbe una parte di lavoro delle distro dando
        più tempo per dedicarsi agli update dei pkg e la situazione resterebbe
        sostenibile, in più i pkg stessi sarebbero molto più controllabili, limitabili,
        senza bisogno di soluzioni draconiane come le partizioni di sistema operativo
        (da lxc+docker di moda ai ben più vecchi e superiori jails di FreeBSD o zones
        di Solaris). Si potrebbe evolvere ecc. Oggi però siamo nell’era che non si
        posson più fare grossi progetti, bisogna aver risultati rapidamente e con poco
        sforzo e il risultato è che anziché avanzare arretriamo.

        Pensa a uno snap di chessò Libreoffice: pensa a come gestisci i documenti che
        salvi da L.O. o come fai ad aprire un allegato dalla mail a L.O.: solo con
        dei hack improbabili, scomodi e potenzialmente forieri di svariate
        vulnerabilità. Pensa a quanto devi scaricare quando esce un agg. di OpenSSL,
        pensa ai potenziali problemi di sicurezza se qualche sviluppatore decide di
        non aggiornare il suo snap perché tanto gli va bene così ecc, in ultima analisi
        pensa a Windows perché le soluzioni che oggi si spingono in ambito open sono le
        soluzioni che Windows scelse molti anni fa, come si è evoluto lo sappiamo. E oggi
        ci inventiamo queste trovate per risolvere problemi che ai tempi di Multics/Plan9
        eran già stati visti e molto meglio risolti. È il problema dell’ignoranza nelle masse:
        più ti allarghi più avrai gente che non vede problemi, che crede di aver soluzioni
        banali a tutti i problemi del mondo e starnazza, con buon seguito, che bisogna fare
        a un certo modo…

        • Aury88

          premesso che non sono così tecnico da capire tutto, ti rispondo a livello generale solo per la problematica sicurezza che è stata discussa in passato a profusione anche a livello nabbo (è quindi l’unica che ho potuto seguire): il problema è che nessuno assicura la bontà del codice. vedi varie vulnerabilità di librerie scoperte quasi un decennio dopo. il fatto di avere un programma aggiornato e basato su librerie aggiornate non esclude la presenza di bug sfruttabili. l’idea quindi è di sandboxare a prescindere dalla bontà del codice e delle librerie usate per cui un applicativo può creare danni unicamente all’interno della propria cartella. è vero quindi che si rende possibile usare codice non aggiornato o pieno di bug di sicurezza ma è anche vero che questo codice è molto limitato per la capacità d’azione.
          Un’altra questione è che negli snappy anche se si usano librerie interne (è da mesi che è possibile utilizzare librerie esterne, cioè snap esposti all’utilizzo da parte di altri, realizzate da programmatori/progetti “certificati”) queste vengono esplicitate e di fatto se c’è una libreria compromessa è facile risalire a quali snap la sfruttano e quindi bloccarli.
          se è anche vero che il lavoro di porting generalmente è svolto dalle varie distro non sempre è così…anzi! il fatto di avere pacchetti creati ad-hoc per distro 1, distro 2, distro3, distro4 ecc è comunque un lavoro in più sia per gli sviluppatori dell’app sia per gli sviluppatori delle distro…questo unito al fatto che molte distro non aggiornano istantaneamente sostituendo librerie con vulnerabilità e che vulnerabilità meno gravi in pacchetti critici vengono corrette solo con nuove release (e ogni distro ha frequenze e periodi diversi di aggiornamento) lascia esposti comunque gli utenti a molti problemi per un periodo di tempo più o meno lungo e il programma ha il rischio di non funzionare. in questa maniera invece si lascia più tempo a tutti per sviluppare il proprio software (ed ogni aggiornamento non deve venir portato per ogni distro)dedicarsi di più (si spera) alla pulizia del codice e all’utilizzo di librerie nuove e gli aggiornamenti sono staccati dall’aggiornamento della distro e rimangono comunque isolati.
          sembra sì una pezza, ma non è possibile avere un sistema esente da bug e allora l’unica è imho un buon sistema di confinamento (per esempio selinux o apparmor) centralizzato e controllare e affidarsi unicamente a quello per controllare la sicurezza del sistema.

          • Kim Allamandola

            > nessuno assicura la bontà del codice.
            La miglior sicurezza è che il codice passi da tanti occhi, tieni presente
            che anche a far review pesante tipo OpenBSD non c’è miglior review che dover
            capire il codice perché non gira come vorresti. Se lo fai asetticamente per
            lavoro produci come un/a prostituta/o vs l’amante, il/la primo/a ha magari
            molta più esperienza e competenza, ma non ci mette quel quid che fa la
            differenza.

            > vedi varie vulnerabilità di librerie scoperte quasi un decennio dopo.
            Vedi quante di queste vulnerabilità sono state scoperte in ambito open e
            quante vengono scoperte, ogni giorno in ambito closed…

            > l’idea quindi è di sandboxare a prescindere dalla bontà del codice
            AppArmour questo fa come si deve, Selinux vorrebbe far anche di più ma è
            di fatto un fallimento per complessità, non è certo snap che “sandboxa”
            veramente poiché hai bisogno di accessi ai dati condivisi (vedi il classico
            scarichi da browser, client torrent, … e riproduci con un player, scarichi
            un allegato e apri con un viewer/editor), se snap è “chiuso” non puoi lavorare
            se non nel cloud, altrimenti la sandbox è come aver la porta blindata e la
            finestra aperta. Come ho scritto sopra prova lo snap di LO capirai, aggiungici
            quello di Dekko (un MUA, client di posta), prova ad aprire un allegato dalla
            mail e modificarlo con LO.

            > Un’altra questione è che negli snappy anche se si usano librerie interne (è
            > da mesi che è possibile utilizzare librerie esterne, cioè snap esposti
            > all’utilizzo da parte di altri, realizzate da programmatori/progetti
            > “certificati”)
            Ovvero hai fatto la sandbox, hai capito che non puoi lavorarci dentro e l’hai
            bucata, ottimo risultato…

            > queste vengono esplicitate e di fatto se c’è una libreria compromessa è
            > facile risalire a quali snap la sfruttano e quindi bloccarli.
            Col sistema attuale non blocchi, ovvero impedisci di usare, nulla. Chi
            aggiorna la libreria vede che ci son dei pacchetti rotti, siccome chi fa ciò
            sono i packager della distro, son collegati tra loro: parte una notifica ai
            packagers dei pkg rotti che agiscono, patchando in genere, i loro pkg e
            avvisando l’upstream. L’utente si trova tutto che funziona e il codice
            passa da tanti occhi…

            > il fatto di avere pacchetti creati ad-hoc per distro 1, distro 2, distro3,
            > distro4 ecc è comunque un lavoro in più sia per gli sviluppatori dell’app
            > sia per gli sviluppatori delle distro…
            Assolutamente NO! Chi sviluppa la distro si occupa di kernel+userland, i
            porters/packagers si occupano del resto, chi sviluppa l’app di quella si
            occupa e basta. Non c’è alcun lavoro extra per nessuno, semplicemente il
            processo “industriale” passa per una serie di soggetti, col sistema snap&c
            elimini uno di questi. Lo sviluppatore, opensource, sviluppa sulla sua
            distro rispettando (in teoria) le specifiche lsb, freedesktop ecc. I
            packagers impacchettano. Fine. Se il suo codice non va sono i packagers che
            glielo fan notare, magari contribuendo con patch.

            > questo unito al fatto che molte distro non aggiornano istantaneamente
            > sostituendo librerie con vulnerabilità
            Le distro son tanto più veloci quanto maggiore è la base di utenti, ma tu
            pensi che i singoli sviluppatori delle singole app siano più veloci? Loro
            l’ultima cosa che vogliono è occuparsi delle loro dipendenze, a loro interessa
            il loro codice, le dipendenze meno cambiamo meglio è perché ogni cambiamento
            è lavoro extra per loro! Al contrario chi impacchetta non ha da preoccuparsi
            di “far evolvere” l’applicazione, a lui interessa che il pacchetto funzioni
            bene sulla sua distro che ben conosce.

            > ed ogni aggiornamento non deve venir portato per ogni distro
            Ben peggio: un aggiornamento di una libreria maggiore deve propagarsi tra
            tutti gli snap (ovvero se agg. OpenSSL ti trovi a scaricare mezza distro)
            mentre nella maggior parte dei casi un agg. di una libreria lascia intonsi
            ed intoccati i suoi “utilizzatori”. Il “porting” mica lo fan gli sviluppatori,
            lo fan i packagers, che solo questo fanno e questo voglion fare. Il solo
            problema è, di nuovo, per il software proprietario che non ha una community
            che si divide il lavoro.

          • Aury88

            “Vedi quante di queste vulnerabilità sono state scoperte in ambito open e
            quante vengono scoperte, ogni giorno in ambito closed…” ma qui non è un confronto open vs closed (che è il motivo semmai per cui ci siano molti più bug in ambito closed non la non condivisione di pacchetti) stiamo parlando di una pacchettizzazione differente non di chiusura del codice.
            “AppArmour questo fa come si deve” si, non intendevo dire che è snapd di per se ma di fatto snapd utilizza apparmor per effettuare il sandboxing e guai se si prova a caricare un pacchetto fatto per una versione di apparmor troppo vecchia
            “Ovvero hai fatto la sandbox, hai capito che non puoi lavorarci dentro e l’hai
            bucata, ottimo risultato…” non stiamo parlando di aprire finestre o avere accesso di scrittura lettura, stiamo parlando di poter sfruttare l’output di librerie esterne per le operazioni e questa cosa deve venir richesta per esplicito dal pacchetto snap, viene gestita da snapd e quindi limitata-controllata da apparmor il tuo pacchetto sfrutta un bug dela libreria condivisa? hai compromesso solamente la cartella del tuo pacchetto e quello della libreria, prima quello stesso pacchetto che sfruttava la stessa libreria con lo stesso bug poteva scrivere in tutte le cartelle di colui che ha lanciato l’applicativo.

            “Le distro son tanto più veloci quanto maggiore è la base di utenti, ma tu
            pensi che i singoli sviluppatori delle singole app siano più veloci?”
            canonical un aggiornamento ogni 6 mesi…un po’ tutte le app click e snap vagamente supportate: anche un aggiornamento ogni settimana. poi per carità, ubuntu ha anche rilasci giornalieri nella versione develop ma le usano solo i develop. anche la versione develop dopo il freeze blocca gli aggiornamenti delle dipendenze e lo mantiene a quella versione, salvo bug critici, per i successi 6 mesi…se vuoi la tua app con gli ultimi aggiornamenti devi passare al successivo ramo di sviluppo, che però non è l’ambiente ideale di lavoro

            ripeto: non è detto che la figura del packager venga eliminata. semplicemente se prima uno voleva la propria app su più distro possibile doveva sperare nell’interesse dei packagers di ogni distro viceversa adesso potrebbe, ma non è tenuto a farlo (comunque pacchettizzare in snap da un sorgente su github è solo un link da mettere nello .yaml) il lavoro extra è chiedere a più packagers di fare lo stesso lavoro ma specifico per ogni distro quanto in realtà potrebbero collaborare per fare un unico pacchetto (sia esso snap o flatpak o altro).

            “Col sistema attuale non blocchi, ovvero impedisci di usare, nulla. Chi aggiorna la libreria vede che ci son dei pacchetti rotti, siccome chi fa ciò sono i packager della distro ” che aggiornano secondo i tempi di riascio della distro e quindi nel frattempo hai app obsolete e devi affidarti a repository sperando di non rovinare nulla…a meno che non facciano un repository esterno e scarichino il problema dipendenze all’utente. a me questo processo di aggiornamento non mi m così immediato , nelle altre moltissimi cambi di versione devono aspettare la nuova versione della distro, le uniche sono le rolling e i rami develop-testing
            “Al contrario chi impacchetta non ha da preoccuparsi di “far evolvere” l’applicazione, a lui interessa che il pacchetto funzioni bene sulla sua distro che ben conosce.” fregandosene quindi se è uscita una versione migliore della libreria tal dei tali se questa non è supportata dalla propria distro. questo imho conferma che è il programmatore quello che è più interessato ad un codice efficacie ed efficiente, è quello che lo conosce meglio ed è quello che una volta che non sarà limitato dai default della propria distro provvederà ad utilizzare le librerie migliori, non quelle che si ritrova di dafault.
            “Ben peggio: un aggiornamento di una libreria maggiore deve propagarsi tra
            tutti gli snap” le librerie più grosse le si sta già condividendo (concentrando l’attenzione sulla bontà di questi pacchetti) e per quanto riguarda lo scaricare l’intera distro si scaricano solo le differenze tra le righe di codice, non l’intero pacchetto.

          • Kim Allamandola

            Hola!
            Scusa la tarda risposta son sta 3gg in Italia e non ho avuto tempo 🙂

            > ma qui non è un confronto open vs closed […] stiamo parlando di una
            > pacchettizzazione differente non di chiusura del codice.
            Vero, ma in parte, perché come non basta “avere codice pubblico” per essere
            opensource, ovvero con una community che sviluppa, che può usare il codice
            ecc vs progetti open tipo Alfresco/Nuxeo, OpenBravo &c che sono si open (più
            che altro perché usando componenti GPL devono ripubblicare a loro volta) ma
            son privi di community e pubblicano codice in maniera tale che capirlo e
            forkarlo è più complicato che ricominciare da capo non basta avere un repo
            su GitHub e distribuire snap “free as in freedom” per seguire il modello
            open. Gli snap servono principalmente a due categorie di tecnici:
            – quelli closed source che non vogliono dare codice o binari ai packagers
            e dovendosi far tutto in casa per ogni distro non possono sostenere la
            mole di lavoro, normalmente fatta dai singoli packagers delle singole
            distro
            – admin privi di un’infrastruttura IT decente (iow automatizzata come si
            deve) che devono gestire app complesse, normalmente non costituite da un
            solo pacchetto
            A nessun altra categoria servono gli snap (e rinnovo l’invito a provare lo
            snap di LibreOffice provando ad aprire un documento presente sul proprio hd).

            Poi che la pacchettizzazione attuale non renda facile la vita in certi casi
            è un’altro discorso che ho fatto spesso: abbiamo bisogno di soluzioni di
            storage adatte ai tempi attuali, da cui possano derivare installer e pkg-man
            adatti ai tempi attuali. La SUN con zfs sopra il quale son nati IPS, i BE
            ecc ha mostrato la via ma è morta prima di arrivare ad un risultato pubblico
            come lo zfs in se. Mi spiego: oggi molti utenti, tecnici inclusi, ce l’han
            col fatto che ad ogni release per avere un sistema pulito serva una fresh
            install e quest’ultima per quanto la si automatizzi richiede comunque molto
            lavoro. Per capirci non abbiamo un installer che “chiede un file di conf”
            banale, “chiede su quali macchine installare” (localhost, serie di macchine
            in LAN ecc) e fa il lavoro del caso. Oggi per automatizzare un’install bare
            metal (iow da zero) serve un preseed/kickstart/… che è un incubo da fare
            bene, serve un host che faccia da mirror apt/*, serve FAI/Cobbler/LinuxCOE/*
            per bootare una o n macchine, Salt/Ansible/script personali per la post-install
            ecc, in altri termini servono ore di lavoro e test non banali.

            La SUN aveva iniziato a cambiar questo. Su OpenSolaris/IllumOS hai il concetto
            di BE (Boot Environment) ovvero dell’OS installato in un volume zfs che puoi
            clonare, installarne uno nuovo, modificare, ecc e provi semplicemente con un
            reboot (anche quickboot, ovvero senza far rifare il post alla macchina solo
            switchando kernel al volo). Non va? No problem, rivvii su un altro BE che sai
            funzionare. IPS non era concretamente ancora integrato ma la strada era di fare
            dei pkg che sono una sorta di volumetti zfs leggeri, aggiornati a livello di
            blocchi con dei send&recv, checksummati ecc, distribuibili ed usabili senza
            “archivi” da spacchettare e spargere su un filesystem ecc. Caiman (l’installer)
            avrebbe dovuto seguire: una GUI/TUI/Script/API che semplicemente gestisce lo
            zfs in locale come via rete, l’install è una mera composizione di pool, volumi
            e “volumetti”. Al livello superiore le applicazioni possono continuare ad usare
            le API POSIX classiche (il “filesystem” classico) che in effetti è una mera
            “vista” dei dati fisicamente salvati (lo ZPL dello zfs), per esempio
            l’equivalente di fuse con sshfs&c. Questa era la strada valida proposta.
            C’erano (e ci sono tutt’ora) le zones come partizioni di sistema operativo
            che vivono a loro volta sopra lo zfs e possono essere composte a livelli
            inferiori allo ZPL ovvero al filesystem.

            Questa architettura (parte prototipo, parte POC, parte production-ready)
            permetterebbe benissimo di avere dei pkg-man comodi e dinamici come quelli
            attuali, nuovi installer adatti agli attuali bisogni ecc. solo che la SUN
            per farla c’ha messo 5-8 anni, ed era ancora ben lontana da aver finito.
            Oggi qualsiasi progetto così lungo è chiamato follia ed il risultato è che
            si spera di tirar fuori dal cappello soluzioni banali che sfruttino le
            tecnologie attuali senza troppa fatica, ottenendo quasi sempre delle torri
            di babele che han più problemi e dan più problemi di quelli che vogliono
            risolvere…

            Sulla velocità di aggiornamento ti domando: hai mai avuto problemi di app
            “obsolete” pacchettizzate da aver dovuto installare a mano o via terzi
            una versione più nuova? Se si di quante app parli? Perché se mi dici che
            vuoi chessò l’ultima versione di OpenShot che ancora non è nei repo ufficiali
            ok, devi fare un po’ di lavoro extra e chi mantiene il PPA dedicato, magari
            persino gli stessi sviluppatori di openshot han del lavoro extra. Questo non
            è male, è bene. Il fatto che ci sia una release non vuol dire che questa sia
            realmente pronta (never trust an unpatched release of anything), per questo
            è buona cosa avere sviluppatori che impacchettano *per la distro che usano*
            non per n distro, avere utenti che si scaricano e installano a mano una data
            applicazione ecc. Questo serve a scoprire bachi che nel processo di release
            non son saltati fuori, a far fare il giro a mille occhi al codice, a fare il
            solito fiume di patch che segue ecc. Questo è il processo che rende il sw open
            stabile, con meno bachi di ogni altro modello di sviluppo, il più aderente
            possibile ai bisogni dei suoi utenti ecc. Nessuno sviluppatore, megacorp
            incluse, può fare una mole di test equivalente, nessun sviluppatore può
            tirar fuori dal cappello tutte le idee che vengono dalle svariate patch che
            seguono ogni release ufficiale. Questo è il processo open.

            Il processo “lineare” sviluppatori -> snap -> utenti al contrario è il tipico
            processo closed dove c’è chi sviluppa, chi distribuisce e chi usa senza una
            vera “comunità” ma al massimo mere comunicazioni tra i singoli elementi della
            catena, è il modello “cattedrale” vs il modello “bazar” di Eric S. Raymond.
            Purtroppo oggi la gran massa dei “nuovi arrivati” è talmente intruppata nei
            concetti “manageriali” delle università attuali e nel modello di sviluppo
            closed che non riesce a vedere questo. La complessità non viene compresa,
            viene “ridotta” a concetti elementari che di fatto non riescono a rappresentare
            la realtà.

            Nel mondo open non ci sono comparti, non ci sono sviluppatori, sistemisti, utenti
            ecc. ci sono persone che sono un po’ (in varia percentuale) di queste categorie e
            la loro interazione, continua, libera, non compartimentata, forma l’ecosistema.

        • Aury88

          ti rispondo solo per quello che ho potuto seguire perchè spiegato in passato in maniera nabba, unico livello a cui posso ambire:
          le app attualmente devono venir portate su ogni singola distro in quanto distro diverse usano librerie e pacchetti, su cui girano le app, diverse o in una diversa versione. di conseguenza un app che aggiorna le proprie dipendenze all’ultima versione rischia di non poter essere comunque usata (aggiornata) per parecchio tempo e viceversa rischia che durante tutto questo arco di tempo venga utilizzata la sua vecchia versione presente nei repository della distro. questo avviene se un utente non vuole compromettere la stabilità della distro con un problema di conflitto di pacchetti e la distro non aggiorna subito (cosa che non sempre si fa subito tranne che nelle rolling e le test). tutto questo meccanismo, che dovrebbe servire a obbligare a tenere aggiornato il codice, crea in realtà solo difficoltà di porting che, per quanto principalmente sulle spalle delle distro, ha anche dei risvolti per lo sviluppatore dell’app (faccio bugfix anche per la versione vecchia supportata per ora da molti o aggiorno solo le nuove?). e tutto questo non ha impedito che bug critici in pacchetti critici rimanessero in circolazione per decenni. l’idea degli snappy è di confinare tutto;puoi anche usare codice scritto dall’NSA esplicitamente per spiarti o fatto con i piedi, ma sarà confinato nella sua cartella e quindi vedrà solo quando interagirai direttamente con lui. il fatto che ogni snap possa portarsi con se le librerie (non è più obbligatorio) semplicemente stacca l’aggiornamento del pacchetto dai vari aggiornamenti delle varie distro e si spera il tempo risparmiato (prima speso nel porting) venga usato per aggiornare e migliorare più frequentemente l’app e la distro. da adesso in poi la sicurezza non è più affidata agli sviluppatori di app e librerie (cioè alla bravura e onestà di x,y,w,z dove x è lo sviluppatore dell’app che sfrutta i pacchetti di y,w e in cui w ha usato il pacchetto di z) e agli sviluppatori delle enne distro nell’aggiornare prontamente o fare backport dei bugfix, ma agli sviluppatori di moduli di sicurezza del kernel (è una sola protezione sì, ma anche l’unica che devi controllare) come selinux o apparmor.
          come ultima nota gli snap espongono per esplicito le librerie (con versione) utilizzate, è quindi possibilissimo anche usando loro sapere subito quali sono gli snap compromessi da una versione della libreria buggata ed eventualmente metterli in una blacklist.

          • Kim Allamandola

            Con tutto il rispetto chi ha affermato queste cose può essere un commerciale di qualche sw-house
            che vuole distribuire sw proprietario: nello sviluppo open lo sviluppatore non si preoccupa di ciò
            che fan le varie distro né fa pacchetti, se non a suo uso e consumo personale. La catena open è:
            – qualcuno sviluppa un’applicazione che gli interessa, lo fa sulla sua distro coi defaults di quella
            di quella distro stando attento al massimo a rispettare l’LSB (Linux Standard Base), le specifiche
            Freedesktop (se è una GUI ecc) ovvero standard distro (ed OS) independent
            – la sua applicazione si nota vuoi da post su qualche blog, vuoi da gente che la trova curiosando su
            GitHub, vuoi da qualcuno che la pubblica su YC, vuoi da lui stesso che la propone ai packager di
            qualche distro. Chi è interessato prende il codice e lo compila, eventualmente patch-a e fa il pkg
            per la singola distro. (Costo per chi sviluppa ZERO)
            – i vari packager (sono tanti per ogni distro) in qualche modo revisionano il codice, propongo patch,
            scrivono traduzioni, forniscono idee per il futuro ecc. La sicurezza non è quindi in mano dei soli
            sviluppatori, è “revisionata” da centinaia di occhi diversi, di gente con competenze, idee, interessi,
            preparazioni diverse.
            Questo ha permesso lo sviluppo di GNU/Linux, dei *BSD ecc come sono oggi, ha permesso di avere
            ben rari gravi bachi di sicurezza, che fan notizia quando scoperti, mentre in altri campi, dove seguono
            la teoria pro-snap che hai esposto (Microsoft, Apple, tutte le sw-house proprietarie) i risultati son ben
            diversi. Le sw house proprietarie non volendo che altri vedano il loro codice non vogliono i packagers,
            non vogliono manco che altri impacchettino i loro binari per mantenerne il controllo e fare i comodi loro,
            pensa per dire a TeamViewer: da parecchie versioni (non so se dalla 7 o dalla 9) han introdotto un
            demone avviato di default che è sempre più scomodo da disabilitare. Se il loro binario fosse impacchettato
            da un packager terzo il demone sarebbe attivato dal lancio della GUI o impostato, se rischiesto, in auto
            avvio. A loro questo non piace ed ecco il risultato. A questo servono gli snap. A togliere ogni controllo alle
            distro riducendole a meri produttori di un ‘OS di base’ su cui distribuire i propri prodotti, cancellando le
            community. Una stupidaggine: pensa a Ubuntu Core: perché vincolare un progetto open ad un account
            di Canonical? Non puoi ad oggi installare Ubuntu-Core senza. Se il progetto seguisse le regole open non
            avresti certo una simile soluzione.

            L’ultima nota: “gli snap espongono per esplicito le librerie (con versione) utilizzate, è quindi possibilissimo anche usando loro sapere subito quali sono gli snap compromessi da una versione della libreria buggata ed eventualmente metterli in una blacklist.”
            certo, impedendo quindi di usare l’applicazione, mentre con le librerie condivise per default l’agg. di una lib.
            aggiorna tutti i suoi utenti, solo alcuni si rompono, e non lo scoprono gli utenti ma i packagers della distro,
            agiscono patchando e permettendo ai loro utenti di continuare ad usare l’applicazione senza bisogno di
            aspettare gli sviluppatori upstream in più per patch-are devono leggere il codice e quindi dire all’upstream se
            li han lavorato bene o meno, fornire idee, miglioramenti ecc.

            Quel che hai scritto non mi è nuovo: è il risultato della deriva commerciale di GNU/Linux e non porta granché
            di buono…

          • Aury88

            premesso che parlo sempre da nabbo ma, da quello che ho visto, sono moltissimi i progetti che pacchettizzano per conto proprio il software, per alcune distro, visto che hanno tutto l’interesse a che il software venga usato il più diffusamente possibile (una aspirazione lecita e non necessariamente commerciale, ma semplice volontà di condividere ed/per attirare sviluppatori). comunque non vedo perchè snap dovrebbe cambiare il rapporto packagers-sviluppatore: allo sviluppatore non interessa pacchettizzare come snapp? semplicemente lo farà qualcun’altro (probabilmente un affezionato di snap o di ubuntu) e questo qualcuno può intervenire nello sviluppo e dare suggerimenti esattamente come prima il packager deb o rpm…viceversa allo sviluppatore a cui interessa una specifica funzione continuerà ad avere a cuore lo sviluppo dell’app senza però compromettere la sicurezza del proprio sistema…esattamente come prima.
            quasi mai l’aggiornamento di una libreria in un pacchetto diventa aggiornamento della libreria e del pacchetto sulla distro…se la libreria è usata in tante app critiche è difficile che venga aggiornato (bisognerebbe aspettare che tutte le componenti adottino l’aggiornamento) e spesso si deve attendere una nuova release della distro per vedere l’utilizzo del pacchetto aggiornato, oppure usare repository esterni con il rischi di vedere comunque tutto compromesso. a mio avviso lo staccare il sistema di librerie dalle interdipendenze con altri programmi non compromette la ricerca da parte degli sviluppatori di usare le librerie migliori possibili, anzi permette allo sviluppatore di sviluppare fregandosene delle limitazioni imposte dai “defaults di quella distro” utilizzata per sviluppare (default scelti non sempre per motivi di sicurezza…molto spesso è solo mancanza di manodopera nel controllare ogni singolo pacchetto per permettere il porting) e usare la versione più aggiornata in barba ai tempi di rilascio delle varie distro. snap (così come click ma penso anche gli altri sistemi di packaging completi di dipendenze) d’altronde è stato pensato proprio per permettere cicli di rilasci frequenti degli applicativi, perchè quindi questi rilasci frequenti non dovrebbero portare anche a miglioramenti lato sicurezza o versione pacchetti utilizzati?
            in tutto questo l’utente sa che l’app x è confinata dal sistema operativo, deve perciò essere buggato il modulo di sicurezza perchè possa fare danni. che ci sia un bug critico nel modulo di sicurezza è una cosa molto più difficile di un bug tra le migliaia di pacchetti e librerie che compongono una distro, e infatti di solito vengono sfruttati questi.
            credo di capire cosa ti preoccupa ma parliamo semmai di una questione “qualitativa del codice” (che però potrebbe anche non deteriorarsi…anzi una volta che hai meno lavoro nel pacchettizzare puoi anche dedicare più tempo allo scegliere i pacchetti alla versione migliore) non di sicurezza, e imho un programmatore e il packager continueranno a metterci la stessa passione e la stessa attenzione di prima, solo dovendo ripetere il lavoro meno volte. forse sarò un illuso ma credo che una volta che si lascia più tempo agli sviluppatori-packagers questi lo dedicheranno a migliorare il programma (anche lato sicurezza)..certo lato commerciale può essere diverso, ma alla fine anche prima ti potevano distribuire codice non open, non studiabile non appoggiato a librerie esterne…e il tutto senza confinamento.

            quello che succede con i windows imho non è detto che si ripeta sotto una distro linux visto che sono strutturalmente differenti lato sicurezza ne secondo me i problemi di windows sono dovuti dall’avere ogni app con e proprie librerie ma semmai è l’assenza di un serio meccanismo di sandboxing e di controllo dei privilegi. (osx non lo conosco proprio quindi evito)

            poi non so…è evidente che ne sai mooolto più di me, ma lato meccanismi sociali non credo (o meglio spero di no) si verificherà quello che paventi. lato tecnico imho se prima, per dire, 10 dovevano pacchettizzare l’app, sapendo della nuova versione della libreria, per 10 distro, adesso ne basterebbe 1 per tutte e 10 le distro (e in realtà dicono sia più semplice pacchettizzare per snap che per i classici pacchetti…quindi 3/4 di packager? 😛 )… quindi quei 10 appassionati di quell’app possono collaborare per creare un unico pacchetto e farlo al meglio..basta che uno di loro sia conscio dell’aggiornamento di una delle enne-librerie che quest’aggiornamento venga fatto e sfruttato nell’app di tutti è 10 le distro….
            non so se è chiaro o ha senso come ragionamento :-/

No more articles