barmic 🦦 a écrit 5800 commentaires

S'il ne peut pas tout il faut en sortir ?

Sérieux c'est complètement con d'opposer les sources d'énergies. C'est du politique. On a largement les moyens de travailler sur 2 ou 3 sources d'énergies différentes. Mais la base c'est de faire avec ce que l'on a pour ne pas perdre de temps.

Qu'on fasse un très gros travail sur l'heolien, le solaire ou l'usine marais motrice ne demande pas à sortir du nucléaire.

On aura jamais trop d'énergies, on sait piloter et nos voisins sont très content qu'on les fournisse.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu as les liens des réactions des développeurs de webkit et de chez Mozilla, si tu veux aller plus loin que faire des remarques désobligeantes.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu es entrain de dire que Mozilla, qui développe un moteur js complet avec le navigateur qui va autour ne connaît pas ce qu'ils ont implémenté ? Ou alors tu es entrain de dire que Google qui développe l'autre moteur js avec le navigateur qui va autour font des trucs pour rien ? Bon et même les développeurs de webkit ne connaissent pas l'événement onmove ?

Tu n'es pas très bien placé sur la courbe de l'effet Dunning-Kruger amha.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Les types somme sont représentables en Kotlin via les sealed classes :

C'est pas juste moins élégant, c'est drastiquement plus limité. Tu dois définir tes regroupement de types et un type ne peut appartenir qu'à un seul groupe. Ça change profondément l'utilisation et c'est bien plus limitant.

De façon plus générale, et bien qu'étant plus habitué au typage nominal, je trouve incroyablement expressif le typage structurel de TypeScript (je pense entre autres à toi, keyof) ; on a pu faire des choses vraiment sympas avec.

Je suis d'accord et ça permet de ne pas lier des chose que tu ne veut pas particulièrement lier. Tu peux créer une fonction qui va prendre en paramètre un objet qui a une référence sans qu'elle est besoin de connaitre ton Warrior sur des projets de bonnes dimensions quand c'est bien utilisé ça simplifie les dépendances.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Maintenant, il n'a pas de concurrence[…]

Je n'ai jamais était fan de postman, mais en outil du même genre tu as soapui (qui contrairement à ce que son nom indique ne se limite pas à soap). En client rest avec moins de fonctionnalités (pas de scripting principalement), tu as rest-client, une extension de vscode. L'utilisation de simples fichiers textes permet de partager facilement les requêtes contrairement à postman.

Je me doute que tu as des fonctionnalités que tu ne retrouvera pas, mais comme je ne connais pas très bien postman je suis intéressé de savoir les quels.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oui tout à fait tu ne fais que remplacer ton FAI.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

L'usage d'un vpn c'est pour être anonyme vis à vis des société qui pistent les internautes

Non. Je trouve fou le brouhaha qu'il y a autour de vpn. Les vpn servent à 3 choses :

• avoir un réseau dont l'accès est authentifié et qui ne peut être espionné (c'est bien plus sérieux que la sécurité par addresses mac (sic))
• sortir sur le réseau internet depuis un point de sortie contrôlé (changer de pays par exemple ou juste ne pas pouvoir être observé depuis un wifi ou par son fai)

