Journal Le petite histoire derrière SQLite (une interview de Richard Hipp)

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
49
3
juil.
2021

C'est en anglais The Untold Story of SQLite, l'interview radio est transcrite.
C'est une amusante histoire jamais racontée, une idée qui a séduit tout de suite et qui a valu à Richard Hipp des contrats inattendus pour ajouter peu à peu des trucs cool à SQLite. Imaginez qu'il ne savait même pas quel montant demander pour se faire payer ! il a d'ailleurs demandé un salaire «gigantesque» et c'est peut-être ce qui a mené à leur perte les géants de l'époque : Motorola, AOL, Nokia, …

  • # intro courte

    Posté par  . Évalué à 9.

    Pour conserver une intro courte, je n'ai rien dévoilé de l'interview, mais sachez que c'est étonnant et passionnant. Avec de multiples histoires autour des smartphones, des logiciels sans bugs et de l'art de programmer. Et des projets annexes.

  • # Passionnant

    Posté par  (site web personnel) . Évalué à 10.

    Ça fait plaisir de voir qu'un logiciel aussi utilisé que SQLite a une suite de test de malade, avec couverture à 100% de tout le code et de toutes les branches de code.

    Si seulement tous les logiciels pouvaient être aussi bien testés, on aurait moins de problèmes.

    • [^] # Re: Passionnant

      Posté par  (Mastodon) . Évalué à 10. Dernière modification le 04 juillet 2021 à 10:09.

      C'est vrai.

      Mais SQLite c'est petit (le répertoires src/ fait 6Mo, le répertoire test/ en fait presque 50Mo !), avec un jeu de fonctionnalités (relativement) réduit, et pas d'interface graphique.
      Pour comparaison, PostgreSQL on est plus proche des 80Mo sans les tests. Et pourtant on lit dans l'article que la seule base de donnée que l'auteur de SQLite ne fait pas crasher avec sa batterie de tests SQL c'est PostgreSQL.

      Très philosophie Unix KISS d'ailleurs, et ça fonctionne bien pour ça.

      Et puis déjà ils passent 3 jours et des milliards de tests pour valider une version, pour « quelque chose d'aussi simple ».

      On ne pourrait pas avoir la même chose pour un outil graphique un peu évolué, comme Scribus par exemple, ou pire comme un monstre comme LibreOffice, voire une créature pan-dimensionnelle venue de nos cauchemars ancestraux les plus anciens comme Firefox…

      Mais pour les commandes de base, et plein d'outils CLI standards de nos Linux préférés, s'ils avaient tous la même couverture de tests, et les mêmes contraintes de qualité, on vivrait dans un monde un peu différent :)

      Après, SQLite est utilisé dans des contextes tellement variés, tellement différents les uns des autres, tellement inimaginables a priori par les auteurs, que ça se justifie.
      D'ailleurs, si ça ne se justifiait pas, ça n'existerait pas, tout ces tests.

      • Yth.

      • [^] # Re: Passionnant

        Posté par  (site web personnel) . Évalué à 7.

        Pour info, sur Firefox, on a un coverage de 65% environ:
        https://coverage.moz.tools/

        Il y a plein de nuances et complexités.
        Sur des choses plus simples à tester comme le moteur JS, on est a plus de 85%:
        https://coverage.moz.tools/#revision=42496ca2c712c0c68515d69b8e7b152a932e7985&path=js&view=directory

        • [^] # Re: Passionnant

          Posté par  . Évalué à 3.

          Oui mais ce ne sont pas des tests aussi poussés non ? Richard Hipp a implémenté des tests aux standards de l'aviation, et ces tests sont lancés sur le code assembleur.

          • [^] # Re: Passionnant

            Posté par  . Évalué à 3.

            Il ne référence pas de standard nommé et les derniers échos que j'ai eu sur du code avionique c'est pour parler de la qualité pourrave de Boeing…

            Il parle de couverture MCDC, ce qui signifie en plus de couvrir tous les embranchements qu'il faut couvrir tous les cas des conditions. C'est un peu plus complexe effectivement. Ça reste néanmoins qu'une couverture et ne valide pas que tes tests testent.

            Pour le test binaire j'imagine que c'est utile quand tu ne fais pas confiance au compilateur. Ça n'a de sens que quand tu as un client donné. C'est parce que son client lui donne une chaîne de compilation à utiliser que ça a un intérêt de le faire, sinon quand tu fais du ll tu n'a pas le contrôle du compilateur et de sa configuration. Tu as d'autres solutions pour faire ça comme prouver le compilateur (oui oui ça existe).

            Par contre, il faut aussi voir que ça ne garanti pas l'absence de bug. Les tests unitaires sont importants, mais ils ne se suffisent pas des tests, d'intégration, fonctionnels voir de fuzzing sont toujours nécessaires.

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Passionnant

              Posté par  (site web personnel) . Évalué à 7.

              Il ne référence pas de standard nommé

              Tu as du lire l'interview en diagonal car il me semble qu'il donne un nom explicite: DO-178B. It’s a quality standard for safety-critical aviation products

              Ça reste néanmoins qu'une couverture et ne valide pas que tes tests testent.

              Comment tu fais pour valider que tes tests testent ?

              Les tests unitaires sont importants, mais ils ne se suffisent pas

              Rien ne laisse penser dans l'interview qu'il s'agisse de tests unitaires. Il parle juste de tests en général. Ton commentaire sonne comme si tu voulais expliquer la bonne façon de faire des tests, alors qu'on est justement en train de contempler un des logiciels libres qui est probablement le plus et le mieux testé au monde. Perso, je m'extasie juste sur le qualité et la pugnacité de ce développeur. Je ne pense pas pouvoir lui apprendre quoi que ce soit mais j'ai certainement beaucoup à apprendre de lui.

              • [^] # Re: Passionnant

                Posté par  . Évalué à 5.

                Tu as du lire l'interview en diagonal car il me semble qu'il donne un nom explicite: DO-178B. It’s a quality standard for safety-critical aviation products

                Effectivement je l'ai raté quand on regarde cette norme, il semble chercher à appliquer le critère le plus poussé (la couverture MCDC), mais il y a bien d'autres critères de dans qui me questionne sur comment il a fait :

                • Les activités de développement et de vérification doivent être confiées à des équipes indépendantes. → bon je présume que c'est le client aéronautique qui finance ça
                • Les exigences de bas niveau (ou exigences de conception) doivent être formellement vérifiées. → sur un logiciel déjà existant c'est ultra long/couteux à faire
                • Tout ce qui est spécifié doit être formellement vérifié : la couverture fonctionnelle doit être assurée. Les documents doivent aussi être formellement vérifiés. → je ne suis pas sûr de ce qu'ils entendent par formellement. Je ne sais pas s'il s'agit de pouvoir relier un comportement spécifié à un test où s'il s'agit de vérification formelle au sens de preuve (je présume que c'est le premier)

                Et il y en a d'autres, la couverture MCDC n'est qu'un détail technique et pas le plus important dans ce standard.

                Comment tu fais pour valider que tes tests testent ?

                La méthode la plus connue c'est de faire du test de mutant. Il s'agit de modifier le code et de voir si un test trouve le mutant.

                Je ne vais pas m'étaler sur ce que tu imagine ou non derrière mon commentaire. C'est un sujet qui m'intéresse donc je ne suis pas béa devant, mais je m'interroge de comment on met en place de la qualité et le standard montre bien que les tests ne sont qu'une partie de cela.

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Passionnant

              Posté par  (site web personnel) . Évalué à 4.

              Tout à fait, il faut aussi savoir se représenter ce que signifie une couverture de code à 100%.
              Cela signifie que 100% des lignes ont été parcouru au moins lors de l'exécution des tests. Mais cela ne veut pas dire que les lignes se sont bien comportés, au mieux ça permet d'éviter les crash ou erreurs grossières, mais la validité de la ligne dépend de comment le test a été écrit et de ce qu'il a vérifié.

              Il faut coupler les tests unitaires avec d'autres types de tests comme tu le mentionnes.

              Une couverture de tests à 100% n'est pas forcément pertinent, car l'effort pour atteindre ce 100% peut être considérable au regard de son intérêt d'un point de vue qualité. Un code avec une couverture de code suffisante mais qui a poussé plutôt les tests d'intégration et autres dans leurs retranchement peuvent être bien plus fiables qu'un code testé à 100% avec que des tests unitaires.

              Puis suivant le contexte, atteindre le 100% peut être vraiment difficile.

              • [^] # Re: Passionnant

                Posté par  . Évalué à 3.

                Cela signifie que 100% des lignes ont été parcouru au moins lors de l'exécution des tests.

                Il parle de 100% MCDC, ça va un peu plus loin que la couverture dont tu parle. Pour aller vite si tu as :

                if (a && b || c)

                Tu dois tester que tu rentre dans le cas parce que a et b sont vrai, mais aussi parce que c est vrai.

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Passionnant

              Posté par  . Évalué à 5.

              Les tests unitaires sont importants, mais ils ne se suffisent pas des tests, d'intégration, fonctionnels voir de fuzzing sont toujours nécessaires.

              L'auteur en parle lui même, il mentionne même explicitement l'utilisation d'un fuzzer en plus des tests :

              The 100% MCD tests, that’s called TH3 […] We test on as many different platforms, as many different operating systems as we can, but we also have lots of different test suites that we run, but we’ve got the original TCL tests. We’ve got TH3 . We’ve got the custom fuzzer stuff that are running constantly. We’ve got a thing called SQL logic test.

              • [^] # Re: Passionnant

                Posté par  (site web personnel) . Évalué à 3.

                Je ne parlais pas du cas actuel ici, je n'ai pas encore lu l'interview, je parlais du contexte global où beaucoup de projets mettent en avant cette métrique mais sans recul sur sa signification.

    • [^] # Re: Passionnant

      Posté par  (site web personnel) . Évalué à 10.

      Si seulement tous les logiciels pouvaient être aussi bien testés, on aurait moins de problèmes.

      Pas dur, il suffit de virer tout le code non testé… J'ai bon ?

      • [^] # Re: Passionnant

        Posté par  . Évalué à 2. Dernière modification le 04 juillet 2021 à 14:37.

        +1

        Et aussi, en tant qu'utilisateur, de se retrousser les manches et d'écrire les tests.

        Globalement, ce n'est pas difficile car il n'y a pas besoin de comprendre le code du logiciel en question, seulement de décrire son comportement.

        En pratique, c'est juste très très long. Hipp a mis deux ans à temps plein pour passer de 95% à 100% de couverture.

  • # de la balle

    Posté par  . Évalué à 5.

    Sympa l'interview.

    J'ai toujours trouvé dommage que la version chiffrée ne soit pas open source.

    https://sqlite.org/see/doc/release/www/readme.wiki

  • # Fossil, un gestionnaire de versions du même auteur

    Posté par  . Évalué à 9.

    Richard Hipp est aussi l’auteur de Fossil, un gestionnaire de versions décentralisé étroitement basé sur SQLite pour garantir l’intégrité des données.

    Fossil fourni un exécutable unique compact qui assure tout : gestion des versions, interface web, bug tracker…

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

  • # SQLite Code of Ethics

    Posté par  . Évalué à -10.

    (Not so) fun fact : si vous êtes athée, vous ne pouvez pas être développeur SQLite.

    • [^] # Re: SQLite Code of Ethics

      Posté par  (site web personnel) . Évalué à 10.

      Je ne vois rien de tel dans le document qui est décrit. Ce que dit le document qui est leur "Code of Ethics", c'est que l'auteur et les développeurs principaux de SQLite entendent suivre ces règles, qui inclut de rendre un culte au Dieu de la vision chrétienne.

      En ce qui concerne les autres:

      No one is required to follow The Rule, to know The Rule, or even to think that The Rule is a good idea […] individuals are free to dispute or ignore that advice if they wish.

      Ça me semble assez clair. Si quelqu'un est Athée, il peut tout à fait contribuer à SQLite. Et il peut même leur dire que leur Règle, ils peuvent se la foutre au cul, ils sont OK avec ça. Eux ne le feront pas en revanche.

      Autrement dit, ton commentaire est un pur FUD.

    • [^] # Re: SQLite Code of Ethics

      Posté par  . Évalué à 3. Dernière modification le 04 juillet 2021 à 21:21.

      No one is required to follow The Rule, to know The Rule, or even to think that The Rule is a good idea.

      edit: trop tard

    • [^] # Re: SQLite Code of Ethics

      Posté par  . Évalué à 7.

      Heu, non, il précise uniquement que les développeurs actuels sont d'accord pour essayer d'appliquer l'esprit de ce code éthique dans leurs interactions en rapport avec le projet. Il y a quand même un gros disclaimer pour expliquer qu'il ne s'agit pas d'un code de conduite (pas des règles à suivre absolument). Ils ont, d'ailleurs, ajouté un code de conduite aussi pour ceux qui préfèrent (celui de mozilla). Perso, je ne suis pas religieux, mais j'ai vraiment aucun problème avec leur façon de présenter la chose.

    • [^] # Re: SQLite Code of Ethics

      Posté par  . Évalué à 8.

      Pour être un peu taquin, de toutes façons, vous ne pouvez pas être développeur SQLite… Tout court :-)

      Plus sérieusement, le projet s'affirme Open-Source, not Open-Contribution et cela n'a rien à voir avec leur Code of Ethics :

      In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches. If you would like to suggest a change and you include a patch as a proof-of-concept, that would be great. However, please do not be offended if we rewrite your patch from scratch.

      • [^] # Re: SQLite Code of Ethics

        Posté par  . Évalué à -5.

        Exactement. C’est ce que j’allais répondre aux commentaires qui me disent que mon affirmation est fausse/du FUD.

        • [^] # Re: SQLite Code of Ethics

          Posté par  . Évalué à 3.

          Je vais enfoncer une porte ouverte, mais je veux être sûr : mon commentaire sur le not Open Contribution n'est pas un soutien à ton commentaire initial :-)

          Tu laisses entendre que la croyance religieuse est un critère de sélection pour contribuer à SQLite. C'est bien évidemment faux.

          En faisant le sous-entendu que les contributeurs SQLite ne tolèrent pas les athées, tu diffuses une fausse info sur cette équipe. On peut le tourner dans tous les sens, mais cette petite remarque ne peut que nuire à ce projet (au mieux, rien n'a changé, au pire, des gens pensent que SQLite est développée par des intolérants).

          Donc, comme ton affirmation en contient beaucoup d'ingrédients, je suppose que c'est pour ça que Philippe t'a dit que c'était du FUD.

          • [^] # Re: SQLite Code of Ethics

            Posté par  . Évalué à -3.

            Je lis l'url,

            je lis la règle 1 "First of all, love the Lord God with your whole heart, your whole soul, and your whole strength."

            Cela écarte les athées, et il y a bien discrimination.

            Après, "No one is required to follow The Rule",

            En gros, la portée de ce texte équivaut à du bavardage de tribune.

            Ce texte est sacrément merdique quand même.

            PS: "Love chastity." sacrés puritains quand même.

            • [^] # Re: SQLite Code of Ethics

              Posté par  . Évalué à -1. Dernière modification le 06 juillet 2021 à 14:01.

              Après, "No one is required to follow The Rule"

              Faut lire jusqu'au bout :

              The founder of SQLite and all current developers have pledged to follow the spirit of The Rule to the best of their ability.

              Si tu ajoutes à ça qu'ils n'acceptent pas les contributions externes, je maintiens que pour être développeur sur SQLite (ou pour espérer le devenir) il faut être chrétien.

              • [^] # Re: SQLite Code of Ethics

                Posté par  . Évalué à 9. Dernière modification le 06 juillet 2021 à 16:21.

                Le texte n'informe pas sur les prérequis pour devenir développeur SQLite (personne ne peut le devenir a priori, peu importe la religion), il informe sur les principes des développeurs actuels. Est-ce que c'est utile, c'est une autre question, mais pas de quoi en faire toute une histoire…

                Enfin, pour la petite longue histoire justement, de mémoire, il n'y avait à l'origine ni code éthique ni de conduite pour ce projet, car sur beaucoup d'années, il n'y avait jamais eu de conflits ou problèmes.

                Un jour, des utilisateurs ont demandé un code de conduite pour les utilisateurs (j'imagine pas pour les devs, le projet n'étant pas ouvert aux patchs externes de toutes façons). L'auteur d'SQLite n'était pas convaincu de la nécessité du truc, vu qu'il n'avait pas ou presque rencontré de problèmes sur plein d'années. Du coup, il ajouté ce code éthique (qu'il a maladroitement initialement appelé code de conduite, n'étant pas un expert du sujet), pour informer/rassurer sur les principes que suivent les devs du projet, sans pour autant les imposer aux utilisateurs. Ça a été mal reçu par certains utilisateurs et donc l'auteur de SQLite, afin de respecter son propre code éthique, en particulier les règles suivantes :

                  18. Be a help in times of trouble
  19. Console the sorrowing
  31. Love your enemies
  34. Be not proud
  71. Make peace with your adversary before the sun sets

                il a donc ajouté un code de conduite (lien vers celui de mozilla, ça lui a pris cinq minutes). Ce dernier semble avoir disparu depuis, car visiblement d'autres personnes se sont plaintes (j'ai pas suivi depuis). C'est pas facile de satisfaire tous les utilisateurs sur des sujets dont l'impact n'est pas mesurable sur un projet !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.