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 su GITBAR, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Mamma mia, in realtà voi mi state sentendo tipo tre settimane dopo, ma questo è il terzo episodio che registriamo in circa 17 ore e devo dire che tre episodi sono sono tanti di cui uno appena finito di registrare quindi veramente stiamo andando a cotimo stiamo andando a cotimo per preparare dei buoni contenuti per la nostra community community che potete trovare appunto nel gruppo telegram dove è anche superattivo il mega ospite di oggi che tra l'altro ci porterà un topic dove tipo Mauro sindrome dell'impostore fatti avanti perché io tipo sono...avete presente quei bambini quando...vi spiego la mia situazione, un bambino davanti all'albero di Natale che sta per...la cui mamma sta per arrivare con tipo il regalo che ha sempre aspettato ecco questa è la mia situazione in modalità natalizia fremente, ma prima di presentarvi l'ospite.Vi ricordo rapidamente i nostri contatti.Info che ho c'è la github.it e t-brain repo in modo classico per contattarci.Gruppo telegram l'abbiamo già detto e guai se non vi iscrivete.Abbiamo anche un canale youtube nel quale potete iscrivervi e cliccare sul campanaccio che è il modo per rimanere aggiornati su tutte le news.Ehi anche questa puntata è registrata in collaborazione con Fisco Zen, esattamente tutto quello che serve quando si ha partita IWA.Sono veramente veramente felice di avere qua a Gitbar una delle star del gruppo Telegram.Voi lo conoscete come Tecnoraver ma al secolo è Matteo Croce, software engineer a meta, ma anche kernel contributor.Ciao Matteo come stai? Bene bene e tu? Io a parte la stanchezza direi bene ma anche tu in quanto stanchezza mi dicevi che non sei a meno dopo aver fatto fatto le tue traversate transatlantiche.Ho fatto delle belle traversate sì.Bello, bello, bello, bello.In realtà tu sbarchi a Meta relativamente recentemente, credo che abbiamo visto proprio il tuo aggiornamento nel gruppo.Prima hai fatto hop su un po' di grandi aziende, nel tuo curriculum c'è Microsoft, c'è Canonical, c'è Red Hat tu vieni da una piccola regione italiana, come per un ragazzo di una piccola regione italiana, che è già una piccola parte di mondo, veramente piccola, essere proiettati in un contesto di queste grandi aziende? Perché finché una la trasformi in casa, ma quando ti muovi tra queste aziende, qual è stata la tua sensazione? All'inizio, prima ancora di iniziare a lavorare, il problema era proprio, come dicevi in Calabria, che la connettività internet era un problema e quindi all'inizio, prima ancora di iniziare a lavorare, studiando, era veramente difficile recuperare la documentazione.Quindi iniziavamo comprando in edicola i cd, i dvd o programmo, i compilatori con le documentazioni.Anche poi non ci sono grandi aziende in Calabria, quindi da lì poi mi sono spostato a Milano e ho cominciato a lavorare in una startup in Milano.e sono entrato prima in una piccola azienda e poi in un'azienda un po' più grande.Però sì, in Calabria c'è poco.Adesso quando io torno in Calabria diciamo che è diverso, perché torno già da dipendente, già da dipendente della multinazionale, quindi mi collego, lavoro la VPN come se fossi in ufficio a San Francisco.Però all'inizio sì, effettivamente è un po' spesante.Ti capisco perché in realtà io da sardo, come hai detto dei cd e delle riviste, mi hai aperto un mondo e mi hai ricordato quando io ragazzetto andavo a scuola dove c'era un unico computer per aula che era già una rivoluzione, sto parlando dei primi anni 2000, e siccome a a casa internet costava rimanere tanto connesso e invece quei computer avevano l'ISDN sempre attiva, io ricordo che avevo i miei floppy, ancora prima dicevi proprio i floppy che era una roba che potevi portare agilmente senza masterizzatore, senza dover aspettare installare nero e fare queste cose.E facevo salva delle pagine web, per leggermele poi a casa con calma e e io così ho imparato a programmare, a far ridere ma è così e certe volte la scarsità questo è proprio un ragionamento che isola un po' da quello che stiamo dicendo ma a certe volte penso che la scarsità aumenti la stickiness verso l'obiettivo e soprattutto aumenti in qualche modo o ci dia più tempo per riflettere sulle poche informazioni.Quando è veramente faticoso reperire le informazioni, tu ci ragioni pesante su quelle informazioni ed è un po' una cosa che è cambiata oggi no? Quanto ci fermiamo poi a ragionare su quello che apprendiamo e lasciamo il nostro cervello passeggiare su quei concetti? No perché siamo figli di una bulimia informativa che diciamo vogliamo leggere subito il capitolo ON+1 senza ancora aver capito il capitolo ON, momento boomer di Mauro.Sì, ma infatti una cosa che mi ricordo è quando ero finalmente riuscito a installare la prima Debian con dei CD comprati questa volta tramite un loog perché scaricare 6-5 CD era infattibile con le nostre linee.C'era questo loog che spediva i CD a casa e li comprai.E quando finalmente riuscì a installare la prima Debian ovviamente non avevo internet.Per far funzionare le cose ero costretto leggermi i manuali.Quindi facevo man, man ifconfig, man qualunque cosa.Io credo che adesso siano poche le persone che facciano proprio man e non vadano su stackoverflow o su chat gpt oggi per prendere le informazioni, però quel andare su man ti costringeva a una disciplina, ti costringeva a fruire di informazioni che magari non te ne fregavano un cazzo in quel momento, però comunque facevano le tue foundational, piano piano mattone sopra mattone costruivano una serie di concetti su quali poi posavi il culo quando crescevi, via via crescendo.Quindi secondo me un po' è quello.E un bel giorno tu arrivi e inizi a mettere mano sul kernel.Come ci sei arrivato? Me lo spieghi.Io ci sono arrivato quasi un po' per gioco, un po' per sbaglio, perché praticamente quando finalmente arrivò la DSL nel mio paese comprai un router DSL e mi ricordo che il router aveva dei problemi, non supportava varie cose tipo la DMZ, non poteva aprire le porte.Praticamente un amico mi aveva detto che c'era questo progetto chiamato OpenWrt che ti consentiva di prendere un router, compilarti la tua distro, sparare flash all'e la sopra e avere un prompt entrando in ssh sul router dove poter fare ip tables di tutto.Io quando ho saputo questa cosa sono rimasto estasiato, sono andato su ebay e ho comprato un router a dsl.Arrivo al router a casa, scopro che quel router non era supportato perché i router supportati erano principalmente modelli venduti nel nord Europa dove c'erano le linee quelle che passano sulla TV via cable, le cable line DOCSIS.Nessuno si era mai curato della parte ADSL perché era più usata in Italia, Spagna e altre regioni, altre nazioni.Ci rimasi molto male, allora ho detto "ma quindi non lo lo posso usare questo router?" "Sì, no, guarda, il router funziona, lo puoi buttare, ma non funziona il modem, perché questo driver c'è...abbiamo soltanto un driver che è leakato di una versione obsoletissima di un vecchio kernel e nessuno si è mai messo lì a farlo funzionare sul nuovo".Allora, visto che comunque ero arrabbiato che avevo comprato il loro router sbagliato, diciamo, mi sono messo lì e ho cominciato a portare questo driver, a modificare il kernel, a modificare il driver fin quando...che non deve avere scritto per un carnet tipo 5 anni prima, era molto molto vecchio.Finché un giorno sono riuscito a fare a comprare questo driver, l'ho attivato, ho tirato su adsl, mi sono connesso, a che ho scritto ai mantenitori convertiti, ho detto guardate ho fatto questo lavoro, funziona, sono connesso.Questi...molto contento, ho detto "oh grandissimo, bel lavoro, lo mergeamo, grazie grazie, ma perché non mantiene il port DSL di questo modo visto che non se ne è mai colato nessuno e lì ho cominciato a lavorare su questo progetto.Allora è bellissima l'idea perché in realtà io ti stavo per fare una domanda e tu hai già dato una risposta nel senso la mia esperienza con lo sviluppo così a basso livello è stato un terrore fottuto di briccare le cose.Siccome io ero molto bravo a distruggere qualunque cosa mi venisse sotto mano, il basso livello mi terrorizzava, invece tu dicevi io mi sono trovato in una condizione senza via d'uscita perché era o il router lo tengo così oppure ce lo butto, che faccio? Il caso specifico ti ha forzato quindi diciamo non hai in qualche modo ho vissuto l'idea e il terrore di brickarlo perché era potenzialmente già brickato per te quel router.Ma mi chiedo a quel punto quando tu dici ok va bene c'è da fare un driver no? Era un driver giusto sì? C'è da fare un driver come cazzo ci sei arrivato a scrivere le prime righe di codice? All'inizio pensavo pure io, ma adesso come faccio a scrivere un driver? All'epoca avevo 18 anni, ero giovane, comunque scrivere è davvero una roba difficile.Poi però mi sono appreso i sorgenti del driver, del kernel, mi sono reso conto che alla fine è del codice C normale, Cioè, un posto che uno sappia programmare in C non è molto diverso da altri programmi scritti in C.Cioè, uno può scrivere un programma scritto in C che analizza delle foto, oppure manipola del testo, e invece con l'OnDriver che faceva funzionare una scheda da DSL.Ovviamente non ho messo mano alla parte proprio di gestione dei segnali, di DSP o degli interrupt, però il resto del codice non era...cioè faceva più paura, ma poi quando vai a lavorarci sopra, posto che sempre uno sapeva il programma in C, non era niente di così spaventoso.Molti di noi in gioventù giocavano a ricompilare il kernel e male che vada si spaccava tutto, ma se si è professionisti e si è a partita IVA non si può mica rischiare di fare errori proprio con questa.Per evitare è quasi sempre necessario affidarsi a un professionista, che vuol dire cercare informazioni online, recarsi di persona presso lo studio, andare in centro città, trovare parcheggio, attendere il proprio turno e mamma mia.Esiste un modo smart per farlo che è affidarsi a Fiscozen che collabora con Gitbar per realizzare questo episodio.Fiscozen infatti è un servizio per aprire e gestire partite online che ci mette a disposizione un commercialista dedicato che ci segue dall'inizio del nostro contratto e che possiamo contattare via via appunto che la nostra attività si evolve via mail, chat e persino telefono.Tutto questo appoggiandosi a una piattaforma evoluta che tra le varie cose ci permette di emettere e inviare fatture elettroniche, di avere forecast in tempo reale sulle tasse che andremo a pagare e una serie di altre funzionalità.Per quanto riguarda la dichiarazione di redditi ci pensa appunto il tuo commercialista dedicato Fisco Zen che senza costi aggiuntivi manda pure l'f24 quindi insomma cosa si può voler di più se quello che ho detto vi interessa cliccate sul link in descrizione per ricevere una prima consulenza gratuita e senza impegno con un esperto fiscale in modo adatto a tutti i dubbi e domande sulla partita IVA e eventualmente ci sono anche 50 euro di sconto sulla sottoscrizione del primo anno qualora decidiate di procedere quindi grazie Fisco Zen tu venivi già da altre esperienze in CI allora? no no quello era il mio hobby avevo imparato a programmare in CI come seguendo dei vari tutorial ma non avevo mai fatto niente di serio vari programmini tipo così amatoriali ok perché io in realtà CI se me lo togli algoritmi e programmazione se mi tu gli algoritmi e programmazione avanzata per me il C era quello poi tutto il resto era il vuoto quindi mi immagino invece un ragazzo di appena 18 anni che ha algoritmi non l'ha fatto quindi magari non si è letto il Kerningham Ricci.No.Arrivare a...no il Kerningham Ricci è l'informatica UNICI quindi ho fatto anche informatica UNICI.Scusa sto vaneggiando mi hai aperto cassetti della memoria tipo seduta dallo psicologo No, però dicevo, mi immagino il ragazzo che comunque magari ha fatto un paio di cose come si usava ai nostri tempi copiando pezzi di codice nella rivista e siccome c'avevi solo quel pezzo di codice per una settimana o per 15 giorni e te lo studiavi bene e capivi ogni virgola di quel pezzo di codice, perché quello c'era, non ce n'era di più, a arrivare in qualcosa di completamente nuovo e veramente talvolta è spaisante quindi avere quella stickiness che ti dice no no ci devo riuscire ci devo riuscire non devo gettare la spugna non è una cosa da poco e poi da quel router open vrt come si è arrivato al kernel del deluxo? a lavorare sempre come mobile maintainer di quella architettura di router che si chiamava AR7 fatta da Texas Teens, una serie di modelli di modem praticamente.Poi mano a mano nel progetto arrivavano vari bug anche sulla parte di rete, sulla parte wifi principalmente che era quella più problematica.I driver wifi sono driver kernel, quindi c'è il bug sul wifi, si aggiustava, c'era il bug sulla Ethernet, si aggiustava.C'era un bug sui led perché magari a giorni e non vanno più i led perché è cambiata una cosa, aggiustavi quindi ho cominciato a mettere mano al kernel.Però sempre lì poi mi sono reso conto che era codice C normale.Infatti poi da quando ho fatto i primi commit poi gli altri sono arrivati facilmente perché secondo me c'è un po' di paura perché molte persone quando pensano di delken e decode, "oddio ma quel basso livello, l'assembly, l'hardware, gli interrupt si spaventano" però in realtà sì, magari nemmeno io riesco a scrivere un interrupt handler da zero o il driver di una gpu da zero, però piccole modifiche fix, bug fix o un codice già esistente oppure un po' più di alto livello come un protocollo di rete che è più astratto rispetto al hardware.Si fa no? Si è un livello di complessità diverso, è una cosa che mi dicevano diverse persone, mi dicevano "guarda Mauro, cioè tu stai usando Redux, Conreact, Luke, ma sei sicuro che quel livello di complessità non sia di più rispetto magari a scendere più in basso livello si faceva ragionamento di un database, scendere o di un sistema di uno storage key value.Mi diceva "ah, sei sicuro che quel livello di complessità non sia superiore al livello di complessità di scrivere uno storage key value dove gli algoritmi sono 5 e 6 che devi conoscere, però alla fine è quello, non è un contesto da cui complessità cambia di livello ma non è necessariamente esponenzialmente più grande".Questa cosa mi ha fatto riflettere parecchio e tu mi stai confermando appunto la stessa teoria.A questo punto siccome abbiamo parlato un po' di Kernel, quando si parla di che? Perché spesso mi capita di sentirmi schiato Kernel sistema operativo, si fa un po' merdaio nel tirare le linee per definire le mappe.Allora se volessimo definire il kernel? Il kernel è praticamente il cuore del sistema operativo, quello che parte subito dopo il bootloader e gestisce la memoria, i processi, i file system e le periferiche tipo schede video, usb, rete...è questo programmone che parte, gestisce il cuore del sistema operativo e poi viene e espone delle API dell'interfaccia che vengono utilizzate dai processi che si chiamano user space che sono i programmi che tutti utilizziamo sia grafici che riga di comando in breve diciamo questo.Quindi è una specie di API che wrappa la parte hardware del nostro sistema? o sto sbagliando? si diciamo che c'è l'hardware poi c'è il kernel e poi ci sono i programmi se li stacchiamo diciamo dal basso all'alto così si.ok e quando si parla invece di kernel modules? i kernel modules sono fondamentalmente delle parti di kernel che non vengono caricate all'avvio sempre ma vengono caricate soltanto quando serve.Faccio un esempio banale uno nel suo computer c'è il kernel module della scheda video ATI e della scheda video nvidia se il computer ha una scheda video nvidia carica il kernel module della scheda video nvidia ma non quello ATI perché se non esistesse il kernel module uno dovrebbe caricare all'avvio tutti i driver esistenti nell'eventualità che qualcuno dovesse servire.Per cui il kernel di per sé io voglio fare questo sforzo e la prima cosa che mi viene da immaginare è un kernel come un host di una serie di kernel module più host con la logica dell'host che deve a partire deve esporre un API o un'interfaccia per dare allo user space il modo di appunto comunicare con livello sottostante e poi monta questi modules che fanno delle azioni specifiche, parlano con la scheda video, accendono il led come i mini indicesi, aprono il cassettino del cd per tornare ai primi anni 2000.A questo punto i kernel modules sono già inclusi nel kernel? Fanno parte di un unico pacchettone gigante o in realtà è qualcosa tipo "installo un module nel kernel"? Allora stanno nello stesso repo, quasi sempre, a meno che non siano di terze parti.Quando si compila il kernel alcuni driver, alcuni moduli possono essere compilati, non compilati o compilati come modulo.Ci hanno questo tristate, questo stato triplo on off oppure m modulo.Si chiamano dopo y n e m nella configurazione y significa buttalo sempre dentro ma di solito si fa su driver tipo che possono servire sempre tipo non so a volte tipo sata o altre cose quasi sempre utilizzate n roba che non vuoi m lo compil come modulo viene creato un file a parte estensione punto k o e quando a runtime, diciamo quando il computer butta, se si accorge che serve quel ko che esiste viene presso, caricato, linkato in memoria e questo è questo questo diciamo l'attore di questo lazy loading è comunque il kernel stesso che se ne fa carico, è attiva, fa esibire...tramite dei tool user space che lo aiutano tipo Udev o altre cose comunque sì Ok, ok, chiaro.In realtà c'è una cosa che ha senso a questo punto introdurre, che è il concetto di kernel monolitico, visto che stiamo parlando di kernel.Quando si dice che il mio kernel, il kernel di Linux è un kernel monolitico, a cosa si riferisce? in realtà quando tu compili un kernel l'output è un binario chiamato vmlinux praticamente è una serie di moduli kernel che sono tutte le funzionalità che tu hai scelto di avere modulari quando un modulo viene caricato però viene linkato al kernel, cioè nel kernel c'è un linker che è molto simile al linker che viene utilizzato al compilatore quando impacchetta tutti oggetti nel binario quindi anche se sul disco sono dei file separati quando viene caricato viene attaccato al kernel in memoria viene linkato proprio nello spazio memoria del kernel quindi alla fine hai questo binario gigante che cresce o diminuisce perché i moduli puoi anche scaricarli volendo.E questo occupa uno spazio di memoria definito abbastanza grande quanto appunto i moduli che vuoi.Quale sarebbe l'alternativa in questo caso? Perché io ho letto un po' in Gino e c'è questa cosa del kernel monolitico come svantaggio, si parla sempre di svantaggi.Quello a cui ti riferisci forse è la distinzione fra i kernel monolitici tipo Linux e i kernel chiamati micro kernel come possono essere quelli di altri sistemi operativi tipo QNX dove alcuni servizi girano come alcuni driver girano come servizi non sono linkati nello spazio membrore del kernel.Quindi non c'è un unico eseguito? Si, è come se fossero dei processi.Un sistema operativo che era avanti in questo settore si chiamava QNX.Il kernel era veramente molto piccolo e poi partivano questi programmi che gestivano i vari driver tipo l'usb, la scheda video e altro.Questa approccia ha vantaggi e svantaggi.Il vantaggio è che se un driver crash non hai un panic totale, muore quel processo può essere riavviato.Lo svantaggio è che questi processi per comunicare col kernel usano delle funzioni di comunicazione che comunque rallentano.I moduli del kernel per comunicare col kernel non hanno bisogno di comunicare, lo spazio di memoria è è lo stesso, ti basta definire una variabile externa che punta a quello che vuoi tu, la leggi e trovi i dati, puoi accedere ovunque.Invece con un programma esterno ci sono dei servizi di inter-process communication che passano dati, serializzano, deserializzano.la gestione della concorrenza sullo stesso arcella diventa un overhead di complessità mica da ridere.Per cui comunque la strada del kernel monolitico così come lo conosciamo pensi sia una cosa che è più efficiente.Poi ci sono degli svantaggi come ho detto prima se un driver anche non fondamentale per il sistema, il driver del mouse, dovesse crashare e crasha male come diciamo, può avere un panic e rebutta il sistema.Oppure io potrei caricare un modulo del kernel malevolo scritto da me e ha accesso totale alla macchina.Chiaro, perché girando insieme a tutto il resto, vede la memoria di tutto il resto e quindi sei insomma fottuto.L'interazione col kernel viene fatta in fase di compilazione ma anche in fase di, potrei dire, una cazzata.Ti prego fustigami perché ero una capra in sistemi operativi magari.Ma tu mi hai detto è possibile attivare dei moduli anche con dei tool delle funzioni specifiche, ma questi moduli li attivi sempre a livello kernel o è da layer superiore che tu puoi dire ok montami lato kernel il driver di dispositivo y periferica z? Allora lo fa sempre il kernel ma ci sono degli strumenti user space che fanno in modo che questa cosa sia trasparente.Praticamente quando serve un driver del kernel, driver non sono solo quelli di periferica, sono anche i protocolli.Faccio un esempio, ci sono dei protocolli di rete tipo IPv6 o sctp o vari protocolli di rete, appena un'applicazione per la prima volta fa un...apre un socket stcp che è copiato come modulo, il kenner se l'accorge, vede che non ce l'ha il modulo caricato e chiama dei programmi user space tipicamente Udev che lo cercano, se lo trovano caricano il modulo e il programma che ha aperto il socket apre la sua connessione sctp e non si accorge che questo modulo non c'era ed è stato caricato alla bisogna.Quando hai detto lo cerca, lo cerca in quali in quali ambiti? nell'ambito del sistema nel quale sta girando o ci immaginiamo anche dei registri? No, no, c'è un percorso prefissato e se non è lì non c'è.Ok, perfetto.Altrimenti mi apriva 70.000 domande sulla sicurezza.Non lo cerco là, in giama.Esatto, mi apriva 70.000 domande sulla sicurezza.Per cui se tu dovessi vedere l'evoluzione del il concetto di kernel da qui a 15 anni cosa pensi che cambierà? Niente! Perché è una roba molto solida cioè io mi chiedo una cosa questo tipo di tecnologie sono là 50 anni 60 anni forse di più non lo so.Sono 91 Linux almeno poi altri kernel esistono da prima quindi sono quasi 50.23 e 9 32...scusa 91, ah sì, 91-32 anni.Sono tanti nell'informatica però.Anche perché quando è nato Linux esisteva già BSD da parecchi anni, non so quanti, ma parecchi anni ed era simile.In realtà non ci sono stati grandi stravolgimenti alla fine su questo tipo di tecnologie e quella la mia domanda è secondo te sono stabili perché hanno raggiunto un tetto di performance/fattibilità/qualità/solidità oppure sono stabili perché in realtà ci si è tanto focalizzati sugli upper layers che alla fine nessuno c'è più un cazzo di voglia di mettere le mani sul kern allora forse ci sono alcune cose che si potevano fare meglio però il problema è sempre la compatibilità, cioè non possiamo andare a riscrivere ogni singolo pezzo di software user space che utilizziamo ad oggi praticamente come funziona adesso c'è il kernel che espone le sue API, le più tipiche sono le syscall sono delle chiamate di sistema base tipo read, write, open, close per aprire e chiudere file, soffit eccetera Immagina a cambiare questo paradigma, tutti i programmi che hanno open, close, read Sai che questa cosa è una roba simile a una risposta che mi è stata data su Kubernetes perché io ho fatto più o meno la stessa domanda non su Kubernetes cioè Kubernetes è diventato il paradigma centrale facendo fuori anche secondo me un po' più di quanto avrebbe dovuto.Momento bold opinion, io vedo che tu ridi sotto i baffi.Non so di che fazione tu sia.Neutro, non l'ho mai usato sinceramente quindi veramente sono neutro.Però ormai sai che è lo standard de facto di molte cose.sì ma no.Quindi è diventato lo standard de facto sorpassando tutta una serie di competitor e un po' immagino è quello che si è successo al kernel di Linus Torvald e arriva un momento in cui neanche si cerca più l'alternativa perché come dicevi tu è costosa o perché in realtà si dice se vabbè ci concentriamo sugli upper layer e quindi ci concentriamo tutti a fare sistemi di astrazione kubernetes in modo che tu non metti le mani in kubernetes perché è un bagno di sangue allora c'è l'azienda pinco pallo che si inventa la roba per farti usare kubernetes senza dirtelo si fondamentalmente lo si usa perché è già lì funziona è pronto e sopra ci fa le due cose quasi ogni oggetto che noi compriamo oggi ha un linux dentro, cioè noi compriamo una smart tv deddo c'è linux, la gopro, l'autoradio della macchina, le stampanti, ho visto linux girare anche dentro delle cose veramente minuscole, dentro le schede ethernet, ci sono schede ethernet che sono dei mini computer con dentro linux che vengono vedute come acceleratori di rete perché fanno delle funzioni in hardware e invece l'hardware è un linux che accelera le cose come dire "there is no hardware offloading, it's just another CPU" inverso quel famoso sticker "there is no cloud" Sì, sì, qua ho appena messo un marker perché diventerà veramente un pezzo topico dell'episodio.E hai ragione, hai assolutamente ragione.Tra l'altro pensavo che poi, detto tra mette, il fatto che sia di Linux e che fosse open ha fatto in modo che davvero fosse arrivasse dappertutto.È proprio questa apertura che io se penso al mio cognato che un paio di aziende fa lavorava per un'azienda francese che si occupa di TV box e là il suo compito era scrivere driver per il kernel per quelle robe, per alcune schede, alcune cose che non so trova troppo lontana dal mio mondo però ecco in quel caso tutta l'idea di andarsi a scrivere delle robe proprietarie cade perché ce l'hai già fatto ce l'hai pronto e là funziona.Forse non è come dicevi tu non è scritto nel modo più moderno possibile, nel modo più bello possibile, ma funziona bene e performante.Chi se ne è fotte e la creatività, l'inventiva si è spostato su un altro settore.Però questa cosa ancora mi stride, noi viviamo nell'epoca di riscrivere tutto e la cosa fantastica è che stiamo mettendo in discussione tutti i livelli, però le foundational nessuno si ferma il culo sulla sedia e prova a ragionarla.No, riscriviamo tutto, io prendo in giro tutti, riscriviamo tutto in rasta, però in realtà il foundational non è il riscrivo ma è il ripenso, perché si parla prima di architettura e software, che è di scrivere ecco, là forse ci si ferma un attimo di più e si desiste.In realtà riscrivere il kernel è probabilmente impossibile, però negli anni sono stati riscritti interi subsystem del kernel nella loro interezza.Per esempio un giorno arrivava un tizio e riscrive il memory management, che è comunque una roba abbastanza grossa, si un italiano tra l'altro.Anche foundational immagin.Si, riscrivono Memorandum Management, linus estasiato, lomergia.Qualche altra volta uno riscrive lo scheduler dei processi, un altro lavoro detto da niente diciamo, e anche quello dentro.Quindi a poco a poco alcune cose sono state riscritte, lo stack di rete, è stato riscritto recentemente il firewall, si è passato da un firewall che si chiama IP tables a uno nuovo chiamato NF tables che è basato su una specie di macchina virtuale tipo bytecode internamente.Anche quello è stato un grosso e ha unificato i vari layer 2, 3, 2, 3 e 4.Prima c'erano tre firewall diversi per IP e per il bridge tipo e per altre cose.Questo invece è un farvolone unico che unifica tutto e gira questa specie di macchina di bytecode interno.Quindi a volte capita che se noi guardiamo il kernel di dieci anni fa o di quindici anni fa c'è poco in comune perché riscrivi un pezzo, riscrivi un pezzo, riscrivi un altro pezzo e alla fine molta roba viene riscritta.Ok quindi è comunque sempre non è una roba statica.A questo punto ti chiedo, a livello di maintaining del kernel, come funziona? Allora, è molto diverso da come dagli altri.Io so come funzionano i progetti open source oggi su Github anche perché contribuisco in alcuni.C'è il maintain, principalmente adesso un contributor forca il repo, clona, modifica le sue cose, manda una pull request.Il maintain le altre persone la guardano, se gli piace viene emergiato.Il kernel è molto diverso ma non per scelta perché ha iniziato a svilupparsi molto prima dell'avvento di Github.In realtà se vogliamo essere precisi il kernel ha iniziato a essere sviluppato molto prima dell'esistenza di git, infatti git è stato scritto da linus torvalds perché voleva un tool open source per la gestione dei sorgenti, però il metodo in cui i maintainer mantengono il tree è rimasto lo stesso fondamentalmente c'è un file di testo perché a loro piacciono le cose semplici, se Seguente da Instrugente del Kernel c'è un file di testo, si chiama "maintainers", dove c'è una serie di path, di percorsi, e sotto ogni path c'è il nome di una persona.Praticamente hai questo signore che mantiene driver USB, c'è quest'altro signore che mantiene net SCAD, hai altre persone che mantengono memory management o file system NTFS per dire.ogni maintainer mantiene le sue cose, ogni maintainer ha una sua mailing list, diciamo ogni subsystem ha una sua mailing list, quando uno fa una modifica diciamo al driver scasi scrive alla mailing list linux scasi, discussioni seguono fin quando il maintainer dice ok la patch adesso mi piace io la prendo e la applica dentro.Quindi in realtà tu con git crei la patch, la condividi nella mailing list, ti espone al pubblico l'udibrio, scherzando, poi ti chiederanno.Non è più così adesso sono molto più educati, lo dico se qualcuno volesse cominciano a contribuire che sono molto più...una volta si ti offendevano più che altro si arrabbiavano adesso no.La patch si...ti dirò di più non è che tu con git crei la patch e la invii tu invii la patch da git.Sì perché c'è la funzione per inviare le mie...Git bend email Io quello lo trovai, tra l'altro c'è anche il concetto di "pure request" su git, ma che vuol dire un'altra cosa? "Request" è un'altra cosa.Esatto, che vuol dire un'altra cosa? Sì.Vai vai scusami.Praticamente diciamo che io faccio le mie quattro modifiche, faccio le mie quattro patch e faccio git, send email e le mando all'admin list linux usb, perché ho modificato della usb.Varie discussioni fin quando le patch vanno il maintainer le prende e le applica nel suo tree perché il maintainer ha un fork del kernel chiamato tipo scasi next per dire o net next per dire il futuro della tree net.L'apple request in questo caso è ogni ogni due mesi ogni prima ogni versione i maintainer scrivono a linus e dicono "please pull my tree" e linus fa il pull dal tree del maintainer e si prende queste 1000-2000 patch, queste 800, si sono grosse, fa il pull di questo grosso request, le guarda perché lui le guarda tutte, le guarda e le merge nel suo tree che è Linux Next che poi diventa...no no, il suo è Linux, si, le push è entro Linux, giusto? Mi chiedo una cosa, allora sul fatto...anzi rimaniamo ancora sul tooling, poi ci spostiamo magari sul concetto un po' più politico.Succede che tu direttamente da git fai la patch e la invi alla mailing list e questo ci sono le funzioni ricordo appunto di averle viste quando cercavo un modo per fare per replicare il concetto di pull request senza dover passare per git e github o gitlab o simili e là mi si aprì un mondo del plumbing di git e delle ceramiche di git perché le vengono definite proprio così a livello di git.A questo punto però il maintainer deve essere in grado di prendere la patch e applicarla al suo branch.La prima cosa che mi viene in mente è i conflitti come fai a tracciare che tu la patch la stai facendo partire dalla stessa starter? No, quindi vuol dire che i conflitti il maintainer se li risolve.I conflitti capitano di solito il maintainer se sono piccoli sbriga lui, se sono grandi ti dice "please, refresh" e tu mandi una cosiddetta v2 v3 perché c'è tutta una sintassi nel mandare le patch, l'oggetto deve essere fatto in un certo modo.Ma quanto c'è di automatizzato in questo processo? Perché in realtà la sintassi sta al galateo perché comunque può essere che sia un ambiente un po' rigido quando c'è davvero tutto questo fermento e anche questa responsabilità, un po' di processo definito ci deve essere altrimenti diventa il liberi tutti.Oppure la sinta...il processo è anche diciamo quello che costruisce magari dei workflow interni del maintainer che lo feccia magari automaticamente gli aggiorna il mirror su github e lui dal tablet si guarda la tua mergè e questo perché in realtà una patch inviata sulla newsletter io l'unica cosa che posso pensare è che lui proprio la scarica e la applica e deve essere davanti al computer ma io non ci credo che nel 2023 un maintainer non faccia review in spiaggia col tablet.Tutte queste sintazzi una volta erano diciamo un codice non etico, erano delle linee guide tipo mandi una patch e quando la rimandi scrivi v2 v3 oppure scrivere nell'oggetto e la mail rfc per dire non applicate, è solo un test.Oppure, un altro esempio, nel messaggio di commit alla fine si usa mettere dei cosiddetti tag, tipo io scrivo una patch che fixa un bug introdotto in un messaggio in un certo commit, scrivo fix su due punti e metto l'inso dell'hash, oppure io fixo un bug che mi è stato segnalato da una persona e io faccio "reported by" due punti l'altra persona, "suggested by" "reviewed by" "tested by" tutti questi tag che all'inizio erano utilizzati così, dopo sono diventati standard e ci sono dei tool che li utilizzano e li scannano per esempio un tag molto importante e il fixest tag, se voi andate a vedere il git log del kernel ci sono un sacco di commit che hanno fixest due punti, questo serve principalmente alle distribuzioni che mantengono il loro kernel downstream, vanno a vedere se nei loro commit applicati localmente ce n'è qualcuno che dovesse avere un fixest tag upstream, vuol dire questo commit introduce un bug che è stato fissato dopo e quindi conviene backportare quel fix lì.Ritornando all'automatismo dei maintainer, una volta il maintainer scaricava la posta con Matt, non so se conoscete lo strumento, è un mail client da terminale quindi Shell diciamo, e c'erano dei tasti per scaricare la mail nel senso l'email con i header tutta l'email completa e poi git am nome del file, git può importare delle patch da un'email tranquillamente.Ovviamente si fa ancora quando si manda tipo una patch singola io ti mando una patch, due patch, ma quando ti mando una serie di 15 16 patch sono dei strumenti che automatizzano questa cosa, ce ne sono diversi uno tipo si chiama B4, ti passi il link della main list, scarica la serie di patch, le applica e le trovi dentro.Hanno automatizzato un po' di cose, non stanno a applicarsi le righe a mano dall'email.Non ti sento però.Qua ho dimostrato il mio essere boomer proprio nell'anima, parlare col microfono a spento, ci abbiamo anche nella sigla d'altro modo.Ho però notato che tantissimi progetti open source, anche importanti, anche di una certa carattura, sono migrati a GitHub.Invece Linus rimane ancora là, ancora con queste modalità che, viste da fuori, in realtà da quello che mi stai raccontando, sono super efficienti e anche molto automatizzate oggi, quindi forse è più un pregiudizio addettato.Siamo noi guidati un po' dalla moda di andare a fare pull request, però a questo punto mi chiedo cosa gli porta a rimanere là nonostante ci siano magari degli strumenti veramente già pronti, comodi e semplici per fare dei processi per i quali magari loro devono lanciare quattro software mettere in pipe roba.Allora github inteso come interfaccia web nel senso proprio sito github.com github come come anche come community.Non come repository git perché tecnicamente si potrebbe utilizzare il repositori git.github.com come storage, ma l'interfaccia no, perché non penso si possa sviluppare su GitHub, perché c'è proprio dei limiti tecnici.Banalmente l'altra volta stavo sfogliando, perché dovete sapere che noi quando sfogliamo i sorgenti al kernel andiamo su git.kernel.org dove c'è il git web del kernel.Stavo sfogliando una cartella e mi è apparso un warning giallo di github dicendo non ti faccio vedere solo i primi mille file perché oltre non vado oppure dei messaggi di aprendo dei committe potrebbe fare sempre un warning giallo dicendo questa diff è troppo grande te la lascio non le modifiche a questo file sono troppe non te le faccio vedere diciamo che tecnicamente l'interfaccia di github non è pronta non e poi i maintainer penso vogliono rimanere sul loro git kernel org postato su loro server e continuano ad usare il loro mail e il loro tool.In realtà io questo lo capisco e da un certo punto di vista lo apprezzo tantissimo, sapete quanto sia il mio piglio indipendentista dal punto di vista di questo modo.Poi detto da te che praticamente sei stato parte di tutte queste big corp che in realtà offrivano questi servizi, per me avere il Kernel sviluppato in modo completamente indipendente con dei flow indipendenti mi dà una sensazione di tranquillità in termini proprio di indipendenza e di sostenibilità del progetto verso il futuro, specie perché è un progetto molto importante.Infatti una domanda che ho chiesto ad altri maintainer che si appoggiano tantissimo a Tool come Ita/GitLab, della situazione "sì vabbè ma voi state mettendo la vostra conoscenza e i vostri pillar della tecnologia in mano a una corporation che è giusto che faccia il suo porco interesse perché nasce per farlo cioè sarebbe sbagliato se non lo facesse ecco e quindi loro mi dicevano sì ma se vogliamo essere utili funzionali se vogliamo rilasciare questo è il modo per ottimizzare i nostri processi di lavoro altrimenti se dovessimo ottenerci un flow come quello di linux probabilmente faremo quello dal giorno alla notte.Peccato che chi fa linux lo fa! Quindi è la dimostrazione che è possibile farla.È vero anche che si basa su, abbiamo detto, più di 30 anni di storia quindi probabilmente non è tutta roba scritta in una settimana quella che gestisce il flow.Però io ho visto delle pull request nel repository di github del kernel, ho visto bene tipo alle allucinazioni della febbre.La prima risposta qual era? Non ci ho buttato un occhio ti dico la verità però ho visto le pull request.C'è un bot che ti dice che grazie per la pull request ma noi le facciamo in un altro modo, ti linka una pagina su wiki e la chiude.Ah, fantastico non l'avevo visto sinceramente, però è interessante.Secondo te avrebbe senso un una roba che come tu fai la pull request su github, una automazione che come fai tu la pull request su github lui fa manda la mail, faccia il patch e mandi la mail in automatico backporting del processo in realtà si si potrebbe utilizzare ma a questo punto perché non te lo automatizzi tu ti fai ti scrivi un tool tu dal tuo clone, dal tuo fork del kernel in locale avvii questo tool che prende la tua patch e la manda alla fine se ritorniamo lì ce l'hai già subito perché devi stare a sbatterti molte cose sono automatizzate perché come dicevo prima c'è questa serie di regole di bon ton del kernel, tipo quando tu mandi tocchi un driver devi mandare alla mail alla main list devi mettere in coppia il maintainer di quel driver perché se no pare brutto che tocchi le cose senza averle senza interpellarlo se quel bug è stato introdotto da una persona devi mettere in coppia con la persona perché prima di devi chiedere il suo parere perché se l'ha rotto lui magari può saperne più di te queste cose sono tutte qualunque molte cose sono automatizzate ci sono dei script che fanno di tutto.C'è uno script per esempio che si chiama "get maintainers" tu gli passi un hash, un commit o un file e lui ti dice a chi mandare la mail.Sembra quell'ufficio tipo del CAF dove vai per sapere a quale altro ufficio del comune devi andare per fare una pratica.Però in realtà hai detto una cosa interessante, io il luogo comune degli sviluppatori a basso livello suggerisce anarchia ok? Però da questo processo da come lo stai raccontando mi farebbe da dire "smells of" non puzza ma odora di democristianità tantissimo nel senso c'è tutto tutto questo Galateo dove al centro ci sono i maintainer specifici cioè gli uomini che aprono il cancello che poi viene aperto dal grande master che è Linus che poi emerge.Ecco io ricordo un po' di storie, lo step back di Linus Torvald, il ritorno, quanto in realtà questi uomini che sono sono dei gatekeeper, influiscono sulla stabilità e penalizzano dall'altro canto magari la velocità e l'evoluzione del kernel stesso, perché alla fine sono dei piccoli decisionisti? Sì, decidono loro.Capita che dei lavori non vengono presi, delle features, delle API che il maintainer è contro non vengono implementate.Di solito molti subsystem non hanno un maintainer solo, quindi c'è questa discussione fra maintainer che alla fine decidono.Però se tutti i maintainer sono contro le tue modifiche non vanno, quindi si decidono loro.E questa cosa non ha mai penalizzato da quello che tu sappia? Può darsi, diciamo che noi ci affidiamo alla competenza del maintainer sperando che di solito lo è che la scelta del maintainer sia la migliore, però visto che comunque tutti sbagliano, con cui mantenersi sono persone e sarà sicuramente capitato che qualche modifica degna di nota che meritava di entrare dentro per una non antipatia per una scarsa errata visione del mantenere non venga presa ma questo succede su tutti i progetti open source alla fine? chiaro chiaro chiaro mi viene in mente una cosa a questo punto vorrei parlare per un attimo ragionare per un secondo di ricambio di maintainer tu hai avuto modo di vedere sai stiamo parlando di una roba che tipo foundational di il mondo nel senso se questa cosa cade, cade il mondo o qualcosa di simile.Cioè mi immagino un'era steampunk.Se tu mi dici "Oggi togli il kernel, togli Linux" siamo in un'era steampunk.Non ci sono alternative.E a questo punto mi chiedo in realtà la distanza tra noi e lo steampunk sono questi gatekeeper che sono gatekeeper ma anche dittatori benevoli che comunque fanno mandare avanti la carretta che altrimenti difficilmente andrebbe avanti e che posseggono una knowledge che poche altre persone hanno.A questo punto mi viene da parlare di ricambio.Quando si parlava parlavo con Paolo, il mio amico riguardo a mantenere node.Ci sono degli core developer in node che spaventati da questa cosa ci hanno tirato dentro il figlio ma proprio hanno formato il figlio di 17enne a scrivere codice c++ perché in realtà i contributor node stavano scarseggiando e lui dice che mia responsabilità ci abbiamo iniettato il mondo di node cazzo adesso dobbiamo anche cacciarci la mosca e prenderci questa responsabilità ecco E' di lì quindi grande fame di ricambio già anche generazionale.Come vedi tu all'interno del mondo del kernel il ricambio generazionale in termini di maintainer ma anche di contributor? Sta avvenendo e se sì quali sono le fonti che generano ricambio? L'università o l'home hacking? Ho visto passare diversi alcuni maintainer, il caso tipico è un maintainer che magari non ha più tempo, comincia a rispondere sempre meno alla mailing list, non è molto presente, viene proposto di la co-maintainership ad un'altra persona, anche perché spesso non è un solo maintainer, sono più persone.Per ogni pat, perché là si ragiona pretendo a pat, possesse 2, 3, anche 5 persone.Ovviamente x86 non lo mantiene una persona sola.Poverino Lewis.Alcuni mantenne che cominciano a lentamente defilarsi, arrivano nuovi.Ci sono stati anche casi di liti, mantenere che dicono "basta, non sono d'accordo, non mi piace, la penso diversamente, chiudo".O persone che per motivi personali non possono più fare il mantenere o non possono più farlo tempo pieno, è capitato pure.Vengono scelte delle altre persone, di solito sono quelli più attivi sulla main list, quelli che comunque hanno più competenze, quelli che ne sanno di più, gli viene proposta la maintainership.Alcune cose vengono mantenute direttamente dalle aziende, principalmente hardware, banalmente i maintainer delle schede wifi Qualcomm, lavorano per Qualcomm perché chi altri avrebbe interesse a sviluppare, a mantenere i driver wifi? Principalmente.Poi c'è pure chi lo fa per hobby.Perché non gli va? Non perché gli va, no proprio perché non gli va se vieni ragazzi in 2000 e devi scrivergli perché non ti andava, vedasi il tuo router.Ci sono, però nell'hardware è molto comune che i manteners sono aziende, poi sono quelli che hanno più interesse perché un'azienda che produce, non lo so, un controller sata ha ovviamente interesse che questo controller funzioni perché poi questo controllo è più utilizzato nell'auto radio di una macchina, su qualche server o su qualunque dispositivo.Sì sì, poi se si avviano cicli di produzione col tuo controller tu ci fai il sordo.Devo dire che in realtà è un po' cambiata quando si pensava ai driver negli anni negli anni 90, primi anni 2000, in realtà era un po' diverso da oggi, le aziende si stanno facendo carico sempre di più, dello sviluppo dei driver vari.Se io oggi dovessi o volessi iniziare a sviluppare per il kernel, e vengo da il mondo javascript front end, con le robe per ragazzotti, come dico io, che poi è il mio mondo, che è agli antipodi, un sistema molto diverso, un ambiente molto diverso con una dev-ex molto diversa.Cosa suggeriresti? Allora, posto che uno sappia programmare in C, perché lo mettiamo come prerequisito, diciamo, perché la codebase è quella, io consiglio di andare a vedere sul log, sultri, i vari commit, quelli più piccoli, facendo pure un div stat, vedendo quei commit di 5 righe, di 3 righe, di 4 righe, e io vi vorrei fare capire che, se voi andate a vedere questi comment più piccoli si capiscono abbastanza facilmente perché non è che per essere un per fare un comment su kernel non bisogna essere torvalds o alan cox ci sono delle parti di codice che sono delle modifiche che sono non dico banali ma alla portata di molti uno off by one in un ciclo, una free che viene messa fuori da un if e non dentro e quindi non viene liberata la memoria, un valore sbagliato, un sacco di modifiche che andando a vedere il se andate a vedere il tree prima o poi troverete sicuramente qualche commit e pensate ma questo lo sapevo fare pure io.Sì, ovviamente pochi sapranno riscrivere il memory management, però la maggior parte dei commit sono roba fattibile da un programmatore c-average, medio.Chiedo quali sono le prospettive poi lavorative di uno che magari investe n tempo su questa cosa e lo chiedo a te che in realtà durante il tuo giorno lavorativo fai tutt'altro, in meta? Sì, lavoro sempre su sistemi Linux ma non sul kernel direttamente adesso, però ho lavorato sul kernel in Red Hat e in Microsoft, anche nell'azienda prima.In realtà non l'avevo iniziato come hobby, non era proprio il mio scopo andare a lavorare a fare il kernel developer, diciamo che quello è stato uno step naturale che è venuto dopo.Però sì, c'è lavoro, ci sono degli sbocchi lavorativi sul kernel perché escludendo le aziende hardware che sono quelle che hanno più bisogno, perché immaginiamo Intel o Nvidia che hanno un sacco di developer che lavorano sui loro driver di rete, di storage o nel caso di NVIDIA sulle schede, sugli acceleratori, o sui driver wifi che sono anche molto richiesti perché ricordiamo che Android e Unker nel Linux e tutti i smartphone che utilizziamo hanno dentro delle schede wifi Qualcomm, Broadcom, altre marche e queste aziende hanno bisogno di un sacco di maintainer che gli mantengono il driver wifi perché altrimenti la Samsung o la Huawei di tutto non compre il tuo chipset nella schiena.Quindi escludendo questi ci sono anche lavori più particolari su attrezzature di rete, ci sono aziende che vendono dei switch con dei protocolli custom o fanno magari inspection del traffico, vengono venduti come firewall, come sì, come firewall professionali, diciamo corporate, quei famosi firewall che vengono venduti che fanno l'inspection del traffico, che rilevano le minacce, che fanno la mitigazione dei DOS.Sono dei server con Linux e dei moduli o delle modifiche allo stack di rete fondamentalmente.Spostiamoci per un attimo nel momento FAN, perché in realtà tu sei anche conosciuto alla community per i tuoi troll e i tuoi scherzi del primo aprile.Sono pesci d'aprile.Sì, ne ho visto un paio che sono fantastici, mi piace ricordare poi magari mettiamo anche i link nelle note dell'episodio quando ha inserito i numeri romani su printf in libc.Sì, mi aiuto molto a scrivere il messaggio di comment.No, Non l'ho letto, ho visto un po' il codice ma non ho letto il messaggio.Ho parlato un po' di Fibonacci e su come i numeri sono arrivati dall'India, passando dagli arabi in Europa.Ho fatto tutta una discussione per rendere ancora più grottesca la cosa.Dimme una cosa, com'è stata la reazione? Ci hanno creduto.Mi hanno risposto "questo flag non è standard, devi prima aprire una richiesta al POSIX standardization group per farlo mettere in POSIX" e mi hanno dato il link dove proporre il nuovo standard.Non stanno andando in un'inomadisima maniera! Altri, persone anche autorevoli, persone che scrivono compilatori, che poi sono i frequentatori abituali della mail list, gli IPC, "questo flag non è stanco, potresti proporlo come estensione?" ci hanno creduto in molti.Fin quando poi un professor della UCLA, abbastanza famoso, mi ha fatto i complimenti per lo scherzo, ha detto che è stato uno dei scherzi che gli è piaciuto di più.Però mi ha corretto in latino, perché ho scritto "Nihil" invece di nulla e lui da professore della UCLA che parla fluentemente latino gli ha corretto la patch.Figato però perché scopri questi personaggi con cui ci interagisci e sono persone con cui difficilmente riusciresti a interagire tutti i giorni al bar a Milano.C'era un altro dove hai convertito il maintainer file di Quemu in json, altro scherzo gigantesco in realtà è molto figa questa cosa dei pesci da aprire lo sai è veramente figa come ti è venuto in mente? ne ho fatti diversi.Guardavo quello dei numeri romani, non è uno scherzo un pesciapile effortless, cioè tutti si sedono sulla sedia.Si è fatto la Merger e Quest, il clone, ti si è fatto proprio il commit che sono 200 righe di roba.In realtà non me l'aspettavo perché io ovviamente non avevo mai visto il codice della printf pensavo che ci fosse uno switch dove analizzava i vari percento f di i e faceva se c'è una i fai quello se c'è una f fai quello invece poi ho scoperto lì che il codice della printf è scritto in un modo veramente complicatissimo però efficientissimo c'è questa dove ogni lettera viene mappata a un puntatore a funzione.C'è questa macchina che se c'è una D di Double punta la funzione D.E' una roba veramente complicata, però è fatta in modo da essere molto efficiente.Già che c'era, ho detto "ormai visto che l'idea l'avevo avuta e la volevo fare, devo ovviamente capire come funziona questa state machine e infilare la mia patch lì dentro".per questo che è venuta così.No perché insomma non era effortless ed è una cosa che mi è...Si è venuta più grande di quanto mi aspettassi.Esatto.Anche quella del candle panic con i suoni non so se hai visto quell'altro scherzo.Ah no quello no però so che tu ti diverti a fare musichette appunto coi suoni...Si avevo fatto quest'altro pesce d'aprile sempre al candle, questo a candle sempre, avevo implementato i suoni del computer durante il candle panic, praticamente utilizzando il buzzer del sistema, il buzzer che hanno i computer fissi, e ho implementato tre differenti musiche in base a un panic, un warning o una ops, un'orare lieve diciamo.Il "Panic" mi suonava la marcia imperiale, il "Warning" mi suonava la musichetta di Super Mario Bros quando moriva, l'"Ops" faceva tipo il funerale di Mozart, una roba del genere.Poi quando ho mandato la patch, il maintainer di x86 perché ho guardato questo scherzo e ho detto "bellissima però io la voglio con le musiche di Ennio Morricone".E lì nacque lo Spotify sul kernel.Fantastico, veramente è un mondo questo.Volevo chiederti una cosa riguardo allo sviluppo nel kernel.Un po' di anni fa il buon vecchio Torvald disse quando gli si chiese "possiamo portare c++ nello sviluppo del kernel per fare almeno certe cose?" con il suo tono inglese molto garbato linus disse "no c++ è un linguaggio orribile" poi un paio d'anni fa adesso non ricordo quando precisamente però un paio d'anni fa linus Torvald diede il benvenuto a Rust per la scrittura dei moduli del kernel.Ecco la prima domanda che voglio farti è secondo te perché Torvalds ha detto no a c++ e sia a Rust? Per una questione di complessità di linguaggio, di rumore nel linguaggio o di differenza nel linguaggio così non stiamo là a dire quale è meglio e quale è peggio o anche per una questione di differenza di tempi è cambiato qualcosa da quando Thorvald disse no a C++ e si arrastra perché è passato del tempo e anche un po' allora la motivazione di escludere C++ è prettamente politica e non tecnica perché io so per certo perché li ho anche toccati, ci sono driver e closed source che noi utilizziamo quotidianamente, scritti in C++ sul kernel perché poi quando vengono compilati l'output è binario quindi il problema che C++ tende a nascondere è prono agli errori perché c'è del codice che viene nascosto nei costruttori, negli operatori.Nel caso di si cerca di avere sempre il controllo su dove viene allocata la memoria, dove non viene allocata, su molte cose.Il fatto di poter avere bug o code path che non sono visibili occhio nudo a una prima visura del codice è un problema per i maintainer che rende difficile la vita ai maintainer.Mentre Rust...io non conosco Rust, lo sto ancora studiando, però sulla parte di gestione della memoria è abbastanza strict, senso che almeno utilizzando bene i cosiddetti lifetime si sa dove la memoria viene allocata rilasciata si ha un certo controllo qualcuno potrebbe argomentare che questo controllo non c'è più quando si utilizzano le unsafe però purtroppo non c'è scampo.Si tra l'altro si cerca di minimizzare comunque al massimo la superficie unsafe di Rust.In un driver penso sia molto difficile, nel senso che va utilizzato.E secondo te, cioè almeno non secondo te, dalla tua prospettiva quanto vedi stai...stia...stia...non mi sono dimenticato di parlare...di parlare...vedi? cosa? ok parlare troppo in italiano in un periodo dove lo parli poco è un casino no volevo chiederti dal tuo osservatorio quanto in realtà di codice kernel sta avvenendo scritto in Rust oggi è ancora molto preliminare molto molto diciamo per lì la situazione o siamo qualcosa di stato? perché non sto seguendo molto attivamente la cosa ho visto solo un driver kernel scritto in Rust ma è bello grosso e il driver di una scheda video scheda video.I driver delle schede video non sono mai piccolini diciamo e questo è un bel ballopone e funziona.Lo uso e funziona.In realtà stavo provando a immaginare cosa fa un driver di una scheda video.Si può fare.Frankenstein Junior.Si.Fantastico.No in realtà per un anno pensavo come potesse essere scritto no? Il driver.Sai mi è venuta un'idea, un'idea di business.Hai presente National Geographic? Si.Ok.Fare un canale che è il National Geographic del codice dove al posto di portarti al chili mangiaro per vedere le cose ti porto dentro il kernel e ti faccio esplorare quel mondo con un conduttore tipo...cosa ne so...come si chiama? Il famosissimo conduttore italiano Piero Angela della situazione che dice "stiamo entrando nel mondo del kernel" Sì, tipo un safari del codice, un safari del repertory Esatto, ti porta a vedere magari Robin Badd, piuttosto che il Kernel, o prima parlavo con Bianca Lana, con Dr.Blaster e con Carmini di Erlang e di centrali telefoniche che devono fare l'auto reload del codice senza spegnere, senza perdere i dati in memoria.Sono cose che per me sono aliene, sono molto fuori dalla portata di 99% degli sviluppatori io conosca e quindi mi chiedo ma questi sviluppatori esistono davvero e tu sei un esempio? No perché ti spiego come la prospettiva che sto vedendo osservata in termini numerici io vedo fiumane di sviluppatori web e via discorrendo e vedo sempre meno sviluppatori molto verticali che fanno una cosa con la sua complessità e quella cosa spesso è super rilevante.Cioè tipo cosa fai Fosdem dell'anno scorso? "Ah beh io mi occupo di alcune parti di Postgres".Ah va bene ok tu lo sai amico mio che c'hai tipo metà del mondo sulla schiena e ne vedo sempre sempre meno persone che lavorano a queste cose piuttosto che lavorare sul web framework nuovo scintillante che però poi alla fine non serve a un cazzo e quindi mi chiedo sono io che sto nella bolla sbagliata o c'è proprio questa discrepanza in termini numerici e se c'è questa discrepanza è data proprio dal mercato o c'è l'elemento interesse verso le cose mainstream che tira? Allora in proporzione si, i sviluppatori di roba più core tipo Postgres o Kernel o anche tipo l'eBGPEG per dire sono di meno ma non perché sono diminuiti gli sviluppatori di cose core, io a me sembra che gli sviluppatori di cose core siano sempre gli stessi numericamente, mentre quelli degli altri aumentano quindi in proporzione come se diminuissero.Però i sviluppatori del kernel non sono diminuiti negli anni, sono anche aumentati e così anche quelli dei progetti più core.Ok perché io ho sempre pensato che bisognerebbe iniziare una battaglia per spostare l'enorme forza forza lavoro in termini buonari che si sta andando a creare attorno al web verso un po' di livelli sottostanti perché giustamente il web si appoggia su quei livelli e se quei livelli non sono ben solidificati anche non solo a livello proprio tecnico ma anche a livello di disorse umane che ci stanno sotto noi stiamo costruendo un burcalifa su una palafita e questa cosa crolla.Come la vignetta di XKCD.Esatto, del NodeModules.E secondo me è la cosa importante.Tu un po' mi rassicuri, mi dici "no, guarda, dalla mia prospettiva i numeri sono aumentati, probabilmente non tantissimo, però non almeno rispetto a quello che mi interessa, che il web ha catalizzato".Però, non lo so, più il tempo passa, più ho questo interesse verso te ne dico una, anche il solo sviluppo applicazioni desktop dove la rete è un elemento.Non so se mi sono un po' rotto le palle del web però fondamentalmente non lo so questo interesse verso scendere un po' più in basso di livello e ragionare un po' più in termini di sistemi e meno di web e di micro front end che tra l'altro è una cosa che mi ha appassionato fino ad un anno e mezzo fa ed ero preso benissimo non so se è proprio con la non più giovane età che vuoi...no è presente quando da vecchietto inizi da persona adulta inizia a rileggere la bibbia o tipo ti riprendi Dante la divina commedia è un po può essere quello però non lo so c'è c'è questo interesse che tira e secondo me la tuto l'hype che sta attorno al Rust e che continua a resistere attorno al Rust può essere un trigger per fare lo shift di un po' di risorse verso i livelli sottostanti.Se il sviluppatore Rust diventerà, probabilmente già lo sono, più di quelli C e cominciano a interessarsi, sì potrebbe attrarre risorse.Se io fossi un ragazzo, al di là del fatto che il C magari lo studia all'università, perché c'è il professore preso bene, tipo fanboy di Cunningham e Ritchie, come era il mio professore, che era capace di tutto per quei due uomini, allora sì.Però non so quanti in realtà oggi si metterebbero a studiare programmazione in C avendo un overload di informazioni che ti dicono "studia JavaScript che devi usare Next.js" quindi boh oh oh oh c'è il Matteo che dice "oh io avevo 200 euro mi sono comprato il router e vaffanculo mi studio e mi riscrivo il perché da ragazzi degli anni 90 più o meno queste erano le nostre situazioni.20 euro lo comprai usato.No, no, perché me lo ricordo benissimo che per far funzionare le cose quando ci spendevi soldi eri pronto a spendere mesi di studio perché avevi più tempo che soldi e quindi giustamente era quello che facevi.Stiamo posto, vaneggiando nel momento vecchie, un marelle, quindi forse guardavo l'orologio siamo a un'ora e 21.Matteo io direi che possiamo spostarci nel momento Paese dei Balocchi, momento in cui il nostro guest e i nostri host condividono con noi un libro, un film, un topic, un qualcosa che abbia in qualche modo attirato l'attenzione e abbia senso condividere con la nostra community.Quindi ti chiedo, cosa ti piacerebbe condividere con il nostro? Dal punto di vista tecnico c'è un libro che tra l'altro è anche stato rilasciato su licenza free, quindi è disponibile online liberamente.È stato scritto da un italiano, si chiama Linux Device Drivers ed non è molto aggiornato dal punto di vista del codice, in senso che molti esempi potrebbero non compilare, però i concetti ci sono tutti.Parte dall'inizio, ti fa scrivere prima un driver a caratteri dove mandi e ricevi delle lettere, dei byte, e poi passa alle porte, ai file, a tutta una serie di sviluppi sempre più consistenti fino a scrivere un piccolo driver di una periferica.Il libro mi pare che si può scaricare dal famoso LWN.net, Linux Weekly News, che è uno dei siti di riferimento nell'ambito Linux per la documentazione.È una specie di giornale del kernel dove vengono pubblicate notizie, news, aggiornamenti.Sono sicuro che in una sezione del sito c'è il pdf di questo scaricabile.Ovviamente l'autore accetta donazioni quindi se volete.Mettiamo il link nel libro e del supporto perché sono comunque dei contributi importanti che dobbiamo sostenere, abbiamo proprio la responsabilità etica di sostenere.Io oggi ne ho parlato e vi porto in realtà un un pezzettino della mail che Linus Torvalds scrisse riguardo a C++ e inizia con "you are full of bullshit".C++ is an horrible language, is made more horrible by the fact that a lot of substandard programmers use it" insomma per generare un sacco di crap quindi francamente anche la scelta insomma di tenere c++ fuori dal codice è un modo per tenere i programmatori c++ fuori dai codici Scritto con i classici modi di Linus Torvald anni 2000 perché un po' diciamo...Era l'antitempi, ma secondo me lui non si arrabbiava, lui lo scriveva ridendo perché lui ha questo modo di parlare così però cioè io non me lo immagino lì paonazzo e arrabbiato che scrive questa No, è perculante secondo me.Esatto, io me lo immagino perculante.Comunque è bellissima, ecco certo probabilmente non scrivere così in un contesto dove se dovessi mantenere la psychological safety, però insomma è un pezzo di storia.È cambiato anche lui.Sì, sì, è cambiato anche lui.Ultimamente l'ho visto arrabbiato, sì si è arrabbiato anche tanto.Dici perché, ti prego.Un paio di mesi fa si è arrabbiato con qualcuno, però la cosa di Linus ogni volta che c'è stata una discussione lui era molto arrabbiato, lui sclera, però se vai a vedere tecnicamente ha ragione.Cioè quando si arrabbia è perché c'è veramente qualcosa di veramente storto e allora diciamo che la discussione merita.E comunque è un bel pezzo di goliardia quella mail, quindi Matteo io con te avrei voluto parlare di ebpf.E' un hot topic degli ultimi anni.Sai che facciamo? ci facciamo con il nostro amico Carminozzo e il nostro buon amico Dr.Blaster, ci facciamo un altro episodio quindi ne approfitto così.Solo su BPF.Anche perché da come dice Alessio voi non leggetelo io me lo leggo così poi io ci facci sordi.Perché come ha detto nella precedente puntata che tra l'altro abbiamo registrato un paio d'ore fa e quindi non l'avete ancora sentita, ma l'avrete sentita quando questo episodio sarà pubblicato.Lui dice che secondo lui è una delle cose che sarà un po' in hype tra un po' quindi è il caso di studiarselo per benino.Come ben sapete github è gratis ma non senza costi questo vuol dire che ogni settimana e ogni mese noi paghiamo tutta una serie di abbonamenti nonostante il fatto che mettiamo a disposizione il nostro tempo in via del tutto gratuita c'è però chi si fa carico di appunto di questi costi prendendoci sulle spalle e supportandoci con una donazione.Questa settimana dobbiamo ringraziare Giuseppe Madiona, spero di averlo pronunciato bene, io coi nomi sono una schiappa totale, che ci invita a due birre con un messaggio che dice "fate un lavoro eccezionale di grande qualità con grande impegno".Grazie mille da Giuseppe, grazie mille a a te Giuseppe per aver supportato Gitbar e aver fatto in modo che una parte delle delle spese dei costi potessero essere in qualche modo condivisa con appunto noi.Detto questo io direi che possiamo continuare con l'episodio ringraziando Giuseppe.Grazie! Vi ricordo che se volete aprire o gestire partite online eliminando gli ostacoli della burocrazia potete prenotare una consulenza fiscale gratuita e senza impegno con un esperto fisco zen al link in descrizione avrete anche 50 euro di sconto sul primo anno di abbonamento Matteo io ti ringrazio tantissimo per esserci venuto a trovare come dico sempre il git bar è un po tipo il circolo del dopo lavoro postale è presente quando negli anni 90 entravi magari con la papà o con la mamma con lo zio nel dopo lavoro postale per prendere un pacchetto di cingome mentre lo zio si beveva la moretti fresca.Ecco, ti veniva fatta la tessera perché se no poi arrivava la guardia di finanza e da circolo arci diventava tipo un circolo chiuso.Anche tu oggi hai ufficialmente la tessera di speaker di Gitbar perché ormai sei anche uno dei membri più attivi nella community, ma non ti mancava proprio la testera da speaker.Questo vuol dire che quando becchi qualche informazione, qualche topic super interessante, per favore contattaci.Dici "oh raga ma avete visto sta cosa? Viva di parlarne!" Per te c'è sempre una moretti fresca, anche se virtuale, nel nostro GeekBar.Io ti ringrazio tantissimo per esserci venuto a trovare rinnovando il tuo invito.Grazie davvero.Di che, grazie a te.Ciao.Ciao ciao.Noi ci diamo appuntamento alla settimana prossima come al nostro solito prima però di chiudere un veloce ringraziamento a Fisco Zen che ha fatto in modo che potessimo fare questo episodio.Un ringraziamento anche a tutti gli amici che ci sostengono cliccando sul pulsante supportaci o con i mezzi del podcasting 2.0 i nostri contatti sono info@github.it @brainrepo su twitter gruppo telegram e anche canale youtube per cui se non l'avete ancora fatto cliccate su iscriviti e cliccate anche sul campanaccio questo farà in modo di ricevere le notifiche e vedere il nostro bel faccione anche su youtube detto questo io vi da appuntamento alla prossima puntata e vado a letto perché ormai sono fuso.Alla prossima! Ciao ciao!
