NicolasP a écrit 274 commentaires

But decades aren't centuries. They're not cardinally numbered.

Effectivement, d'après wiktionary, un siècle c'est soit une période de 100 ans, soit une durée de cent années dans la logique du calendrier julien puis grégorien. Donc avec la 2ème définition parler du 20ème ou 21ème siècle a du sens, il y a des années bien définies où on change de millénaire ou de siècle.
Au contraire, une décennie, c'est juste une période de 10 ans, il n'y a pas la 2ème définition. On ne parle pas de la 201ème décennie du calendrier julien. Du coup, c'est pas si simple de dire qu'on a ou qu'on n'a pas changé de décennie, il faudrait une convention partagée par une majorité.

L'ennui c'est que si t'as pas un oeil sur tes gamins pdt qu'ils sont sur Gcompris ,dans la mn qui suit un instant d'inattention, il seront sur des sites de merde ou à jouer à des jeux à la con.

Mes enfants ont accès à GCompris, à des vidéos et à différents jeux (ainsi qu'à internet tout entier, même s'ils n'en n'ont pas bien conscience). Et quand ils sont sur GCompris, au bout d'1 minute d'inattention, je les retrouve sur GCompris. D'une part, parce ce que GCompris ce n'est pas une application qu'il faut fuir absolument, c'est ludique et ils aiment bien. Et d'autre part ils savent que s'ils ont le droit d'être sur GCompris, ça ne leur donne pas le droit d'être sur une vidéo.

Le numérique, ça fait partie de l'éducation générale. Il faut expliquer, donner un cadre et le faire respecter avec un mélange de contrôle et de confiance.

il y en a ici qui ont passé plus de temps à commenter qu'à apprendre le C++

A mon avis tous ceux qui ont commenté ont au moins 15 ans d'expérience sur le C++ et peuvent te donner leurs profiles github pour le prouver !

