Discussion :

[Bill Fassinou]

Linus Torvalds : « GitHub crée des fusions inutiles et vous ne devriez jamais utiliser ses interfaces pour fusionner quoi que ce soit »
le pilote NTFS de Paragon est ajouté au noyau Linux 5.15

Cela fait un bon moment déjà que Linus Torvalds attend que Paragon Software soumette son pilote NTFS pour qu'il soit ajouté au noyau Linux. C'est désormais chose faite, et Torvalds a finalement fusionné le nouveau pilote avec les sources du noyau Linux 5.15. Mais avant ça, il s'est plaint de l'utilisation de la fonction de demande de fusion de GitHub dans la soumission, en disant que GitHub "crée des fusions absolument inutiles". Apparemment, le créateur du noyau Linux n'aime pas beaucoup les fusions GitHub, voire pas du tout. Aussi, les avertissements du compilateur sont désormais traités comme des erreurs par défaut dans les constructions du noyau.

Au début du mois d'août, Torvalds a donné un coup de pouce à Paragon Software pour que l'entreprise soumette une "pull request" - une soumission réelle du code à fusionner dans les sources du noyau - afin que son pilote NTFS en lecture-écriture puisse être inclus dans la prochaine version 5.15, pour laquelle la fenêtre de fusion est actuellement ouverte. Pour rappel, NTFS est le système de fichiers natif de Windows et l'implémentation de Paragon améliorera l'interopérabilité, par rapport au pilote existant qui a un support d'écriture limité. Vendredi, Paragon a dûment soumis sa "pull request", en disant :

« La version actuelle fonctionne avec des fichiers normaux/compressés/spars et prend en charge l'acl, la relecture du journal NTFS ». Cela dit, l'entreprise est toujours en train de se familiariser avec le processus de soumission et Torvalds avait pas mal de commentaires à faire, destinés à améliorer les futures demandes d'extraction. Tout d'abord, le créateur du noyau Linux a déclaré que la demande d'extraction aurait dû être signée. « Dans un monde parfait, ce serait une signature PGP que je peux tracer directement jusqu'à vous à travers la chaîne de confiance, mais je n'ai jamais vraiment exigé cela », a-t-il dit.

Ensuite, il a noté que le code dans la demande d'extraction comprenait des commits de fusion effectués avec l'interface utilisateur Web de GitHub. « C'est une autre de ces choses que je ne veux *vraiment* pas voir - GitHub crée des fusions inutiles, et vous ne devriez jamais utiliser les interfaces GitHub pour fusionner quoi que ce soit », a-t-il déclaré. Il a ajouté : « [G]ithub est un site d'hébergement parfaitement bien, et il fait un certain nombre d'autres choses bien aussi, mais les fusions ne sont pas l'une de ces choses ». Par le passé, notamment en 2012, Torvalds s'était déjà plaint de certains aspects de GitHub.

« Je ne fais pas de demandes d'extraction GitHub. GitHub jette toutes les informations pertinentes, comme avoir même une adresse e-mail valide pour la personne qui fait la demande d'extraction. Le diffstat est également déficient et inutile », avait-il alors déclaré. Notez que la commande git request-pull est différente de la fonction pull request de GitHub. En outre, le dépôt de Paragon a des messages de commit qui manquent d'informations, comme "Merge branch 'torvalds:master' into master". À ce propos, Torvalds a déclaré samedi que "les fusions du noyau Linux doivent être faites *correctement*".

Il a ajouté : « Cela signifie des messages de commit appropriés avec des informations sur ce qui est fusionné et *pourquoi* vous fusionnez quelque chose. Mais cela signifie aussi des informations correctes sur l'auteur et le committer, etc. Tout cela, GitHub l'a complètement raté ». Malgré ces commentaires, Torvalds a néanmoins fusionné la soumission de Paragon. Il faut noter que ce pilote a déjà raté plusieurs fenêtres de fusion. « Le pull initial a souvent quelques bizarreries et je vais les accepter maintenant, mais pour la poursuite du développement, vous devez faire les choses correctement », a déclaré Torvalds.

