Buf a écrit 449 commentaires

Le but est alors d'avoir un captcha qui distingue les humains légitimes (vrais acheteurs) des humains non légitimes (payés pour).

Le but n'est pas forcément d'aller jusque là (ça me semble très difficile, surtout si on ne veut pas rejeter d'acheteur légitime), mais plutôt d'avoir des moyens d'ajuster la difficulté en fonction d'un certain nombre de règles. Le but est de faire perdre un maximum de temps (et donc d'argent) aux services de résolution, tout en évitant de faire fuir les clients légitimes.

Si au lieu de pouvoir résoudre 1000 captchas à l'heure (par exemple), une personne n'arrive plus qu'à en faire que 50, ça risque de réduire suffisamment la rentabilité du service pour qu'il ne soit plus viable.

Effectivement, s'il n'est pas exercé et mis à jour régulièrement, un plan ne vaut pas beaucoup mieux qu'une absence de plan.

Oui, la crise est exceptionnelle, mais elle était aussi prévisible dans ses grandes lignes. On a déjà eu plusieurs crises au XXIème siècle qui aurait dû nous préparer à ce que l'on vit actuellement (SARS, MERS, H1N1).

Et le but n'est pas de tout dimensionner de façon à pouvoir réagir parfaitement à n'importe quelle crise, c'est avant tout une question d'organisation : avoir un minimum de stock de produits de première nécessité (nourriture, médicaments, matériel de protection, etc), avoir des plans pour en obtenir davantage en cas de besoin, si possible sans dépendre de l'étranger (par exemple, avoir des partenariats avec l'industrie pour garder une capacité de production locale), et surtout, avoir des procédures en place, histoire de pouvoir être pro-actif quand la crise arrive, plutôt que l'anarchie actuelle où on ne fait que réagir avec un temps de retard.

Alors oui, tout ça coute de l'argent. Il faut voir ça comme une assurance : en temps normal, c'est de l'argent dépensé dans le vide, mais en cas de gros pépin, c'est inestimable.

La flambée en Italie n'a surpris que ceux qui n'ont pas prêté attention à ce qu'il se passait en Chine. Dès le mois de janvier, on avait une très bonne idée des paramètres de l'épidémie.

Et au passage, 2% de mortalité, c'est environ 20 fois une grippe moyenne. Le pourcentage d'hospitalisation n'a également rien de comparable. Rien que sur cette base, il aurait fallu mieux se préparer.

Histoire de remettre en contexte : le 6 mars, il y avait déjà plus de 4600 cas identifiés en Italie, avec presque 200 morts. La situation était déjà visiblement hors de contrôle là-bas. Parler de sur-réaction à ce moment-là, c'est avoir la tête profondément enfoncée dans le sable.

Ce n'est pas un SCUD, c'est le prix du travail effectué, qui motivera ensuite l'entreprise à acheter une maintenance correcte. Dit-toi que si tu fais le gentil, la conclusion est qu'il y aura un gentil pour le problème suivant et que donc pas besoin de dépenser en maintenance. Si tu as un problème éthique, dit-toi que baisser ton prix est en fait mauvais pour eux à long terme.

Ce que mon chef faisait dans mon ancienne boite, c'était de toujours mentionner sur les factures le coût réel de l'intervention (genre x heures à y de l'heure), puis d'appliquer (ou pas) un rabais sur le montant à payer. De cette façon, le client est conscient qu'on lui fait une fleur et voit bien ce que ça risque de lui coûter à l'avenir pour une intervention similaire.

J'entends par là isoler l'espace mémoire utilisé par chacune des tâches. Sur un Amiga 500, un programme peut lire et écrire n'importe où en mémoire, y compris dans l'espace du noyau ou des autres tâches, et l'OS ne peut rien faire pour empêcher ça car le processeur ne possède pas le circuit de gestion de la mémoire requis (MMU).

Ça ne change rien au fait que l'Amiga était effectivement en avance sur son temps et son OS était un vrai multitâche préemptif, à l'époque où le reste des ordinateurs personnels étaient encore tous monotâches.

Précision : le 286 a quand même un MMU, mais sans fonctionnalité de mémoire virtuelle, qui est le mécanisme de base de protection de la mémoire des OS actuels.

L'Amiga 500 n'était pas capable de protéger les tâches, le 68000 n'ayant pas de MMU. Et le 286 en était bien capable, même s'il n'avait pas de MMU, en utilisant la segmentation et les tables de descripteurs locales (ce qui est loin d'être aussi efficace que ce permet le 386).

Quand la facture est émise, tu as 30 jours pour la payer, si tu es dans les délais, il n'y a pas d'intérêts. Ça permet donc de payer certains achats quasiment 2 mois plus tard. Les intérêts commencent à courir uniquement en cas de paiement en retard ou partiel.

La situation dont on parle ici, c'est pour un voyage de plusieurs mois (si c'est 2-3 semaines, pas de problème pour payer la facture au retour). La connexion e-banking dans ce cas, ça va être un truc à prévoir dans tous les cas, parce qu'il risque bien d'y avoir d'autres choses à gérer pendant ce temps.