Si l'attaquant ne sait pas que tu utilises cette méthode, et/ou qu'il ne connait pas la liste des 2048 mots (ce qui es en principe le cas, sinon c'est une attaque ciblée sur toi), alors l'entropie est immensément plus élevée.

Cet XKCD propose une méthode qui aurait dû/pu être enseignée au plus grand nombre possible de gens. Si ça avait été effectivement le cas, tu peux être sûr que ça aurait été mis en tête de liste des crackers.
Quant à la liste, l'objectif est quand même que ça soit 2048 mots relativement communs, sinon la partie "déjà mémorisée" ne fonctionne pas. J'ignore combien de mots une personne humaine quelconque connaît, mais ça ne doit pas être des ordres de magnitude au dessus de 2048. Tu multiplies ça par le nombre de langues utilisées si l'attaque porte sur une base internationale et au final tu obtiens quelques bits d'entropie en plus, mais pas "immensément" plus.

J'avais retenu des cases du xkcd sur l'entropie : plus c'est long, plus c'est difficile à deviner

Juste pour préciser : le fait que "plus c'est long, plus c'est difficile à deviner" est vrai (si toutes les autres conditions sont identiques), c'est juste que ce n'est pas le propos de cet xkcd.

Qu'est ce que je n'ai pas compris ?

Cette formule est valable pour des caractères choisis aléatoirement, ce n'est pas le cas ici.
La méthode consiste à choisir 4 mots aléatoires dans une liste de 2048 mots. C'est donc équivalent à choisir 4 caractères aléatoires dans un alphabet virtuel de 2048 caractères. Chacun de ces caractères a une entropie de 11 bits, et l'entropie totale est donc de 44 bits.

Le XKCD ne dit pas que la taille compte, en tout cas ce n'est clairement pas le message principal.

Il dit plutôt qu'il existe une méthode de génération de mot de passe qui aboutit à un résultat plus facile à mémoriser pour un humain et plus difficile à deviner pour un ordinateur que les recommandations "usuelles". Les mots de passe générés avec cette méthode peuvent avoir des tailles très variées (au pifomètre de 16 à 40+ caractères) mais l'entropie (ou la difficulté pour les deviner) est constante.

Your Pa$$word doesn't matter est un article écrit par un membre de l'équipe sécurité d'Azure. En résumé, dans la vraie vie, la plupart des attaques qui ont réussi ne l'ont pas été à cause d'une faiblesse du mot de passe, mais à cause d'un autre facteur. Et donc si on veut vraiment se protéger, ce n'est pas avec des règles sur les mots de passe (que ça soit longueur ou complexité) mais avec de l'authentification multi facteurs.

De manière générale, imposer des dates d'expiration ou des contraintes sur les mots de passe n'est plus à l'ordre du jour (recommandations du NIST). J'ai l'impression que c'est juste l'inertie qui fait qu'on voit encore des règles de ce type.

Mais c'est un cas un peu bizarre ici, non? Il n'y a pas d'exclusion mutuelle pour deux boules en parallèles.

Je suppose que tu te places dans mon interprétation, c'est à dire que les ressources sont les intersections.

Dans cet article, l'exclusion mutuelle, c'est juste l'existence d'une ressource non partageable, c'est à dire qui ne peut pas être utilisée par 2 process en même temps. Avec 2 boules en parallèles, chacune a ses ressources non partageables. Mais ce n'est pas un problème car on ne veut pas les partager. Les conditions C2 et C4 ne seront jamais vérifiées.

Si il n'y a que trois boules, deux conditions ne sont plus remplies. L'exclusion mutuelle car il y a une boule qui n'est exclue par aucune autre

L'exclusion mutuelle c'est l'existence d'une ressource qui ne peut pas être partagée. Un seul process à la fois peut y avoir accès. Le fait d'avoir 3 boules ne change rien à l'existence ou non de cette ressource. Il y a toujours l'exclusion mutuelle.
A noter que la légende du schéma indique que la ressource c'est la zone grise, mais l'animation ainsi que la "right-before-left policy" suggèrent plutôt 4 ressources partagées qui sont les intersections des lignes bleues.

et l'attente circulaire

Effectivement, elle n'existe plus et donc il n'y a plus le deadlock.

Ces 4 conditions sont-elles aussi suffisantes comme cela est suggéré dans l'article?

J'aurais dû mal à démontrer que c'est suffisant, je ne vois même pas dans quel formalisme se placer. Mais intuitivement, oui ça l'est.
Supposons que les 4 conditions (C1, C2, C3, C4) soient vérifiées. Pour qu'il n'y ait pas de deadlock, il faut au moins 1 process qui puisse faire évoluer son état. Disons que c'est P1. C4 implique que P1 soit en attente d'une ressource (disons R1) détenue par un autre process (disons P2). C1 implique que P1 doive attendre la libération de R1. C3 implique que seul P2 puisse libérer R1. Donc P1 ne peut faire évoluer son état avant P2. De même P2, ne peut pas faire évoluer son état avant P3, … jusqu'à Pn qui ne peut pas faire évoluer son état avant P1.
La seule possibilité qu'il n'y ait pas de deadlock est donc que tous les process fassent évoluer leurs états simultanément. Hors chaque process a besoin d'une ressource non partageable (C1) qui est aussi nécessité par un autre process. Du coup, la simultanéité est elle aussi interdite.

Dans le raisonnement ci-dessus, je ne me sers pas de C2, mais j'ai l'impression que c'est une forme affaiblie de C4. J'ai peut-être raté quelque chose.

Il faut faire des hypothèses supplémentaire sur le scheduling, j'imagine. J'ai bien l'impression que je pourrais créer un scheduler qui ne va jamais autoriser un deadlock même avec 4 boules.

Le scheduler pourrait peut-être éviter d'arriver dans la situation où les conditions sont vérifiées et donc éviter le deadlock. Mais si tu te places dans une situation où les conditions sont déjà vérifiées, aucun process ne peut tourner. Du coup le scheduler n'a aucune marge de manœuvre (autre que killer un process).

Comme si on me disait que HTTP permet de corriger les problèmes de la couche de liaison… ça n'a aucun sens puisqu'elle s'appuie dessus

C'est tout à fait faisable pour un système de corriger les problèmes du système sur lequel il s'appuie. Pour rester sur les couches réseau: TCP corrige les problèmes de perte ponctuelle de paquets ou d'arrivée dans le désordre de la couche IP.

C'est l'aspect graphique qui ne te plais pas dans les boutons ?

C'est ça mais aussi le fait que ça soit du texte, alors que la cible ce sont des enfants qui ne savent pas lire ou à peine.

La partie démarrage pourrais se faire dans une petite modale qui serait caché une fois l'exercice commencé. (ça laisserais plus de place à l'écran également)

