Buf a écrit 441 commentaires

À propos de unsafe, quand tu dis :

Sauter un bound check (vérification que i est entre 0 et t.len() quand on fait t[i]) dans une boucle appelée des millions de fois, quand on est sûr que l'indice est bien dans les bornes.

C'est très souvent faisable sans passer par unsafe.

Le compilateur va générer un bound check uniquement dans les cas où il ne peut pas déterminer à la compilation si l'accès risque d'être hors bornes. Si on ajoute une vérification explicite qui lui permet d'être sûr qu'aucun accès hors bornes n'est possible, il n'y aura pas de bound check.

Une autre façon est de modifier la boucle pour utiliser un itérateur, quand c'est possible.

Ça semble un peu plus compliqué que ça. Voici la page qui décrit la prestation : https://www.post.ch/fr/reception/demenagement/annonce-de-demenagement

Le point "Les entreprises participantes sont informées directement par la Poste (y c. date de validité = date du déménagement)" semble indiqué que ces entreprises sont informées au préalable. Comment est-ce que la Poste sait à qui communiqué l'info ? Je n'ai pas trouvé l'explication.

Tout à fait. Et le problème va encore être amplifié à mesure que les nouveaux modèles seront entrainés avec du texte généré par AI. On risque d'avoir un problème de dégénérescence progressive dû à une diminution de la qualité des sources.

Évidemment, il ne faudrait en théorie entrainer ces modèles qu'avec du texte écrit par des humains, mais en pratique, c'est très difficile à faire.

calibre et le plugin sont libres à 100%, mais il s'agit d'un plugin non-officiel, utilisation à tes risques. Je l'utilise depuis plusieurs pour pouvoir transférer les livres de ma bibliothèque sur ma liseuse Kobo, aucun problème à signaler.

Thorium est mixte. Le gros du lecteur est libre (BSD 3-clause), mais la partie qui gère le DRM est un blob non libre. À toi d'en tirer les conclusions que tu veux. Pour le code source, c'est par ici : https://github.com/edrlab/thorium-reader

Il y a eu un autre type de rendu intermédiaire qui n'est pas mentionné dans la dépêche, utilisé entre autres par Alone in the Dark (sorti en 1992). Ici, le personnage, les ennemis et les objets sur lesquels on peut agir sont en vraie 3D avec un rendu temps réel, et les décors sont précalculés (et donc gérés comme de simples images 2D), avec des positions de caméra fixes.

À l'époque, l'animation des personnages était une vraie révolution, avec des mouvements parfaitement fluides de modèles 3D.

Dire que c'est juste un jouet, c'est se méprendre complètement sur les buts du projet.

Wireguard ne cherche pas à être une solution clé en main pour du VPN d'entreprise. Le but est de fournir un protocole robuste et efficace, ainsi qu'une API pour permettre à des outils externes de fournir les fonctionnalités avancées. On trouve par exemple Tailscale, qui propose une solution complète avec toutes les fonctionnalités que tu mentionnes. Il y aussi pas mal de projets libres, avec différents niveaux d'avancement.

Un autre article intéressant sur le sujet, qui arrive en gros à la même conclusion : https://davidgerard.co.uk/blockchain/2022/08/20/proof-of-stake-is-better-than-proof-of-work-but-ethereums-merge-wont-fix-any-other-problem-with-cryptocurrency/

Ah non, Pluto, c'est le chien de Mickey. L'ami de Mickey, c'est Dingo.

Bon courage pour prouver le moindre préjudice individuel de la disponibilité de ton numéro de tel associée à ton nom (plus ou moins réel) et seulement de ça.

Il n'y a pas que ça. Pour certains comptes, on a aussi le lieu de domicile, l'employeur et la date de naissance. En recoupant avec d'autres informations (publiques ou issues d'autres fuites), on commence à avoir de quoi monter une usurpation d'identité.

Un serveur derrière un NAT, c'est pas forcément limité aux particuliers, c'est aussi très courant sur de l'hébergement pro en datacenter, en particulier si on utilise une solution basée sur des containers style Kubernetes.