En marge de l'ajout du pilote NTFS de Paragon au noyau Linux 5.15, Torvalds a aussi activé l'option de compilation "-Werror" par défaut pour toutes les constructions du noyau. L'indicateur de compilation "-Werror" traite tous les avertissements comme des erreurs de construction. En promouvant tous les avertissements en tant qu'erreurs, Torvalds oblige les développeurs à s'assurer que les avertissements de construction qui pourraient autrement passer inaperçus, ou seulement vaguement concernés par les développeurs, soient désormais traités en priorité étant donné qu'ils interrompent le processus de construction.

Torvalds a commenté ce changement : « Nous devrions vraiment toujours avoir une construction propre, et nous désactiverons les avertissements spécifiques trop enthousiastes si nécessaire, si nous ne pouvons pas les corriger. Mais alors que j'applique assez religieusement cela dans mon propre arbre, cela n'est pas appliqué par les différents robots de construction qui ne signalent pas nécessairement les avertissements. Donc cela fait simplement de '-Werror' un drapeau de compilateur par défaut ». De nombreux projets logiciels utilisent déjà "-Werror" par défaut pour assurer un meilleur contrôle de la qualité.

Ils veillent à ce que les avertissements soient traités, mais la plupart de ces projets ne sont pas de la taille du noyau Linux. Par ailleurs, ce patch ajoute aussi WERROR comme commutateur Kconfig. Cela permet de désactiver l'indicateur "-Werror" si de nouvelles versions du compilateur introduisent de nouveaux avertissements qui ne peuvent pas être immédiatement corrigés par le noyau ou d'autres problèmes sélectifs pour lesquels il n'est pas possible de créer un noyau sans avertissements. L'option WERROR est activée par défaut pour toutes les constructions du noyau.

Linus a terminé le message du correctif par : « J'espère que cela signifiera que je recevrai moins de demandes d'extraction contenant de nouveaux avertissements qui n'ont pas été remarqués par les divers automatismes que nous avons mis en place. Touchons du bois ».

Source : Linus Torvalds (1, 2)

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de l'avis de Torvalds sur l'interface utilisateur Web de GitHub ?
Êtes-vous du même avis que lui ? Utilisiez-vous GitHub pour les fusions ? Si oui, partagez votre expérience.

Voir aussi

Torvalds veut un nouveau pilote NTFS dans le noyau et a choisi le pilote NTFS de Paragon Software

Paragon Software libère son pilote NTFS pour Linux avec une bien meilleure performance que le pilote actuel, mais l'entreprise a du mal à intégrer les codes du développement collaboratif

Un nouveau contrôleur de mémoire pour le noyau Linux promet des économies de mémoire significatives, notamment au niveau de la RAM, pour toutes les plateformes Linux

[Fleur en plastique]

Création du format NTFS : juillet 1993, suivant Wikipédia.
Intégration du pilote NTFS dans Lunix : septembre 2021.

Retard de Lunix : 28 ans. Pas mal la performance.

[chrtophe]

N'importe quoi, comme d'habitude.

Le support NTFS dans le noyau date des années 2000. Le support est complet en lecture, était considéré expérimental en écriture surtout pour un manque de support complet des ACL, de la compression, et probablement du cryptage il me semble.

le paquet NTFS-3G donne un meilleur support que le pilote du noyau.

Les infos évoqués ici concernant NTFS est l'intégration au noyau du pilote de la société Paragon, en remplacement du pilote actuel. paragon vendait le produit auparavant. Ils le vendent toujours pour Mac OS X. avant ça tu pouvais accéder sans problème à une partition NTFS depuis Linux.

Il est à noter que NTFS est un FS propriétaire Microsoft, et qu'il faut leur payer une licence pour avoir accès aux specs complètes, ce qu'a dû d’ailleurs faire Paragon. Les pilotes libres ont été développés par rétro-ingénierie.

[esperanto]

Création du format NTFS : juillet 1993, suivant Wikipédia.
Intégration du pilote NTFS dans Lunix : septembre 2021.

Retard de Lunix : 28 ans. Pas mal la performance.

