zimoun a écrit 70 commentaires

Votre cas d'usage n'est pas le cadre de cet article. :-)
Et pour être honnête, ce cas d'usage n'est pas mon coeur de métier.

Concernant Nix, je ne sais pas.

Concernant Guix, les fonctionnalités pour ce genre de cas d'usage ne sont pas encore totalement mature pour être utilisé en production. Pour faire simple la réponse est guix deploy et voici quelques pointeurs :

https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-deploy.html
https://guix.gnu.org/blog/2019/towards-guix-for-devops/

roptat qui contribue beaucoup à Guix a écrit cela :

https://linuxfr.org/news/guix-un-outil-pour-les-remplacer-tous#comment-1797262

Au niveau sysadmin, pour la gestion des paquets, un intérêt est le rollback et les profils (ce qui est fait par des solutions comme modulefiles ou virtualenv).
(en passant il n'y a pas besoin d'être superutilisateurs pour installer des paquets et il n'y a pas de problème)
Ensuite, si on utilise Guix System (ou Nix OS), le rollback s'applique aussi aux services.

Il y a les fichiers manifest qui permettent de déclarer ses paquets en spécifiant un commit Guix particulier (un channel). Donc sur n'importe quelle machine, il est trivial d'instancier exactement la même configuration.

DevOps et SRE n'est pas mon coeur de métier donc je ne sais pas.

Pour vous donner un exemple concret, il faudrait que vous décriviez un problème concret et votre actuelle solution concrète.

Pour faire simple, une introduction aux keywords #: est cette page:

https://www.gnu.org/software/guile/manual/html_node/Why-Use-Keywords_003f.html

Oui c'est un mythe les histoires de parenthèses et de Lisp. Comme avec le C par exemple, il faut juste faire un effort d'indentation et tout se passe bien.

Et si on est totalement honnête, la seule chose vraiment pénible est de converser les parenthèses balancées. Mais cela se résout avec tout bon éditeur de texte.

---

Notez que les définitions des paquets paraissent plus difficiles qu'avec Nix parce que j'ai fait un peu de zèle. ;-)

Si c'est pour aller un peu plus quand dans un commentaire ici, je voudrais nettoyer un peu les choses alors. :-)

1. Disons avoir un guix.scm propre pour construire master (quelque soit le commit).
2. Savoir pourquoi il ya un Seg Fault avec guix environment.
3. Regarder de plus près pourquoi cpprestsdk ne compile pas avec Boost 1.70. Parce que normalement, ca devrait ! Par exemple, par défaut il ya -Werror et … il y a beaucoup de warnings. :-) Donc je vais re-essayer un peu ce qui évitera de ressortir une vieille version de Boost et simplifiera le brol. Chose que je ne voulais pas faire initialement parce que bon cpprestsdk c'est loin de mes affaires. Mais maintenant au point où j'en suis… :-)
4. Faire l'équivalent de la dernière partie avec le conteneur, toussa.

Bon si je ne suis pas sorti du bois d'ici la milieu de semaine prochaine, c'est que j'aurais eu d'autres préoccupations plus urgentes. ;-)
Dans ce cas, reprenez ce que vous voudrez. :-)

Avec Guix, c'est plus facile de fixer une version comme c'est fait.

Pour ne pas fixer une version fixe, à ma connaissance il n'y a rien de natif et il faut écrire un peu plus qu'avec Nix. Comme là par exemple:

http://git.savannah.nongnu.org/cgit/mescc-tools.git/tree/guix.scm

Idem que dans l'autre section, on suppose que l'on se trouve dans le dossier contenant le fichier guix.scm sinon il faut indiquer ledit chemin ou utiliser un channel.

Guix

  guix build --load-path=. mymathserver

  guix install --load-path . mymathserver

Cependant, je préféres installer dans un profil séparer du profil courant. Par exemple,

  guix install --load-path=. mymathserver --profile=/tmp/my-server-test

Puis il faut "activer" ce profil :

  source /tmp/my-server-test/etc/profile

