Come avevamo anticipato in chiusura dell’articolo “Riuscirà una tempesta invernale dove tutti hanno fallito, cioè a fermare una release del Kernel Linux?” in realtà ci credevamo poco anche noi e, puntualmente, la conferma è arrivata: Linus Torvalds ha ripreso a lavorare a tutte le pull request della prossima versione del Kernel Linux, il problema è che è particolarmente… Agguerrito.
Il lavoro di merge è ripreso lo scorso diciassette gennaio, quindi praticamente lo stesso giorno in cui riportavamo la notizia e, come riporta Phoronix, il numero di merge effettuate già allora era imponente, as usual:
Ma le notizie non finiscono qui, perché il giorno successivo sempre Phoronix ha raccontato della pubblicazione della fix relativa alla horrendous performance regression che Torvalds aveva rilevato con una certa enfasi prima della tempesta. La patch, logicamente identificata come “urgente”, è stata inclusa nel Kernel e sarà presente quindi nella sua versione 6.8, pertanto tutto torna tranquillo.
Talmente tranquillo, che è tempo in realtà per una bella polemica il cui pretesto sono gli inode, che il Dittatore Benevolo ritiene letteralmente abbiano fatto il loro tempo.
Gli inode (index node) sono una struttura di dati utilizzata nei filesystem Unix e Unix-like per memorizzare informazioni su un file o una directory. Per ciascuno di essi vi è associato un inode che contiene metadati cruciali.
In un thread sulla mailing list del Kernel Linux, raccontato da The Register, Torvalds non usa giri di parole:
Yes, inode numbers used to be special, and there’s history behind it. But we should basically try very hard to walk away from that broken history.
Sì, i numeri di inode erano speciali e c’è della storia dietro ad essi, ma dovremmo cercare decisamente di allontanarci da quella storia, che è rotta.
An inode number just isn’t a unique descriptor any more. We’re not living in the 1970s, and filesystems have changed.
Un numero di inode non è più un descrittore univoco, non viviamo negli anni ’70, ed i filesystem sono cambiati.
La verità però è che la riflessione sugli inode è parte di un discorso più ampio rivolto allo sviluppatore (che proviene da Google) che poi ha proposto una patch, particolarmente indigesta al creatore di Linux il quale, per un momento, ha ricordato il “vecchio” Torvalds pre-ritiro (di ben due settimane, nel 2018):
You copied that function without understanding why it does what it does, and as a result your code IS GARBAGE. AGAIN.
Hai copiato quella funzione senza capire perché fa quel che fa, ed il risultato è che il tuo codice è SPAZZATURA. ANCORA.
Chiaramente il messaggio ha portato tutto tranne che serenità, tanto che lo Steven Rostedt, lo sviluppatore, dopo essersi sorbito lo shampoo, ha ribattuto specificando come il suo coinvolgimento nella patch fosse sostanzialmente per dare una mano e non per diventare un esperto della materia (che nello specifico era eventfs), aggiungendo un’altra chicca:
Ironically, one of the responsibilities that I’ve been putting off to fix up eventfs was writing that document on a support group for maintainer burnout. :-p
Ironicamente, una delle responsabilità che ho messo da parte per sistemare eventfs è stata quella della scrittura del documento relativo al gruppo di supporto per il burnout dei maintainer. :-p
Risposta che ovviamente sarà ben lungi dall’essere risolutiva nei confronti della questione, ma che la dice lunga su cosa ci voglia per lavorare nel Kernel Linux, ossia competenze, capacità e tanta, tanta pazienza per sopportare Linus Torvalds.
Tanto perfetto nell’essere il maintainer di uno dei software più importanti del mondo, quanto zoppicante quando si tratta di empatia.
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
Lascia un commento