Par ici, en zone urbaine, on a encore une poignée de « pistes qui sont juste une bande sur le côté de la chaussée ». C’est là où je me fais le plus frôler par les automobilistes, qui semblent penser que si tu es sur ta petite bande super étroite, ils n’ont plus à respecter le mètre de distance de sécurité…
C'est encore horrible par rapport à d'autre langage (cf le nouveau record).
Heu… tu est sérieux là ? Le seul truc de « verbeux » dans un record, c’est les accolades à la fin dont on se demande un peu ce qu’elles font là :
recordPoint(intx,inty){}
On ne peut pas vraiment dire que ça rends le truc illisible…
Tout ce qui concerne spring boot, la gestion d'erreur complexe à comprendre, le fait que cela ne soit plus programmatique.
La gestion d’erreurs (en particulier les checked exceptions) est connu comme l’une des erreurs de conception du langage, entre autres par certains concepteurs du langage. Je ne comprends pas ce que tu veux dire par « Tout ce qui concerne spring boot, » et « le fait que cela ne soit plus programmatique. ».
Cela implique beaucoup de lenteurs (les cpu n'aiment pas les indirections mémoires) et beaucoup de consommation mémoire par rapport à une structure identique en C++, par exemple.
La consommation mémoire, pourquoi pas (et encore, le gros de la consommation mémoire en Java, c’est surtout des gens qui ne savent pas s’en servir et qui font des fuites mémoires partout, et qui laissent les paramètres à des valeurs démesurément hautes). Les performances… Java peut monter franchement haut en performances, notamment pour un langage non compilé en natif.
Je vois du vrai et de l’obsolète dans ce que tu écris :
Java est très verbeux, donc plus difficile à lire.
Plutôt faux depuis Java 8. On est très loin de la verbosité de Java jusqu’à 1.4 inclus.
Il n'est pas assez paramétrique ce qui oblige à jouer avec des @…, voir des bouts de définition en XML à coté du code, ce qui implique lourdeur, et lenteur.
Sur un projet moderne, ça fait des années que je n’ai plus eu à configurer quoi que ce soit en XML à côté du code en Java. Quant à la lourdeur et la lenteur incluses parce que « pas assez paramétrique », je suis réellement curieux d’avoir un exemple de ce que tu entends par là (c’est une vraie question, pas un troll).
Une appli web qui ne fait pas grand chose : 500Mo d'artefact de gitlab…
Ha ? Tu utilises quoi comme framework ? J’ai un projet perso avec Spring Boot + Kotlin + connexion à la BDD + génération de pages en HTML avec Thymeleaf, je râlais parce que le JAR exécutable (et unique fichier produit) était passé de 49 à 65 Mo en passant à la dernière version de Spring Boot. C’est objectivement gros, surtout quand Quarkus peut produire des binaires natifs beaucoup plus petits (mais sur des piles moins grosses), mais un ordre de grandeur sous ce que tu donnes.
Le type 'null' est toujours là. Les types de base ne sont pas des objets.
Tout ça, OK (et à mon sens le null est peut-être le plus gros problème de Java). Il y avait un projet pour se débarasser des types de base, mais ça fait longtemps que je n’en ai plus entendu parler.
Il n'y a pas de notion de layout mémoire, tout objet est "boxé" ce qui implique une grosse quantité de pointeur de partout.
Et du coup ça implique quoi comme problème, vu que tu ne manipules jamais de pointeur en Java ?
Le modèle "multi-thread" est pas top, ce n'est ni Go, ni Rust.
C’est assez vrai, mais Java date de 1996, Go de 2009, Rust de 2010. Les API récentes ont aussi beaucoup amélioré l’utilisation des threads, et on trouve des API réactives tout à fait convaincantes et performantes depuis peu.
Les licences entre openjdk et jdk d'Oracle, ne sont pas claire.
C’est en effet un problème, de même que les incompatiblités entre les différents fournisseurs de JVM/JDK (on les rencontre surtout pour les modes graphiques).
Et retrouver aujourd'hui, une jvm 8 est compliqué.
Les Pays-Bas sont beaucoup plus denses (416 habitants/km² contre 107 pour la France et 31 pour le Gers) ; à la campagne on a besoin de petites routes « roulantes » (i.e. limitées à beaucoup plus que 30 km/h)
Les Pays-Bas sont beaucoup plus plats, construire une route y coute moins cher qu’en France.
Soyons clairs : j’adorerais que l’on puisse rouler partout en vélo en toute sécurité, y compris en rase campagne. Mais en ce qui concerne la France, les contraintes géographiques font que sécuriser des pistes cyclables (je dis bien « sécuriser », donc plus que peindre une bande blanche sur le bas-côté) sur l’ensemble du territoire couterait une fortune. Et ça n’est pas des exemples non applicables et des généralités du type « Quand on veut, on peut » déconnectées de toute réalité qui prouvent le contraire, hélas.
La question de la sécurisation des routes de campagne (pour les cyclistes mais pas que : beaucoup sont dangereuses pour tous les usagers) est un vrai problème qui n’a pas de solution triviale que l’on pourrait se contenter de copier/coller depuis l’étranger. Même des aménagements du type « Chaucidou » nécessitent plus de largeur et d’entretien que beaucoup de routes de campagnes, et ça n’est même pas garanti que la « sécurité » supplémentaire de ce genre d’aménagement aurait aidé dans le cas de Zezinho (l’article montre le type de route dont on parle ici).
Y’a eu pas mal d’efforts en ce sens, mais la pratique habituelle ça reste quand même d’avoir une JVM avec toutes ses API, ce qui est effectivement souvent lourd pour pas grand-chose.
C'est aussi un peu comme ça qu'a était pense groovy avec beaucoup plus d'ambition en terme de nouveauté et un énorme intérêt pour être vraiment interfaçable avec java
C’est tout l’intérêt de Kotlin : son principe de base, c’est d’abord et avant tout d’être pratique et agréable à utiliser en leur permettant de se concentrer sur ce qui est important dans le code, pas sur des détails type boilerplate (« A modern programming language that makes developers happier. » d’après eux). Ça fait hurler les puristes des langages et les chercheurs, mais à l’usage dans l’industrie c’est infiniment plus agréable à utiliser que, par exemple, Scala qui lui a une conception orientée par la théorie.
La popularité de Groovy par rapport à Kotlin, je la vois à la fois par rapport à mon expérience personnelle et par rapport aux tendances de recherche sur Google.
Si tu as des vrais arguments contre Java (des qui existent encore en 2020, pas des qui datent de Java 1.4 et de plus de 20 ans) et pas des insultes, je serais curieux de les lire.
Idem pour toute personne qui plusseoierait le message de Maxzor.
Kotlin est le langage qui monte le plus dans les langages alternatifs qui tournent sur la JVM. Le fait qu’il soit poussé comme langage principal sur Android aide beaucoup.
C’est aussi celui qui ressemble le plus à Java (il a été pensé en gros comme « Java en mieux, avec des idées tirées de Scala, mais en plus pragmatique et plus efficace »).
Groovy s’est rapidement fait dépasser en popularité par Kotlin (même si Gradle l’utilise (même si on peut scipter Gradle avec Kotlin))
Scala, c’est plus difficile à savoir : j’ai l’impression qu’il est très utilisé dans certains milieux, mais a du mal à en sortir. Je n’ai jamais vu de vague de « OK maintenant on va utiliser Scala au lieu de Java », alors que c’est assez fréquent avec Kotlin, notamment parce que Scala est plus difficile à prendre en main (et a longtemps été lentissime à compiler).
Ceylon n’a jamais percé.
Et ça n’est pas une question d’implémentation mais clairement de fonctionnalités : en terme de fonctionnalités, Java rattrape Kotlin. Tout mon propos est là : en tant que développeur et d’utilisateur au quotidien du langage, ça fait plaisir de voir que Java ne stagne plus comme il a pu le faire à plusieurs époques, et se décide à intégrer les bonnes idées qui viennent d’ailleurs dans la « communauté ».
J’aurais pas dit « mieux » d’après la vidéo. Le message que j’en retiens, c’est plutôt que Java a la possibilité de modifier directement la JVM pour mieux coller à ses évolutions, et donc que les implémentations Java des fonctionnalités peuvent être plus efficaces (le temps que Kotlin tire partie des évolutions de la JVM à son tour).
Évidemment les améliorations de la JVM devraient profiter à tous les langages qui l’utilisent, dont Kotlin-sur-JVM (même si le langage a l’air surtout utilisé sur Android).
Je ne sais pas de quoi tu parles, du moins en 2020 (et pour info quand le reCAPTCHA moderne a un doute, c'est plutôt des photos à tagger avec feux tricolores etc, depuis 2012 de tête pour v2, sans parler de reCAPTCHA v3). La, tu donnes l'idée que tu ne connais pas la "concurrence" moderne.
Non. Tu supposes, et tu supposes mal. Quand je parle des mots déformés, je parle des vieilles merdes qu’on trouve à la place des vieux reCAPTCHA (qui étaient plus des mots illisibles que déformés d’ailleurs, à l’époque ou l’on faisait de la reconnaissance de texte gratos).
Tout le reste de ton « argumentaire » est du même tonneau : tu projettes tes attentes sur l’article et les solutions proposées, et tu en déduis que c’est de la merde parce que ça ne répond pas à tes attentes.
Les hypothèses de l’article sont claires : on est dans le cas d’un formulaire simple que tu gères toi-même, tu as explicitement envie de ne pas imposer à tes utilisateurs de se faire traquer par Google, tu n’as pas peur de faire un peu de code1 et tu sais que le système ne résistera pas à une attaque poussée ou ciblée.
Si tu es hors de ces hypothèses, ben c’est simple : c’est que la solution proposée ne te correspond pas.
Le but n’est pas et n’a jamais été de remplacer reCAPTCHA (dans le sens d’une solution clé-en-main et très efficace).
D’ailleurs reCAPTCHA v2 ou v3 demandent quand même d’écrire du code, puisque normalement il faut vérifier le token et interpréter le score renvoyé. D’ailleurs, maintenir reCAPTCHA demande autant d’effort que maintenir ce que je propopse. ↩
Je dirais que les gens font du reCAPTCHA parce que quand tu cherches une solution efficace sur Internet, c’est à peu près la seule qui fonctionne. Alors que dans beaucoup de cas – qui sont exactement ceux que je vise – tu as un bête formulaire qui est ciblé par des spammeurs peu sophistiqués. Et je ne sais pas toi, mais personnellement ça me fait chier de me taper un reCAPTCHA ou de saisir des lettres illisibles pour un bête formulaire de contact ou un système de commentaires.
La perte d’humain est surtout théorique, pour en avoir il faudrait un temps de détection comme spam vraiment haut par rapport au fomulaire.
Note aussi que proposer du code n’aurait que peu d’intérêt : ce qui est visé, c’est les gens qui font leurs formulaires eux-mêmes. Si tu sais coder ton formulaire et la logique qui va avec, coder les idées que je propose est trivial, et ce quelque soit le langage que tu utilises. Et honnêtement, coder ces protections m’a pris à peu près autant de temps que de configurer et intégrer un reCAPTCHA.
Au-delà de la blague, les panneaux solaires photovoltaïques aiment bien la lumière, mais assez peu la chaleur : leur rendement diminue significativement s’ils chauffent trop…
D’ailleurs, ils avaient déjà choisi des CPU AMD dans la génération actuelle (PS4 / Xbox One), malgré les performances catastrophiques de ces CPU (Jaguar, évolution de Bobcat, une architecture basse consommation).
De ce que je comprends, Wikipedia a une approche encyclopédique et factuelle là où le projet mentionné aurait plus une approche pédagogique et journalistique.
Des couleurs un peu moins tristes que gris/beige suffiraient, j’imagine. Et peut-être changer la police à serifs du menu en haut à droite qui fait vieux de mon point de vue.
Si le cœur d’un éventuel sciencefr.org serait « des actualités scientifiques », la base de linuxfr.org me semble bonne, avec un traitement très orienté « journal » de l’information (des articles destinés à rester assez peu de temps et à être consultés à un moment proche de leur parution). Avec toutefois un travail sur l’apparence. Je n’ai rien contre l’apparence actuelle de linuxfr.org, mais elle est assez austère voire tristoune. Ça va bien pour un public geek comme ici ; mais si on veut attirer un public plus généraliste je pense qu’on peut faire mieux (et hélas, je n’ai pas les compétences pour faire ça en un temps raisonnable).
Si le cœur d’un éventuel sciencefr.org serait « des articles scientifiques », dans le sens où les articles seraient destinés à être consultés un peu n’importe quand et pas forcément à une date proche de leur parution, je ne suis pas sûr que linuxfr.org soit une bonne base. Je partirais plutôt sur quelque chose comme une instance de Zeste de Savoir qui est plus orienté « éditorial » et dont on peut trouver les sources ici.
Du même tonneau, un pote étudiant avait une poubelle, avec rien à voler dedans (même l’autoradio était d’origine). Pour éviter de se la faire abimer, il la laissait toujours ouverte, avec la boite à gants ouverte et la plage arrière du coffre enlevée, pour qu’on voie bien qu’il n’y avait rien à voler.
Il y a quand même des cons qui lui ont pété une vitre (alors que la portière était ouverte…) pour lui piquer un autoradio invendable.
Ces clés fonctionnent avec des batteries, qui s’usent à peu près toutes à la même vitesse – puisqu’il n’y a pas de vraie différence de consommation entre celle qui sert tous les jours et la clé de secours rangée au fond d’un tiroir.
Ce qui implique que :
Ces clés ont une durée de vie, puisqu’une batterie n’est pas infinie.
Qu’il n’est pas prévu à ma connaissance que le particulier puisse recharger lui-même sa clé de voiture1.
Et l’effet kiss cool : comme tout le jeu de clés de la voiture a été produit en même temps et que leurs batteries se déchargent à la même vitesse… elles tombent en panne à peu près en même temps. Donc, le jour où vous ne pouvez plus rentrer dans votre voiture parce que votre super clé électronique est déchargée, il y a de fortes chances pour que la clé de secours soit aussi déchargée.
Je connais au moins deux personnes à qui cette blague est arrivée… il n’y a plus qu’à utiliser la clé mécanique à l’ancienne, en admettant que le modèle de voiture en soit encore pourvu.
Quelque part, ça ne me surprends pas d’une industrie qui arrive encore à fabriquer des véhicules dans lesquels on peut encore enfermer les clés à l’intérieur par mégarde.
On vit quand même dans un monde où l’on peut imaginer de recharger la batterie d’une clé de voiture. ↩
Java fais facilement une consommation de mémoire importante, il demande donc d'y passer du temps ce qui a un coût qui n'est pas toujours justifié par de petits projets en entreprises. De ces défaut découle un autre problème, le coût des développeurs.
Et une immense partie du cout en mémoire, sur les machines récentes, vient de l’incompréhension des développeurs du modèle mémoire de Java et des réglages par défaut de la JVM.
[^] # Re: La peinture c'est un premier pas...
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Cyclimse en Anjou. Évalué à 10.
Par ici, en zone urbaine, on a encore une poignée de « pistes qui sont juste une bande sur le côté de la chaussée ». C’est là où je me fais le plus frôler par les automobilistes, qui semblent penser que si tu es sur ta petite bande super étroite, ils n’ont plus à respecter le mètre de distance de sécurité…
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est pas pour casser l'ambiance
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Java 15 est sorti. Évalué à 3.
Heu… tu est sérieux là ? Le seul truc de « verbeux » dans un
record, c’est les accolades à la fin dont on se demande un peu ce qu’elles font là :On ne peut pas vraiment dire que ça rends le truc illisible…
La gestion d’erreurs (en particulier les checked exceptions) est connu comme l’une des erreurs de conception du langage, entre autres par certains concepteurs du langage. Je ne comprends pas ce que tu veux dire par « Tout ce qui concerne spring boot, » et « le fait que cela ne soit plus programmatique. ».
La consommation mémoire, pourquoi pas (et encore, le gros de la consommation mémoire en Java, c’est surtout des gens qui ne savent pas s’en servir et qui font des fuites mémoires partout, et qui laissent les paramètres à des valeurs démesurément hautes). Les performances… Java peut monter franchement haut en performances, notamment pour un langage non compilé en natif.
Concernant les threads, il y a eu le framework Executor et ses évolutions futures, et il me semble que ça a encore été amélioré depuis.
Pour les frameworks recatifs, je pense à des choses comme RxJava ou Spring Reactor.
Concernant les différences entre JVM/JDK, quelques exemples ici.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est pas pour casser l'ambiance
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Java 15 est sorti. Évalué à 5.
Je vois du vrai et de l’obsolète dans ce que tu écris :
Plutôt faux depuis Java 8. On est très loin de la verbosité de Java jusqu’à 1.4 inclus.
Sur un projet moderne, ça fait des années que je n’ai plus eu à configurer quoi que ce soit en XML à côté du code en Java. Quant à la lourdeur et la lenteur incluses parce que « pas assez paramétrique », je suis réellement curieux d’avoir un exemple de ce que tu entends par là (c’est une vraie question, pas un troll).
Ha ? Tu utilises quoi comme framework ? J’ai un projet perso avec Spring Boot + Kotlin + connexion à la BDD + génération de pages en HTML avec Thymeleaf, je râlais parce que le JAR exécutable (et unique fichier produit) était passé de 49 à 65 Mo en passant à la dernière version de Spring Boot. C’est objectivement gros, surtout quand Quarkus peut produire des binaires natifs beaucoup plus petits (mais sur des piles moins grosses), mais un ordre de grandeur sous ce que tu donnes.
Tout ça, OK (et à mon sens le
nullest peut-être le plus gros problème de Java). Il y avait un projet pour se débarasser des types de base, mais ça fait longtemps que je n’en ai plus entendu parler.Et du coup ça implique quoi comme problème, vu que tu ne manipules jamais de pointeur en Java ?
C’est assez vrai, mais Java date de 1996, Go de 2009, Rust de 2010. Les API récentes ont aussi beaucoup amélioré l’utilisation des threads, et on trouve des API réactives tout à fait convaincantes et performantes depuis peu.
C’est en effet un problème, de même que les incompatiblités entre les différents fournisseurs de JVM/JDK (on les rencontre surtout pour les modes graphiques).
10 secondes chrono si tu connais le nom de AdoptOpenJDK (qui est à connaitre si tu travailles avec Java).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Les pistes cyclables partout c'est possible
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Accidentologie, sécurité routière et cyclisme. Évalué à 2.
On ne parle pas du tout de la même chose : ma réponse était sur le fait de rendre la grande majorité des routes cyclables.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Les pistes cyclables partout c'est possible
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Accidentologie, sécurité routière et cyclisme. Évalué à 3.
Comparons ce qui est comparable :
Soyons clairs : j’adorerais que l’on puisse rouler partout en vélo en toute sécurité, y compris en rase campagne. Mais en ce qui concerne la France, les contraintes géographiques font que sécuriser des pistes cyclables (je dis bien « sécuriser », donc plus que peindre une bande blanche sur le bas-côté) sur l’ensemble du territoire couterait une fortune. Et ça n’est pas des exemples non applicables et des généralités du type « Quand on veut, on peut » déconnectées de toute réalité qui prouvent le contraire, hélas.
La question de la sécurisation des routes de campagne (pour les cyclistes mais pas que : beaucoup sont dangereuses pour tous les usagers) est un vrai problème qui n’a pas de solution triviale que l’on pourrait se contenter de copier/coller depuis l’étranger. Même des aménagements du type « Chaucidou » nécessitent plus de largeur et d’entretien que beaucoup de routes de campagnes, et ça n’est même pas garanti que la « sécurité » supplémentaire de ce genre d’aménagement aurait aidé dans le cas de Zezinho (l’article montre le type de route dont on parle ici).
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est pas pour casser l'ambiance
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Java 15 est sorti. Évalué à 3.
Y’a eu pas mal d’efforts en ce sens, mais la pratique habituelle ça reste quand même d’avoir une JVM avec toutes ses API, ce qui est effectivement souvent lourd pour pas grand-chose.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand même)
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Java 15 est sorti. Évalué à 3.
Pour l’utilisation de Kotlin, je me base plus sur mon expérience et surtout ce que je vois de son support un peu partout, que sur des index aussi bancals de TIOBE (dont la courbe contient des sautes impressionnantes et inexpliquées). Or Kotlin est de plus en plus supporté, depuis les gros et anciens frameworks à la mode comme Spring aux nouveaux frameworks à la mode comme Quarkus.
C’est tout l’intérêt de Kotlin : son principe de base, c’est d’abord et avant tout d’être pratique et agréable à utiliser en leur permettant de se concentrer sur ce qui est important dans le code, pas sur des détails type boilerplate (« A modern programming language that makes developers happier. » d’après eux). Ça fait hurler les puristes des langages et les chercheurs, mais à l’usage dans l’industrie c’est infiniment plus agréable à utiliser que, par exemple, Scala qui lui a une conception orientée par la théorie.
La popularité de Groovy par rapport à Kotlin, je la vois à la fois par rapport à mon expérience personnelle et par rapport aux tendances de recherche sur Google.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est pas pour casser l'ambiance
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Java 15 est sorti. Évalué à 10.
Si tu as des vrais arguments contre Java (des qui existent encore en 2020, pas des qui datent de Java 1.4 et de plus de 20 ans) et pas des insultes, je serais curieux de les lire.
Idem pour toute personne qui plusseoierait le message de Maxzor.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand même)
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Java 15 est sorti. Évalué à 4.
Pour plusieurs raisons :
Et ça n’est pas une question d’implémentation mais clairement de fonctionnalités : en terme de fonctionnalités, Java rattrape Kotlin. Tout mon propos est là : en tant que développeur et d’utilisateur au quotidien du langage, ça fait plaisir de voir que Java ne stagne plus comme il a pu le faire à plusieurs époques, et se décide à intégrer les bonnes idées qui viennent d’ailleurs dans la « communauté ».
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand même)
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Java 15 est sorti. Évalué à 5.
J’aurais pas dit « mieux » d’après la vidéo. Le message que j’en retiens, c’est plutôt que Java a la possibilité de modifier directement la JVM pour mieux coller à ses évolutions, et donc que les implémentations Java des fonctionnalités peuvent être plus efficaces (le temps que Kotlin tire partie des évolutions de la JVM à son tour).
La connaissance libre : https://zestedesavoir.com
# Java 15, le nouveau Kotlin ? (mais un peu en retard quand même)
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Java 15 est sorti. Évalué à 4.
Ça fait plaisir de voir que Java tente de rattraper son retard sur Kotlin. Dans l’ordre de la dépêche :
Évidemment les améliorations de la JVM devraient profiter à tous les langages qui l’utilisent, dont Kotlin-sur-JVM (même si le langage a l’air surtout utilisé sur Android).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Si facile alors pourquoi les gens utilisent reCAPTCHA?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Protéger simplement un formulaire contre le spam en 2020 (sans reCAPTCHA). Évalué à 10. Dernière modification le 11 septembre 2020 à 11:40.
Non. Tu supposes, et tu supposes mal. Quand je parle des mots déformés, je parle des vieilles merdes qu’on trouve à la place des vieux reCAPTCHA (qui étaient plus des mots illisibles que déformés d’ailleurs, à l’époque ou l’on faisait de la reconnaissance de texte gratos).
Tout le reste de ton « argumentaire » est du même tonneau : tu projettes tes attentes sur l’article et les solutions proposées, et tu en déduis que c’est de la merde parce que ça ne répond pas à tes attentes.
Les hypothèses de l’article sont claires : on est dans le cas d’un formulaire simple que tu gères toi-même, tu as explicitement envie de ne pas imposer à tes utilisateurs de se faire traquer par Google, tu n’as pas peur de faire un peu de code1 et tu sais que le système ne résistera pas à une attaque poussée ou ciblée.
Si tu es hors de ces hypothèses, ben c’est simple : c’est que la solution proposée ne te correspond pas.
Le but n’est pas et n’a jamais été de remplacer reCAPTCHA (dans le sens d’une solution clé-en-main et très efficace).
D’ailleurs reCAPTCHA v2 ou v3 demandent quand même d’écrire du code, puisque normalement il faut vérifier le token et interpréter le score renvoyé. D’ailleurs, maintenir reCAPTCHA demande autant d’effort que maintenir ce que je propopse. ↩
La connaissance libre : https://zestedesavoir.com
[^] # Re: Si facile alors pourquoi les gens utilisent reCAPTCHA?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Protéger simplement un formulaire contre le spam en 2020 (sans reCAPTCHA). Évalué à 8.
Je dirais que les gens font du reCAPTCHA parce que quand tu cherches une solution efficace sur Internet, c’est à peu près la seule qui fonctionne. Alors que dans beaucoup de cas – qui sont exactement ceux que je vise – tu as un bête formulaire qui est ciblé par des spammeurs peu sophistiqués. Et je ne sais pas toi, mais personnellement ça me fait chier de me taper un reCAPTCHA ou de saisir des lettres illisibles pour un bête formulaire de contact ou un système de commentaires.
La perte d’humain est surtout théorique, pour en avoir il faudrait un temps de détection comme spam vraiment haut par rapport au fomulaire.
Note aussi que proposer du code n’aurait que peu d’intérêt : ce qui est visé, c’est les gens qui font leurs formulaires eux-mêmes. Si tu sais coder ton formulaire et la logique qui va avec, coder les idées que je propose est trivial, et ce quelque soit le langage que tu utilises. Et honnêtement, coder ces protections m’a pris à peu près autant de temps que de configurer et intégrer un reCAPTCHA.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Je ne sais pas
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Un expert en sécurité poursuivi en justice pour des articles sur des dysfonctionnements réels !. Évalué à 5. Dernière modification le 10 septembre 2020 à 18:08.
Pour être exact, il y a bien une exception de vérité à la diffamation en droit français (qui a droit à son propre article Wikipédia !), mais elle est si contraignant et complexe à faire valoir qu’elle est très peu utilisée.
PS : il y a aussi une « exception de bonne foi » dont je doute qu’elle puisse être utilisée ici, vu le montage en cours.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Constat similaire
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Où vivre dans 100 ans ?. Évalué à 5.
Au-delà de la blague, les panneaux solaires photovoltaïques aiment bien la lumière, mais assez peu la chaleur : leur rendement diminue significativement s’ils chauffent trop…
La connaissance libre : https://zestedesavoir.com
[^] # Re: Mauvaise idée…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal vers un sciencefr.org ?. Évalué à 5. Dernière modification le 05 septembre 2020 à 11:13.
e-penser est en fait celui qui produit le moins dans ta liste.
La connaissance libre : https://zestedesavoir.com
[^] # Re: One Task One processor
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 8.
D’après Wikipedia, les deux sont vraies (dans le sens où elles ont été énoncées par Moore à peu près dans ces termes).
La connaissance libre : https://zestedesavoir.com
[^] # Re: AMD dans les consoles next-gen
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 10.
D’ailleurs, ils avaient déjà choisi des CPU AMD dans la génération actuelle (PS4 / Xbox One), malgré les performances catastrophiques de ces CPU (Jaguar, évolution de Bobcat, une architecture basse consommation).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Wikipedia
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal vers un sciencefr.org ?. Évalué à 6.
De ce que je comprends, Wikipedia a une approche encyclopédique et factuelle là où le projet mentionné aurait plus une approche pédagogique et journalistique.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Quel serait le cœur de la plateforme ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal vers un sciencefr.org ?. Évalué à 2.
Des couleurs un peu moins tristes que gris/beige suffiraient, j’imagine. Et peut-être changer la police à serifs du menu en haut à droite qui fait vieux de mon point de vue.
La connaissance libre : https://zestedesavoir.com
# Quel serait le cœur de la plateforme ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal vers un sciencefr.org ?. Évalué à 5.
Si le cœur d’un éventuel sciencefr.org serait « des actualités scientifiques », la base de linuxfr.org me semble bonne, avec un traitement très orienté « journal » de l’information (des articles destinés à rester assez peu de temps et à être consultés à un moment proche de leur parution). Avec toutefois un travail sur l’apparence. Je n’ai rien contre l’apparence actuelle de linuxfr.org, mais elle est assez austère voire tristoune. Ça va bien pour un public geek comme ici ; mais si on veut attirer un public plus généraliste je pense qu’on peut faire mieux (et hélas, je n’ai pas les compétences pour faire ça en un temps raisonnable).
Si le cœur d’un éventuel sciencefr.org serait « des articles scientifiques », dans le sens où les articles seraient destinés à être consultés un peu n’importe quand et pas forcément à une date proche de leur parution, je ne suis pas sûr que linuxfr.org soit une bonne base. Je partirais plutôt sur quelque chose comme une instance de Zeste de Savoir qui est plus orienté « éditorial » et dont on peut trouver les sources ici.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Une question me taraude
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Sécurité ouverture/démarrage des nouvelles voitures. Évalué à 9.
Du même tonneau, un pote étudiant avait une poubelle, avec rien à voler dedans (même l’autoradio était d’origine). Pour éviter de se la faire abimer, il la laissait toujours ouverte, avec la boite à gants ouverte et la plage arrière du coffre enlevée, pour qu’on voie bien qu’il n’y avait rien à voler.
Il y a quand même des cons qui lui ont pété une vitre (alors que la portière était ouverte…) pour lui piquer un autoradio invendable.
La connaissance libre : https://zestedesavoir.com
[^] # Et l’effet kiss cool de la batterie de ces clés.
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Sécurité ouverture/démarrage des nouvelles voitures. Évalué à 10.
Ces clés fonctionnent avec des batteries, qui s’usent à peu près toutes à la même vitesse – puisqu’il n’y a pas de vraie différence de consommation entre celle qui sert tous les jours et la clé de secours rangée au fond d’un tiroir.
Ce qui implique que :
Je connais au moins deux personnes à qui cette blague est arrivée… il n’y a plus qu’à utiliser la clé mécanique à l’ancienne, en admettant que le modèle de voiture en soit encore pourvu.
Quelque part, ça ne me surprends pas d’une industrie qui arrive encore à fabriquer des véhicules dans lesquels on peut encore enfermer les clés à l’intérieur par mégarde.
On vit quand même dans un monde où l’on peut imaginer de recharger la batterie d’une clé de voiture. ↩
La connaissance libre : https://zestedesavoir.com
[^] # Re: Low Technologies
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Un processeur à 850 000 cœurs et 2 500 milliards de transistors de la taille d’un PC portable. Évalué à 5.
Je crois que ce commentaire va plutôt sous https://linuxfr.org/users/vendrediouletrollsauvage/liens/un-apple-iie-pour-controler-le-demantelement-d-armes-nucleaires (je ne sais pas si un modérateur peut déplacer un commentaire ?)
La connaissance libre : https://zestedesavoir.com
[^] # Re: le meilleur langage pour les projets d'entreprise
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Toileharicot 12 est dehors. Évalué à 3.
Et une immense partie du cout en mémoire, sur les machines récentes, vient de l’incompréhension des développeurs du modèle mémoire de Java et des réglages par défaut de la JVM.
La connaissance libre : https://zestedesavoir.com