pmeunier a écrit 114 commentaires

Donc qu'est ce que Pijul permet qui n'est fondamentalement pas possible de faire avec Git qui recalcul les patchs quand cela est nécessaire?

Pijul permet deux choses que Git ne peut pas faire:

• Dans Pijul, les patchs sont associatifs, ce qui veut dire que si on applique un patch A, puis B et C, on obtient le même résultat qu'en appliquant A et B, puis C. C'est assez intuitif, mais Git n'a pas cette propriété. Concrètement, ça veut dire que Git peut parfois prendre des lignes qui viennent de la fin du fichier, et les merger au début du fichier. Ça ne garantit pas que tous les merges donnent du code qui marche, mais au moins il y a une vraie structure mathématique, ce qui veut dire que le comportement est conforme à l'intuition.

• Dans Pijul, deux patchs qui peuvent être produits en parallèle commutent toujours, et ça change tout. La commutation élimine complètement le besoin de rebaser, et le cherry-picking devient l'opération par défaut, de manière complètement transparente. Par exemple, on peut cherry-picker plusieurs fois depuis la même branche sans craindre de ressusciter des conflits. La commutation de patchs élimine aussi largement l'utilité des branches, qui servent la plupart du temps dans Git à simuler la commutation de changements indépendants.

Pijul a aussi une vraie représentation interne des conflits, qui rend leur résolution plus facile : ce n'est pas juste un cas particulier bizarre, intermédiaire entre une tentative de merge local et le commit de merge. Dans Pijul, deux personnes avec le même ensemble de patchs voient les mêmes conflits.

Oublions pour un moment les problèmes d'UI (Git n'a pas besoin de serveur, SVN oui, et c'était casse-pieds. Git est vraiment mieux là-dessus, et d'ailleurs des non-techniciens peuvent l'utiliser même sans comprendre grand chose).

D'un point de vue théorique, Git et SVN sont tous les deux assez synchrones, dans le sens où ils forcent un ordre entre les opérations. On peut faire plus synchrone : Google Docs, par exemple, ou d'autres CRDTs. Git peut sembler un peu plus asynchrone que SVN, parce qu'il n'ordonne pas des opérations qui touchent à des branches différentes. Mais comme dans ce cas les opérations touchent nécessairement à des morceaux différents du dépôt, on ne peut pas vraiment parler d'asynchronisme.

Pijul, par contre, est complètement asynchrone : les contraintes d'ordre entre deux opérations sont réduites au strict minimum (essentiellement, on ne peut pas renommer un fichier, ou écrire dedans, avant d'avoir créé ce fichier). Dans Pijul, en dehors de cette contrainte, l'ordre n'a pas d'importance, puisque tous les ordres possibles aboutiraient au même résultat (les entrailles de Pijul sont mathématiquement un peu subtiles pour garantir ça, mais ça marche).

Mais comme les auteurs de Pijul font quand même du logiciel (y compris Pijul lui-même), ils comprennent quand même la contrainte des historiques clairs. Et dans Pijul, chaque branche se rappelle de l'ordre dans lequel les patchs ont été appliqués. Mais ça n'a pas d'importance, et d'ailleurs on peut enlever un patch en plein milieu (si les dépendances sont respectées) sans affecter le reste.

Avant Pijul, il y avait Darcs et Camp. Plus d'infos sur la clarté de l'historique là : https://www.youtube.com/watch?v=iOGmwA5yBn0

Il y a une structure de données interne qui modélise ton dépôt. Ton patch est créé, appliqué à cette structure de données, enregistré dans un fichier, et ajouté à l'historique de la branche.

Je ne suis pas sûr de savoir à quoi il est "relié", mais je pense que tu veux parler de ce que Pijul appelle des "dépendances", qui sont d'autres patchs. Si on voulait simuler Git avec Pijul, il suffirait que chaque nouveau patch ait le dernier patch comme unique dépendance (ce qui impliquerait qu'il a aussi tous les autres, par transitivité).

(si j'ai mal compris la question n'hésite pas à la reposer)

Est-ce que l'objectif est de défendre Git coûte que coûte, ou de comprendre mes arguments ? Dans le doute, je vais faire comme si c'était de comprendre mon argument.

Hum… Non ? git t'oblige à avoir une copie de travail (clone), ensuite le fait de faire une branche c'est juste une bonne pratique.

C'est un peu plus qu'une bonne pratique, c'est la seule solution pour faire commuter des patchs indépendants, et le seul avantage de Git sur SVN (un gros avantage, on est d'accord). La commutation du travail est la principale intuition derrière le contrôle de versions distribué, c'est le truc que les algos de merge de Git essaient de simuler.

Tu peux très bien te retrouver avec un historique non linéaire en git, mais tu va te faire mal. C'est pas de la faute de git.

100% d'accord, mais je maintiens que ce n'est pas pour une bonne raison, c'est juste parce que Git ne me laisse pas parler de patchs sans avoir à rebaser (un peu comme à l'époque où SVN ne me laissait pas parler de commit sans avoir à merger).

Comprendre un historique non linéaire est une plaie. Trouver une erreur dans une jungle de patch est à des magnitudes plus compliquées qu'avec un log linéaire.

Je suis partiellement d'accord, et c'est d'ailleurs pour ça que Pijul a les deux. Dans Pijul, une branche a un historique linéaire et un ensemble de patchs.