Le serveur peut également être derrière du NAT, et là, le mode passif n’aide en rien.

La vraie question, c'est pas pourquoi Mozilla et les autres décident de supprimer le support de FTP, c'est plutôt : pourquoi en 2021 ce protocole est-il encore utilisé ? Il aurait dû disparaitre il y a déjà au moins 20 ans…

Pour rappel, la première RFC pour ce protocole date de 1971, c'est encore plus vieux que TCP/IP ! Et contrairement à d'autres protocoles, il n'a pas fondamentalement évolué depuis.

Le problème fondamental est l'utilisation de deux connexions : une pour les commandes, une pour les données. Pour que ça fonctionne sans friction, il faut partir du principe que chaque machine connectée a une adresse IP publique et qu'il n'existe pas de firewall. Dès le moment où on introduit du NAT ou un firewall, il faut commencer à bricoler, et ça devient rapidement très laid. En gros, on ne peut faire du simple port forwarding comme pour 99% des protocoles existants, il faut que le firewall supporte explicitement FTP pour pouvoir modifier les paquets au vol et ouvrir des ports dynamiquement. Et pour que ça marche, il faut que le firewall puisse inspecter les paquets, donc si on veut du SSL, il faut que ça soit aussi géré par le firewall (je pense que c'est une des principales raisons qui font que FTPS n'a jamais vraiment décollé).

On a de nombreuses alternatives bien meilleures depuis au moins vingt ans. Le protocole aurait dû être considéré comme obsolète et commencer à disparaitre à ce moment-là. Et qu'en 2021, sa suppression dans un browser fasse débat me dépasse complètement…

Par rapport à Oracle : principalement le prix. Pour une grosse installation, le prix des licences Oracle est ridiculement élevé, typiquement un ordre de grandeur au-dessus de l'équivalent en SQL Server.

Par rapport à PostgreSQL : comme déjà mentionné, c'est le choix "naturel" quand on a déjà un environnement Microsoft ou qu'on développe en .Net, tous les outils sont conçus pour fonctionner ensemble et s'intègrent facilement. On a aussi un ensemble de fonctionnalités avancées disponibles en standard qui n'existent que sous forme d'outils externes pour PostgreSQL (au niveau de la réplication et haute disponibilité, par exemple, ou pour les données géographiques). Et pour les installations plus petites, il y a une version "Express", gratuite. Elle est évidemment très limitée (en particulier, il y a une limite sur la taille maximale de la db), mais ça reste suffisant dans beaucoup de cas.

Pour avoir travaillé sur SQL Server, je dois dire que c'est un plutôt bon produit, que ça soit niveau fonctionnalités, stabilité, performance ou facilité d'utilisation.

Je ne suis pas spécialiste en crypto et pour moi, OCB, c'est autre chose, mais quand on mentionne "mode d'opération authentifié", je pense immédiatement à GCM.

Est-ce que OCB a des avantages concrets et importants par rapport à GCM qui peuvent justifier de le préférer à ce dernier ? En faisant une recherche rapide, j'ai trouvé deux petites choses : plus simple à implémenter et un peu plus résistant à une réutilisation de nonce avec une même clé. Ça me semble assez faible comme arguments.

Mac OS 9 n'est pas un ancêtre de Mac OS X, même lointain. Si on voulait faire une métaphore familiale, ça serait plutôt un beau-frère ou un cousin par alliance.

Les deux systèmes n'ont rien en commun techniquement, leur lien de parenté est purement contractuel.

Pour moi, c'est un VPS chez Gandi, avec Exim pour la partie SMTP et Dovecot pour l'IMAP.

Il y a un très gros risque d'insérer des données pourries sans s'en rendre compte immédiatement, et c'est ensuite la misère à corriger.

Le CSV, c'est la fausse bonne idée par excellence, le truc qui a l'air simple mais qui ne l'est pas du tout dès qu'on tombe sur un cas non prévu initialement.

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.