Buf a écrit 449 commentaires

Je suis quasi certain que les bases de données modernes utilisent double ou long double.

Les bases de données possèdent plusieurs types numériques (dont float et double), mais pour stocker du monétaire, elles n'utilisent ni l'un ni l'autre, elles utilisent des flottants décimaux. Le C ne possède nativement aucun type de ce genre, mais ça existe dans d'autres langages (type decimal en .Net, par exemple).

Par DECIMAL tu veux parler d'arithmétique exacte en virgule fixe?

Le décimal est généralement en virgule flottante, mais l'exposant est simplement appliqué en base 10 au lieu de base 2.

Ben si, ça a de l'importance, parce que dès le départ, ta valeur est entachée d'une erreur (petite et bornée, certes). Maintenant, si tu additionnes 2 millions de nombres avec chacun ce type d'erreur, les erreurs s'additionnent, et le résultat pourra être faux de manière imprévisible, même si on ne fait aucun arrondi intermédiaire.

Avec du décimal, on additionnerait des valeurs exactes, et le résultat serait donc exact.

Il est tout à fait possible de suivre les mêmes règles avec du code utilisant des flottants.

Non, parce que les valeurs initiales seront déjà entachées d'une erreur. Par exemple, on ne peut pas représenter exactement un montant de 10.15€ avec un float, donc peut importe les règles qu'on définit derrière, le résultat pourra être faux.

Le problème n'est pas une question de chiffres significatifs, si on fait le même test avec 30.14, on obtient à l'affichage 30.139999 (alors même que la valeur de base n'a que 4 chiffres significatifs).

Le problème, c'est que l'exposant est appliqué en base 2, et du coup, le nombre en question n'est pas représentable de façon exacte, peut importe la taille de la mantisse et de l'exposant, tout comme on ne peut pas représenter de façon exacte le développement décimal de 1/3.

Si tu stockes tout en centimes, tu utilises des nombres à virgule fixe, ce qui revient à avoir un exposant constant et décidé à l'avance. Comme tu appliques ton exposant en base 10, ça évite les problèmes de précision qu'on a avec le binaire.

En pratique, ça marche aussi, mais ça a l'inconvénient que tu limites d'entrée de jeu la précision que tu peux avoir. Si un jour tu as besoin de dixièmes de centime, tu es bloqué.

je crois c'est plutôt un problème de représentation/stockage des nombres en virgule flottante en SQL (peut-être à cause de la nature binaire des principaux composants informatiques)

Oui, c'est ça, mais c'est pas limité au SQL, on a le même problème avec les floats/doubles dans n'importe quel langage de programmation qui les gère.

Comment est stocké un float (ou double, peu importe) en mémoire ? On a 3 éléments : une mantisse, un exposant et un signe. La mantisse et l'exposant sont des nombres entiers, le signe est juste un bit. La valeur représentée sera calculée comme puis suivant le bit de signe, ça sera positif ou négatif. Le problème de ceci, c'est que l'exposant est appliqué en base 2, ce qui empêche de représenter de façon exacte certains nombres. Par exemple, on peut représenter sans problème 0.5 (2^-1), mais 0.1 n'a pas de représentation exacte en float. C'est exactement le même problème qu'en décimal pour représenter des nombres comme 1/3 ou 1/7, on doit se contenter d'une approximation.

Pour un type decimal ou monétaire, c'est exactement le même principe, on retrouve nos mantisse, exposant et signe, mais la différence est que l'exposant est appliqué en base 10. Du coup, tout nombre avec un développement décimal fini est représentable de façon exacte (tant qu'on reste dans les bornes admises par le type).

Le problème quand on manipule des données monétaires avec des floats, c'est que pratiquement chaque valeur non entière sera entachée d'une petite erreur dès le départ, et que ces erreurs vont pouvoir s'accumuler au fil des calculs, et on risque d'avoir un résultat significativement faux à la fin.

il était fait mention de prévisions de pluviométrie pour Harvey qui n'excédait pas la moitié de celles d'une autre tempêtes du milieu des année 00 (~2005). Si j'ai bonne mémoire ~1m pour l'aînée, et ~50cm pour la cadette. Mais les chiffres ont peut-être évolué ? Sinon, il semble que la proximité amplifie notre perception ; à mettre en perspective donc.

Harvey a provoqué un cumul de précipitations de 51 pouces (soit environ 1.3m) à certains endroits. Source

long n = 1;
Console.Write(n >> 64);

affiche 1.

Mais le comportement est spécifié :

When the type of x is long or ulong, the shift count is given by the low-order six bits of count. In other words, the shift count is computed from count & 0x3F

Spec

Autrement dit, un décalage de 64 est considéré comme un décalage de 0, parce que seuls les 6 bits de poids faibles sont pris en compte.

Je ne vois aucune mention de l'encodage utilisé pour les chaines de caractères, alors que c'est un point crucial pour un outil qui génère du binaire. Il faut différencier l'encodage du fichier source (qui peut être imposé, par exemple UTF-8), et le résultat dans le binaire généré, qui devrait pouvoir être spécifié (sur le modèle de ce qui est fait pour l'endianness).

Sur la réutilisation du couple key/iv, c'est effectivement toujours une erreur, mais en mode CTR, c'est absolument catastrophique. Ça signifie par exemple que si je connais un couple cleartext/ciphertext, je peux déchiffrer absolument tous les autres messages chiffrés avec le même couple key/iv d'une taille inférieure ou égale à mon message ! (et les autres, je peux déchiffrer le début)

Utiliser des algorithmes connus et réputés, c'est bien, mais c'est la partie facile. Concevoir un système complet qui soit sécurisé, c'est très difficile, et même les pros et spécialistes dans le domaine font des erreurs. Pour un débutant (et à te lire, je pense que c'est ton cas), c'est quasiment impossible d'y arriver du premier coup, tellement il y a de pièges à éviter et d'erreurs à ne pas commettre.

Il n'y a aucun mal à essayer et développer son propre système (c'est une façon d'apprendre), par contre, il faut bien être conscient que ce n'est en l'état qu'un jouet, et ça ne devrait en aucun cas être utilisé pour stocker quoi que ce soit d'important. Le numéro de version 1.0.0 est trompeur, ça donne l'impression qu'on a quelque chose qui est prêt à être utilisé, or ce n'est pas le cas du tout. Tu devrais mettre un avertissement clair sur le site, histoire d'éviter que quelqu'un n'utilise ça en pensant être en sécurité.

https://explosm.net/comics/3479/

J'ai fait 2-3 tests, voici où on en est aujourd'hui (pour les dernières version de tous les navigateurs cités)

• sur un 301, Firefox et Chrome changent le POST en GET. IE garde le POST, mais n'affiche aucun avertissement (alors que c'est exigé par la spec)
• sur un 302, tous les browsers changent le POST en GET, et c'est le comportement attendu par la plupart des frameworks web (mais ça ne correspond pas à la spec)
• le 303 est traité correctement partout (mais peut éventuellement poser problème avec les très vieux browsers)
• avec un 307, tous les browsers conservent le POST, mais seul Firefox affiche un avertissement, conformément à la spec.

Dans tous les cas, j'ai beaucoup de mal à imaginer une situation dans laquelle le comportement POST-redirect-POST est utile. En pratique, on ne retourne jamais de 301 après un POST.

Maintenant, concernant la spec HTTP2, à mon avis, ils cherchent à coller à la pratique actuelle plutôt qu'à suivre ce qui est dit dans la spec HTTP 1.1 (et que personne ne respecte)

Il faut aussi tenir compte du fait que quand un disque lâche, le RAID passe en mode dégradé, ce qui peut considérablement augmenter la sollicitation sur les disques restants et donc la probabilité qu'un autre lâche peu de temps après.

En fait, après réflexion, je confonds peut-être avec Java Web Start. Là, il me semble qu'on peut régler plus finement les permissions.

Sauf qu'en fait ça le fait sortir automatiquement de tout confinement, sans choix possible

Je sais pas si ça a changé, mais à l'époque où je faisais du Java, il ne suffisait pas que le code soit signé pour sortir de la sandbox, il fallait également une autorisation explicite de l'utilisateur.

Pas sûr. J'ai pas l'impression qu'il y a eu des masses de BR de boules, les fournisseurs sont plutôt passés massivement au dématérialisé.

En multijoueurs, Steam est le passage obligatoire.
Un jeu multijoueur non disponible sur Steam est très vraisemblablement voué à l'échec à cause du manque de joueurs.

Exception notable : les jeux Blizzard. Je ne pense pas qu'on puisse dire que Starcraft 2 ou Diablo 3 soient des échecs ou manquent de joueurs…

Honnêtement, je pense que le Bitcoin est une mode, et ça va passer. Sa valeur actuelle est basée sur une forte demande (à cause de l'effet mode), mais ça ne va probablement pas durer. Et dès le moment où l'effet de mode sera passé, ça va très vite s'écrouler, on risque d'avoir l'équivalent virtuel d'un bank run, avec tout le monde qui essaie de vendre au plus vite et les cours qui s'effondrent.

Estimation au pifomètre : dans 3 ans, le Bitcoin aura pratiquement disparu.

Ça veut aussi dire que quelqu'un, quelque part, a dû perdre l'équivalent de la valeur de ta tablette, donc Bitcoin, c'est aussi le risque d'y laisser des plumes.

Si tous les virtual hosts sont dans le même domaine, ça marche aussi avec un certificat wildcard (par exemle, avec un certificat pour *.example.com, ça marchera pour site1.example.com, site2.example.com, etc.)

Et je suis d'accord, il n'y a pas de raison de vérifier l'identité, à moins de la mettre dans le certificat, ce qui n'est pas fait aujourd'hui.

C'est fait pour les certificats EV (extended validation), qui sont signalés par les navigateurs (passage en vert de la barre d'adresse, par exemple). Pour obtenir un tel certificat, il y a bien une vérification de l'identité du demandeur (alors qu'effectivement, pour un certificat normal, on vérifie au mieux que le demandeur possède bien le nom de domaine)

Par exemple, si je vais sur le site de ma banque (https://www.postfinance.ch/), en 1 click je peux voir que le certificat a été fourni à l'entreprise Postfinance AG, à Berne, en Suisse.

Le terminal mobile étant l'avenir de la consultation du web, et le poids lourd sur ce secteur étant google.

Pour le moment, c'est encore largement Apple (source : les statistiques de fréquentations des différents sites web hébergés par ma boite, iOS représente en moyenne 2 fois plus de visites qu'Android), et Safari ne supporte pas WebP. Donc pas d'urgence de ce côté-là.

j'ai du mal a voir en quoi ça renforce la sécurité, si l'algo du challenge est connu, ça fait juste rajouter une étape,

Avec ce genre de systèmes, il y a un secret partagé entre l'appareil et le fournisseur du service. La sécurité repose là-dessus, pas sur l'algorithme.

T'as rien compris, il y a un réseau parallèle secret via des backdoors dans les antennes de tous les opérateurs de la planète. Ils ne sont au courant de rien, mais à chaque fois qu'une nouvelle antenne est posée, le réseau d'écoute mondial se développe.