Ça permet d'enlever des patchs presque n'importe où dans l'historique sans avoir à rebaser. Et deux historiques qui contiennent les mêmes patchs, même pas forcément dans le même ordre, produisent toujours les mêmes fichiers (ce n'est pas toujours le cas dans Git, même quand les commits ont été mis dans le même ordre à coups de rebase).

Pour trouver une erreur, j'imagine que tu fais référence à git bisect. C'est carrémment possible dans Pijul, même si on ne l'a pas encore implémenté, et on peut même isoler des ensembles de patchs bien plus finement que dans Git.

Merger plus de 2 fichiers est aussi bien plus compliqué, déjà qu'en merger 2 est casse gueule.

C'est vrai quand on merge avec une "heuristique qui marche souvent". Quand on a un algo de merge qui vérifie certains axiomes pratiques, et où tout est réversible, c'est plus facile. Bien entendu, travailler ensemble et se mettre d'accord c'est dur dans la vraie vie, donc fusionner des changements l'est aussi. Mais au moins, Pijul ne le rend pas plus dur que la vraie vie en introduisant des sources d'erreurs techniques.

C'est vraiment décidable d'avoir A(B(C())) == A(C(B())) ?

Dans Pijul la commutation BC=CB est décidable, parce que des patchs qui ne commutent pas se référencent toujours explicitement (ou via une chaîne de dépendances), donc des patchs créés indépendamment commutent toujours (donc c'est décidable). À ce sujet, dans Darcs, la commutation est décidable sans conflits, et avec des conflits non-triviaux je ne comprends pas trop ce qu'il fait.

Mais là, c'est plutôt A(BC) == (AB)C. Et c'est décidable si A, B et C sont des patchs produits par Pijul, puisque c'est toujours le cas (une machine de Turing qui voudrait le décider s'arrêterait tout de suite sans regarder les patchs, et répondrait "oui").

Et qu'avoir un historique compréhensible c'est sacrément pratique pour maintenir ton logiciel ou pour l'auditer.

Et d'ailleurs, Pijul peut même améliorer la qualité de l'historique par rapport à Git ! Vu que Pijul n'a pas besoin de rebaser des changements pour les appliquer sur une autre branche, on peut retracer l'historique des changements, qui serait complètement perdus sinon. C'est bien pratique quand on a une branche instable et une branche stable, par exemple, et qu'on fait passer les correctifs de bugs de la branche instable à la branche stable.

Ça, en Git, ce serait un cauchemar, géré à coups de rebases et autres "rerere", au prix de longues et stressantes heures de travail qui auraient peut-être été mieux investies à réfléchir à l'algo ou à écrire du code.

Surtout que je ne vois pas la contrainte que cela pose. Éventuellement tu peux me parler du fait que ça contraint celui qui veux fusionner son code à faire en sorte qu'il fusionne correctement.

Clairement, quand on travaille tout seul sur une histoire linéaire, ou qu'on s'organise suffisamment bien pour découper le projet à l'avance sans jamais changer radicalement d'organisation, Git ne pose aucune contrainte.

Mais dès qu'on bosse sur un projet un peu moins bien défini, ou qu'on veut revenir en arrière de façon un peu non-triviale (annuler le patch d'avant-hier, mais pas celui d'hier), ou fusionner des branches temporairement, ou "cueillir des cerises", ça devient super contraint.

Attention, je n'ai pas dit impossible, Git permet bien de faire tout ce qu'on veut. J'ai juste dit "contraint", ce qui implique que ça engendre des coûts de maintenance importants dans certains projets.

Pas besoin de savoir ce que veut dire "théorie des patchs" pour l'utiliser. En vrai, c'est une structure de données qui garantit que les patchs se comportent bien, c'est-à-dire qu'ils vérifient certains axiomes :

• commutation : deux patchs produits indépendamment peuvent être appliqués dans n'importe quel ordre sans que cela ait d'influence sur le résultat.
• associativité : appliquer deux patchs en même temps fait la même chose que les appliquer individuellement, i.e. appliquer d'abord A, puis B et C ensemble fait la même chose que A et B ensemble, suivis de C.
• inverse : tous les patchs ont un inverse, qui est un autre patch que je peux envoyer pour "annuler" mes changements. Dans Pijul, absolument tous les patchs qui résolvent des conflits ont un inverse.

Mais le pari de Pijul, c'est qu'en vrai, on n'a pas besoin de savoir ça. La théorie des patchs en pratique, ça veut juste dire que tout se passe conformément à l'intuition. Dans Pijul, les branches ne servent qu'à suivre plusieurs versions du projet en parallèle (branche stable et instable, par exemple, mais pas besoin de branches pour contribuer à un projet).

Répondre à un troll est-il un art ? On va essayer en tout cas…

Je suis heureux avec Git, et j'ai pas envie de tout changer, […]

Je suis content que tu sois heureux, évidemment. Je ne suis moi-même pas malheureux avec Git, je l'utilise régulièrement pour contribuer à différents projets, avec ou sans GitHub.

Mais comme je l'utilise quand même beaucoup, et que je sais un peu comment il marche, je sais aussi qu'il a de gros problèmes, par exemple quand on essaie de l'utiliser soit un peu trop vite (en essayant d'être un peu trop "agile", à l'approche d'une deadline par exemple), soit avec un peu trop d'utilisateurs. Ces problèmes, ainsi que les problèmes d'UI sont théoriques

