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.
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.
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. ;-)
[^] # Re: Mal connaître sa distribution
Posté par zimoun . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 2.
L'intérêt est double:
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 :
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
Une vidéo expliquant les enjeux se trouve là :
https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
Cela permet de ré-écrire partiellement la recette d'une paquet.
Je crois que RPM est capable de faire du transactionnel.
Le fait d'être "fonctionnel" rend les transactions faciles à implémenter. Ou disons plus facile que dans les approches "classiques" de gestion de paquets.
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
modulefileset 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.