Ce nouveau gestionnaire de version est développé en Rust. Il reprend la même théorie des patches que darcs, mais en résolvant ses problèmes de performance.
Le développeur principal, Pierre‐Étienne Meunier, fait des annonces régulières sur r/rust, répond aux questions de manière très complète et y défend son bébé !
Le but ici n’est pas de traduire le manuel, je vous laisse découvrir les particularités de l’outil.
Chose rare, un papier devrait être publié d’ici la fin de l’année qui fournit les théorèmes, des preuves et la complexité algorithmique du programme.
Quelques liens supplémentaires :
Est‐ce que Pijul arrivera à faire parler de lui ? Il est encore un peu tôt pour le dire, même si la théorie derrière a l’air solide, il faudra que l’interface utilisateur soit simple et fasse justement oublier celle‐ci.
# Coquilles et fautes
Posté par Snark . Évalué à 5.
J'ouvre le traditionnel fil des corrections avec "annonces régulièreS", "son bébé" (pas de t), "qui devraiT", "A l'air solide" (pas À), "faSSe justement oublier celle-ci"…
[^] # Re: Coquilles et fautes
Posté par Benoît Laurent (site web personnel) . Évalué à 1.
Arf, désolé, ça m'apprendra à poster tard.
Est-ce qu'un modérateur peut les corriger ? Merci.
[^] # Re: Coquilles et fautes
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Merci pour l'info !
Posté par Ririsoft . Évalué à 9.
Je vais regarder ça de près.
Fanboy de Hg dès ses premières heures j'ai du m'incliner face à l'hégémonie de Git. Bien que satisfait dans les grandes lignes, je suis toujours obligé de regarder les man pages pour un certain nombre d'opérations dont je n'arriverai jamais, je crois, à me souvenir de leur fonctionnement exacte, git reset en particulier.
J'utilise beaucoup aussi le rebase et je suis donc très curieux de voir ce que donne pijul dans un tel workflow.
Bref merci pour l'info :-)
[^] # Re: Merci pour l'info !
Posté par David Demelier (site web personnel) . Évalué à 3.
Utilisateur Mercurial depuis toujours, je ne me suis pas incliné à git :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Merci pour l'info !
Posté par jeberger (site web personnel) . Évalué à 1.
Pareil, au pire j'utilise hggit pour interagir avec les moutons qui utilisent Git (qui a dit "broken by design"?)
# Un peu de marketing que diable...
Posté par Psychofox (Mastodon) . Évalué à 2.
Avec un nom pareil c'est pas gagné dans le genre pas évident à retenir. Et oui j'ai lu la FAQ et compris le pourquoi de ce nom mais ça n'y change rien.
[^] # Re: Un peu de marketing que diable...
Posté par Colin Pitrat (site web personnel) . Évalué à 5. Dernière modification le 19 septembre 2017 à 09:00.
Moi je trouve ça pas mal. Ce n'est pas si facile qu'il y paraît de choisir un bon nom. Ce qui plaira à un francophone ne sonnera pas forcément bien à d'autres. Dans le cas présent, je pense que le nom passe bien dans beaucoup de langues. En français, il n'est pas difficile à retenir (ça ressemble un peu à pilule, l'orthographe est simple …) et le lire/dire 2 ou 3 fois devrait suffire à être à l'aise avec.
Après c'est vrai que Crotophaga aurait été plus classe.
[^] # Re: Un peu de marketing que diable...
Posté par Michaël (site web personnel) . Évalué à 8.
Oui mais là faut bien avouer que la pijul passe mal.
[^] # Re: Un peu de marketing que diable...
Posté par Marotte ⛧ . Évalué à 6.
Consonne voyelle consonne voyelle consonne, 5 lettres, pas facile à retenir ?
Même si la dyslexie va encore frapper et qu’on va entendre (et lire) quelques "piluj"… je trouve que tu exagères.
[^] # Re: Un peu de marketing que diable...
Posté par freem . Évalué à 3.
Là ou ça va être lourd, c'est si la commande source est
pijul: sur les claviers "classiques" (enfin, au moins les azerty/qwerty que je connais), ces lettres sont toutes sous la main droite, ça risque d'être douloureux en ligne de commande :)[^] # Re: Un peu de marketing que diable...
Posté par Liorel . Évalué à 5.
Raison de plus pour passer au bépo ;)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Un peu de marketing que diable...
Posté par freem . Évalué à 2.
Ben non, il faudrait un clavier comme bépo pour le mexicain du coup la :D
Enfin, c'est vrai qu'en bépo c'est mieux à écrire: il n'y a que le "pi" qui n'alterne pas les mains.
[^] # Re: Un peu de marketing que diable...
Posté par pmeunier . Évalué à 8.
Salut ! Je suis un des auteurs de Pijul, et je suis super en retard pour répondre.
Ce nom est en effet horrible à taper, encore pire sur un clavier dvorak. Toutes les lettres sont sur la main gauche, sauf le "l" qui est sur l'auriculaire droit, ligne du haut. En plus la main gauche doit changer de ligne à chaque lettre.
On a des idées pour le changer, parce qu'un plus il se prononce différemment dans toutes les langues. Les auteurs le prononcent comme en espagnol, mais les finlandais disent "piyoul", les anglophones "pidjoul", les français "pijul" (prononcé comme en français), et il existe sans doute plein d'autres variantes.
Bref, ce n'est pas la priorité, mais on a des idées pour le changer (peut-être quand il deviendra 1.0).
[^] # Re: Un peu de marketing que diable...
Posté par Albert_ . Évalué à 8.
De ce que j'ai entendu dire c'est pas forcement une bonne idee de faire ca "plus tard" car si, je l'espere pour vous, le projet commence a avoir un certains nombre d'utilisateur vous ne pourrez plus changer le nom ou vous allez en perdre en route!
Mais je suis d'accord avec vous, le choix d'un nom c'est chiant!
[^] # Re: Un peu de marketing que diable...
Posté par Renault (site web personnel) . Évalué à 5.
Tu sais rien que Linux qui pourtant ne semble pas compliqué à prononcer a 3 manières différentes de le prononcer rien qu'aux États-Unis.
Et je n'ose imaginer avec des noms plus complexes comme Debian, cela doit arriver fréquemment aussi.
Bref, je pense qu'il ne faut pas s'arrêter à ça, les gens prononcent les marques de manière personnelle systématiquement, sauf si la publicité mondiale arrive à imposer la prononciation attendue.
[^] # Re: Un peu de marketing que diable...
Posté par El Titi . Évalué à 5.
Sûr qu'ils vont pas nous faire avaler la Pijul aussi facilement !
# Bugs
Posté par claudex . Évalué à 1.
Il a aussi intérêt, je pense, à avoir des fonctionnalités qui sortent du lot par rapport à git. Comme par exemple, un gestionnaire de bug intégré, ou un wiki (comme fossil par exemple).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bugs
Posté par Dring . Évalué à 8.
Beurk. Un wiki ou un bug tracker intégré ? Pourquoi ?
À la rigueur, faciliter l'usage de ces outils, rajouter des moyens pour simplifier l'interfaçage, voir s'associer pour distribuer des packs complets, mais surtout pas une application fourre-tout.
[^] # Re: Bugs
Posté par claudex . Évalué à 8.
Parce que ça permet de le distribuer avec les sources. Et si tu fork, Tu récupères tout avec.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bugs
Posté par Colin Pitrat (site web personnel) . Évalué à 7.
Ce n'est pas au gestionnaire de source de faire ça ! Je suis d'accord que ce serait mieux si github mettait les pages wiki et les bugs dans le repository (google code le faisait pour les pages wiki au moins).
Mais ça doit rester en dehors du gestionnaire de sources dont ce n'est pas le rôle. Par contre, certaines fonctionnalités peuvent le faciliter (récupérer une sous partie du repository par exemple, éventuellement en lecture seule, ou interface de type système de fichier).
Avoir des composants séparés qui sont intégrés dans une solution de plus haut niveau permet de changer les composants (et donc d'évoluer) plus facilement. En plus, ça peut permettre d'avoir le choix pour certains composants (tout le monde n'a pas les mêmes préférences pour la gestion de docs, de bugs, etc…)
[^] # Re: Bugs
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
C'est le cas (dans un repository séparé): https://help.github.com/articles/adding-and-editing-wiki-pages-locally/
Je trouve l'idée de Fossil d'intégrer le wiki et le suivi de bugs avec les sources intéressant pour faire un truc complètement décentralisé. Chacun travaille sur sa machine avec sa liste de bugs, son wiki qui est tenu à jour avec les sources, etc. Et on synchronise tout ça avec un push sur un serveur, par exemple.
Je précise que je n'ai pas (encore) joué avec et que je ne sais pas comment ça se comporte en pratique. La solution retenue chez moi pour le moment est un dépôt git avec des pages vimwiki dedans, mais l'inconvénient est que vim est quasiment indispensable pour naviguer dans le wiki ou générer un rendu html.
[^] # Re: Bugs
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 5.
Fossil non seulement a plein de fonctionnalités en plus (bug tracker, wiki, documentation, distribution de binaires non versionnés, gestion des utilisateurs, etc.) mais en plus il est beaucoup plus simple d'utilisation que git, plus léger, plus rapide, et ne prends pas la tête pour rien.
Donc j'ai du mal à voir l'intérêt de ce nouveau venu. Des DVCS corrects et plus simples que git y'en a une palanquée, de Mercurial à Fossil.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Bugs
Posté par Benoît Laurent (site web personnel) . Évalué à 1.
Pijul se démarque vraiment de par le fait qu'il découle d'une théorie solide.
pamaury en dit plus dans son commentaire :Pourquoi du théorie des patch c'est bien
# Repos
Posté par dzecniv . Évalué à 2. Dernière modification le 19 septembre 2017 à 11:24.
[^] # Re: Repos
Posté par StyMaar . Évalué à 2.
Pijul était initialement écrit en OCaml, il a été ré-écrit en Rust au moment de la version 0.2 début 2016.
L'inconvénient d'un VCS auto-hébergé, c'est que quand ça bug ça fout le bazar dans l'historique.
[^] # Re: Repos
Posté par Michaël (site web personnel) . Évalué à 10.
Qu'est-ce qui a motivé ce changement? Est-ce qu'il y a des choses plus faciles en Rust qu'en OCaml? Et réciproquement? Bref, si tu as choses à dire sur l'étape de traduction, que cela concerne la motivation, les difficultés ou les résultats, ça m'intéresse. :)
[^] # Re: Repos
Posté par Dinosaure (site web personnel) . Évalué à 4.
Il me semble que le principal inconvénient, à l'époque, d'OCaml comme choix a été le support sur Windows.
Aujourd'hui, un effort constant par OCamllabs (en la personne de David Allsopp) essaye d'intégrer OCaml sur Windows. Cependant, cet effort a été entrepris après le choix de l'équipe de Pijul.
Je suis le premier à être déçu de ce choix (que je comprends ceci dit) puisque Pijul aurait pu être un projet intéressant pour des problématiques courantes à l'éco-système d'OCaml et a des projets sur lesquelles je travaille. Mais bon, si j'ai le temps je pourrais m'y pencher et faire revivre l'implémentation en OCaml :D !
[^] # Re: Repos
Posté par kantien . Évalué à 3. Dernière modification le 26 septembre 2017 à 12:02.
Et il semble bien qu'un bon support de Windows soit un critère essentiel pour pijul, ils ont même écrit leur propre bibliothèque ssh pour cela (openssh supporte mal Windows). Il y a peut être aussi des raisons liées à la performance, en particulier sur la gestion du parallélisme (les quelques libs que j'ai testées pour faire du map-reduce sont tout de même coûteuses en mémoire, ocaml-multicore devrait résoudre ce problème).
Le mieux serait que pmeunier expose ses raisons, mais il est peut être passé à côté de la question.
Implémenter git en OCaml ne t'a pas suffit ! ;-D Tu vas devenir un spécialiste des systèmes de gestion de versions.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Repos
Posté par pmeunier . Évalué à 8.
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).
[^] # Re: Repos
Posté par Michaël (site web personnel) . Évalué à 3.
Je n'ai pas jugé utile de le préciser mais je le fais à présent: loin de moi l'idée d'ouvrir une guerre de paroisses, ma question est tout à fait naïve – je ne connais absolument pas Rust et je suis curieux d'avoir des éléments de comparaison concrets avec OCaml. Donc du coup, merci beaucoup pour ta réponse!
Ça c'est un trait vraiment particulier, est-ce que tu sais l'expliquer historiquement?
Qu'est-ce qui ne vas pas avec les threads? Dans le cas de services dont le terme dominant de la performance est assujetti aux IO, l'approche alternative à la Lwt/NodeJS basée sur un thread système pour les IO, un thread système pour la logique de l'application, et des threads légers collaboratifs dans l'application et une échelonnement (“scalabilité” en bon franglais) horizontal pour monter en charge est maintenant bien mise à l'épreuve; mais c'est totalement hors de propos pour un gestionnaire de version, non? Du moins pour la partie client. ;)
[^] # Re: Repos
Posté par shbrol . Évalué à 2.
Peut être leur absence dans les normes C et C++ avant une version récente (par ex C11)
[^] # Re: Repos
Posté par kantien . Évalué à 3.
D'un autre côté, il a déjà du faire face à des commentateurs défendant git, il craignait peut être que ce soit pareil ici (d'autant que les guerres de chapelle entre langage peuvent être âpres).
Le parallélisme ? Les approches à la Lwt (ou Async) c'est pratique mais ça ne parallélise pas les calculs sur tous les core du CPU. J'ai l'impression que la propriété de commutativité entre patchs indépendants se prête bien à la parallélisation des calculs. Il y a bien le projet ocaml-multicore (encore chez OCaml Labs) à base de fibres mais il en est encore au stade de la recherche (bien qu'il avance sûrement).
À l'heure actuelle, il faut forker (comme dans cet exemple du benchmark game) pour faire du map-reduce en parallèle, ce qui n'est pas des plus adapté comme solution.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Repos
Posté par Michaël (site web personnel) . Évalué à 2.
Je ne connais pas async, quant à Lwt il me semble qu'elle utilise la même approche que NodeJS (à moins que ce ne soit le contraire) en utilisant un deuxième fil d'éxécution (Thread lourd géré au niveau de l'OS par oppositions aux Threads légers implémentés par Lwt.) Comme je l'esquissais plus haut cette approche à le mérité de la simplicité au niveau de l'application dans les cas où le redimensionnement horizontal d'une application est possible, cela permet de travailler avec une variable simple, le nombre de processus, au lieu d'une grandeur composée par le nombre de processus auquel il fait adjoindre le nombre de fils d'éxécution. Évidemment, cela ne convient pas à tous les les problèmes.
Ceci dit je suis bien d'accord que la situation des Threads sous OCaml est loin d'être idéale mais j ne suis pas certain que la remarque à laquelle pmeunier fait allusion est spécifique à OCaml.
[^] # Re: Repos
Posté par pmeunier . Évalué à 3.
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.
[^] # Re: Repos
Posté par kantien . Évalué à 4.
Il me semble qu'il y a avait un GC dans les débuts de Rust, puis ils l'ont retiré. Felix Klock (membre de l'équipe en charge des nouvelles fonctionnalités du langage) a écrit une série d'articles intéressante sur le sujet :
Pour ce qui est du multi-cœur en OCaml, c'est justement le GC qui pose problème. Xavier Leroy et Damien Doligez avaient écrit un article en 1993 A concurrent, generationnal garbage collector for a multithreaded implementation of ML qui était resté lettre morte avant de servir de base au projet OCaml-multicore. Comme pour pijul, cela pose pas mal de problèmes théoriques qui doivent d'abord être pleinement résolus avant d'avoir plus qu'un prototype. Le projet avance, mais au rythme de la recherche… ;-)
J'avais donc vu juste au niveau des besoins de parallélisation ? Je dois reconnaître que j'ai aussi du mal à comprendre la réaction d'une partie de la communauté quand elle explique que ce n'est pas la bonne façon de programmer.
Il y a bien des bibliothèques pour le parallélisme, comme functory, mais elles profiteraient d'un GC adapté au multi-cœur. Je m'étais servi de cette dernière pour faire le test du benchmark game sur les GC et ça rivalisait avec Rust (mais j'ai dû tuner le GC pour arriver à égaler les performances en temps CPU et c'était coûteux en mémoire).
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Repos
Posté par Dinosaure (site web personnel) . Évalué à 3.
J'avoue que pour le coup, j'ai du mal à cerner cette communauté qui ne veut pas d'OCaml-multicore ou même des outils disponibles aujourd'hui comme Lwt ou Async.
Après, je peux tout de même essayer de faire une proposition de réponse sur ce qu'est OCaml pour pas mal de gens encore. C'est un langage à PoC ni plus ni moins qui permet de faire l'état de l'art à des concepts qu'on ne retrouve que sur papier. En cela, l'ambition de pas mal de gens qui utilise (utilisait) OCaml n'était que de parvenir à un résultat qui les satisfasse et pas forcément en phase avec ce qu'une communauté attendrait d'eux.
En cela, l'intérêt de s'occuper du multi-threading dans les programmes Caml serait une tâche au mieux nécessaire si la mise à l'échelle ne fonctionne pas - et comme le souligne kantien, OCaml a de très bonne performances, donc cette question ce pose rarement - ou au pire trop coûteux en temps et développement pour s'y atteler.
Mais à l'opposé de cela, une communauté (plus industrielle) souhaite créer et utiliser des outils et les questions sur le multi-threading interviennent donc (notamment puisque le problème de la mise à l'échelle, dans un contexte industrielle, ce pose de facto). Mais pour cela, il faut un peu se désaliéner du milieu de la recherche et plutôt côtoyer les acteurs industriels de la communauté OCaml - qui n'ont qu'un avis trancher entre Lwt/Async mais pas sur la question du multi-threading vu la proportion de projets utilisant ces librairies.
Après, de mon point de vu, je trouve ça plutôt cool qu'il est des gens (qui sont en général pas si bêtes) pour s'offusquer du multicore car ça laisse toujours des questions et réponses intéressantes sur l'intérêt du multicore qui, à mon sens, n'est pas systématique. En cela, la problématique est prise avec des pincettes pour satisfaire le plus grand nombre sans partir tête baissé sur une implémentation duquel un bon nombre de la communauté n'y serait pas regardant.
Les extrêmes ne sont jamais bon et dieu sait qu'il y en a dans la communauté OCaml - et c'est toujours drôles de lire les mailing lists - mais si on arrive à cristalliser ces clivages et à en produire quelque chose qui satisfait tout le monde, ça peut prendre du temps et beaucoup de patience, mais le résultat n'en sera que meilleur.
[^] # Re: Repos
Posté par Michaël (site web personnel) . Évalué à 6.
Je ne veux pas parler pour les gens qui sont farouchement opposés au multicore puisque je n'en fais pas partie. Cependant je peux faire quelques remarques qui tendent a relativiser l'importance de la disponibilité d'un système tirant partie des multiples cœurs.
Dans mon expérience professionnelle, j'ai eu à travailler sur des systèmes avec beaucoup de cœurs (environ 200) pour faire du calcul numérique (finance) et pour tirer pleinement parti de ce genre d'équipement il ne faut pas seulement paralléliser les calculs mais aussi travailler sur la localisation des données en mémoire pour éviter les mouvements de cache trop importants qui pénalisent grandement l'application. On peut bien-sûr faire du calcul numérique en OCaml ou dans n'importe quel langage de haut niveau et faire attention à la localisation des données mais certaines fonctionnalités des plateformes (de type OpenMP) sont plus faciles à utiliser dans certains langages, et puis il y a tout un écosystéme historique, comme des logiciels scientifiques (Mathematica il me semble) qui peuvent émettre du code C etc., ce qui dans l'ensemble fait qu'il est assez naturel dans ce contexte d'écrire la fonction de calcul dans un langage bas niveau et de faire un binding vers le langage de haut niveau – d'autant qu'il est relativement facile d'écrire ce type de bindings pour OCaml et Lisp, que Python est quasiment conçu “par design“ comme un langage facilement extensible en C++. (Lua a aussi une FFI très facile à utiliser mais je n'ai pas encore entendu parler de gens qui font du calcul scientifique en Lua.)
Le type d'application numérique qui demande un grand nombre de cœurs sur une machine donnée est assez spécifique, il faut que le calcul utilise abondamment toute la structure initiale, autrement il est plus avantageux de faire tourner le calcul sur plusieurs machines. Pour prendre deux exemples simples, un calcul du premier genre est le calcul du carré d'une grosse matrice carrée. On peut faire un calcul par blocs en parallèle, mais cela n'est pas facile à délocaliser parceque, si par exemple si on fait 4 blocs de même taille, il faut transférer 3/4 des données pour obtenir 1/4 du résultat (et plus le nombre de blocs augmente, pire le ratio est!). Un calcul du second genre sont les calculs exploratoires faits sur une classification, où chaque fil va faire un calcul très complexe sur une petite donnée ce qui se parallélise facilement sur des machines différentes (pas forcément facile ou judicieux de louer une machine à 200 cœurs en comparaison de la location de 100 machines à 2 cœurs).
En dehors du calcul scientifique une autre application du calculs en parallèle est l'écriture de serveurs. L'approche consistant à écrire un serveur monofil dont on fait tourner un grand nombre de copies derrière un répartiteur de charge offre tellement d'avantages (logique d'application plus simple, circonscription a priori des erreurs, bugs plus facilement reproductibles, déploiement plus facile à redimensionner) qu'à la condition qu'il ne pose pas de problème de synchronisation particulier, c'est souvent la solution privilégiée.
Pour revenir au cas particulier de pijul je n'au aucune idée des algorithmes mis en jeu ni des structures de données utilisées donc je ne peux pas juger de l'avantage que ce logiciel peut tirer ou non du parallélisme léger (par opposition au fork & IPC) sur une architecture multicœur, mais dans ma petite expérience personnelle les problèmes pour lesquels ce type de parallélisme est bien adapté sont plutôt une niche qu'une généralité – surtout parceque pour que cela soit vraiment efficace il y a un travail considérable à faire sur les structures de données, travail d'autant plus critique sur les machines grand public qui ont souvent moins de mémoires cache que de cœurs. Ce n'est pas que je sois contre OCaml multicœur – et j'ai d'ailleurs bien du mal à comrpendre qu'on puisse l'être – et je serai même ravi de jouer avec lorsqu'il sera là, mais il me semble particulièrement facile de surestimer les bénéfices qu'on peut retirer de ce genre de parallélisme.
# Pourquoi du théorie des patch c'est bien
Posté par pamaury . Évalué à 6.
Je suis le développement de pijul depuis quelques temps et cet article n'évoque pas un (peut-être LE) point essentiel de pijul (alors que le lien vers le blog ne parle que de ça): pijul a un théorie correcte des patch. Pourquoi c'est important ? Avec git, svn, hg, etc (en gros tous sauf pijul ou darcs), on peut faire un merge de deux codes et se retrouver avec un code inattendu sans conflit. Qu'est-ce que l'on entend par inattendu ? Idéalement il faut lire le blog, sinon ce lien donne un explication visuelle. De la façon dont je vois ça, c'est du même ordre que la différence entre un langage dont le système de type est "sound" (O'Caml, Rust dans le fragment sûr par exemple) ou "unsound" (C, C++, Java, la plupart en fait). Certes on peut tout faire en C/C++/Java mais on peut écrire des choses qui n'ont pas de sens ou ne produisent par le résultat escompté, exemple en Java. Bien sûr être sound/unsound ne suffit pas à être un bon ou un mauvais langage et comme la plupart de ces choses, ce n'est souvent pas le candidat le meilleur techniquement qui gagne. Cela dit on peut espérer un jour avec des langages et DCVS qui sont agréables à utiliser ET corrects.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Benoît Laurent (site web personnel) . Évalué à 1.
J'ai préféré laisser les curieux aller fouiller les liens plutôt que de dire des bêtises, ça reste assez difficile à expliquer.
Merci d'avoir pris le temps de détailler les différences avec un DVCS classique.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par damaki . Évalué à 3.
Ce genre de soucis est supposé être repéré par les tests unitaires et/ou les participants aux revues de code. Honnêtement, ce genre de cas se produit très rarement en java parce qu'il n'y a pas un pan énorme du langage et des libs qui permette de faire des choses stupides dans ce genre, les effacements de types et autres joyeusetés.
Effectivement, un merge git peut donner des incohérences vu que git gère les conflits fichier par fichier. Ça ne veut aucunement dire que l'ensemble est fonctionnel, seuls des tests peuvent le prouver.
Sur le côté cohérence de git, git n'oblige pas à être cohérent sur le repo, car on considère que ce n'est pas son travail. Les commits et les branches, c'est le travail des développeurs et intégrateurs. Git ne force pas de workflow spécial ou de logique, d'où la prolifération des workflows d'utilisation de git. Si le graphe des commits ne ressemble à rien sous git, faut disputer les devs qui n'y prêtent pas attention. Exemple concret : l'équivalent d'un svn update est un git pull --rebase et il faut donc éduquer les devs sur la bonne commande à utiliser pour ne pas pourrir l'historique.
Pour en revenir à pijul, malgré leurs bonnes idées, j'ai du mal à lui trouver des atouts suffisants. C'est dommage que sa doc se focalise sur un avantage futile (youpi, mes merges sont supposément plus fiables) plutôt que sur des avantages concrets dans 100% des cas (mon repo est 100% fiable, validable et ne peut pas techniquement être corrompu sans rattrapage possible).
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pamaury . Évalué à 3.
En effet, je ne dispute pas le fait que de toute façon il faut toujours regarder le résultat d'un merge. Mais je ne pense que pas qu'il faut voir pijul comme un projet qui veut remplacer git. L'idée c'est plutôt d'expérimenter avec un modèle différent.
D'ailleurs je ne dirais pas qu'il y a pas que c'est futile. En problème typique en git qui n'existe pas en pijul et darcs: je fork master dans une branche X. Je fais plein de commits, de son côté master diverge. Puis je cherry-pick un commit de master très important dans X. Plus tard je merge X dans master: il y a un conflit car X est appliqué deux fois, git ne réalise pas que c'est "le même commit". Je recommande de lire les deux articles suivants qui expliquent bien les différences, cela ne concerne pas que les merge:
merging et merging and pjiul (notamment "Case study 2: parallel development" pour l'exemple ci-dessus).
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par benoar . Évalué à 5.
Dans 90% des cas, git va réaliser que c'est le même commit (cf. git-patch-id(1)). Dans 9% des cas où il bloquera, on se rendra compte que le merge n'est pas si « évident » que ça en pratique, et peut-être qu'il va même nécessiter de le re-travailler. Et dans 1% des cas, peut-être que oui, il aurait pu s'en rendre compte et le faire tout seul mais n'y arrivera pas. Et pour augmenter encore la possibilité de résolution, utiliser git-rerere(1).
Bref, pour 99% des cas qui concernent ce problème précis, git va être le meilleur en pratique. Et vu que ce problème n'est pas rencontré si souvent, dans 99,999% des cas d'utilisation de git en général, il sera supérieur. À moins que tu arrives au même niveau sur tout le reste de git : fiabilité, communauté, évolution, rapidité, etc.
Ça n'est pas pour te décourager, tu dis toi-même que c'est un projet d'expérimentation, et c'est très bien. Dire que la théorie des patchs, « c'est bien », oui, peut-être, mais je ne vois pas en quoi en pratique ça changera quoi que ce soit : l'exemple donné dans ton premier commentaire est complètement tiré par les cheveux et n'arrivera jamais en pratique. Oui, c'est mieux quand un outil semble « parfait » jusqu'au bout, mais pour ce problème en particulier je pense qu'on n'arrivera jamais à une jolie théorie des patchs qui n'ait pas des perfs de merdes et une complexité ahurissante, tout ça pour un gain très très minime.
Bon courage pour l'expérimentation en tous cas, ça doit être marrant à coder !
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 10.
Oui, sauf que ce problème peut être utilisé pour créer des failles dans un logiciel, même open source, et même en passant les reviews et les tests : aucun test unitaire ne peut garantir l'intégralité d'un code, et d'ailleurs toutes les failles de sécurité qui arrivent (on en découvre tous les jours presque partout) avaient échappé aux tests unitaires dans 100% des cas (encore mieux que 99,999%).
Sur les autres avantages et "Git va être le meilleur", c'est un peu ce qu'on disait de SVN quand Git est sorti.
Il n'est pas 100% honnête (et même pas 99,999% honnête) de dire "Git est supérieur" en oubliant les questions essentielles du temps d'apprentissage et du passage à l'échelle sur de gros dépôts et de grosses équipes.
Dans la vraie vie, on a parlé avec pas mal de monde depuis qu'on a commencé ce projet, et on a déjà entendu (assez rarement quand même) ce "je comprends tout Git, et c'est tellement mieux que votre truc que je ne vais même pas aller regarder ce que c'est".
Par contre, on ne l'a absolument jamais entendu des gens avec qui on a parlé qui travaillent sur de très gros trucs (par exemple chez Apple ou Facebook, ou même des gens qui gèrent les dépôts du noyau Linux).
Et on soupçonne un tout petit peu que les gens qui nous disent ça "oublient" en général de mentionner qu'ils ont passé 10 ans à essayer de le comprendre, lus des quantités ahurissantes de livres, de blogs et de manuels pour essayer de forcer Git à rester dans les clous des axiomes que Pijul garantit au débutant qui fait son premier dépôt avec un pote, sans avoir la moindre idée de ces trucs ni de notre théorie.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par benoar . Évalué à 3.
Mouarf, avec ton exemple, là ? Je veux bien un exemple concret, pour moi ça reste un cas irréaliste.
Ah bon ? J'ai pas souvenir de ça. Dès le début, c'était le soft « codé par Torvalds » et même s'il était difficile d'accès, très vite les gens ont reconnu sa supériorité (et les problèmes de SVN) même si on imaginait une période de transition pendant laquelle SVN allait rester encore présent. Mais j'ai rarement vu un soft prendre de l'ampleur aussi rapidement que git !
Oui c'est vrai. Mais étant partisan des courbes d'apprentissage paraboliques, j'estime que ça vaut le coup à long terme.
Chez Facebook & co, et dans les entreprises en général, il y a des contraintes particulières qui font qu'il est moins adapté, mais ce sont pour moi de mauvaises raisons : 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 et on le tord pour en faire un outil d'intégration et ça marche mal, soit on fait des trucs crades parce que « on n'a pas le temps » et du coup ça foire parce que les branches deviennent n'importe quoi. Bref, oui, git impose une certaine méthodologie de développement (bien qu'il n'impose pas de workflow particulier), et c'est celle qui est au cœur du Libre : indépendance, fonctionnalités bien isolées (il y a d'autres outils pour l'intégration), et nécessité d'être plutôt propre et maintenable car c'est le seul moyen d'être gérable quand peu de gens contribuent.
C'est intéressant de se poser ces questions (même si pour « des gens qui gèrent les dépôts du noyau Linux », je suis sceptique), mais je pense que ça a très peu à voir avec la théorie des patchs. Après, si tu veux t'atteler à la résolution des autres « défauts » de git, pourquoi pas, mais à ce moment-là ça n'est plus une histoire de théorie des patchs, qui semble pourtant être ton cheval de bataille ici.
Je pense rentrer dans ta description, effectivement, même si elle est légèrement exagérée sur les besoins de maîtriser git comme il faut ; on y arrive avant 10 ans en général :-) Cependant, je suis convaincu que ça en vaut la peine. 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…
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 4.
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).
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/
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.
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.
Tu as le droit d'être sceptique, mais dans la vraie vie plein de gens sont insatisfaits de Git, y compris son inventeur.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par benoar . Évalué à 4.
Quel rapport avec git ? La réticence au changement en entreprise va parfois contre toute logique. Il y aurait le meilleur VCS au monde qu'ils resteraient à CVS…
Alors j'avoue c'est bien présenté, et que ça donne envie d'aller voir. C'est bien d'avoir une certaine assurance comme tu le fais, et je vois que tu as la théorie derrière pour soutenir ton truc. Mais fais attention à ne pas voir toujours les défauts de git qui t'arrangent : tu pourrais passer à côté des choses géniales que tu ne remarques même pas. 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 !). Plein de trucs sûrement « pas propres » et pas prouvés ni sûrs, mais qui le rendent génial.
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…
Parce qu'il développent du soft d'une manière qui n'a aucun sens pour le libre. Souvent parce qu'ils ne veulent pas modulariser, parce qu'ils l'utilisent comme outil d'intégration, etc (c'est la liste que j'ai déjà citée). Et qu'aucun outil apportant les fonctionnalités de git ne pourra faire mieux en perf ; ils auront donc des très plus pourris, mais qui tiennent leur taille de projet. Ou alors ça serait une vraie révolution, mais j'y crois très peu. Pijul le serait, d'après toi ?
Option « --depth » de git-clone, et pour aller plus loin voir le fonctionnement du fichier « shadow » dans le .git (je ne vois pas de doc, mais en gros tu peux mettre n'importe quel nombre de ref dedans qui permettent de cacher des parties de la hiérarchie ; ça fait partie des trucs avancés peu exploités mais qui donnent des idées).
Ça fait deux fois que t'en parles mais je ne l'ai jamais entendu dire ça… source ?
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Lutin . Évalué à 2. Dernière modification le 24 septembre 2017 à 07:50.
Peut-être ça :
https://framablog.org/2012/09/26/linus-torvalds-linux-git-fake/
(mais j'ai pas compris la fin, il semble que ça soit une blague).
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par freem . Évalué à 2.
As-tu remarque l'uri de ton lien? Il y a fake dedans, ca a tendance a me faire douter. Et une interview surprise, vraiment?
Plus probablement, je n'ai pas remarque l'ironie de ton post?
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Lutin . Évalué à 3.
C'est même écrit très clairement à la fin billet. Je n'ai rien trouvé d'autre sur Linus se plaignant de git.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 7.
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.
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).
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).
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par xcomcmdr . Évalué à 1.
Eh bien qu'ils partagent leurs raisons. Les arguments d'autorité ne servent à rien, à part envenimer la discussion.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 4.
Il y avait les raisons dans mes commentaires précédents, ce n'était pas un argument d'autorité.
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".
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par groumly . Évalué à 9.
Ah bah ça tombe bien, ils l’ont fait:
https://m.cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
Tu peux aussi aller demander aux studios de jeux vidéos ce qu’ils pensent de git.
En gros, leur position c’est que plusieurs repo c’est une grosse erreur pour une grosse entité (C’est compliqué et ça apporte absolument rien, à part des emmerdes). Même dans une organization de taille moyenne, c’est un gros merdier à gérer (opengrok rend tout juste le,problème gerable).
Git à un parti pris très fort pour le multi repo, et n’est absolument pas adapté au mono repo.
Ca reste une philosophie qui peut se discuter, mais très honnêtement, d’un point de vue pragmatique, sorti de “ya que perforce qui soit capable de gérer un gros repo, et franchement, ça saoule de l’utiliser”, ya pas vraiment d’avantages du côté du multi repo. N’importe quelle boite de taille moyenne se retrouve vite avec plus de 100 repos, et c’est un enfer à gérer à quotidien ou sur le long terme.
Ce qui n’est absolument pas discutable est que git scale tres mal sur de gros repo. La question est “combien de boîtes atteignent cette échelle”, à l’heure des micro services, systèmes distribués et infrastructure as code, Ben je pense que la réponse est “beaucoup plus que ya 10 ans quand git est devenu populaire”.
Alors, ouais, le kernel tourne sous git, mais ça reste un projet de relativement petite échelle, essentiellement texte, qui avance assez lentement (3 mois entre chaque release, c’est très lent dans un monde de CD avec plusieurs releases par jour à une échelle de millions, voire centaines de millions d’utilisateurs).
C’est aussi un projet très yolo avec les pratiques qualité, qui délègue les tests aux autres.
Comme rare sont ceux qui ont les reins assez solide pour implémenter leur propre dvcs dans leur coin, Ben on fait avec. Mais ya clairement matière à détrôner git.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Renault (site web personnel) . Évalué à 7.
Déjà le noyau a un cycle d'environ 2 mois, pas 3.
Et Linux, petit projet, sérieusement ? En 2 mois c'est entre 10 000 et 15 000 commits qui sont intégrés. Soit environ 8 commits par heure en moyenne, à tout heure de la journée. Le noyau grossi de près de 300 000 lignes de code (donc la différence entre suppression et ajouts) à chaque version. Et plusieurs milliers de codeurs y participent à chaque version. Pour un total de plusieurs millions de lignes de code.
Pour un projet indépendant (qui ne dépend pas d'autres modules donc), des projets de cette taille et qui évoluent si vite, tu n'en as pas beaucoup. Que ce soit des Logiciels Libres ou des projets internes en entreprise.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par groumly . Évalué à 4.
relativement. Le kernel est énorme pour un projet individuel. Comparé a la somme de code totale d'une boite de taille moyenne, ya pas de quoi fouetter un chat non plus.
Oui, le projet est gros. mais c'est 99.9% du texte. 2 mois entre release c'est super long, Facebook fait 2 releases par jour. Et puisqu'on parle de Facebook/Google, ils ont plus de commit/changements en une année que le kernel en a eu depuis le debut. Et c'est pas que du texte, ya beaucoup de binaires la dedans aussi (images ou autres), vu qu'ils mettent absolument TOUT dans le meme repo.
N'importe quelle boite oriente consommateur avec un backend de taille raisonnable (on va dire qq années d'existence avec 5-10 millions monthly active) va rapidement taper dans l'échelle du kernel si tu pars sur du mono repo (et ya de très bonnes raisons de faire du mono repo). Ce genre d'échelle c'est plus que courant, en tout cas par ici.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Sufflope (site web personnel) . Évalué à 4.
C'est quoi le rapport entre le nombre de release par jour et le dépôt de version ? C'est git qui crée les paquets .deb/.rpm / construit les images Docker maintenant ? Première nouvelle.
Ah et oui un VCS c'est pas forcément idéal pour versionner des .psd de 500Mo, no shit Sherlock, heureusement que la nullité de git nous l'a appris !
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par El Titi . Évalué à 3.
Bel argument à 2 balles.
C'est pour ça que des boites s'évertuent à inventer des monstruosités comme Git LFS pour contourner les limitations d'un DVCS, tellement le fait d'avoir des gros repo qui peuvent contenir des artworks est un non sens.
Ne pas toucher au sacro saint, surtout.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par benoar . Évalué à 4.
Comment les avantages que j'ai cités seraient là pour compenser un manque de principe solide ? Quels principes exactement, puisqu'ils ne sont pas en rapport avec la théorie des patchs, à priori ? Tu restes vague et ça ne me convainc pas.
Heu… WTF ? Git ne recalcule jamais de « hash de tout le dépôt » ! Pour quelqu'un qui me sort qu'il connaît git mieux que tout le monde ici… C'est justement ce qui fait la vitesse de git, il a juste besoin d'aller chopper les objets en relation avec le(s) commit(s) précédent(s), et que tout est hashé et donc dépend pas du tout de la complexité de ton dépôt, mais légèrement du nombre d'objets.
WTF2 ?! Git ne stock aucun diff lié à un commit : il a juste un algo de packing qui dé-duplique, mais sans aucune relation avec un commit donné. Ce dernier ne contient que des SHA1 du/des tree(s) référencé.
Heu… oui, les « fichiers » sont effectivement juste du contenu et la liaison avec un path donné n'est pas reverse-trackée et juste trouvée par heuristique, mais c'est plutôt très clair et simple comme concept. Oui, ça fait que les copies et déplacement de fichiers avec modification sont suivis par heuristique, mais c'est très cohérent en fait : il n'existe de « vrai » lien entre deux fichiers modifiés et déplacés que dans la tête du programmeur, et vouloir tracker ça en plus du contenu va pouvoir amener à des difficultés qui font que git préfère simplement ne pas le faire. Oui, les 3-way merge ne sont pas associatifs, mais pareil, je ne sais pas si chercher absolument un sens à toute combinaison de patch ne va pas t'amener vers des problèmes simplement insolubles. Ou alors qui de toutes façons amèneront une telle complexité que personne n'en voudra.
Bref, pour quelqu'un qui dit très bien connaître git, je trouve certains de tes arguments légers. Après, je vois qu'on a une idée du design logicielle assez différente, et donc qu'on aura du mal à réconcilier nos arguments là-dessus, mais perso avec l'expérience (je vais ajouter un argument d'autorité : tu as l'air plus jeune que moi, vu tes vidéos ;-)) je trouve les concepts d'Unix, qu'on retrouve dans Git, vraiment géniaux.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 4.
Je te cite :
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.
Des principes, ce serait une liste d'axiomes que Git garantit à l'utilisateur. L'associativité serait un exemple.
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".
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.
Plus de détails !
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").
C'est une raison légitime pour ne pas écouter ce que je dis, et c'est honnête de le reconnaître.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Anthony Jaguenaud . Évalué à 3.
C’est aussi une bonne raison de dire f..k aux vieux et de faire ton rebel ;-)
Merci en tout cas de ta patience dans les échanges.
Un vieux :'(
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par benoar . Évalué à 2.
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…
Oui pardon, j'ai un peu exagéré une interprétation personnelle de tes écrits. 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.
Bah si, pour moi, c'est du style Unix. On doit vraiment en avoir une interprétation différente.
En tous cas, la vision de la « perfection de la théorie » que tu sembles avoir me paraît elle loin d'Unix : généralement, c'est la simplicité d'implémentation qui prévaut, dans cette philosophie.
Ça serait trop long. Moi par exemple je kiffe le design orienté format de données plutôt qu'API, qu'utilise beaucoup Torvalds. J'aime les principes d'Unix comme évoqué plus haut, mais je vois que chacun peut avoir des interprétations différentes (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). Ça serait trop long à développer ici.
C'était une blague, même si elle n'était pas drôle. Désolé.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 2.
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.
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).
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.
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 …".
Bon, vu les commentaires d'autres sur ce fil, je ne pouvais pas trop savoir. Désolé !
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par freem . Évalué à 4. Dernière modification le 06 octobre 2017 à 15:34.
On ne doit pas connaître le même C alors. Affichage de chaînes de caractères:
printf,puts. Idem pour la lecture.Définir un bloc de code réutilisable, entre les macros et les fonctions, on a aussi plus d'une façon de faire.
Passer plusieurs données à une fonction? Variadic arguments, pointeurs sur listes.
À l'origine, il était aussi possible de ne pas déclarer le type de retour des fonctions si on retournait un int…
Du coup, une seule façon de faire les choses en C… mouai.
Pour UNIX, 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.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par kantien . Évalué à 2.
Il est vrai que prendre C et Unix comme point de comparaison est étrange quand on sait que le créateur de git n'est autre que Linus Torvalds, dont on peut difficilement dire qu'il doit avoir une connaissance succincte tant du langage que du système. D'autant que git fonctionne essentiellement à base de pointeur et « d'effet de bord ».
Je vois plus la différence entre les deux approches comme analogue à celle entre les langages dits impératifs et ceux dits fonctionnels purs, surtout que Darcs, qui a servit d'inspiration à pijul, est issu de la communauté Haskell.
Bien que j'ai déjà lu des personnes défendant la position (qui se tient) que C est un langage fonctionnel pur.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 2.
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.
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)
Je ne sais pas si c'est une blague, mais si je lis ce lien, j'y trouve cette phrase :
Ç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).
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 1.
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).Ç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 ?
Vu que j'ai un peu utilisé Unix dans ma vie, je doute un peu de tes doutes.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par freem . Évalué à 4.
Ok pour les I/O, mais le souvent couvre-t-il aussi les calculs alors? Par exemple les divisions par puissances de 2?
Ou l'acces a la memoire, que tu consideres le role principal du C (pour moi, le role de C n'est pas de manipuler la memoire, mais de faire des programmes portables et performants qui font quelque chose, peu importe quoi, l'acces memoire etant un moyen, non une fin)?
Pour ce qui est de la "double API"… d'un cote y'a posix (et non unix, qui est un OS, pas un standard) de l'autre C, ce sont des outils differents, et ce point (les acces aux fichiers) se comprends facilement: open est bas niveau, moins portable que fopen (puisque pas forcement implemente par les os non posix), et plus souple. Bref, ce ne sont pas des doublons.
Au final, j'ai l'impression que tu te concentres sur des details d'implementation pour dire qu'on ne peut faire les choses que d'une facon avec ces outils… tiens, un exemple de plusieurs facons de faire un truc avec posix: effectuer plusieurs choses en "meme temps". Multi-thread ou multi-process. Pour communiquer? Entre la memoire partagee, les sockets et les signaux, y'a du choix.
Certes, il y a de grosses differences entre leurs roles et capacites (surtout pour les signaux, pour lesquels envoyer un message complexe necessiterait enormement de code, vu que je ne crois pas qu'il soit possible d'attacher une info, mais c'est faisable, en construisant un systeme qui utiliserait un signal pour envoyer 1, un autre pour les 0… ce serait moche, oui, mais faisable a priori) mais le point est la: ces outils permettent d'echanger des messages.
Tiens en parlant de sockets: poll, epoll, select ou eselect? Ces fonctions font la meme chose, avec diverses limitations ou avantages.
Voila qui devrait aider a ce que tu comprennes mes doutes.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 1.
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 ?
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par freem . Évalué à 2. Dernière modification le 09 octobre 2017 à 19:56.
Je ne rebondissait que sur le fait que l'on ne pouvait souvent faire les choses que d'une maniere en C et posix. Ce qui, a mon avis est faux (mais comme je l'ai dit, je ne suis pas expert en C ni en posix, il me reste tant a apprendre).
Pour le reste, le seul langage anterieur a C que je connaisse est l'asm intel 16 (et un peu 32 donc pas sur de l'anteriorite) bits… meme pas en fait, je sais pas qui est le1er né. Du coup, savoir pourquoi C s'est impose m'est impossible. Je suppute que son gros avantage etait justement qu'il n'etait pas trop bas niveau pour l'epoque (par exemple compare a l'asm), portable et efficace (pas trop de couches intercalaires pour faire le moindre truc). Mais…ca reste supposition de ma part, et j'ai pas envie d'apprendre le B rien que pour le decouvrir :)
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Albert_ . Évalué à 2.
Moi aussi, parceque en fait ca c'est pas Linus qui le fait? Je ne l'ai pas encore vu re-ecrire git parceque le bonhomme a legerement pris l'habitude de faire cela plutot que de parler.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
A la vue des derniers commits de Linus, il s'agit majoritairement de ré-intégration de branches ou de tags.
Ceux-ci ont déjà été retravaillés et mergés en amont donc pour cette tâche d'assez haut-niveau, pas besoin de ré-écrire Git.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Colin Pitrat (site web personnel) . Évalué à 3.
Quand je lis 'faut disputer les devs qui n'y prêtent pas attention' je suis tout de suite méfiant.
Mon compilateur a des messages d'erreurs incompréhensibles mais faut disputer les devs qui écrivent du code qui ne compile pas. J'ai pas écrit de tests mais si quelqu'un casse quelque chose à l'avenir, faut le disputer parce que c'est mal de casser mon code. Le repository est incohérent mais faut disputer les devs qui ont pas utilisé le flag --no_incoherence_introduced_please
Si l'on cherche à comprendre pourquoi 'les devs' on fait 'une bêtise' on se rend bien souvent compte qu'en fait, l'outil n'est pas pratique à utiliser, permet une erreur (voir l'encourage) sans que cela n'apporte quoi que ce soit et qu'en modifiant l'outil ou en en changeant on fait disparaître le problème définitivement. Alors qu'en 'disputant les devs', on se fatigue juste à crier sans que ça ne change rien.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Renault (site web personnel) . Évalué à 4.
Normalement le développeur, avant de merger officiellement sur le dépôt, doit vérifier sur le merge fonctionne comme attendu (compile et que les tests unitaires tournent correctement). Voire un système d'intégration continue qui vérifie ces propriétés avant de pousser ça définitivement dans le dépôt commun.
Tu peux donner les outils que tu veux aux développeurs, s'ils ne vérifient pas (ou si aucun mécanisme dans l'intégration du code ne le fait) que son commit / merge n'apporte pas de soucis particuliers, je ne vois pas par quel miracle un outil pourrait tout résoudre. C'est quand même la base… Car bon, si le code ne compile pas, je n'ose imaginer s'il a vérifier qu'il n'y a pas eu de bogues / régressions ou autres introduits.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Il faut disputer l'équipe pour ne pas être claire sur son workflow.
Dans certains cas, il est possible d'utiliser git pull --rebase (et d'ailleurs d'activer l'option autorebase dans le .git pour ne pas avoir à le faire à la main tout le temps). Dans d'autres cas, il y a juste trop d'activité et un historique trop compliqué pour que ça soit possible (le noyau Linux, WebKit, ou de très gros projets très actifs dans ce genre).
Et comme git est conçu d'abord pour le noyau Linux, forcément les réglages par défaut sont surtout appropriés pour ce cas là.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 10.
Salut ! Je suis un des auteurs de Pijul, et en retard pour répondre.
Ces avantages "concrets" sont bien évidemment garantis par notre théorie. L'avantage des merge n'est certes pas le principal avantage, mais l'idée d'avoir une théorie petite, qui garantit un petit nombre d'axiomes simples, est un avantage énorme.
Et d'ailleurs, si on regarde les bonnes pratiques, les "successful workflows" et autres "Pro Git Book" en connaissant ces axiomes, on se rend compte que tout le monde cherche à garantir la même chose.
Maintenant, (sauf dans le cas rare de Git is inconsistent, où Git fait vraiment n'importe quoi), il y a deux façons de garantir ces propritétés : soit c'est la machine qui le fait, soit c'est le programmeur. C'est exactement la même différence qu'entre la programmation fonctionnelle et les autres langages. Il n'est d'ailleurs pas extraordinairement surprenant de voir des utilisateurs de Rust, Haskell, OCaml, Scala etc. désirer mieux que Git.
Notre pari, c'est qu'alors que les langages fonctionnels sont plus difficiles d'accès que Python, pour nous ça a l'air d'être l'inverse : l'utilisateur peut complètement oublier qu'il y a une théorie derrière, tout ce qu'il voit ce que "ça colle à l'intuition" (c'est à ça que servent des axiomes dans toutes les théories) et que "ça va vite".
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Sufflope (site web personnel) . Évalué à 5. Dernière modification le 19 septembre 2017 à 13:24.
On comprend bien à la lecture que le mec n'aime pas git, mais bon au risque de passer pour insane à ses yeux ça ne me choque pas. Je m'avance beaucoup sur la maitrise de la chose, mais git ne gère pas des patchs mais un graphe orienté d'états successifs. Son exemple visuel montre clairement qu'il ne construit pas le même graphe dans les deux scénarios, ça ne me choque donc pas que l'état final puisse différer dans un cas extrêmement capillotracté.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par kantien . Évalué à 10. Dernière modification le 19 septembre 2017 à 22:38.
pijul aussi gère, à sa façon, un graphe orienté d'états successifs : un dépôt c'est une catégorie, c'est-à-dire un graphe orienté qui vérifie certaines propriétés. Les sommets du graphes sont des « fichiers » et les arcs des patchs : si il y a un arcs entre deux sommets alors la cible est le résultat du patch appliqué à la source.
En réalité les sommets ne sont pas des fichiers mais une notion étendue des ceux-ci : des digle (directed graph fi le). Si le graphe est linéaire on a un fichier au sens usuel (ligne à ligne), tandis que l'on obtient un graphe en cas de conflit lors d'un merge.
Résoudre un conflit revient juste à appliquer un patch sur un tel sommet : ainsi pijul garde en mémoire, dans son graphe, le sommet conflictuel au lien de l'effacer.
Un des propriétés marrantes c'est l'associativité des patchs :
Ici on a un 3-way merge1 qui s'obtient naturellement comme la composition de merge de 2 patchs : quelque soit le chemin pris on arrivera toujours sur le même état final Q. C'est cette propriété que n'ont pas les autres DCVS comme git et qui constitue la reproche des partisans de darcs et pijul.
Après, je ne sais pas si en pratique cela s'avérera d'un grand intérêt et plus souple à l'usage que l'existant, mais la théorie qu'il y a derrière est jolie. Elle est expliquée plus en détail dans ces deux articles de blogs :
si le dessin rappelle à certains le problème de l'héritage multiple, c'est normal il lui est formellement identique, et c'est tout l'intérêt des catégories de fournir un outillage conceptuel unifié pour ce type de problématique. ↩
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Sufflope (site web personnel) . Évalué à 4.
C'est marrant comme il suffit de parler d'un concept mathématique relativement avancé en termes un tant soit peu profanes pour t'invoquer. Y a sûrement une nouvelle tradition de magie à la Ouija à monter.
Je sais d'avance que la suite de cette conversation sera, en réponse, un autre pavé encore plus indigeste pour moi, que je ne comprendrai carrément pas, car j'ai arrêté les maths suffisamment tôt pour ma satisfaction professionnelle vu que j'aime mon travail, mais trop tôt par rapport à la maitrise d'icelles que j'aimerais avoir, mais bon je me lance quand même.
Oui alors c'est sûr, si tout le monde appelle dans son cas "état" ce qu'il stocke dans un sommet, on gère tous des états. Git stocke en premier lieu des "états"-"sommets" qui représentent concrètement et trivialement le contenu brut du dépôt aux instants T(x), et ajoute par dessus un graphe de relations bête et méchant. J'ai l'impression que pijul travaille dans l'autre sens en ayant comme citoyen de première classe les arêtes avec le patch comme contenu, et en déduit des sommets-"état du dépôt".
Du peu que je sais j'ai l'impression que le c'est-à-dire est à l'envers. Je peux envisager de voir un graphe orienté comme une catégorie, en tant que suite de morphismes dans le même groupe (transformation de fichiers) à chaque fois, mais à l'inverse, voire toute catégorie comme un graphe orienté, j'ai plus de mal, puisque dans une catégorie par définition les morphismes de groupe n'ont à priori pas les mêmes ensembles de définition et d'image ? Ou alors un graphe peut avoir des sommets "fichiers" et des sommets "bananes" si une des arêtes est un morphisme de groupe partant de l'ensemble "fichiers" et arrivant dans l'ensemble "banane", ce qui, convenons-en, ne sera que peu exploitable comme gestionnaire de sources.
Si par arc tu veux parler de ce que j'appellerais arête, alors à vérifier mais dans git les sommets c'est pareil (et c'est pas que "des fichiers", c'est "tous les fichiers du dépôt à l'instant T") par contre les arcs ne sont pas valués comme semblent être ceux de pijul, ils ne représentent que la relation "tel commit a tel ascendant dans le graphe". La sortie de
git diffpar exemple (dans mon souvenir ; si je me goure, j'ai perdu toute crédibilité :-)) n'est pas l'affichage des "patchs" contenus dans les arêtes comme dans pijul, mais est reconstruite en comparant les deux instantanés du dépôt comparés.En écrivant ça j'ai l'intuition de retrouver ce pourquoi git est si plaisant à utiliser (surtout comparé à SVN qui était dominant à l'époque, il est vrai). Faire un "rebase" en git (prendre un bout de graphe et le déplacer) est extrêmement efficace (il ne déplace que des relations) mais peut effectivement créer des changements autres que ceux "contenus" dans les commits (même si pour rappel un commit ne contient pas de changement mais décrit un nouvel état complet) d'où conflits à résoudre. Sauf que je ne vois pas comment pijul peut être magiquement mieux. Si pijul a stocké "alors là tu changes la ligne 3 du fichier 'foo' de 'bar' vers 'baz'" comme patch, par quelle magie, lorsque je le
rebasesur un nouveau sommet où précédemment la dite ligne 3 a été modifiée de 'bar' vers 'boo', il recolle les morceaux ? A part en disant "oh merde je m'en fous je colle 'baz' puisque de toute façon on voulait 'baz'". Ou alors en disant "euh au secours conflit !".Exactement comme git en fait.
A ce propos je rebondis sur ta première image, c'est précisément le même biais que dans le lien que je critiquais. Vous prenez tous les deux le cas "simple" où la ligne changée dans les deux branches est la même au départ. C'est "simple" pour un humain parce que c'est "la même" visuellement et on se dit "pffff git est con", mais :
Ta deuxième image est carrément malhonnête. Tu ajoutes un
originalqu'il n'y avait pas et qui comme par hasard renforce l'effet visuel de "j'ai juste ajouté une ligne" (sauf que dans la réalité ce n'est qu'un cas particulier simple pour un humain qui comprend le fonctionnel des sources). Si toi et ta femme aviez changé "work" pour une ligne différente chacun de votre côté ?Par ailleurs le merge final (ainsi que sa généralisation dans la 3ème image) est simplement un merge déterministe, ce qui :
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Michaël (site web personnel) . Évalué à 4.
Je pense que la façon habituelle de voir un graphe G comme une catégorie C est de dire que
C'est un “gag” assez déroutant de la théorie des catégories qu'à aucun moment elle ne demande que les objets soient des ensembles avec des éléments ni que les morphismes puissent être appliqués sur des éléments de ces objets. On peut aussi transformer groupes et monoïdes en catégories ou en graphes. Si ces manipulations semblent a priori un peu gratuites il ne faut pas perdre de vue que chacune des ces théories (graphes, catégories, monoïdes) ont chacune un corpus phénoménal de théorèmes ce qui justifie le besoin de changer de point de vue sur les objets qu'on étudie.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Sufflope (site web personnel) . Évalué à 5.
Je rebondis sur mon (y a même des chances que ça ne compile juste pas) avec un exemple.
Supposons que j'ai sur
mastercette méthode en Groovy pour récupérer un utilisateur dans mon appli Grails, qui filtre les utilisateurs blacklistés (on passera sur la propreté d'utiliser desnull, de ne pas filtrer directement en base, etc., hein, c'est un exemple) :Dans la branche A le développeur gentil décide que le blacklist c'est trop méchant et retire ce filtre :
Plus tard, dans la branche B le développeur méchant pense que le blacklist c'est cool et qu'en plus un type qui ne s'est pas connecté depuis 1 mois c'est louche :
Qu'est-ce que pijul va faire au merge ? S'il applique les patchs successivement le résultat ne compilera même pas avec un
elseorphelin :Toute autre combinaison valide syntaxiquement (retirer les deux test, garder les deux) est indécidable sans les specs de l'appli. Ainsi que toute modification (genre retirer le premier filtre mais garder celui sur la date en retirant le
else, comment tu sais que c'est ce qu'on veut finalement ? Et pijul ne parle pas le Groovy à priori).À moins que j'ai vraiment loupé un truc, seule l'attitude de git, s'arrêter et te dire t'es gentil tu corriges tes conneries est valide.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par kantien . Évalué à 4.
Il va dire qu'il y a conflit, comme git. Mais la différence entre les deux outils (ou plutôt entre leur fondement théorique) ne se situe pas à ce niveau là, c'est-à-dire que ce n'est pas sur ce genre de question qu'ils se distinguent : pijul n'est en rien un outil magique qui résout tout seul les conflits de merge en devinant ce qu'il y a dans la tête des programmeurs.
En fait, je me suis rendu compte que j'ai mal utilisé le terme de « 3-way merge » ce qui t'a sans doute induit en erreur sur le fonctionnement de pijul.
Je n'ai pas le temps de corriger mon erreur de présentation, j'essaierai de voir demain. Sinon, le plus simple est d'aller lire les deux articles de blog que j'ai donné en lien, je voulais juste en faire un résumé et un teaser.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 10.
Pijul fait bien entendu la même chose.
Je voudrais juste rajouter que "appliquer les patchs successivement" a un sens, mais Pijul garantit que les applique dans n'importe quel ordre fait la même chose, ce qui permet de laisser les deux développeurs faire un pull de l'autre, et d'aboutir à exactement le même résultat :
L'attitude de Git dans ce cas :
Ce n'est pas complètement raisonnable, en particulier sur des codes plus gros qu'une fonction de trois lignes qui fait un truc simple.
Ce qui est encore moins raisonnable, c'est que Git peut en plus, dans pas mal de cas, indiquer un conflit alors qu'il n'y en a pas, simplement parce que le manuel de bonnes pratiques a dit de faire un rebase il y a trois mois. L'intention du manuel était bonne : il s'agissait juste d'essayer de simuler la commutation de patchs. Mais ça n'a pas trop marché, et maintenant il faut relire un code déjà testé et relu quinze fois auparavant, pour s'assurer encore une fois que tout va bien, alors que ce n'est pas forcément sur ce morceau-là du projet qu'on voudrait travailler maintenant.
Relire du code est absolument essentiel, on est d'accord, mais on peut aussi supposer que les participants au projet ont un temps de travail fini, et des priorités de relecture et de tests décidés par autre chose que par Git. Dans ce cas, c'est une perte de temps.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 10.
Je réponds super en retard (je suis un des auteurs du truc).
Personne ne conteste que Git est bien mieux que SVN. Mais il est basé sur les mêmes heuristiques "qui marchent souvent", et passe encore moins bien à l'échelle de très gros dépôts (un truc à la mode chez Google et Facebook) que SVN.
Pijul n'est pas "magiquement mieux", dans le sens où il n'y a aucune magie, seulement une vraie théorie qui gère tous les cas, donne des axiomes simples et efficaces à l'utilisateur (et des algos avec une meilleur complexité que Git, même s'il y a encore eu moins de micro-optimisation dans Pijul que dans Git).
Une conséquence de ces axiomes est que les conflits ne sont pas (comme dans Git ou même Darcs) des "cas pourris" qu'il faut résoudre avant le prochain commit. Ils sont traités comme le cas normal.
En fait j'aurais plutôt tendance à dire que Git est "magiquement" moins bien, parce qu'il utilise des heuristiques (de la magie) qui marchent souvent. Il n'y a pas de principe qui assure que tout va toujours bien se passer. Au fait, les gens qui font Pijul, c'est-à-dire Florent Becker, moi-même, et les gens qui commencent à nous rejoindre, connaissent très bien Git (et très bien Darcs, et un peu moins Mercurial et SVN).
C'est effectivement un conflict dans Pijul. Pijul n'utilise pas du tout le contenu des lignes pour appliquer un patch, seulement leur histoire et leur contexte.
Ça n'a rien de magique, il y a simplement des règles pour garantir les axiomes.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par kantien . Évalué à 5. Dernière modification le 23 septembre 2017 à 11:46.
Je n'ai pas vu à quel moment il a été fait mention d'un concept mathématique relativement avancé en termes profanes. Tu disais que git gère un graphe orienté d'états successifs, je t'ai répondu que pijul faisait de même.
Si mes réponse apparaissent comme des pavés indigestes, alors c'est que j'ai échoué à atteindre mon objectif. Mon intention principale, quand j'écris sur ce site, est d'être compris par le plus grand nombre et non d'utiliser des termes pédants et abscons. Ton choix d'avoir arrêté les maths suffisamment tôt pour ta satisfaction professionnelle est on ne peut plus respectable : chacun fait et étudie ce qu'il lui plait. Cela étant, si je peux réussir à te faire comprendre ce qui distingue git et pijul sans entrer dans des détails techniques et théoriques, j'aurai atteint mon objectif.
Comme te l'a déjà répondu Michaël : toute catégorie peut être vu comme un graphe orienté (on les présente souvent ainsi d'ailleurs) mais la réciproque n'est pas vraie; mon c'est-à-dire n'est pas mis à l'envers. Mais laissons donc de côté le concept de catégorie et gardons donc celui de graphe orienté : il sera compris de tout le monde.
De ce que j'en ai lu et compris, pijul aussi a pour sommets dans son graphe le contenu du dépôt aux instants T(x), à savoir les fichiers de la branche de travail. En revanche, pijul voit l'évolution de l'historique d'un dépôt comme un succession de patchs appliqués sur lui et c'est ce que représente son graphe en étiquetant chaque arêtes par un patch. Ce qui donne bien aux patchs un statut de citoyens de première classe, mais il ne passe pas son temps à déduire les fichiers par application des patchs par simple soucis d'efficacité :
Venons-en maintenant à une propriété qui distingue git et pijul : l'associativité. C'est certes une notion mathématique mais simple à comprendre : elle dit, en gros, dans le cas de l'addition, que
(a + b) + c = a + (b + c)ce qui fait qu'en général on se dispense d'écrire les parenthèses et que l'on écrit tout simplementa + b + c.Il est très utile, en pratique, d'avoir des opérations associatives et lorsque ce n'est pas le cas, il faut faire attention à la manière dont on les regroupe. Si je reprend l'exemple de la multiplication des matrices données dans un autre journal pour réduire le nombre de cache miss :
Dans son article, Ulrich Drepper précise bien « we ignore arithmetic effects here which might change the occurrence of overflows, underflows, or rounding », et il a raison : l'addition n'étant pas associative en arithmétique flottante, les deux programmes ne sont pas identiques. Mais son intention était surtout de montrer que l'ordre dans lequel les instructions étaient effectuées avaient son importance sur la gestion du cache CPU.
Quittons cette courte digression et revenons à nos moutons. Si l'arithmétique flottante n'est pas associative, il n'en est pas de même des séries d'instructions dans un langage comme le C :
(e1;e2);e3se comporte commee1;(e2;e3)oue1;e2;e3. Par contre, la fusion des patchs et commits en git ne vérifient pas cette propriété. C'est ce qui lui est reproché, entre autre, par les promoteurs de darcs et pijul. Le lien du premier commentaire illustrait ce phénomène, et la documentation de pijul l'illustre avec ces deux schémas :si chaque point illustre des patchs appliqués, disons A B C, alors avec git on aurait :
(A;B);C ≠ A;(B;C). C'est ce qui se passe quand on fait du cherry-picking et du rebase. En revanche, pijul vérifie bien cela et c'est ce qu'illustrait ce graphe :Si l'on part de l'état O du dépôt, qu'Alice et Bob fork pour aller l'un dans l'état B et l'autre dans l'état C. Puis Alice passe ensuite dans l'état M. Peu importe que l'on fusionne d'abord B et C dans l'état N pour ensuite fusionner N et M, ou que l'on fusionne directement C et M : dans tous les cas on arrivera sur le même état Q. Pour revenir rapidement sur la notion de catégorie, cette propriété d'associativité fait partie de sa définition : un graphe qui ne la vérifie pas ne peut être vu comme une catégorie, en revanche une catégorie vue comme un graphe la vérifiera.
Comme l'a dit pmeunier, git ne vérifiant pas cette propriété (pourtant utile et, dans le fond, désirée par les utilisateurs), il y a des guides de bonnes pratiques pour combler cette lacune, là où, par construction, elle est automatiquement satisfaite dans pijul.
Outre cette propriété d'associativité des patchs, il y en a une autre fort utile : celle qui cherche à capter l'essence de fonctionnalités orthogonales ou indépendantes. 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. Cette propriété s'appelle la commutativité des patchs, à savoir
p1;p2fait la même chose quep2;p1(oua + b = b + a). Pijul détecte automatiquement de telle situation et transforme (de manière transparente pour l'utilisateur) le graphe de dépendance des états. Dans une telle situation :pijul va chercher s'il ne peut trouver un patchs
a(q)telle que dans le graphe suivant :la fusion des états A et C donne le même état B que dans la séquence
p;q, et en arrière plan on aura dans le graphe de pijul cette situation :ce qui permet, entre autre, de paralléliser les calculs, mais rend aussi le graphe plus flexible à l'usage. Les guides de bonnes pratiques expliquent également comment obtenir une telle chose en git : avec pijul, rien à faire, elle est fournie de base sans effort de le part des utilisateurs.
Un dernier point, un peu plus technique que ce qui précède, mais pas si difficile à comprendre, c'est là raison d'être des digle. Lorsque l'on cherche à fusionner deux états, on se retrouve dans la situation suivante :
Le problème est que si l'on prend pour type des sommets celui des fichiers, ce problème n'a pas toujours de solution : c'est ce qu'il se passe lorsqu'il y a conflit. Il y a un principe général qui consiste à dire : si le problème n'a pas de solution, alors agrandissons l'espace du possible et il aura toujours une solution. C'est, pour donner une comparaison, ce qu'on fait les algébristes quand ils ont inventé les nombres complexes : certains polynômes n'ont pas de racines, ce n'est pas grave, il suffit de rajouter des nombres et tout polynôme aura une racine. Raison pour laquelle, en cas de conflit, pijul produit pour sommet un graphe orienté de lignes et non un fichier. De la même façon que l'on peut projeter de plusieurs façons différentes un nombre complexe sur un nombre réel, on peut aplatir de différentes façon un digle en un fichier ou réduire de différentes façons un conflit. Mais cette phase ne résolution, comme dans git, n'est pas effectuée automatiquement par pijul mais reste à la charge des programmeurs.
En espérant avoir éclairci quelques différences entre git et pijul, sans avoir écrit un pavet indigeste.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Michaël (site web personnel) . Évalué à 1.
Ce n'est pas plutôt le contraire? Un graphe orienté peut toujours être transformé en catégorie (attention, les morphismes de la catégorie correspondent aux chemins!) tandis qu'une catégorie peut ne pas être transformée en graphe, essentiellement parceque les objets de la catégorie ne forment pas nécessairement un ensemble.
Ceci-dit, c'est une objection essentiellement scolaire parcequ'il va de soi qu'on ne peut tirer quelque chose du point de vue “graphe” sur les catégories que pour des catégories bien particulières.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par kantien . Évalué à 2.
Non, c'est bien ce que j'ai écrit : toute catégorie est un graphe orienté, mais la réciproque est fausse. Une catégorie est un graphe orienté qui doit vérifier un certain nombre d'axiomes; autrement dit, ces axiomes sont des contraintes imposées au graphe et tout graphe qui ne les satisfait pas ne peut représenter une catégorie.
Comme tu évoques la notion d'ensemble, voici un exemple : un modèle de la théorie des ensembles est un graphe orienté qui n'est pas une catégorie. La théorie des ensembles est une théorie axiomatique d'une relation binaire que l'on appelle l'appartenance (notée
) et une relation binaire peut parfaitement se représenter comme un graphe orienté où l'existence d'une relation entre deux objets est signifiée par la présence d'une arête entre les deux sommets du graphe. Pour qu'un tel graphe puisse représenté une catégorie, il faudrait que la relation soit réflexive et transitive : ce qui n'est pas le cas de la relation d'appartenance, ni de nombreuses autres relations binaires.
En revanche on peut toujours, à partir d'un graphe orienté, engendrer une catégorie en prenant sa fermeture transitive :
puis en rajoutant une flèche de chaque sommet vers lui-même.
Pour revenir sur le graphe de l'univers des ensembles, les contraintes imposées par les axiomes sont tels que l'on peut plonger ou encoder n'importe quelle construction mathématique en son sein. La généralité de la notion de catégorie permet de faire la même chose : ce sont deux approches distinctes sur le fondement des mathématiques mais d'égale utilité.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Michaël (site web personnel) . Évalué à 2.
Ah oui effectivement, comme mathématicien assez peu versé dans la logique je considère un peu rapidement que les sommets d'un graphe et ses arêtes sont des ensembles, mais si on relaxe ces conditions au même niveau que celles que l'on met sur les objets d'une catégorie, il n'y a pas d'obstacle à associer formellement les deux notions.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par kantien . Évalué à 2.
Disons que la notion d'ensembles en mathématique est ambigüe (cf. le pardoxe de Russel), alors j'ai tendance à utiliser ce terme pour désigner les objets d'un modèle de la théorie des ensembles (ou les sommets d'un graphe qui est modèle de la théorie). Ce qu'il y a avec ZF (comme avec la théorie des catégories) est que l'on peut réflchir la métathéorie dans la théorie elle-même et aboutir à des théorèmes du style : si ZF est consistante alors elle a un modèle dénombrable (bien que le modèle en question possède des ensembles non dénombrables de son point de vue).
Pour une présentation succincte de la théorie des catégories, il y a le cours Inititation à la théorie des catégories de Gérad Huet qui commence ainsi :
Comme les notations ci-dessus te rappellerons celles utilisées pour les annotations de typage en OCaml, et que CAML signifie Categorical Abstract Machine Language (c'est la machine abstraite du bytecode OCaml), tu pourras aussi jeter un œil à De la déduction naturelle a la machine categorique :
Sinon, pour en revenir à pijul, j'ai eu une nouvelle idée pour présenter la notion de fusion dans ce système. Quand on a une relation reflexive et transitive (un préodre), on peut la voir comme une catégorie (en réalité ce sont les catégories ayant au plus une flèche entre deux objets). Prenons, par exemple, la catégorie dont les objets sont les entiers et la relation de préodre « être un multiple de ». Ainsi le schéma de fusion suivant :
peut se lire :
AetBsont des mutliples deO(A = p * OetB = q * O) etM(M = r * A = s * B) est un multiple commun deAetB. Mais parmi tous les mutliples communs deAetB, il y en a un qui est plus petit que les autres : c'est lui la fusion !!! Ce qu'exprime ce diagramme :si je prends un autre multiple
FdeAetBalors il est multiple de leur ppcmM.Cette notion, qui est une généralisation de la notion de borne supérieure (le plus petit des majorants si on y voit une relation d'ordre, le descendant minimal dans l'historique du dépôt) est ce que les catégoriciens appellent une somme amalgamée. Comme une telle somme n'existe pas toujours si on prend pour objets des fichiers, il faut prendre pour objets des digles.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Sufflope (site web personnel) . Évalué à 3.
Non bien sûr, les graphes orientés c'est du bon sens populaire, l'autre jour j'en parlais avec ma boulangère. Elle m'a d'ailleurs dit "oublie pas d'étiqueter les arêtes sinon c'est un peu trop simple".
D'accord je vois certains cas où le comportement de git peut différer suivant la stratégie choisie. Ce sont des symptômes de "n'importe quoi as a process". J'ai essayé de l'illustrer avec du "vrai code" avec mon histoire de validation d'utilisateur (pas terrible mais mieux que vos exemples soit sans code tout court (intéressant pour un gestionnaire de sources) soit avec des exemples encore moins réalistes et spécialement conçus dans votre sens pour que les parties en conflit aient exactement la même apparence, pour qu'on puisse les confondre alors que rien ne permet à priori de supposer qu'elles seront identiques) et la conclusion qu'on m'a livrée c'est "ah bah là pijul arrête aussi de bosser en disant qu'il y a conflit".
Si ça te fait mal de te taper sur le tibia avec une serpette, est-ce que vraiment la bonne solution c'est de la remplacer par une serpette en mousse ?
Premièrement : dans un cas "réel" l'auteur a été obligé d'admettre que pijul n'arrivera nul part, qu'il abandonnera en déclarant un conflit. Deuxièmement : encore heureux, si pijul décidait tout seul quoi faire, il pourrait aboutir à un arbre de sources qui ne compile pas…
Non. Cf. point précédent. Ou alors pour mon code de gestion d'utilisateurs, donne-moi le code final automatiquement produit (indice : il est indécidable (ça devrait te plaire comme mot)).
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 !
Non, tu ne les as pas compris. Cf. argument précédent : si deux patchs ne se recouvrent pas "géographiquement" ils sont interchangeables.
Ça va faire très argument d'autorité, mais je bosse avec git depuis bientôt 10 ans, et il semble que je sois gâté par la nature sur ce point, ou que j'ai la même topologie neuronale que Linus, car même mes collègues très intelligents se tournent vers moi quand il faut "un guru git" et je suis extrêmement à l'aise avec. Ça n'est pas un argument pro-git (au contraire, à la limite…), c'est pour dire que si tu veux attaquer git avec des exemples, muscle ton jeu, car sortir des contre-vérités évidentes comme ça ne t'aide pas.
La problématique de fiabiliser la production logicielle m'intéresse réellement. C'est le fait de pouvoir y prendre une bonne part dans ma nouvelle boite, qui m'a fait accepter ce poste. Je suis un fan de git, mais si concrètement pijul apporte de vraies avancées, j'en parlerai au boulot ! Néanmoins, pour l'instant je vois :
Certaines par toi que je viens de pointer, certaines par un des auteurs de pijul même, pointées par d'autres ailleurs dans les commentaires.
OK c'est super que pijul ait une théorie lui permettant de toujours produire un résultat déterministe au lieu de lâcher l'affaire ou de diverger; sauf que tu oublies un petit détail : je m'en fous que pijul ait une théorie lui garantissant de toujours être un endomorphisme de "l'ensemble des combinaisons de chaines de caractère" (les "sources") et donc de ne jamais être indéterminé (aucun résultat) ou une distribution (plusieurs "ordonnées" pour une abscisse), car dans le monde réel nous ne travaillons pas sur "l'ensemble des combinaisons de chaines de caractère" mais "l'ensemble des combinaisons de chaines de caractère ayant un sens" (que ce soit un sens du point de vue du compilateur, ou pire du point de vue de leur but métier, c'est-à-dire qu'il faut qu'elles compilent mais en plus qu'elles fassent ce qu'on voulait exprimer).
Et ça pijul ne le garantit évidemment pas, puisqu'il ne parle pas tous les langages de programmation / de balisage / les langues du monde (si on décide de versionner un manuscrit par exemple), et n'a encore moins conscience des specs du code. Je pense l'avoir illustré par mon exemple de fonction de récupération d'utilisateur. Je ne changerai pas d'avis tant qu'on ne m'aura pas prouvé que pijul résout le problème.
Indice avant que tu t'échines pour rien : l'auteur de pijul a dit qu'il fera comme git, qu'il s'arrêtera sur un conflit (merde c'est pas un endomorphisme défini sur tout l'ensemble des "trucs à versionner" alors ?? :-( ), alors c'est pas avec tes petits graphiques sans contenu que tu y arriveras.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par kantien . Évalué à 4.
Je ne comprends absolument pas le sens de cette partie de ton commentaire. On va reprendre l'historique de nos échanges, ce sera plus clair.
Tu as commencé par écrire
ce à quoi je te réponds
tu réagis ensuite par
et je réponds à cela par
À moins que j'ai complètement la berlue ou que j'ai perdu la raison, c'est bien toi qui as parlé de graphe orienté et je ne vois toujours pas en quoi c'était en termes profanes. Que ta boulangère ne sache pas ce qu'est un graphe orienté, personne ne l'a nié, mais là n'était pas la question. Le fait est que pijul aussi gère un graphe orienté d'états successifs, la différence entre les deux outils ne se situe pas à ce niveau là. Que ce graphe soit une catégorie (et c'est peut être cette notion que tu appelais « concept mathématique relativement avancé »), on s'en fout un peu dans le fond, raison pour laquelle j'ai ensuite écrit :
Il va de soi que par mon tout le monde, j'entendais tout programmeur (ce qui exclus ta boulangère, à moins qu'elle ne programme dans ses moments de loisir), c'est-à-dire les seules personnes susceptibles de discuter des entrailles de ce genre d'outils.
Reprenons la distinction entre pijul et git.
Là je ne comprends pas trop non plus. Les deux graphes en question expose la même situation que celle dans le lien du tout premier commentaire de pamaury, et à ce moment tu ne semblais pas avoir compris. Pourtant ils disent la même chose. En revanche tu continues avec :
sauf que ton exemple ne correspond pas du tout à cette situation. Ton code illustre deux branches qui divergent et qui rentrent en conflit quand on les fusionne : ce n'est pas du tout ce qu'illustrent les graphes colorés. Ils illustrent deux stratégies qui ne génèrent pas nécessairement de conflit mais avec deux résultats différents pour git et un seul avec pijul. Ainsi, lorsque tu écris :
tu n'as toujours pas compris. Non, dans un cas réel il n'y a pas nécessairement conflit et pijul arrivera bien toujours dans le même état Q quelque soit le chemin pris dans le graphe, c'est-à-dire quelque soit la stratégie utilisée. Assurément, bien que git fusionne sans se plaindre (il n'y a pas de conflit) le code ne compilera pas, mais cela demandera un travail supplémentaire au développeur ou alors il faudra utiliser un workflow conditionné par l'outil. On est là dans le même genre de problématiques qu'entre typage statique ou typage dynamique : pour éviter les runtime error (un code qui ne compile pas après fusion) il faut prendre ses précautions.
Pour la suite :
Si ! cette propriété est automatiquement satisfaite par construction dans pijul. Cf. mon point précèdent. Ton exemple de code de gestion d'utilisateur est hors propos pour parler de cette spécificité de pijul.
De plus, personne, mais alors vraiment personne, n'a prétendu qu'il existait un outil de fusion magique qui résout les conflits tout seul. Là n'est pas la question, ni le problème que cherche à résoudre pijul.
Pour la question des patchs indépendants :
La question n'était pas là mais celle-ci : dans un tel cas, git crée-t-il automatiquement deux branches distinctes dans son graphe d'états pour se faciliter le travail ?
Je veux bien te croire, mais tu ne sembles pas disposer à faire l'effort d'essayer de comprendre ce que les autres écrivent. Dans un autre journal où j'essayais d'illustrer l'analogie stricte entre typage statique et démonstration de théorèmes, tu m'avais également lu de travers. À moins que tu ne considères pas le typage statique comme relevant de la problématique de fiabiliser la production de logicielle. Une partie du système qui gère les lignes automatiques du métro parisien a été développé selon une telle méthodologie, et il est difficile de remettre en cause pas les faits sa fiabilité.
Si git te satisfait pleinement, pourquoi changer d'outil ? Pijul offre certes des avancés (ne serait-ce que celle de fournir une spécification à la notion de fusion), mais pas celles qui semblent correspondre à tes attentes :
Pijul ne le résout évidemment pas, personne n'a jamais dit le contraire, il n'y a rien à prouver. Tu l'as dit toi même : aucun logiciel ne viendra jamais le résoudre, le problème est indécidable, c'est même pire, il est informulable (le problème n'est pas l'absence de procédure de décision, mais qu'on ne peut même pas l'exprimer formellement).
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 3.
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.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par El Titi . Évalué à 3.
Il parle de dissonance cognitive, de mon coté je vois un autre biais dans son raisonnement:un homme de paille. Il construit un raisonnement dans lequel git comm pijul sont indecidabele, donc git est aussi bon que Pijul, et les autres cas OSEF dasn la vrai vie.
Du grand art !
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 4.
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
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 ?
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par kantien . Évalué à 2.
Il est tout de même possible de réordonner manuellement l'historique à coup de
git rebase -i. Après contrairement à pijul, il faut le faire à main, rien ne garantie que les commits que l'on réordonne commutent, on peut supprimer un commit sans supprimer la clôture transitive de ses dépendances futures… C'est totalement casse-gueule, il faut être un git guru et avoir une connaissance précise de l'historique.Je t'accorde que c'est une conception assez étrange de l'informatique que de ne pas automatiser ce qui peut l'être, et cela sans filet de sécurité.
À sa décharge, je ne pense pas que c'était du mépris vis à vis de sa boulangère, mais seulement qu'elle n'emploie pas le terme de « graphe orienté » pour décrire son déplacement dans des rues. Après je suis bien d'accord qu'elle en a une expérience directe et quotidienne, et que les raisonnements qu'elle effectue sont identiques à ceux que l'on fait en théorie des graphes. L'exemple historique typique sur le sujet est celui de Socrate faisant démontrer le théorème de Pythagore (sous la forme du problème de la duplication du carré) à un jeune esclave dans le dialogue du Ménon, en lui posant seulement des questions, laissant son auditeur y répondre tout seul, et introduisant seulement à la fin de leur échange le terme technique de diagonale du carré. L'art du mathématicien étant, comme le disait Poincaré, de donner le même à nom des choses qui se distinguent par leur contenu mais sont identiques dans leur forme.
Ce qui est conforme à ce que doit faire toute bonne théorie : la théorie n'est que l'universelle pratique mise en principes.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Message de service: tu dois avoir un message urgent dans ta boîte aux lettres associée à ton compte.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Michaël (site web personnel) . Évalué à 2. Dernière modification le 19 septembre 2017 à 23:50.
Merci pour ces références! Au delà de l'aspect esthétique – dont l'expérience montre en général qu'un problème mieux représenté est également mieux compris et les traitements afférents sont plus faciles – il faut se souvenir que GIT ne sauvegarde pas les résolutions de conflit – à moins d'un paramétrage spécial. C'est gênant lorsqu'on travaille sur l'historique, par exemple, dans les rebase complexes où figurent des résolutions de conflit, que git demande de résoudre à nouveau. Par ricochet cela rend inutilement pénible la fusion de deux dépôts GIT, puisque l'approche bébête consistant à importer (
fetch) une deuxième historiqueCOMMIT-0 … { historique complexe … } COMMIT-1puis à faire uncherry-pickdeCOMMIT-0sur la tête de la vieille historique puis unrebasedeCOMMIT-0..COMMIT-1ne marche pas. Le problème peut être résolu grâce au filter tree mais c'est bien plus compliqué à mettre en œuvre et incroyablement lent. (J'en ai récemment fait un de 12h sur une historique assez modeste, 4 ans et équipe de 4 à 8 personnes.)[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Albert_ . Évalué à 2.
Dans un rebase je suis d'accord dans un merge je le suis beaucoup moins.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Michaël (site web personnel) . Évalué à 4. Dernière modification le 20 septembre 2017 à 10:03.
Qu'est-ce que tu veux dire exactement?
Ce dont je parle est la situation suivante: partant de la branche
maintenance/v2.0deux branchesfix/bug-1etfix/bug-2sont “mergées“ vers une nouvelle branchepatchset/v2.0.1elle aussi issue demaintenance/v2.0, ce qui donne lieu à une résolution de conflit. Si maintenant on décide que le “patchset”patchset/v2.0.1ne soit finalement pas ajouté àmaintenace/v2.0mais seulement àmasteralors on a envie de “rebaser” la branchemaintenance/v2.0..patchset/v2.0.1surmasteret cela ne marche pas facilement parceque dans sa version la plus simple l'appeldemande de rerésoudre les conflits résultant du “merge” de
fix/bug-1etfix/bug-2. C'est dans ce sens que “git ne sauvegarde pas les résolutions de conflit”. Ce comportement peut dépendre de la version (2.8.4 ici) et de la configuration (cf.rerere) mais c'est dans certains cas le fonctionnement normal de git.[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Albert_ . Évalué à 3.
Ah d'accord je vois ce que tu veux dire. Ce que je voulais dire c'est quand tu fais un merge (et pas un rebase) si tu as des conflits ils sont gardes dans un commit specifique contrairement a rebase ou tu les resouts un par un dans une branche detache et tu n'auras plus de trace des resolutions une fois le rebase fini (enfin il me semble).
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par groumly . Évalué à 2.
C’est un peu à côté de la plaque, mais si t’as vraiement autant de branches que ça, le problème c’est pas l’algorithme de merge ou le fait que rebase écrase les merge conflict…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 10.
Pas vraiment. Par exemple, dans un projet de petite taille comme Pijul, qui a été essentiellement écrit à deux, on travaillait tous les deux sur quarante trucs à la fois.
On a utilisé Darcs, et presque chaque patch avait une nouvelle fonctionnalité ou une nouvelle résolution de bug. Pour faire la même chose avec Git, il nous aurait effectivement fallu plusieurs dizaines de branches. Pire, il aurait fallu se souvenir, en même temps qu'on démouchait du code, de la branche courante et des interactions potentielles avec toutes les autres branches.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Albert_ . Évalué à 3.
Alors la respect. Bosser sur l'equivalent de 40 branches en meme temps je n'ose meme pas imaginer et en fait je ne suis meme pas sur que mon cerveau supporte la charge!
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . Évalué à 9.
Bon, il y avait plein de trucs à faire. Et on apprenait Rust en même temps, ce qui est une expérience assez agréable.
Mais je ne suis pas non plus en train de dire que mon cerveau a totalement supporté la charge ;-)
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Albert_ . Évalué à 2.
Bon quelqu'un peut changer les notes par defaut de pmeunier?
C'est un peu ridicule que l'auteur du logiciel ait ses messages caches uniquement parceque son compte est jeune.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 5.
C'est la dure vie du commentateur de LinuxFr mais compte tenu des notes à ses derniers commentaires, cela devrait changer assez vite :)
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par freem . Évalué à 3.
tu peux aussi naviguer a -42, si ca te gene tant.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Dinosaure (site web personnel) . Évalué à 1.
Cf.
git rerere:)[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par Michaël (site web personnel) . Évalué à 2.
Oui, je le mentionne dans le commentaire auquel tu réponds. Le seul problème est que comme c'est une fonction d'utilisation relativement rare, on ne la découvre qu'a posteriori, lorsque c'est trop tard. :)
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par kantien . Évalué à 2.
Au fond, je n'en doute pas vraiment. J'ai présenté la chose ainsi1 pour ne pas heurter certaines sensibilités. Si je devait faire un parallèle, le fondement du système me fait penser au passage du paradigme ptoléméen avec ces épicycles au paradigme héliocentrique de Copernic et Kepler.
en fait, j'ai eu ce week-end des idées similaires pour essayer de fonder les Modular Implicits en OCaml; mais sur cette dernière question il faut que j'approfondisse encore mes pressentiments pour être sûr que ce n'est pas un cul de sac. ↩
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
# Is it possible to refer to a specific version? Yes. Maybe. In practice, no.
Posté par freem . Évalué à 10.
Oui, c'est possible, enfin, on sait pas trop mais ça doit bien pouvoir se faire, on à même de superbes idées sur comment faire…
Du coup, on fait comment pour contribuer à un logiciel?
Parce que sans moyen actuel de se référer à une version (que ce soit des numéros de révisions comme SVN ou des hash de commit comme git, peu importe, tant qu'on peut différencier les versions) je vois très mal comment discuter de problèmes (j'utilise un soft, je vois un bug ou une fonctionnalité qui serait intéressante, comment je fais pour savoir que j'ai bien la dernière version et que donc mon problème est encore d'actualité?)…
Pour moi, en tout cas, c'est pas un frein, mais bien un point bloquant.
[^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.
Posté par pmeunier . Évalué à 10.
Non, en l'occurrence c'est plutôt "c'est déjà implémenté dans la bibliothèque, c'est rétro-compatible, mais il faut écrire plein de commandes supplémentaires, ce qui implique de bike-shedder beaucoup, et il y a plein de trucs d'ingénierie plus urgents à résoudre".
Exemples de trucs d'ingénierie :
Et il y a des trucs qui demandent des algorithmes plus durs à écrire, comme par exemple l'affichage des patchs déjà recordés dans le terminal, ou l'affichage plus complet des contextes des patchs sur nest.pijul.com.
[^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.
Posté par gouttegd . Évalué à 7.
Et déléguer tout ça à OpenSSH (comme le fait Git, sous GNU/Linux du moins), ce n’était pas envisageable ?
Un programme qui vient avec sa propre implémentation de SSH, c’est un programme ui dans 99% des cas :
~/.ssh/config,ProxyCommandpar exemple),Rien que le dernier point rend un tel programme inutilisable pour moi, ma clef privée étant stockée sur une carte à puce rendant l’utilisation d’un agent indispensable.
J’admets ne pas lire le Rust couramment, mais je ne vois rien dans le code de
thrusshou depijullui-même qui me laisse penser que le protocole SSH-Agent est pris en charge.[^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.
Posté par pmeunier . Évalué à 10.
Excellente question ! D'autant que je suis moi-même un utilisateur de Yubikey, et j'ai une clef SSH cryptée avec.
En fait j'aurais même pu déléguer à libssh et/ou libssh2. Il y a eu plusieurs raisons à ce choix :
OpenSSH ne marche pas bien sous Windows. Des projets avec peu de moyens d'ingénierie, comme par exemple Darcs, sont empêtrés là-dedans depuis des années.
J'avais https://nest.pijul.com en tête quand j'ai commencé à écrire Thrussh. Maintenir une version d'OpenSSH à jour et sécurisée sur un serveur distant était une tâche au-dessus de mes compétences en administration système, et du temps que nous pouvions passer à l'administration. En fait, j'ai commencé par écrire un binding Rust vers la partie serveur de libssh. Au bout de 5000 lignes de bindings, de cheveux arrachés à lire leur code C (la doc n'existe presque pas), et toujours pas de serveur en vue, j'ai craqué.
Bien sûr, je pourrais maintenir une version de Pijul qui parle à OpenSSH, et une autre qui parle au client de Thrussh. Ou même ne pas maintenir le client, et seulement un serveur. Mais écrire/maintenir un client et un serveur est moins cher que l'un des deux seulement, parce qu'on peut tester plus facilement avec des tests d'intégration. Comme je n'ai pas un temps infini, c'est pratique. En plus, le serveur de Thrussh n'a pas beaucoup d'utilisateurs (il est vraiment jeune), donc les rapports de bugs sont plutôt sur le client, et les réparations sont souvent communes avec le serveur.
On finira par lire
~/.ssh/configet prendre en compte les agents, mais ce n'est pas du tout le rôle de Thrussh de faire ça. L'idée de Thrussh (contrairement au monolithique OpenSSH) est d'offrir une petite bibliothèque facile à utiliser et à auditer, et qui contient tout le protocole SSH 2. J'ai commencé à implémenter les agents dans une autre bibliothèque, et j'ai été pour l'instant bloqué par des choix contradictoires entre *ring* (une bibliothèque de crypto en Rust) et le protocole. Mais ça viendra !Il y a eu un gros effort sur la crypto en Rust. Des bibliothèques comme *ring* ont commencé à tourner un petit peu avant Thrussh, et c'était l'occasion de contribuer à faire évoluer l'écosystème. Le problème des agents met en valeur un cas que *ring* n'avait pas prévu, par exemple.
Pareil pour Mio et Tokio, deux excellents projets pour les entrées-sorties asynchrones en Rust. Mio est arrivé avant Thrussh, et Tokio un peu après (mais maintentant Thrussh ne parle plus qu'à Tokio, Mio est la couche du dessous).
[^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.
Posté par Sufflope (site web personnel) . Évalué à 6.
apt install openssh-serverou équivalent c'était trop compliqué, donc pour faire plus simple je réimplémente SSH ? Si la page Wikipedia pour NIH avait besoin d'une illustration, elle est servie.[^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.
Posté par pmeunier . Évalué à 9.
Ce n'est pas du tout ce que j'ai écrit dans mon commentaire. D'abord il y a d'autres raisons que j'ai expliquées, par exemple au sujet de Windows. Était-ce "trop compliqué" de lire ces lignes dans mon commentaire avant de répondre n'importe quoi ?
Ensuite, le cas précis de mon serveur est particulier : je veux pouvoir laisser n'importe qui envoyer des patchs, ou enregistrer une nouvelle clef publique, par SSH. Je veux aussi que mon serveur tourne vite. En fait je veux qu'il tourne super vite. Et d'ailleurs ses utilisateurs le remarquent ici ou là.
Pour ça j'ai besoin de plusieurs choses :
Un contrôle total sur les interactions entre le client et le serveur, alors qu'OpenSSH ne me permet que de lancer un exécutable à distance. Je veux aussi pouvoir enregistrer les clefs de l'utilisateur s'il m'a donné un password correct, par exemple, et s'il me confirme qu'il veut enregistrer sa clef. OpenSSH ne me permettrait de faire ça qu'à grands renforts de scripts pour parser les logs, qu'il serait difficile à intégrer au reste du service, à moins de hacks qui finiraient par casser rapidement.
Une connexion avec une base de données. Les clefs publiques des utilisateurs ne sont pas stockées dans un fichier, mais dans une base de données PostgreSQL.
Une interdiction absolue de faire quoi que ce soit d'autre que les trucs autorisés. Je ne sais pas sécuriser ce type de trucs, il y a trop de pièges qu'on peut envoyer dans des arguments de shell, et ça nécessite une équipe pour veiller dessus, quand on veut faire les choses bien. Pareil pour les mécanismes d'authentification : OpenSSH peut certainement utiliser des tas de modules pam, mais je ne sais pas faire, et les experts de ça que je connais y ont passé dans leur vie environ 100 fois le temps-homme que Thrussh, et il reste encore sans doute plein de failles dans leurs configurations.
Je veux une performance de ouf sur mon serveur. Fork + exec de la part d'OpenSSH serait déjà beaucoup, et je ne parle pas du changement de contexte entre process à chaque connexion.
Maintenant j'ai tout ça à la fois, avec en prime des trucs de sécurité intéressants fournis par l'IO asynchrone, comme des délais avant
accept()de plus en plus grands quand les connexions n'aboutissent pas à une authentification réussie.Avant de commencer j'avais un peu discuté avec un ingénieur de chez SSH (l'entreprise finlandaise) quand j'habitais à Helsinki, ce qui a un peu achevé de me convaincre.
[^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.
Posté par foobarbazz . Évalué à 5.
Tu es nouveau ici :-p raconter n'importe quoi c'est juste une manière de dire bonjour :-)
[^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.
Posté par Sufflope (site web personnel) . Évalué à 2. Dernière modification le 30 septembre 2017 à 02:00.
Non tu n'as jamais écrit ça, ostensiblement. 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 qui fournit une config maintenue et sécurisée. 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…
[^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.
Posté par pmeunier . Évalué à 7.
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 :
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.
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.
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.
[^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.
Posté par freem . Évalué à 2.
Du coup, complètement hors sujet, mais PAM, c'est quoi, en vrai, l'intérêt de ce truc?
J'ai vaguement compris que c'est censé être une lib pour gérer la sécurité, mais ça m'a toujours eu l'air vachement complexe et lourd, un peu trop peut-être pour être vraiment sûr? Il y a des gens qui utilisent vraiment ce truc? Je veux dire, volontairement, en dehors du fait que ce soit installé par défaut sur la distribution… j'ai cru comprendre que certaines (slackware, pour ne pas la nommer) s'abstenaient de l'utiliser?
Bon, tu ne sais peut-être pas, mais vu que tu en parles je me suis dit que tu avais essayé de comprendre le fonctionnement de ce machin :)
[^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.
Posté par pmeunier . Évalué à 1.
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.
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.
# Preuves ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Alors :
De quoi parle-t-on au juste ici pour les preuves ? Démonstration mathématique basée sur les théorèmes précédant ou preuves de bon fonctionnement du programme ?
Il ne semble pas qu'il y ait, en Rust, moyen de prouver le bon fonctionnement du programme.
Si ?
[^] # Re: Preuves ?
Posté par Benoît Laurent (site web personnel) . Évalué à 1.
J'ai lié dans le journal ce commentaire
Il y aura publication d'ici la fin d'année. Donc on verra bien.
Est-ce que l'algo seul peut être prouvé sans que le programme complet soit prouvé ? Je ne sais pas.
Côté Rust il y a quelqu'un qui travaille dessus :
https://www.ralfj.de/blog/2017/07/08/rustbelt.html
[^] # Re: Preuves ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Alors, tout dépend de la techno utilisée.
De ma petite expérience en Spark, on peut prouver des morceaux du programme en ne marquant que certaines unités de compilation comme étant en Spark.
Typiquement, les entrées/sorties sont exclues du sous-ensemble vérifiable par Spark.
Mais, il faut bien voir qu'il faut quand même écrire les annotations Spark dans le code Ada pour pouvoir prouver quoique ce soit et ça, c'est pas forcément toujours très aisé.
Après, j'ai aussi vu un Coq2Rust permettant donc de créer son programme Rust à partir d'un programme Coq mais j'avoue ne pas avoir regardé plus que ça.
[^] # Re: Preuves ?
Posté par pmeunier . Évalué à 8.
Salut ! Je suis un des auteurs de Pijul.
Ce n'est pas non plus ce qu'on demande aux autres (dont Git et Mercurial), mais j'avoue qu'on a hésité entre Rust et Idris à un moment, entre autres pour cette raison.
Si les algos sont prouvés, c'est déjà bien mieux que Git par exemple (en plus, quelle spécification donner à Git, vu qu'il fait parfois des bêtises ?).
Je veux bien aider des gens à le prouver, par contre, mais il faut commencer par les fondations (qui nous ont pris plus de temps que le projet lui-même). Exemples :
Sanakirja, un dictionnaire clef-valeur à la LMDB, mais avec des tables forkables efficacement (la complexité est compliquée à expliquer, je l'ai fait là). Le code n'est pas très gros, mais les algos sont un peu tordus : il y a des skiplists et des B trees, mais tout est transactionnel, y compris la gestion de la mémoire. Exemple, si on débranche la machine au milieu d'une transaction qui a alloué plein de blocs dans le fichier, quand on redémarrera, la base de données sera retrouvée exactement dans l'état initial (et Sanakirja n'a rien de spécial à faire, il n'y a pas besoin de journal, c'est seulement que le commit de transaction est atomique).
Thrussh, une bibliothèque SSH asynchrone.
[^] # Re: Preuves ?
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Donc en fait tu ne bosses pas sur projet qui mérite une dépêche, mais plusieurs.
Je me sens nul…
[^] # Re: Preuves ?
Posté par pmeunier . Évalué à 4.
C'est pas trop l'objectif.
Au contraire, viens coder avec nous, il y a du boulot !
[^] # Re: Preuves ?
Posté par GuieA_7 (site web personnel) . Évalué à 2.
C'était une façon détournée de dire "bravo" et "j'ai hâte de lire ces dépêches". :)
(en vrai je code déjà du libre à plein temps ; ça vaut ce que ça vaut, mais je pourrai difficilement faire plus)
[^] # Re: Preuves ?
Posté par Fulgrim . Évalué à 1.
Je pense qu'il ne parle que de la preuve des théorèmes et de l'algo, pas du programme.
# Transport via SSH
Posté par flan (site web personnel) . Évalué à 2.
J'ai un peu regardé le projet, et j'ai l'impression que le seul transport est via SSH. Est-ce correct ?
Pourquoi ce choix ? Je trouverais dommage d'abandonner HTTP (ou websocket si on veut un mode connecté).
Enfin, peut-être que je me trompe complètement :)
[^] # Re: Transport via SSH
Posté par pmeunier . Évalué à 2.
Très bonne remarque. Note que nest.pijul.com, notre service d'hébergement, a évidemment une partie HTTP. Il contient aussi un petit serveur SSH maison qui ne sert qu'à ça. Il est impossible d'ouvrir une session pour "faire de l'administration" dessus, non pas parce qu'il est "très bien sécurisé", mais parce qu'il ne gère pas un paquet de trucs, entre autres les sessions.
La bibliothèque elle même saurait les gérer, mais le serveur ne contient pas le handler qui permettrait d'ouvrir un pseudo-terminal ou une session.
Note d'autre part que SSH est un protocole bien plus général que ce qu'on lui fait souvent faire : il a deux ou trois commandes pour ouvrir des sessions et renvoyer des ports TCP, mais il sait aussi envoyer des données arbitraires sans avoir besoin d'une session, d'un shell ou d'un programme autre que le client et le serveur.
À la dernière RustFest, j'avais par exemple live-codé un prototype de communication entre microservices.
Pour répondre à ton commentaire, depuis Pijul, on peut cloner ou puller depuis HTTP, mais pusher seulement par SSH.
On aura peut-être des pushs par HTTP dans le futur (et on accepte très volontiers une contribution là-dessus, même si ce n'est "que" du design), mais il y a plusieurs inconvénients aujourd'hui au niveau de l'expérience utilisateur :
J'ai du mal à voir un cas de figure précis où on voudrait ça. Si tu as une machine dans le cloud par exemple, d'où viendrait le serveur HTTP capable de gérer ça ? Et pourquoi avoir besoin d'une authentification/proxy très sophistiquée ? Pourquoi SSH ne serait pas suffisant ? Faire de l'UX sans cas un peu précis, c'est compliqué. Mais je suis ouvert à la discussion là-dessus.
S'authentifier en HTTP est compliqué, et nous n'avons pas encore imaginé de manière de rendre ça fluide en ligne de commande (c'est quand même le principal objectif du projet). Dans un navigateur, il y a plein de manières de s'authentifier : SSO, OAuth, Mots de passe, Yubikeys, pseudo-2-factor avec un téléphone, gestionnaires de mots de passe… Comment on fait ça en ligne de commande ?
[^] # Re: Transport via SSH
Posté par claudex . Évalué à 3.
Tu peux déjà avoir une infra qui toute la chaine d'authentification en place pour HTTP (LDAP, Kerberos, TLS client…) . Cela peut être plus simple de réutiliser cela avec un reverse proxy que de devoir refaire la même configuration pour SSH et ne pas oublier de la modifier là en plus que les autres.
On arrive bien à faire du TLS client, du Kerberos, du 2factor, du Yubikey en SSH en ligne de commande. Pourquoi on n'y arriverait pas en HTTP ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Transport via SSH
Posté par pmeunier . Évalué à 4.
Oups, je me rends compte que j'avais oublié autre chose : les performances de HTTP <= 1.1 n'égalent pas SSH, qui a des paquets binaires, le multiplexage de flux, et les connexions ouvertes longtemps (websocket est un peu un hack, quand même).
Avec HTTP 2, on pourra comparer.
Bonne remarque. Mais sauf si j'ai loupé un truc, la question n'est donc pas "je voudrais bien pousser en HTTP", mais plutôt "je voudrais bien que Pijul gère les cent-cinquante standards différents d'authentification en HTTP".
Ou alors il doit y avoir un moyen générique de faire faire ça à un proxy ? Je serais bien content d'avoir une référence à lire sur le sujet.
On pourrait certes y arriver, mais ce n'est quand même pas (à mon avis) le même degré de complexité. SSH est un seul protocole, qui comporte trois façons de s'authentifier (password, public key, none), plus une extension très utilisée (keyboard-interactive, utilisée par OpenSSH pour les mots de passe à la place de password).
Tout est spécifié de manière extrêmement précise dans une seule RFC (plus l'extension dans une autre RFC), et on a déjà une bonne sécurité une fois qu'on a ça. C'est tellement facile à implémenter que les implémentations les plus utilisées ont des failles de sécurité qui se comptent sur le doigts de la main, alors qu'OpenSSL a un très gros problème par an, et plusieurs petits chaque mois.
[^] # Re: Transport via SSH
Posté par flan (site web personnel) . Évalué à 2.
Ah non, il n'y a pas forcément besoin de gérer toutes les méthodes d'authentification HTTP… qui ne sont d'ailleurs pas forcément si nombreuses que ça côté client (beaucoup sont faites par le site lui-même, pas en HTTP : si tu regardes les pages web, le code renvoyé est toujours 200 et non 401/403). Mais les principales pourraient l'être.
Après, tu peux effectivement faire confiance au proxy (apache ou nginx), qui va (par exemple) ajouter un header HTTP (souvent REMOTE_USER) contenant le nom d'utilisateur. Le serveur applicatif n'a plus qu'à utiliser ce header HTTP, et c'est gagné.
Au passage, SSH connaît d'autres méthodes que les trois que tu cites (notamment Kerberos/GSSAPI) :)
[^] # Re: Transport via SSH
Posté par claudex . Évalué à 3.
Il me semble que la convention, c'est de définir le header REMOTE_USER.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Transport via SSH
Posté par flan (site web personnel) . Évalué à 2.
je ne connais pas bien le cloud, mais je n'ai jamais eu de problème à installer un git avec authentification Kerberos en HTTP (y compris en bidouillant gitlab pour le faire sur la version open-source) sur des machines à ma disposition. Ensuite, même si SSH permet de faire plein de choses, je ne suis pas sûr qu'il soit aussi souple que HTTP (ce n'est pas un reproche, ils n'ont pas été conçu pour faire la même chose) :
Je connais essentiellement Kerberos comme authentification (c'est du du SSO), et git sait s'en servir de façon transparente en HTTP (le serveur lui réclame du Kerberos, le client se contente de lui en fournir). J'ai également une Yubikey, mais elle me permet de récupérer mon ticket Kerberos au login, du coup je ne sais pas si on peut faire de l'authent' SSL avec git de façon simple.
En termes d'interface, je ne vois pas trop en quoi ça serait différent par rapport au SSH. cURL propose plein d'authentifications, si tu veux regarder :)
[^] # Re: Transport via SSH
Posté par pmeunier . Évalué à 1.
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.
[^] # Re: Transport via SSH
Posté par freem . Évalué à 3.
Certains de tes arguments sont inversables me semble, voire errones:
• pas besoin d'ouvrir de nouveaux ports si le 22 est deja ouvert
• ssh force l'authentification, mais n'impose pas d'authentification forte. Utiliser une cle sans pass, ca me semble proche de ce que fait https: on pourrait considerer ca comme un simple certificat, avec non pas le but d'authentifier le serveur (ce cote etant automatique avec ssh me semble) mais l'utilisateur, certes. Enfin, d'un autre cote mieux vaut ne pas laisser n'importe qui pousser un patch.
• openssh n'est pas adapte a plusieurs instances. Peut-etre (jamais essaye, ca serait amusant de verifier) mais on s'en fout: pijul implemente un autre serveur ssh, lui pourra tres bien l'etre.
De maniere generale, j'ai l'impression que tu confonds le protocole SSH et le serveur OpenSSH. Et meme si un certain nombre de tes arguments sont valides (moins d'usages actuels pour ssh que http, donc moins de code) je trouve quand meme ssh plus pertinent des lors que l'on a besoin de sessions: les "cookies du http", ca fait quand meme gros hack, avec re-nego tcp a chaque transfert de fichier en plus.
[^] # Re: Transport via SSH
Posté par pmeunier . Évalué à 1.
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
cryptsetupcomme 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.
[^] # Re: Transport via SSH
Posté par claudex . Évalué à 3.
Non, il chiffre au dessus du FS. Cela veut dire qu'un utilisateur du système (par exemple un navigateur ou un client mail troué) qui a accès au fichier ne pourra lire que la version chiffré.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Transport via SSH
Posté par pmeunier . Évalué à 1.
Oui, c'est vrai. Apparemment j'ai oublié comment était la vie avant l'administration système à distance ;-)
[^] # Re: Transport via SSH
Posté par flan (site web personnel) . Évalué à 2.
J'ai l'impression que je me suis mal exprimé sur Kerberos/GSSAPI ; c'est du SSO qui n'a rien à voir avec HTTP (enfin, autant que le concept de login/mot de passe).
Quand je me connecte à ma session (Windows/Linux/macOS), que ce soit par carte à puce/Yubikey ou avec un mot de passe, mon ordinateur envoie tout ça au serveur Kerberos de mon employeur qui lui renvoie en échange un ticket valable une journée (on peut également obtenir un ticket n'importe quand avec kinit, après s'être connecté en local sur la session). L'ordinateur ouvre alors la session et garde le ticket pour lui. Ensuite, quand je me connecte à un service quelconque (serveur web, mail, NFS, SSH, imprimante, Jabber, …), mon ordinateur va transmettre le ticket au service qui me reconnaîtra automatiquement, sans que j'ai besoin de rentrer le moindre login ou mot de passe. Bon, en vrai, c'est un chouia plus compliqué, mais ça reste vrai dans les grandes lignes.
Du coup, il n'y a aucun hack à utiliser une authentification Kerberos sur HTTP ou sur SSH (en cherchant des cookies dans le navigateur).
[^] # Re: Transport via SSH
Posté par flan (site web personnel) . Évalué à 2.
mais si tu respectes certaines bonnes pratiques, ton réseau d'administration est différent de ton réseau de développement, donc ton port 22 n'est pas accessible aux développeurs. Au contraire, 443 a de fortes chances d'être accessible sur le réseau des utilisateurs.
je ne comprends vraiment pas ce que tu veux dire ; en quoi utiliser une clef sans mot de passe est proche de ce que fait HTTPS ? Le fonctionnement de ces deux protocoles est fondamentalement différent :
oui, mais dans ce cas, soit tu acceptes de remplacer du code éprouvé (OpenSSH) par du code très jeune pour l'administration, soit tu as deux services SSH qui tournent sur la même machine (cette option étant de toute façon obligatoire si tu respectes la séparation entre réseau d'administration et réseau de dév.).
je ne vois pas pourquoi tu parles de cookies HTTP, et en quoi ils sont un hack. En tout cas, quand tu fais du git+http, tu n'as absolument pas besoin de cookies…
[^] # Re: Transport via SSH
Posté par freem . Évalué à 3.
PS desole pour le pate du point 1, je n'arrive pas a formater quand j'utilise les * :/
# suggestions
Posté par Albert_ . Évalué à 5.
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).
C'est LA condition sine qua non.
Git a une tel base que sans cela personne ne voudra l'essayer et donc l'adopter.
Git le fait avec git-svn (Mercurial le fait avec git je crois).
Le probleme c'est que je ne suis pas sur que cela soit faisable vu que vous utilisez des concepts differents. C'est a vous de voir mais sans cela je suis desole de vous dire mais pijul restera un projet academic rigolo et sympa.
[^] # Re: suggestions
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
J'appuie à fond. Dans toutes les entreprises que j'ai fait, la migration SVN --> Git n'a pu se faire que parce qu'il y avait des outils permettant de basculer les projets déjà existants.
La connaissance libre : https://zestedesavoir.com
[^] # Re: suggestions
Posté par pmeunier . Évalué à 4.
Oui, bien entendu. D'ailleurs on a déjà commencé à écrire ça.
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.
[^] # Re: suggestions
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
On arrive bien à importer du SVN et même du CVS ou du RCS (le système de gestion de versions standardisé par POSIX) dans git. Par contre, le "dans les deux sens" est moins facile, je pense. Je n'ai heureusement pas eu besoin de ce genre de choses pour l'instant, seulement de migrer des projets existants de SVN ou RCS vers git.
[^] # Re: suggestions
Posté par Albert_ . Évalué à 2.
Les concepts en ce qui concerne les patchs sont, me semble, t'il tres similaire.
Pijul, d'apres ce que j'ai compris, amene un truc nouveau sur ce point la.
J'ai fait avec svn dans les deux sens ca fonctionne, par contre c'est LEEEENNNNNTTTTTTTT.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.