• Le premier problème de Git est le manque de commutation des changements :

  • Git oblige ses utilisateurs à forker (brancher) les dépôts alors qu'ils voudraient en réalité envoyer un patch pour faire avancer le projet. Cette différence, qui, je te l'accorde, paraît évidente après des années de Git, n'a rien de naturel. Et d'ailleurs, git log -p affiche un patch (des changements), pas un commit (une version) !
  • Git séquentialise tout. Si je veux combiner des changements depuis plusieurs branches librement, il faut que je choisisse un ordre, même si les commits ont été produits en même temps. Ça encore, ça n'a rien de naturel ! D'autant plus que comme Git n'a pas de vrai algo de merge, l'ordre que je choisis ne fera pas forcément la même chose, je ne verrai pas les mêmes conflits, et même sans conflits, parfois pas les mêmes fichiers !

• Le deuxième problème de Git est l'absence d'associativité des changements. Si je git commit A, puis que je git pull B et C en même temps, ça ne fait pas toujours la même chose que si je commit A, puis que je git pull B, puis git pull C. Ça, c'est parce que l'algo de merge de Git est un algo d'optimisation que a parfois plusieurs solutions, auquel cas il en choisit une arbitrairement (sans même en avertir l'utilisateur). Et ça arrive même en l'absence de conflits.

Pourquoi Git fait ça comme ça ? La réponse est purement technique, c'est parce que gérer des patchs, ça rend les changements asynchrones, et qu'on ne comprend pas grand chose à l'asynchronisme, en pratique comme en théorie. C'est pour ça que Git séquentialise tout. C'est ça qui le rend monstrueusement rapide et relativement économe en espace disque (ça, et 10 ans de développement d'une grosse communauté).

Mais Git contraint les projets un peu trop gros ou un peu trop agiles à une organisation très rigoureuse, qui n'a pas souvent grand chose à voir avec les contraintes du projet. Je travaille régulièrement sur des projets suffisament contraints par ailleurs (des articles de recherche ou du code scientifique) pour ne pas vouloir me rajouter des bâtons dans les roues exprès.

[…] tout ré-apprendre.
un nouveau VCS que je suppose réécrit from scratch. Stop, j’ai pas fini de faire le tour de Git.

Tout ré-apprendre, non! Apprendre RCS, CVS, SVN, Git prend du temps et ne finit jamais vraiment, parce qu'il n'y a pas d'algorithme propre derrière, ces outils marchent la plupart du temps, mais (1) ne modélisent pas très bien le problème de travail collaboratif, et (2) sont contraints, pour une raison ou pour une autre, à utiliser des heuristiques au lieu d'algos bien définis.

