Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Linus Torvalds ha duramente criticato il primo lotto di patch RISC-V proposte per l’inclusione in Linux 6.17, affermando che le modifiche sono arrivate troppo tardi e contenevano quella che lui ha definito “spazzatura” non correlata a RISC-V e che interessava gli header comuni del kernel.
Era particolarmente infastidito dalla nuova macro helper make_u32_from_two_u16(), che secondo Torvalds rendeva il codice meno chiaro e peggiorava le cose. Notò che la semplice scrittura del form (a mostrava immediatamente cosa stava succedendo, mentre l’uso dell'”helper” oscurava l’ordine delle parole e introduceva ambiguità.
No, questa è spazzatura ed è arrivata troppo tardi.
Ho chiesto un ritiro anticipato.
richieste perché sono in viaggio, e se non riesci a seguire questa regola, almeno rendi le richieste di pull *buone*.
Ciò aggiunge vari elementi indesiderati che non sono specifici di RISC-V ai file di intestazione generici.
E con "spazzatura" intendo davvero. Questa è roba che nessuno dovrebbe inviami, figuriamoci in ritardo in una finestra di unione.
Come questo folle e inutile "helper" make_u32_from_two_u16().
Quella cosa rende il mondo un posto peggiore in cui vivere. È spazzatura inutile che rende incomprensibile qualsiasi utente, e attivamente *PEGGIO* che non usare quello stupido "aiutante".
Torvalds ha sottolineato che tali modifiche non dovrebbero comparire nelle intestazioni generali, né tantomeno essere apportate alla fine della finestra di merge. Ha avvertito che non accetterà più richieste di pull tardive né consentirà la creazione di “spazzatura” al di fuori dell’albero dell’architettura RISC-V.
Secondo lui, gli autori potranno riprovare queste modifiche solo nella versione 6.18 e solo all’inizio della finestra di unione, senza modifiche controverse e inutili.
La vicenda dimostra che, anche in un ecosistema aperto e collaborativo come quello di Linux, l’inclusività non significa accettare qualsiasi contributo senza filtro. L’open source nasce per essere accessibile, ma richiede disciplina, coerenza e qualità tecnica. Come ha dimostrato Torvalds, le regole di integrazione e revisione servono a preservare la stabilità e la chiarezza del codice, evitando l’introduzione di modifiche inutili o dannose.
Ma l’open source non doveva essere inclusivo? Sì, ma inclusivo non vuol dire indulgente con la “spazzatura”: vuol dire garantire che ogni contributo sia valido, utile e ben integrato nell’interesse di tutta la comunità.