Cela ne change rien pour les sociétés qui pistes les internautes. La majorité de ses sociétés s'appuient sur la destination de ton trafic (les trackers que tu peux trouver sur chaque site) pas sur le réseau et même celles qui s'appuient sur le réseau te verrons à la sortie du vpn.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Déjà c'est quoi l'usage d'un langage ? Le nombre de personnes qui l'utilise à partir de quelle quantité de code ? (qui j'écris 3 lignes littéralement de bash de temps en temps comment il faut me compter ?) Est-ce que le nombre de lignes peu se comparer entre langage ? Est-ce que ça a un intérêt de savoir que 2 milliards de de gens font du D de l'autre côté de la planète sur un domaine qui ne te concerne pas ?

Bref qu'est ce qu'on s'en fout ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

En quoi le typage de Typescript est plus "expressif" que Kotlin ? Est-ce l'héritage du JAvascript ?

Kotlin est un langage typé statiquement. Selon moi, il a pour lui de ne pas supporter le JSON (pour beaucoup c'est un inconvénient), et le support des DSLs.

Typescript est typé statiquement aussi (au runtime ce sera du js), mais il fait du typage structural et il permet d'exprimer des types sommes. Ce ne sont que quelques exemples, il y a encore des aspects plus subtiles (avec key of entre autre).

Pour les assets de ce que je comprends vous utilisiez pleins de techno différentes et c'est compliqué de tout merger. Ça peut se comprendre, même si je trouve qu'en conclure que typescript est un problème en soit c'est allé très vite en besogne.

Perso, je n'ai jamais réussi à débuguer un fichier js issue d'une transpilation en utilisant le mapping associé sur notre version de dev (donc sans compression )… Mais je ne dis pas que c'est impossible, ni que Typescript est un mauvais choix (juste que je préfère Kotlin).

C'est exactement la même technique qu'avec kotlin. Je présume que le fait que tu utilise un écosystème plus kotlin friendly doit jouer. J'essaie perso de moins chercher à utiliser mon environnement dans des contexte différents et préfère embrasser les usages du contexte en question. Par exemple si je devais faire de l'embarquer je ne tenterais pas de voir si je peux faire un build natif de java/python si l'usage est plutôt d'utiliser du C.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Et je ne comprends pas non plus ce qu'apporte kotlin en plus vu que typescript a un typage plus expressif.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu veux dire que des projets essaie de compiler / compresser les assets et sont emmerder par TypeScript

Non je parle d'avoir une étape de build. Mais je suis intéressé par les problèmes que pose typescript pour ça, tu as un lien ?

On pourrait aussi ajouter que certains projets ne se compile pas via l'IDE, mais que l'IDE supporte le système de build du projet.

Je ne comprends pas de quoi tu parle. Jusqu'au début des années 2010's beaucoup d'IDE venaient avec leur propre build et certains projet ne se construisaient qu'avec l'IDE. Aujourd'hui et particulièrement dans le monde du web ça n'existe pas. Tout le monde utilise npm ou yarn peut-être avec un bundler mais tous s'utilisent en cli. Je ne comprends pas ta remarque du coup. Les éditeurs s'appuient sur ces commandes pour produire les infos dont ils ont besoins.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Donc c'est pas vraiment un argument ;)

Si si justement c'en est un :)

Voui. Et un bon IDE te masque cet état de fait, rendant complètement transparent le processus.

Beaucoup de projets ont quoi qu'il arrive une étape de build pour éviter d'avoir une quarantaine de requêtes dès le premier chargement d'une page.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

OpenJDK a une liste de projets libres qui leur servent entre autre à ça. Tu peux aussi activer des logs pour qu'hotspot indique les choix qu'il fait. Ça n'en fait pas quelque chose de génial (les projets ont une certaine latence pour passer aux nouveautés à des fins de compatibilité et lire ces logs, bien que compréhensibles, ne vaut pas une doc qui donne des règles) mais c'est déjà ça.

Note qu'en plus les heuristiques d'un jit dépendent d'informations runtime, tu peux avoir des optimisations différentes selon l'état de la jvm ce qui peut rendre assez complexe les benchmark.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si on a le temps de détecter ces 3%

Oui mais la détection est importante justement. Avant d'en arriver à dérouler des boucles à la main, c'est intéressant de vérifier les IO, les algo et structures de données et une fois que toutes ses choses sont faites, on peut aller vers des optimisations qui vont commencer à prendre le pas sur la lisibilité et la maintenabilité.

Et oui quelques lignes de code peuvent drastiquement changer la donne. Prends le bug de GTA sur le parsing de fichier json : How I cut GTA Online loading times by 70%. On parle de quelques dizaines de lignes.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Les compilateurs n'éditent pas de document pour donner des grands principes d'état de l'art comme ça ? Que ce soit des règles de codage ou des options de compilation qu'ils n'activent pas par défaut car cassant la norme mais qui devraient être l'usage selon eux.

Je comprends qu'Intel vend des formations, mais gcc/llvm me paraissent plus ouverts.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne sais pas ce qu'il en est depuis le rachat par Atos, mais Bull coopérait avec IBM pour développer AIX.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

depuis le temps et les versions rien que la migration va être une gageure qui prendra temps et argent…)

Et attendre améliore la situation ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tout à fait, de la même manière que des structures de données plus complexes (comme les map) n'ont pas la même implémentation optimales selon si elles sont petites ou grande.

En fait, je pense que find est déjà optimisé mais pour des tailles de l'ordre de la centaine.

En soit elle pourrait faire un test au runtime pour ça.

Personne ne doit faire de recherche linéaire sur 1 millions d'élément.

Entièrement d'accord et si l'exercice de regarder comment marchent les optimisations de la toolchain est intéressant et pratiques sur des cas triviaux, il faut :

1. s'assurer que ce que l'on observe à petite échelle garde du sens à grande échelle
2. s'assurer que l'ont est entrain de regarder quelque chose de pertinent (quel est l'impact de ce que l'on regarde sur la performance globale du programme ?). Il me semble que dans biens des cas le problème est moins dans la performance CPU que dans les IO par exemple. Utiliser de manière pertinentes les mmap/io_uring/etc me semble amplement plus important.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Évidemment il n'est pas question de tout optimiser, mais la vraie raison pour laquelle nous écrivons du code de haut niveau n'est pas que les compilateurs sont très performants ; c'est plutôt un compromis du temps de mise en œuvre. En d'autres termes, nous acceptons du code sous optimal au profit d'une écriture et d'une maintenance simplifiée.