C'est un peu la même situation que les langages système avant C et Unix : tout le monde faisait une tambouille qui ne marchait pas trop mal, mais il a suffi d'un design rationnel comme C (même s'il n'est pas parfait) pour qu'on n'entende plus trop parler des BASIC, FORTRAN et autres COBOL (bien sûr, ces langages existent encore, mais ils ont été marginalisés et/ou forcés d'adopter des features de C, comme malloc et free pour FORTRAN, par exemple).

en Rust. Question de mode ? Stop, j’ai pas fini de faire le tour de C/C++

Pour la même raison, on peut imaginer que personne ne "fera jamais le tour" de C et C++. En tant que programmeur (et chercheur en info), j'aime bien voir une machine basée sur une théorie rationnelle travailler pour moi. C'est peut-être une satisfaction marxiste, et très clairement une satisfaction moderniste, mais c'est une satisfaction quand même.

Si une machine peut vérifier mon code pour moi, pourquoi vouloir à tout prix le faire à la main ? Le code que j'écris en Rust n'est pas très différent de ce que j'écrirais en C++, mais il est entièrement vérifiable par un algo basé sur une théorie cohérente. En utilisant ce genre de langage, je passe mon temps à écrire du code presque correct, et à laisser le compilateur me guider pour finir de l'écrire correctement.

En C, je passerais mon temps à débugger des erreurs d'allocation mémoire ou de concurrence, et je continuerais à les faire jusqu'à la fin des temps, parce que je suis un être humain. En Rust, je fais ces erreurs aussi, mais plutôt que de passer une semaine à les corriger, le compilateur Rust me les signale en quelques millisecondes.

écriture d’une lib SSH en Rust. Hein ? Ouais, je sais, c’était pas forcément mieux avant, toussa. Mais pourquoi tout refaire ? Pour ajouter de nouvelles failles ?

Ça c'est facile. Ce ne sont bien sûr pas mes oignons, mais à l'avenir, pour des trolls de meilleure qualité, je te conseille de te documenter un peu mieux.

La motivation de la lib SSH, c'est simplement parce qu'il n'existait pas de bibliothèque SSH en C pour écrire un serveur, qui soit documentée correctement. Et la seule bibliothèque utilisable pour écrire un serveur (libssh) est bourrée de failles un peu triviales, est très mal documentée, et son code est assez horrible.

Écrire ça en Rust permet d'écrire (pour la première fois) un serveur avec quasiment les perf de C++, avec un automate de protocole clairement défini qui évite plein de failles classiques (je n'ai aucun mérite, ça marche juste parce qu'une machine le vérifie), avec une API super modulaire et facile à utiliser.

et pourquoi SSH ? OK, j'ai pas cherché à savoir, mais si je veux du SSH, j'utilise ssh, pas Git. Chacun son taff.

Qui a dit que Pijul remplace SSH ? Comme quoi parfois il vaut mieux chercher un peu à savoir…

J'espère ne pas avoir sorti trop de choses de leur contexte. Je choisis de ne pas répondre au "point systemd", sorte de point Godwin du geek Debian. Tu es vraiment un Hitler du contrôle de version !

voir un accès root gratuit si le souci de config est au niveau de sshd lui-même.

(je suis l'auteur de Thrussh, et un des auteurs de Pijul)

Ça a été ma principale motivation pour écrire Thrussh. Avant, Pijul marchait à travers le client OpenSSH. Et même en temps qu'utilisateur de NixOS et NixOps, je ne sentais pas trop la configuration d'un serveur OpenSSH qui fasse appel à une base de données pour vérifier les clefs des utilisateurs, et serve en même temps pour ouvrir un shell.

Nest.pijul.com a un serveur Thrussh qui écoute les clients demander une ouverture de session, l'exécution d'un programme, mais ne fait rien de tout ça, et se contente de faire croire au client qu'il l'a fait. Quand un client présente une clef, le serveur vérifie qu'elle est dans la base de données. Ensuite, quand il demande une commande shell, le serveur la parse avec une regexp, appelle la fonction correspondante, et renvoie un code d'erreur.

La principale idée est que le code qui a le moins de failles de sécurité est celui qui n'est pas écrit.

Après, quand tu as écrit un serveur, écrire un client n'est pas bien difficile, et ça permet de tester plus en détail. J'ai récemment été assez content de voir que j'avais raison de me méfier des solutions existantes (https://www.cvedetails.com/cve/CVE-2018-10933/). Écrire de l'asynchrone en Rust te force à définir proprement l'automate du protocole, ça évite ce genre de blagues par construction (il y a sans doute plein de trous de sécurité que ça n'évite pas, hein).

Voila qui devrait aider a ce que tu comprennes mes doutes.

Merci d'avoir pris le temps d'utiliser des arguments, ça marche mieux !

J'ai bien pris note du fait que C était un langage bas niveau, et avec une histoire un peu longue.

Maintenant qu'on a bien discuté des trucs pas très jolis de C, en quoi cela permet-il de contester mon argument initial auquel tu sembles t'opposer, à savoir : C a marché parce qu'il était plus puissant et plus facile à apprendre que ses prédécesseurs ?

PAM est une système modulaire pour gérer l'authentification sur des machines Unix. Certains de ses modules parlent avec des serveurs LDAP, d'autres comprennent les tickets Kerberos, etc.

Le module le plus commun consiste à gérer l'authentification par mot de passe, mais dans le contexte d'une grosse organisation, ça devient vite très limité : les gens veulent se connecter sur plusieurs machines, parfois à distance et avec plusieurs protocoles (SSH, IMAP, etc.), veulent changer leur mot de passe, accéder à des services web avec le même mot de passe, etc.

Je ne sais pas qui utilise Slackware dans ce genre de contexte.

ça m'a toujours eu l'air vachement complexe et lourd, un peu trop peut-être pour être vraiment sûr

Oui, mais dans une grosse boîte ce n'est pas un gros problème : il y a des équipes pour le sécuriser. Dans mon cas, je n'ai pas ça. Et même si j'avais plus de gens sur le projet, je préférerais qu'ils travaillent sur d'autres trucs.

Il est vrai que prendre C et Unix comme point de comparaison est étrange

Je n'ai pas comparé Pijul à C. Il faut replacer mon commentaire dans son contexte. J'ai utilisé cet exemple pour montrer que la difficulté d'utilisation n'était pas une condition nécessaire à la puissance d'un outil, et que C a vite remplacé ses prédécesseurs parce qu'il était beaucoup plus facile à utiliser sans être moins puissant.

Bien entendu, aujourd'hui, après plein d'innovations sur les langages, et d'innombrables couches de re-standardisation, certaines des idées de C et d'Unix ont perdu de leur élégance, semblent moins canoniques ou un peu vieillottes.

Ça n'enlève rien à mon argument, puisqu'il se référait justement à l'époque où C est sorti.

quand on sait que le créateur de git n'est autre que Linus Torvalds

Je n'ai jamais nié les compétences techniques ou la vision de Torvalds. Mais je sais ne pas être seul à juger Unix (et C) élégants et Git pas du tout élégant. Il ne me semble pas choquant que des superstars de l'implémentation de systèmes d'exploitation (qui ont toute mon admiration) ne soient pas nécessairement experts en théorie de la concurrence.

(on pourrait aussi remarquer que Linus Torvalds n'a créé ni C ni Unix)

Bien que j'ai déjà lu des personnes défendant la position (qui se tient) que C est un langage fonctionnel pur.

Je ne sais pas si c'est une blague, mais si je lis ce lien, j'y trouve cette phrase :

As with any purely functional language, cpp consists only of (nestable) expressions, not statements. Now here’s the clever part: when evaluated (not executed), a cpp expression yields a (pure) value of type C, which is an ADT (abstract data type) that represents imperative programs.

Ça me semble faux : en CPP, suivant l'ordre d'évaluation des macros, on peut tomber sur du code différent (avec des sémantiques différentes).

Affichage de chaînes de caractères: printf, puts. Idem pour la lecture.

C'est pour ça qu'il y avait un "souvent" dans ma phrase. Je suis totalement d'accord que les entrées-sorties en C sont la principale raison pour laquelle ce n'est pas un "toujours".

Je suis d'accord qu'il y a plein de petites fonctions pour simplifier le code (puts/printf), et surtout une double API très moche sous Unix entre les pointeurs et les descripteurs de fichiers (open / fopen).

Passer plusieurs données à une fonction? Variadic arguments, pointeurs sur listes.

Ça ne fait pas vraiment la même chose, les listes sont sur le tas, les arguments sur la pile. C sert d'abord à manipuler finement la mémoire, non ?

je ne connais pas assez l'API des kernels pour juger, mais je doute fort que les choses ne puissent se régler que d'une seule façon

Vu que j'ai un peu utilisé Unix dans ma vie, je doute un peu de tes doutes.

On tourne en rond. Je te dis que git est génial pour des choses qui n'ont rien à voir avec la théorie des patchs, et tu me rétorques qu'il lui manque la théorie des patchs…

Je comprends que ça pouvait être mal interprété. C'était uniquement un exemple d'un principe sur lequel Git pourrait être basé. On n'a pas besoin de théorie des patchs pour avoir l'associativité. Peut-être qu'il existe une alternative à 3-way merge qui est associative.

Ceci dit, cette question est étrange : les gens qui croient que Git donne certaines garanties à l'utilisateur devraient être en mesure d'énoncer ces garanties (garanties = axiomes = principes), plutôt que l'inverse.

Mais j'avoue que je n'aime pas trop tes arguments se rapportant à « on a discuté avec des gens qui savent, et vous ne pouvez pas comprendre leurs problèmes », en gros, si je caricature.

C'est une caricature d'autant plus grossière que j'avais énoncé quelques unes des raisons factuelles pour lesquelles un très gros utilisateur pourrait ne pas vouloir de Git, et que des liens vers des blogs de Facebook et Google ont été postés dans la même discussion (pas par moi).

Moi par exemple je kiffe le design orienté format de données plutôt qu'API

Là-dessus, on est totalement d'accord. À tel point que Pijul est exactement ça : une nouvelle structure de données, dont la principale nouveauté est d'être tolérante aux conflits.

(dire qu'on ne retrouve pas les concepts d'Unix dans git, inventé par le créateur de l'Unix libre majoritaire aujourd'hui… je comprends pas)

Je suis d'accord qu'il y a un peu de l'esprit Unix dans Git. Par exemple, le fait que beaucoup de choses soient accessibles avec des scripts shell.

Mais Torvalds n'a pas inventé C et Unix (et c'est un argument d'autorité).

Du point de vue des concepts, les concepts d'Unix et de C sont simples et élégants, il n'y a souvent qu'une seule façon de faire chaque chose (je ne parle pas des commandes shell, qui sont une petite partie du design d'Unix, mais plutôt des appels systèmes), un petit nombre de concepts avec des rapports clairs et déterministes entre eux. Si tu prends deux concepts quelconques d'Unix ou de C, ils ne seront jamais liés par une heuristique qui peut parfois se planter. Exemple : mmap n'utilise pas une heuristique pour savoir s'il doit mapper un seul fichier, ou deux l'un au-dessus de l'autre (cet exemple est tiré par les cheveux, mais comme Unix est designé très rigoureusement, on ne peut pas trouver ce type d'exemples).

