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 ;-))
Pour le coup, ce que j'imagine être la méthode scientifique c'est, en gros, observer un certain nombre de cause et de résultats, essayer de déduire la règle, puis prouver qu'elle est relativement juste avec un jeu d'expériences, preuve qui doit être validée par d'autres.
Mes propos restent vagues, c'est normal, c'est pas mon domaine. Par contre, je trouve pas ça si pompeux que ça.
Pour être explicite, le compilateur peut introduire une backdoor à la compilation.
Mais il faut bien partir d'un binaire exécutable, parce que sinon, on doit se fier a un humain au niveau de l'intention et de la qualité (faut bien le construire, le 1er compilo). Dans le cas des compilateurs, c'est déjà le cas, mais on peut tester avec un certain nombre d'implémentations les résultats, plus ou moins, via fuzzing.
C'est pas idéal, mais ça me semble la seule solution avec un vrai potentiel de confiance. Et sur ce point, l'absence de standardisation de l'ABI du C et du C++ seraient, ironiquement, une force, alors que ça cause tant de problèmes de portabilité...
Enfin moi cela ne me dérange pas d'utiliser GHC parce qu'Haskell c'est chouette
Voila, la, je te rejoins :)
Bon, pas sur l'haskell parce que je connaît pas, mais je rejoins le fait qu'on doive faire l'équilibre entre la confiance et le sympa. Perso, un de mes arguments pour le C ou le C++, c'est que, justement, on a plusieurs implémentations, et je pense que pouvoir tester un code sur toutes ces implémentations est une force dont peu de langages «sûrs» peuvent se targuer (hein, rust?).
Je joue le conservatisme sur ce point.
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.
Magnifique. Merci, même si, pour moi, l'ingénierie est un peu une science de la pratique: on a observé que telle combinaison marche dans certaines situations, mais une autre est meilleure. On sait pas pourquoi, certes. Du coup, un mélange de science, d'expérience et d'intuition?
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 ? ;-)
Ça m'amuserais énormément d'améliorer mes opinions lors d'une rencontre physique.
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.
Justement, je pense que les étiquettes officielles sont foireuses, quand on ouvres un peu les boîtes. Par exemple, Debian dispose de plusieurs outils pour gérer packages et dépôts: apt, apt-get, aptitude, dselect, synaptics... leur point commun? L'outil qui installe le paquet dans le système. Et cet outil, c'est dpkg. Pour moi, c'est lui, le vrai gestionnaire de paquets, mais j'aime le low level, j'aime avoir la maîtrise de mes systèmes, je suis probablement pas dans la norme.
Abus de langage.
Qui est commun et difficile a ne pas faire, je pense. Ou peut-être que je n'ai pas la même définition, c'est un problème récurrent...
Mais on ne manipule jamais un fichier .nar manuellement.
C'est aussi ce qu'on dit d'un fichier .deb, mais moi, dans la pratique, tant a titre perso que professionnel, ça m'arrive chaque semaine.
La raison principale, c'est que l'environnement officiel de debian est trop complexe. Par contre le format est bien documenté, et facile a implémenter de façon très automatique en shell, si on se contente d'un jeu de fonctionnalités (en gros: ne pas utiliser pré/post rm/inst, dont le résultat final est trop complexe pour mon esprit simple).
Ah, quand j'évalue un logiciel, je tends a... lire le code et les formats. Pour que, si un jour un problème surviens, je puisse le patcher. Parce que c'est bien beau d'avoir le droit, encore faut-il avoir les compétences pour. Hors, un deb, je pourrais l'ouvrir avec un éditeur hexa, si besoin est. C'est une qualité non négligeable pour moi.
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 ?
Le fait de garantir un truc que même les manpages disent que ce n'est pas garantit. À savoir, que sur les FS de linux, il semble être impossible de garantir qu'un autre process n'écrit pas en même temps sur le même fichier, parce que les verrous sont juste informatifs, si un process ne veux pas les respecter, il peut ne pas le faire.
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.
Pas de soucis, j'ai bien conscience de ce que peux ou non un gestionnaire de paquet. Je pense depuis longtemps que l'approche de Nix/Guix est intéressante, sinon je n'aurais pas pris la peine de répondre.
Hélas, les TODOlist des geeks ont tendance a s'allonger plus vite qu'autre chose, mais, honnêtement, il me suffirais de pas grand chose, genre, un outil qui permets de naviguer et manipuler les paquets installés (idéalement en ncurses), pour que j'adopte. Parce que pour moi, les forces de Debian, c'est 1) sa stabilité, et 2) aptitude.
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 4.
Je sais qu'il est tard, mais bon...
Pour le coup, ce que j'imagine être la méthode scientifique c'est, en gros, observer un certain nombre de cause et de résultats, essayer de déduire la règle, puis prouver qu'elle est relativement juste avec un jeu d'expériences, preuve qui doit être validée par d'autres.
Mes propos restent vagues, c'est normal, c'est pas mon domaine. Par contre, je trouve pas ça si pompeux que ça.
Mais il faut bien partir d'un binaire exécutable, parce que sinon, on doit se fier a un humain au niveau de l'intention et de la qualité (faut bien le construire, le 1er compilo). Dans le cas des compilateurs, c'est déjà le cas, mais on peut tester avec un certain nombre d'implémentations les résultats, plus ou moins, via fuzzing.
C'est pas idéal, mais ça me semble la seule solution avec un vrai potentiel de confiance. Et sur ce point, l'absence de standardisation de l'ABI du C et du C++ seraient, ironiquement, une force, alors que ça cause tant de problèmes de portabilité...
Voila, la, je te rejoins :)
Bon, pas sur l'haskell parce que je connaît pas, mais je rejoins le fait qu'on doive faire l'équilibre entre la confiance et le sympa. Perso, un de mes arguments pour le C ou le C++, c'est que, justement, on a plusieurs implémentations, et je pense que pouvoir tester un code sur toutes ces implémentations est une force dont peu de langages «sûrs» peuvent se targuer (hein, rust?).
Je joue le conservatisme sur ce point.
Magnifique. Merci, même si, pour moi, l'ingénierie est un peu une science de la pratique: on a observé que telle combinaison marche dans certaines situations, mais une autre est meilleure. On sait pas pourquoi, certes. Du coup, un mélange de science, d'expérience et d'intuition?
Ça m'amuserais énormément d'améliorer mes opinions lors d'une rencontre physique.
Justement, je pense que les étiquettes officielles sont foireuses, quand on ouvres un peu les boîtes. Par exemple, Debian dispose de plusieurs outils pour gérer packages et dépôts: apt, apt-get, aptitude, dselect, synaptics... leur point commun? L'outil qui installe le paquet dans le système. Et cet outil, c'est dpkg. Pour moi, c'est lui, le vrai gestionnaire de paquets, mais j'aime le low level, j'aime avoir la maîtrise de mes systèmes, je suis probablement pas dans la norme.
Qui est commun et difficile a ne pas faire, je pense. Ou peut-être que je n'ai pas la même définition, c'est un problème récurrent...
C'est aussi ce qu'on dit d'un fichier .deb, mais moi, dans la pratique, tant a titre perso que professionnel, ça m'arrive chaque semaine.
La raison principale, c'est que l'environnement officiel de debian est trop complexe. Par contre le format est bien documenté, et facile a implémenter de façon très automatique en shell, si on se contente d'un jeu de fonctionnalités (en gros: ne pas utiliser pré/post rm/inst, dont le résultat final est trop complexe pour mon esprit simple).
Ah, quand j'évalue un logiciel, je tends a... lire le code et les formats. Pour que, si un jour un problème surviens, je puisse le patcher. Parce que c'est bien beau d'avoir le droit, encore faut-il avoir les compétences pour. Hors, un deb, je pourrais l'ouvrir avec un éditeur hexa, si besoin est. C'est une qualité non négligeable pour moi.
Le fait de garantir un truc que même les manpages disent que ce n'est pas garantit. À savoir, que sur les FS de linux, il semble être impossible de garantir qu'un autre process n'écrit pas en même temps sur le même fichier, parce que les verrous sont juste informatifs, si un process ne veux pas les respecter, il peut ne pas le faire.
Pas de soucis, j'ai bien conscience de ce que peux ou non un gestionnaire de paquet. Je pense depuis longtemps que l'approche de Nix/Guix est intéressante, sinon je n'aurais pas pris la peine de répondre.
Hélas, les TODOlist des geeks ont tendance a s'allonger plus vite qu'autre chose, mais, honnêtement, il me suffirais de pas grand chose, genre, un outil qui permets de naviguer et manipuler les paquets installés (idéalement en ncurses), pour que j'adopte. Parce que pour moi, les forces de Debian, c'est 1) sa stabilité, et 2) aptitude.