NicolasP a écrit 255 commentaires

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.

Si le client change de port la vérification de port tombe à l'eau.

Ça arrivera dès qu'un navigateur voudra lancer plusieurs connexions simultanées.

Pour ta dernière phrase je comprend pas où tu veux en arriver.

Je suppose qu'il voulait dire HTTPS et pas HTTP. En HTTP, tu n'arriveras pas à faire quelque chose de sécurisé dans le cas général. Même si la technique de vérification du port était applicable, tu fais circuler les login/mdp en clair sur le réseau. Il n'y a aucun intérêt de protéger la session, si tes login/mots de passe ne le sont pas. Qu'est-ce qui t'empêche de mettre en place du HTTPS ?

Ça reste par définition un langage de prog, et donc des lignes de code

Non. Ou alors il te faut une définition de langage de programmation très large. Il n'y a par exemple aucune possibilité de faire des branchements conditionnels ni aucune structure de données (hormis une variable tampon car ils ont la possibilité de faire des copier/coller), … On est très très loin du turing compliant.

On ne l'utilise pas pour faire de l'algorithmie, juste pour décrire de manière formelle des actions à répéter bêtement et méchamment.

Le fond de l'article part du postulat que ce sont les développeurs qui vont écrire les tests en gherkin.

Sur un projet sur lequel je suis, ce sont des fonctionnels qui ne savent pas écrire une ligne de code qui écrivent le gherkin. Et évidemment eux ils ne vont pas tester le statut d'une chaîne de tâches asynchrones. Ils vont tester "est-ce que quand je mets 'toto' dans le champ 'nom' et que je clique sur 'valider', ça m'affiche bien une page de confirmation dans laquelle j'ai une url vers bidule truc". Je schématise mais le principe c'est que eux vont faire les tests métiers plus ou moins de bout en bout. Les tests unitaires restent à la charge des développeurs (et ne sont pas faits avec du Gherkin).

Pour ce qui est de la motivation, ça a été très simple : soit ils font leurs tests à la main à chaque mise en prod, soit ils utilisent ça. Ils ont choisi de leur plein gré et ont été moteurs quant aux choix des "phrases" que les développeurs leur ont mis à disposition.

L'énoncé l'interdit :

une jeune araignée marche à une vitesse de 1m par minute et ne sait pas tisser de toile, sauter et encore moins se laisser tomber.

Clang générerait certains binaires plus petits que MSVC en étant ABI-compatible

L'article est plus mitigé (et dit l'inverse dans le cas de la version 64 bits optimisée avec /O2). Par contre, le binaire généré avec clang se compresse mieux que celui généré avec msvc. Du coup, l'installeur résultant est plus petit.

Le gras est de moi :
"However, compared to MSVC builds using link-time code generation (LTCG) and profile-guided optimization (PGO) Clang generates larger code in 64-bit for targets that use /O2 but smaller code for targets that use /Os. The installer size comparison suggests Clang's output compresses better."

La motivation des développeurs n'est pas dans la recherche d'un binaire plus petit ou plus optimisé mais dans le fait d'utiliser le même compilateur sur toutes les plateformes.

. Je ne suis pas sûr qu'un processus puisse directement en modifier un autre, même s'il y a filiation et qu'il est lancé sous l'identité du même utilisateur. Techniquement, le cloisonnement doit s'appliquer quand même

Pour utiliser assez souvent un débogueur sous Windows sans forcément être root, je te confirme que tu peux modifier l'espace mémoire d'un process qui t'appartient. Et c'est pareil sous linux : pas besoin d'être root pour lancer gdb sur un process à soi.

Je crois que la documentation à ce sujet sous Windows est là pour le principe général et là pour le fait que la création d'un process permette dans le cas général de modifier sa mémoire aux autres process du même user. J'ai bien dit "je crois", car ça dépasse largement mes connaissances et ne prétends pas tout comprendre aux articles donnés. La même documentation explique les cas qui ne fonctionnent pas : les process protégés par l'UAC et les process créés avec un contexte de sécurité plus élevés, utilisés notamment pour tout ce qui est DRM.

En plus, il faudrait mapper les deux processus dans des plages distinctes du plan mémoire.

Pas besoin de mapper le 2nd processus, il suffit d’accéder à la mémoire via des fonctions dédiées : ReadProcessMemory et WriteProcessMemory notamment.

Normalement sur le long terme tu vas également télécharger

Si j'ai bien compris, chez MS, ça se fait en même temps : https://jpassing.com/2011/05/03/windows-hotpatching-a-walkthrough/

Mais par contre cela peut (et doit) etre utilise pour modifier les binaires et propager des trucs pas propres non?