Si on suit ton raisonnement:
Création du format ext2 : janvier 1993, suivant Wikipédia.
Intégration du pilote ext2 dans Windows : ???
Retard de Windows : ∞. Pas mal la performance.

A part ça, totalement hors sujet car la question de l'article porte sur l'utilisation de GitHub et non sur NTFS qui était ici seulement un exemple.

[Kannagi]

Surtout que le NTFS est probablement pas le meilleurs système de fichier, j'espere qu'il a eu des MAJ ?

Je trouve ça hallucinant d'utiliser le même système de fichier pendant plus de 20 ans
Sur Linux on a eu le ext2,ext3 ,ext4 et maintenant le Btrfs ,sans parler du choix du système de fichier d'autre que ceux là.

[chrtophe]

j'espere qu'il a eu des MAJ ?

Oui.

Je trouve ça hallucinant d'utiliser le même système de fichier pendant plus de 20 ans

D'un autre coté, c'est qu'il tient la route.
Et à comparer à ext2,ext3,ext4, à la base ce sont des évolutions de l'un par rapport à l'autre, un peu comme les différentes version d'NTFS. Ext2 date de 1993.

Mais le NTFS comme extX sont des systèmes qui sont voués à disparaitre, n'étant pas des plus adaptés aux SSD par rapport à ReFS pour Windows ou BRTFS pour Linux (pour ne citer qu'eux). Mais ils ne vont pas disparaitre comme ça, ils vont encore perdurer un moment, même si ils seront de moins en moins mis en avant.

On dérive là par rapport au sujet initial.

[LittleWhite]

Bonjour,