(il y a d'autres solutions de faire pour mettre à jours tous les chemins :-))

Finalement, taper mymathserver fonctionne (serveur dans localhost).

Il n'y a pas vraiment de default.nix. Il y a 2 solutions pour faire la même chose :

• soit un channel (qui peut être local ou à distance)
• soit utiliser --load-path pour ajouter (prepend) un dossier dans la recherche des paquets.

Disons que l'on a cloné le dépôt mymathserver et que l'on se trouve dans le dossier. Et dans ce dossier, il y a aussi un fichier, disons guix.scm qui contient les définitions (voir autres sections).

Guix

 guix environment --load-path=. mymathserver

mkdir mybuild
cd mybuild
cmake ..
make

Mais ./mymathserver retourne Segmentation fault. A investiguer…

Guix

(define-module (linuxfr)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix packages)
  #:use-module (guix build-system cmake)

  #:use-module (gnu packages tls)
  #:use-module (gnu packages compression)
  #:use-module (gnu packages check))

(define-public mymathserver
  (package
   (name "mymathserver")
   (version "0.1")
   (source (origin
            (method git-fetch)
            (uri (git-reference
                  (url "https://gitlab.com/nokomprendo/mymathserver")
                  (commit (string-append "v" version))))
            (file-name (git-file-name name version))
            (sha256
             (base32 "0vvq2z2pjdr7dm6s4d6a3ikp7lw391lk4mdlqd18rgmr2jqfhl0b"))))
   (build-system cmake-build-system)
   (arguments '(#:tests? #f))
   (native-inputs
    `(("boost" ,boost-old)
      ("cpprestsdk" ,cpprestsdk)
      ("gtest" ,googletest)
      ("openssl" ,openssl)))
   (synopsis "Toy example")
   (description "Nothing relevant")
   (home-page "https://gitlab.com/nokomprendo/mymathserver")
   (license #f)))

Nix

{ stdenv, fetchFromGitHub, cmake, boost, openssl, websocketpp, zlib }:

stdenv.mkDerivation {

  name = "cpprestsdk";

  src = fetchFromGitHub {
    owner = "Microsoft";
    repo = "cpprestsdk";
    rev = "v2.10.14";
    sha256 = "0z1yblqszs7ig79l6lky02jmrs8zmpi7pnzns237p0w59pipzrvs";
  };

  buildInputs = [ boost cmake openssl websocketpp zlib ];
}

Guix

(define-module (linuxfr)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix packages)
  #:use-module (guix build-system cmake)

  #:use-module (gnu packages tls)
  #:use-module (gnu packages compression))

(define-public cpprestsdk
  (package
   (name "cpprestsdk")
   (version "v2.10.14")
   (source (origin
            (method git-fetch)
            (uri (git-reference
                  (url "https://github.com/microsoft/cpprestsdk")
                  (commit version)))
            (file-name (git-file-name name version))
            (sha256
             (base32 "0z1yblqszs7ig79l6lky02jmrs8zmpi7pnzns237p0w59pipzrvs"))))
   (build-system cmake-build-system)
   (native-inputs
    `(("websocketpp" ,my-websocketpp)
      ("boost" ,boost-old)
      ("openssl" ,openssl)
      ("zlib" ,zlib)))
   (arguments '(#:tests? #f
                ;; Warnings not always addressed by upstream, see:
                ;; https://github.com/microsoft/cpprestsdk/issues/724
                #:configure-flags '("-DWERROR=OFF")))
   (synopsis "C++ REST SDK by Microsoft")
   (description "The C++ REST SDK is a Microsoft project for cloud-based
client-server communication in native code using a modern asynchronous C++ API
design.  This project aims to help C++ developers connect to and interact with
services.")
   (home-page "https://github.com/microsoft/cpprestsdk")
   (license #f)))

Le projet jouet mymathserver dépend de cpprestsdk qui est le point sensible à empaqueter car le code n'est pas très robuste. Pour s'en convaincre, il suffit d'aller faire un tour sur les issues GitHub.

https://github.com/microsoft/cpprestsdk/issues

Donc, il faut un peu tricoter avec la version de Boost.

Du côté de Guix, le paquet websocketpp est dans disponible après la bonne version de Boost. Donc on pourrait s'en sortir avec guix time-machine. Mais beaucoup de substituts ne sont plus disponibles donc il y aurait beaucoup de compilations à faire—ce qui n'est pas un problème en soi mais pas le but ici.

Bref! en plus du projet jouet mymathserver et de cpprestsdk comme dans l'article initial, j'ai "empaqueté" websocketpp et une vieille version de boost. Empaqueter est un bien grand mot puisque ce sont les vieux paquets dépoussiérés à coup de git show.

Finalement, on compare des pommes et des oranges puisque le tour d'horizon a été fait avec ce qui était facile pour Nix (2 paquets personnalisés) et donc dans une autre configuration, cela aurait été Nix qui aurait dû fournir plus de paquets personnalisés. Donc il faut s'arrêter après les 2 mêmes paquets, les 2 autres derniers sont juste là pour éviter de recompiler le monde entier.

Ceci dit, avec ces définitions, on est capable de reproduire la première partie.

---

Le fichier disons /tmp/test/linuxfr.scm contient les paquets personnalisés ci-dessous.

Pour tout construire, il faut faire:

  guix build -L /tmp/test mymathserver

En terme de reproductibilité, si vous utilisez la time-machine :

  guix time-machine --commit=b3e28b5ef5e23e564eeac8823ad2c837f7c40650 \
    -- build -L /tmp/test mymathserver

vous devriez compiler au bit près la même chose que moi. Donc normalement, vous devriez avoir: /gnu/store/hqhsc61v4xpj1ld0dwvf8gabxr3x0dwc-mymathserver-0.1 comme résultat. Sinon, il ya une source de non-déterminisme.

Je ferai un autre commentaire pour donner l'équivalent des commandes. :-)

---

(define-module (linuxfr)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix packages)
  #:use-module (guix build-system cmake)

  ;; boost
  #:use-module (guix build-system gnu)
  #:use-module (gnu packages)
  #:use-module (gnu packages perl)
  #:use-module (gnu packages python)
  #:use-module (gnu packages shells)
  #:use-module (gnu packages icu4c)

  #:use-module (gnu packages tls)
  #:use-module (gnu packages compression)
  #:use-module (gnu packages check)
  )


(define-public mymathserver
  (package
   (name "mymathserver")
   (version "0.1")
   (source (origin
            (method git-fetch)
            (uri (git-reference
                  (url "https://gitlab.com/nokomprendo/mymathserver")
                  (commit (string-append "v" version))))
            (file-name (git-file-name name version))
            (sha256
             (base32 "0vvq2z2pjdr7dm6s4d6a3ikp7lw391lk4mdlqd18rgmr2jqfhl0b"))))
   (build-system cmake-build-system)
   (arguments '(#:tests? #f))
   (native-inputs
    `(("boost" ,boost-old)
      ("cpprestsdk" ,cpprestsdk)
      ("gtest" ,googletest)
      ("openssl" ,openssl)))
   (synopsis "Toy example")
   (description "Nothing relevant")
   (home-page "https://gitlab.com/nokomprendo/mymathserver")
   (license #f)))


(define-public cpprestsdk
  (package
   (name "cpprestsdk")
   (version "v2.10.14")
   (source (origin
            (method git-fetch)
            (uri (git-reference
                  (url "https://github.com/microsoft/cpprestsdk")
                  (commit version)))
            (file-name (git-file-name name version))
            (sha256
             (base32 "0z1yblqszs7ig79l6lky02jmrs8zmpi7pnzns237p0w59pipzrvs"))))
   (build-system cmake-build-system)
   (native-inputs
    `(("websocketpp" ,my-websocketpp)
      ("boost" ,boost-old)
      ("openssl" ,openssl)
      ("zlib" ,zlib)))
   (arguments '(#:tests? #f
                ;; Warnings not always addressed by upstream, see:
                ;; https://github.com/microsoft/cpprestsdk/issues/724
                #:configure-flags '("-DWERROR=OFF")))
   (synopsis "C++ REST SDK by Microsoft")
   (description "The C++ REST SDK is a Microsoft project for cloud-based
client-server communication in native code using a modern asynchronous C++ API
design.  This project aims to help C++ developers connect to and interact with
services.")
   (home-page "https://github.com/microsoft/cpprestsdk")
   (license #f)))


;;;
;;; End here. 
;;; Below hack to build cpprestsdk with the correct versions
;;; without rebuilding the world.
;;;

(define-public my-websocketpp
  (package
    (name "websocketpp")
    (version "0.8.1")
    (source
     (origin
       (method git-fetch)
       (uri (git-reference
             (url "https://github.com/zaphoyd/websocketpp.git")
             (commit version)))
       (file-name (git-file-name name version))
       (sha256
        (base32 "12ffczcrryh74c1xssww35ic6yiy2l2xgdd30lshiq9wnzl2brgy"))))
    (build-system cmake-build-system)
    (native-inputs
     `(("boost" ,boost-old)
       ("openssl" ,openssl)))
    (arguments '(#:configure-flags '("-DBUILD_TESTS=ON")
                 #:phases
                 (modify-phases %standard-phases
                   (add-after 'install 'remove-tests
                     (lambda* (#:key outputs #:allow-other-keys)
                       (let* ((install-dir (assoc-ref outputs "out"))
                              (bin-dir (string-append install-dir "/bin")))
                         (delete-file-recursively bin-dir)
                         #t))))))
    (home-page "https://www.zaphoyd.com/websocketpp/")
    (synopsis "C++ library implementing the WebSocket protocol")
    (description "WebSocket++ is a C++ library that can be used to implement
WebSocket functionality.  The goals of the project are to provide a WebSocket
implementation that is simple, portable, flexible, lightweight, low level, and
high performance.")
    (license #f)))                      ;license:bsd-3


(define-public boost-old
  (package
    (name "boost")
    (version "1.67.0")
    (source (origin
              (method url-fetch)
              (uri (string-append
                    "mirror://sourceforge/boost/boost/" version "/boost_"
                    (string-map (lambda (x) (if (eq? x #\.) #\_ x)) version)
                    ".tar.bz2"))
              (sha256
               (base32
                "1fmdlmkzsrd46wwk834jsi2ypxj68w2by0rfcg2pzrafk5rck116"))
              (patches '("/tmp/test/patches/boost-fix-icu-build.patch"))))
    (build-system gnu-build-system)
    (inputs `(("icu4c" ,icu4c)
              ("zlib" ,zlib)))
    (native-inputs
     `(("perl" ,perl)
       ("python" ,python-2)
       ("tcsh" ,tcsh)))
    (arguments
     `(#:tests? #f
       #:make-flags
       (list "threading=multi" "link=shared"

             ;; Set the RUNPATH to $libdir so that the libs find each other.
             (string-append "linkflags=-Wl,-rpath="
                            (assoc-ref %outputs "out") "/lib")

             ;; Boost's 'context' library is not yet supported on mips64, so
             ;; we disable it.  The 'coroutine' library depends on 'context',
             ;; so we disable that too.
             ,@(if (string-prefix? "mips64" (or (%current-target-system)
                                                (%current-system)))
                   '("--without-context"
                     "--without-coroutine" "--without-coroutine2")
                   '()))
       #:phases
       (modify-phases %standard-phases
         (delete 'bootstrap)
         (replace 'configure
           (lambda* (#:key inputs outputs #:allow-other-keys)
             (let ((icu (assoc-ref inputs "icu4c"))
                   (out (assoc-ref outputs "out")))
               (substitute* '("libs/config/configure"
                              "libs/spirit/classic/phoenix/test/runtest.sh"
                              "tools/build/doc/bjam.qbk"
                              "tools/build/src/engine/execunix.c"
                              "tools/build/src/engine/Jambase"
                              "tools/build/src/engine/jambase.c")
                 (("/bin/sh") (which "sh")))

               (setenv "SHELL" (which "sh"))
               (setenv "CONFIG_SHELL" (which "sh"))

               (invoke "./bootstrap.sh"
                       (string-append "--prefix=" out)
                       ;; Auto-detection looks for ICU only in traditional
                       ;; install locations.
                       (string-append "--with-icu=" icu)
                       "--with-toolset=gcc"))))
         (replace 'build
           (lambda* (#:key make-flags #:allow-other-keys)
             (apply invoke "./b2"
                    (format #f "-j~a" (parallel-job-count))
                    make-flags)))
         (replace 'install
           (lambda* (#:key make-flags #:allow-other-keys)
             (apply invoke "./b2" "install" make-flags))))))

    (home-page "http://www.boost.org")
    (synopsis "Peer-reviewed portable C++ source libraries")
    (description
     "A collection of libraries intended to be widely useful, and usable
across a broad spectrum of applications.")
    (license #f)))
;; (license (license:x11-style "http://www.boost.org/LICENSE_1_0.txt"
;;                               "Some components have other similar licences."))

C'est une bonne idée de comparer avec Guix. Si tu as le temps de nous faire un retour, ce serait chouette.

Tout ca va dépendre si Microsoft fait bien le travail pour empaqueter cpprestsdk. Avoir la version de Boost avec laquelle vous avez compilé aide déjà pas mal. :-)

Merci!

Je vous tiens au courant ici. :-)

Très intéressant. Cela permet de vous un peu les similarités et différences. :-)

Par exemple, Guix n'est pas supporté par Cachix même s'il y a un ticket d'ouvert depuis longtemps. :-)

https://github.com/cachix/cachix/issues/85

En revanche, Guix fournit guix publish qui permet de servir les paquets que l'on a construit localement. Oui cela est moins pratique que Cachix. :-)

https://guix.gnu.org/manual/en/html_node/Invoking-guix-publish.html

Il y a un patch pour distribuer via IPFS mais il n'a pas encore été assez testé, je crois.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33899https://ipfs.io/

A ma connaissance, il n'y a pas d'image officielle pour Gitlab CI. Mais il y a des images sur DockerHub ;-)

Merci car cela donne du concret par rapport à ce qui a été dit dans l'autre annonce.

Quelles versions avez-vous utilisé ?
En particulier pour Boost.

Comme je trouve la comparaison intéressante, j'ai fait quelques tests avec Guix. Mais avec Boost@1.70 j'ai un message d'erreur à la compilation de cpprestsdk. Et comme je ne voudrais pas passer trop de temps à empaqueter cette "chose" pour laquelle je n'ai pas un vif intérêt. :-)

Merci d'avance.

Rien que ça ? Faudrait se calmer un peu, non ? Tu as vu la lumière et tout ce que les gens peuvent dire qui ne seraient pas dans ton sens ne sont que rhétorique ?

Ahaha j'adore… <3

Pour le reste, vu que cela ne vous intéresse apparemment pas, pas la peine que je prenne du temps pour répondre.

Comme le disait une certaine émission, à une certaine époque: c'est fini et vous pouvez reprendre une activité normale. :-)

En Pré-Scriptum: j'ai pas suivi les liens, je vais le faire, ça semble super intéressant. Je ne fais que réagir à tes arguments ici, qui sont intéressants.

Peut-être commencez par cela. ;-)

pardon, on m'a appris a considérer le mot sécurité comme un buzzword, quand il est tout seul.
Ça protège de quoi, et dans quelles limitations?

Attaque Trusting Trust par exemple.

Arf… pardonnes donc le pauvre auto-didacte que je suis du manque de connaissances théorique…. mais je renifle ici quand même… euh, pour être poli, 3 mots mis ensembles pour impressionner la galerie. Désolé si c'est crû. En fait, non, pas tant désolé que ça, ce coin du web reste un coin ou je peux m'exprimer et apprendre sans faussetés.

Au temps pour moi. Désolé.

Il faut entendre tout processus de traitement numérique utilisé en Science. Cela va de la simulation numérique (météo, méca, etc.) à l'étude génétique des cancers par exemple.

Aujourd'hui, tous les champs de la Science utilisent à un moment ou un autre un logiciel (ou plusieurs) et souvent le résultat (scientifique) est plus "dû" au traitement numérique qu'à l'observation elle-même.

Or la méthode scientifique n'est pas appliquée à la gestion desdits logiciels. Donc finalement, est-ce encore de la Science ? (question ouverte qui n'appelle pas de réponse :-))

(Méthode scientifique est pompeux et ne réfère à pas grand chose de bien définie : voir toute la philosophie des sciences ;-))

Mais, oui, on sait, tu peux être espionné dès lors que tu confies ton hard a un autre. On sait, même le CPU peut leak… ça fait que 2 ans qu'on a des preuves, certes.
Mais, y'a un moment, soit on fait abstinence, soit on reste un minimum optimiste, non? A noter que, j'ai lu 1984.

On ne parle pas du hard qui est une question en soi. Déjà uniquement avec le soft, ca suffit.

Pour être explicite, le compilateur peut introduire une backdoor à la compilation. Et comme un compilateur est lui même le résultat d'une compilation, ladite backdoor peut être ainsi propagée. D'où la question du bootstrap.

Au quotidien, oui clairement on s'en fiche un peu. Enfin moi cela ne me dérange pas d'utiliser GHC parce qu'Haskell c'est chouette ;-) alors que le compilateur GHC n'est pas encore bootstrappable (à ma connaissance) donc potentiellement une source de fragilité en terme de sécurité.

Et sinon, oui le hardware est une question. Il y a des projets qui essaie justement d'avoir du hard bootstrappable. Mais je ne suis pas sûr de suffisamment bien comprendre pour l'expliquer. :-)

Tu parles de science. Je te parle d'ingénierie. C'est p'tet la qu'on se comprend pas, je suis pas assez intelligent pour la science, mais je reste captivé par l'idée de supprimer toute contrainte inutile a l'humain. Il parait aussi que je suis pas idiot, mais, je connais pas de scientifique.
Bref, à quoi ça sert?

Traduction libre d'une réponse Alan Cox :-)
L'ingénierie ne requiert pas de science. La science aide beaucoup mais les gens construisait des mûrs en brique parfaitement bien bien avant qu'ils sachent pourquoi le ciment fonctionne.
https://lkml.org/lkml/2001/12/1/110

Donc on peut construire des choses incroyables sans science. :-)

Cependant la science (en tant que méthode) se repose de plus en plus sur l'ingénierie (en tant que technique) et tout devient un peu mélangé.

Bref, la question que vous posez sort du cadre de Guix et de LinuxFr et prendrait un peu plus qu'un commentaire pour y répondre. Êtes-vous dispo pour une bière ? ;-)

Je crois que RPM est capable de faire du transactionnel.

Atta… tu compares RPM, un format de fichier, avec APT, un exécutable et… nix, une distro?
Justement, parlons simples, parlons binaires, ça ressemble a quoi le format de nix?

Pour moi RPM c'est Red hat Package Manager et APT c'est Advanced Package Tools. Donc mes excuses si c'est un raccourci mais je voulais dire RPM pour toute l'infrastructure RedHat (et consort), un peu comme je pourrais aussi dire APT pour tout l'écosystème Debian. Abus de langage.

Remarquez que dans tous les commentaires, j'ai parlé de Guix en tant que gestionnaire de paquets et jamais vraiment en tant que distribution. C'est une autre histoire.

Personnellement, j'utilise Guix (gestionnaire de paquets) avec une distribution Debian stable. Debian me fournit principalement le noyau linux et le système de fichiers, plus quelques autres trucs comme des pilotes etc.. Bref!

Tout ca pour dire que je crois que le gestionnaire de paquets RedHat (et/ou consort) permet de faire du transactionnel.

Ca ressemble à quoi le format des paquets Guix ? La recette source ressemble à ca :
https://guix.gnu.org/blog/2018/a-packaging-tutorial-for-guix
Et le binaire c'est un format qui s'appelle nar. C'est repris de chez Nix qui l'a défini, voir par exemple une spec là:
https://gist.github.com/jbeda/5c79d2b1434f0018d693
Mais on ne manipule jamais un fichier .nar manuellement.

Guix fait l'hypothèse (forte) qu'il y a suffisamment de stabilité dans le noyau, le système de fichiers, etc. pour ne pas influencer sur la transparence binaire. Mais oui il y a une question pertinente sur l'effet du hardware.

Tu vois, c'est justement par l'intermédiaire de Nix que j'ai appris cette faiblesse. Et de mon job. Je suis tellement curieux… j'ai cherché, j'ai voulu reproduire cette fiabilité supposée, et… j'ai trouvé que c'était de la poudre aux yeux.
Parce que le soft (le kernel est un soft) sous linux ne permets pas cette hypothèse. Et Nix/Guix l'affirment a chaque fois comme forte.
J'aime pas ça, c''est pas honnête.

Qu'est-ce qui n'est pas honnête ?

Et juste pour comprendre. Vous avez pris 2 hardwares différents et mis dessus 2 versions différentes du noyau linux avec 2 versions différents du système de fichiers. Ensuite, vous avez mis dans ces 2 environnements différents exactement la même chaîne de compilation, bit à bit identique, du compilateur au linker en passant la Glibc. Puis vous avez compilé le même code source dans ces 2 environnements et vous n'obtenez pas le même binaire identique bit à bit, est-ce cela ?

Si oui, je suis intéressé par connaitre le matériel en question, les versions des noyaux en questions, des systèmes de fichiers, de la chaîne de compilation et de ce que vous avez compilé. Du coup, je serais intéressé que vous me contactiez en privée. :-)

Parce que oui c'est possible mais c'est rare. :-)
Et je n'ai pas encore vu de mes propres yeux de tel cas.

Cependant, qui peut le plus peut le moins. ;-)

Pitié, non… Un dev sys ne seras jamais un bon dev web, un architecte ne sera jamais un bon maçon, et vice versa. Cette expression je la prend comme une forme de mépris. C'est désagréable, même si je sais que je l'ai moi aussi commise, cette erreur.
On peut avoir les notions des métiers adjacents, mais jamais on ne les fait aussi bien que des pros.

Le qui se réfèrait à "gestionnaire de paquets". :-)

---

Merci pour vos commentaires.

J'espère que vous prendrez le temps de tester Guix parce que notre discussion là est beaucoup plus large de ce qu'apporte le gestionnaire de paquets Guix comparé à ce qui existe (avec Debian par exemple). Et je ne voudrais pas qu'avec cette déviation, certes intéressante, vous ayez une fausse impression de ce que Guix fait/est.

On m'a dis la même de la PO (Programmation Object). Mais je suis resté à la POO (Programmation Orientée Objet). Parce que forcer une façon de penser, c'est brider.

Sauf erreur de ma part personne n'a pas parlé de POO en présentant de Guix. C'est vous en lisant inherit et héritage qui extrapolez.

J'ai l'impression que l'on s'amuse plus à une joute rhétorique que vraiment chercher à comprendre ce que fait l'outil et comment il fonctionne. Mais bon, c'est le jeu sur LinuxFr. ;-)

J'espère que tu espères pas convaincre des devs expérimentés en leur présentant un système nouveau qui a déjà des artefacts mis en avant? Parce que, bon, les artefacts, on (enfin, je) les accepte que quand ils sont obligatoire, hein.
Au point que, pour mes collègues j'ai écrit un script pour générer des .deb à partir d'un fichier ini-style. Certes, des debs castrés, mais ça marche et c'est simple.

Idem ici. Vous découpez le cheveux en 4 alors que je vous ai donné un exemple concret avec GnuPG de ce que c'était. De quelle était l'idée derrière.

Donc au lieu de juger et comparer l'idée (technique) avec par exemple Debian, vous faites de la rhétorique sur un mot en réponse à un autre commentaire en essayant de trouver une "faille" dans la présentation (mots) de ladite idée. Pourquoi pas mais je ne suis pas convaincu de là où cela mène. :-)

C'est une astuce pour réécrire partiellement une recette de construction. Je ne vois pas en quoi cela casse la composition. En revanche oui, cela peut rendre plus fragile certains paquets.

Désolé, tu viens de contre-vendre le projet.
Moi, ce que je veux, c'est une distro qui concurrence la solidité et la simplicité réelle de debian. Et par simplicité réelle, j'entends… comment dire… ouvres donc un ficher .deb, tu verras.

Je suis désolé pour vous parce que vous passez à côté d'un changement de paradigme en terme de gestion de paquets à cause de simples arguments de rhétorique.

Et si l'on cherche la petite bête, les méta-paquets de chez Debian présentent exactement le même type de fragilité mais cela ne semble pas vous poser de problème. Mais je dis ca, je dis rien. ;-)

---

Bref, j'ai essayé de répondre au mieux aux commentaires en présentant les concepts et en mettant des liens pointant vers la documentation.

Honnêtement, si vous n'avez pas envie d'aller voir par vous même, je ne vois pas trop ce que moi je peux faire de plus ; à part troller. :-)

Ou il y a une autre option paraphrasant vos mots :

Il suffit de dire qu'on doit essayer de changer ça parce qu'on en a pris conscience, le fait que de pouvoir collectivement vérifier "l'organe initial" pour lui faire confiance.

Finalement, si je comprends bien, c'est la même conclusion concernant la reproductibilité que pour n'importe quel outil utilisant le schéma d'une distribution classique : il y a toujours un hic quelque part car les distributions classiques sont doomed en fait. :-)

Plus de propagande là : ;-)
https://archive.fosdem.org/2019/schedule/event/gnu_guix_new_approach_to_software_distribution/

Pour partager du code le mieux ça reste de faire de la composition

C'est difficile de tout expliquer dans des commentaires ici et là. ;-)

A l'essentiel: Guix compose. :-)

Cette histoire d'inherit est un artefact dans la grande histoire de Guix. :-)
C'est une astuce pour réécrire partiellement une recette de construction. Je ne vois pas en quoi cela casse la composition. En revanche oui, cela peut rendre plus fragile certains paquets.

Doit-on considérer que le même code source compilé par 2 compilateurs est la même version ou non ? Qu'est-ce qu'une même version ? Code source identique ? Binaire identique ? Résultat identique ?

Je ne vois pas vraiment l'intérêt pour un utilisateur d'avoir, au niveau système, plusieurs build d'un programme avec plusieurs compilos… pour un développeur, ok, mais un programmeur fera de toute façon ses tests dans un dossier local.

L'intérêt est double:

• sécurité
• science computationnelle reproductible.

Le seul moment ou je vois un problème potentiellement posé par la compilation d'un même source avec les mêmes options de build par un compilateur différent, c'est pour une bibliothèque dont l'ABI peut changer. Et ce problème est habituellement contourné par les bibliothèques elles-mêmes quand elles sont bien foutues (par exemple en utilisant pimpl).

De ce que je comprends, vous définissez même par: code source identique et résultat identique.

C'est le cas d'usage le plus courant. Mais il faut garder en tête :

• Que vous n'avez aucune garantie que le compilateur n'a pas introduit de code frauduleux. C'est ce que l'on appelle la Trusting Trust attaque et le problème du bootstrapp.

Le papier par Ken Thompson himself :
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

Et une vidéo en anglais très didactique—il faut faire abstraction de l'application (bitcoin) car cela s'applique à n'importe quel programme compilé :
https://www.youtube.com/watch?v=I2iShmUTEl8

• En calcul scientifique, si on dit que l'on fait de la Science, cela signifie que l'on doit contrôler au maximum son environnement d'exécution pour trouver l'origine des différences et donc contrôler les erreurs—ou disons plutôt fournir une preuve de confiance.

Une vidéo expliquant les enjeux se trouve là :
https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible

Je pense plutôt que c'est moi qui ne comprend pas à quoi sert ton héritage ni (hum… c'est chiant en vrai de faire un ou inclusif en langage parlé…) comment ça marche.

Cela permet de ré-écrire partiellement la recette d'une paquet.

Je trouve honnêtement le concept intéressant, mais pour moi sa plus grosse et principale force, c'est le fait qu'il semblerait invalider complètement une suite d'actions si une installation échoue, et ça, dpkg ne sait pas le faire, ses frontaux non plus.

Je crois que RPM est capable de faire du transactionnel.

Par contre, je me demande si la raison est vraiment le fait que nix/guix soient fonctionnels, justement.

Le fait d'être "fonctionnel" rend les transactions faciles à implémenter. Ou disons plus facile que dans les approches "classiques" de gestion de paquets.

Enfin, l'histoire ainsi que le fait que le noyau linux (ou sont-ce extX les coupables?) ne permette pas, à ma connaissance, de réellement verrouiller un fichier

Oui, c'est légitime comme question. Et à ma connaissance il n'y a pas encore vraiment de réponse par manque d'observation.

Guix fait l'hypothèse (forte) qu'il y a suffisamment de stabilité dans le noyau, le système de fichiers, etc. pour ne pas influencer sur la transparence binaire. Mais oui il y a une question pertinente sur l'effet du hardware.

Cependant, qui peut le plus peut le moins. ;-)