D'un point de vue sécurité, dés que tu peux modifier le code exécutable d'un process, tu as le même niveau d'accès que lui. La méthode décrite ne change rien au niveau des barrières. Si tu avais le droit de modifier le code, ça te permet de le faire proprement. Si tu n'avais pas le droit, ça ne te facilitera pas la vie.

Chez MS, ils font ça tellement souvent qu'ils ont prévu de quoi patcher leur code à la volée.

• chiffrement/déchiffrement côté serveur. C'est une limitation de sécurité que je trouve hallucinante en 2017

Je ne connais pas NextCloud, mais je vois quelques considérations d'ordre générale sur le fait que le chiffrement côté client ne soit pas implémenté sur toutes les applications en 2017 :
- Ça complique le dédoublonnage de fichiers à des fins d'économie d'espace disque (le serveur ne peut pas savoir que 2 utilisateurs ont uploadé la même photo)
- Ça empêche les recherches côté serveur (une recherche de tous les fichiers contenant un mot donné devient concrétement impossible)
- Si les métadonnées sont chiffrées, il devient aussi impossible de trier côté serveur pour par exemple afficher les 20 commentaires les plus récents (il faut rapatrier toutes les données côté client pour les trier, ce qui a un impact sur les performances)
- De manière générale, toute opération en masse qu'on aurait tendance à effectuer côté serveur devient impossible (générer des miniatures des photos, recherche de contacts en doublons, …)
- Impossible d'être compatible avec des protocoles standards (diffusion de fichiers multimédia par exemple) qui n'ont pas prévu cette fonctionnalité.

Pour répondre à certaines de ces problématiques, on aurait besoin de chiffrement totalement homomorpe sacrément performant. On ne sait pas faire aujourd'hui. Du coup, il faut choisir entre le chiffrement côté client ou les fonctionnalités.
A noter que les 2 options ne sont pas exclusives. Il se pourrait très bien qu'il y ait un module de gestion de photos avec du chiffrement côté serveur et un module de gestion de mots de passe avec du chiffrement côté client.

Par contre, dans un contexte pro l'avantage est certain ; l'administrateur peut avoir une clé de déchiffrement de secours qui permet de déchiffrer les fichiers de tous les utilisateurs si besoin est