Je n'ai pas compris. Moi je proposais juste de supprimer le bouton commencer. Et de faire en sorte que quand on clique sur un des boutons "Nombres", ça fasse tout de suite comme si on avait aussi cliqué sur commencer.

Vu la cible, ça serait bien de changer les libellés des boutons, éventuellement les remplacer par des images. Et il faudrait pouvoir écouter la consigne.

Après avoir choisi la difficulté, le jeu pourrait commencer tout de suite, sans avoir à cliquer sur le bouton commencer.

Un bouton recommencer serait sympa aussi.

Avez-vous prévu de l'inclure en tant qu'activité dans GCompris ? C'est le genre de jeu qui s'y prête.

Du coup, je suis allé cherché si CBGraham existe vraiment. Oui, il a bien un compte et dans sa description c'est bien un professeur. Par contre, il n'a pas l'air de répondre à des questions sur Java mais plutôt sur iPhone.

Ça me fait penser à cette image vue sur Twitter. C'est probablement un fake, mais la réponse est inattendue.

Le typage statique étant un sur-ensemble du typage dynamique les langages statiques n'ont rien besoin de faire ;)

Sauf quand il faut s'interfacer avec un langage à typage dynamique. Par exemple, le mot clef dynamic a été introduit dans le C# pour ça.

N'est-il pas possible de compiler uniquement un fichier sensible avec l'option LFENCE ? Faire un seul fichier C qui manipule des clefs ou token crypto, et compiler uniquement celui-là avec l'option pour éviter les pénalités d’exécution.

Spectre permet d’accéder à n'importe quelle zone mémoire allouée à un processus. Du coup, ça ne servirait à rien de compiler seulement une partie du source avec cette option.

Je ne vois pas en quoi le modèle de menace diffère. Quelle différence entre :
- une application web qui te pousse un javascript dont l'origine est authentifiée par l'utilisation de TLS, pour que le client puisse chiffrer une donnée avant de l'envoyer au serveur de l'éditeur ;
- et un client lourd, dont l'origine est authentifiée par la signature du package l'éditeur, qui chiffre une donnée avant de l'envoyer au serveur de l'éditeur ?

Si le terminal est compromis, il n'y a effectivement aucune différence.
Par contre s'il est fiable, dans le 1er cas ton application web a un risque de compromission à chaque utilisation, alors que dans le 2ème cas le risque est à chaque mise à jour. A priori, on peut supposer que les mises à jour sont beaucoup moins fréquentes que les utilisations. Du coup, tu pourrais très bien analyser une version donnée et si tu la valides, tu peux la conserver tant que tu le souhaites (à condition que les protocoles ne cassent pas la compatibilité avec elle).