Pour avoir utiliser l'interface Web afin de faire des modifications mineures (documentation/typo...) sur certains dépôts, je suis bien d'accord que le processus n'est pas du tout optimal.
Maintenant, je ne me rappelais pas que le dépôt principal du noyau Linux était sur Github (je pensais que ce n'était qu'un miroir de celui-ci : https://git.kernel.org/)). Du coup, je m'attendais encore moins à ce qu'un développeur utilise l'interface de Github pour contribuer au noyau.

[esperanto]

Maintenant, je ne me rappelais pas que le dépôt principal du noyau Linux était sur Github (je pensais que ce n'était qu'un miroir de celui-ci : https://git.kernel.org/)). Du coup, je m'attendais encore moins à ce qu'un développeur utilise l'interface de Github pour contribuer au noyau.

Je ne pense pas que le dépôt principal soit celui de GitHub. Mais certains développeurs refuseront d'utiliser autre chose que GitHub pour faire des contributions (et j'imagine que c'est uniquement pour ce cas qu'il existe un miroir du noyau dans GitHub)
De même que certains projets auxquels je participe refusent toute autre forme de participation qu'une pull request GitHub.
La position dominante encourage parfois de mauvaises pratiques.

Au passage je découvre la commande request-pull dans cet article (avec Git on apprend de nouvelles commandes tous les jours ;-) alors je vais étudier ça de près. Le gros problème justement avec la position de GitHub, c'est que pour contribuer à un projet il faut obligatoirement un miroir sur GitHub, alors que Git était conçu pour être décentralisé: pourquoi ne peut-on pas faire une pull request en donnant en référence une URL d'un serveur à soi (mais accessible par internet, évidemment)? Du coup, GitHub a transformé Git en un Subversion amélioré...

[sergio_is_back]

Création du format NTFS : juillet 1993, suivant Wikipédia.
Intégration du pilote NTFS dans Lunix : septembre 2021.

Retard de Lunix : 28 ans. Pas mal la performance.

Fleur Atomique a encore sévi !!!

A part ça je ne vois, pour ma part je précise, que très peu d'intérêt à utiliser NTFS sous Linux à part en lecture pour récupérer le contenu d'un disque, la plupart des FS Linux actuels sont plus performants que NTFS
Et j'attends toujours le support des FS Linux (ext3, btrfs, reiserfs, xfs, etc...) sous Windows...

[Ti-Slackeux]

Création du format NTFS : juillet 1993, suivant Wikipédia.
Intégration du pilote NTFS dans Lunix : septembre 2021.

Retard de Lunix : 28 ans. Pas mal la performance.

Troll velu détecté !!

Sinon pareil que mon vdd ^^"

[esperanto]

A part ça je ne vois, pour ma part je précise, que très peu d'intérêt à utiliser NTFS sous Linux à part en lecture pour récupérer le contenu d'un disque, la plupart des FS Linux actuels sont plus performants que NTFS

Personne ne dit le contraire, ça n'est jamais utile d'utiliser pour un OS le système de fichiers d'un autre.
L'intérêt est de pouvoir partager des données quand on a un dual boot. Pour le moment chez moi j'ai une partition FAT32 qui sert uniquement à cela, parce que je ne connais pas bien les limites du pilote NTFS de Linux. Mais si le nouveau pilote supporte la lecture-écriture sans aucun risque, je reconsidérerai la question lors d'une prochaine installation.

[chrtophe]

la plupart des FS Linux actuels sont plus performants que NTFS

Là je peux pas vraiment juger. En tout cas sous Windows il fait correctement le job, maintenant on a pas trop le choix non plus.

Pour le moment chez moi j'ai une partition FAT32 qui sert uniquement à cela

Le prob. de FAT32, c'est qu'il est limité. Utiliser NTFS peut avoir un intérêt pour dépasser ces limitations pour du transfert inter OS.
Sinon il y a aussi exFAT, mais j'ai ai pas eu assez à faire pour pouvoir le juger.

[tola4269]

Encore des "mon système à moi, il est mieux que ton tien, na !".

Le fait que NTFS soit mieux compris sous linux est un bon point et c'est tout.

Pour le dual boot ou la récupération ou le partage de données, cela sera plus facile pour ceux qui utilise tous ces OS en interaction.

[lbloch]

À propos de partage de systèmes de fichiers, en dual boot, Ext4 et AHCI d'un côté, NTFS, Optane et RST de l'autre : quelle compatibilité peut-on espérer ? Quand on passe de l'un à l'autre, c'est la sélection d'une option dans le firmware ? Qui a bien compris ce qui se passe là ?

Cf. Installation dual boot Linux Windows pour exposé plus complet de mon interrogation.

[foetus]

Surtout que le NTFS est probablement pas le meilleurs système de fichier, j'espere qu'il a eu des MAJ ?

Pour la petite histoire avec l'annonce de Vista, Microsoft avait annoncé WinFS (<- lien wikipedia en français)

Mais WinFS a été annulé en 2006, et "pompé" dans d'autres projets comme SQL Server et d’ADO.NET.
Peut-être que NTFS a eu sa mise à jour.

La seule mise à jour connue c'est depuis Windows 10 version 1607, le chemin de fichiers qui n'a plus 1 longueur de 260 caractères Maximum Path Length Limitation (<- lien msdn en anglais)

[stardeath]

La seule mise à jour connue depuis Windows 10, Version 1607, c'est le chemin de fichiers qui n'ont plus 1 longueur de 260 caractères Maximum Path Length Limitation (<- lien msdn en anglais)

attention, c'est pas ntfs dont tu parles là, seulement des fonctions usuelles win32 qui avaient une limite.
depuis que j'utilise ntfs (genre win xp) la limite en nombre de caractères d'un chemin c'est 32k et des brouettes, et la seule manière à l'époque de s'en servir c'était d'utiliser les unc.

[Madmac]

A part ça je ne vois, pour ma part je précise, que très peu d'intérêt à utiliser NTFS sous Linux à part en lecture pour récupérer le contenu d'un disque, la plupart des FS Linux actuels sont plus performants que NTFS

Si on utilise Wine, beaucoup d'installateur de programme ne fonctionne pas correctement. Si on désire jouer sur Linux, une partition NTFS simplifie beaucoup de choses.

[air-dex]

On parle ici de NTFS et de Linux, mais il me semble que le sujet principal est GitHub et git, le créateur de ce dernier étant d'ailleurs un certain... Linus Torvalds. On dirait surtout donc que le papa de git n'est pas satisfait de ce qu'en a fait la forge logicielle qui lui a permis d'exploser et de s'imposer.