Il me semble que ton journal démontre l'inverse. std::find permet à la toolchain (que ce soit le compilateur ou la bibliothèque standard) d'implémenter simplement des optimisations. Là où les heuristiques qui vont dérouler des boucles peuvent être fragiles (être appliquées ou non par faux positif/négatif) et même être cassé dans le code (parce que boucle toute propre, tu peux repasser dessus 1 ans plus tard et y ajouter un 'tit traitement qui va invalider l’heuristique).

Ensuite il semble effectivement que les toolchains ne sont pas forcément aussi optimisées qu'on l'espérerais. Il me semble néanmoins qu'il est préférable de s'appuyer dessus et que tenter d'optimiser sois-même et d'arriver assez vite à du code bugué et très difficile à maintenir comme on le voit dans d'autres commentaires. Sincèrement avoir un code qui recherche une valeur dans un tableau qui contiens une erreur suffisamment non trivial pour ne pas sauter aux yeux, je préfère avoir un code un peu plus lent. Je place la correction du code comme une qualité qui est tout de même devant toutes les autres en terme de qualité logiciel.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Sinon, je ne veux pas faire un truc exotique, juste avoir des requêtes qui arrivent au proxy, qui les redirige vers yunohost, ou la box domotique, ou le nas, en fonction. Ça me parait pas délirant comme besoin.

Effectivement. Sans en savoir plus je dirais que le plus simple c'est de rooter les requêtes en fonction des sous noms de domaine. Comme ça tu fais, nas.yannick.fr pour aller sur ton nas, box.yannick.fr pour ta box, etc.

Pour ça il faut un proxy tcp, qui va juste regarder les noms de domaine et choisir où envoyer quoi. C'est lui qui s'occupe de TLS pour tout le monde. La seule chose à savoir pour chaque services (yunohost, ta box, etc) c'est comment leur dire derrière quel sous nom de domaine ils sont (et encore ils n'ont pas forcément nécessaire selon comment ils fonctionnent).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si tu as d'autres outils beaucoup plus générique, il faudrait utiliser un proxy plus généraliste style "proxy sur TCP ou UDP" ou des tunnels SSH, mais dans ce cas je n'ai pas de connaissance.

C'est assez me en fait, mais je suis pas sûr qu'apache le fasse. nginx ou haproxy sont très bien pour ça.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu n'a pas à gérer cette histoire de challenge, parce que c'est ton revers proxy qui doit faire la terminaison TLS (si tu veux que ce soit un proxy http).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est parce que le terme cellule mémoire se perd un peu. Ce qui le rendait bien plus pertinent que ramasse miettes.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Évidement les mécanismes de triches sont délétères dans une communauté de jeu, certains ayant des avantages par rapport aux autres et amenant un gros déséquilibre. Mais en fait, ce genre de déséquilibre n'intervient que dans les jeux où il faut "être le meilleur", et ce n'est pas forcément plus agréable d'avoir en face de soi un joueur très bon qui ne triche pas mais ne laisse aucune chance. Une des premières motivations des tricheurs vient donc, paradoxalement, de ce déséquilibre : ne pouvant être assez bons avec leurs skill persos, ils cherchent à l'améliorer avec l'aide de l'informatique. En ce sens, une triche "légère" va leur permettre de se mesurer de façon plus égalitaire avec de très bons joueurs. Mais elle va aussi les renforcer dans l'idée que ce niveau n'est atteignable qu'en trichant (si l'autre est si bon, c'est forcément qu'il triche, non ?), donc favoriser le fait d'utiliser de plus en plus de mécanismes de triche, jusqu'à faire perdre tout intérêt au jeu. Parce qu'un bon jeu, c'est un jeu qui maintient dans le flow, en donnant juste ce qu'il faut de difficulté et de réussite pour qu'on trouve ça gratifiant. Une triche peut satisfaire temporairement mais rend souvent le jeu trop facile et lui fait perdre son intérêt…

C'est le cas que je connais peut être le mieux. Ça ne marche pas très bien. Prends un genre qui est un carton aujourd'hui : les battles royals. C'est tout le principe d'être le meilleur et de demander du skills. Leur reprocher c'est comme de reprocher au tour de France d'être une course. C'est intrinsèque au genre et pour ne pas te faire bully, tu as un système de classement pour que tu ne soit pas juste de la chaire à canon et un système pour limiter voir empêcher les reroll pour éviter qu'un rang S vienne te moissonner juste pour l'amusement de bully les autres.

Une triche peut satisfaire temporairement mais rend souvent le jeu trop facile et lui fait perdre son intérêt…

Tu peut te retrouver dans une compétition de cheater, c'est amusant de moissonner, tu as ton p'tit shot de satisfaction quand tu vois l'écran qui te dit que t'a gagné.

Le hack et l'anti-cheat est un savant équilibre (parce que le monde du mod est complètement là dedans aussi) et c'est à chaque jeux de trouver son positionnement en fonction de son style, de sa population etc.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pour info, java a des JEP qui sont équivalent aux PEP de python si ça parle plus. Il y a toujours une section motivation ici.

Pour le cas des sealed class (donc qui sont des interfaces dont l'héritage est limité) est pratique avec les switch expression.

Si tu as :

return switch(shape) {
    case Square s -> /* */;
    case Circle c -> /* */;
};

Tu es obligé d'avoir un switch complet. Les sealed class permettent de garantir la complétude sans avoir de default.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll