Guillaume Smet a écrit 377 commentaires

Sauf que tu parles d'anecdotes, de plus sur des systèmes ultra spécifiques. Il y a beaucoup de gens qui utilisent Java et sont très contents des performances.

Pour des applications serveurs, le compilateur JIT de Java est assez redoutable.
Si tu veux faire des applications type CLI, tu as GraalVM de nos jours (qui fait de la compilation AOT, ce qui dans certains cas sera moins performant que de la compilation JIT car le JIT peut optimiser des choses basées sur les motifs d'exécution).

Pour prendre un exemple, mon bot GitHub en Quarkus pour le projet Quarkus (dont je compte parler un de ces jours sur ce site) démarre en 20ms compilé en natif avec GraalVM.

Et l'implémentation d'une action simple avec le framework Quarkus GitHub App que j'ai développé pour ça est en tout et pour tout :

class MyGitHubApp {

    void onOpen(@Issue.Opened GHEventPayload.Issue issuePayload) throws IOException {
        issuePayload.getIssue().comment("Hello from MyGitHubApp");
    }
}

C'est à dire qu'avec juste cela, tu auras un bot GitHub qui répond aux requêtes et ajoute un commentaire pour tout nouvel issue GitHub créé. Rien besoin d'autre mis à part un fichier de configuration pour les clés de signature. Et l'IOException est là juste à cause de l'API Java GitHub qui devrait virer cette exception dans la prochaine version majeure.

Le fait qu'on puisse mal bosser en Java ne dit rien sur le langage. Tu peux mal bosser dans tous les langages.

Bon et puis parfois, ce n'est juste pas le bon langage pour la tâche. Et c'est pas bien grave, utilise autre chose dans ce cas.

Je pense que ta vision de Java doit dater des années 90.

Accessoirement, la majorité de tes points ne sont pas liés au langage lui-même mais à ce que certaines personnes en font.

Lenteur excessive. Les langages interpretés c'était bien avant

Celle-là m'a bien fait rire.

Bref, on ne te fera pas changer d'avis mais, des fois, c'est pas mal de se poser la question de pourquoi tant de gens aiment quelque chose quand on a des idées préconçues comme ça.

Ta méthode est f05AfficherStocks(Medicament[] p_tabMeds) et tu lui passes meds[0].getStock(). Tu devrais lui passer meds.

Par ailleurs, si j'étais toi, j'utiliserais des List (une ArrayList fera très bien l'affaire ici) plutôt que des arrays, c'est un peu moins pénible à manipuler.

Je te conseille aussi d'utiliser un IDE qui te pointera ces erreurs directement.

Non, un schéma, c'est différent d'une table.

Dans PostgreSQL, tu as base > schéma > table. Par défaut tu as un schéma public dans une base mais tu peux avoir autant de schémas que tu veux.

Ca permet d'isoler complètement un ensemble de tables (et du coup tu peux avoir le même modèle n fois dans n schémas différents). Tu peux aussi définir le schéma par défaut quand tu te connectes et définir des droits spécifiques.

Bref, je te conseille d'en lire un peu plus sur la notion de schéma dans PostgreSQL.

Bonjour,

Déjà, il faut bien comprendre que tu ne peux pas avoir le beurre et l'argent du beurre i.e. isolation des données et capacité à requêter facilement sur l'ensemble. Du coup, c'est un compromis à trouver par rapport à ce qui est le plus important pour toi.

Ensuite, si tu utilises PostgreSQL, je pense qu'avoir des schémas séparés dans la même base est une bonne option dans plein de cas : tu peux gérer des permissions distinctes et bien isoler les données et tu peux quand même requêter sur plusieurs schémas (même si ce sera toujours moins pratique que tout avoir dans les mêmes tables). Requêter sur plusieurs bases est possible mais plus pénible.

Tu peux aussi restaurer un schéma spécifique, ce qui peut-être pratique s'il y a une grosse boulette sur un tenant qui n'impacte pas les autres.

Pour maintenir la cohérence d'ensemble de la traduction Weblate permet d'utiliser une mémoire de traduction qui donne une liste de correspondances entre la langue de référence et la langue cible. Des choses du genre preview -> aperçu pour éviter que quelqu'un traduise par exemple par prévisualisation.

Ah c'est chouette ça. On n'utilisait pas vraiment d'outils web à l'époque.

Ce qui est important c'est que l'utilisateur comprenne vite et bien ce qui est nommé ou expliqué. Ainsi on peut choisir de garder un terme anglais s'il est plus utilisé ou mieux compris que le terme français correspondant. C'est d'autant plus vrai pour le français qui n'est pas utilisé seulement en France.

C'est sûr mais ça ne rend pas forcément la chose plus facile car le traducteur doit savoir où s'arrêter et ça dépend pas mal du métier. D'où l'intérêt d'un lexique dont tu parlais tout à l'heure mais il faut quelqu'un pour fixer les règles au départ. Et en plus les règles vont dépendre du pays. Typiquement au Québec, ils ont tendance à vraiment vouloir une traduction pour des mots qu'on aurait peut-être plus tendance à laisser en français en France.

Je ne dis pas que c'est impossible mais ce n'est vraiment pas un sujet évident, contrairement à ce qu'on pourrait penser.

De mon expérience sur GForge (il y a longtemps) et Hibernate Validator (plus récemment mais beaucoup moins de messages à traduire), c'est très compliqué…
Et les outils facilitant une traduction partielle n'aide pas forcément à la qualité de l'ensemble.

Déjà, tu vas avoir plein de gens qui vont contribuer alors qu'ils ne maîtrisent pas forcément bien la langue parce que c'est relativement facile comme contribution. Ensuite tu auras des gens qui vont ajuster juste un message et qui vont casser la cohérence de l'ensemble (en utilisant un mot à la place de celui qui est utilisé partout ailleurs par exemple) ou une personne traduisant la moitié et une autre personne traduisant l'autre moitié sans trop tenir compte des choix faits avant.

En plus, c'est quand même super fastidieux sur les grosses applis, donc tu ne peux pas trop en demander à des contributeurs de passage.

Si tu veux vraiment t'assurer de la qualité d'une traduction :
- il faut une personne qui maîtrise bien les deux langues qui chapeaute tout et qui soit responsable de la cohérence de l'ensemble sur le long terme (et c'est pas simple à trouver !)
- il faut que cette personne maîtrise bien ton outil ou en tout cas le métier autour de ton outil parce que le contexte d'utilisation d'un message dans l'outil peut vraiment changer comment tu le traduis
- c'est un sacré boulot sur des grosses applications

Et même si tu payes des bons traducteurs à un instant t, c'est pas toujours évident de refaire des prestations au fil de l'eau pour 20 nouveaux messages.

Le mode bazar pour une traduction, ça amène à des résultats "créatifs" et c'est super difficile d'arriver à un résultat nickel. Et le mode cathédrale, ben, c'est aussi super difficile (et coûteux) de maintenir le truc sur le long terme.

Sinon, tu as la méthode qu'utilisait Liferay à ses débuts : tu files tout à Google Translate et tu termines avec "Regard et sensation" pour "Look and feel". Au moins, tu te marres bien en utilisant l'appli.

Tu as probablement vu cette dépêche qui parle d'un sujet assez proche : https://linuxfr.org/news/compter-automatiquement-les-mots-prononces-sur-les-chaines-d-information-continue ?

Le fait de faire du logiciel libre et le fait de vouloir en retirer une rémunération sont orthogonaux.

Perso, je suis un peu choqué par les commentaires au dessus genre "tu fais du libre, tu l'as voulu, c'est normal que personne ne te paie". Ben, non. Tu peux faire du libre et trouver normal que les entreprises qui utilisent ton logiciel se demandent comment participer au fait que le logiciel soit maintenu, au fait que quelqu'un leur réponde quand ils posent des questions, que quelqu'un réagisse vite s'il y a une CVE. Obligatoire non, c'est du libre, tu fais bien ce que tu veux, un peu logique, oui, quand même.

La remarque sur "t'as qu'à trouver un business model" n'est pas vraiment beaucoup plus brillante. Le modèle du service est très compliqué à monter. Perso, j'ai contribué à GForge pendant des années quand c'était à peu près la seule solution pour avoir une forge d'entreprise. Je n'ai jamais eu aucun problème pour faire financer les modifs spécifiques, jamais aucun problème même pour que certains développements spécifiques soient libres. Par contre, je facturais systématiquement 2 jours de contribution libre (c'est à dire que je faisais pendant ces 2 jours ce que je pensais important pour le projet, et à cette époque, je bossais aussi des heures dessus sur mon temps libre, comme d'autres contributeurs de l'époque, donc 2 jours, c'était vraiment pas cher payé) pour chaque installation que je faisais. Et ben, les clients tiquaient sévèrement à chaque fois. Et pourtant, c'est sur ces deux jours que je faisais des améliorations plus générales et pas liées à un truc spécifique, ce qui est fondamentalement nécessaire. On était très peu sur ce marché et ça demandait une expertise un peu relou parce que beaucoup d'infra donc ils venaient quand même. Mais le logiciel aurait été plus simple à maîtriser, ils seraient allés dans la SSII d'en face qui aurait été moins chère parce qu'ils ne contribuent pas.
Arriver à financer du vrai développement de fond (maintenance, refactoring, sécurité, facilité d'installation…) sur du service, c'est très compliqué quand la SSII d'en face va dumper les prix journées et faire un truc à l'arrache.

Pour l'anecdote, j'ai arrêté de contribuer quand il est devenu clair qu'il fallait refondre profondément le logiciel et qu'on ne trouvait aucun moyen de financement. Et la goutte d'eau a été quand un grand groupe européen (mais genre vraiment gros) que je ne citerai pas m'a contacté personnellement pour que je prenne l'engagement de relire les patches qu'ils allaient m'envoyer rapidement, de leur faire des retours et de les intégrer dans GForge… gratuitement parce que bon ils payaient déjà une SSII pour les écrire alors je comprenais bien qu'ils ne pouvaient pas en payer deux…

Et après, il y a tous les logiciels où le service ne fait pas vraiment de sens parce qu'utilisation évidente et pas vraiment de fonctionnalités à ajouter. Ca n'empêche qu'il faut quand même maintenir le logiciel sur le long terme et que ça demande du temps.

Et contribuer par la contribution (oui, bon, vous m'avez compris), c'est une fausse impression. Parce que pour chaque contribution, on génère du travail chez les mainteneurs. Et à un moment, il faut bien que le mainteneur (qui a franchement le boulot le plus chiant) arrive à faire son beurre d'une manière ou d'une autre.

Pour finir, par contre, il est loin d'être simple pour une entreprise de sponsoriser des logiciels libres. C'est un peu plus facile pour tout ce qui est sous l'égide d'une fondation (mais je ne suis pas sûr que l'argent aille vraiment aux développeurs individuels pour le quotidien) mais pour des logiciels développés par quelqu'un sans société derrière, c'est assez compliqué.

Ah et en fait, j'ai pas fini parce que le modèle du support est assez marrant aussi. Je serais assez curieux de voir la liste des contributions fondamentales qui ont été menées grâce aux grands contrats de support de l'état et des grosses entreprises récupérées par les grosses SSII/SSLL du marché pour faire du support sur une liste de logiciels libres à la Prévert auquel pour la majorité ils ne contribueront jamais concrètement à maintenir le truc sur le long terme.

Y'a pt'et une petite différence entre laisser les candidats parler/leur couper la parole tout le temps, leur poser des question gentilles/ des questions qui fâches, les laisser raconter des conneries, rectifier les chiffres.

Ah mais on est d'accord. Sauf que sitôt que tu corriges un chiffre, que tu poses une question pour creuser, le candidat s'offusque et va dire aux journalistes de vérifier ses chiffres, que c'est n'importe quoi, qu'on le martyrise, etc (ce qui est d'ailleurs aussi possible car plein de journalistes baclent leur boulot ou veulent juste faire de la polémique facile). Et bam, sujet suivant. Toutes les réactions sont exagérées, c'est devenu un cirque.

Bref, autant les médias, que les politiques, que les gens qui les regardent sont responsables de cette débacle. On a fait de la politique un cirque. Et c'est exactement pareil à l'assemblée. Sérieux, jamais dans une entreprise, tu laisserais ce genre de comportement de cour de récré avoir lieu au quotidien. Mais on ne va jamais parler du député sérieux, bosseur et discret.

On commence à avoir des articles de décryptage des débats avec vérification des chiffres à froid etc. mais c'est déjà trop tard, le mal est fait, la majorité des gens ne liront pas les articles.

Y'a aussi que la complaisance, elle dépend du candidat, par exemple NDA ou Philippe Devillier ont peu de complaisance de la part des média, là où les candidats issus des grands partis seront mieux accueillis.

Alors ça c'est facile à expliquer. Tu t'en tapes s'ils reviennent ou pas. Alors que s'il te manque un gros candidat pour un débat, ton débat est par terre.
Perso, ce qui m'irrite le plus c'est la condescendance vis à vis des "petits" candidats qui est assez insupportable. Ce n'est pas parce que tu es "petit" que tu n'apportes pas quelque chose d'important au débat démocratique.
Et accessoirement, ce n'est pas parce que tu es "petit" que tu ne peux pas être élu.

Je pense aussi qu'il y a une vraie volonté de ne pas déstabiliser les "gros" candidats pour éviter les mouvements de foule vers d'autres candidats.

D'ailleurs l'état d'urgence n'a pas permis d'empêcher un seul attentat, et ce pendant plus deux ans; on peu arguer de son utilité sur les 2 mois qui on suivit les attentats pour chopper les terroriste, et à l'époque si j'avais été député j'aurais probablement voté pour, ou me serait abstenu, mais avec le recul que j'ai aujourd'hui, je voterai contre, car l'état n'a pas rendu l'état de droit en temps et en heure, et qu'il l'a utilisé à des fins politique.

Le fait est que tu ne peux pas savoir en fait, c'est ce que je disais.
On n'a absolument aucune information sur les possibles attentats évités. En admettant qu'il n'y ait plus d'attentats du tout, il y a plein d'options :
- soit des gens essayent effectivement d'organiser des attentats et l'état d'urgence aide à empêcher l'organisation d'une manière ou d'une autre
- soit des gens essayent effectivement d'organiser des attentats et les moyens normaux sans état d'urgence auraient été aussi efficaces
- soit personne n'essaie d'organiser d'attentats, et l'état d'urgence est inutile

En l'occurrence, les citoyens lambdas n'ont aucune info pour savoir quelle option est la bonne vu que ce genre d'infos n'est pas accessible. Et le fait qu'il soit utilisé à d'autres fins moins glorieuses ne change rien à cet état de fait.

Encore une fois, je ne dis pas qu'il est utile. Je dis juste qu'on n'en a aucune idée.

Dans une démocratie qui fonctionne, tu fais confiance aux gens qui ont les bonnes informations pour prendre les bonnes décisions. Et je n'ai pas dit qu'on était dans une démocratie qui fonctionne :).

Si les citoyens ont une part de responsabilité, préférer le confort que l'inconfort, la majorité de la population continue de s'informer par la boite à image ou pour certains la radio.

Je ne sais pas si c'est encore le cas de la majorité. Le bouche à oreille, les réseaux sociaux et compagnie jouent un grand rôle dans l'information des gens aujourd'hui. En particulier, sur l'information foireuse et polémique.

Prenons un exemple sorti du chapeau : prenons un candidat sérieux et intelligent qui fait une très bonne prestation sérieuse à un débat mais une petite phrase sortie de son contexte prête à polémique. Qu'est ce que les gens vont retenir ? Et de quoi la majorité des gens vont être au courant ?

Je suis absolument contre la déresponsabilisation des gens en mettant ça sur le compte d'un système. En tant que personne, tu fais tes choix et tu es responsable de tes choix.
Les médias balancent aux gens exactement ce qu'ils ont envie de voir/entendre pour faire du chiffre. Il suffit de voir les audiences d'Hanouna, qui influence clairement la pensée de tout un tas de gens. Et le plus drôle, c'est qu'ils ont l'impression qu'il est contre le fameux système.
S'il n'avait pas eu des audiences hallucinantes, jamais on ne lui aurait laissé les coudées aussi franches et autant de temps d'antenne.

Bref, je pense qu'on est assez d'accord sur le constat avec une petite différence de point de vue sur les responsabilités :).

Les raisons ne changent pas grand chose au constat qu'il devient extrêmement difficile d'avoir un fonctionnement démocratique en France (et ailleurs, cf le "si mon candidat n'est pas élu, c'est que l'élection est truquée" aux US et les débordements qui ont fait suite).

Quant aux mensonges, pour moi, la responsabilité est partagée. Les citoyens ont tendance à voter pour celles et ceux qui leur disent ce qu'ils veulent entendre. Les médias sont complaisants, et s'ils ne le sont pas, de toute manière, les candidats se plaignent qu'on veut les faire taire et qu'on les martyrise et leurs partisans vont dans ce sens aussi. Résultat des courses : la situation actuelle.

Quand les gens prendront un peu de recul et éviteront de réagir à chaud n'importe comment, ce sera déjà mieux. Quand ils comprendront qu'on peut ne pas être d'accord et avoir raison tous les deux, aussi. Les réseaux sociaux n'aident pas car ils enferment les gens dans des bulles où tout le monde pense pareil. Evidemment, ça existait déjà avant, tu avais tendance à te rapprocher des gens qui pensaient comme toi mais là tu as une chambre d'écho énorme et continuelle.

coucou l'état d'urgence pour menace terroriste

Bon exemple de ce qu'il est quasi impossible de gérer aujourd'hui. Admettons que tu l'enlèves, admettons qu'il y ait un attentat (je ne fais pas de lien de cause à effet, juste que ça nous tombe dessus de temps en temps), tout le monde tombera sur celui qui a enlevé l'état d'urgence et le tiendra pour responsable des morts. Donc, tu fais quoi ? Ben, tu le laisses en place. Accessoirement, on est loin d'avoir les infos pour savoir s'il est utile. Le fait qu'il n'y ait pas d'attentats peut autant être un signe de son utilité que de son inutilité.

C'est assez proche de l'exemple que prenait Misc au dessus à propos de Roselyne Bachelot qui s'est fait taper dessus pour avoir été prudente puis encenser maintenant parce qu'elle, au moins, avait été prudente.

Bref, les dérives actuelles et la difficulté à avoir un fonctionnement démocratique sont de la responsabilité de tout le monde à mon sens, pas seulement de la classe politique et des médias.

Les gens râlent point. C'aurait été fait différemment, c'aurait été pareil. Après, je me garderais bien de donner mon avis sur le sujet. Je dis juste que si tu imposes des restrictions aux gens, peu importe la manière, ils râleront. Et même si c'est fait avec un vote, même en respectant les principes de la République. Suffit de voir le nombre de gens qui disent qu'un président est illégitime parce qu'il n'a pas eu plus de 50% des suffrages obtenus au premier tour.

Et, les référendums, on a vu ce que ça a donné avec le Brexit. Prendre des décisions impopulaires avec un référendum en France, bon courage… Et ce n'est pas parce qu'une décision est impopulaire qu'elle est mauvaise. Encore une fois, je parle en général, pas forcément dans ce cas particulier où j'évite joyeusement de donner mon avis. Un référendum, je trouve que c'est de moins en moins une solution, en particulier avec la manière dont les gens s'informent et se désinforment de nos jours. C'est con mais c'est comme ça.

Et admettons même que tu fasses un référendum, les gens qui ont voté pour la solution qui n'a pas la majorité vont quand même se plaindre, dire que c'était n'importe quoi, que les gens étaient mal informés ou n'importe quelles autres raisons qui justifieront le fait qu'ils ne se sentent pas liés par ce référendum.

Oui, de toute manière, dans les situations relous, il n'y a jamais de décisions qui contenteront les gens. Après, je pense qu'un des soucis de la société actuelle est que tout le monde a un mégaphone à disposition, ce qui rend les choses difficilement gérables.

Le plus drôle, c'est que la même décision genre celle de Bachelot va être vu comme bonne au départ parce que prudente puis mauvaise parce que le H1N1 a fait plop donc gâchis d'argent, puis rebonne des années plus tard "ah ben ça au moins, Roselyne Bachelot à l'époque, elle avait fait les choses bien, c'est pas comme le gouvernement de maintenant".

Je pense qu'on peut difficilement lutter contre malheureusement. Mais, perso, je trouve un peu fatiguant cette manie de décider de la validité d'une décision à partir de ce qui en ressort. La validité d'une décision, c'est par rapport aux données d'entrée que tu la juges. Après, c'est juste une histoire de bol ou de pas de bol.

Et ouais, je pense qu'on ne demande pas assez l'avis des peluches. La mienne ne parle vraiment que quand elle a quelque chose à dire. La sagesse.

J'ai jeté un oeil et effectivement leur nombre de cas graves est très bizarre comparé aux autres pays.

Tout le monde n'a peut-être pas la même définition de cas graves, ou alors vu qu'il y avait beaucoup plus de cas avant, les gens avec des formes graves ont été plus lissés ? Ou alors c'est la marmite :).

Nan, j'ai des collègues très actifs sur Twitter au UK et étant tout ce qu'il y a de plus inactif et ne suivant que très peu de monde, mon fil est rempli d'actus UK. Donc je suis vaguement ce qui se passe (par contre avec un filtre très très orienté politiquement).

Dans ma théorie extrêmement scientifique validé par mon Totoro en peluche, le pic d'avril 2021 en France correspond à celui de janvier au UK mais il a juste mis plus longtemps à se réveiller (l'hibernation tout ça).