Et sinon, le https est suffisant en lui-même, pas besoin d'un VPN pour se connecter à sa banque quand on est sur un réseau dans lequel on n'a pas confiance.

Mais sinon des fois les voyages sont à cheval entre deux mois donc à choisir si c'est payable avec la Maestro je le fais et je pense que beaucoup d'autres le font aussi.

Je vois pas le problème. La facture de la carte de crédit, elle est payable à 30 jours en général, donc même si tu es en voyage quand elle arrive, normalement ça ne pose pas de problème (et encore moins si la facture est électronique, dans ce cas, c'est payable depuis n'importe où).

Et pour le côté gestion, j'ai une application qui va avec ma carte de crédit (Corner card), je peux consulter en tout temps les achats qui ont été faits avec ma carte, ainsi que le solde disponible.

(Les bazouins papier ça marche aussi, mais c'est un peu rétro, non?)

Oui, mais pas mal d'entreprises les utilisent encore. Ma banque propose un truc pas mal pour traiter les bulletins papier : depuis leur application smartphone, je prends en photo la ligne de codage en bas du bulletin de versement (qui contient toute l'information utile pour faire le virement), et ça va automatiquement l'ajouter à une liste de paiements à traiter la prochaine fois que je me connecte à mon compte.

Le truc c'est que nos Visa/Mastercard sont de vrais cartes de crédits donc si la Maestro est supportée on a plutôt intérêt à la sortir avant car zéro intérêt.

Avec une carte de crédit, il n'y a des intérêts à payer que si le solde n'est pas payé complètement dans les délais. Si on paye complètement sa facture chaque mois, il n'y a pas d'intérêt.

Dans mon cas : pour les payements, j'utilise uniquement mes cartes de crédit, en payant chaque mois la totalité du montant. La carte de débit (Postfinance dans mon cas, c'est pas vraiment correct de dire que tout le monde a une Maestro) ne me sert que pour retirer du cash.

Parce que les API pour programmer le GPU ne sont pas les mêmes d'une plateforme à une autre (OpenGL sous Linux, DirectX sous Windows, Metal sous iOS/macOS), il faut donc ajouter une couche d'abstraction indépendante de l'API graphique si on veut du multiplatforme.

Cet article explique assez bien le problème et donne des références vers les sections du standard C99 https://www.viva64.com/en/b/0306/

Je ne vois pas de comportement indéfini dans le code.

J'ai l'impression que tu considères qu'un pointeur nul est un pointeur vers l'adresse 0. Ce n'est pas ce que disent les différents standard C/C++, un pointeur nul est une valeur à part, ça représente une adresse invalide. Quand on essaie de le déréférencer, on a un comportement indéfini.

En pratique, le compilateur ne va en général pas s'embêter et va effectivement générer un accès à l'adresse 0, mais il n'a aucune obligation de le faire.

