• # Cargo.lock affligeant

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

    Quand je vois le Cargo.lock du projet je suis content de toujours développer en C et C++ et ne pas faire parti du nouvel npm.

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Cargo.lock affligeant

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

      Sauf que contrairement à npm, ça compile que les symboles nécessaire et ce de manière statique.

      Le fait que tu n'as que peu de dépendances en C/C++ c'est dû au fait que tu n'as pas de réel gestionnaire de paquet pour ces écosystèmes. Au final, soit tu réinvente la roue, soit tu dépend d'une immense librairie type boost. Moue, j'ai jamais été convaincu.

      En Rust, on a pris le meilleur de NPM (la réutilisation du code) sans les défauts (pas de node_modules de 8Go, versions fixées à mettre à jour explicitement donc pas de chaos dûe aux mises à jour auto de colors/faker/leftpad).

      A la fin, on est bien content d'avoir un binaire unique qui n'inclus que ce qui est réellement utilisé. C'est plus facile à distribuer qu'un programme C/C++ qui dépend de dll/.so qui sont jamais distribués dans les bonnes versions par les distros.

      C'est facile de cracher sur npm, c'est moins facile de regarder comment ça marche dans la réalité.

      https://link-society.com - https://kubirds.com

      • [^] # Re: Cargo.lock affligeant

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

        Sauf que contrairement à npm, ça compile que les symboles nécessaire et ce de manière statique.

        Ben déjà parce que npm ne compile pas vraiment et que c'est compliqué de savoir ce que l'on garde ou pas, contrairement à un langage compilé qui sait tout ce qui est référencé.

        Le fait que tu n'as que peu de dépendances en C/C++ c'est dû au fait que tu n'as pas de réel gestionnaire de paquet pour ces écosystèmes. Au final, soit tu réinvente la roue, soit tu dépend d'une immense librairie type boost. Moue, j'ai jamais été convaincu.

        Carrément d'accord mais en même temps, cela vient aussi en doublon du gestionnaire de paquets de ta distrib.
        Par exemple, en Ada, il y a Alire qui reprend les mêmes idées mais qui vient concurrencer, par exemple, les repos Debian. Du coup, le mainteneur Debian peut se poser des questions quant à la pertinence de son travail.

        A la fin, on est bien content d'avoir un binaire unique qui n'inclus que ce qui est réellement utilisé. C'est plus facile à distribuer qu'un programme C/C++ qui dépend de dll/.so qui sont jamais distribués dans les bonnes versions par les distros.

        Heureusement qu'on n'a pas attendu Rust pour faire de la compilation statique… C'était même plutôt la norme il y a de nombreuses années.
        D'ailleurs, même aujourd'hui, rien n'empêche de compiler un code C/C++ en statique et de distribuer le gros binaire.

        • [^] # Re: Cargo.lock affligeant

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

          Ben déjà parce que npm ne compile pas vraiment et que c'est compliqué de savoir ce que l'on garde ou pas, contrairement à un langage compilé qui sait tout ce qui est référencé.

          Oui, c'est bien ce que je voulais souligner :

          • langage interprété : beaucoup de dépendances == problématique
          • langage compilé : beaucoup de dépendances == osef

          cela vient aussi en doublon du gestionnaire de paquets de ta distrib.

          Sauf que sous Linux, tu n'as pas 2 distributions qui fournissent les mêmes versions de la lib dont tu dépend. Ce qui rend la tâche difficile pour celui qui veut distribuer son logiciel. Plusieurs choix s'offrent à lui :

          • supporter toutes les distros et chacune des versions de la lib via du code spécifique, des tests de régressions, etc…
          • supporter une seule version de la lib et donc ne supporter potentiellement que peu de distro Linux
          • se reposer sur des environnements type flatpak ou docker qui standardise entre plusieurs distro les libs incluses

          Je te laisse deviner quel choix est le plus souvent fait.

          Heureusement qu'on n'a pas attendu Rust pour faire de la compilation statique…

          Vas-y, montre mois les binaires fait en C/C++ qui compilent statiquement boost, Gtk, Qt, et autres giga-lib, alors qu'ils n'utilisent que 3 fonctions de ces dernières.

          https://link-society.com - https://kubirds.com

          • [^] # Re: Cargo.lock affligeant

            Posté par  (site web personnel, Mastodon) . Évalué à 6.

            Vas-y, montre mois les binaires fait en C/C++ qui compilent statiquement boost, Gtk, Qt, et autres giga-lib, alors qu'ils n'utilisent que 3 fonctions de ces dernières.

            Bon, je vais faire fi du ton agressif et/ou hautain.
            Par curiosité, j'ai compilé ce code statiquement (hormis pour pthread qui refuse catégoriquement d'être compilé de la sorte) en utilisant la ligne suivante:

             c++ -o server server.cpp /usr/lib/x86_64-linux-gnu/libboost_iostreams.a /usr/lib/x86_64-linux-gnu/libboost_thread.a -lpthread

            Résultat, l'exécutable pèse 404Ko et la commande ldd me fournit:

                linux-vdso.so.1 (0x00007fff6e729000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd6dc2d0000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd6dc0ee000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd6dc0d3000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd6dbee1000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fd6dc34f000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd6dbd92000)

            On voit donc bien que Boost est compilé statiquement.
            Le poids cumulé des deux archives est de 968Ko, le linker a donc bien fait son travail.

            Du coup, comme tu listais aussi Gtk, j'ai fait un petit code en GtkAda qui match le code le plus simple du site gtk-rs.

            with Gtk.Main;
