Mais une question que j'avais posée est : qu'est-ce qui peut pousser un développeur à utiliser cette fonction en dehors des bornes 0 .. 63 ?
Là tu veux dire que tu trouves rare ce genre de situation ?
la majorité des codes l'utilisant se retrouveraient pénalisés d'un test inutile sur X86
Et là tu veux dire que finalement tu trouves fréquente ce genre de situation ? J'avoue que suis un peu perdu dans ce que tu me dis.
J'émettais bien l'hypothèse que les situation où on avait besoin de sortir de ces bornes étaient rares. En conséquence, la grande majorité de codes utilisant shift_right se retrouveraient pénalisés d'un test inutile sur X86 si les implémenteurs de langage haut niveau choisissaient tous ton approche, pour la simple est bonne raison qu'il ne sortiront jamais de ces bornes et que ce test dynamique s'avérait inutile pour eux. Certains langages, dont OCaml fait partie, semblent avoir fait le choix de ne garantir le bon comportement que sur l'intervalle O .. 63 pour des raisons tout à fait légitimes d'efficacité et de le documenter. Ainsi les cas exceptionnels qui ont besoin de sortir de ces bornes doivent coder leur propre fonction avec un test sur la valeur de l'entrée. C'est un choix qui me semblent tout à fait convenable d'un point de vue pragmatique. Tu dois bien reconnaître que ton projet est un cas bien particulier à but pédagogique que des programmeurs réaliseront peut dans la réalité. Rust va même jusqu'à refuser de compiler s'il détecte statiquement que l'on sort de ces bornes.
Une approche peut être plus mixte est celle de Haskell, qui se comprend et se tient aussi : mais tout cela reste une question de choix. Je suis allé voir le code qui nous intéresse et l'on trouve :
-- Wrappers for the shift operations. The uncheckedShift# family are-- undefined when the amount being shifted by is greater than the size-- in bits of Int#, so these wrappers perform a check and return-- either zero or -1 appropriately.---- Note that these wrappers still produce undefined results when the-- second argument (the shift amount) is negative.-- | Shift the argument left by the specified number of bits-- (which must be non-negative).shiftL#::Word#->Int#->Word#a`shiftL#`b|isTrue#(b>=#WORD_SIZE_IN_BITS#)=0##|otherwise=a`uncheckedShiftL#`b-- | Shift the argument right by the specified number of bits-- (which must be non-negative).-- The "RL" means "right, logical" (as opposed to RA for arithmetic)-- (although an arithmetic right shift wouldn't make sense for Word#)shiftRL#::Word#->Int#->Word#a`shiftRL#`b|isTrue#(b>=#WORD_SIZE_IN_BITS#)=0##|otherwise=a`uncheckedShiftRL#`b
Ce qui revient peu ou prou à implémenter les fonctions << et >> comme je l'ai fait plus haut en OCaml à partir des versions fournies par la bibliothèque standard dans le module Int64. Les implémenteurs de la bibliothèque standard OCaml n'ont pas choisi cette approche, laissant le soin aux développeurs qui en ressentent le besoin de le faire eux même.
Cela étant il reste la question de la circularité du second argument, qui ne pose pas de problème en ADA, mais qui en pose un en Haskell :
Raison pour laquelle j'avais posé la question qui, elle aussi, n'était pas dénuée de fondements. ;-)
Et puis bon, c'est quand même étrange de fournir, à haut niveau, un opérateur qui fournit le même quotient par 2^64 que par 1 dans un langage de haut niveau sous prétexte que certains processeurs ont ce comportement pour de simples raisons d'optimisation.
J'espère t'avoir fait comprendre que, bien que le comportement puissent apparaître étrange lorsqu'on l'ignore, ce n'était pas un choix dénué de fondements ni sans justifications tout à fait recevables. Le seul reproche que l'on peut faire à freePascal est de ne pas le documenter mais non d'avoir un tel comportement.
Sinon toujours en étant taquin, en poussant ton principe à l'extrême, je pourrais dire : un langage qui a besoin de tests unitaires n'est pas un langage haut niveau digne de ce nom. :-P
Cette présentation est celle d’un chercheur vieillissant qui porte un regard historique sur les trente dernières années de son travail.
Il y a deux sortes de chercheurs : les prolifiques et les monomaniaques. Je fais partie de la seconde catégorie, car j'ai toujours pratiqué le même genre d’investigations, à savoir la spécification et la construction vérifiée de systèmes informatisés.
Ce travail, autant théorique que pratique, s’est concrétisé au cours de toutes ces années dans trois formalismes voisins : Z, B et Event-B (dont je ne suis pas, loin de là, le seul contributeur). Je vais tenter d’expliciter comment les idées que contiennent ces formalismes et les outils correspondants ont lentement émergés de façon parfois erratique.
Je tenterai aussi de préciser les multiples influences qui ont participé à cette évolution. En particulier, je montrerai comment plusieurs réalisations industrielles ont permis de progresser dans ce domaine. Mais je soulignerai aussi les échecs et parfois les rejets de la part de communautés tant universitaires qu’industrielles.
Pour finir, je proposerai quelques réflexions et approches pour le financement de recherches telles que celle-ci.
Présentation dont j'extrais deux diapos :
la RATP décide de supprimer les tests unitaires et d'intégration
Octobre 98 : lancement de la ligne 14
Depuis lors pas de problèmes avec le logiciel développé avec [soit 17 ans plus tard, et il tourne, tourne, tourne…]
pour remplacer l'ancienne méthodologie avec tests unitaires par celle-ci :
86.000 lignes en ADA ont été produites automatiquement
27.800 preuves ont été faites
92% ont été prouvés automatiquement par l'Atelier B
Coût des preuves interactives : 7 hommes-mois
Les preuves interactives sont moins chères que les tests
Tu vois ADA lui aussi n'est pas assez « haut niveau » finalement. En fait Ada est à la méthode B ce que OCaml est à Coq : le langage dans lequel est écrit son noyau ainsi que le langage cible vers lequel il « compile ». Coq qui a servi, par exemple, à ecrire un compilateur C certifié correct. Ce sont là des exemples de ce que peut faire la rigueur de la formalisation mathématique pour garantir l'absence de bug dans un logiciel, à condition d'être effectuée avec les outils et les langages adéquats. ;-)
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
J'ai d'ailleurs une autre question : en ADA le type natural est-il lui aussi cyclique ou, sinon, que se passe-t-il lorsque l'on arrive aux bornes ? Dans plein de langage, dont OCaml, le type du second paramètre est lui aussi cyclique (le type int c'est Z/2^63Z en 64 bits) ce qui ne ferait que repousser le comportement observé de manière tout aussi étrange lui aussi.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Pour ce que doit faire le shift_right, on est d'accord : il décale à droite et remplace les trous par des zéros. Mais une question que j'avais posée est : qu'est-ce qui peut pousser un développeur à utiliser cette fonction en dehors des bornes 0 .. 63 ? C'est pour cela que j'avais écrit qu'elle ne faisait vraiment sens que sur cette intervalle. Dans quel contexte va ton réellement lui passer les valeurs 64, 65 ou tout autre supérieure ? Et cela ce n'est pas sans incidence pour un implémenteur de langage haut niveau. Comme tu l'as montré pour ADA : si on évite les valeurs supérieures à 63, on évite un test de comparaison à chaque exécution sur une architecture X86. Quelle intérêt un code pourrait avoir, sur une telle instruction, de se rendre dans un domaine où la sortie vaut toujours 0 ? Et je pense que la raison qui à présider au choix de laisser le comportement non défini en dehors de ces bornes sont des raisons de performances générales : la majorité des codes l'utilisant se retrouveraient pénalisés d'un test inutile sur X86. C'était là le fruit de mes « spéculations », comme celles de Def. Et c'est aussi ce que dit wikipédia :
This helps allow C compilers to emit efficient code for various platforms by allowing direct use of the native shift instructions which have differing behavior.
Ensuite sur ce que fait X86, je n'ai pas dit que c'était délibéré de leur part (bien que ma formulation pouvait laisser penser le contraire) mais je ne faisais que décrire, en me basant sur son comportement, la structure mathématique qui lui correspondait : un opérateur sur un tore, son domaine se ramenant de fait à Z/2^64Z x Z/64Z. Que peut-il servir à modéliser en pratique dans le quotidien d'un programmeur, j'en sais foutre rien et je m'en fout un peu à vrai dire. Mais c'est plus drôle qu'une fonction stationnaire, et c'est joli un donut ! :-P
Quoi qu'il en soit, pour un langage haut niveau qui reproduit l'instruction machine, le développeur ne peut pas s'appuyer sur le comportement de shr sur X86 s'il veut un tel comportement, mais le coder lui-même s'il veut un code portable. Comme il doit le coder lui-même s'il veut que la sortie soit constamment égale à 0.
Pour ce qui est de ton autre question pour OCaml sur PowerPC, je suppose que la réponse est : la sortie est stationnairement nulle à partir de 64. Ce qui est sans doute aussi le cas en C ou C++. Mais je n'ai pas de telle machine à disposition, ni de ARM, pour vérifier.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Je te rejoins quasiment en tout point. Sauf sur le point clé suivant: […]
Effectivement, c'est sur ce point que l'on diverge. C'est lorsque tu écris : « [elle] ne devrait répondre qu'au seul problème du quotient d'un entier machine entre 0 et 2n - 1 par une puissance positive quelconque de 2 » en parlant de la primitive shift_right. Pour moi, elle ne devrait rien être, mais elle est ce que l'implémenteur a décidé qu'elle serait. C'est tout le problème de la spécification d'un code. C'est pour cela que j'avais écrit :
En conséquence, la seule chose à faire si l'on veut savoir ce que fait une fonction, c'est d'aller lire la doc : on ne peut pas se fier uniquement à son type ni à ses attentes. Et le seul moyen de vérifier qu'elle se comporte exactement comme le spécifie la doc, c'est d'aller lire le code d'où la condition sine qua non que celui-ci soit publiquement accessible. Voilà une leçon que pourront retenir tes étudiants de cet exercice.
C'est un peu comme Hilbert qui disait qu'en géométrie on s'en fout des noms point, droite ou plan et qu'on pourrait les remplacer par chope de bière, chaise et table : ce qui compte c'est l'axiomatique des structures. Dans toute cette histoire, moi ce que je vois c'est que certains langages ne te fournissent pas de base l'axiomatique que tu souhaiterais. Ce à quoi je te réponds : ils te donnent néanmoins les moyens de construire la structure que tu désires. D'ailleurs au sujet de ADA, je suis allé voir la documentation est le moins que l'on puisse dire c'est que ni le type, ni son complément dans la documentation ne permet de savoir c'est que fait cette fonction shift_right. Même grâce au complément en langue anglaise, je trouve que l'on a là une sous-spécification de son comportement. Au moins, dans certains langages qui ne font pas ce que tu souhaites, avec la documentation on sait ce qu'elle doit faire.
Au fond ce que je vois, c'est qu'on a un opérateur qui agit sur un cylindre : produit cartésien d'un anneau Z/nZ avec un domaine fini. Toi tu veux que l'on prolonge le cylindre en saturant sur sa valeur au bord (ARM), d'autres recollent les bouts et opèrent sur un tore (X86). Ce qui compte surtout c'est qu'il soit possible de faire des découpages et des collages pour construire la structure que l'on souhaite, et cela tous les langages le permettent. Le rôle d'un langage de haut niveau c'est de fournir des moyens plus abstrait que l'assembleur pour effectuer ces constructions puis de passer la main au compilateur pour traduire le tout en code machine. Apprendre un langage donné consiste essentiellement à apprendre les méthodes de construction qu'il fournit pour définir des structures ainsi que les moyens pour opérer sur celles-ci.
Ce que tes étudiants ont expérimenté c'est qu'un tore est cyclique sur ces deux dimensions et qu'il n'a pas du tout la même géométrie qu'un cylindre. Ce qui me rappelle un épisode des Simpson dans lequel Stephen Hawking était très intéressé par la théorie d'Homer selon laquelle l'Univers avait la forme d'un Donuts. :-P
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Je me permets de concentrer dans ce commentaire ma réponse à celui-ci ainsi qu'à cet autre commentaire, étant donné que tu y reprends les mêmes idées. Tu as été clair malgré l'heure tardive, j'espère pouvoir faire de même en cette heure plus matinale.
Il me semble que dans ton approche de la question, tu mélanges plusieurs problématiques. Dans l'exemple que tu donnes ici, tu montres surtout comment un système de type avancé (ici une forme restreinte de type dépendant) permet d'être plus précis sur la spécification d'un code et comment un compilateur peut en tirer partie pour générer un code optimisé (ici en supprimant un test de comparaison à l'exécution rendu inutile par ton type amount). Cela rejoint un exemple que j'avais donné dans la dernière dépêche sur Haskell, où je montrais comment utiliser les GADT (types de données algébriques généralisés) pour exprimer la proposition : « tout arbre binaire parfait non vide a une racine ». Ce qui permettait de coder la fonction qui extrait cette racine sans que le code généré par le compilateur ait à vérifier à l'exécution que l'arbre était non vide (c'était déjà spécifié dans le type de la fonction).
Revenons à présent au sujet précis du journal : le décalage à droite bit à bit. Dans un autre commentaire, tu précises à bon droit que l'arithmétique modulaire est la base de tous les processeurs courants et dans le cas présent on fait de l'arithmétique dans l'anneau Z/nZ avec n = 2^64. Se pose alors la question que doit faire cette fonction de décalage à droite ? et tu réponds toi même : « [elle] ne devrait répondre qu'au seul problème du quotient d'un entier machine entre 0 et 2n - 1 par une puissance positive quelconque de 2 ». Ce à quoi je te répondrai : l'architecture X86 fait cela en restant dans le cadre de l'arithmétique modulaire, et ne la mélange pas avec de l'arithmétique sur les entiers. En effet prenons le type de cette fonction : function my_shr (u : unsigned_64; a : natural) return unsigned_64. Elle prend en paramètre un entier non signé sur 64 bits, un entier naturel et renvoie un entier non signé sur 64 bits. Or pour opérer au sein de l'anneau sus-mentionné, elle doit donc associer un élément de cette anneau au paramètre a : natural, puis renvoyer ensuite le quotient d'une division euclidienne effectuée au sein de l'anneau. Les processeurs X86 on fait le choix de prendre l'élément 2 ^ (a % 64), ce qui peut sembler assez « naturel » lorsque l'on pratique l'arithmétique modulaire. Exemple en OCaml sur mon X86 :
En revanche, de ce que j'ai compris, l'architecture ARM ne voit pas cela du tout comme une opération d'arithmétique modulaire, mais semble considérer une telle donnée (un entier non signé sur 64 bit) comme un suite finie de 0 et de 1 ou plutôt comme une suite stationnaire de valeur nulle à partir du rang 64 et si tu lui donne la suite u(n) elle te renvoie la suite u(n+a). Ce qui semble être le comportement que tu souhaiterais, mais ce n'est pas du tout le point de vue de l'arithmétique modulaire. Autrement dit, elle voit un entier de 64 bit comme un entier naturel compris entre 0 et 2^64 - 1 représenté en base 2, effectue une division euclidienne par une puissance de 2 et opère donc sur l'ensemble des entiers naturels.
Viens maintenant le problème des langages compilés et de la spécification qu'ils donnent à une telle primitive. Ils pourraient tout à fait faire un choix strict et défini en optant pour la vision modulaire à la X86 ou la vision entière à la ARM. La plupart on choisit d'utiliser pour chaque architecture la primitive correspondante du processeur et elle n'est donc spécifiée et définie que sur le domaine où elles coïncident, à savoir 0≤ a < 64. Si le programmeur veut une fonction plus fortement spécifiée, alors il n'a qu'à la coder lui-même.
Tu concluais ton commentaire réponse par : « c'est pour ça que j'adore l'Ada, vous l'aurez remarqué :) », je terminerai le mien par j'adore le lamba-calcul typé et rien de plus normal pour le mathématicien et logicien que je suis :) Le lamba-calcul typé (dont font partie les langages comme Haskell, OCaml ou Coq) a pour principe fondamental la correspondance preuve-programme : une programme est la preuve d'un théorème dont l'énoncé est le type ! \o/
Si l'on prend le langage qui a le système de type le plus sophistiqué (Coq), je te laisse deviner ce que fait une fonction dont le type est « pour tout (n: nat), il existe (p:nat) tel n ≤ p et p soit premier » si on lui passe un entier en entrée. En Coq, cela pourrait se définir ainsi :
Definitiongreater_prime(n:nat):={p:nat|n<=p/\primep}.Theoremma_fonctionn:greater_primen.Proof.(* la preuve *)Qed.
Pas besoin d'aller lire la doc pour savoir ce que fait la fonction, la lecture de son type suffit à cela. ;-)
Au final si j'étais un peu taquin, en se basant sur la popularité des langages de programmation je dirais qu'à l'heure actuelle la programmation consiste, la plupart du temps, dans l'art de faire des mathématiques comme un goret dans des langages atrophiés. En conséquence, la seule chose à faire si l'on veut savoir ce que fait une fonction, c'est d'aller lire la doc : on ne peut pas se fier uniquement à son type ni à ses attentes. Et le seul moyen de vérifier qu'elle se comporte exactement comme le spécifie la doc, c'est d'aller lire le code d'où la condition sine qua non que celui-ci soit publiquement accessible. Voilà une leçon que pourront retenir tes étudiants de cet exercice.
Comme tu enseignes les mathématiques, si le sujet t'intéresse il y a un dossier sympa sur le sujet dans la gazette des mathématiciens d'octobre 2014 : théories des types et mathématiques certifiées, et la théorie homotopique des types pousse encore plus loin la correspondance que j'ai signalée plus haut et fournit des fondements élégants à l'ensemble de l'édifice mathématique.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Merci beaucoup pour toutes ces précisions, je comprends mieux ce qui se passe (ainsi que l'organisation interne du compilateur).
Et ça peut expliquer pourquoi une sémantique sous-spécifiée a été choisie (mais je spécule) : les shifts sont traduits vers du code très efficace, mais leurs sémantiques côté machine change selon les plateformes.
En spéculant aussi, j'en arrive à la même conclusion. D'appelant en appelé, on finit toujours par appeler en toute fin une instruction machine : autant prendre le plus dénominateur commun des architectures. Cela permet d'avoir le code le plus efficace sur toute les architectures, et si l'appelant veut une spécification plus large, il la code lui même, ce n'est pas bien compliqué.
Je pense que ce doit être aussi la raison pour laquelle en C ou C++ le comportement n'est pas spécifié. Ce sont des instructions très bas niveau, cela permet d'avoir l'instruction la plus efficace sur chaque architecture et il est de la responsabilité de l'appelant de vérifier que le second paramètre se trouve bien dans les bornes où la fonction fait sens sans ambiguïté. Dans des langages haut niveau, on peut même se demander si le choix de la structure de données est le plus adapter au problème si l'on se retrouve à devoir gérer des cas en dehors des bornes « naturelles ».
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
et la doc précise bien que le comportement est non spécifié :
val (lsl) : int -> int -> int
n lsl m shifts n to the left by m bits. The result is unspecified if m < 0 or m >= bitsize, where bitsize is 32 on a 32-bit platform and 64 on a 64-bit platform.
val (lsr) : int -> int -> int
n lsr m shifts n to the right by m bits. This is a logical shift: zeroes are inserted regardless of the sign of n. The result is unspecified if m < 0 or m >= bitsize.
val (asr) : int -> int -> int
n asr m shifts n to the right by m bits. This is an arithmetic shift: the sign bit of n is replicated. The result is unspecified if m < 0 or m >= bitsize.
Reste la question : pourquoi avoir suivi le comportement du C au lieu de définir le résultat proprement ? Je n'en ai aucune idée.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Shifting by the number of bits in a native integer (or more) is zero, except when the "overshift" is right shifting a negative value under use integer , in which case the result is -1 (arithmetic shift).
Until now negative shifting and overshifting have been undefined because they have relied on whatever the C implementation happens to do. For example, for the overshift a common C behavior is "modulo shift":
1>>64==1>>(64%64)==1>>0==1# Common C behavior.# And the same for <<, while Perl now produces 0 for both.
Now these behaviors are well-defined under Perl, regardless of what the underlying C implementation does.
Jusqu'à la 5.2, Perl se reposait sur l'implémentation en C et le comportement était indéfini; depuis la 5.4, le comportement est bien défini.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
ce qui signifie que les fonctions sont des primitives codées en C (je n'ai pas trouvé le code C correspondant). Je suppose que la première doit correspondre à un décalage arithmétique et la seconde à un décalage logique. Ne connaissant pas la norme du C, mais elle doit rejoindre celle du C++ là-dessus, si c'est implementation defined alors le comportement des fonctions OCaml dépend du compilateur C utilisé et donc il paraît normal que le comportement soit non spécifié.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Est-ce mieux, moins bien ? Diffficile à dire. Et paradoxalement, tu critiques le résultat de notre type de scrutin, alors que dans le cas présent, c'est plus un "second choix" qui a été élu. Macron a profité du vote utile au premier tour, et au second tour il a rassemblé tous ceux qui le préféraient à Le Pen.
La question n'est pas de savoir si dans certaines situations notre mode de scrutin finit par désigner tout de même un candidat de Condorcet, mais qu'un tel candidat puisse passer à la trappe. Le problème est même plus profond : il n'existe pas de méthode pour agréger les préférences individuelles et en sortir une « unique préférence collective » (l'énoncé est volontairement flou, pour plus de précision voir le théorème d'Arrow ou sa variante de Gibbard-Satterthwaite).
Le problème de notre système, que l'on retrouve dans les discussions de ce journal, et qu'il incite au vote utile (on n'exprime pas réellement sa préférence maximale, mais on peut être tenter de « calculer ») et surtout qu'il mène à des situations où un parti comme le FN, qui n'a aucune chance d'être élu, se retrouve au second tour. Il existe des méthodes, certes « non parfaites » (cf. impossibilité ci-dessus), à un seul tour qui possède bien moins de défauts (voir par exemple les trois articles sur Images des Maths dans mon premier message de ce fil).
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
D'où le pinning en ayant les dépôts de Sid dans le sources.list, avec priorité pour Testing, et on vise explicitement Sid avec l'option -t sid pour le paquet en question dès qu'il est dispo : pas besoin d'attendre qu'il arrive dans testing.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
La discussion portait sur les modes de scrutin et non sur l'organisation politiques des pays. Et je maintiens mon avis sur le scrutin majoritaire uninominale à deux tours. Mais pour comprendre le problème, et exprimer un avis un minimum avisé sur le sujet, encore faut-il au moins faire l'effort de lire les liens de mon message (ne serait-ce que pour savoir de quoi l'on parle).
Par exemple pour reprendre la conclusion du message auquel je répondais :
Et pour revenir à ta remarque en début de paragraphe, le gars dont on parle a été premier à chaque tour. Question légitimité ça me parait difficile à remettre en cause.
On peut sans difficulté imaginer une situation où trois options A, B et C sont présentées aux électeurs. Les préférences du corps électoral seraient divisées en trois groupes :
A > C > B : 40 % (A est préféré à C qui est préféré à B) ;
B > C > A : 35 % (B est préféré à C …) ;
C > A > B : 25 %.
Avec une telle répartition du corps électoral, si chaque électeur dans notre système choisit l'électeur qu'il préfère, on a un premier tour avec A à 40 %, B à 35 % et C à 25 %; puis un second tour qui donne A victorieux avec 65 % (40 + 25) face à B avec 35%. Il est largement premier aux deux tours et donc « question légitimité, ça paraît difficile à remettre en cause ».
Pourtant, le candidat C (éliminé au premier tour) gagnerait en duel face à chacun des deux autres : 60 % (35 + 25) face à A et 65 % (40 + 25) face à B; C est ce que l'on appelle un candidat de Condorcet. Alors lequel de A et C est le plus légitime selon toi ?
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Elle est intéressante votre discussions. En cherchant un peu, je suis tombé sur une étude (ancienne vu le sujet, elle date de 2008) qui testait la sécurité de différents gestionnaires de paquets et les méthodes de distribution : A Look In the Mirror: Attacks on Package Managers. Je n'ai pas eu le temps de la lire en détail, mais en conclusion il pointe bien un problème sur le HTTP / HTTPS :
If the package manager supports HTTPS and it correctly checks certificates, the distribution can set up
repositories or mirrors that support HTTPS transfers. This will not protect against a malicious mirror, but will prevent a man-in-the-middle attack from an outsider.
Apparemment, l'étude consistait à montrer comment on pouvait créer un miroir malicieux. Si quelqu'un a le courage de regarder plus en profondeur l'étude et voir si certains éléments sont toujours d'actualité…
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Je recopie ici le passage d'une de mes commentaires dans un des ces journaux :
Enfin, pour l'anecdote, je n'ai plus grand espoir de voir le mode de scrutin changer en France, mais on ne sait jamais. Lors de l'élection de 2002 j'avais prévenu mon entourage des dangers que représentait le grand nombre de candidats au premier tour et le risque d'éparpillement des voix; j'ai obtenu pour réponse : la politique c'est pas des mathématiques ! Suite au résultat du premier tour, aucune prise de conscience : le mode de scrutin ne pose aucun problème. Dans la foulée, un ami qui effectuait sa thèse en science politique organise une conférence avec politologues et sondeurs (qui défendaient leur chapelle sur leurs « erreurs de prédiction ») pour essayer d'analyser et de comprendre le résultat de l'élection. Au moment des questions du public, rebelote, je remets sur le tapis la question du mode de scrutin et là, réaction identique et unanime : où est le problème avec notre mode de scrutin ? il n'y a aucune raison de le changer !
Je doute, par expérience, que la résistance au changement proviennent des deux gros partis, mais bien plutôt des électeurs eux-mêmes qui ne voient pas que le mode de scrutin pose problème.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Le résultat est intéressant en lui même, ne serait-ce que pour légitimer l'autorité du président élu, mais si quelqu'un a des sources plus précises et exactes, je suis intéressé.
Sans vouloir nier la véracité des faits rapportés par Nicolas Grégoire, on ne peut pas dire qu'en dehors de sa parole il apporte la moindre preuve via ses documents (comme la fort bien souligné Michaël dans son commentaire).
Mais dans le fond, c'est une pratique courante et répandue dans tous les partis cet usage des assistants parlementaires. Sans vouloir en prendre la défense, ni minimiser de tels abus, je suis étonné par une certaine candeur de la population face aux « révélations » de ce genre de faits.
Enfin, si la volonté était de pointer du doigt Macron, il n'était pas nécessaire de remonter si loin dans le temps en passant par une attaque contre Bayrou. L'emploi parlementaire sur mesure du fondateur des Jeunes avec Macron ou comment bosser deux jours par semaine pour plus de 3000€ et pouvoir consacrer le reste de son temps « bénévolement » pour la campagne de Macron.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
De rien. Vu que tu n'avais jamais utilisé les backports, tu peux lancer un :
apt-get -t jessie-backports upgrade
pour voir tous les paquets que tu peux mettre à jour dans leur version backportée. Et si tu veux aller plus loin, mais c'est plus risqué et tendu, tu peux jouer avec le apt pinning.
Ou en plus secure, mais plus long en temps de calcul (cela lance un solveur SAT pour vérifier si le paquet est installable en gérant les conflits entre paquets) :
apt-get install apt-cudf aspcud
puis pour installer un paquet :
apt-get --solver aspcud install ton-paquet
Il y a quelques articles d'exemples sur le blog de Roberto DiCosmo. Cette méthode permet d'installer des paquets que le solveur interne de apt-get aurait refusé pour cause de conflits.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Oui c'est normal. Debian ne met pas ses versions à jour au cours d'une version stable mais effectue seulement des correctifs de sécurité. Ubuntu n'est pas basé sur la version stable de Debian. Raspbian recompile et patch les paquets sources Debian et a son propre noyau pour l'adapter aux spécificités du matériel.
Disons que c'est bien ce que laissait sous-entendre l'auteur du journal qui soit n'avait pas lui-même compris la situation, soit a fait preuve de malhonnêteté intellectuelle.
Cela étant, je ne suis pas certain que ce document à lui seul ait permis de pouvoir voter. Il fait bien mention d'une application de l'article L. 34, mais il est signé par le maire de l'arrondissement. Or, d'après l'article en question, seul le juge de tribunal d'instance peut statuer. Il se peut, comme l'indique le titre du papier, que le maire atteste simplement de l'existence d'une erreur matérielle et qu'il faille ensuite, muni du document, saisir le juge pour obtenir définitivement l'inscription.
Quoi qu'il en soit, un système infaillible est quasi-impossible à mettre en place, mais le notre est fait de telle sorte qu'il soit possible de corriger ses « bugs » si l'on s'en rend compte à temps.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Du haut niveau pour gérer correctement du bas niveau
Posté par kantien . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 1. Dernière modification le 20 mai 2017 à 15:29.
J'émettais bien l'hypothèse que les situation où on avait besoin de sortir de ces bornes étaient rares. En conséquence, la grande majorité de codes utilisant
shift_rightse retrouveraient pénalisés d'un test inutile sur X86 si les implémenteurs de langage haut niveau choisissaient tous ton approche, pour la simple est bonne raison qu'il ne sortiront jamais de ces bornes et que ce test dynamique s'avérait inutile pour eux. Certains langages, dont OCaml fait partie, semblent avoir fait le choix de ne garantir le bon comportement que sur l'intervalleO .. 63pour des raisons tout à fait légitimes d'efficacité et de le documenter. Ainsi les cas exceptionnels qui ont besoin de sortir de ces bornes doivent coder leur propre fonction avec un test sur la valeur de l'entrée. C'est un choix qui me semblent tout à fait convenable d'un point de vue pragmatique. Tu dois bien reconnaître que ton projet est un cas bien particulier à but pédagogique que des programmeurs réaliseront peut dans la réalité. Rust va même jusqu'à refuser de compiler s'il détecte statiquement que l'on sort de ces bornes.Une approche peut être plus mixte est celle de Haskell, qui se comprend et se tient aussi : mais tout cela reste une question de choix. Je suis allé voir le code qui nous intéresse et l'on trouve :
Puis pour
shiftLetshiftRl:Ce qui revient peu ou prou à implémenter les fonctions
<<et>>comme je l'ai fait plus haut en OCaml à partir des versions fournies par la bibliothèque standard dans le moduleInt64. Les implémenteurs de la bibliothèque standard OCaml n'ont pas choisi cette approche, laissant le soin aux développeurs qui en ressentent le besoin de le faire eux même.Cela étant il reste la question de la circularité du second argument, qui ne pose pas de problème en ADA, mais qui en pose un en Haskell :
Raison pour laquelle j'avais posé la question qui, elle aussi, n'était pas dénuée de fondements. ;-)
J'espère t'avoir fait comprendre que, bien que le comportement puissent apparaître étrange lorsqu'on l'ignore, ce n'était pas un choix dénué de fondements ni sans justifications tout à fait recevables. Le seul reproche que l'on peut faire à freePascal est de ne pas le documenter mais non d'avoir un tel comportement.
Sinon toujours en étant taquin, en poussant ton principe à l'extrême, je pourrais dire : un langage qui a besoin de tests unitaires n'est pas un langage haut niveau digne de ce nom. :-P
De tels langages existent et comme je ne suis pas sectaire je te propose la méthode B présentée au Collège de France par son concepteur.
Présentation dont j'extrais deux diapos :
pour remplacer l'ancienne méthodologie avec tests unitaires par celle-ci :
Tu vois ADA lui aussi n'est pas assez « haut niveau » finalement. En fait Ada est à la méthode B ce que OCaml est à Coq : le langage dans lequel est écrit son noyau ainsi que le langage cible vers lequel il « compile ». Coq qui a servi, par exemple, à ecrire un compilateur C certifié correct. Ce sont là des exemples de ce que peut faire la rigueur de la formalisation mathématique pour garantir l'absence de bug dans un logiciel, à condition d'être effectuée avec les outils et les langages adéquats. ;-)
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Du haut niveau pour gérer correctement du bas niveau
Posté par kantien . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.
J'ai d'ailleurs une autre question : en ADA le type
naturalest-il lui aussi cyclique ou, sinon, que se passe-t-il lorsque l'on arrive aux bornes ? Dans plein de langage, dont OCaml, le type du second paramètre est lui aussi cyclique (le typeintc'estZ/2^63Zen 64 bits) ce qui ne ferait que repousser le comportement observé de manière tout aussi étrange lui aussi.Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Du haut niveau pour gérer correctement du bas niveau
Posté par kantien . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2. Dernière modification le 19 mai 2017 à 18:10.
Pour ce que doit faire le
shift_right, on est d'accord : il décale à droite et remplace les trous par des zéros. Mais une question que j'avais posée est : qu'est-ce qui peut pousser un développeur à utiliser cette fonction en dehors des bornes0 .. 63? C'est pour cela que j'avais écrit qu'elle ne faisait vraiment sens que sur cette intervalle. Dans quel contexte va ton réellement lui passer les valeurs64,65ou tout autre supérieure ? Et cela ce n'est pas sans incidence pour un implémenteur de langage haut niveau. Comme tu l'as montré pour ADA : si on évite les valeurs supérieures à 63, on évite un test de comparaison à chaque exécution sur une architecture X86. Quelle intérêt un code pourrait avoir, sur une telle instruction, de se rendre dans un domaine où la sortie vaut toujours0? Et je pense que la raison qui à présider au choix de laisser le comportement non défini en dehors de ces bornes sont des raisons de performances générales : la majorité des codes l'utilisant se retrouveraient pénalisés d'un test inutile sur X86. C'était là le fruit de mes « spéculations », comme celles de Def. Et c'est aussi ce que dit wikipédia :Ensuite sur ce que fait X86, je n'ai pas dit que c'était délibéré de leur part (bien que ma formulation pouvait laisser penser le contraire) mais je ne faisais que décrire, en me basant sur son comportement, la structure mathématique qui lui correspondait : un opérateur sur un tore, son domaine se ramenant de fait à
Z/2^64Z x Z/64Z. Que peut-il servir à modéliser en pratique dans le quotidien d'un programmeur, j'en sais foutre rien et je m'en fout un peu à vrai dire. Mais c'est plus drôle qu'une fonction stationnaire, et c'est joli un donut ! :-PQuoi qu'il en soit, pour un langage haut niveau qui reproduit l'instruction machine, le développeur ne peut pas s'appuyer sur le comportement de
shrsur X86 s'il veut un tel comportement, mais le coder lui-même s'il veut un code portable. Comme il doit le coder lui-même s'il veut que la sortie soit constamment égale à0.Pour ce qui est de ton autre question pour OCaml sur PowerPC, je suppose que la réponse est : la sortie est stationnairement nulle à partir de 64. Ce qui est sans doute aussi le cas en C ou C++. Mais je n'ai pas de telle machine à disposition, ni de ARM, pour vérifier.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Du haut niveau pour gérer correctement du bas niveau
Posté par kantien . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.
Effectivement, c'est sur ce point que l'on diverge. C'est lorsque tu écris : « [elle] ne devrait répondre qu'au seul problème du quotient d'un entier machine entre 0 et 2n - 1 par une puissance positive quelconque de 2 » en parlant de la primitive
shift_right. Pour moi, elle ne devrait rien être, mais elle est ce que l'implémenteur a décidé qu'elle serait. C'est tout le problème de la spécification d'un code. C'est pour cela que j'avais écrit :C'est un peu comme Hilbert qui disait qu'en géométrie on s'en fout des noms point, droite ou plan et qu'on pourrait les remplacer par chope de bière, chaise et table : ce qui compte c'est l'axiomatique des structures. Dans toute cette histoire, moi ce que je vois c'est que certains langages ne te fournissent pas de base l'axiomatique que tu souhaiterais. Ce à quoi je te réponds : ils te donnent néanmoins les moyens de construire la structure que tu désires. D'ailleurs au sujet de ADA, je suis allé voir la documentation est le moins que l'on puisse dire c'est que ni le type, ni son complément dans la documentation ne permet de savoir c'est que fait cette fonction
shift_right. Même grâce au complément en langue anglaise, je trouve que l'on a là une sous-spécification de son comportement. Au moins, dans certains langages qui ne font pas ce que tu souhaites, avec la documentation on sait ce qu'elle doit faire.Au fond ce que je vois, c'est qu'on a un opérateur qui agit sur un cylindre : produit cartésien d'un anneau
Z/nZavec un domaine fini. Toi tu veux que l'on prolonge le cylindre en saturant sur sa valeur au bord (ARM), d'autres recollent les bouts et opèrent sur un tore (X86). Ce qui compte surtout c'est qu'il soit possible de faire des découpages et des collages pour construire la structure que l'on souhaite, et cela tous les langages le permettent. Le rôle d'un langage de haut niveau c'est de fournir des moyens plus abstrait que l'assembleur pour effectuer ces constructions puis de passer la main au compilateur pour traduire le tout en code machine. Apprendre un langage donné consiste essentiellement à apprendre les méthodes de construction qu'il fournit pour définir des structures ainsi que les moyens pour opérer sur celles-ci.Ce que tes étudiants ont expérimenté c'est qu'un tore est cyclique sur ces deux dimensions et qu'il n'a pas du tout la même géométrie qu'un cylindre. Ce qui me rappelle un épisode des Simpson dans lequel Stephen Hawking était très intéressé par la théorie d'Homer selon laquelle l'Univers avait la forme d'un Donuts. :-P
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Du haut niveau pour gérer correctement du bas niveau
Posté par kantien . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 7.
Je me permets de concentrer dans ce commentaire ma réponse à celui-ci ainsi qu'à cet autre commentaire, étant donné que tu y reprends les mêmes idées. Tu as été clair malgré l'heure tardive, j'espère pouvoir faire de même en cette heure plus matinale.
Il me semble que dans ton approche de la question, tu mélanges plusieurs problématiques. Dans l'exemple que tu donnes ici, tu montres surtout comment un système de type avancé (ici une forme restreinte de type dépendant) permet d'être plus précis sur la spécification d'un code et comment un compilateur peut en tirer partie pour générer un code optimisé (ici en supprimant un test de comparaison à l'exécution rendu inutile par ton type
amount). Cela rejoint un exemple que j'avais donné dans la dernière dépêche sur Haskell, où je montrais comment utiliser les GADT (types de données algébriques généralisés) pour exprimer la proposition : « tout arbre binaire parfait non vide a une racine ». Ce qui permettait de coder la fonction qui extrait cette racine sans que le code généré par le compilateur ait à vérifier à l'exécution que l'arbre était non vide (c'était déjà spécifié dans le type de la fonction).Revenons à présent au sujet précis du journal : le décalage à droite bit à bit. Dans un autre commentaire, tu précises à bon droit que l'arithmétique modulaire est la base de tous les processeurs courants et dans le cas présent on fait de l'arithmétique dans l'anneau
Z/nZavecn = 2^64. Se pose alors la question que doit faire cette fonction de décalage à droite ? et tu réponds toi même : « [elle] ne devrait répondre qu'au seul problème du quotient d'un entier machine entre 0 et 2n - 1 par une puissance positive quelconque de 2 ». Ce à quoi je te répondrai : l'architecture X86 fait cela en restant dans le cadre de l'arithmétique modulaire, et ne la mélange pas avec de l'arithmétique sur les entiers. En effet prenons le type de cette fonction :function my_shr (u : unsigned_64; a : natural) return unsigned_64. Elle prend en paramètre un entier non signé sur 64 bits, un entier naturel et renvoie un entier non signé sur 64 bits. Or pour opérer au sein de l'anneau sus-mentionné, elle doit donc associer un élément de cette anneau au paramètrea : natural, puis renvoyer ensuite le quotient d'une division euclidienne effectuée au sein de l'anneau. Les processeurs X86 on fait le choix de prendre l'élément2 ^ (a % 64), ce qui peut sembler assez « naturel » lorsque l'on pratique l'arithmétique modulaire. Exemple en OCaml sur mon X86 :En revanche, de ce que j'ai compris, l'architecture ARM ne voit pas cela du tout comme une opération d'arithmétique modulaire, mais semble considérer une telle donnée (un entier non signé sur 64 bit) comme un suite finie de
0et de1ou plutôt comme une suite stationnaire de valeur nulle à partir du rang64et si tu lui donne la suiteu(n)elle te renvoie la suiteu(n+a). Ce qui semble être le comportement que tu souhaiterais, mais ce n'est pas du tout le point de vue de l'arithmétique modulaire. Autrement dit, elle voit un entier de 64 bit comme un entier naturel compris entre0et2^64 - 1représenté en base 2, effectue une division euclidienne par une puissance de2et opère donc sur l'ensemble des entiers naturels.Viens maintenant le problème des langages compilés et de la spécification qu'ils donnent à une telle primitive. Ils pourraient tout à fait faire un choix strict et défini en optant pour la vision modulaire à la X86 ou la vision entière à la ARM. La plupart on choisit d'utiliser pour chaque architecture la primitive correspondante du processeur et elle n'est donc spécifiée et définie que sur le domaine où elles coïncident, à savoir
0≤ a < 64. Si le programmeur veut une fonction plus fortement spécifiée, alors il n'a qu'à la coder lui-même.Tu concluais ton commentaire réponse par : « c'est pour ça que j'adore l'Ada, vous l'aurez remarqué :) », je terminerai le mien par j'adore le lamba-calcul typé et rien de plus normal pour le mathématicien et logicien que je suis :) Le lamba-calcul typé (dont font partie les langages comme Haskell, OCaml ou Coq) a pour principe fondamental la correspondance preuve-programme : une programme est la preuve d'un théorème dont l'énoncé est le type ! \o/
Ce qui donne le tableau suivant :
Si l'on prend le langage qui a le système de type le plus sophistiqué (Coq), je te laisse deviner ce que fait une fonction dont le type est « pour tout (n: nat), il existe (p:nat) tel
n ≤ pet p soit premier » si on lui passe un entier en entrée. En Coq, cela pourrait se définir ainsi :Pas besoin d'aller lire la doc pour savoir ce que fait la fonction, la lecture de son type suffit à cela. ;-)
Au final si j'étais un peu taquin, en se basant sur la popularité des langages de programmation je dirais qu'à l'heure actuelle la programmation consiste, la plupart du temps, dans l'art de faire des mathématiques comme un goret dans des langages atrophiés. En conséquence, la seule chose à faire si l'on veut savoir ce que fait une fonction, c'est d'aller lire la doc : on ne peut pas se fier uniquement à son type ni à ses attentes. Et le seul moyen de vérifier qu'elle se comporte exactement comme le spécifie la doc, c'est d'aller lire le code d'où la condition sine qua non que celui-ci soit publiquement accessible. Voilà une leçon que pourront retenir tes étudiants de cet exercice.
Comme tu enseignes les mathématiques, si le sujet t'intéresse il y a un dossier sympa sur le sujet dans la gazette des mathématiciens d'octobre 2014 : théories des types et mathématiques certifiées, et la théorie homotopique des types pousse encore plus loin la correspondance que j'ai signalée plus haut et fournit des fondements élégants à l'ensemble de l'édifice mathématique.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Primitive en C pour OCaml
Posté par kantien . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 4.
Je me suis précipité dans mon code, celui-ci est plus « naturel » :
et on a une certaine cohérence :
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Primitive en C pour OCaml
Posté par kantien . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 4.
Merci beaucoup pour toutes ces précisions, je comprends mieux ce qui se passe (ainsi que l'organisation interne du compilateur).
En spéculant aussi, j'en arrive à la même conclusion. D'appelant en appelé, on finit toujours par appeler en toute fin une instruction machine : autant prendre le plus dénominateur commun des architectures. Cela permet d'avoir le code le plus efficace sur toute les architectures, et si l'appelant veut une spécification plus large, il la code lui même, ce n'est pas bien compliqué.
Je pense que ce doit être aussi la raison pour laquelle en C ou C++ le comportement n'est pas spécifié. Ce sont des instructions très bas niveau, cela permet d'avoir l'instruction la plus efficace sur chaque architecture et il est de la responsabilité de l'appelant de vérifier que le second paramètre se trouve bien dans les bornes où la fonction fait sens sans ambiguïté. Dans des langages haut niveau, on peut même se demander si le choix de la structure de données est le plus adapter au problème si l'on se retrouve à devoir gérer des cas en dehors des bornes « naturelles ».
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Primitive en C pour OCaml
Posté par kantien . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 4.
Tu supposes bien, elles sont définies dans le module Pervasives :
et la doc précise bien que le comportement est non spécifié :
Reste la question : pourquoi avoir suivi le comportement du C au lieu de définir le résultat proprement ? Je n'en ai aucune idée.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Quelques autres
Posté par kantien . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 6.
Comme pour les autres, c'est dans la doc :
Jusqu'à la 5.2, Perl se reposait sur l'implémentation en C et le comportement était indéfini; depuis la 5.4, le comportement est bien défini.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
# Primitive en C pour OCaml
Posté par kantien . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 6.
En regardant le fichier d'implémentation et l'interface du
module Int64, on tombe sur :ce qui signifie que les fonctions sont des primitives codées en C (je n'ai pas trouvé le code C correspondant). Je suppose que la première doit correspondre à un décalage arithmétique et la seconde à un décalage logique. Ne connaissant pas la norme du C, mais elle doit rejoindre celle du C++ là-dessus, si c'est implementation defined alors le comportement des fonctions OCaml dépend du compilateur C utilisé et donc il paraît normal que le comportement soit non spécifié.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Abstention abstention ...
Posté par kantien . En réponse au journal Résultats des elections, qui est le vrai vainqueur ?. Évalué à 5.
La question n'est pas de savoir si dans certaines situations notre mode de scrutin finit par désigner tout de même un candidat de Condorcet, mais qu'un tel candidat puisse passer à la trappe. Le problème est même plus profond : il n'existe pas de méthode pour agréger les préférences individuelles et en sortir une « unique préférence collective » (l'énoncé est volontairement flou, pour plus de précision voir le théorème d'Arrow ou sa variante de Gibbard-Satterthwaite).
Le problème de notre système, que l'on retrouve dans les discussions de ce journal, et qu'il incite au vote utile (on n'exprime pas réellement sa préférence maximale, mais on peut être tenter de « calculer ») et surtout qu'il mène à des situations où un parti comme le FN, qui n'a aucune chance d'être élu, se retrouve au second tour. Il existe des méthodes, certes « non parfaites » (cf. impossibilité ci-dessus), à un seul tour qui possède bien moins de défauts (voir par exemple les trois articles sur Images des Maths dans mon premier message de ce fil).
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Première historique..
Posté par kantien . En réponse au journal MacronLeaks est tombé dans le pot de miel tendu par En Marche!. Évalué à 5.
On n'a pas du assez te le dire qu'en tu en étais un. :-P
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: imprécisions et mauvais conseils
Posté par kantien . En réponse au journal Comment je suis passé d'Ubuntu à Debian Sid. Évalué à 4.
D'où le pinning en ayant les dépôts de Sid dans le
sources.list, avec priorité pour Testing, et on vise explicitement Sid avec l'option-t sidpour le paquet en question dès qu'il est dispo : pas besoin d'attendre qu'il arrive dans testing.Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Résultats alternatifs
Posté par kantien . En réponse au journal Résultats des elections, qui est le vrai vainqueur ?. Évalué à 2.
Pour ma part j'ai participé à l'expérience voter autrement, mais les résultats ne seront diffusées qu'à l'issue du second tour des législatives.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Abstention abstention ...
Posté par kantien . En réponse au journal Résultats des elections, qui est le vrai vainqueur ?. Évalué à 3.
La discussion portait sur les modes de scrutin et non sur l'organisation politiques des pays. Et je maintiens mon avis sur le scrutin majoritaire uninominale à deux tours. Mais pour comprendre le problème, et exprimer un avis un minimum avisé sur le sujet, encore faut-il au moins faire l'effort de lire les liens de mon message (ne serait-ce que pour savoir de quoi l'on parle).
Par exemple pour reprendre la conclusion du message auquel je répondais :
On peut sans difficulté imaginer une situation où trois options A, B et C sont présentées aux électeurs. Les préférences du corps électoral seraient divisées en trois groupes :
Avec une telle répartition du corps électoral, si chaque électeur dans notre système choisit l'électeur qu'il préfère, on a un premier tour avec A à 40 %, B à 35 % et C à 25 %; puis un second tour qui donne A victorieux avec 65 % (40 + 25) face à B avec 35%. Il est largement premier aux deux tours et donc « question légitimité, ça paraît difficile à remettre en cause ».
Pourtant, le candidat C (éliminé au premier tour) gagnerait en duel face à chacun des deux autres : 60 % (35 + 25) face à A et 65 % (40 + 25) face à B; C est ce que l'on appelle un candidat de Condorcet. Alors lequel de A et C est le plus légitime selon toi ?
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Cell-eux qui ne sont pas comptées...
Posté par kantien . En réponse au journal Résultats des elections, qui est le vrai vainqueur ?. Évalué à 2.
Si on se fit à une étude INSEE de mars 2017 ainsi qu'aux résultats, on a ces chiffres :
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: HTTP remplacent ?
Posté par kantien . En réponse au journal Debian va débrancher ses dépôts FTP. Évalué à 3. Dernière modification le 10 mai 2017 à 12:49.
Elle est intéressante votre discussions. En cherchant un peu, je suis tombé sur une étude (ancienne vu le sujet, elle date de 2008) qui testait la sécurité de différents gestionnaires de paquets et les méthodes de distribution : A Look In the Mirror: Attacks on Package Managers. Je n'ai pas eu le temps de la lire en détail, mais en conclusion il pointe bien un problème sur le HTTP / HTTPS :
Apparemment, l'étude consistait à montrer comment on pouvait créer un miroir malicieux. Si quelqu'un a le courage de regarder plus en profondeur l'étude et voir si certains éléments sont toujours d'actualité…
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Abstention abstention ...
Posté par kantien . En réponse au journal Résultats des elections, qui est le vrai vainqueur ?. Évalué à 6. Dernière modification le 08 mai 2017 à 23:06.
Aucun système n'est parfait mais le notre est un des pires que l'on puisse concevoir.
Ce n'est pas comme si le sujet était inconnu et non documenté :
ni que certains journaux avaient évoqué le sujet dernièrement :
Bonne lecture. :-)
Je recopie ici le passage d'une de mes commentaires dans un des ces journaux :
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Résultats
Posté par kantien . En réponse au journal Résultats des elections, qui est le vrai vainqueur ?. Évalué à 10.
Le flegme est un trait de caractère typiquement britannique, à ne pas confondre avec la flemme.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
# Source officielle
Posté par kantien . En réponse au journal Résultats des elections, qui est le vrai vainqueur ?. Évalué à 10.
Oui, les résultats officiels sur le site du ministère de l'intérieur.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
# Pourquoi remonter si loin dans le temps ?
Posté par kantien . En réponse au journal Les langues se délient... . Évalué à 6.
Sans vouloir nier la véracité des faits rapportés par Nicolas Grégoire, on ne peut pas dire qu'en dehors de sa parole il apporte la moindre preuve via ses documents (comme la fort bien souligné Michaël dans son commentaire).
Mais dans le fond, c'est une pratique courante et répandue dans tous les partis cet usage des assistants parlementaires. Sans vouloir en prendre la défense, ni minimiser de tels abus, je suis étonné par une certaine candeur de la population face aux « révélations » de ce genre de faits.
Enfin, si la volonté était de pointer du doigt Macron, il n'était pas nécessaire de remonter si loin dans le temps en passant par une attaque contre Bayrou. L'emploi parlementaire sur mesure du fondateur des Jeunes avec Macron ou comment bosser deux jours par semaine pour plus de 3000€ et pouvoir consacrer le reste de son temps « bénévolement » pour la campagne de Macron.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: 4.11
Posté par kantien . En réponse à la dépêche Sortie du noyau Linux 4.10. Évalué à 4.
De rien. Vu que tu n'avais jamais utilisé les backports, tu peux lancer un :
pour voir tous les paquets que tu peux mettre à jour dans leur version backportée. Et si tu veux aller plus loin, mais c'est plus risqué et tendu, tu peux jouer avec le apt pinning.
Ou en plus secure, mais plus long en temps de calcul (cela lance un solveur SAT pour vérifier si le paquet est installable en gérant les conflits entre paquets) :
puis pour installer un paquet :
Il y a quelques articles d'exemples sur le blog de Roberto DiCosmo. Cette méthode permet d'installer des paquets que le solveur interne de
apt-getaurait refusé pour cause de conflits.Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: 4.11
Posté par kantien . En réponse à la dépêche Sortie du noyau Linux 4.10. Évalué à 5.
Oui, il faut bien ajouter le dépôt backports à ton
sources.listpuis cibler celui-ci lors d'une commande d'installation de paquet :Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: 4.11
Posté par kantien . En réponse à la dépêche Sortie du noyau Linux 4.10. Évalué à 9. Dernière modification le 02 mai 2017 à 22:46.
Oui c'est normal. Debian ne met pas ses versions à jour au cours d'une version stable mais effectue seulement des correctifs de sécurité. Ubuntu n'est pas basé sur la version stable de Debian. Raspbian recompile et patch les paquets sources Debian et a son propre noyau pour l'adapter aux spécificités du matériel.
Pour avoir un noyau 4.9 avec Jessie, il faut utiliser les backports.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Tu vas vites en besogne
Posté par kantien . En réponse au journal Et si les "erreurs purement matérielles" pouvaient influer sur le processus démocratique. Évalué à 2. Dernière modification le 30 avril 2017 à 10:17.
Disons que c'est bien ce que laissait sous-entendre l'auteur du journal qui soit n'avait pas lui-même compris la situation, soit a fait preuve de malhonnêteté intellectuelle.
Cela étant, je ne suis pas certain que ce document à lui seul ait permis de pouvoir voter. Il fait bien mention d'une application de l'article L. 34, mais il est signé par le maire de l'arrondissement. Or, d'après l'article en question, seul le juge de tribunal d'instance peut statuer. Il se peut, comme l'indique le titre du papier, que le maire atteste simplement de l'existence d'une erreur matérielle et qu'il faille ensuite, muni du document, saisir le juge pour obtenir définitivement l'inscription.
Quoi qu'il en soit, un système infaillible est quasi-impossible à mettre en place, mais le notre est fait de telle sorte qu'il soit possible de corriger ses « bugs » si l'on s'en rend compte à temps.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.