---

Merci de poser toutes ces questions. C'est intéressant d'avoir un retour. :-)

Je me permets de faire un petit résumé.

Guix est un gestionnaire de paquets transactionnel et inclut nativement la coexistence de plusieurs versions (les modulefiles et consort en beaucoup mieux), il permet de faire du roll-back et de voyager dans le temps, il inclut nativement la génération de conteneur (Docker, Singularity, tarball relocatable), il permet de travailler nativement dans un conteneur, il prend au sérieux les problèmes de bootstrap, et j'en passe d'autres; comme le fallback vers Software Heritage si les sources upstream ont disparues, etc..

Alors oui chaque fonctionnalité prise individuellement existe ici ou là. Mais il n'y a aucun outil qui les intégrè aussi bien—sauf la grande tante Nix :-).

Et oui il y a encore des questions ouvertes, en particulier sur la transparence binaire.

Mais aujourd'hui, le vrai problème de Guix est une base d'utilisateurs assez petite donc des retours d'expériences assez peu nombreux. N'hésitez pas à essayer, il n'y a rien à faire avec le script d'installation et cela sera totalement transparent pour votre distribution. Puis venez râler en francais ou en anglais que cela ne convient pas sur help-guix@gnu.org. :-) Tous les retours sont bons à prendre. ;-)

