Linus Torvalds c�l�bre le 20e anniversaire de Git. Est-il plus c�l�bre que Linux ?Git a 20 ans : questions et r�ponses avec Linus Torvalds
Pour c�l�brer les vingt ans de Git, Linus Torvalds s'est livr� � une foire aux questions pour discuter de la fa�on dont il a chang� � jamais le d�veloppement de logiciels. Pour rappel, Linus Torvalds est un ing�nieur logiciel finlandais, cr�ateur et d�veloppeur principal du noyau Linux. Il a �galement cr�� le syst�me de contr�le de version distribu� Git.
Il y a exactement vingt ans, le 7 avril 2005, Linus Torvalds a effectu� la toute premi�re validation du syst�me de contr�le de version Git. Torvalds a �crit Git en seulement 10 jours apr�s que les d�veloppeurs du noyau Linux aient perdu l'acc�s � leur outil propri�taire, BitKeeper, en raison de d�saccords sur les licences. En fait, lors de ce premier commit, il avait �crit suffisamment de Git pour utiliser Git pour faire le commit !
La conception non conventionnelle et d�centralis�e de Git, aujourd'hui omnipr�sente et apparemment �vidente, �tait r�volutionnaire � l'�poque et a modifi� la mani�re dont les �quipes logicielles collaborent et d�veloppent.
La vid�o suivante montre l'interview de Linus Torvalds o� il parle des premiers jours de Git, revient sur les principales d�cisions de conception � l'origine du succ�s durable de Git et discute de la fa�on dont il a chang� � jamais le d�veloppement logiciel. La suite de l'article est la transcription de la vid�o.
Taylor Blau : Cela fait 20 ans, presque � l'heure pr�s, que Git a �t� suffisamment auto-h�berg� pour �crire son premier commit. Vous attendiez-vous � �tre assis ici 20 ans plus tard, � l'utiliser encore et � en parler ?
Linus Torvalds : Toujours en train de l'utiliser, oui. Peut-�tre pas en train d'en parler. Je veux dire que cela a �t� l'une des grandes surprises, � savoir � quel point il s'est impos� dans le monde du SCM. J'y voyais une solution � mes probl�mes, et je pensais �videmment qu'il �tait sup�rieur. M�me il y a 20 ans jour pour jour, je pensais que la premi�re version, qui �tait assez brute - pour �tre honn�te, m�me cette version �tait sup�rieure � CVS.
Mais en m�me temps, j'avais vu CVS s'accrocher au march� - SVN est apparu, mais c'est juste CVS sous une autre forme, n'est-ce pas - pendant de nombreuses d�cennies. Je me suis donc dit : � D'accord, ce march� est tr�s collant. Je ne peux pas utiliser CVS parce que je le d�teste passionn�ment, alors je vais faire mon propre truc. Je ne pouvais plus utiliser BitKeeper, �videmment. Alors je me suis dit, ok, je vais faire quelque chose qui marche pour moi, et je ne me pr�occuperai pas des autres. Et cela s'est vraiment vu au cours des premiers mois et des premi�res ann�es - les gens se plaignaient que c'�tait un peu difficile � utiliser, pas assez intuitif. Puis il s'est pass� quelque chose, comme si on avait appuy� sur un bouton.
Je vais faire quelque chose qui marche pour moi, et je ne me pr�occuperai pas des autres.
Taylor Blau : Vous avez parl� de BitKeeper. Nous pourrions peut-�tre en parler.
Linus Torvalds : Bien s�r.
Taylor Blau : Vous avez �crit la version initiale de Git en une dizaine de jours pour remplacer le noyau.
Linus Torvalds : Oui et non. Il a fallu moins de dix jours pour que je puisse l'utiliser pour le noyau, oui. Mais pour �tre juste, tout le processus a commenc� en d�cembre ou novembre de l'ann�e pr�c�dente, donc en 2004.
Ce qui s'est pass�, c'est que BitKeeper avait toujours assez bien fonctionn� pour moi. Il n'�tait pas parfait, mais il �tait � des ann�es-lumi�re de tout ce que j'avais essay�. Mais BitKeeper dans la communaut� du noyau a toujours �t� tr�s mal accueilli par la communaut� parce qu'il �tait commercial. Il �tait gratuit pour une utilisation open source parce que Larry McVoy, que je connaissais, aimait vraiment l'open source. Je veux dire qu'en m�me temps, il en faisait un business et il voulait vendre BitKeeper � de grandes entreprises. Le fait que BitKeeper ne soit pas open source et qu'il soit utilis� pour l'un des plus grands projets open source �tait un point de friction pour beaucoup de gens. Et c'�tait aussi le cas pour moi.
Dans une certaine mesure, je voulais vraiment utiliser l'open source, mais en m�me temps, je suis tr�s pragmatique et il n'y avait rien d'open source qui �tait, m�me de loin, assez bon. J'esp�rais donc que quelque chose de mieux se pr�senterait. Mais ce qui est arriv�, c'est que Tridge, en Australie, a fait de la r�tro-ing�nierie sur BitKeeper, ce qui n'�tait pas si difficile, car BitKeeper �tait en fait une bonne enveloppe autour de SCCS, qui remonte aux ann�es 60. SCCS est presque pire que CVS.
Mais c'�tait explicitement contre les r�gles de la licence de BitKeeper. BitKeeper disait : vous pouvez l'utiliser pour l'open source, mais vous ne pouvez pas faire d'ing�nierie inverse. Et vous ne pouvez pas essayer de cloner BitKeeper. Et cela a pos� d'�normes probl�mes. Et tout cela se passait en priv�, donc je parlais � Larry et j'envoyais des courriels � Tridge et nous essayions de trouver une solution, mais Tridge et Larry �taient vraiment aux antipodes l'un de l'autre et il n'y avait aucune solution qui se dessinait.
Lorsque j'ai commenc� � �crire Git, cela faisait quatre mois que je r�fl�chissais � ce probl�me, � ce qui fonctionnait pour moi et � la question suivante : � Comment puis-je faire quelque chose qui soit encore mieux que BitKeeper, mais qui ne le fasse pas comme BitKeeper ? Je ne voulais pas me retrouver dans la situation o� Larry me dirait : � H�, tu as fait la seule chose que tu n'�tais pas cens� faire. �
...comment faire quelque chose qui fait encore mieux que BitKeeper, mais qui ne le fait pas de la m�me mani�re que BitKeeper.
Taylor Blau : Je voudrais parler de ces deux choses. Nous pouvons commencer par cette p�riode de 10 jours. Si j'ai bien compris, vous avez pris cette p�riode pour vous �loigner du noyau et vous vous �tes surtout concentr� sur Git de mani�re isol�e. Comment s'est d�roul�e la transition entre le travail sur Git et le noyau ?
Linus Torvalds : Eh bien, comme il ne s'agissait que de deux semaines, c'est ce qui s'est pass�. En fait, ce n'�tait pas tr�s important. J'avais d�j� fait ce genre de choses pour - au cours des 35 derni�res ann�es, j'ai �t� en vacances deux ou trois fois, c'est vrai, pas tr�s souvent. Mais je me suis d�j� �loign� du noyau pendant deux semaines d'affil�e.
Et c'�tait assez int�ressant parce que l'une de mes r�actions a �t� de voir � quel point il est plus facile de programmer dans l'espace utilisateur. Il y a tellement moins de choses dont il faut se pr�occuper. Vous n'avez pas � vous soucier des allocations de m�moire. Vous n'avez pas � vous soucier de beaucoup de choses. Et le d�bogage est tellement plus facile quand vous avez toute cette infrastructure que vous �crivez quand vous faites un noyau.
En fait, c'�tait un peu - je ne dirais pas relaxant, mais c'�tait amusant de faire quelque chose dans l'espace utilisateur o� j'avais un objectif assez clair de ce que je voulais. Je veux dire, un objectif clair dans le sens o� je connaissais la direction. Je ne connaissais pas les d�tails.
Taylor Blau : L'une des choses que je trouve int�ressantes � propos de Git, surtout 20 ans plus tard, c'est que le mod�le de d�veloppement qu'il encourage me semble si simple qu'il est presque �vident � ce stade. Mais je ne dis pas cela comme un terme r�ducteur. Je pense qu'il y a eu beaucoup de r�flexion pour distiller l'univers des id�es de contr�le de source jusqu'� ce qui est devenu Git. Dites-moi, quels ont �t� les choix non �vidents que vous avez faits � l'�poque ?
Linus Torvalds : Le fait que vous disiez que c'est �vident maintenant, je pense que ce n'�tait pas �vident � l'�poque. Je pense que l'une des raisons pour lesquelles les gens ont trouv� Git tr�s difficile � utiliser est que la plupart des personnes qui ont commenc� sans utiliser Git venaient d'un contexte de type CVS. Et l'�tat d'esprit de Git, je l'ai abord� d'un point de vue de personne de syst�me de fichiers, o� j'avais ce d�dain et presque de la haine pour la plupart des projets de gestion de contr�le de source, donc je n'�tais pas du tout int�ress� par le maintien du statu quo.
Et le plus gros probl�me pour moi - eh bien, il y en avait deux �normes. L'un �tait la performance : � l'�poque, j'appliquais encore beaucoup de correctifs, ce que Git a presque fait dispara�tre, car je ne fais plus que fusionner le code d'autres personnes.
Mais pour moi, l'un des objectifs �tait de pouvoir appliquer une s�rie de correctifs en une demi-minute, m�me s'il s'agissait de 50 ou 100 correctifs.
Taylor Blau : Vous ne devriez pas avoir besoin d'un caf� pour...
Linus Torvalds : Exactement. Et c'�tait important pour moi parce que c'est en fait une question de qualit� de vie. C'est l'une de ces choses o� si les choses sont instantan�es, si une erreur se produit, vous voyez imm�diatement le r�sultat et vous continuez et vous le corrigez. Certains des autres projets que j'avais examin�s prenaient environ une demi-minute par correctif, ce qui n'�tait pas acceptable pour moi. Et ce parce que le noyau est un projet tr�s vaste et que beaucoup de ces SCM n'ont pas �t� con�us pour �tre �volutifs.
Et c'�tait important pour moi parce que c'est en fait une question de qualit� de vie.
En effet, nous avions d�j� rencontr� ce probl�me avec BitKeeper, qui utilisait des CRC et des MD5, mais qui ne les utilisait pas pour tout. L'une des premi�res id�es que j'ai eues, c'est qu'absolument tout �tait prot�g� par un tr�s bon hachage.
C'est ce qui a guid� l'ensemble du projet, avec deux ou trois id�es de conception fondamentales. C'est pourquoi, � un bas niveau, il est en fait assez simple, mais la complexit� r�side dans les d�tails, les interfaces utilisateur et toutes les choses qu'il doit �tre capable de faire - parce que tout le monde veut qu'il fasse des choses folles. Mais le fait d'avoir une conception de bas niveau avec quelques concepts de base a facilit� l'�criture, la r�flexion et, dans une certaine mesure, l'explication des id�es aux gens.
Je compare cela � Unix. Unix a comme philosophie de base que tout est un processus, tout est un fichier, on fait passer des choses entre les choses. En r�alit�, ce n'est pas si simple. Il y a les concepts simples qui sous-tendent la philosophie, mais tous les d�tails sont tr�s compliqu�s.
Je pense que c'est ce qui m'a fait appr�cier Unix en premier lieu. Et je pense que Git a un peu le m�me genre de caract�ristiques, il y a une simplicit� fondamentale dans la conception et puis il y a la complexit� de l'impl�mentation.
Taylor Blau : Il y a un lien entre Unix et la fa�on dont Git a �t� con�u.
Linus Torvalds : Oui.
Taylor Blau : Vous avez parl� de SHA-1. L'une des choses auxquelles je pense au cours de la semaine ou des deux semaines o� vous avez d�velopp� la premi�re version de Git, c'est que vous avez pris beaucoup de d�cisions qui sont rest�es dans les m�moires.
Linus Torvalds : Oui, c'est vrai.
Taylor Blau : Y en a-t-il eu, y compris SHA-1 ou non, que vous avez regrett�es ou que vous auriez voulu faire diff�remment ?
Linus Torvalds : Eh bien, je veux dire que je regrette SHA-1 dans le sens o� je pense qu'il a caus� beaucoup d'agitation inutile avec l'id�e d'essayer de supporter SHA-256 aussi bien que SHA-1. Je comprends pourquoi c'est arriv�, mais je pense que c'�tait surtout inutile.
Je ne pense pas qu'il y ait eu un besoin �norme et r�el, mais les gens �taient inquiets, alors c'�tait court. Je pense donc qu'il y a eu beaucoup d'efforts gaspill�s. Il y a un certain nombre d'autres petits probl�mes. Je pense que j'ai fait une erreur dans la fa�on dont les entr�es du fichier d'index sont tri�es. Je pense qu'il y a ces d�tails stupides qui ont rendu les choses plus difficiles qu'elles ne devraient l'�tre.
Mais en m�me temps, beaucoup de ces choses pourraient �tre corrig�es, mais elles sont suffisamment petites. Cela n'a pas vraiment d'importance. Toutes les complexit�s sont ailleurs en fin de compte.
Taylor Blau : Il semble donc que vous ayez peu de regrets. Je pense que c'est une bonne chose. Y a-t-il eu des moments o� vous n'�tiez pas s�r que ce que vous essayiez de r�aliser allait fonctionner, s'assembler ou �tre utilisable ? Ou aviez-vous d�j� une id�e assez claire ?
Linus Torvalds : J'avais une id�e claire des �tapes initiales, mais je n'�tais pas s�r de la fa�on dont cela fonctionnerait � long terme. Honn�tement, apr�s la premi�re semaine, j'avais quelque chose de bien pour appliquer les correctifs, mais pas vraiment pour le reste. J'avais les bases pour faire des fusions, et les structures de donn�es �taient en place pour cela, mais cela a pris, je crois, une semaine de plus avant que je ne fasse ma premi�re fusion.
Il y a un certain nombre de choses pour lesquelles j'avais une vue d'ensemble et un r�sultat en t�te, mais je n'�tais pas s�r d'y arriver. Oui, les premiers pas, je veux dire la premi�re ou les deux premi�res semaines, vous pouvez aller voir le code - et les gens l'ont fait - et ce n'est pas un code compliqu�.
Taylor Blau : Non.
Linus Torvalds : Je crois que la premi�re version faisait 10 000 lignes ou quelque chose comme �a.
Taylor Blau : Vous pouvez plus ou moins le lire en une seule s�ance.
Linus Torvalds : Oui, et il est assez simple et ne fait pas beaucoup de v�rifications d'erreurs et d'autres choses de ce genre. Il s'agit vraiment d'un � Faisons-le fonctionner parce que j'ai un autre projet que je consid�re comme plus important que celui auquel je dois me consacrer �. C'�tait vraiment le cas. Il m'arrivait de rencontrer des probl�mes qui m'obligeaient � faire des changements.
� Il y a eu un certain nombre de choses pour lesquelles j'avais une vue d'ensemble et un r�sultat en t�te, mais je n'�tais pas s�r d'y arriver. �
Linus Torvalds : La premi�re version - je pense que nous avons fini par faire un transfert de magasin d'objets incompatible � un moment donn�. Au moins, fsck se plaint de certains des anciens objets que nous avions parce que j'ai chang� le format des donn�es.
Taylor Blau : Je ne savais pas d'o� cela venait.
Linus Torvalds : Oui, non. La premi�re version ne faisait pas tout ce qu'elle devait faire.
Et j'ai oubli� si j'avais fait une conversion ou non. Il se peut que je n'aie jamais eu besoin de convertir. Et nous avons juste quelques avertissements pour quelques objets dans le noyau o� fsck dira, � H�, c'est un ancien format qui n'est plus support� �. Ce genre de choses. Mais d'un autre c�t�, dans l'ensemble, cela a vraiment fonctionn�, je veux dire, �tonnamment bien.
Le gros probl�me a toujours �t� l'acceptation par les gens.
Taylor Blau : C'est vrai.
Linus Torvalds : Et cela a pris beaucoup de temps.
� Mais d'un autre c�t�, dans l'ensemble, �a a vraiment march�, je veux dire, �tonnamment bien. �
Taylor Blau : Nous avons un peu parl� du fait que la fusion a �t� mise en place mais qu'elle n'a pas �t� fonctionnelle avant la deuxi�me ou la troisi�me semaine. Quelles sont les autres fonctionnalit�s que vous avez laiss�es de c�t� dans la version initiale et dont vous vous �tes rendu compte plus tard qu'elles �taient en fait essentielles au projet ?
Linus Torvalds : Eh bien, ce n'est pas tant � r�alis� plus tard �, c'�tait des choses dont je ne me souciais pas, mais je savais que si cela devait aller quelque part, quelqu'un d'autre le ferait. La premi�re semaine o� je l'ai utilis� pour le noyau, j'utilisais litt�ralement les commandes brutes, ce qu'on appelle aujourd'hui les � commandes de plomberie �, � la main.
Taylor Blau : C'est �vident.
Linus Torvalds : Parce qu'il n'y avait pas de porcelaine. Il n'y avait rien au-dessus pour le rendre utilisable. Donc, pour faire un commit, vous faisiez ces choses tr�s obscures.
Taylor Blau : D�finir l'index, faire un commit-tree.
Linus Torvalds : Oui, commit-tree, �crit, et cela renvoie juste un SHA que vous �crivez � la main dans le fichier head et c'est tout.
Taylor Blau : Est-ce que hash-object existait dans la premi�re version ?
Linus Torvalds : Je pense que c'�tait l'un des premiers binaires que j'avais o� je pouvais simplement v�rifier que je pouvais tout hacher � la main et il renvoyait le hachage en standard, puis vous pouviez faire ce que vous vouliez avec. Mais c'�tait comme si le d�but de la porcelaine �tait moi en train de faire des scripts shell autour de ces choses tr�s difficiles � utiliser.
Et honn�tement, ce n'�tait pas facile � utiliser m�me avec mes scripts shell.
Mais pour �tre juste, le premier public cible de ce projet �tait compos� de personnes qui utilisaient BitKeeper. Ils connaissaient au moins une bonne partie des concepts que j'avais en t�te. Les gens l'ont adopt�.
Il n'a pas fallu longtemps pour que d'autres d�veloppeurs du noyau commencent � l'utiliser. J'ai �t� surpris par la rapidit� avec laquelle des personnes charg�es du contr�le des sources ont commenc� � intervenir. Et j'ai commenc� � recevoir des correctifs de l'ext�rieur quelques jours apr�s avoir fait la premi�re version publique de Git.
Taylor Blau : Je voudrais aller un peu plus loin. Vous avez pris la d�cision de confier la maintenance � Junio assez t�t dans le projet. Pourriez-vous me parler un peu de ce que c'est que de le voir g�rer le projet et de voir la communaut� interagir avec lui avec un peu de distance apr�s toutes ces ann�es ?
Linus Torvalds : Pour �tre honn�te, j'ai g�r� Git pendant trois ou quatre mois. Je crois que je l'ai c�d� en ao�t [2005] ou quelque chose comme �a.
Et quand je l'ai abandonn�, je l'ai vraiment abandonn�. Je me suis dit : � Je suis toujours l�. � Je lisais encore la liste de diffusion Git, ce que je ne fais plus. Junio voulait s'assurer que s'il me demandait quoi que ce soit, je serais d'accord.
Mais en m�me temps, je me disais que ce n'�tait pas ce que je voulais faire. Je veux dire, c'est... Je me sens encore idiot. Ma fille a�n�e est partie � l'universit� et, deux mois plus tard, elle m'a envoy� un message pour me dire que j'�tais plus connu au laboratoire d'informatique pour Git que pour Linux, parce qu'ils utilisent Git pour tout. J'ai r�pondu que Git n'avait jamais �t� une chose importante pour moi. Git, c'�tait � je dois faire �a pour faire le noyau �. Et c'est un peu ridicule que, oui, j'ai utilis� quatre mois de ma vie pour le maintenir, mais maintenant, 20 ans plus tard...
Oui, c'est � Junio qu'il faut s'adresser, pas � moi, parce qu'il a fait un excellent travail et que je suis tr�s heureux que les choses se soient si bien pass�es. Mais pour �tre honn�te, je dois reconna�tre que j'ai travaill� avec des gens sur Internet pendant suffisamment longtemps pour savoir - pendant les quatre mois o� j'ai assur� la maintenance de Git - qui avait le bon go�t d'�tre un bon mainteneur.
Ma fille a�n�e est partie � l'universit� et, deux mois plus tard, elle m'envoie un message pour me dire que je suis plus connu au laboratoire d'informatique pour Git que pour Linux, parce qu'ils utilisent Git pour tout.
Linus Torvalds : Pour moi, c'est difficile � d�crire. On peut le voir dans les correctifs, dans la fa�on dont ils r�agissent au code des autres, dans leur fa�on de penser. Junio n'a pas �t� le premier � participer au projet, mais il a �t� l'un des premiers � �tre pr�sent d�s la premi�re semaine, apr�s que j'ai rendu le projet public.
Il a donc �t� l'une des premi�res personnes - mais ce n'�tait pas comme si vous �tiez le premier, et que vous �tiez le seul. C'�tait plut�t du genre : � Bon, j'ai vu cette personne travailler pendant trois mois et je ne veux pas maintenir ce projet. Je vais lui demander s'il veut �tre le mainteneur. Je pense qu'il �tait un peu nerveux au d�but, mais cela a vraiment bien fonctionn�.
Taylor Blau : Oui, il a certainement dirig� le projet de fa�on admirable dans les...
Linus Torvalds : Oui, je veux dire, le go�t est tr�s important pour moi, mais d'un point de vue pratique, le fait de rester dans un projet pendant 20 ans, c'est encore plus important, n'est-ce pas ? Et il l'a fait.
Taylor Blau : Je pense qu'il conna�t �tonnamment bien presque tous les aspects de l'arbre.
Nous avons beaucoup parl� des d�buts de Git. Je voudrais parler un peu de la p�riode interm�diaire de Git, ou peut-�tre m�me de la p�riode dans laquelle nous nous trouvons actuellement.
L'une des choses que je trouve int�ressantes � propos de cet outil, �tant donn� son omnipr�sence, c'est qu'il a clairement �t� efficace pour aider au d�veloppement du noyau, mais il a aussi �t� tr�s efficace pour les �tudiants universitaires qui �crivent de petits projets de classe sur leurs ordinateurs portables. Qu'est-ce qui, selon vous, a rendu Git efficace aux deux extr�mes du spectre du g�nie logiciel ?
Linus Torvalds : La nature distribu�e de Git facilite beaucoup de choses et c'est ce qui le diff�rencie de la plupart des SCM. Il y a d�j� eu des SCM distribu�s, mais, � ma connaissance, il n'y a jamais eu quelque chose o� c'�tait l'objectif de conception num�ro un - avec les autres objectifs de conception num�ro un - o� l'on peut travailler avec Git uniquement localement et o�, plus tard, si l'on veut le rendre disponible ailleurs, c'est tr�s facile.
C'est tr�s diff�rent de CVS, par exemple, o� il faut mettre en place ce type de d�p�t et o�, si l'on veut le d�placer ailleurs, c'est tr�s p�nible et on ne peut pas le partager avec quelqu'un d'autre sans en perdre la trace.
Il y aura toujours un d�p�t sp�cial quand on utilise un SCM traditionnel et le fait que Git n'ait pas fait �a, et qu'il ne l'ait pas fait par conception, c'est ce qui a rendu des services comme GitHub triviaux. Je veux dire que je banalise GitHub parce que je me suis rendu compte qu'il y avait beaucoup de travail pour cr�er toute l'infrastructure autour de Git, mais en m�me temps le site d'h�bergement Git de base n'est pratiquement rien parce que tout le design de Git est con�u pour faciliter la copie, et que chaque d�p�t est le m�me et �gal.
Et je pense que c'est ce qui l'a rendu si facile � utiliser en tant que d�veloppeur individuel. Lorsque vous cr�ez un nouveau d�p�t Git, ce n'est pas grand-chose. C'est comme dans Git et c'est fini. Vous n'avez pas besoin de mettre en place une infrastructure ni de faire les choses que vous deviez traditionnellement faire avec un SCM. Et si ce projet prend de l'ampleur et que vous d�cidez de le confier � d'autres personnes, cela fonctionne �galement. L� encore, vous n'avez rien � faire. Il suffit de l'envoyer sur GitHub et le tour est jou�.
C'est quelque chose que je voulais vraiment. Je n'avais pas r�alis� combien d'autres personnes le voulaient aussi. Je pensais que les gens �taient satisfaits de CVS et SVN. Je ne le pensais pas vraiment, mais je pensais qu'ils �taient suffisants pour la plupart des gens, disons-le comme �a.
Taylor Blau : J'ai v�cu toute ma vie avec le contr�le de version dans le cadre du d�veloppement de logiciels, et l'une des choses qui m'int�ressent est de savoir comment vous voyez le r�le de Git dans la fa�on dont le d�veloppement de logiciels se fait aujourd'hui.
Linus Torvalds : C'est une question trop vaste pour moi. Je n'en sais rien. Ce n'est pas pour cela que j'ai �crit Git. Je l'ai �crit pour mes propres probl�mes.
Je pense que GitHub et les autres services d'h�bergement ont montr� � quel point il est facile de cr�er tous ces petits projets al�atoires d'une mani�re qui n'existait pas auparavant. Cela a �galement entra�n� la disparition de nombreux projets. On trouve des projets ponctuels o� quelqu'un a fait quelque chose et l'a laiss� derri�re lui, mais il est toujours l�.
Mais cela change-t-il vraiment la fa�on dont le d�veloppement de logiciels est effectu� dans l'ensemble ? Je n'en sais rien. Je veux dire que cela change les d�tails. Cela facilite la collaboration dans une certaine mesure. Il est plus facile de r�aliser ces projets improvis�s. Et s'ils ne fonctionnent pas, ils ne fonctionnent pas. Et s'ils fonctionnent, vous pouvez maintenant travailler avec d'autres personnes. Mais je ne suis pas s�r que cela ait chang� quoi que ce soit de fondamental dans le d�veloppement de logiciels.
� Cela facilite la collaboration dans une certaine mesure. �
Taylor Blau : Pour aller un peu plus loin, le d�veloppement de logiciels modernes n'a jamais �volu� aussi vite qu'aujourd'hui...
Linus Torvalds : Allez-vous prononcer le mot � IA � ?
Taylor Blau : Je ne vais pas prononcer le mot � IA �, � moins que vous ne le vouliez.
Linus Torvalds : Non, non, non.
Taylor Blau : ... quels sont les aspects de l'outil qui, selon vous, ont �volu� ou doivent encore �voluer pour continuer � prendre en charge les flux de travail nouveaux et exigeants pour lesquels les gens l'utilisent ?
Linus Torvalds : J'aimerais voir plus de suivi de bogues. Tout le monde le fait. Qu'on l'appelle suivi de bogues, probl�mes ou autre, j'aimerais qu'il soit plus unifi�. Parce que pour l'instant, c'est tr�s fragment� et chaque site d'h�bergement en fait sa propre version.
Et je comprends pourquoi ils le font. A, il n'y a pas de bonne base standard. Et B, c'est aussi un moyen d'apporter de la valeur ajout�e et de garder les gens dans cet �cosyst�me, m�me si Git lui-m�me signifie qu'il est tr�s facile de d�placer le code.
Mais j'aimerais qu'il y ait un syst�me plus unifi� o� le suivi des bogues et les probl�mes en g�n�ral seraient plus partag�s entre les sites d'h�bergement.
Taylor Blau : Vous avez mentionn� plus t�t que cela faisait au moins un moment que vous n'aviez pas suivi r�guli�rement la liste de diffusion.
Linus Torvalds : Oui, c'est vrai.
Taylor Blau : En fait, cela fait m�me un petit moment que vous ne vous �tes pas engag� dans le projet. Je pense que d'apr�s mes calculs, la derni�re fois c'�tait en ao�t 2022...
Linus Torvalds : Oui, j'ai quelques patchs exp�rimentaux dans mon arbre que je garde. Ces jours-ci, je consulte les sources Git et j'ai, je crois, quatre ou cinq correctifs que j'utilise moi-m�me. Je crois que j'en ai envoy� quelques-uns � la liste de diffusion Git, mais ils ne sont pas tr�s importants. Ce sont des d�tails qui sont tr�s sp�cifiques � mon flux de travail.
Mais honn�tement, je veux dire, c'est aussi vrai pour le noyau Linux. Je travaille sur Linux depuis 35 ans, et il a fait tout ce dont j'avais besoin la premi�re ann�e, n'est-ce pas ? Et ce qui me fait continuer � travailler sur le noyau, c'est que, A, le mat�riel �volue sans cesse, et le noyau doit �voluer avec lui, bien s�r. Mais B, ce sont tous les besoins des autres. Jamais dans ma vie je n'aurais besoin de toutes les fonctionnalit�s du noyau. Mais je m'int�resse aux noyaux, et je continue � le faire 35 ans plus tard.
En ce qui concerne Git, c'est comme si Git avait fait ce dont j'avais besoin d�s la premi�re ann�e. En fait, surtout au cours des premiers mois. Et quand il a fait ce dont j'avais besoin, j'ai perdu tout int�r�t. Parce que lorsqu'il s'agit de noyaux, je suis vraiment int�ress� par leur fonctionnement, et c'est ce que je fais. Mais lorsqu'il s'agit de SCM, c'est comme si je n'�tais pas du tout int�ress�.
Quand il s'agit de Git, c'est comme si Git avait fait ce dont j'avais besoin au cours de la premi�re ann�e. En fait, la plupart du temps au cours des premiers mois.
Linus Torvalds : J'ai appr�ci� le fait que les strat�gies de fusion soient devenues l�g�rement plus intelligentes. J'ai aim� le fait que certains scripts aient finalement �t� r��crits en C pour les rendre plus rapides, car m�me si je n'applique plus 100 s�ries de correctifs, je finis par faire des choses comme le rebasage des arbres de test et d'autres choses de ce genre et je b�n�ficie de certaines am�liorations de performance.
Mais, je veux dire, ce sont des d�tails d'impl�mentation assez petits en fin de compte. Je pense que le plus grand changement que je suivais encore il y a quelques ann�es �tait cette histoire de hachages multiples, qui me semble vraiment tr�s p�nible.
Taylor Blau : Y a-t-il des outils dans l'�cosyst�me que vous avez utilis�s en parall�le ? Je veux dire que je suis moi-m�me un grand utilisateur de tig. Je ne sais pas si vous l'avez d�j� utilis�.
Linus Torvalds : Je n'ai jamais - non, m�me au d�but quand nous avions, comme quand Git �tait vraiment difficile � utiliser et qu'il y avait des interfaces utilisateur suppl�mentaires, le seul wrapper autour de Git que j'ai jamais utilis� �tait gitk. Et il a �t� int�gr� � Git assez rapidement, n'est-ce pas ? Mais j'utilise toujours le langage de commande dans son int�gralit�. Je n'utilise pas l'int�gration de l'�diteur. Je ne fais rien de tout cela parce que mon �diteur est trop stupide pour s'int�grer � quoi que ce soit, et encore moins � Git.
Il m'arrive de faire des statistiques sur l'utilisation de mon historique Git, juste parce que je me demande quelles commandes j'utilise. Et il s'av�re que j'utilise cinq commandes Git. Et git merge, git blame et git log sont trois d'entre elles, � peu pr�s. Je suis donc un utilisateur tr�s occasionnel de Git.
Taylor Blau : J'aimerais savoir ce que sont les deux autres.
Linus Torvalds : Je veux dire �videmment git commit et git pull. J'ai fait ce truc du top 5 � un moment donn� et �a a peut-�tre chang�, mais il n'y a pas beaucoup de - j'ai quelques scripts qui utilisent git rev-list et qui vont tr�s bas et font des statistiques pour le projet...
Taylor Blau : En ce qui concerne votre interaction avec le projet, quelles sont, selon vous, les fonctionnalit�s du projet, que ce soit au d�but ou depuis, qui n'ont peut-�tre pas �t� appr�ci�es � leur juste valeur ?
Linus Torvalds : Je veux dire que Git a �t� beaucoup plus appr�ci� qu'il ne le m�rite. Mais c'est l'inverse de la question que je me poserais. Ce qui m'a le plus marqu�, c'est que les gens ont commenc� � appr�cier ce que Git pouvait faire au lieu de se plaindre de sa diff�rence.
Et �a, je veux dire, c'�tait plusieurs ann�es apr�s le premier Git. Je pense que ce sont ces �tranges d�veloppeurs web qui ont commenc� � utiliser Git � grande �chelle. C'est comme Ruby on Rails, je crois. Je n'avais aucune id�e, je ne sais toujours pas ce qu'est Ruby. Mais les gens de Ruby on Rails ont commenc� � utiliser Git en 2008, quelque chose comme �a.
C'�tait �trange parce que cela a amen� un tout nouveau type d'utilisateur de Git, du moins un que je n'avais pas vu auparavant. Il devait exister en arri�re-plan, mais il �tait �vident que tous ces jeunes gens qui n'avaient jamais utilis� de SCM auparavant utilisaient Git pour la premi�re fois, et c'�tait ce que le projet qu'ils utilisaient utilisait, de sorte que c'�tait en quelque sorte la solution par d�faut.
Je pense que cela a chang� la dynamique. Quand il n'y a plus ces anciens qui ont utilis� un SCM tr�s diff�rent toute leur vie, et que soudain vous avez des jeunes qui n'ont jamais rien vu d'autre et qui l'appr�cient, au lieu de dire � Git est si difficile �, j'ai commenc� � voir ces gens qui se plaignaient de � Comment faire ceci alors que ce vieux projet est dans CVS ? C'�tait amusant.
Mais oui, non. Le fait que les gens appr�cient Git, je veux dire, bien plus que je ne l'aurais jamais pens�. Surtout si l'on consid�re les premi�res ann�es o� j'ai re�u beaucoup de haine � son sujet.
Taylor Blau : Vraiment ?
Linus Torvalds : Oh, les plaintes n'ont pas cess� d'affluer.
Taylor Blau : Parlez-moi de cela.
Linus Torvalds : Oh, je veux dire, c'est plus comme si je ne pouvais pas donner de d�tails. Il faut chercher sur Google. Mais le nombre de personnes qui m'ont envoy� � Pourquoi �a fait �a ? � Et les guerres de flammes � propos de mon choix de noms. Par exemple, je n'avais pas git status, qui est en fait l'une des commandes que j'utilise assez r�guli�rement maintenant.
Taylor Blau : C'est dans le top 5 ?
Linus Torvalds : Ce n'est probablement pas dans le top 5, mais c'est quand m�me quelque chose d'assez courant. Je ne pense pas l'avoir jamais utilis�e avec CVS parce qu'elle �tait si lente.
Et les gens avaient toutes ces attentes. Je me souviens donc des premi�res ann�es, des plaintes concernant les noms des sous-commandes qui �taient diff�rents sans raison valable. Et la raison principale �tait que je n'aimais pas beaucoup CVS, alors je faisais parfois les choses diff�remment.
J'ai trouv� int�ressant le changement qui s'est op�r� entre 2007 et 2010, lorsque les gens ont commenc� � se plaindre de la difficult� d'utilisation de Git pour ensuite en appr�cier toute la puissance.
Taylor Blau : J'aimerais prendre quelques instants pour r�fl�chir � l'avenir du projet. Selon vous, quels sont les plus grands d�fis auxquels Git est ou sera confront� ?
Linus Torvalds : Je n'en sais rien. Je veux dire qu'il a eu tellement plus de succ�s que je n'en ai jamais eu... Je veux dire, les statistiques sont folles. Il est pass� d'une utilisation pour le noyau et quelques autres projets � une utilisation assez populaire, pour atteindre aujourd'hui 98% des SCMs utilis�s. C'est un chiffre que j'ai vu dans un rapport de l'ann�e derni�re.
Je ne sais pas � quel point c'est vrai, mais c'est �norme. Et dans ce sens, je ne m'inqui�terais pas des d�fis parce que je pense que les SCMs ont un effet de r�seau tr�s fort. Et c'est probablement la raison pour laquelle, une fois qu'il a d�coll�, il a d�coll� de fa�on importante. Lorsque tous les autres projets utilisent Git, par d�faut, tous les nouveaux projets utilisent �galement Git. Parce que cela ne vaut pas la peine d'avoir deux SCM diff�rents pour deux projets diff�rents.
Je ne vois donc pas cela comme un d�fi pour Git, mais plut�t comme un d�fi pour tous ceux qui pensent avoir quelque chose de mieux. Et honn�tement, parce que Git fait tout ce dont j'ai besoin, les d�fis viendraient probablement des nouveaux utilisateurs.
C'est ce que nous avons constat�. Nous l'avons vu avec des personnes qui ont utilis� Git d'une mani�re que je consid�re explicitement comme une mauvaise approche. Comme Microsoft, la monorepo pour tout, qui a montr� des probl�mes d'�volutivit�. Je ne dis pas que Microsoft a eu tort de faire cela. Je dis que c'est litt�ralement ce pour quoi Git n'a pas �t� con�u.
Je suppose que la plupart de ces probl�mes ont �t� r�solus parce que je ne vois pas de plaintes, mais en m�me temps je ne suis plus la liste de diffusion de Git autant qu'avant.
Je ne sais m�me pas si le probl�me des gros fichiers est consid�r� comme r�solu. Si vous voulez mettre une image de DVD dans Git, c'est du genre, pourquoi voudriez-vous faire �a ?
Mais, je veux dire, c'est le d�fi. Lorsque Git est omnipr�sent, on trouve tous ces gens qui font des choses �tranges que l'on n'imaginerait jamais - que je n'imaginais pas et que je consid�re comme des erreurs flagrantes.
Mais bon, c'est une opinion personnelle. Il est clair que d'autres personnes ont des opinions personnelles tr�s diff�rentes. C'est donc toujours un d�fi. Je veux dire que c'est quelque chose que je vois aussi dans le noyau, o� je me demande pourquoi diable vous faites �a ? Cela ne devrait pas fonctionner, mais c'est pourtant ce que vous faites.
Lorsque Git est omnipr�sent, on trouve des gens qui font des choses �tranges que l'on n'imaginerait jamais, que je n'imaginais pas et que je consid�re comme des erreurs flagrantes.
Linus Torvalds : Non, je n'en ai jamais essay�. Je veux dire, litt�ralement, puisque je suis parti de l�, de l'absence totale d'int�r�t pour le contr�le de source, pourquoi chercherais-je des alternatives maintenant que j'ai quelque chose qui fonctionne pour moi ?
Je suis arriv� � Git en n'aimant pas le contr�le de source, et maintenant je ne le d�teste plus. Et je pense que les bases de donn�es sont particuliers - c'est la chose la plus ennuyeuse de ma vie. Mais les SCM ne sont toujours pas quelque chose qui m'int�resse vraiment.
� Je suis arriv� � Git en n'aimant pas le contr�le de source, et maintenant je ne le d�teste plus. �
Taylor Blau : Vous m'avez permis de mettre un terme � la derni�re question que j'avais � vous poser. Donc, Linux est arriv� il y a 34 ans, Git il y a 20 ans...
Linus Torvalds : Oh, cette question.
Taylor Blau : Nous sommes donc en retard d'environ cinq ans pour le prochain grand projet.
Linus Torvalds : Non, non, je vois les choses dans l'autre sens. Tous les projets que j'ai d� r�aliser, je l'ai fait parce que je n'ai rien trouv� de mieux que quelqu'un d'autre.
Mais je pr�f�re de loin que d'autres personnes r�solvent mes probl�mes � ma place. Ainsi, le fait que je doive proposer un projet est en fait un �chec du monde - et le monde n'a tout simplement pas �chou� au cours des 20 derni�res ann�es en ce qui me concerne.
J'ai commenc� � faire Linux parce que j'avais besoin d'un syst�me d'exploitation et qu'il n'y avait rien qui correspondait � mes besoins. J'ai commenc� � faire Git pour la m�me raison. Et il n'y a pas eu de... J'ai commenc� Subsurface, qui est mon logiciel de plong�e, enfin, qui n'est plus mon logiciel de plong�e, mais qui �tait tellement sp�cialis� qu'il n'a jamais d�coll� de mani�re importante. Cela a permis de r�soudre un probl�me particulier, mais mon utilisation de l'ordinateur est tellement limit�e que je pense avoir r�solu tous les probl�mes.
C'est probablement d� en partie au fait que je fais cela depuis si longtemps que je ne peux faire les choses que d'une certaine mani�re. J'utilise toujours le m�me �diteur que lorsque j'�tais � l'universit� parce que mes doigts ont appris une chose et qu'il n'y a pas de retour en arri�re possible. Je sais que l'�diteur est mauvais et je le maintiens parce que c'est un projet mort que personne d'autre n'utilise.
Mais je pr�f�re de loin que d'autres personnes r�solvent mes probl�mes � ma place. Ainsi, le fait que je doive trouver un projet est en fait un �chec du monde - et le monde n'a tout simplement pas �chou� au cours des 20 derni�res ann�es pour moi.
Taylor Blau : Eh bien, sur ce point.
Linus Torvalds : Sur ce point.
Taylor Blau : Merci pour 20 ans de Git.
Linus Torvalds : Je l'ai fait pour des raisons tr�s �go�stes. Et vraiment - je veux dire, c'est le moment de r�p�ter que oui, sur les 20 ans, j'ai pass� quatre mois dessus. Tout le m�rite en revient donc � Junio et � toutes les autres personnes impliqu�es dans Git, qui ont d�j� fait bien plus que moi.
Taylor Blau : Quoi qu'il en soit, je vous remercie.
Si vous voulez en savoir plus sur l'outil de contr�le de sources distribu� Git, voici le tutoriel Pro Git. Pro Git a �t� �crit pour aider les d�veloppeurs professionnels � apprendre l'outil de contr�le distribu� Git. Vous apprendrez pourquoi Git est diff�rent et puissant, comment l'utiliser en commen�ant par des exemples simples et avanc�s, puis comment faire une transition vers Git � partir d'un syst�me d�j� install�.
Et vous ?
Pensez-vous que les propos de Linus Torvalds sont cr�dibles ou pertinents ? Quel est votre avis sur l'interview ?Voir aussi :
Linus Torvalds consid�re l'intelligence artificielle comme un � outil qui n'a rien de r�volutionnaire �, en comparaison aux compilateurs qui permettent d'automatiser l'�criture du code assembleur Git : les d�veloppeurs utilisent-ils le syst�me de contr�le de version de fa�on optimale ? Il semblerait que beaucoup de d�veloppeurs se limitent au strict minimum 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
Vous avez lu gratuitement 0 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer � vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer � vous proposer des publications.