fork_bomb a écrit 64 commentaires

Il n’y a pas de contradiction dans nos deux messages

Je ne comprends pas comment il peut ne pas y avoir contradiction ? Tu parles du "choix" de la séquence chronologique continue puis de ses inconvénients.

Ça me parait incompatible avec le fait que la séquence chronologique continue est obligatoire ¹.

Je suis d’accord sur le principe pour éviter les collisions, mais le choix de la séquence chronologique continue ne doit pas forcément être la première idée basique venue.

Ce n'est pas "pour éviter les collisions", c'est une obligation légale pour que l'administration fiscale puisse s'assurer qu'elle est en possession de toutes les factures et qu'il n'y ait pas de factures antidatées créées a posteriori.

C'est soit du troll soit une tentative d'humour ratée.

Il fait référence à un type de faille qui s'appelle l'énumération.

Si un contenu est référencé par un numéro séquentiel, par exemple banquefr.com/compte/1, banquefr.com/compte/2, etc. et qu'il n'y a pas de contrôle d'accès, un attaquant peut accéder à tous les contenus, y compris ceux auxquels il n'a pas le droit, en changeant le numéro. C'est également possible de connaître le nombre de contenus en créant un nouveau contenu et en regardant son numéro.

Aucun rapport avec les factures donc, à part qu'il y a des numéros séquentiels.

Mais il est partout, parce que ceux qui l'utilisent invoquent "l'intérêt légitime".

Je trouve toujours ça très étonnant.

Au contraire, un juriste avec qui j'ai travaillé (mais je peux me mal me rappeler car ça fait longtemps), m'a dit qu'au contraire il ne faut pas y avoir d'opt-out pour les données collectées sur la base de l'intérêt légitime.

En effet, si on peut accepter que l'utilisateur refuse le traitement, il pourrait être argumenté qu'il n'y a pas tant d'intérêt légitime que ça.

Par exemple un intérêt légitime courant est la lutte contre la fraude. Si on veut lutter contre la création d'un nouveau compte suite à une fermeture de compte, on ne peut pas permettre aux utilisateurs de de demander la suppression des données comme l'adresse mail du premier compte.

Quand on en est à rendre une appli obligatoire, c'est qu'à priori aucune discussion n'est possible.

Evidemment que l'appli est obligatoire et qu'aucune discussion n'est possible a priori. On comprend du journal que c'est une association type club de badminton, et l'appli sert à réserver les terrains et organiser les matchs.

Comment veux-tu que l'association fonctionne correctement et que ce ne soit pas le gros bordel si certains membres décident de ne pas l'utiliser ?

Si tu es un nouveau membre tu ne peux pas te pointer en disant "votre appli c'est de la merde, c'est pas libre", alors que le bureau de l'assoce s'est fait chier à trouver une solution, qui a priori fonctionne correctement. La discussion ne devient possible que si tu respectes le travail des membres existants, et que tu proposes quelque chose qui améliore la situation, tout en prenant en charge une grande partie du travail vu que les autres membres seront sans doute réticents à changer une 2e fois de façon de fonctionner.

Ton approche pour la génération du PDF (faire du dessin sur un canvas) n'est pas bonne (exemple de fonction) : plus les documents vont être complexes, plus ça va être difficile de générer quelque chose de correctement formaté.

D'ailleurs si on génère la facture sur la démo avec les paramètres par défaut, il y a déjà des soucis de textes qui se dépassent ou se recouvrent.

Une approche beaucoup plus efficace est de générer une facture dans un format intermédiaire (typiquement HTML ou LaTeX) puis de convertir ce format en PDF.

Mon détecteur d'AI slop est à 0.

Il est peut-être en panne. Le code et le designe de la démo ne me paraissent pas vibe codés mais :

• Le site est très clairement vibe-codé ("pill" avant les h1, les textes de réassurance qui font très LLM, la taille et le "professionnalisme" de la page sans commune mesure avec le code)

• Nouveau compte

• "L'idée de ce projet ne vient pourtant pas d'une veille technologique. Elle vient d'une discussion avec un charpentier." dans le journal est plus que suspect, non seulement la tournure de phrase et le type d'exemple sont typiques d'un LLM, mais elle est aussi très générique pour une expérience personnelle.

Utiliser une application du commerce pour réserver les terrains et organiser les appariements c’est quand même assez léger sur l’échelle du n’importe quoi

Si tu veux qu'on puisse t'aider il faudrait être plus précis, à la fois sur l'historique des faits et sur l'application en question.

Parce que sans plus de précisions, pour qu'il y ait eu une issue aussi grave au différend, je ne vois que 1) les co-présidents sont très impulsifs ou ont une dent contre toi, ou 2) tu as failli à tes obligations (par exemple pas allé à des matchs où tu étais convoqué via l'application) sans chercher une solution.

Dans le premier cas je ne vois pas de solution (si ce n'est les aspects juridiques mentionnés dans l'autre commentaire). Dans le deuxième cas tu peux acheter un smartphone Android, éventuellement y installer un OS dé-googlisé, installer l'application et revenir la queue entre les jambes. Et bien sûr dernière solution, rejoindre un autre club.

Les solutions sont pas oufs, mais sans plus de détails difficile de proposer mieux / plus précis.

Il y a un moment tu dis stop. Maintenant, qu'on m'explique l'intérêt de cette licence, à part piéger des dev random …

Admettons que tu écrives une base de données libre.

L'entreprise truc créé et vend une base de données dérivée de ta base de données libre.

La licence GPL oblige l'entreprise à distribuer le code source de sa base de données sous licence GPL.

Maintenant admettons que l'entreprise truc ne mette à disposition sa base de données dérivée que sous forme de SaaS.

Avec la licence GPL tu est niqué. Avec la licence AGPL tu peux t'assurer que le code source de la base de données dérivée soit disponible.

L'objectif n'est pas de faire de l'OpenSource mais de camoufler des pratiques pire que du propriétaire, puisqu'il n'y a pas de possibilité de négocier ou de se mettre en règle et de le prouver

C'est une blague ? Le logiciel dont tu parles (iText) est disponible sous licence AGPL et également sous licence commerciale. Il est donc tout à fait possible de l'utiliser dans un logiciel propriétaire en étant en règle.

Et pourtant, je sais, j'aurais dû faire comme les anciens du monde Java: NE JAMAIS UTILISER DE DÉPENDANCE AGPL dans un projet sérieux. (c'est l'une des raisons du succès de Java en entreprise).

J'ai une mauvaise nouvelle pour toi : certains composants de Java ne sont pas open source, les utilisateurs ne font souvent pas attention à ce qu'ils installent, et Oracle est très agressif dans les audits de licence.

Pourquoi on s'offusquerait de la licence ?

Merci Jean-Marie pour ta contribution

Le côté égoïste du cooldown (j'attends que les autres rencontrent le problème)

Le problème de cet argument c'est qu'il est complètement faux. Les paquets vérolés ne sont pas détectés par les autres utilisateurs mais typiquement :

• Par les entreprises spécialisées dans l'analyse de dépendances, qui se servent de ces analyses pour faire la pub pour leurs services destinés aux entreprises

• Par les mainteneurs qui se rendent comptent que leurs jetons ont été récupérés

Evidemment que ça existe encore. Sinon comment tu fais pour créer un image OCI pour l'utiliser, par exemple, dans les technologies que tu mentionnes, avec swarm ou kubernetes ?

Alors aujourd'hui, je t'en prie, écris, toi, un journal, pour expliquer comment on code en JS/Node, ce qu'il y a de positif, de bon, de cool, là-dedans.

Par exemple le journal sous lequel tu commentes ?

Super travail, merci !

Je suis surpris de voir pas mal d'applis qui sont simplement de la documentation (par ex. plusieurs applis des APHP ou de l'INRAE), et en plus la dite documentation est séparée en plusieurs applis. J'ai du mal à comprendre l'intérêt d'avoir fait cet effort par rapport à un simple site, et aussi curieux du nombre d'utilisateurs de ces applis.

Si je comprends bien comment Future (en Java) marche, il permet d'exécuter une fonction dans un autre thread (ou plus généralement d'une façon fournie par l'exécuteur), et ensuite d'obtenir son résultat avec la méthode Future.get(), qui est bloquante.

Avec le modèle Reactor, ce n'est pas possible (ni souhaité) d'avoir une fonction bloquante (vu que ça bloquerait tous les traitements du thread unique, et, dans le cas de Future.get provoquerait un deadlock), donc il n'est pas possible d'avoir une fonction Future.get, et donc d'extraire le résultat du calcul du Future.

On serait donc obligé d'utiliser le résultat de la Future sans l'extraire, par exemple avec CompletableFuture.thenApply, ce qui, si on utilise ça partout, serait particulièrement illisible, d'où l'intérêt d'avoir un sucre syntaxique comme async/await pour gérer ça plus simplement

Franchement c'est un peu lamentable de passer du temps à écrire ce message qui n'a aucun détail précis (qui permettraient au lecteur de comprendre ce qui ne te plait pas dans le langage) plutôt qu'à mettre à jour tes connaissances.

Je pourrais répondre point par point mais je ne vois pas pourquoi je prendrais du temps alors que tu ne l'as pas fait.

Juste pour prendre ton premier point un peu précis :

Le JavaScript est un langage dramatique […] à débugger

Pour débugger un programme JavaScript, que ce soit Node.JS ou dans le navigateur, je met un point d'arrêt en cliquant dans mon éditeur ou dans les outils de développement, et quand je relance le programme, il s'y arrête.

Franchement je ne vois rien de complotiste ou d'incohérent (après je suis l'auteur, j'imagine que ça aide).

Je ne voulais pas dire qu'il est complotiste ou incohérent, mais qu'en regardant uniquement des indices rapidement visibles (la longueur et le thème, et maintenant le score négatif), des gens ont pu conclure sans lire que c'était ce type de journal

J'en conclue donc que peu importe le fond, que j'y ai passé quelques heures, il faut que je me tape des -1 de réflexe ?

Malheureusement ce n'est pas l'effort qu'on y a mis qui fait le succès de quelque chose, surtout pour un contenu sur internet où tout le monde à une surabondance de choses à lire ou à regarder.

Dans le cas de ton journal il y a pour moi deux soucis qui font que les lecteurs de DLFP ne vont pas y accorder l'attention qu'il mérite :

• Comme déjà évoqué, la référence à l'IA : il y a eu ces derniers mois de nombreux contenus de mauvaise qualité générés par IA, ce qui fait que les lecteurs ont désormais une réaction épidermique

• La longueur et le thème philosophique du journal : il y a là aussi un historique de journaux de ce type, mais avec un contenu incohérent ou complotiste, laissant presque (ou pas) penser à des problèmes psychiatriques chez leurs auteurs

Pré-scriptum : oui, j'ai fait écrire mon commentaire à un LLM (GPT-5.5)

L'utilisation du LLM dans ton journal se voit beaucoup trop. On retrouve tous les travers habituels : des tonnes de texte, des analogies à répétition, des détours dans tous les sens et une argumentation qui avance péniblement. Le résultat donne une impression de profondeur, mais quand on regarde de près il y a souvent assez peu de substance derrière.

Le plus gênant, c'est que cela fait perdre du temps au lecteur. Parce que générer trois pages de texte ne coûte quasiment rien à une IA, le texte n'est plus contraint par l'effort d'écriture. En revanche, chaque paragraphe supplémentaire doit être lu par des humains. J'ai eu plusieurs fois l'impression de devoir traverser de longues digressions pour extraire une idée qui aurait tenu en quelques lignes.

Au final, j'ai surtout l'impression que le LLM a servi à augmenter le volume du journal plutôt que sa qualité. Le texte aurait probablement gagné à être deux ou trois fois plus court et à consacrer l'espace économisé à renforcer les arguments plutôt qu'à les reformuler.

Mais encore ?

L'article est intéressant, mais je trouve que la gravité du "problème" évoqué n'est absolument pas en rapport avec la popularité de l'article.

Tout d'abord, la solution que préfère l'auteur (dernier paragraphe) sont les green threads. Ce n'est pas une meilleure solution mais un compromis différent, comme dit dans mon journal (besoin de gérer la synchronisation à la main, overhead sur chaque thread, profil de performance différent). Certes il n'y a plus le sujet du function coloring au niveau du langage, mais encore faut-il que les autres compromis conviennent.

Sur le fond, la raison principale pour laquelle le function coloring n'est pas un vrai problème, c'est que dans un programme bien architecturé, l'I/O est en haut de l'arbre des appels, et qu'au fur et à mesure qu'on rentre dedans on essaie d'avoir des fonctions pures, ou plus généralement qui peuvent facilement être testées.

D'ailleurs le function coloring n'est pas spécifique à async/await : une fonction qui prend en premier argument une connexion à la base de données, ou encore une référence à la requête en cours ne peut pas être appelée par une fonction qui n'a pas cette référence. Certes dans ce cas il y a des façons simples d'éviter le problème comme utiliser un singleton, du thread-local storage ou équivalent, mais ce n'est pas forcément une solution propre ou souhaitable.

Pour moi le seul cas où il y a un vrai problème est si l'on doit appeler une fonction async à partir d'une librairie qui ne le prévoit pas, par exemple un validateur XML qui permet de fournir un callback pour vérifier certains éléments, et on souhaite dans ce callback appeler un service web. Mais, en pratique, du moins dans l'écosystème node.js, c'est extrêmement marginal (personnellement je n'ai jamais vu le problème), et, vu que la grande majorité des librairies sont opensource il est facile de les modifier pour avoir le comportement qu'on souhaite.

Et, enfin, ce n'est pas vrai qu'il n'est pas possible d'appeler des fonctions async à partir d'une fonction sync. Ce n'est pas une bonne idée vu que ça bloque l'event loop, mais, par exemple en Node.js ça peut être fait en exécutant la fonction dans un worker thread et en attendant son résultat avec Atomics.wait.