with Gtk.Window; use GtK.Window;
with Ada.Text_IO;use Ada.Text_IO;
With Ada.Exceptions; use Ada.Exceptions;

procedure simple_gtk is

   main_window : Gtk_Window;

begin
   Gtk.Main.Init;

   main_window := Gtk_Window_New;
   main_window.Set_Default_Size (320, 200);
   main_window.Set_Title ("Hello, World! ");

   main_window.show_all;
   Gtk.Main.Main;
exception
   when Error : others => Put_Line("Ouuupppsss");
      Put_Line (Exception_Information(Error));
end simple_gtk;

            L'exécutable, compilé avec les infos de debug, pèse, quant à lui, 3.6Mo mais ne peut pas être compilé entièrement en statique, il semblerait que compiler avec Gtk en statique ne soit pas recommandé.
            Le binaire dépend donc finalement de 47 bibliothèques dynamiques.

            Et enfin, à titre de comparaison, j'ai créé le Cargo suivant pour compiler le hello world, mentionné en lien plus haut, en Rust:

            [package]
name = "simple-gtk"
version = "0.1.0"
authors = ["Blackknight"]
edition = "2018"

[dependencies]
gtk = { git = "https://github.com/gtk-rs/gtk3-rs.git" }

            Tout compile bien en release.
            L'exécutable pèse 3.7Mo et dépend de 69 bibliothèques dynamique… Donc finalement, ce n'est pas statique non plus.
            Par contre, la compilation en debug produit un exécutable de… 109Mo avec les mêmes 69 libs.
            Du coup, là, je suis preneur d'informations pour qu'on m'explique la taille !

      • [^] # Re: Cargo.lock affligeant

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

        Sauf que contrairement à npm, ça compile que les symboles nécessaire et ce de manière statique.

        Ça change rien, je viens d'essayer en local et ça a téléchargé 92 dépendances. C'est plus que le nombre de paquet total de mon image minimale de alpine.

        Le fait que tu n'as que peu de dépendances en C/C++ c'est dû au fait que tu n'as pas de réel gestionnaire de paquet pour ces écosystèmes. Au final, soit tu réinvente la roue, soit tu dépend d'une immense librairie type boost. Moue, j'ai jamais été convaincu.

        Toujours pas d'accord. Boost c'est un framework bloat, il y a certes beaucoup de modules mais la plupart sont indépendants. Mais tu prends un mauvais exemple.

        Personnellement quand je développe en C ou en C++, j'ai jamais eu à utiliser une lib externe pour faire des trucs aussi basique que générer un nombre positif dans une plage précise.

        Dans mon application actuelle voilà mes dépendances :

        • curl
        • jansson
        • mosquitto
        • sqlite

        Je comprends pas l'intérêt de faire une bibliothèque (comprendre paquet cargo) pour une ou deux fonctions.

        A la fin, on est bien content d'avoir un binaire unique qui n'inclus que ce qui est réellement utilisé. C'est plus facile à distribuer qu'un programme C/C++ qui dépend de dll/.so qui sont jamais distribués dans les bonnes versions par les distros.

        Ça n'a absolument rien à voir avec le langage. Tu peux faire du full statique en C si ça te chante. Les 3/4 des bibliothèques sont fournies en statique et comme le linker est intelligent il inclue aussi que le nécessaire (à condition que la bibliothèque soit pas amalgamée).

        git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Cargo.lock affligeant

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

      Justement en tant que dev C/C++ je trouve dommage qu'on doive tout faire à la main.
      Ce que tu trouves affligeant est la démonstration de la ré-utilisabilité et c'est un gros manque de C/C++ (qui a des gestionnaires de ce type maintenant mais aucun qui a pris le dessus)

      • [^] # Re: Cargo.lock affligeant

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

        Justement en tant que dev C/C++ je trouve dommage qu'on doive tout faire à la main.

        Tu n'as pas à tout faire à la main

        • Json ? nlohmann json / jansson
        • Client HTTP ? libcurl
        • Lecture d'archives ? libarchive
        • XML ? expat, tinyxml, pugixml
        • Multimedia ? SDL2, SFML

        D'ailleurs le plus simple c'est de chercher dans les projets “awesome”.

        Pour C, pour C++.

        git is great because linus did it, mercurial is better because he didn't

        • [^] # Re: Cargo.lock affligeant

          Posté par  (site web personnel) . Évalué à -1. Dernière modification le 14 janvier 2022 à 16:45.

          Tu n'as pas à tout faire à la main

          Ha? Tu as mis plein de noms sans indiquer comment tu les récupères, Merci, je connais que les libs existent, et c'est n'est pas du tout le sujet.
          Le "à la main" concerne comment les installer. Quel équivalent (et donc considéré comme universel par les devs) à npm? C'est la toute la question, à laquelle tu n'as pas répondu (normal, il n'y a pas, je l'ai déjà écrit dans mon commentaire).

          Prenons l'exemple de libcurl: apt install libcurl-dev, yum install libcurl-devel, navigateur web ou plein de "packageurs" dont aucun n'a le dessus, pour un seul projet tu n'as déjà pas la même procédure suivant l'OS, ne parlons pas de plusieurs projets.

          Tu critiques le Cargo.lock mais tu n'as pas compris à quoi il sert et ce qui manque au C/C++ par rapport à d'autres langages. Il manque clairement un npm au C/C++, il y a des tentatives mais aucune de référence comme pip ou npm pour les autres langages.

          Donc : tu ne démontres absolument pas "Tu n'as pas à tout faire à la main" (tu démontres plutôt le contraire en fait, en tapant à côté du problème), c'est affligeant pour reprendre un mot utilisé ici.

    • [^] # Re: Cargo.lock affligeant

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

      Quand je vois le Cargo.lock du projet

      Mais mais mais, il n'y a que du code qui sort de chez Microsoft !

    • [^] # Re: Cargo.lock affligeant

      Posté par  . Évalué à 2.

      Le cargo.lock a peu d'intérêt car il est généré.
      Le fichier intéressant est le cargo.toml qui liste les dépencences, 390 lignes.

      Et franchement en étant ni dev RUST ni dev C/C++ je trouve ça beaucoup moins terrifiant que les fichiers boostrap, 1102 lignes, configure.ac, 750 lignes et Makefile, 215 lignes, init.cfg, 764 lignes qui semblent nécessaires à la compilation de la version GNU.

      • [^] # Re: Cargo.lock affligeant

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

        Et franchement en étant ni dev RUST ni dev C/C++ je trouve ça beaucoup moins terrifiant que les fichiers boostrap, 1102 lignes, configure.ac, 750 lignes et Makefile, 215 lignes, init.cfg, 764 lignes qui semblent nécessaires à la compilation de la version GNU.

        La différence, c'est que ça, c'est déjà du code, pas des dépendances.
        En plus, c'est du code de build donc si tu veux comparer, il faudrait aller regarder comment est codé le cargo build.

        Au final, tu compares 3000 lignes de code avec un listing de 390 dépendances qui, elles,contiennent aussi beaucoup de code.

        Ceci dit, il est vrai que les autotools, c'est pas ça et ça ressemble beaucoup à de la magie noire.

        • [^] # Re: Cargo.lock affligeant

          Posté par  . Évalué à 4.

          Ceci dit, il est vrai que les autotools, c'est pas ça et ça ressemble beaucoup à de la magie noire.

          Bien pour ça que j'ai vu pas mal de projets C ou C++ migrer vers cmake d'abord, et maintenant aussi vers meson (parfois même de cmake vers meson), au point que même certains IDE, il me semblent, n'ont plus leur propre système de build (ce qui se faisait beaucoup à une époque, systématiquement je dirais même?) mais se basent sur cmake/meson/whatever, pas sûr du tout, mais je ne serais pas surpris même que certains déprécient leur système de build originel…

          Mais bon, même cmake ou meson, on peut considérer que c'est du code, ça ne liste pas stricto sensu les dépendences.

  • # Changement de licence au passage

    Posté par  . Évalué à 3.

    Fait notable, la licence n'est pas la GPL mais la MIT. Au moins, c'est clairement indiqué et assumé.

    (Perso je trouve ça dommage, mais inutile de démarrer un énième débat sur les licences, on n'est pas dredi non plus).

    • [^] # Re: Changement de licence au passage

      Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 14 janvier 2022 à 19:23.

      C'est dans l'espoir de susciter plus d'adoption ou est-ce juste un repère d'anti-libres ?

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Changement de licence au passage

        Posté par  . Évalué à 3.

        Oui, pour favoriser l'adoption dans certains contextes (embarqué, par exemple) :

        [The MIT Licence] potentially makes it more attractive for use in places where software licensed with GPLv3 is not adopted due to its restrictions on Tivoization among other things

    • [^] # Re: Changement de licence au passage

      Posté par  . Évalué à 4.

      On n'est pas dredi ? Tu es sûr ? :)

  • # retours intéressants de Sylvestre L.

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Le lien date de juillet 2021. On peut le mettre en lien avec ce billet de mars 2021 d'une personne de chez Mozilla qui l'a empaqueté pour Debian (il avait déjà fait un exercice similaire avec CLang) puis utilisé au quotidien en conditions réelles.
    https://sylvestre.ledru.info/blog/2021/03/09/debian-running-on-rust-coreutils

    L'auteur est revenu ce mois-ci avec un billet pour faire le point sur l'avancement, suite à la sortie de la version coreutils 0.0.12 : les choses avancent mais la route est longue…
    https://linuxfr.org/users/antistress/liens/sylvestre-ledru-and-other-developers-have-been-working-on-a-rust-based-coreutils-phoronix#comment-1881821

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Suivre le flux des commentaires

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