Alors tu me diras que ça n'explique pas celui de novembre 2020 mais dans ces cas-là, on a qu'à dire que c'est l'exception qui confirme la règle.

Ah ah, tu fais moins le malin maintenant avec tes courbes, hein ? :)

Tout cela pour dire que ce n'était pas très sérieux tout ça mais globalement chaque fois que je vois plein d'articles sur le COVID au UK (j'ai des collègues là-bas) sur mon fil Twitter, ça manque jamais de devenir relou après. Tu me diras vu que c'est relou super régulièrement, ça ne pourrait être qu'une coïncidence et tu aurais parfaitement raison. Mais mon Totoro en peluche et moi sommes très fiers de notre théorie alors on va rester là-dessus, même si c'est bien bidon.

Ce qui est assez amusant, c'est qu'à chaque pic au Royaume-Uni, on a :
- côté R-U, plein de gens qui disent : "on fait n'importe quoi, regardez la France, ils ont beaucoup moins de cas que nous"
- côté France, plein de gens qui disent : "ah ah, regardez le R-U, c'est n'importe quoi"

Et 3 semaines après, on a exactement le même pic en France.

Globalement, suffit de suivre ce qu'il se passe au R-U pour savoir ce qu'il va nous arriver dans 3 semaines, ça s'est vérifié pour à peu près tous les pics.

Et du coup, si on suit un peu, on a 3 semaines pépouzes pour se préparer et faire des cabanes en papier toilette dans son appartement.

Oui, tout est à jeter dans cette série. Le pire étant que c'est chiant à mourir. Ca pourrait être éloigné et chouette mais c'est juste très très raté.

Par contre, sur Apple TV, je conseille la très bonne série Mr. Corman. C'est beaucoup moins polissé que le reste de l'offre et j'ai trouvé ça bien chouette.

C'est fou comme on a du mal à avoir une discussion posée ici. Tu sais, on peut discuter sans chercher la petite bête dans ce que l'autre écrit et lui donner le bénéfice du doute quant à sa cohérence. On peut aussi ne pas être d'accord et avoir tous les deux raisons car des enjeux différents.

Pour expliquer ce que je disais :

Mais pour chaque composant utilisé, il faut être sûr du code existant, sûr de l'équipe et sûr du futur du composant et que l'équipe ne sera jamais gangrénée

Cette partie-là désigne un absolu. Si tu veux être sûr de ton composant, il faut que toute la chaîne soit sure. C'est infaisable dans les faits d'avoir la capacité à vérifier chaque maillon de la chaîne à chaque instant. Mais il est important de le savoir et d'en être conscient.
Du coup, il est de la responsabilité de chaque maillon à son échelle de faire du mieux qu'il peut et d'éviter les comportements les plus dangereux. Parce que tout le reste de la chaîne va en payer le prix.

D'où le :

Ca veut juste dire que certaines pratiques ne sont pas souhaitables et qu'il faut qu'on fasse un peu plus attention à ce qu'on fait en tant que développeurs de composants réutilisés.

Et par rapport à ce que tu dis toi :

Quant au github actions, tu avais déjà ça avec des plug-ins maven ou de ton IDE (vim et emacs inclus).

Il y a une petite nuance et elle est importante, je l'avais précisé plus haut : tout est plus facile de nos jours, ce qui rend les comportements dangereux moins visibles. Entre utiliser un plugin Maven qui a dû être déployé sur Maven Central (et donc quand même avoir quelques petits checks au cours de la démarche, même si pas idéal) et juste pointer vers un repo GitHub arbitraire, il y a un monde. Tu pourras me dire qu'on pouvait ajouter un repo Maven externe. Sûr mais c'était moins fluide et j'ai l'impression que plus de gens se rendaient compte qu'il fallait faire attention dans ce cas. Ca ne m'empêchait pas de le faire parfois mais je mesurais quand même ce que ça m'apportait par rapport au risque.

Mon point c'est que quelque chose de dangereux est devenu super fluide, naturel, sans aucune vérification et sans aucune prise de recul de la part des développeurs. Et je m'en rends bien compte car j'ai le plus grand mal du monde à convaincre des ingénieurs par ailleurs brillants que c'est un souci d'envoyer sa passphrase à du code externe (et mouvant vu que pointant sur un tag mouvant genre v2 pour suivre toutes les évolutions du dit repo). Et oui, le maven-gpg-plugin, on lui envoie aussi la passphrase. Mais c'est du Apache et leur mode de fonctionnement est très sécurisant vis à vis de la malveillance organisée. Donc c'est un risque que je suis prêt à accepter.

Bref, perso, je vais m'arrêter là parce que ça ne m'intéresse pas trop d'avoir des conversations avec gens qui cherchent la petite bête plutôt que d'essayer de comprendre le raisonnement de l'autre (ce qui n'empêche pas de ne pas être d'accord par ailleurs).

Je comprends très bien ta position mais je pense que les choses sont beaucoup plus nuancées et que généraliser des pratiques dangereuses (et inutiles dans certains cas, cf mon exemple) en se disant qu'il y a bien quelqu'un qui trouvera la faille un jour, ça ne me semble pas la meilleure manière de faire les choses et qu'avoir un comportement plus responsable et conscient des dangers à chaque étage est souhaitable. Ce qui n'empêche pas de prendre des risques quand ça en vaut la chandelle mais au moins on en est conscient et ça change tout.

Ca n'empêchera pas les boulettes et c'est la vie. Mais franchement, évitons les risques inutiles.

Oui, pour suivre un peu cela, j'ai vu de tout. La régénération est effectivement un bon argument, un ami qui vient de passer à une voiture électrique me disait qu'il ne freinait quasiment plus en ville et avait une conduite beaucoup plus douce.

Par contre, des ahuris qui se vantent des performances de leur Tesla et comment les autres voitures électriques sont nazes parce qu'elles ne font pas le 0 à 100 en moins de 4 secondes, j'en vois un sacré paquet sur les espaces de discussion.

Après, le bilan global de la voiture électrique, on le connaîtra quand on aura industrialisé massivement le recyclage des batteries. Jusque là, c'est très difficile d'avoir une vision globale.

Franchement, si on commence à faire des voitures de tous les jours qui accélèrent aussi forts, il ne faut pas trop s'étonner.

Que ce soit un problème technique ou une erreur humaine (genre appuyer sur l'accélérateur au lieu du frein) - je mets de côté la volonté de faire le kéké vu que le gars avait l'air de faire une sortie pépère en famille mais on verra bien ce que dit l'enquête -, une Tesla Model 3 grande autonomie (ce qui ne paraît pas déconnant pour un taxi) accélère de 0 à 100km/h en 4.4 secondes. Et c'est 3.3 secondes pour le modèle Performance qui est juste 4000 euros plus cher. Et c'est en partant de l'arrêt donc si tu roulais à 30 ou 50, ça donne du beaucoup plus que 100 en quelques secondes.

A cela ajoute le fait que la voiture est très lourde en raison du poids des batteries donc bonjour l'énergie cinétique du bouzin.

Après, on ne peut pas dire qu'il y ait eu des tonnes d'accidents et on verra bien ce que dit l'enquête mais si le gars était effectivement en mode pépère, que ce soit un problème technique ou une mauvaise manipulation, ça ne me fait pas rêver des masses et je me dis qu'on gagnerait à être un peu plus mesuré sur les accélérations des voitures électriques. Le fait qu'on puisse avoir des performances telles facilement ne dit pas qu'on doive.

Que tout ne soit pas parfait je suis d'accord. Affirmer que rien est fait me semble verser dans l'émotion du moment.

Euh non, je ne suis pas dans l'émotion du moment, je suis passé plutôt entre les gouttes pour Log4Shell : on utilise JBoss Logging donc ça ne m'a pas vraiment impacté. On a fait des releases parce qu'on utilise l'API pour la brancher dans JBoss Logging (et donc pas l'implémentation où est la faille) et qu'on ne voulait pas se faire flagger en faux positif par les outils de scan pas trop finauds.

Et mon raisonnement n'est pas lié à cela, ça fait 2 ans que je vois les dérives que je souligne. Comme je le disais précédemment, les projets Apache ne sont pas vraiment impactés par ce problème particulier. Ils ont une gouvernance et une infra assez sécurisées globalement.

Prends un peu de recul par rapport aux exemples que je donnais sur GitHub Actions. Ils sont réels et symptomatiques de comment les choses sont faites de nos jours. Comme je le disais, ça simplifie la vie. Après, dans beaucoup de cas, les gens ne se rendent pas compte qu'ils donnent le droit de commit à du code tierce dans leurs repositories. Et qu'à partir de ce moment là, il est super facile d'injecter du code et que la probabilité de s'en rendre compte si c'est bien fait avant que ça impacte des utilisateurs est proche de 0.

Etre conscient du problème, c'est déjà un pas dans la bonne direction. Et ça ne veut pas dire qu'il faut jeter le logiciel libre avec l'eau du bain (sinon je me retrouverais au chômage et ça m'arrangerait moyen). Ca veut juste dire que certaines pratiques ne sont pas souhaitables et qu'il faut qu'on fasse un peu plus attention à ce qu'on fait en tant que développeurs de composants réutilisés.

Après, des boulettes, il y en aura toujours et tout le monde en fera. Mais ce n'est pas de cela que je parle.

Tu as toujours et tu aura toujours des gens qui font n'importe quoi. C'est pas lié à l'informatique ni à aujourd'hui.

Je ne pense pas que ce soit une bonne raison de ne pas se poser de questions sur les pratiques d'aujourd'hui et sur comment faire en sorte d'améliorer la résilience de l'écosystème en général. Certaines pratiques d'aujourd'hui sont nouvelles et extrêmement dangereuses. Perso, je préfère en être conscient et faire attention sur mes projets.

Après, chacun fait bien comme il veut :).

Encore une fois, j'ai bien précisé que je n'avais pas spécialement de solution au problème. Je n'appelle rien de mes voeux, je pointe juste un souci qui existe et que les gens minimisent, volontairement ou non.

Exemple réel vu dans la vraie vie et contre lequel j'essaie de me battre : utiliser une GitHub Action d'un repo tierce pour mettre en place la configuration GPG en lui passant la clé et la passphrase. Et ce n'est pas un exemple inventé.
Autre exemple : des applications tierces qui facilitent le développement à qui tu donnes le droit de commit sur ton repository.

Je n'appelle pas à la construction d'une cathédrale, j'appelle juste les gens à un peu de prudence et à se rendre compte de ce qu'il se passe. Certaines pratiques sont dangereuses et c'est plutôt une bonne idée de s'en rendre compte. Après, chacun décidera s'il veut ajuster son comportement ou pas. Parfois, c'est une bonne idée de se priver d'un peu de confort pour éviter de se prendre un mur plus tard.

Le jour où quelqu'un ciblera un framework largement utilisé en injectant du code pour envoyer quelque part les comptes et les mots de passe, j'ai du mal à voir en quoi ta CI et des bugs bounties vont aider. On s'en rendra compte à un moment mais bonjour les dégâts.

Accepter qu'il y ait un risque ne veut pas dire courir comme un poulet sans tête en espérant ne pas taper un mur. Si chacun sur son projet est un peu plus conscient des enjeux, ça améliore de beaucoup la résilience de l'ensemble.

Après heartbleed il y a des choses qui ont était faites de manière plus général (il y a FOSSA dont je parlais plus haut, mais la linux fondation aussi avait fais des choses).

C'est l'arbre qui cache la forêt franchement. C'est bien, c'est sûr mais ciblé sur quelques composants.

Les composants qui terminent dans des tonnes d'applications, il y en a des milliers. Et beaucoup d'entre eux sont maintenus par des toutes petites équipes en mode arrache. Et il en suffit d'un.

Log4j 2 est un exemple intéressant car c'est un projet Apache, qui a des règles plutôt strictes de revue, de votes, d'intégration dans les équipes… Donc globalement un projet sain et plutôt sécurisant. Et la faille est due à de la maladresse, pas de la malveillance.

Mais pour chaque composant utilisé, il faut être sûr du code existant, sûr de l'équipe et sûr du futur du composant et que l'équipe ne sera jamais gangrénée (on a vu quelques attaques côté npm, où quelqu'un qui paraissait de bonne volonté a repris la maintenance d'un composant largement utilisé pour finalement y inclure une faille volontairement bien après), d'autant qu'on met de plus en plus les composants à jour automatiquement (Dependabot, Renovate).

Note que je n'ai pas de solution miracle. Je pointe juste un problème systémique qui va avec la réutilisation massive de composants et aussi leurs multiplications. Je pense qu'au début de l'Open Source, c'était plus compliqué de mettre en place ce genre de vecteur parce que rien que mettre en place ton infra de développement, release, te faire connaître, ça demandait du temps et un sacré effort. C'est beaucoup plus facile maintenant. Ca a de très bons côtés mais aussi des composantes qui demandent de la prudence.

Les GitHub Actions sont un excellent exemple : GitHub fournit très très peu de GitHub Actions standards et facilite la mise en place d'un écosystème d'actions. Et ça fleurit dans tous les sens avec plein de gens qui réutilisent des actions déjà faites sans les regarder car très pratique. Au niveau de ton repository, tu pointes vers un repo externe généralement vers une version glissante (donc le code de l'action peut évoluer dans le temps) et tu utilises cette action pour builder/releaser. Il est super facile d'utiliser la dite action pour injecter du code, par exemple dans un workflow de release pour que ce soit discret (tu verrais facilement une manipulation de la branche main mais pour un tag c'est hyper discret).

L'Open Source repose beaucoup sur le modèle scientifiquement appelé "modèle Bisounours" où le monde entier est gentil et essaie de faire avancer tout le monde. Jusqu'à présent, ça marche plutôt bien. Mais c'est super super fragile si on commence à introduire des gens mal intentionnés qui ont du temps dans le bazar. Espérons qu'ils restent occupés à miner des bitcoins :)

Personnellement, je suis plutôt surpris qu'il y ait si peu d'attaques de ce genre. Pour l'instant, la majorité de celles qu'on connaît ont touché l'écosystème Javascript.

3- log4j est maintenu par 4 honorable personnes contributrices

Ce qui est plutôt beaucoup pour ce genre de bibliothèques très ciblées. Des tonnes de bibliothèques beaucoup plus grosses sont maintenues par quelques personnes sur leur temps libre. Le développeur principal de Jackson (bibliothèque JSON et bien plus quasi omniprésente dans le monde Java) par exemple travaille dessus sur son temps libre. C'est le cas de bien d'autres projets Open Source.

Et même quand ce n'est pas sur le temps libre, il y a souvent très peu de contributeurs et beaucoup de choses à faire.

Ensuite, peu de développeurs sont sensibilisés à la sécurité. Et même dans ce cas, quand tu vois arriver une pull request avec un truc qui peut être pratique pour les gens, tu ne prends pas toujours le recul nécessaire pour te rendre compte des conséquences. Bien souvent les problèmes de sécurité sont amenés comme ça : une fonctionnalité qui a l'air pratique alors pourquoi pas… et boum deux ans après quelqu'un se rend compte qu'il y a une faille évidente.

Maven en question ?

Ben non, justement. Maven a tout un tas de mécanismes pour corriger ce problème très simplement.

Beaucoup d'entreprises ont des proxies Maven que tous les builds utilisent pour récupérer les dépendances : elles peuvent bannir les anciennes versions directement sur le proxy.
Je pense aussi que beaucoup d'entreprises ont un pom parent et il est facile via une directive dependencyManagement de forcer la version de log4j - alors ce ne sera pas exactement forcé car si un projet la déclare explicitement, la version explicite prend le pas, mais ça enlève au moins toute la partie "une vieille dépendance dépend d'une vieille version de ce truc". Mais pour ça, tu peux utiliser l'enforcer plugin pour bannir des dépendances.
Il y a aussi tout un tas de gens qui ont développé des agents pour réécrire le code à la volée.

Log4j 2 est loin d'être la pire dépendance pour ce genre de problèmes car l'API est assez récente et assez stable donc la mise à jour très facile. Ca aurait pu être bien pire (genre nécessiter des changements d'API dans tous les sens pour que des vieux trucs non maintenus puissent encore fonctionner).

Un point qui me chagrine est que chaque fois qu'il y a une faille, on dirige plein d'argent et plein de recherche sur le projet qui a posé souci et on perd de vue que c'est un problème général. Tous les jours, on utilise du code Open Source dont on a absolument aucune idée du contenu (le problème est le même pour le code proprio mais on l'utilise moins facilement). On espère que les gens qui le développent savent ce qu'ils font et sont sérieux et honnêtes. Ben pour l'instant, on a eu globalement du bol. Est-ce que ça va durer ?

Et j'attends avec une impatience toute relative la première GitHub Action non officielle utilisée largement qui sera reprise par un mainteneur peu scrupuleux et qui injectera du code un peu partout dans tous les repositories qui l'utilisent. Ca va être extrêmement sympathique.