En passant, Vagrant est en train de l'empaqueter pour Debian. ;-)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850644#56
Donc n'hésitez pas du côté Debian non plus.

Guix/nix font probablement toutes ces choses mieux (l'inverse serais dommage), ils ne les ont pas forcément inventé et les gens n'ont pas attendu nix pour proposer des solutions

On n'est pas à un concours pour le prix Nobel mais pour le coup, il me semble que oui : appliquer les principes de programmation fonctionnelle à la gestion de paquets n'avait jamais été fait avant les débuts de Nix en 2003. Mais je peux me tromper, si tu as des références à ce sujet, ça m'intéresse.

Concernant Debian, il y a eu cette présentation à DebConf14.

http://debconf14-video.debian.net/video/311/seeing-debian-through-a-functional-lens

Toujours est-il que Nix—et Guix=Guile+Nix ;-)—est à mon avis un changement de paradigme dans la gestion des paquets. Comme tout paradigme différent, tout n'est pas orthogonal. :-)

Tu le construis avec quels outils ?

Avec 2 outils: un peu de magie et beaucoup d'amour. ;-)

Le terme "le" se réferre à paquet, n'est-ce pas?

C'est toute la machinerie du boostrapp. Au lieu de faire une longue explication ici, le mieux me semble-t-il est d'aller voir la documentation officielle. :-)

