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.
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.
[^] # Re: Mal connaître sa distribution
Posté par zimoun . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 3.
Peut-être commencez par cela. ;-)
Attaque Trusting Trust par exemple.
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 ;-))
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. :-)
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 ? ;-)
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
.narmanuellement.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.
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.