Avec 833 en simple cœur, l’A12Z [le CPU du Mac ARM pour développeurs] en émulation obtient à peu près les performances d’un Athlon 3000G ou d’un Core i3 Skylake. En natif, à travers la version iOS, le résultat passe à 1130, l’équivalent d’un core i7 6700K (un CPU qui fonctionne à 4 GHz, contre 2,4 GHz ici). […] Dans tous les cas, compte tenu de la fréquence (2,4 GHz), les performances sont excellentes et le DTK en émulation est largement plus rapide qu’un MacBook de 2017, doté d’un Core i5 7Y54 avec un TDP faible (7W) : entre 50 et 78 % de mieux sur les tests longs.
Le reste dans le numéro 46 de CanardPC Hardware, 6,90 € chez votre marchand de journaux (qui je crois est encore ouvert malgré le confinement).
Si on parle d'un petit ordinateur de bureau (et pas d'un Ryzen 7 ou d'un Core i7), c'est crédible.
CanardPC Hardware dans son dernier numéro a pu faire des mesures sur quelques machines ARM destinés à ce type d'usage, et en particulier sur la machine fournie par Apple aux développeurs pour les tests du futur Mac ARM. Et les résultats sont impressionnants, loin des brouettes que l'on pourr supposer.
(ils ont aussi installé Windows sur des vieux Raspberry Pi, et là c'est bien aussi lentissime qu'attendu 😁)
Aujourd’hui, si tu n’as pas de raison extérieure impérative d’utiliser J9, la seule raison que je vois c’est pour le plaisir d’utiliser une alternative. Il y a peut-être des cas spécifiques particuliers où elle est intéressante, mais de but en blanc je n’en connais pas.
L’argument « pour » était tout simplement que pendant longtemps, les produits IBM refusaient de se lancer (ou se comportaient n’importe comment) s’ils n’utilisaient pas J9…
Si tu étais riche (parce que la licence n’était pas donnée si tu voulais utiliser J9 autrement que pré-packagé avec un produit IBM) et que tu avais besoin d’un peu plus de performances, jusqu’à Java 1.5 inclus, ça pouvait être aussi une solution à étudier.
Oui, quand je dis « puissant » c’est « assez pour être vu », pas « phare dans la nuit », j’aurais dû précise. Parce qu’on trouve aussi les gens qui éblouissent les autres usagers, même si d’expérience c’est plus un problème te trottinette électrique.
J’ajoute qu’en plus de l’OpenJDK, il y a d’autres JDK alternatifs. Le plus utilisé (et qui reste vraiment un JDK, pas un machin étrange comme GraalVM) est sans doute J9, le JDK d’IBM, qui est récemment passé chez la fondation Eclipse.
Jusqu’à Java 6, il était sensiblement plus performant que le JDK d’Oracle, mais ça n’est plus le cas. Il est obligatoire pour certains produits IBM, et son implémentation est complètement différente, y compris les classes de l’API.
s'il vous plait équipez vos vélos de phares clignotant et portez casque et gilet munis de bandes réfléchissantes.
S’il vous plait équipez vos vélos de phares fixes et puissants et portez un casque hors agglomération.
Pourquoi un phare fixe et pas clignotant ? Parce qu’un phare clignotant permet d’être repéré de loin (ça clignote, ça se voit), mais a deux inconvénients :
Soit il clignote très vite (plusieurs hertz) et c’est atroce et perturbant (et donc peut faire louper des dangers tiers)
Soit il clignote lentement, et empêche de percevoir correctement votre vitesse et votre trajectoire. Or, un cycliste ça va relativement vite (calculs ci-dessous), et le temps pendant lequel vous êtes éteint, vous êtes invisibles. Bonus pour ces gens qui ont des lampes à clignotement aléatoire : on voit qu’il y a quelque chose, mais c’est impossible de deviner ce que c’est, à quelle vitesse et dans quelle direction.
« Puissant » parce que les lampes vendues par défaut avec certains vélos sont des merdes qui sont invisibles à plus de 10 mètres, et donc totalement insuffisantes, surtout hors agglomération.
Le gilet fluo n’est pas vraiment utile la nuit si vous avez des phares corrects, il est plutôt utile au crépuscule. Pourquoi ? Parce qu’il ne produit pas de lumière. La nuit hors éclairage, tant que vous n’êtes pas pris directement dans le faisceau d’un phare, que vous ayez un vêtement noir ou une combinaison haute visibilité, c’est exactement pareil. J’ai failli rentrer dans un nombre incalculable de cyclistes l’hiver, sur les pistes non ou mal éclairées qui passent dans les parcs à Montpellier, à cause de gens qui pensaient qu’un gilet fluo les rendait magiquement visibles dans la nuit malgré l’absence de tout éclairage.
Cela dit, si vous avez un gilet fluo, ça reste une bonne idée, surtout hors agglomération (où vous croiserez surtout des voitures qui vous verront de plus loin avec que sans le gilet) (je me demande même s’il n’est pas obligatoire hors agglomération la nuit ?).
PS : le calcul.
Un cycliste qui avance doucement, c’est 15 km/h, donc 4,17 m/s. Un phare à 1 Hz vous laisse invisible une demi-seconde, pendant lesquelles vous aurez parcouru plus de 2 m.
Hors agglomération, on va sensiblement plus vite, typiquement 30 km/h sans trop forcer. Le même phare laisse plus de 4 m de déplacement qui ne sera pas vu par les voitures aux alentours.
Et j’ai croisé des phares qui clignotaient encore plus lentement que ça.
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).
[^] # Re: quel forceur ce Martoni
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le retour du RiscPC ?. Évalué à 6.
Pour le seul cas du Mac ARM :
Le reste dans le numéro 46 de CanardPC Hardware, 6,90 € chez votre marchand de journaux (qui je crois est encore ouvert malgré le confinement).
La connaissance libre : https://zestedesavoir.com
[^] # Re: quel forceur ce Martoni
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le retour du RiscPC ?. Évalué à 7.
Si on parle d'un petit ordinateur de bureau (et pas d'un Ryzen 7 ou d'un Core i7), c'est crédible.
CanardPC Hardware dans son dernier numéro a pu faire des mesures sur quelques machines ARM destinés à ce type d'usage, et en particulier sur la machine fournie par Apple aux développeurs pour les tests du futur Mac ARM. Et les résultats sont impressionnants, loin des brouettes que l'on pourr supposer.
(ils ont aussi installé Windows sur des vieux Raspberry Pi, et là c'est bien aussi lentissime qu'attendu 😁)
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.
Aujourd’hui, si tu n’as pas de raison extérieure impérative d’utiliser J9, la seule raison que je vois c’est pour le plaisir d’utiliser une alternative. Il y a peut-être des cas spécifiques particuliers où elle est intéressante, mais de but en blanc je n’en connais pas.
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.
L’argument « pour » était tout simplement que pendant longtemps, les produits IBM refusaient de se lancer (ou se comportaient n’importe comment) s’ils n’utilisaient pas J9…
Si tu étais riche (parce que la licence n’était pas donnée si tu voulais utiliser J9 autrement que pré-packagé avec un produit IBM) et que tu avais besoin d’un peu plus de performances, jusqu’à Java 1.5 inclus, ça pouvait être aussi une solution à étudier.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Construire des pistes cyclables mais pas que ...
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Cyclimse en Anjou. Évalué à 2.
Oui, quand je dis « puissant » c’est « assez pour être vu », pas « phare dans la nuit », j’aurais dû précise. Parce qu’on trouve aussi les gens qui éblouissent les autres usagers, même si d’expérience c’est plus un problème te trottinette électrique.
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.
J’ajoute qu’en plus de l’OpenJDK, il y a d’autres JDK alternatifs. Le plus utilisé (et qui reste vraiment un JDK, pas un machin étrange comme GraalVM) est sans doute J9, le JDK d’IBM, qui est récemment passé chez la fondation Eclipse.
Jusqu’à Java 6, il était sensiblement plus performant que le JDK d’Oracle, mais ça n’est plus le cas. Il est obligatoire pour certains produits IBM, et son implémentation est complètement différente, y compris les classes de l’API.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Construire des pistes cyclables mais pas que ...
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Cyclimse en Anjou. Évalué à 7. Dernière modification le 24 septembre 2020 à 17:29.
S’il vous plait équipez vos vélos de phares fixes et puissants et portez un casque hors agglomération.
Pourquoi un phare fixe et pas clignotant ? Parce qu’un phare clignotant permet d’être repéré de loin (ça clignote, ça se voit), mais a deux inconvénients :
« Puissant » parce que les lampes vendues par défaut avec certains vélos sont des merdes qui sont invisibles à plus de 10 mètres, et donc totalement insuffisantes, surtout hors agglomération.
Le gilet fluo n’est pas vraiment utile la nuit si vous avez des phares corrects, il est plutôt utile au crépuscule. Pourquoi ? Parce qu’il ne produit pas de lumière. La nuit hors éclairage, tant que vous n’êtes pas pris directement dans le faisceau d’un phare, que vous ayez un vêtement noir ou une combinaison haute visibilité, c’est exactement pareil. J’ai failli rentrer dans un nombre incalculable de cyclistes l’hiver, sur les pistes non ou mal éclairées qui passent dans les parcs à Montpellier, à cause de gens qui pensaient qu’un gilet fluo les rendait magiquement visibles dans la nuit malgré l’absence de tout éclairage.
Cela dit, si vous avez un gilet fluo, ça reste une bonne idée, surtout hors agglomération (où vous croiserez surtout des voitures qui vous verront de plus loin avec que sans le gilet) (je me demande même s’il n’est pas obligatoire hors agglomération la nuit ?).
PS : le calcul.
Un cycliste qui avance doucement, c’est 15 km/h, donc 4,17 m/s. Un phare à 1 Hz vous laisse invisible une demi-seconde, pendant lesquelles vous aurez parcouru plus de 2 m.
Hors agglomération, on va sensiblement plus vite, typiquement 30 km/h sans trop forcer. Le même phare laisse plus de 4 m de déplacement qui ne sera pas vu par les voitures aux alentours.
Et j’ai croisé des phares qui clignotaient encore plus lentement que ça.
La connaissance libre : https://zestedesavoir.com
[^] # 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