Non, non, la balance (la vrai, avec deux plateaux) mesure bien la masse, pour autant qu'on admette le Principe d'équivalence. Mais il faut la mettre dans les bonne conditions pour qu'elle puisse opérer.
Ce qu'il faut, c'est que la balance soit plongée dans un champ de gravité uniforme, de cette façon les effets relatifs de la gravité (le poids) se compensent (c'est en ça qu'intervient le principe d'équivalence) et on compare bien les masses posées sur les deux plateaux.

Le problème de fond c'est que la balance ne permet pas de comparer les poids mais compare les composantes verticales des sommes des forces appliquées aux autres objets. Et du coup, quand il y a une force non négligeable autre que le poids, la balance ne permet plus de mesurer la masse (et ce qu'on admette le principe d'équivalence ou pas).

J'ai tenté de calculer, mais je me retrouve avec une équation qui n'est fonction que de la masse des objets (1 kilo) et de l'écart de hauteur de leur centre de gravité, sans aucun facteur multiplicateur.
Donc je me suis trompé dans ma réduction de formule.

En supposant que les vaches sont sphériques, la force appliquée (en mécanique Newtonienne, pas besoin de relativité générale ici) sur chacun des objets va être :
G * 1 * M/R² et G * 1 * M / (R +r)²
avec
G : la constante gravitationnelle
M : la masse de la Terre
R : la distance entre le centre de la Terre et le centre de gravité de l'objet en plomb
r : la différence de hauteur entre le centre de gravité de l'objet en plomb et le centre de gravité du tas de plumes

Du coup, la force appliquée sur l'objet en plomb est (R+r)²/R² plus importante que celle sur le tas de plumes. Pour un ordre de grandeur, si on prend 6400km comme distance entre le centre du plomb et celui de la terre, et 1 cm de plus pour le tas de plumes, on est à 3 * 10‐⁹ d'écart.

Bref contrairement à la poussée d'Archimède, cet écart est complètement négligeable.

Pendant qu'on est dans les effets négligeables, même dans en l'absence complète d'atmosphère, il y a plein d'autres paramètres à prendre en compte si on ne veut rien négliger. Par exemple, la position de la balance et son orientation à cause de la force de coriolis et de la force centrifuge. Et puis il ne faut pas oublier l'influence de la lune, du soleil et de tous les objets qui ne sont pas équidistants des centres de gravité des 2 objets (ce qui inclue la balance elle-même)

1

car ce n'est ni plus substantiellement long à écrire, ni à lire, ni à comprendre, ni à stocker.
Donc, pour moi, à ce niveau, 'var' c'est inutile.

Le gain principal c'est qu'il n'y a pas de répétition, ça fait moins d'information à lire / à analyser. C'est pas énorme, mais on n'a jamais dit que ça révolutionnait le monde.

2

Désolé si ce n'était pas clair dans mon commentaire précédent, mais je n'ai jamais dit que c'était bien de mettre des var partout. Je dis juste qu'il y a des fois, c'est ce que fait le code qui est important, pas comment il le fait. Ce n'est clairement pas le cas de tous les codes.

le problème est masqué car le var myContacts = getContacts(); est juste au dessus de ta boucle.
Intercales un ou deux écrans de code et tu n'a plus le contexte.

Je ne vois pas ce qu'un écran ou deux changeraient. Au pire, tu ne sais plus que ça n'a pas été initialisé avec la méthode getContacts() mais ça n'a aucun rapport avec le typage.

Pour pas te perdre, tu vas avoir tendance à généraliser ce que tu fais dans ton exemple, cad nommer tes variables en fonction de leurs types.

Mes variables sont nommées en fonction de ce qu'elles contiennent, pas en fonction du type. Qu'est-ce qui te fait dire ça ?

Peut être un exemple simple et court qui te parleras plus :

On est d'accord dans ton exemple, l'implémentation sous-jacente est importante, c'est donc un cas où il ne faut pas utiliser var.

Pour le formuler autrement : développer c'est empiler des abstractions les une au dessus des autres. Le but c'est de choisir le niveau d'abstraction qui te permet d'être le plus efficace. Et ce n'est pas le niveau qui donne le plus d'information qui est le meilleur (sinon on serait tous en train de faire de la mécanique quantique pour comprendre notre code), c'est celui qui donne l'information la plus pertinente. Et ça ça dépend du contexte. Par exemple, je reprends ma variable contacts.
Si tu as besoin de trier une liste de contacts avec de grosses contraintes de performances, tu as intérêt à savoir précisément le type mais aussi à avoir des statistiques sur le contenu et le contexte d'appel. Tu as besoin de beaucoup d'informations. Tu vas écrire ta fonction avec un typage explicite et pas mal de commentaires pour documenter tout ce que le langage ne te permet pas d'écrire formellement.
Si tu as besoin d'afficher le nom de chaque contact, tu te moques de tout ça, tu ne le précises pas. Et si tu devais lire une telle fonction mais avec toutes ces informations, tu insulterais certainement le développeur qui te fait perdre ton temps avec des détails inutiles. Le type est juste un de ces détails inutiles parmi d'autres. La différence c'est que c'est une information apportée par le langage, non par les commentaires et que jusqu'à cette version il n'y avait donc aucun moyen de dire "le type de cette variable, c'est pas ce qu'il y a de plus important pour comprendre le code".

Suffit de passer ce "var" magique à une API qui a des méthodes de même nom mais avec des arguments de types différents pour être sûr d'avoir du code Java du niveau d'un code javascript…

Je ne suis pas sûr de comprendre ce que tu as voulu dire par là. Mais juste pour être certains qu'on parle de la même chose : le mot-clef var fait de l'inférence de type pas du Duck Typing. La variable a un type bien défini, nommé, et en général identique à celui de la valeur de l'expression affectée à la variable. La variable n'est pas du tout un argument valide pour une méthode qui attendrait un type différent mais avec des méthodes/propriétés de même nom.

Pour des exemples d'usage, personnellement je m'en sers quasiment partout dans mes déclarations de variables initialisées dans des méthodes :

Je trouve que :

var myMap = new HashMap<String, String>();

est plus lisible que :

HashMap<String, String> myMap = new HashMap<String, String>();

Ça évite de se répéter et il n'y a aucune perte d'information disponible visuellement dans cette situation.

Ensuite pour les retours de fonctions, le type n'est pas forcément l'information la plus importante. Des fois c'est la sémantique qui est importante, pas l'implémentation.
Dans l'exemple que tu donnes plus bas où on fait des calculs sur des entiers avec risque de dépassement, clairement le type est important et tu as intérêt à le rendre visible. On est dans un cas où l'implémentation est importante.
Par contre, si tu écris du code métier avec beaucoup d'abstraction, très rapidement tu te moques du type, le point important pour le lecteur est qu'est-ce qu'on veut faire, pas comment on le fait.

var myContacts = GetContacts();
for (var contact : myContacts){
   Display(contact.Name);
}

L'exemple ci-dessus est parfaitement compréhensible, peu importe le type de myContacts. Rajouter le type permettrait d'expliciter le comment on gère ça sous le capot. Mais si le lecteur est intéressé par le comportement de la méthode et non par son implémentation, c'est juste de la pollution visuelle. Contrairement à ce que tu insinues dans un de tes commentaires, ça n'a rien à voir avec le fait de se contenter d'un code qui compile, c'est simplement une question de qu'est-ce qu'on veut mettre en valeur dans son code.

les logiciels libres sont-ils libres de droits ?

La page des mentions légales ne dit pas ça. Elle dit que 4 des logiciels utilisés pour le site sont libres de droits. A aucun moment, elle ne généralise à l'ensemble des logiciels libres. Et ça ne veut même pas dire que toutes les déclinaisons de ces 4 logiciels sont libres de droits, juste que celles utilisées le sont.

quelles sont les conséquences de la mention concernant les logiciels utilisés par le site de la Cour de Cassation ?

Pour le commun des mortels, il n'y aucune conséquence. D'une part parce qu'au final cette mention ne dit pas grand chose (cf ma réponse à ta première question) et d'autre part parce que de toute façon cette page n'a pas la même valeur juridique qu'un arrêt de la cour.
Pour ceux qui ont des droits sur les logiciels en question (ou sur les autres logiciels utilisés mais non nommés), il peut y avoir des conséquences si cette mention ne respecte pas les conditions de la licence. Mais je pense que ce n'était pas le but de ta question.

Les dates que tu donnes sont les dates d'annonce de ces langages. Si on regarde la date des premières versions stables, l'écart est plus important.

Pour Go :

Version 1.0 was released in March 2012

Pour Rust :

La première version stable de Rust, Rust 1.0 est arrivée en 2015.

J'imagine que la plupart des gens attendent la première version stable d'un langage avant de faire un projet Github dessus. Ça doit pouvoir se vérifier (ou non) sur Github, mais je n'ai pas trouvé.

le reste c'est la vue de l'esprit du programmeur qui fait que certains lots de bits sont des nombres

Un bit, c'est un nombre. Un lots de bits, c'est une suite de nombres.

C'est notre interprétation qui en fait des nombres.

Notre interprétation consiste à donner une signification à ces nombres.

Si vraiment tu veux considérer qu'un ordinateur ne sait pas manipuler des nombres, il faut que tu descendes à un niveau plus bas que le bit. Tu peux dire qu'un ordinateur manipule des charges électriques qu'on interprète comme étant des bits. Mais ça serait quand même un peu tordu.