https://guix.gnu.org/manual/en/html_node/Bootstrapping.html#Bootstrapping

En particulier, cette section

https://guix.gnu.org/manual/en/html_node/Preparing-to-Use-the-Bootstrap-Binaries.html#Building-the-Build-Tools

Pour ce qui concerne le C, GNU Mes a fait un gros boulot et la graine commence à être raisonnable. :-)

Je veux bien mais tu va devoir faire confiance au binaire de ce compilateur si j'ai bien compris.

GNU Mes est une histoire en soi. :-)

Le but est de réduire la taille des binaires auxquels on fait confiance. Ceci pour réduire la surface d'une attaque Trusting Trust.

Discuter et analyser la taille de ces binaires est déjà un pas en avant. Je ne sais pas où en est Debian, je suis un peu perdu avec le "stage0" de Gentoo et je ne sais pas du tout comment Arch fait.

Se passer d'une étape de compilation est extrêmement complexe, c'est pas une question de guix, nix ou apt. Si tu veux remettre en cause les dépôts de ton outils, il y a soit un compilateur à qui tu es contrains de faire confiance soit tu prends des étapes hyper relous de construction d'un compilateur from scratch (tu fais confiance à quel éditeur hexa décimal ? ;)

Oui c'est un problème compliqué. :-)
Et oui cela dépasse le cadre de Guix et autres.
Cependant, ce n'est pas pour cela qu'il n'y a pas de question. ;-)