Dans Git, ce n'est pas le cas pour tout. Par exemple, il y a plein de façons de faire ce qu'on veut (de l'aveu de Torvalds lui-même).

Un autre exemple, on voit régulièrement des explications de Git pour des débutants qui commencent par "un commit n'est pas un patch" (plutôt que de dire ce que c'est), on voit plus rarement des explications d'Unix qui commencent par "un fichier n'est pas …" ou "un pointeur n'est pas …".

C'était une blague, même si elle n'était pas drôle. Désolé.

Bon, vu les commentaires d'autres sur ce fil, je ne pouvais pas trop savoir. Désolé !

En quoi ce commentaire est-il constructif ?

Si tu avais lu le commentaire auquel tu réponds, tu n'écrirais pas ça. Mais je peux répondre à ce que tu dis :

Moi aussi je trouve plus simple d'écrire 5000 lignes de code (orienté crypto qui plus est…) que d'installer le serveur OpenSSH packagé par ma distrib

Ce que tu écris est faux : Windows, une "distrib" très courante, ne package pas le client d'OpenSSH.

5000 lignes, ce n'est pas Thrussh, c'est les bindings que j'avais entrepris vers Libssh, une bibliothèque C existante qui implémente SSH. La prochaine fois, essaie de lire avant de répondre.

qui fournit une config maintenue et sécurisée.

Oui, pour un cas d'utilisation complètement différent du mien. Je veux que mon serveur accepte des patchs, ne fasse rien d'autre, et vérifie les mots de passe et les clefs avec une base de données.

OpenSSH ne fait pas ça. La combinaison OpenSSH + shell + pam + dix modules de pam fait peut-être ça, après plusieurs semaines à temps plein de configuration.

En plus quand je comprends pas l'install et la config de 50 lignes d'un serveur, il est évident que je ferai mieux en l'écrivant moi-même…

Autre exemple de mépris, et autre exemple d'ânerie : la configuration d'OpenSSH avec PAM pour parler à PostgreSQL, avec toutes les barricades pour éviter que le client ne fasse des trucs louches avec les commandes shell, ce n'est pas 50 lignes, ça ne s'écrit pas en deux minutes, et ce n'est pas facile à sécuriser.

En plus, il est hors de question pour le Nest de laisser OpenSSH lancer Pijul à chaque commande. Le Nest est asynchrone, et Pijul prend un lock sur le dépôt, ce qui bloquerait au moins un thread du serveur (très grave en asynchrone), et potentiellement le serveur entier, à chaque fois que quelqu'un pousse un patch.

Un détail non-technique : je comprends qu'il soit tentant de juger Pijul en discutant des détails d'implémentation de Git.

Ceci dit, pour être cohérent, il faudrait aussi éviter de dire d'énormes âneries sur des concepts élémentaires d'informatique ("élémentaires" dans le sens "essentiels", pas forcément "simples"). Par exemple, la décidabilité, ça a une définition précise.

Ou sinon, quand tu écris

Si, dans un commit, je modifie une partie d'un fichier, puis dans le commit suivant j'en modifie une autre qui n'a rien à voir : peu importe l'ordre dans lequel je les réalise, on devrait aboutir au même résultat.

Je veux pas te provoquer de douleur psychique à base de dissonance cognitive, mais, breaking news, dans ce cas de figure (modifications non colocalisées) git fera la même chose !

C'est complètement faux, dans tous les cas. Git n'est jamais commutatif, au contraire : il ordonne scrupuleusement les commits, c'est même sa principale utilité.

C'est une différence fondamentale entre Git et Pijul : Pijul a un nouveau type de structure de données qui rend la commutativité possible, et cette structure de données est même l'idée centrale (les merge corrects dans 100% des cas sont importants, mais moins).

Il aurait fallu mieux comprendre l'argument avant de le mépriser : ça m'étonnerait que tu penses que les commits de Git commutent, d'ailleurs tu as parlé de graphes orientés acycliques dans un autre commentaire.

Ceci n'est pas une critique sur le fait de dire des âneries (c'est cool de se laisser le droit de dire des âneries, de l'accepter et de le reconnaître), mais uniquement sur le mépris.

Autre exemple du même mépris : toute boulangère ou boulanger qui se déplace de chez lui à sa boulangerie en passant par des rues a chaque jour une expérience directe des graphes orientés, avec des étiquettes sur les arêtes.

Cet exemple est loin d'être anodin : le seul truc que Pijul essaie de faire, c'est de modéliser proprement l'expérience directe et quotidienne de millions de programmeur, et d'implémenter une théorie conforme à leur expérience quotidienne directe.

Les deux types de mépris (envers "la boulangère" et envers Pijul) se ressemblent étrangement, non ?

J'ajouterais un petit détail technique supplémentaire : les conflits dans Git sont bien un truc qu'il "essaie" de résoudre, parce que 3-way merge est une heuristique.

De plus, certains conflits sont provoqués par l'outil lui-même, comme par exemple quand on cherry-pique plusieurs fois depuis la même branche.

Dans Pijul, au contraire, les conflits sont définis clairement. Ce n'est pas un truc qu'il "n'arrive pas à faire et doit jeter l'éponge", mais au contraire une situation normale. Et c'est d'ailleurs la solution raisonnable : si un outil de résolution automatique de conflits sur du texte était possible, on pourrait essayer de l'appliquer sur des textes produits par des Israéliens et des Palestiniens.

je ne connais absolument pas Rust et je suis curieux d'avoir des éléments de comparaison concrets avec OCaml.

Ok. J'ai oublié aussi autre chose : Rust n'a pas de GC, mais un système de propriété des variables qui est très marrant à utiliser.

Sur les threads: "ce n'est pas la bonne façon de programmer" est bien le genre de réponses auquel je faisais référence. Même les téléphones portables ont des tas de cœurs, et la communauté OCaml est encore en train d'expliquer à qui veut l'entendre que ce n'est pas la bonne façon de programmer.

Comment les avantages que j'ai cités seraient là pour compenser un manque de principe solide ?

Je te cite :

Genre le système sous-jacent exposé et exploitable, les formats de données simples et centraux, l'état du VCS exposé dans le filesystem, l'utilisation en shell facile (pas mal de fonctions de merge de git sont même juste du shell !).

En gros: trop bien, on peut aller le bricoler. Sauf qu'on n'a essentiellement besoin de le bricoler parce qu'on se retrouve dans une situation pourrie à cause du manque de théorie solide dessous.

Quels principes exactement, puisqu'ils ne sont pas en rapport avec la théorie des patchs, à priori ?

Des principes, ce serait une liste d'axiomes que Git garantit à l'utilisateur. L'associativité serait un exemple.

Pour quelqu'un qui me sort qu'il connaît git mieux que tout le monde ici

Je n'ai absolument jamais dit ça. J'ai peut-être suggéré d'écouter mes arguments avant de dire "Git sera de toute façon tellement mieux que je n'ai pas besoin de t'écouter".

WTF2 ?! Git ne stock aucun diff lié à un commit

C'est vrai, j'ai écrit ça un peu tard et en décalage horaire, excuse-moi, ça fait bien longtemps que je n'ai pas regardé les entrailles de Git.

Ceci dit, ça n'enlève rien à mon argument, au contraire : le fait qu'il t'affiche un diff et qu'il travaille sur un objet complètement différent n'est pas ce que ferait C ou Unix, qui n'ont pas ce type de décalage.

Après, je vois qu'on a une idée du design logicielle assez différente

Plus de détails !

je trouve les concepts d'Unix, qu'on retrouve dans Git, vraiment géniaux.

Ce n'est pas exactement ce que j'ai dit dans mon commentaire précédent ? À part le fait qu'on ne retrouve à mon avis pas les concepts d'Unix dans Git, pour les raisons que j'ai déjà données, et que tu n'as pas vraiment commentées directement (à part à coups de WTF sur mes imprécisions techniques, et de "Git est mieux de toute façon").

je vais ajouter un argument d'autorité : tu as l'air plus jeune que moi

C'est une raison légitime pour ne pas écouter ce que je dis, et c'est honnête de le reconnaître.

Le mieux serait que pmeunier expose ses raisons, mais il est peut être passé à côté de la question.

J'ai bien vu la question, mais j'ai espéré jusqu'au bout qu'on n'allait pas me demander de commenter ce choix ;-)

Comparer des langages de programmation est difficile, et il est facile d'être mal interprété. Je ne vais donc pas comparer, et seulement dire des trucs que j'aime bien dans Rust.

• Windows est supporté comme une plateforme considérée comme standard par l'équipe de développement. Notre ambition, c'est de mettre le contrôle de version à la portée de tous, en restant aussi puissant que Git. Exclure les utilisateurs Windows nous éloigne de cet objectif.

• La communauté Rust est géniale et croît rapidement, il est facile de parler de Rust en dehors de la France.

• On peut écrire des trucs comme Sanakirja (le backend de Pijul) en Rust, qui a besoin de manipuler des chaînes de caractères sur la pile (sans avoir à écrire du C et des bindings).

• Il y a une vraie culture crypto dans la communauté Rust, ce qui permet d'apprendre rapidement et de discuter.

• Petits détails techniques : compiler des programmes en Rust est très facile, et il y a des threads (et personne pour nous expliquer que ce n'est pas la bonne façon de programmer).

Au fait petite suggestion, si jamais vous voulez que votre outils soit adoptes il doit y avoir un moyen de communiquer et d'echanger au minimum avec git (dans les deux sens).

Oui, bien entendu. D'ailleurs on a déjà commencé à écrire ça.

Le probleme c'est que je ne suis pas sur que cela soit faisable vu que vous utilisez des concepts differents.

Git ne conserve pas toujours suffisamment d'information pour pouvoir importer l'historique correctement, mais on peut très bien imaginer un outil qui marche dans suffisamment de cas.

Eh bien qu'ils partagent leurs raisons.

Il y avait les raisons dans mes commentaires précédents, ce n'était pas un argument d'autorité.

Les arguments d'autorité ne servent à rien, à part envenimer la discussion.

Mon commentaire était en quelque sorte l'inverse d'un argument d'autorité : "ne jette pas les arguments de quelqu'un que tu ne considères pas comme une autorité, il y a plein de gens qui disent la même chose, on peut peut-être considérer leur opinion".

tu pourrais passer à côté des choses géniales que tu ne remarques même pas.

Encore une fois, si on a commencé Pijul, c'est qu'on connaissait suffisamment bien Git pour en être insatisfaits.

Une partie des "avantages géniaux" que tu évoques sont utiles uniquement parce qu'ils permettent de compenser les problèmes posés par le manque de principes solides dessous.

Mais il y a aussi plein de trucs absolument géniaux dans Git ! Je n'ai jamais dit le contraite ! À commencer par la vitesse, designer des algos avec le potentiel pour le battre en vitesse a été vraiment intéressant.

Option « --depth » de git-clone, et pour aller plus loin voir le fonctionnement du fichier « shadow » dans le .git

Suggestion : suppose que les ingénieurs de Google et Facebook (et plus généralement les gens avec qui tu parles, dont moi) connaissent ces options quand ils disent ce type de trucs.

Les shallow clones améliorent un peu ce problème dans certains cas, en particulier ils permettent de compiler le projet, mais pas forcément de "travailler" sur le projet, comme par exemple de fusionner des commits qui ont divergé depuis plus longtemps que la profondeur.

Et chaque commit a besoin de calculer un hash de tout le dépôt, même si ce n'est que pour un seul fichier (j'imagine que ce n'est pas le principal souci, même dans une grosse instance).

C'est drôle que tu prennes l'exemple du C, parce que justement il a une courbe d'apprentissage un peu rude quand même, il n'est pas parfait, et j'aurais donc fait le parallèle avec git.

Je n'ai pas pris C au hasard. Encore une fois, la courbe d'apprentissage n'est pas toujours égale à la puissance de l'outil.

C est certes difficile à maîtriser, mais il est basé sur un petit nombre de concepts simples (fonctions, variables, pointeurs, préprocesseur) et orthogonaux, qu'on peut expliquer facilement, ce qui n'était pas le cas des langages d'avant.

Git a un point commun avec C, le petit nombre de concepts (branches, commits, trees).

Par contre, il est très différent de C sur deux points :

• ces concepts ne sont pas orthogonaux : par exemple, les commits sont souvent affichés (et représentés à l'intérieur) comme des patchs.

• les relations entre ces concepts sont compliquées et floues, voire incohérentes : par exemple, les fichiers sont rebricolés à partir du contenu par des heuristiques, et les merges entre branches sont faits par 3-way merge, qui n'est pas associatif (pas associatif = des lignes ajoutées par Alice se retrouvent dans un morceau que Bob a écrit indépendamment).

Ah bon ? J'ai pas souvenir de ça. Dès le début, c'était le soft « codé par Torvalds »

Des gens ont effectivement dit ça, mais en pratique plein de projets et d'entreprises sont encore sous CVS.

Torvalds lui-même le considère comme très imparfait, même si je suis d'accord que Git a connu un développement impressionnant (j'ai l'impression que c'est en très grande partie grâce à GitHub).

Mais étant partisan des courbes d'apprentissage paraboliques, j'estime que ça vaut le coup à long terme.

Cependant, je suis convaincu que ça en vaut la peine.

Je n'ai aucun problème à apprendre des trucs. Dans la vie, je suis chercheur : mon métier est d'apprendre des trucs qui n'ont pas de courbe d'apprentissage connue.

Pour des outils standards et connus, je n'ai pas non plus de problème, mais seulement quand ça vaut le coup.
Si tu as besoin d'exemples, regarde les langages qu'on utilise (Rust, Nix) et les dépendances de Pijul qu'on a dû écrire (Sanakirja, Thrussh).

Par exemple, il est beaucoup plus difficile d'apprendre le monocycle que le vélo. Si l'objectif est de se déplacer, ton commentaire ressemble à "oui mais le monocycle est plus difficile à apprendre, donc il est forcément plus efficace".

Pour les cas désespérés, il y a toujours https://git-man-page-generator.lokaltog.net/

Alors que souvent, les soft plus abordables, c'est agréable à utiliser au début, puis quand on les maîtrise bien, ils deviennent limitants et on passe à autre chose…

C'est vrai dans plein de cas. Dans le nôtre, c'est plutôt l'inverse qui est vrai : Pijul est capable de reproduire tous les workflows possibles de Git, et peut faire des choses largement plus puissantes, tout en restant simple.

Ce genre de trucs a déjà existé avant en informatique : dans les années 70, plein de gens adoraient la courbe d'apprentissage de leur langage préféré (et étaient très créatifs pour inventer de nouveaux langages obscures chaque semaine). Et à un moment, tout le monde s'est rendu compte que C offrait au moins la même puissance que les autres, en beaucoup plus souple et facile.

soit ça donne trop de liberté aux devs et les chefs n'aiment pas ça (git c'est vraiment pour que chaque dev soit complètement indépendant, c'est très présent dans son idéologie, ya pas à dire), soit ça n'intègre pas tout le nécessaire d'intégration

Ce n'est pas du tout le principal problème de ces gros utilisateurs. Leur principale préoccupation est bien le passage à l'échelle : Git devient très lent sur les très gros dépôts, parce qu'il a besoin de tout l'historique de tout pour fonctionner.

Et ces gros industriels veulent de très gros dépôts parce qu'ils ont plein de projets interdépendants compliqués à compiler.

(même si pour « des gens qui gèrent les dépôts du noyau Linux », je suis sceptique)

Tu as le droit d'être sceptique, mais dans la vraie vie plein de gens sont insatisfaits de Git, y compris son inventeur.

Oui, c'est vrai. Apparemment j'ai oublié comment était la vie avant l'administration système à distance ;-)

Sur la distinction protocole SSH / serveur OpenSSH, c'est totalement vrai. Par contre, pour le coup de la clef sans mot de passe, je ne suis pas sûr de suivre : tout ce que fait le mot de passe est de crypter la clef secrète sur le disque. Si ton disque est déjà crypté, c'est redondant, parce que le noyau linux remplit alors exactement le même rôle qu'un agent SSH,
avec cryptsetup comme interface (sauf que le noyau tourne en root, ce qui protège même un peu mieux la clef).

Sur les gros hacks de HTTP, je suis totalement d'accord. Les websockets sont un autre exemple de trucs pour lesquels le protocole n'était clairement pas prévu.
Mais HTTP 2 résout une partie des problèmes de performance de HTTP 1/1.1, et c'est vrai que plein d'entreprises ont des systèmes d'authentification basés sur les hacks en question. Étant donné que le principal argument de Pijul pour des entreprises d'une taille suffisante pour utiliser ce type de hacks est "on passe à l'échelle bien mieux que Git", je suis d'accord que ça vaut le coup de s'y préparer.

Le seul truc un peu relou pour l'instant étant la transition "je récupère un cookie/ticket SSO dans mon navigateur, et je le file à Pijul en ligne de commande".
Notre objectif (on n'y est pas encore) est que n'importe quel débutant en programmation soit capable d'utiliser Pijul sur son premier projet, et qu'il n'ait (presque) rien à apprendre ensuite, même pour aller travailler sur un énorme projet propriétaire.

Merci pour les références ! Mon problème d'interface utilisateur était essentiellement lié à l'authentification (je ne connais pas grand chose à tout ça en HTTP).

Effectivement, c'est envisageable.