Si le besoin c'est que l'administrateur soit capable de déchiffrer les fichiers car un utilisateur a perdu son mot de passe, c'est compatible avec le chiffrement côté client. Il suffirait que les clefs de chiffrement des utilisateurs soit chiffrées avec une clef publique de l'administrateur et stockées sur le serveur. Ça nécessite cependant de faire confiance aux utilisateurs (pour pas qu'ils envoient une clef bidon, ce que le serveur serait incapable de détecter). Ça ne répondrait donc pas à un besoin de l'administrateur de vérifier par exemple que le contenu des fichiers uploadés respecte certaines règles (et encore il pourrait supprimer a posteriori les fichiers qu'il ne peut pas lire).

Je ne suis pas sûr de comprendre les implications. En gros ma clef wifi ne serait pas protégée, c'est ça ?

Ça voudrait dire qu'en cas de perte du PC, il faudrait que je modifie la clef. Si c'est juste ça, ça reste acceptable pour moi.

Pourquoi ne pas juste chiffrer le home du coup?

Parce que je n'y ai pas pensé :) Effectivement je viens de regarder ça semble correspondre à mon besoin et c'est simple à mettre en place.

Merci !

Merci pour cette explication.

Je vois bien que ça marche sur l'exemple donné plus haut, mais ce n'est pas du tout évident pour moi que l'arrondi bancaire donne cette garantie. Tu peux détailler stp ?

N'étant pas convaincu de la garantie, j'ai essayé de comprendre l'intérêt de l'arrondi bancaire par rapport à l'arrondi au plus proche (celui où quand la partie à arrondir vaut exactement 5, on arrondit au supérieur).

Intuitivement, l'arrondi au plus proche est meilleur car les plages d'arrondis font exactement la même taille pour tous les nombres. Par exemple si on arrondit à l'entier (pour simplifier, ça ne change rien si on arrondit à 2 décimales) :
- La plage [0.5- 1.5[ s'arrondit à 1
- La plage [1.5- 2.5[ s'arrondit à 2
- La plage [2.5- 3.5[ s'arrondit à 3
- La plage [3.5- 4.5[ s'arrondit à 4
- …

Alors qu'avec l'arrondi bancaire, on a un biais qui favorise les nombres pairs :
- La plage ]0.5- 1.5[ s'arrondit à 1
- La plage [1.5- 2.5] s'arrondit à 2
- La plage ]2.5- 3.5[ s'arrondit à 3
- La plage [3.5- 4.5] s'arrondit à 4
- …

Cependant vu que c'est utilisé en plein d'endroits par plein de gens plus compétents que moi, il y a sûrement une raison mais je ne l'ai pas trouvée.
Wikipedia évoque un biais corrigé par l'arrondi bancaire, mais sans expliquer lequel.
Sur le web, on peut lire que le problème de l'arrondi au plus proche c'est que quand la partie à arrondir vaut exactement 5, on arrondit toujours au supérieur. Mais je ne vois pas en quoi c'est un problème. Pour moi, c'est une nécessité si on veut une bonne répartition des arrondis.

Quelqu'un peut m'éclairer ?

et les problème de débordement disparaissent.

Et sont remplacés par un problème qui est probablement encore plus fréquent (quand a et b ont la même valeur, l'algorithme met les 2 valeurs à 0).

En python, la bonne manière de faire est celle de François Guerin.
Il faut arrêter de se dire que plus un code repose sur une technique complexe, plus il est stylé/beau. C'est faux. Pas de bénéfice et des inconvénients par rapport à la méthode standard, ça veut dire que c'est un mauvais code.

le 1 an ca ressemble au stagiaire/technicien qui paye avec ses sous le renouvellement pour "aider", comme a la fin du mois il sait que la compta ne va pas valider ses frais "car il manque le numéro de tva intracommunautaire", une impression d'ecran n'est pas une facture etc … . a propos ta demande de congé est refusé, le chef prend les même date que toi.

Et encore, le stagiaire/technicien a eu de la chance que le renouvellement ne se fasse pas par payment CB protégé par 3D Secure

Par contre j'aimerai que https par défaut.

Pour quelle raison ?

En 2017, il faut inverser le raisonnement. On ne devrait plus avoir à justifier l'usage du HTTPS qui devrait être le choix par défaut. Au contraire, c'est quand on propose du HTTP qu'il faut le justifier.

L'apport de https semble assez faible. Les paquets Debian étant signés gpg par leur mainteneurs, la préservation de leur intégrité est indépendante du protocole comme du pigeon par lequel ils ont été acheminés.

HTTPS propose plus que l'intégrité de la réponse du serveur. Il y a la confidentialité comme abordé dans un autre commentaire, mais aussi l'intégrité de la requête du client. Est-ce que par exemple, un attaquant ne pourrait pas forcer un downgrade de la version d'un paquet ? Au lieu de télécharger la version N sur un serveur de Debian, le client se retrouve à télécharger la version N-1 qui contient des failles de sécurité sur le serveur de l'attaquant. Cette version N-1 ayant été "légitime" en son temps, elle aussi est signée.

Il y a peut-être des mécanismes dans Debian qui protège de ça, mais clairement la signature GPG à elle toute seule n'est pas suffisante pour se dire que le HTTP c'est sécurisé.

Dans l'exemple donné sur SO, tu as 2 parties :
1. La première consiste à écrire du code pour convertir ta liste. Ce code est à écrire en C# et à compiler pour obtenir un fichier DLL (y compris sous linux)
1. La deuxième consiste à utiliser cette DLL en y faisant référence. L'auteur de la réponse a supposé qu'elle était présente dans C:\Debug\ListInConstr

Si j'ai bien compris, tu n'as appliqué que la 2ème partie, c'est pour ça que ça ne marche pas. Par contre, j'avoue ne pas comprendre non plus à quoi sert la 1ère partie.

Vous savez comment convertir une liste Python vide en .NET ?

Si la liste que tu veux passer est vide, c'est peut-être plus simple de créer directement une List .NET vide que de convertir une liste python.

Je ne connais rien à PythonNet mais d'après le readme ça pourrait donner quelque chose comme :

from PrincetonInstruments.LightField.Automation import Automation
from System.Collections.Generic import List
from System import *
l = List[String]()
instance = Automation(True,l)

un certificat délivré par eux a la même utilité et offre la même sécurité qu'un certificat délivré par n'importe quelle autre autorité (tant que vous générez votre CSR de votre côté)

Si on parle de la sécurité de la clef privée : oui c'est la même qu'avec une autre CA. Si on parle de la sécurité du service qui utilise le certificat : non la sécurité est plus faible qu'avec une autre CA. Il y a un risque non négligeable que du jour au lendemain WoSign ne soit plus reconnue comme CA de confiance :

if such additional back-dating is discovered (by any means), Mozilla will immediately and permanently revoke trust in all WoSign and StartCom roots.

Il y a donc un risque que le service devienne indisponible du jour au lendemain.

De plus, est-ce que demander des certificats à une CA en laquelle on ne peut pas avoir confiance est vraiment une bonne idée ? Est-ce que ça ne donne pas du poids à cette CA pour dire "si vous nous retirez de la liste des CA reconnues, ça va causer beaucoup de problèmes. Donc ne le faites pas / donnez nous un plus long sursis !" ?