Et une des choses que Guix fait—entre autres—est de fournir des outils pour avoir une vision plus claire sur cette chaine de production source->binaire. Pour le dire clairement, il y a une plus grande transparence binaire, à mon humble avis.

Ces étapes "hyper relous" sont déjà avancées.

https://gitlab.com/janneke/stage0
https://bootstrapping.miraheze.org/wiki/Stage0

normalement la version que tu proposes est traduite à 100%.

Il y a encore des choses à faire… :-)

https://guix.gnu.org/manual/fr/html_node/Invoking-guix-time_002dmachine.html#Invoking-guix-time_002dmachine

Par contre, je suis convaincu qu'on peut trouver mieux que « récupère le .po, modifie-le et envoie-moi le diff ».

+1 :-)

Mais je n'ai aucune idée :-(

Par contre, je suis convaincu que guix deploy utilise le bon modèle de déploiement (sans état) contrairement à Ansible & Co.

Connais-tu propellor ?

http://propellor.branchable.com/

Dans Guix, il n'y a pas de notion de stable vs instable. Donc je ne comprends pas cette phrase.

Ça concernait NixOS, qui a plusieurs canaux de base (stable, unstable) alors qu'on n'a que le canal par défaut dans Guix (donc l'équivalent de unstable). Et oui c'est long à mettre à jour ou installer des paquets, parce qu'il n'y a pas toujours des substituts, et que les paquets sont pas forcément très bien découpés, ce qui fait augmenter le nombre de dépendances inutiles.

Cela correspond à changer de branche / canal avec guix pull, non ?

Et donc le calcul de la dérivation est long, c'est ca ? Je ne vois pas pourquoi il devrait être "plus long".

Concernant la disponibilité de substituts, c'est comparer des pommes et des oranges. ;-)

C'est une information qui fait partie du paquet, donc tu peux l'installer et tu peux la vérifier de la même manière. Évidemment il peut y avoir un problème au bootstrap, mais je présume qu'ily een a un aussi aussi avec ta solution.

Pour faire simple, la graine utilisée pour bootstrapper est donnée par le commit de Guix.

$ guix describe
Generation 10   Sep 03 2018 17:32:44    (current)
  guix e0fa68c
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: e0fa68c7718fffd33d81af415279d6ddb518f727

https://guix.gnu.org/manual/en/html_node/Invoking-guix-describe.html#Invoking-guix-describe

Imaginons que l'on ait la définition du paquet foo là chemin/du/paquet—et ce paquet n'est pas dans l'arbre officiel.

Connaissant le commit, je peux à n'importe quel moment réutiliser la même graine et donc construire le paquet.

guix time-machine --commit=e0fa68c -- build -L chemin/du/paquet foo

Et le résultat sera toujours le même. Enfin devrait. ;-)

En revanche, le résultat de guix build -L chemin/du/paquet foo dépendra de l'état (commit) dans lequel je me trouve au moment où je lance ladite commande.

La machinerie (côté Guix) est là mais tout n'est pas résolu non plus (côté dev. des langages).

Pour ce qui concerne le C, GNU Mes a fait un gros boulot et la graine commence à être raisonnable. :-)

Mais pour d'autres langages, c'est encore assez compliqué. Voir ce qui est fait pour Rust.

Ne parlons pas d'Haskell. ;-)

etc.

https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/
https://guix.gnu.org/blog/2018/bootstrapping-rust/
https://www.joachim-breitner.de/blog/748-Thoughts_on_bootstrapping_GHC