Il nuovo Kernel Linux strizza l’occhio ad NTFS

4

Parliamo spesso dell’amore che, ultimamente, Microsoft ha nei confronti di Linux e -più in generale- dell’open-source. Ma nessuna storia d’amore è veramente tale se non opportunamente ricambiata.

E’ il caso della recente approvazione del buon Torvalds all’inclusione nella versione 5.15 del Kernel al driver NTFS3 di Paragon Software, di cui vi avevamo già parlato, che renderà molto più semplice lavorare con il suddetto filesystem proprietario anche dal nostro amato pinguino.

This is NTFS read-write driver. Current version works with normal/compressed/sparse files and supports acl, NTFS journal replaying. Most of the code was in linux-next branch since Aug 13, but there are some patches, that were in linux-next branch only for a couple of days. Hopefully it is ok – no regression was detected in tests.

Questo è il driver di lettura-scrittura NTFS. La versione attuale funziona con file normali/compressi/sparsi e supporta le ACL ed il replay journal di NTFS. La maggior parte del codice è nel branch linux-next dal 13 di Agosto, ma ci sono alcune patch che son rimaste in quel branch solo per pochi giorni. La speranza è che sia ok, nessuna regressione è stata rilevata nei test.

Pare anche che gli sviluppatori di Paragon siano sulla buona strada per fare merge request corrette, anche se non ancora perfette al 100%. Già perchè se un anno fa una loro patch fu rifiutata perchè troppo massiccia, questa volta il contenuto della merge request va bene, il problema è nella merge request stessa.

Se l’ultima volta sono stati quindi i manutentori a rifiutare una patch da 27000 riga di codice, questa volta Torvalds ha risposto alla richiesta di merge con alcuni consigli e richiedendo di eseguire nuovamente la sottomissione della stessa usando una procedura più consona, ovvero non usando l’interfaccia di GitHub.

I notice that you have a GitHub merge commit in there […] That’s another of those things that I really don’t want to see – GitHub creates absolutely useless garbage merges, and you should never ever use the GitHub interfaces to merge anything…GitHub is a perfectly fine hosting site, and it does a number of other things well too, but merges are not one of those things.

Ho notato che avete fatto un merge commit di GitHub qui […] Questa è un’altra di quelle che davvero non voglio vedere – GitHub crea dei merge spazzatura assolutamente inutili, e non dovreste mai utilizzare le interfacce di GitHub per fare merge di niente… GitHub è un buon sito di hosting, e fa anche una serie di altre cose bene, ma i merge non sono tra queste.

A quanto pare il problema più grosso è la gestione delle informazioni in fase di merge che GitHub rimpiazza per meccanismi suoi interni.

A merge must contain proper commit messages with information about is being merged and why you merge something […] But it also means proper authorship and committer information etc. All of which GitHub entirely screws up.

Un merge deve contenere messaggi di commit ben fatti con informazioni riguardanti cosa si sta mergiando e perchè lo si sta mergiando […] Ma significa anche che deve contenenere buone informazioni sull’autore e su chi ha eseguito il commit. Tutte queste vengono totalmente incasinate da GitHub.

Inoltre, anche a livello di sicurezza, il dittatore benevolo fa notare come ogni cosa al di fuori di kernel.org – dove si fida personalmente di chi gestisce gli account – vorrebbe che la pull request sia un tag firmato, non un semplice branch, sottolineando come in un mondo perfetto l’ideale sarebbe una firma PGP che possa riportare direttamente a chi fa la richiesta tramite una catena di verifiche.

Insomma, la volontà di avere un supporto più completo anche a tecnologie proprietarie dell’azienda di Redmond c’è, la scopo ultimo pare sia solo quello di rendere più chiaro a tutti anche lo storico di chi e del perchè alcune modifiche sono state introdotte nel nostro amato kernel. Cosa che considerando la natura prettamente “pubblica” del suo codice può portare beneficio sia nel processo di inclusione, che nel processo di analisi futura nel caso si rendesse necessario.

Come al solito, per il beneficio di tutti!

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.