[Musica] Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo Ma ahimè, lo stronzo è mai medesimo e l'ho scritto giusto ieri [Musica] Siamo quelli che santificano il nuovo framework javascript preferendo segretamente jQuery Gli stessi per il quale il testing è importante, infatti la nostra codebase ha solo due test e flake pure Siamo noi quelli che il tuo linguaggio fa cagare, ma il mio è peggio.Quelli che la chiarezza nei comment message prima di tutto, e dentro ce l'appella tutti i santi.Quelli che in call parlano per 5 minuti prima di accorgersi che il mic è muto.Quelli che non si può fare di default, diventa velocemente un tutto e possibile se hai le risorse, tempo e budget ilimitato.Siamo noi quelli che l'AI va regolamentata, ma hai visto questo nuovo modello che disegna gatti di funambuli? quelli che il dipende e unisci gratis la prigione e quelli che la RAL...no vabbè fa già ridere così siamo quelli che fanno lo slalom tra le specifiche che cambiano costantemente ormai rassegnati che la definition of ready è solo una pia illusione quelli che si sentano dire "ho un'idea per un'app" ed è subito l'ennesimo social come instagram ma meglio Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al Gitbar e davanti a una birra tutto ci sembra un po' meno grave.Bene e benvenuti, sperando che la registrazione sia partita e benvenuti ad una nuova puntata di Gitbar.Questa settimana non ci sarà Mauro, sarà un po' una puntata pirata, insomma, come quelle che si facevano una volta e quindi ringrazio per essere qui con me.Alessio? Ciao a tutti, è un piacere essere qui.I nostri ascoltatori avranno notato che, come hai detto tu, non c'è Mauro perché gli abbiamo detto "senti, è ora che un'altra volta ad imparare a programmare perché i libri su PHP non te sono abbastati evidentemente quando stavamo in pandemia, quindi l'abbiamo ripreso, l'abbiamo rimesso dentro alla cantina.Infatti è chiuso dentro lo scantinato e adesso sta programmando con un laptop tra le gambe.Sta lì da quante ore? Sono sempre poche, sono sempre poche e poi abbiamo fatto questa cosa per rendere il tutto un po' più duro che si ricordasse, sono solo libri apogei, insomma.Quindi è il senso, proprio abbiamo deciso di farlo in quel modo, di solo libri in italiano, così è necessariamente costretto a concentrarsi.a concentrarsi.Come avete sentito con noi c'è anche Luca che era entrato a gamba tesa.L'hai fatto bene.Che poi in realtà ci stiamo facendo mistero, tantissimo mistero, ma se state vedendo il video lo state vedendo in basso a sinistra non siamo soli ma questa stasera siamo in compagnia di Andrea.Ciao Andrea! Chi sei, da dove vieni e perché sei su The Cloud? Ciao a tutti, sono nella bottiglia.Io sono Andrea Mandini e vengo da Verona.Sono un ascoltatore di Gitba, ma l'ascolto sempre a 1,5 per, per cui le vostre voci sono molto stasera.Di solito lo sento molto più veloce.Di solito faccio le parti meno interessanti, ovviamente sfrutterò anche questa quando lo scolterò.Io ho una storia di vecchio sistemista, diciamo che sono nato con il computer 8-bit e ho cominciato a lavorare, a programmare, con un vecchio Olivetti, mi ricordo, che siccome non trovavo le cassettine per i giochi in edicola, come invece i miei amici con il Commodore 64, io ero costretto a imparare a programmare per giocare a qualcosa, altrimenti non facevo niente con il computer.Poi magari scopriremo dell'altro, che ho fatto, sì.Cosa parliamo stasera? Stasera parliamo di storie di overtà.Prima di tutto parliamo molto lentamente.Parliamo molto lentamente.Dispetto a tutti quelli che ci ascoltano a velocità raddoppiata.No, ma a parte i scherzi? A parte i scherzi, grandi storie di povertà e di bambini non abbienti, perché io ho imparato Linux per lo stesso motivo.Avevo un computer che era uno scassone, Windows non funzionava più e quindi a un certo punto ho detto "ok, mettiamo su CD, vediamo".c'erano i floppy, no, c'erano già i CD in realtà.E da là è stato Amore a prima vista assolutamente non ricambiato.CD di Linux da Linux Journal, tipo, c'era, oppure tipo da Win Magazine, che ogni tanto non solo faceva Windows, ma c'era anche quel momento concorrenza dove selezionare i teladistro.Io compravo Linux Magazine, che era il win magazine della concorrenza, cioè nel senso sempre della stessa caseditrice però ti davano i cd di Linux a posto dei cd con lo shareware.E quindi...Guarda, su me hai sollevato un buon punto, ma queste riviste esistono ancora.Cioè, io non vado in edicola da anni, ma esistono ancora queste riviste? Allora, io penso che sì.Forse una o due ci sono ancora.Se esistono, danno ancora la versione di Winrar, di sicuro.Esatto.Assolutamente sì, ragazzi.era bella questa cosa perché effettivamente gli dava più quel feeling fisico alle cose.Io sono una di quelle persone che ha ordinato il CD di Ubuntu quando si poteva ancora fare di farlo.Con Shippin, come no? Stiamo a fare molta pubblicità io.Da fare.Sì, sì, esatto.Ma vi ricordate com'era bello quando Ubuntu aveva i CD? E quando Red "Dat", "Fedora", come potete prenderlo.Quando c'era lui, Mark Shuttleworth, i CD arrivavano in orario.C'era stato questo momento in cui, per i più piccini, che non lo sapranno, perché ci sono delle persone che ancora non lo sanno, tu potevi ordinare quanti CD de Ubuntu ti pareva da questo sito che era shipit.ubuntu.com, gli davi il tuo indirizzo di casa e un mese dopo ti arrivavano effettivamente dei CD, cioè fisicamente dei CD bellissimi col branding di Ubuntu.E io ci ho fatto un sacco di proseliti con questa corbelleria, perché insomma dire altri termini.Però era quel momento prima che uscisse Windows 7, che poi insomma si erano mescolate con Windows Vista, si erano un po' mescolate le carte in tavola e quindi c'è tipo tutti quanti a un certo punto si sono installati Linux.All'epoca scaricare un CD era una roba impensabile per cui benvenga, perché te lo chiedevano a casa.Tanti Linux Day fatti con CD canonica.Allora guarda, secondo me hai preso una roba veramente figa, ma avete mai fatto un install party di Linux? Perché io ho fatto tantissimi Linux Day, l'ho mai fatto.Un po' perché, no, non po' perché non ne ho mai avuto bisogno, un po' perché ci ho sempre avuto una vergogna terribile.Ma qualcuno di voi ha mai fatto un install party? Ha installato o ha fatto installare? Sì, sì, abbiamo fatti diversi, insomma, un po' in zona, facevamo un po' di install party, tipicamente era l'attività del Linux Day, del pomeriggio magari, che la gente portava il proprio pc a rischio e pericolo di formattagli tutto, di perdere tutto quello che aveva sopra, al punto che facevamo anche fermare una liberatoria a un certo punto per sollevare la responsabilità per caso qualcosa non funzionasse.Era divertente, diciamo che adesso un po' si è persa quella con la library, ormai è diventato facile installare, anche per usare la fine dai.Faccio una piccola interruzione perché abbiamo con noi direttamente dalla città con i numeri civici colorati, Leonardo.Non solo di Genova perché anche Genova fa i numeri rossi, dall'accento forse si può capire qual è l'altra città ai numeri rossi.Ciao Andrea, a piacere.Allora giusto così per fare un piccolo recap anche perché per l'ora di realtà non abbiamo ancora cominciato il vivo della della puntata sul tema della puntata ma stiamo parlando di come era bello quando potevi farti spedire i cd delle distro a casa o compravi tipo le riviste in eticola che ti che ti davano i cd con il ma stiamo registrando sì sì assolutamente stiamo già registrando così sì sì quindi quindi quelle cose del tipo "ah, che schifo l'Irux si possono odiare" e le lasciamo lì.Quindi, allora Andrea, ti faccio io la prima domanda un po' per andare in tempo perché siamo tipo a dieci minuti e non abbiamo ancora cominciato.Che cos'è un pacchetto? È fisicamente un pacchetto, come è fatto, come si fa, esatto, e che ci puoi mettere.Io sono estremamente curioso.Per me è sempre stata una roba estremamente eterea, cioè nel senso zipperista, l'apt install, dnfi, così da ci accontenti tutti.Il nome del pacchetto, ma non ho la minima di quello che ci sia dietro.Hai detto me o Leonardo? Non ho capito.A te, a te, prego.Non ne so nulla io, per cui...Non sono quelli che arrivano per post a casa, quindi...Ah, guarda, ci sono passati quando ero...Siamo abituati adesso a parlare di container, eccetera.i pacchetti LPM e Unabian sono i prototipi di questo tipo di distribuzioni software perché di fatto un pacchetto non è altro che un insieme di file che può essere binari, compilati, librerie, file di configurazione, asset grafici tipo icone, font eccetera tutte pacchettate insieme, compresse possibilmente, e poi dentro c'è anche dei metadati che specificano ad esempio le dipendenze di questo pacchetto, per cui se tu vuoi installare Firefox magari ti serve come dipendenza anche un ambiente grafico, potrebbe essere utile averlo, quindi diciamo che a ritroso in modo ricorsivo un pacchetto contiene tutto quello che serve per girare come la macchina a destinazione più cosa altro deve installare package manager siamo abituati ad usarlo anche in altri linguaggi, Python, JavaScript, tutti i package manager quindi più o meno un pacchetto, il concetto di pacchetto è quello anche dei linguaggi insomma.La cosa più bella di 3pm, io conosco un po' quelli lì perché di fatto mantengo un po' di package in open source, è il fatto ad esempio che puoi mettere in un pacchetto degli script che vengono eseguiti quando l'utente installa il pacchetto, quando l'utente lo disinstalla, quando l'utente lo aggiorna, prima dell'installazione, dopo l'installazione e per cui tu puoi inserire delle azioni da fare, ad esempio rinviare dei servizi o o rinominare dei file di configurazione, aggiungere delle unit, sistemi di...eccetera eccetera per cui c'è la massima libertà.Non so se ti ho risposto.No no, assolutamente.Ma diciamo una cosa di cui sono sempre stato curioso e Alessio il perché sto facendo questa domanda.Ma quindi nel pacchetto si può mettere anche non qualcosa che sia eseguibile? Cioè nel senso, al fine come hai fatto esempio giu', no? Il pacchetto delle icone, dei...la fonte.Alla fine c'è...è come se fosse il pacchetto di per sé un eseguibile che mi fa cose, tipo...non mi sono stato malissimo.Sì, cioè in un pacchetto possono esserci qualsiasi tipo di file che poi vanno a venire nel file system Linux, quindi puoi mettere eseguibili, ma anche librerie, link simbolici, puoi mettere un po' di tutto, non c'è, non c'è, sono vincoli.È un'immagine di un piccolo file system, di fatto, infatti quando si fa, si crea un pacchetto e lo si fa di solito in un ambiente ciaccaruttato, cioè si fa in un ambiente isolato, una specie di piccolo container, così sei sicuro che il tuo pacchetto non prende dentro altre cose che magari hai già sulla macchina, per cui per comodità tua vai in un ambiente "pulito".Ho una domanda, il package manager come fa a sapere che quel pacchetto è stato installato? C'è una specie di database interno che fa parte probabilmente degli hook del package manager? Sì, RPM di suo ha proprio un database di cose installate, lo tiene nella macchina ovviamente, fa il backup automaticamente, se lo mantiene da solo in modo trasparente per l'utente, infatti tanti non sanno neanche che esiste.Comunque esiste un database dentro la macchina che tiene l'elenco di tutti i pacchetti, anche volendo quando l'hai installato, la data di installazione, quando l'hai aggiornato...c'è un sacco di metodate nei pacchetti, il maintainer, il changelog ad esempio per vedere la differenza tra un pacchetto e l'altro, cosa è cambiato...ci sono un sacco di cose tutte dentro il database di RPM.È un database SQLite o è un file? No, è proprietario.Io sinceramente non sono mai andato a vedere il formato, ma non è un database vero e proprio.Se vuoi interrogarlo, da programma ci sono le librerie, c'è librpm per interagire con questo sistema e tu puoi fare esempio puoi scrivere un tuo package manager ad esempio quello che ha fatto suse ha fatto zipper oppure redatta fatto dove ha fatto yume per interagire ad alto livello con queste queste feature diciamo.Quindi l'app ti da le API è a suo livello per installare i pacchetti, rimuovere, aggiornare eccetera, ma poi tutto il resto ce lo devi mettere tu.Quindi significa che io posso installare esempio un...se io ho proprio il file dell'rpm lo posso installare anche senza nessun package manager, proprio facendo "rpm install".Ma a quel punto la differenza qual è? Cioè ho comunque tutte le dipendenze dentro o comunque anche c'è tutto il tracciamento magari delle dipendenze e qualche cosa che fa il package manager che sta su rpm cioè qual è la differenza tra ad esempio zipper e usare rpm così secco diciamo che zipper ti facilita o jume o dnf è quello che ti facilita appunto perché automaticamente ti scarica installare tutte dipendenze.Se tu provi a installare un rpm diciamo liscio così, debotto, senza senso, ti dice "guarda che non hai questa dipendenza qua, ciao".Quindi o te le procuri tu scaricando gli rpm che ti servono a tua volta e quindi dopo le installi tutte insieme con un unico comando, puoi fare anche rpm install *.rpm e tutto quello che c'è nella cartella per installare.altrimenti ti affidia un package manager di più alto livello che ti fa anche la gestione delle dipendenze e anche di eventuali conflitti perché non è detto che una dipendenza vada bene in assoluto per a tutto eccetera eccetera.Magari due pacchetti dipendono dalla stessa libreria però dalla stessa libreria di versioni diverse, poi vi può essere un conflitto e e devi risolvere qualche modo.Ok, quindi significa che io posso installare...Ora, per le persone che mi stanno ascoltando, questa domanda sembra estremamente naiva da fare, ma a me apre tutto uno scenario anche per capirci di più.Ma allora, io posso installare due versioni diverse dello stesso pacchetto? Cioè, nel senso, ad esempio, io come sviluppatore, se voglio sviluppare Python, ad esempio, cioè hm ci sono i version manager di Python oppure uso eh ASDF insomma nel senso di eh di solito come sviluppatore io vado verso diciamo quella cosa là ma ammettiamo che io ho questa macchina dove ho i i miei siti in P in PHP ok però magari c'ho quello in P in P in PHP 5 che è quello più vecchio che mi fattura ovviamente di più e quello nuovo in php8 che insomma è così che l'ho fatto sia a caso.Le posso avere entrambe le versioni? Cioè come funziona? Come fa poi il sistema operativo o comunque il pacchetto che usa quella dipendenza a prendere quella giusta? Generalmente un pacchetto ha una versione, quindi tu non hai il pacchetto di php versione 5 poi ci sarà il pacchetto di php versione 6, non so anche se esiste il php versione 8 quello che si fa in genere se vuoi installare più versioni delle stesse cose, ad esempio si con python, con php, è creare pacchetti con nome diverso che dentro il nome abbiano anche la major version del software.Quindi se ad esempio voglio una macchina vera il gcc 10, 11, 12, per i miei appuntamenti, avremo un pacchetto rpm gcc 10, un pacchetto gcc 11, e un pacchetto gcc 12.funziona la cosa perché appunto il pacchetto gcc 12 non dipende, non ha nessuna nessuna legame con gcc 11 magari ovviamente anche a livello di my system quindi andrà a scrivere cose in directory diverse tipicamente col nome della versione del pacchetto dentro e quindi tutto funziona, un po' come tu puoi installarti python 3.11, 3.12 e 3.10 senza che si vadano a cavallare uno con l'altro.Ovviamente deve essere il mantenimento del pacchetto, fare i pacchetti bene, perché deve tener conto di questa cosa.Ad esempio noi in facciamo con Rust, perché di fatto manteniamo le ultime due versioni precedenti del linguaggio del compilatore, dei vidi compatibilità eccetera eccetera.E riguardo le dipendenze di un pacchetto si possono gestire, o meglio come vengono gestite, il fatto che un pacchetto gcc 11 necessita di una libreria versione 10, il 12 la versione 12, allora diciamo i pacchetti non si sovrascrivono però necessitano le librerie che magari non hanno questo nome della versione quindi potrebbero andare a sovrascrivere, viene gestito o dipende dal maintainer? No, viene gestito in modo simile come faresti in javascript o comunque in un'altra linguaggio che ha un package manager.Quando crei un pacchetto devi creare un file che si chiama spec file, cioè un file di metadata che dice che questo pacchetto per funzionare richiede ad esempio la glibc versione 6.0.1.Se tu invece dici che questo pacchetto richiede la versione 5.0.1.1 quando tu installerai quel pacchetto il package manager ti propone di installare la versione richiede il tuo pacchetto, quindi dipende da quello che è scritto dentro lo spec file.Se tu dichiari che ti va bene qualsiasi libreria da una certa versione in su, metti ">=" e via e quindi sei contento se hai da OpenSSL dalla versione 1 in poi mi va bene tutto.per esempio.Se invece dici io voglio, per se sera, la versione 3.3, il package manager ti fa testare la versione 3.3.Però in una directory locale, cioè non va poi a sovrascrivere l'eventuale 4? No, è abbastanza fatto bene sul sistema.Sì, è un po' complicato da metterci le mani le prime volte però una volta capito il meccanismo è abbastanza...la cosa carina è che ti rendi conto veramente di come è fatto un sistema Linux, perché al fine vai proprio a vedere nel dettaglio dove sono i file, dove sono le librerie, perché si chiamano così eccetera eccetera...quindi il linker dinamico, linker statico, il pad di configurazione dei linker eccetera eccetera.Ma allora a questo punto domanda da super ignorante, ma non avrebbe più senso fare tipo l'equivalente tipo del fat jar, quindi questo RPM enorme con tutto dentro? Beh, checchilo qua, però hai dei problemi, per esempio se per caso ti uscisse una vulnerabilità su una libreria, se dovessi aggiornare una dipendenza, poi devi andare in tutti i pacchetti dove hai messo quella dipendenza lì e fare un upgrade di tutti quei pacchetti lì, quindi ad esempio esce una cosa a caso, un bug su libcurl, tutti i pacchetti che hanno quella dipendenza lì dentro il path.java, il path.rpm, dovresti andare ad aggiornare.Si può fare l'upgrade del maintainer nel caso di un'offendazione.invece se riesce a isolare un po' le dipendenze, rendele meno coese, è un po' come il coach, cioè se riesce a disaccoppiare le cose è meglio alla fine, perché l'architettura ha un vantaggio sia dal punto di vista dell'efficienza e sia dal punto di vista della manutenibilità, cioè aggiorni una libreria e riesci ad aggiornarne 100 pacchetti dove hai messo quella libreria lì, Stesso motivo per cui si preferisce fare il linking dinamico invece che linkare staticamente tutto come fa Go oppure Rust.Se il maintainer dice "io voglio Glibc versione 5.15.2" e l'assetta fissa, quindi non da lì in poi, ti puoi fare anche l'upgrade, però quel pacchetto deve essere aggiornato dal maintainer, se no te userai sempre quella lì che è bugata.quindi anche il maintainer deve...non c'è, si si, si confondono su questo.Esistono dipendenze non opzionali però, come dicevo, se non hai questa dipendenza o questa versione, utilizza quest'altra versione, questa è proprio completamente da ignorante, non so nemmeno se è possibile...puoi fare le alternative, c'è il modo che si chiama update alternative, per cui magari puoi far scegliere all'utente cosa vuole usare ad esempio come login manager oppure come shell banalmente o cosa del genere, oppure puoi anche dire guarda questo pacchetto qua io quando te lo installo anche queste altre cose obbligatorie.Poi se vuoi io ti consiglio di installare anche magari una documentazione oppure gli script di bash completion, per cui tu puoi anche dare dei consigli all'utente per dire "guarda questa dipendenza qua non è obbligatoria ma è raccomandata per cui vedi tu se vuoi installarla bene, altrimenti fai il tuo.Ho una domanda, scusa ce l'avevo in canna già da prima, nei pacchetti abbiamo detto che ci possono essere diverse cose, risorse binarie eccetera, ma ci possono essere anche dei sorgenti che poi si compilano quando si installano? Non si fa spesso, si fa magari per i linguaggi interpretati, per esempio Python, Gua, PHP, Node...una cosa che si può fare anche e anche che fa automaticamente package manager è quando crei un pacchetto binario per le varie piattaforme perché non abbiamo ancora detto che poi il pacchetto viene compilato per x86, per ARM, per PowerPC eccetera eccetera e poi viene creato anche il cosiddetto source rpm per cui tu puoi scaricare direttamente in formato pacchetto proprio i sorgenti dell'applicazione che stai installando e questa cosa è carina perché ti permette anche di fare le cosiddette reproducible build, cioè tu puoi creare poi veramente verificare che il dinario che hai scaricato è esattamente uguale a quello che ti compieresti a mano scaricando i sorgenti dalla piattaforma dove hai preso il codice.Quindi è anche un motivo di verifica.Poi abbiamo detto che i pacchetti sono anche firmati con una chiave pubblica, per cui c'è anche una verifica dal punto di vista dell'affidabilità del pacchetto.A questi punti sono forse un po' esorgenti, ma dipende.Come al solito dipende.Quando ha senso parlo e quando no.Nel caso del linguaggio di programmazione si possono mettere esempi di codice, documentazione, che al fine sono documentazione e cose del genere, sarebbe utile farlo.Sulla domanda di Luca, in Node.js capita per esempio la libreria di SQLite viene compilata nel momento dell'installazione, per cui se tu facessi il big package da Linux a Mac non funzionerebbe, anzi spesso quando cambiano le piadi in Node.js anche da una versione all'altra devi ricompilare.Avevo una domanda, perché questo l'ho visto, io lavoro nel mondo Node.js, però l'ho visto anche da altre parti di distro Linux.Come mai ogni tanto esce fuori un nuovo package manager? Cioè, che problemi ci sono? Cioè, è vero che è un po' come un special network con il framework, però abbiamo Debian, io sono un Debianista, uso Deb.Perché qualcuno sceglie qualcos'altro? Non stiamo risolvendo lo stesso problema? E magari si parla solo di performance, ma cos'è? Non lo capisco.Non c'è una riposta, qui è un po' la libertà dell'open source che ti permette di fare queste cose per cui ogni tanto qualcuno ci trova e magari risolve esigenze un po' diverse è come dire perché ci sono tanti desktop, perché ci sono gnome KDE Non era il podcast giusto ma sarebbe stata la domanda successiva che risolve KDA rispetto al nome che è più bello.Proverò il PCBI quando c'è Emacs cosa del genere.Eh esatto tipo una roba del genere no ma allora a questo punto la mia domanda successiva è qual è la differenza tra un pacchetto RPM ed un pacchetto Deb ad esempio? Cioè nel nel senso c'è qualche più curiosità che uno ha rispetto rispetto Io ho avuto una brevissima esperienza intensa che spero di ripetere poco, ok? Che è stata quella di scrivere alcune RPM-spech.È stata un'esperienza...Mistica.Mistica, esatto.Tra i virgolette è bella perché era una cosa che non avevo mai fatto, ok? Quindi è stata un'occasione per imparare qualche cosa di nuovo.Ma è stata anche un'esperienza complessa proprio perché la documentazione, so io tordo, però la documentazione non l'ha trovata.Io andavo a vedere alcuni specifari che c'erano scritte dentro queste cose e dicevo "madonna, che cos'è questa magia?".Ok, quindi nel senso, sai, non è quella cosa che tu vai sulla documentazione, ti cerchi quella funzione e ce la firma.Nel senso, è stata una mia esperienza un po' fumosa oppure effettivamente c'è un po' questo scattering di informazioni? Sono due domande, una differenza tipo tra RPM e Deb e una perché l'RPM specie è così complesso da scrivere.Allora non ti so rispondere su Deb perché non sono manitentore di pacchetti da bianco, quindi lascio a chi ne sa più di me sicuramente.E a naso la sensazione risolvono un po' lo stesso problema oggettivamente, cioè scaricare, gestire dipendenze, gestire il fatto che l'utente possa installare e disinstallare roba e non lasciare tracce in giro, gestire i backup dei loro file di configurazione.Probabilmente Debian nasce da una filosofia diversa, probabilmente nasce più o meno nello stesso periodo, RPM essendo un atto con Red Hat, ha più questo spirito commerciale per cui Debian si è voluta un po' discostare da questa cosa qua, creando un loro progetto gestito in autonomia con le loro governance e tutto quanto.Quindi probabilmente non c'è una vera ragione tecnica dietro, insomma a livello di efficienza mi sentirei di dire che sono abbastanza allineati, forse c'è gente che si trova meglio con i DEB, c'è gente che si trova al medico per il RPM, non c'è una grande differenza.Riguardo alla documentazione, è vero, c'è anche da dire che non c'è questa grande flotta di persone che corrono per dire "io voglio mantenere un pacchetto RPM", per cui probabilmente è un po' il caso del DeRuoval e della Lina, per cui se ci fosse più persone che vengano a dire "Ehi, voglio diventare il nuovo maintainer" magari qualche sforzo in più per fare documentazione più sensata, anche più accessibile, probabilmente verrebbe fatto.Alla fine chi mantiene i pacchetti sono chi gestisce le distribuzioni e la gente che più o meno fa questo lavoro da sempre, per cui magari di solito chi gestisce un pacchetto è anche un grande conoscitore di quel software di stesso, magari interagisce anche con il progetto vero e proprio, upstream, contribuisce con del codice dei test eccetera e tante volte sono i progetti stessi che si auto impacchettano perché tante volte nella nella build dei progetti specialmente quelli ben strutturati nella CI che fa la build magari che gira su GitHub o GitLab trovi già i job che fanno che creano direttamente gli arreppiamo i dead.Quindi è un modo per creare alla fine un eseguibile.Si, diciamo che potrebbe essere documentato meglio, sono d'accordo, anche alla fine probabilmente vi darò qualche dritta se volete cimentarvi.Dopotutto quello che ci hai detto, di sicuro ci verrà la voglia di farlo.In realtà pensavo che un maintainer forse deve avere più conoscenza dell'ecosistema in cui che è il suo punto di partenza nel cugiure al pacchetto cioè del fatto che ah dobbiamo aggiornare questa libreria però questa libreria deve avere il nome della versione dentro perché se no andiamo ehm al ropero quindi sicuramente è un aiuto se se eh contribuisce al progetto però probabilmente ha bisogno cioè ha bisogno è è uno che che conosce più l'ecosistema cioè la macchina su cui su cui andrà.Sì.Con il lavoro ecco che deve avere tipo un polpo avere mille mani, mille occhi In più il maintainer deve anche fare delle scelte, ad esempio il pacchetto lo compilo con questi flag, ci metto dentro queste opzioni, aggiungo al pacchetto un file di configurazione già pronto così l'utente non deve stare lì a scriverselo lui fa delle scelte per l'utente, quindi si mette nei panni dell'utente quello che installerà il pacchetto e cerca di facilitargli la vita il più possibile ovviamente, a volte ci riesce a volte no insomma.Poi a volte il maintainer deve anche reagire ad eventuali bug che escono ovviamente solo cv, paghe sicurezza, per cui hai bisogno anche di controllare costantemente i feed di notizie per vedere se escono vulnerabilità, ad esempio se sono cose gravi che escono ogni tanto, e poi devi come maintainer anche stare aggiornato con il progetto vero e proprio, per cui se magari il loro sviluppatore, voi sviluppatori vi rilasciate una versione della 10, domani esce la 11, probabilmente la gente della distribuzione, gli utenti della distribuzione vorranno usare la 11 invece della 10, ma finché il maintainer del pacchetto non fa il pacchetto, nessuno andrà a usarlo perché di solito la gente non va a scaricarsi i sorgenti dai tab o sai, per fare uscire l'RPM anche per la versione in generale il perché a me piacerebbe che esce la versione undici e esce anche l'RPM undici però per esperienza almeno io usavo Linux eh tanti anni fa mi sembra eh non è non è così pari eh cioè esce la versione poi il manter si prende si sobbarca tutto il lavoro per fare uscire l'RPM anche per eh la versione undici eh esiste una che fa chi fa il pacchetto il mantener per cercare di renderlo sincronizzabile oppure mh è proprio una cosa così libertina nel senso che diciamo che eh eh eh siamo nell'open source quindi eh non c'è questo grande diciamo nessuno viene a prendermi a casa se se domani non esce la BASC 6.4 no certo certo e io progetto un mese dopo perché il maintainer magari ha da fare quindi lo può uscire con i tempi il maintainer farà con i suoi tempi questo è più o meno sì sì diciamo che per i progetti grossi c'è anche una grande coordinazione esempio lo è sceso KDA ultimamente è uscita la versione 6 per cui c'è stato un grande lavoro di coordinazione per gestire tutto quello che serviva per portare KDA alla versione 6 lo stesso quando è uscito Gnome Quindi i pacchetti sono usciti in concomitanza? Sì, più o meno.Ci sono anche vari stream di sviluppo, per cui magari se uno vuole fare il beta tester, che qui poi entriamo anche nel merito del testing, può magari scaricarsi una versione ancora alfa o beta, magari si crea lui il proprio pacchetto, prova il pacchettino prima di rilasciarlo al mondo intero, fare la prova sulle sue macchine e poi eventualmente decide se il pacchetto è buono e se funziona bene per tutti e dà ok per pubblicarlo.Qui c'è anche un discorso di testing, di release, di gestione del rilascio del maneggimento.quindi è un po' lo stesso ma sì quindi stesso scusami stesso ciclo del software è un po' parallelo, un po' rallentato perché ovviamente eh gli sviluppatori fanno fanno uscire un poco prima però cerchi nei progetti grossi sembra ci sia un po' più di coordinazione.Sì sì sì sicuramente.Poi vabbè progetti talmente grossi tipo ovviamente Kubernetes che che da soli anche il pacchettizzazione e tutto l'altro.- Sì, è chiaro.- Kubernetes tra l'altro è un esempio particolarmente fausto tra...di collaborazione tra OpenSUSE e Kubernetes stesso, perché se non sbaglio i pacchetti di Kubernetes sono buildati su OBS, no? - Sì, sì è vero.Cioè abbiamo una collaborazione per fare la build, mettiamo noi le macchine per fare la build di Kubernetes.ma anche qua allora il non so quanto vogliamo scendere poi nei particolari di questa cosa ma a parte e allora i pacchetti RPM vengono sputati fuori da e tra l'altro questo mi mi fa sovvenire una cosa che poi vi porterò nei balocchi che è stata una cosa a cui Carmine assistito live a questo FOSDEM.I pacchetti RPM vengono sputati da questa CHRoot su queste macchine, ma il tooling per i pacchetti RPM? Quanto tooling c'è? Quali sono i maggiori tool per il packaging, specialmente RPM, dato che tu sei coinvolto in prima persona? sembra di capire.Io uso praticamente OBS che è il sistema di build di Suse che è Open Build Service, è un progetto open source, quindi lo trovate su github come sorgenti, proprio è una web application che con i suoi API, i suoi backend, frontend eccetera io uso quello perché alla fine mantengo i pacchetti su OpenSUSE probabilmente Altadistro hanno al loro tooling, punto c'è il suo sito dove gestiscono i pacchetti loro Fedora c'è un altro sito ancora, io conosco quello di OpenSUSE ovviamente di fatto è una specie di ambiente dove tu è una specie di metafora repository di progetti quindi una specie di tab se vuoi con dentro le facility per sottomettere quando tu fai il push di un progetto, lui automaticamente gli dà i file di descrizione del progetto e lui con quelli può iniziare a fare la build per varie piattaforme perché sotto ha un certo numero di worker, di macchine, di architetture diverse, c'è X86, c'è 64 bit, 32 bit, c'è Raspberry, c'è PowerPC, c'è il mainframe, automaticamente la build di questi pacchetti, compilazione eccetera e pacchettamento fisico diciamo e poi lo fa automaticamente anche per le versioni che gli dici tu, quindi tu gli dici nel pacchetto questo pacchetto qua va bene per openSUSE versione 15.4 e 15.5 e automaticamente lui fa partire a build e crea dei repository e dopo puoi andare a aggacciare la distribuzione se vuoi, oppure poi automaticamente vanno a finire in un progettone più grande che è il mega repository ufficiale di openSUSE.Si può fare quella che viene detta submit request Esatto, la cosa bella è che questa cosa qua può farla chiunque, quindi è aperta al pubblico e non è legata a SUSE, quindi noi facciamo con OBS, facciamo la build di pacchetti Debian, Fedora, facciamo la build di container, docker, etc.e senza nessun tipo di problema, quindi qualsiasi cosa coinvolga, facciamo una build, è un po' una sia gigantesca, quindi crea degli artefatti che poi vanno a finire in posti vari.Allora ti faccio una domanda che questo sia il momento giusto.Quindi io decido domani di voler buildare il mio applicativo per OpenSUSE.Mi registro su Open mi creò l'account, insomma mi mi faccio la mia home, suppongo si chiama così, sto parlando proprio a caso e metto il mio pacchetto.Bene.Esprimo le sue dipendenze così.Ora, quel pacchetto come ci finisce? Se ci se se ci finisce all'interno proprio dei repository ufficiali di OpenSUSE, chi è che lo de chi è che lo decide? Qual è il processo di governance? poi, diciamo, che responsabilità ho io poi una volta che questa roba ci finisce dentro Pensus e soprattutto finisce dentro Tumbleweed, finisce dentro Leap.Cioè, come funziona? E poi che cos'è Slow Roll? Tante domande.Aspetta, parlo solo io stasera.Allora, andiamo con ordine.Tu crei il tuo pacchetto, io ho fatto un esempio sul mio blog, intanto scrivo qualche articoletto, ho fatto un esempio di pacchettizzazione di un semplice giochino della battaglia navale, come fare un pacchetto da zero, per newbie.Poi, diciamo che tu fai, puoi decidere di tenertelo per te nel tuo progetto home, perché ogni utente ha un progetto home, Oppure, come diceva Alessio, sottometterlo a un altro progetto.Quindi tu crei il pacchetto, una volta che l'hai buildato e funziona, hai visto che si installa, eccetera, magari l'hai anche testato, possibilmente, e tu quello che fai è la submit, quindi mandi il pacchetto e gli dici "Voglio che questo pacchetto vada a far parte di un progetto".In OpenSource, in OBS, si chiamano progetti, quindi ogni versione di distro è un progetto, quindi ci sarà il progetto Tumbleweed, il progetto Leap, il progetto Leap 15.6, il progetto Leap 15.5, eccetera.Per cui tu hai il tuo pacchetto e dici "Voglio sottometterlo per questo distro, questo, questo, questo".C'è un processo di review, quindi i gestori del progetto, i maintainer del progetto, vedono la tua richiesta e valutano se accettarla o meno, ovviamente.Quindi è come una pull request su GitHub, possono dire "ok, va bene, accettare" oppure commentare e dire "questo qua non va bene, devi cambiare, devi spostare questa cartella qua, la devi mettere in un altro posto, poi devi fare chmod di un file, tutto quello che c'è da cambiare e poi alla fine se ti accetta una richiesta il tuo pacchetto va a finire nel progetto.Una volta nel progetto, se il progetto è quello di Tumbleweed, va a finire nella Presidenta Factory, che è quella da cui poi i maintainer della distro attingono per fare effettivamente uno snapshot della situazione attuale e creare quella che è la distro vera e propria.Quindi di fatto si parte tutto dalla factory che è il progettone, diciamo quello globale dove ci sono tutti i pacchetti.Poi Tarlowid è uno snapshot periodico di Factory e Leap è uno snapshot periodico di Tarlowid, quindi una volta ogni tanto si dice ok al primo giugno fermiamo quella versione lì e quella sarà Leap 15.7 Slow roll invece è come Thumbleweed, quindi con gli aggiornamenti continui, quindi non ha una versione, però per l'occasione, Slow roll versione 10, Slow roll versione 11, Slow roll versione 18, ma una roll in release dove però gli aggiornamenti non sono così frequenti come in Thumbleweed, che è una rolling release come Arch Linux, quindi ti vedrai nel pacchetto basso, spaltare dalla versione 6.5 alla 6.7, ma la rifaltando la 6.6 perché il maintainer della distro ha deciso che la 6.6 non aveva niente di particolare.Quindi è un po' un avvenimento.Quindi significa che se io voglio ad esempio far sì che il mio progetto finisca nella prossima leap, io faccio la richiesta leap o la faccio a factory? Cioè a questo punto è possibile, cioè non sarebbe tipo fare a factory e poi i maintainer decidono se farà fine dentro...Cioè secondo me...Sì, diciamo tu di solito si fa sempre riferimento a factory, quindi factory è quella che comanda il concetto poi se ad esempio si tratta di un update perché raramente arrivano pacchetti nuovi quindi di solito quello che fai tu è fare un aggiornamento di un pacchetto quindi quello che fai tu è se vuoi che l'aggiornamento arrivi direttamente a lib puoi anche fare la sua admitta a lib oppure lasciare che lo facciano i maintainer di lib.Se lo fai tu, bene, se non lo fai tu, i maintainer di lib devono stare a guardare cosa è stato aggiornato e pescarsi gli aggiornamenti da factory.Quindi è un po' un pull di...Sì, in realtà c'è stata questa cosa che effettivamente pure a me qualche volta mi fatto strano perché rispetto alle pull request di github che tu di solito scrivi la forchi fai la pull request la fai te la pull request su obs chiunque può fare una submit request ovunque tipo e quindi praticamente c'è stata che magari che ne so luca si è accorto che c'è stata una versione nuova di un pacchetto dentro Factory che gli serve su Leap e lui se fa auto nomalmente la Submit Request da Factory a Leap.È una cosa ancora più open, se vuoi vederla in questo modo, è molto aperta come sviluppo quindi chiunque può fare passando tutto.e quindi cioè nel senso ammettiamo che c'è una cpu in un in un pacchetto nel senso per come me la state spiegando è un processo che richiede nel tempo ci ci sono diciamo delle procedure degli dei shortcut per le cose proprio veloci cioè se c'è ad esempio quando c'è stata il caso della backdoor in xz che poi magari se ne sei qualcosa ce la puoi anche spiegare perché vedo che che va effettivamente.Abbraccio insomma con questa cosa qui.Quando si doveva fare l'update di di XZ? Si è fatta tutta questa altra fila oppure c'è un modo in cui il mantenere della lista vuol dire ok questa cosa ci ci finisce ora e se la prendono tutti senza aspettare la versione nuova? È lo stesso processo o ci sono tipo delle patch dei dei pacchetti di verbo? Non non da la soffita così.Ma diciamo che per per proprio per discorso di sicurezza c'è una strada privilegiata, c'è uno scorciatoio che è l'incident, quindi tu praticamente apri un incident e la richiesta va a priorità più alta e viene approvata praticamente istantaneamente, quindi in modo più veloce il processo.Il mantenere notificato nel giro di pochissimo tempo, c'è una squadra dedicata a queste cose qua ovviamente, per fortuna non sono io e quindi penso che il nostro collega Paolo e me ci saranno qualcosa, però vedo che hanno una velocità maggiore di reaction, quindi lo stanno aspettando.La cosa che probabilmente non abbiamo neanche detto prima è che se vuole il maintainer del pacchetto, quindi il packager, aggiunge anche delle patch al pacchetto stesso quindi lui prende il sorgente di quello dei progetti upstream e può, se vuole, aggiungere patch per modificare questi sorgenti di solito appunto per risolvere problemi di sicurezza oppure per cambiare funzionalità magari togliere cose che non servono oppure qualsiasi cosa, posso aggiungere un numero a piacere di patch e poi quando il pacchetto viene compilato queste patch vanno a finire dentro il pacchetto finale e il binario che esce contiene le patch del maintainer.Quindi lo facciamo ad esempio col kernel, mettiamo un sacco di patch che non distribuiamo direttamente di kernel vanilla ma aggiungiamo noi delle patch abbiamo una squadra dedicata per il kernel e gestiscono questo tipo di modifiche insomma.questo tra l'altro poi dopo di dire ancora un po' perché è guardasimo.No, io ho il momento aziendalista scusate, è stato a dire qualcosa di importante.Una cosa importante cioè che OBS contrariamente a tutta la concorrenza supporta il concetto di transient build o transient rebuild, non so come cazzarola si dice, però praticamente una volta che viene aggiornato un pacchetto di un software viene rebuildato, accadena pure tutto quello che dipende da quel software, che è il motivo per cui se tu tu submetti un update dei glibc, qua mi rifaccio all'esempio di Dan Cermak che ho visto fare, se tu submetti un aggiornamento dei glibc su factory e viene accettato, vedi lo spike del grafico della cpu che ti manda i mortacci perché viene ribildata tutta la distro a a catena, che è una cosa che ho scoperto che il tooling concorrente non fa e è il motivo per cui quando noi abbiamo fatto, quando è stata scoperta la vulnerabilità di XZ, che è stato un esempio un po' in fausto perché non ha raggiunto le distribuzioni stabili, quindi tutto il casino è successo solo praticamente a Andrea, per esempio, solo penso sia successo su Tumbleweed oppure su Arch, Linux e le distribuzioni Blitzing Edge.Praticamente è stata presa, è uscita la patch, è stata presa la patch, è stata mandata su OBS la patch e è uscita subito.Cioè è stato subito tagliato lo snapshot dei fattori per fa' Tumbleweed e praticamente qualche ora dopo la cosa era stata fissata completamente.Ma allora io faccio la domanda ancora più azienda, aziendalista.Cioè in realtà facciamo così, non la faccio aziendalista, la faccio in generale.Una distro enterprise a pagamento, ok? Qui possiamo prenderla anche come esempio Sless, ha immagino un processo diverso per decidere che cosa finisce dove, ok? Qual è diciamo il processo? Cioè nel ora qui ho detto io volevo mettere il mio pacchetto dentro l'IP e se lo voglio mettere voglio mettere dentro / perché mi sento enterprise come funziona? Beh allora tanto devi essere diciamo nel team che gestisce i rilasci e i pacchetti, cioè una distro enterprise a persone dedicate che non sono gli hobbysti come me oppure come una persona che nel tempo libero fa anche quella cosa lì, ma fa tutto il giorno solo pacchetti, gestisce vulnerabilità, patch, rilasci eccetera eccetera.Non è che chiunque possa e dire aggiungo un pochetto all'adistro Enterprise, anche perché c'è da dire che hai dei constraint, dei requirement di mantenibilità, per cui se noi diciamo che SLAS è ufficialmente supportata per, mi ricordo quanti anni, 7-11 anni, un numero spropositato di tempo, vuol dire che tu il pacchetto di versione, quella versione lì, deve rimanere quella versione lì per tutto quel tempo lì, non è una roll release.Se tu nel last desk hai Vim6 fra 11 anni e tu dopo 11 anni dici al cliente che la distro è mantenuta per 11 anni, tu dopo 11 anni dovrai ancora mantenere Vim6.Quindi è un po' diverso il meccanismo.Ci sono persone dedicate, squadre apposta, pagate per fare questa cosa, professionisti molto molto bravi oggettivamente, che fanno anche il backporting di patch, un sacco di lavoro per fare in modo che le cose "vecchie" funzionino, anche quei sistemi moderni, perché adesso non mi ricordo il numero esatto di versione il kernel, ma ci sono distro che hanno ancora il kernel 4.5, quindi se le vengono mantenute, quindi c'è gente che prende le patch del kernel 6.9 moderno e le porta sul kernel 4.5, quindi non funzionalità ma patch di sicurezza.Noi garantiamo questa cosa qua, è una cosa molto molto diversa.E' proprio un'altra concezione di lavorare, perché tu sei vincolato più al mantenere funzionante quello che hai rilasciato e dato al cliente che ha prelato per quello.Mentre in Tanduid c'è la visione opposta, perché sei incentivato a rilasciare, ad aggiornare sempre più spesso le cose.Più cose rilasci, più lo distro è figa.Quindi lo distro è moderna, è più roll release, le ultime novità, puoi testarle eccetera eccetera.Faccio una domanda per tutti in realtà.Avete mai utilizzato Flatpak? Vi piace? cioè, ci avete mai avuto problemi? Cioè, nel senso, alla fine, in un mondo che, che cazzo, c'è una cosa estremamente filosofica, che sembra uno spot di un'assicurazione, tipo, in un mondo che cambia, perché ancora fare g r p m e non fare tutto flat pack, che è così figo, è così giovane e se devi fare una modifica è una mazza nel culo terribile.Perché? No, adesso, seriamente, vi piace Flatpak? Secondo voi ha senso e come si rapporta con, in questo caso, il "classico" RPM? [Parlamento dell'intervento] Vuoi andare per ultimo? Ok, guarda, allora...io uso una distro che è tipo strana, perché è una versione di OpenSUSE che è fatta da un signore che si chiama Richard Brown, che praticamente è uno dei...dobbiamo dire, distribution architect di OpenSUSE, eccetera.e lui ha creato questa cosa che si chiama Micro S Desktop, vabbè poi semmai ve lo cercherete, ve lo mettiamo nei balocchi, che è sostanzialmente una distro immutabile che usa un particolare flavor, diciamo, Dezzy, come gestore dei parchetti e poi il resto usa tutto Flap.Questa è doverosa premessa perché? Perché lui ha detto "Regà, è il 2024, a meno di non essere la distro enterprise per cui quello che installi te lo annusi prima e dici "mamma mia quanto odora di bosco e di riviera questo pacchetto RPM", chiaramente c'è un uso normale del computer, che non sia quello del serverone, comporta che tu devi avere due principali requisiti.Il primo è che le applicazioni che usi si aggiornino "da sole" e siano all'ultima versione, perché tu il browser ce lo devi avere all'ultima versione, il client di Spotify fa schifo e ce lo devi avere sandboxato eppure quello all'ultima versione, che ne so, il client email ce lo devi avere all'ultima versione, tutta una serie di cose ce le devi avere all'ultima versione perché è importante, perché è di qua, perché è di là, perché tu come utente vuoi avere una cosa utilizzabile che non sia Vim, Seide, 600 anni fa supportato per 10 anni, che ha un valore questa cosa, ma è diverso.Io, utente Alessio, che abito a Santa Maria delle Mole, non lo percepisco.Dall'altra parte, il compito del distributore di software che ti fa i pacchetti RPM che odorano di rosmarino appena colto, il ruolo di quell'entità è preposto a farti avere una base image che sia inossidabile e quella cosa tu la fai con gli RPM e la fai con un certo tipo di tecnologia tipo Koji, Tefedora, tipo ABS, tipo Launchpad di Ubuntu, quelle sono ancora cose tecnologicamente valide.Però on top di quel layer là che è molto piccolo e che ha molta meno superficie d'impatto c'è il Flatpak che è universale tra l'altro quindi ti dà...non sei legato alla lore della distro, ai problemi specifici della distro e ti mantieni solo quello che è di acidistro.E allora perché non farlo con i container? I Flatpak so container.Ah tu dici la parte sotto? esatto e la parte sotto la fai con i container ma i container sempre zipperin ce fai dentro no no certo no sì sì sì cioè nel senso facciamo così aggiungo anche una cosa alla domanda così sicuramente rispondiamo tutti perché vi triggero in un mondo che cambia se doveste distribuire la vostra applicazione ora? Lo fareste con un con un con un con un image neoci, con un pacchetto rpm, con un bundle flap, con un app image che secondo me, qui lo dico più nego, è una bomba e mi piace tantissimo? Come lo fareste? Ma l'applicazione è desktop intendi? Sì, sia desktop sia no.Nel senso tu stai e fai il nuovo crude per la chiesa e lo devi mettere sui server.Lo fai con l'RPM, con il container, con il file zip e lo metti dentro i virtual host di Apache, tipo boh non lo so, una...No, no, cioè l'approccio quello del file system immutabile, eccetera, ti dice "oh sì, perché non è compito dell'abbésime già avere il crudella chiesa da installare.E ti dirò anche un'altra cosa che noi su OpenSUSE lo facciamo diverso e è fatto in un certo modo il file system immutabile.Il file system De Fedora Silverblue è uno CI."improvvisamente le cavoce scoppiano" sì concordo con adesso poi secondo me appunto dipende dall'applicazione che fai o dipende dall'uso che fai di Linux, cioè se è per l'uso desktop e se è per l'uso server ormai diciamo che i carichi di workload nel 2024 si faranno ai container.Nel uso desktop è comodo il flatpack però anche lì non ho visto grandi documentazioni su come si fa un flatpack.Se io voglio fare il mio flat pack, come faccio a contribuire, dove li trovo, dove li scarico, come li buildo.Alla fine abbiamo preso il problema di RPM e l'abbiamo spostato da un'altra parte.Sì sì, concordo.Alla fine ci riferiamo sempre a quelle risorse solite, due o tre siti, dove puoi scaricare il Flatpak, però anche lì diventa una centralizzazione del software, mica male per dire.Speriamo che siano sempre trostati, siano sempre validi, sempre buoni questi Flatpak che scarichiamo.Diciamo che là c'è la risposta a quella del quello che vuole fare il benaltrista che ti dice "ah ci sta il beggetto su FlapTab" che è una risposta che non piace che è lo stesso tipo di cosa tipo Slack se ricerca i DM degli utenti e ci fa l'intelligenza artificiale "eh vabbè ma c'è l'opt-out" Per cui sì, sono alternative molto comode e poi tra l'altro non abbiamo neanche citato si può utilizzare un container dentro la distro, cioè tu puoi usare una distro normale come Tumbleweed e usarla come se fosse una immutabile, semplicemente installando Flatpak, installando i pacchetti che ti servono via Flatpak, oppure usando Tool come DistroBox per lavorare con container e tu la tua distro praticamente non la tocchi quasi mai.Tra l'altro non abbiamo neanche detto che se per caso qualcosa va male, in un aggiornamento di Thumbweed, e a volte per carità può anche succedere, puoi sempre fare snapshot rollback e torni indietro al sistema esattamente come era prima dell'installazione perché zipper fa i snapshot prima e dopo l'installazione di pacchetti qui puoi tranquillamente fare gli aggiornamenti a post e reno perché tanto male che vada torna sempre indietro è una bella garantia che puoi rispondere.Se si approfondire il file system transazionale tutta la tecnologia che sta dietro a queste cose che sta dicendo Andrea, Andrea si ammazza perché io considero la concorrenza perché Ftl ha fatto molto bene.Noi su OpenSUSE lo facciamo con un tool che si chiama Transactional Update e gli snapshot di B3FS.E questo si apre tutto quanto un altro capitolo che non apre prima.Sì, guarda lasciamo perdere.C'è un altro strumento che si usa per fare queste cose che è quello che usa Fedora che si chiama RPM OSTRI, che praticamente è tipo un affare mitologico che ti prende il il pacchetto che tu stai installando e lo trasforma in una transazione e praticamente fa la stessa cosa che fai quando fai uno step di build di un Dockerfile.È una cosa veramente allucinante che io se se avete qualche notte de sonno da perde perché il bambino ha vomitato, queste cose qua assolutamente ve lo consiglio.Domanda quindi, a questo punto, perché insisto, è una cosa che è interessante, sia per Luca sia per Leonardo, nei vostri anni dove avete deploiato le vostre cose, io non ci ho mai pensato a fare l'RTM, cioè nel senso in tempi più o meno moderni faccio il container, non me lo ponevo il problema, c'è lo script con il compianto capistrano, non so nel senso se si usa ancora oggi, che ti scaricava il sorgente sulla macchina e ti traviava o che ti metteva i file pphp in una certa cartella e si faceva facile.Secondo voi, alla luce di tutto quello che stiamo dicendo, oggi è tutto container, le persone vogliono i container oppure c'è ancora spazio, a prescindere da quanto sia, si cambia l'azienda per fare qualcos'altro.Io penso che i container sia una validissima alternativa ma che spesso li si sceglie a prescindere, come si sceglie di fare la cosa serverless, o di fare la roba col servizio del cloud provider che non si capisce nienzo.Nel senso, c'ha ancora spazio questa cosa oppure no? Rispetto anche se vi riguardate in dietro, come è cambiato il modo di distribuire e di rilasciare ciò su cui lavorate? Allora, io riporto un'esperienza di quando ero un Linux user che ero molto contento dei Backend Manager che usavo, principalmente Deb, qualche volta RPM, ma quando c'era un conflitto io non sapevo dove mettere le mani.Mi avevano detto di fare questo one-liner e mi si installa l'applicazione nuova, invece no.E quindi sarei a dire "allora fai il super giarrone con tutto", che però si porta dietro i problemi che deve essere aggiornato nel caso che una dipendenza che la mia testa eh sia sia aggiornata.Ma anche tu leggevi Pollycock? Come? Anche tu leggevi Pollycock e ti facevi i pacchetti dei compit del cubo desktop se vuoi qua no? Eh ci ho provato una volta e ho risultato quando ha funzionato per cui probabilmente eh non non era non era così esplicativo.Io sarei per dire cioè c'è il mio pacchetto ti do tutto quello ormai stiamo parlando di file, ti do tutto il pacchetto e te lo installi, al limite occupa più di quello che ti serve, però si porta dietro problemi dell'aggiornamento.Un po' compromesso, non ho una risposta e non ho una grossa esperienza perché noi diciamo non ho mai fatto pacchetti o distribuito cose che ci prendi e lo installi, mentre per Adme te lo con fili queste sono le istruzioni per farlo funzionare senza senza altre cose sopra.Volevo aggiungere che è venuto in mente stiamo parlando da un'ora un quarto di come installare una nuova versione dell'applicazione e quanti problemi ci sono perché le più complesse io voglio io voglio solo la versione nuova e invece sotto c'è tutta questa questa roba quattro che in realtà c'è sì sono d'accordo anche con leonardo io non ho grande esperienza io appunto direi manderei le istruzioni dico per installarlo fai cool https studio sh poi me la vedo io nel tuo sistema operativo sono sono più di questo no però per per le piccole cose che faccio? Attualmente sì, faccio container ma semplicemente perché è quello che la gente vuole.Se la gente vuole quello io gli do quello.Se fossi stato in un'altra epoca avrei dato le istruzioni per farlo passo passo sul sistema.Se fossi capace a fare pacchetti, ma adesso, dopo questo podcast, dopo questa puntata, ci riproverò e sarò capace in qualche modo.Per quello che è il sistema operativo mi aspetto di usare il package manager del sistema operativo per tutto il resto si può fare quello che si vuole, anche "circle by bash" l'ho visto fare tante volte però mi aspetto che se installano a distro, non so se è perché per abitudini o che, però la debia di Vim o di Bash mi aspetto di avere un container con dentro Bash la base image.La domanda la domanda de Marzullo del duemila e ventiquattro è dove finisce la base image? Dove inizia la linea? se abbiamo inventato il tappino che non si stacca dalla bottiglia credo che anche questo problema potrà essere risolvo risolto in in tempi brevi quindi allora guarda io io io conversazione un po' di tempo fa in cui chiedeva una cosa del genere ma ho risposto "eh, ma tra un po' sarà tutto un unicernel", cioè quindi capito siamo proprio andati oltre così, quindi non so veramente dove comincia e dove finisce, non credo che ci sia una risposta, ma è interessante comunque come il tempo passi ma si cercano di risolvere sempre gli stessi problemi in una maniera leggermente diversa.Cioè, è tutto diverso ed è tutto standard.Insomma, la mia massima esperienza di packetizzazione di qualche anno fa è stata una formula di brew su Mac, che secondo me è un po' più moderno come approccio anche per per schiverlo però alla fine si stava risolvendo lo stesso insomma problema cioè boh alla fine i tempi cambiano ma ci sono sempre gli stessi problemi.Ecco considerando che siamo ad un'ora e un quarto a questo punto farei la domanda insomma così e quindi Andrea come funziona il testing di questi pacchi, il testing di una distro.Perché qui è bello che stiamo parlando, io faccio la sub mission, mi accettano, mi fanno, insomma, così eccetera eccetera, ma alla fine se io mi installo l'IP ci sarà qualcuno che questi pacchetti ha visto se funzionano o meno.Come funziona tutto questo processo? Allora, intanto quello è proprio il mio lavoro, nel senso che io sono un QA engineer, quindi diciamo che di lavoro faccio il testing, quindi prima di tutto faccio quello e poi quando basta tempo faccio un po' di parchetti di eduzione.Allora, il problema di fondo è come vai a testare un programma, quindi il problema eterno è quello lì, cioè cosa effettivamente andiamo a testare noi e qua c'è la fantasia del test perché uno può inventarsi mille test diversi, si parte da banalmente installo il pacchetto, funziona, si installa senza conflitti, se c'è un conflitto come diceva prima Leonardo per me è già un no, quindi non do l'ok a rilascio.Poi una volta installato il programma funziona, fa quello che deve fare, è conforme alle documentazioni, a quello che dice di fare, oppure una volta che l'ho lanciato mi formata la macchina.Questo è un altro test da noi facciamo test automatici in SUSE, usiamo un tool che si chiama OpenQA che ci siamo scritti noi praticamente, cioè ci sono scritti gli altri, non io ovviamente, è un grotto programma abbastanza complesso e quello che fa è testare, è nato per testare intere distribuzioni, questo programma è anche un hypervisor, quindi lui lancia una ISO di una distro in una macchina virtuale e verifica, con degli script che scrive il tester, cioè noi praticamente, che le immagini coincidano, gli output a video siano quelli che ti aspetti, i log, i file di dauto siano quelli giusti che dovrebbero esserci se eseguo un comando allora questo comando ottiene l'auto che mi aspetto eccetera eccetera questa cosa qua viene fatta in automatico ad esempio per ogni submission di pacchetti quindi ogni volta che qualcuno fa una submit di un pacchetto parte un processo automatico che crea una nuova macchina virtuale, fa partire la distro desiderata, quindi fa partire quattro macchine virtuali, una con la 15.5, 15.6, Targoid e SlowRoll, per esempio, e su queste macchine qua fa partire il sistema base, poi del sistema base installa il tuo pacchetto e qui il tester, cioè noi qui engineer, scrive del codice per verificare che il pacchetto faccia quello che deve fare.Quindi si può andare dalla semplice installazione oppure se è un pacchetto, faccio un esempio, Firefox, tanto per prendersene per quello, lanciamo Firefox nell'ambiente grafico in vari ambienti grafici quindi KDE, GNOME, Xfce eccetera eccetera e vediamo l'immagine di Paragsof Cache, interagiamo con Firefox scrivendo nelle url nella barra di indirizzo in un sito di riferimento, verifichiamo che il sito venga renderizzato correttamente da Firefox, proviamo sempre tramite l'API di OpenQA possiamo interagire con la macchina virtuale, quindi possiamo premere tasti, muovere mouse virtuale eccetera...scriviamo, cambiamo delle opzioni di Firefox, settiamo i cookies, cancelliamo...facciamo quello che farebbe di fatto un utente, quindi è un po' una specie di...se qualcuno conosce Selenium, Playwright, qui faremo un po'...però per tutto il sistema operativo quindi lo facciamo per il browser ma lo facciamo anche per il volume manager di linux lo facciamo per il kernel lo facciamo per tutto il sistema operativo è testato con migliaia di test automatici e insomma è un bel bel bel risultato però a volte si spacca qualcosa ovviamente non sempre tutto funziona perfettamente, specie da un aggiornamento all'altro si vedono le piccole differenze, però facciamo quello che possiamo per testare il software.Poi questo era a grandi linee OpenQL e Apore, se uno vuole se lo va a vedere.Ci sono dei test specifici per determinati pacchetti, ad esempio per il kernel c'è la suite LTP? Io ti stavo proprio per chiedere questo! Papacassaro raccontami di LTP! LTP è una suite di test specifica per il kernel, è un progetto open source congiunto non solo di suze di IBM, c'è Red Hat dentro, c'è Microsoft, c'è Fujitsu, sono un po' di grosse aziende che contribuiscono con codice effettivamente quindi è un progetto pubblico open source di fatto è una enorme suite di test che testa tutte le syscall del Kernel, quindi partiamo si chiama Open che sta per un file, proprio quello del kernel in LTP c'è una serie di test di funzioni che chiamano la Open del kernel con parametri tutti i più svariati possibili, quindi la prova a chiamare con un puntatore nullo, la prova a chiamare se si aspetta un file descriptor tu gli passi -1, si aspetta un buffer di 256 byte, tu gli non passi uno da 10 giga e così.Texting a tutto spiano, stiamo anche introducendo del founding, da quello che ho sentito ultimamente, per verificare che da un aggiornamento all'altro, ad esempio del kernel, le AC score rispondono allo stesso modo, perché può succedere che il kernel viene aggiornato, viene modificato costantemente dai sviluppatori e grazie a questi questi suite di test noi riusciamo a capire quando ad esempio un aggiornamento potrebbe andare a impattare sulle applicazioni perché noi di fatto testiamo lato utente e lato syscall.Poi se volete parlo un'altra mezzogiornata, si fanno anche test di performance ad esempio, perché noi abbiamo anche un reparto che fa il testing di performance a livello di I/O di disco dirette, quindi provando ad esempio un aggiornamento da un kernel all'altro se le performance cambiano sotto una certa soglia, il percentile stabilita da contratto eccetera eccetera allora in quel caso lì il kernel viene rifiutato l'aggiornamento perché vuol dire che andrebbe troppo lento rispetto a quello di prima quindi non avrebbe senso cambiarlo, magari ha senso se risolvere i problemi di sicurezza eccetera però noi facciamo anche aggiornamenti, c'è anche test sulle prestazioni, sui consumi di risorse, se un programma occupa troppa RAM rispetto a quella di prima, per noi è un aggiornamento che magari mettiamo in dubbio, vale la pena mandarlo fuori il suo aggiornamento.Dopo sono valutazioni che vanno fatte di caso in caso, però passiamo al lato testing ci sbizzarriamo parecchio.Testiamo anche le migrazioni, una cosa che pochi considerano è ad esempio un cliente che ha Suse 11, vecchia Suse, e vuole aggiornare a SUSE 15.3 a 15.6, che sono dei reparti apposta che fanno anche testing di installare una versione e lanciare la procedura di migrazione della distro, quindi di aggiornamento della distro da una versione all'altra, cosa che il Suse è permesso, non credo che l'altro faccia, non sono sicuro, da una major all'altra, senza ristallare niente.Per cui anche lì testiamo, ad esempio, perché passando da una versione all'altra tipicamente cambierai versione di MySQL, versione di Postgres, versione di Apache, versione di Nginx.Quello che facciamo noi è installare applicazioni di test di prova fatte apposta che verifichino che l'installazione faccia anche la migrazione dei dati da una versione all'altra.Quindi si cerca di testare tutto quello che si può testare.Ovviamente è impensabile fare questo anche per i micro pacchetti, le piccole librerie, fate diciamo magari per i big player perché quello magari l'ottanta per cento dell'utenza si aspetta che sono sarebbe semplicemente non possibile fare una release di una nuova versione.No no, lo facciamo su richiesta su esigenza dei clienti che spesso ci segnalano queste cose qua.Un cliente ha un grosso storage array, una SAN enorme e magari vuole testare che compramo una certa scheda Fibre Channel, il Kernel supporti ancora la modalità di trasferimento che usava prima perché gli faceva comodo usare quella lì.Quindi facciamo un po' di tutto.C'è anche una parte di testing manuale.Lo chiedo perché, nel senso, ho visto al Fosden qualche anno fa e mi è rimasto affascinato, e ho cercato di proporlo in diversi posti, insomma, dove sono stato.Quello che in gergo si chiama il Test Case Management System, che è perché se lo stessi immaginando è tipo avere delle check box manuali, quindi di cose che magari non sono automatizzabili o non automatizzabili, e puntarle se quella cosa funziona.C'è anche questa parte qui o è tutto automatizzato? Cioè c'è tipo questa checklist scritto "ok, questo va, questo va, questo va" e lo testate manualmente? Allora, si cerca di fare il più possibile automaticamente.Cioè il mio lavoro è proprio automatizzare le cose che gli altri fanno manualmente.C'è un team che fa, si chiama Update Validation, cioè prendono poi gli aggiornamenti e fisicamente lo installano sui su varie macchine diverse che possono andare dal mainframe alla DMAX perché noi gestiamo anche questo tipo di architetture abbiamo una batteria di raspberry dove installiamo gli aggiornamenti e quindi loro testano manualmente le cose che non si possono automatizzare però diciamo che cerchiamo anche di collaborare con questo team perché ci comunichino dove diciamo spendono più tempo, dove è più complicato testare manualmente e man mano che passa il tempo arricchiamo la nostra suite di test automatici in modo che diventa sempre più facile per loro testare le cose perché hanno meno cose da testare praticamente e è sempre più comodo per noi, è sempre più veloce farlo.Mi pare che negli ultimi tre anni, grazie ai test automatici, abbiamo tipo triplicato il numero di rilasci che riusciamo a fare dentro un anno praticamente, quindi automatizzando ovviamente si riesce a fare molto di più e spesso anche senza errori dell'utente e così via.Ovvio che la fantasia, la genuinità di un testere esperto è difficile da riprodurre automaticamente, perché magari qualcuno che conosce esattamente quel pacchetto lì, magari riesce a in quel momento lì a testare una cosa, a verificare una cosa che in automatico non ti viene spontaneo, non ti viene in mente, perché magari per testare un determinato aggiornamento fai caso esattamente a quella cosa lì che in automatico non puoi fare.Ad esempio nel caso di OpenSSL ci sono gli aggiornamenti che magari vai a testare che certi algoritmi criptografici non si rompono da un aggiornamento all'altro, non puoi fare in automatico ma a volte si fa anche a mano.Anche banalmente installare il sistema operativo nuovo quando esce una versione nuova su un computer a caso, cioè prendi un portatile vecchio e ci stavi sopra su The Linux potresti scoprire cose che all'automatico non hai scoperto, magari la USB della tal marca non funziona perché non l'hai mai provato in automatico e così via.Questo è interessante, nel senso c'è un IBM Z da qualche parte con quell'architettura che fa girare le cose, nel senso anche quando noi diciamo che le cose vengono buildate su OBS, ok? Vengono comunque cross compilate o ci sono proprio delle macchine che girano su quell'architettura anche molto esoterica, diciamo? Sì, sì, abbiamo delle macchine apposta, abbiamo macchine fisiche donate dai BM, dai cosi' spumenti vendor eccetera, sono un data center, disponibile di tutti, sia su architettura ARM 64 bit, RISC-D, PowerPC, S390, volendo se volete abbiamo accesso anche a un mainframe personale.Possiamo dare una distanza sul mainframe.Dettagli.Ok, allora siamo ad ore 33 di registrazione, quindi a questo punto direi se avete tutti un'ultima domanda e poi possiamo passare, perché tanto so che occupa tutta l'altra mezz'ora, possiamo passare agli sbalocchi.Una domanda che, insomma, c'avevo in canna poco fa, non so se alla fine si è dato per spuntato o si è detto e mi è sfuggito.Io faccio il mio software, la mia nuova app, la mia nuova calcolatrice che voglio, o una libreria, non lo so, che non voglio distribuire, però facciamo che la faccio e la metto open source con le istruzioni di installazione.Succede o è possibile, e immagino dipenda comunque sempre dei vari contesti, che poi chi fa il pacchetto vero e proprio è un altro che non ha niente a che vedere con me? Beh sì, hai all'interno più frequente, anzi, praticamente sempre, siccome parliamo di software open source, perché non abbiamo mai parlato di licenza stasera però, se la licenza lo permette chiunque può prendere quel software lì e farci quello che vuole, quindi dipende dalla licenza che hai messo sul tuo software ovviamente, ma se la licenza è ok e corrisponde all'open source io posso prendere il tuo software e il pacchettizzarlo anche senza dirti niente per esempio e distribuirlo perché vuoi dire è free software.Sicuramente puoi forcarlo e farci quello che vuoi però di sì no alla fine si deve per forza forcare e fare quello che vuoi.Questo implica anche distribuirlo.Sì sì ma non è detto che devo forcare il progetto fisicamente su GitHub, posso semplicemente scaricarmi il target data e via.Sì però nel momento in cui c'è bisogno di fare una patch di sicurezza o qualcosa a quel punto chi è l'owner? Se lo faccio io e poi tu devi...come si diceva prima, chi sviluppa più veloce rispetto al maintainer e a un certo punto forse la parte di organizzazione.Rispondo come risponderebbe il mio capo, l'owner è la community.Open source, quindi chiunque può prendere quel pacchetto e migliorarlo, farlo una versione più recente.Non è detto che io che ho fatto la versione tre anni fa abbia ancora voglia o motivazione per fare la versione nuova.Potrebbe essere un'altra persona, potresti essere tu stesso che magari visto che facendo il pacchetto di tuo software viene più usato e quindi hai un vantaggio anche tu, potrebbe essere chiunque.per cui stiamo parlando della community, quindi non c'è un vero owner, se non a livello virtuale, c'è il maintainer del software, ma alla fine quando io lo forco, di chi è questo software? Mio, è tuo, è di tutti? Ah sì, che non avevo pensato al fork alla fine, perché nella distribuzione del pacchetto mi mancava il fatto che comunque da qualche parte tutto il necessario per creare il pacchetto deve stare e quindi deve essere versionato.Bel tema anche quello dell'ownership, perché alla fine tutti vogliono questi pacchetti fatti e aggiornati, ma nessuno o pochi vogliono contribuire come è nel software, come nel software open source, tutti vogliono i programmi che funzionano belli e tutto, però poi a metterci effettivamente le mani sappiamo bene che contribuzioni quelle che sono, insomma.Non voglio entrarne a polemiche.No, no, quando ci metti le mani a un certo punto esce fuori "ah ma sai che c'è? Penso che questo computer dual monitor, mi sa che me ne tengo un monitor solo".Quelle cose là.Allora a questo punto, tanto, maggio che sia veloce la risposta e se non lo è va bene comunque.La licenza, cioè quindi quando dici la licenza è ok, va va bene, significa che, cioè nel senso quali sono le licenze che vengono vengono consigliate e soprattutto come si gestisce un cambio di di licenza, cioè noi abbiamo visto Redis nell'ultimo periodo, abbiamo visto Terraform ce ne saranno sicuramente altri.Come si gestisce questa cosa? Cioè significa che ad un certo punto quella cosa non viene più mantenuta? Certo, cioè nel senso la licenza che va bene per noi è quella che corrisponde ai criteri della distribuzione.Ad esempio nel caso di Debian, Debian ha come cardine base che vuole distribuire solo Free Software, giusto? Quindi più che ci servono cose particolari ti danno i repository non debian ma di cose non free.Stessa cosa per OpenSource, quindi noi distribuiamo solo software OSI della Open Source Initiative, quindi solo free software.Se uno vuole per esempio i driver dell'NVIDIA che sono closed, deve aggiungere un repository extra della distro che non è gestito da OpenSUSE, se lo gestisce lui si arrange lui ed è gestito da altre persone, grazie che fanno il loro lavoro, per qualità ottimo lavoro, però non è parte della distribuzione, quindi non essendo free software non è nella distro.Poi succede che NVIDIA collabora con noi, quando aggiornano i driver ci dicono "guardate che abbiamo già fatto i driver, fate il pacchetto" poi c'è la collaborazione Se un pacchetto cambia licenza invece si gestisce con la versione, fino a una certa versione il prodotto era free software, da una certa versione in poi non sarà più free software e quindi si smette di distribuirlo nella versione open source, eventualmente se ci sono alternative si installano alternative e se non ci sono, niente, bisogna rispettare le licenze che non c'è da discutere.quindi troverai distribuzioni che distribuiranno Redis fino a una certa versione e poi basta, oppure se far distribuire la versione, adesso non sono aggiornato su Redis in particolare, distribuiranno la versione distribuibile di Redis.Ok, domanda così prima dei balocchi sicuramente polemica, per tutti, secondo voi uno strumento come copilot o similari può aiutare in questo tipo di lavoro? Perché nel senso io so qual la policy di OpenSUSE e la condivido appieno.Ma secondo voi? Cioè dice qual è la policy di OpenSUSE? Che allora, non so la frase corretta, ma che non è consentito utilizzarlo.Ah, ok, un po' un discorso diverso, secondo me.Parli di sviluppo software o di pacchettizzazione? Di pacchettizzazione, cioè nel senso alla fine mi sembra un task che è molto specifico con la documentazione che è difficile reperire.Secondo me uno strumento come Copilot o similari potrebbe dare un boost a questa cosa, oppure no? È una domanda che sto facendo spesso a diverse persone che fanno diverse cose, ad esempio c'è magari quello che mi dice "no perché io faccio il kernel", "no perché io faccio un'altra cosa", allora per chi fa il pacchetto potrebbe essere utile e che ne pensate in generale? Dai facciamo così la domanda.A me non piace.A me non piace proprio lo strumento però nel senso che fatti scrivere in RPM spec da un assistente c'hai quel momento, c'hai quella fric...c'hai quando devi fare un pacchetto RPM, c'hai quella friction iniziale, quel momento in cui scrivi, appare in file bianco e non sai che c'è, devi scrivere e devi rileggere tutta la doc per capire che c'è, devi scrivere.Quella cosa, quello step là, quello scaffolding iniziale, mo' sicuro Andrea mi dice "no guarda c'è stanno i scaffolding" linkameli e mettili nei balocchi perché io non li so e me servono, cioè letteralmente me servono in questo momento e quindi sì, datemi i scaffolding degli RPM perché se no non so come pacchettizzare una cosa che tra l'altro sta nel Redmine open source e volevo fare questa contribution, ma mi sto perdendo per strada.Come assistente generico è difficile che sia stato addestrato su queste cose.Questo è vero, tra l'altro.È un po' borderline, perché non troverai molti dettagli tecnici, però immagino che sia più facile farsi fare un script python che è uno spec file, perché alla fine non è così diffusa la cosa e per gli stessi motivi ovviamente.Poi quello che faccio anche io banalmente è prendere uno spec file di un altro pacchetto, quindi essendo open source io posso andare a vedere come ha pacchettizzato quella cosa lì Fedora, ad esempio, oppure come fa Arch, come si ha risolto dei problemi di compilazione.Essendo tutto open è un vantaggio che possiamo, come sempre, andare a vedere il lavoro degli altri e imparare il lavoro degli altri.Un assistente, tipo un io personalmente non l'ho mai usato ma non vedo neanche grande necessità perché alla fine tu un pacchetto da vero lo fai la prima volta e poi vai solo a fare piccoli aggiustamenti incrementali per cui è come dire devo fare un programma nuovo, fare una web applicazione nuova, ok ho il tuo di scaffolding, farlo utile la prima volta.Poi, è tutto quello che fai, aggiungere feature, togliere cose, fare testing, provare, cambiare.Può essere utile la prima volta, ma alla fine, secondo me, è molto più proficuo fare prove o leggersi la documentazione.Tanto alla fine non rischi di rompere nulla, ti fai un pacchetto nella tua home e non è che rompi la distribuzione, voglio dire se funziona provi da solo, provi sul tuo pc, lo fai girare sul penqa e poi Secondo me, non so ovviamente il caso specifico, perché non ho idea di come fare uno spec file, quindi...però io adotto questa regola, uso AccoPilot e simili quando so che è più bravo di me.e quindi, o meglio, quando so che io sono ignorante a bestia su quello che devo fare, chiedendo a Copilot o facendo fare l'autocomplete a lui, anche se non dà una cosa funzionante, comunque mi mette quelle parole chiave o quel keyword, o quelle funzioni, quelle specifiche che poi riesco, con una googlata o con una documentazione, andare a vedere, andare a studiare quella parte lì.Quindi probabilmente in questo contesto sarebbe utilissimo perché, ok, cosa devo scrivere? Magari, forse, se è un po' allenato riesce a darmi uno schema, scaffolding di questo, se non so nemmeno dove trovarlo a questo punto.E quindi sì, su cose dove so che non ho problemi, che sostanzialmente perdo più tempo a controllare perché mi fido poco quello che fa copilot è simile a poco senso.Un amico per esempio ha avuto la svolta perché doveva programmare e mantenere un progetto open su android e per vedere la retrocompatibilità di alcune funzioni su android della versione 9 piuttosto che la 10 piuttosto che la 11, in quello Copilot aiuta tanto più che una googolata perché lui non è master in android, quindi non conosce tutto il percorso.Sviluppava fino a poco tempo fa la 8, adesso c'è la 12 e chiede che cosa fa, come migrare un pezzo di codice.In quello funziona una bomba.Questo in linea generale.Allora ragazzi faccio proprio una roba hard limit, proprio per una questione infrastrutturale, perché nel senso io questo form dove si paga su Steamyard non l'ho ancora trovato come farlo mentre registriamo.Quindi via con il momento dei balocchi.Cominciamo da Andrea.Io ho tre balocchi perché sono generoso.Il primo che vi porto è questo repository che si chiama Awesome Package Maintainer, che è un po' il cheat sheet per chi vuole diventare maintainer di un pacchetto, scritto da una brava persona cina ed è completamente costantemente aggiornato quindi potete anche fare pull request eccetera e ci sono un sacco di bei trucchetti e vi spiega i tool, vi spiega proprio le cose per iniziare e quindi vi consiglio di leggerlo.Il secondo balocco che vi porto da tester, questa volta ho inventato il cappellino da tester.È questo articolo che ho trovato questa mattina su Scientific Americans, praticamente come una fabbrica di birra irlandese famosa ha inventato il t-test, praticamente un test statistico che ha rivoluzionato il modo di fare statistica, quindi come la Guinness ha cambiato il mondo della statistica e del testing in generale.L'alcol porta sempre bene il visio.La soluzione di tutti i problemi dell'uomo.Visto che siamo a Githubar si parla di birra.L'ultimo mi piaceva portarvi un libro che anch'io sono appassionato lettore ed è questo libro qua "The Art of Painting Clearly" di Rolf Dobelli, poi vi scrivo anche il titolo dell'autore.Praticamente è un libro molto snello, sono un centinaio di biais cognitivi spiegati bene, 86 capitoletti da due pagine, quindi si legge abbastanza a modo snello.Ogni capitolo affronta un differente bias cognitivo, quindi bias di conferma e così via, un sacco di cose interessanti.Vi spiega anche come non cadere in questi bias, purtroppo ci cadiamo molto spesso tutti quanti, e lo consiglio perché a me è piaciuto come libro, "The Art of Thinking Clearly" di Rolf Dobelli.Volevo aggiungere sul fatto dell'OSOM che se cercate su GitHub "osom" trettino asterisco trovate una serie di linguaggi di programmazione, qualsiasi cosa trovate risorse e kudos ai i maintainers che mantengono queste liste.Io ho un podcast che ovviamente non c'entra nulla con la puntata, però si chiama Brain on Fire ed è un podcast corto, sono 5 puntate da 25 minuti in italiano, dove un dottore, uno psichiatra parla delle ADHD.Quindi lo consiglio perché chi è stato magari diagnosticato o ha dei dubbi può capire di più su questo su questa divergenza neurologica, che è un problema sulla concentrazione, anzi sulla capacità di mantenere l'attenzione su una cosa, e secondo me molte persone si possono trovare, metto l'indicatore in descrizione.il tutorial di Open Build Service che è una documentazione estremamente precisa di come funziona il packaging su Open Build Service in particolare.Allora, vado velocissimo, non so se già stava portato, probabilmente sì, ma lo sto leggendo proprio in questo momento, lo sto rileggendo perché la prima volta l'avevo letto a cazzo di cane."Crafting Interpreters" di Robert Nystrom, mi sembra.Aspettate che questo ce l'ho detto bene."Crafting Interpreters" di Robert Nystrom.Sì, è un libro che vi che vi spiega come creare l'interprete del vostro linguaggio di programmazione preferito.In realtà è un linguaggino molto molto semplice.Non è un tutorial, nel senso che non è un tutorial, insomma vi guida passo passo e anche alcuni richiami, secondo me, interessanti su come funziona un linguaggio di programmazione, come si passa dal testo poi all'esecuzione di ciò che voi state facendo.Che è una cosa che con i type system più moderni e più complessi sono concetti che stanno ritornando e che sono più importanti che mai, specialmente quando parliamo di metà programmazione.Vai Luca.mio balocco è un'applicazione, avevo la necessità di monitorare il mio tempo, darci un costo, gestire più progetti eccetera eccetera, ho trovato questo bellissimo tool, applicazione open source che si chiama KeyMai, te lo installi sul tuo server, c'è sia un premis che sas, anche se c'è un docker io l'ho installato a manina, con StratoGenX, Reverse Proxy, PHP eccetera eccetera ed è carino, ti crea anche le fatture, sto costruendo un plugin per la fatturazione elettronica e poi quando lo pubblicherò lo rilascerò open source, la licenza è compatibile, quindi ci sta, che non mi piace, per me è solo questo.Ok.Credo che ci siamo tutti.Alessio dove sei? Ah allora allora ripetiamo i contatti così eccolo eccolo eccolo qui Alessio ci siamo tutti quindi ripetiamo i contatti in chiusura ah ci potete ci potete trovare sul nostro magnifico gruppo di mille e cinquecento persone e ci trovate lì e non è il classico gruppo asterisco asterisco Italia.Poi il canale YouTube che io ogni volta me lo scordavo il canale YouTube GitBar Podcast bellissimo veramente mettete la cliccate sulla campanella come dicono quelli bravi.Campanaccio.il campanaccio per discorsarsi da asterisco asterisco Italia.E poi ho info@hitman.it che non so se funziona e non so se voi mandate ancora le mail ma...Che altro? per chi non è dentro.etto prenderemo su Twitter e quindi sì mi pare che che che che abbiamo fatto tutto quindi un un ringraziamento ad Andrea per essere stato qui con noi queste due ore insomma alla fine le abbiamo le abbiamo fatte tutte eh un un argomento non trovate su tutti i podcast.Attenzione.Quindi ringraziamo Andrea, ringrazio Luca, Alessio e Leonardo e ci vediamo.E Carmine me stesso.E i Carmini questo plurale maiestatis.e ci vediamo alla prossima puntata.Ciao! Ciao a tutti! E donate perché i libri di HP per Mauro costano un botto! Sì, grazie! Grazie ai donatori che non sappiamo chi siano! Non sappiamo chi siano! Sulla settimana! Sulla settimana! Ciao ciao! Ciao! [Risate]