Je parle uniquement en cas de comportement indéfini. Quand c'est défini, le compilateur doit convertir le code de façon à ce résultat corresponde à ce qui est défini, c'est évident, sinon il ne respecte pas le standard.

Mais dans le cas dont on parle (déréférencement d'un pointeur nul), le comportement est bien indéfini, et ça laisse donc la liberté au compilateur d'en faire ce qu'il veut. Il aurait effectivement tout aussi bien pu remplacer le tout par le code que tu donnes, ça aurait été autant valable que le choix qui a été fait.

Je n'ai pas de source officielle, mais si tu fais une recherche "C++ null pointer undefined behavior", tu vas trouver des tas de références.

Maintenant, en pratique, ça va effectivement dans la plupart des cas résulter en un accès à l'adresse 0, et la plupart des OS vont faire en sorte que ça donne une erreur (en ne mappant aucun page à cette adresse), ce qui va donner le SEGFAULT bien connu.

Mais c'est juste une possibilité, si le compilateur voit une opportunité d'optimisation, il a tout-à-fait le droit de faire ce qu'il veut.

Je vois plusieurs explications qui peuvent expliquer qu'il n'y ait pas d'avertissement :

• c'est compliqué à implémenter dans le cas général
• ce n'est pas vraiment utile en général
• ça risque d'inonder l'utilisateur de faux positifs dans le cas d'un programme typique

Le point commun de tout ça : l'exemple donné ici est construit exprès pour démontrer ce comportement, ça ne représente pas un cas général. Il ne faut donc pas jeter trop vite la pierre aux devs de Clang, ils cherchent avant tout à optimiser des programmes réels, infiniment plus complexes que la démo qu'on a ici. Et je suppose que le problème doit être d'une complexité toute autre quand on a des centaines de milliers de lignes de code réparties dans plusieurs dizaines de fichiers.

Un pointeur nul a une signification particulière dans les langages C et C++, et en particulier, le fait de le déréférencer est un comportement indéfini, et donc le compilateur n'a absolument aucune obligation de transformer ça en un accès à l'adresse 0, il peut en faire ce qu'il veut.

Les strings, ça ne sert pas qu'à afficher du texte à destination de l'utilisateur, et donc, même pour une application affichée en chinois (par exemple), il y aura probablement beaucoup de chaines de caractères qui sont codables en latin1 : requêtes SQL, chemins vers des fichiers, URLs, messages pour les logs, etc.

Au final, on gagnera de la place sur tout ça, et ça risque bien de largement contrebalancer le fait qu'on doive stocker un flag supplémentaire sur chaque objet string.

Non, pas du tout. En fait, avant, tout était codé en UTF-16. Maintenant, un objet String contient un nouveau champ qui précise l'encodage utilisé. Ça va être latin1 si possible, ou UTF-16 sinon. Pour le développeur, ça ne devrait rien changer, c'est un détail d'implémentation et l'API publique ne change pas.

Ça change rien au problème, la question de base reste la même : est-ce que le type de données utilisé est adapté au problème ?

Si le type monétaire que tu utilises n'offre pas la précision voulue pour les calculs que tu dois faire, clairement, il n'est pas adapté, mais ça ne veut pas pour autant dire que les flottants binaires sont la solution. Il existe d'autres types décimaux, avec plus de chiffres significatifs (voire de précision arbitraire, genre BigDecimal en Java), c'est de ce côté-là qu'il faut chercher.

Après, suivant le problème, on peut éventuellement ne pas avoir besoin d'une grande précision au final (genre pour une analyse statistique), et là, les flottants binaires seront adaptés, car nettement plus efficaces.

La question à se poser, c'est pas tellement s'il y aura ou pas une erreur à la fin, c'est plutôt : est-ce que j'utilise un type de données adapté à mon problème ?

Si on a du float ou double pour du monétaire, la réponse est clairement "non". Même si dans la majorité des cas, on arrivera quand même à un résultat correct, il existe des types de données mieux adaptés (car conçus précisément pour résoudre ce problème).