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 !
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par pmeunier . En réponse au journal Pijul 0.11. Évalué à 3.
Répondre à un troll est-il un art ? On va essayer en tout cas...
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 log -paffiche un patch (des changements), pas un commit (une version) !Le deuxième problème de Git est l'absence d'associativité des changements. Si je
git commitA, puis que jegit pullB et C en même temps, ça ne fait pas toujours la même chose que si je commit A, puis que jegit pullB, puisgit pullC. Ç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, 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).
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.
Ç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.
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 !