barmic 🦦 a écrit 5783 commentaires

Or, il n'était pas, et ça ne l'est toujours pas, inhabituel de coder les SE en langage C.

À ça. Il dit que Linus ne s'est pas pris de commentaire parce que ce n'est pas inhabituel de faire un noyau en C ce qui signifie qu'ici c'est normal d'avoir ce genre de commentaire car c'est inhabituel de coder un noyau en rust.

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

Les prof ne se sont pas plains de ne pas avoir à apprendre faire des recherches sur internet aux étudiants…

Le problème n'est pas google ici. Ce n'est même pas forcément un problème, c'est juste qu'il y a un glissement des usages de l'ordinateur vers les mobiles et tablettes.

Moi perso l'un ou l'autre, je ne sais pas ranger.

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

Il n'y a rien de bizarre à coder un noyau en rust. Il y a déjà plusieurs projets pour le montrer et les développeurs de linux intègrent du rust (progressivement pour le moment dans les modules).

Pour jouer les surpris quand on parle de coder un noyau en rust, il fallait venir il y a 5 ans.

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

Je comprends le principe, mais je vois pas pourquoi être condescendant. C'est le principe même d'essayer un tas de choses et de voir ce qui est à garder ou pas. Surtout que l'existant est loin d'être exempte de défauts.

Je ne vois pas ce qu'il y a de dérangeant dans ce projet. Si ça te soule passe ton chemin si tu as raison, le projet n'aura pas besoin de toi pour mourir dans son coin.

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

Mais ces camps sont une réalité.

Oui, mais non. Ils existent et sont aussi présent parce qu'on polarise le débat sur cette question, mais c'est un problème en soit. Je persiste parce que ça n'a rien anodin : poser un problème de la bonne façon c'est déjà commencer à le résoudre.

Cette question dévie permet aux politiques de se définir facilement, c'est facilement différenciant et ça évite de poser des questions que personne ne veut entendre.

Tu parle de changement sociétal, comme s'il suffisait de se dire pour le changement sociétal, mais comment on arrive à ce changement sociétal est un problème immense. Pendant qu'on s'échine à compter les g de CO2, on ne pose pas la question de ce changement. Comment on l'amène ? Est-ce qu'on considère que le prix et donc le marché se suffit ? Est-ce qu'on veut faire de la planification ? Est-ce qu'on invente autre chose ? Quel part doit être supporté par les entreprises et par les particulier ? Quel pans de notre économie ne peut plus marcher (ou en tout cas pas comme actuellement) dans ce nouveau contexte ?

Plus loin encore, quel pans de notre mode de vie dépend de production de CO2 hors de notre territoire ? Comment on fait ? Est-ce soutenable ?

On choisi de mettre l'emphase sur la source d'énergie parce qu'électoralement c'est bien moins clivant, mais ce n'est pas pour ça que c'est pertinent.

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

Pour rebondir sur la rationalité: personne ne se présente comme motivé par des choix fondamentalement irrationnels, et au final, tout le monde considère que l'irrationnel, c'est l'autre.

Tu maintiens des questions de camps. C'est ce que je trouve regrettable.

Distinguer des camps qui s'opposent envenime le débat et l'enferme dans des considérations qui n'ont rien de pertinent.

J'ai aussi l'impression que ces personnes qui veulent éviter la question des changements sociétaux et qui donc misent sur une solution salvatrice 100% technologistes sont plus présents du côté nucléaire que du côté EnR.

Pourquoi chercher à tout rapprocher à l'axe enr/nuc ? Si le problème c'est ceux qui ne veulent pas de changement sociétaux pourquoi ne pas simplement le dire ? Sinon ça crée des homme de paille.

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

Une frustration qui revient souvent, c'est de voir la difficulté de communiquer avec certains politiciens qui misent tout sur le technologique.

Les solutions EnR sont aussi très technologiques. Les générations, le stockage, la durée de vie et le recyclage sont aussi de l'ordre de la recherche plus ou moins avancées.

On oppose qui se ressemblent bien plus qu'on ne le croit et aucune démarche ne se passe de gap technologiques.

Je ne suis pas un expert non plus, mais j'ai un vrai problème à laisser des politiques annoncer des choix qui sont clairement de l'ordre idéologique. Penser que l'on peut se permettre ce genre de considération et alimenter des querelles de clocher me paraît être une racine du mal. On a besoin de rationalité.

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

Tous les axes reposent sur des technologies qui n'existent pas encore (industrialiser les générations suivantes du nucléaire ou stocker de l'énergie). Donc c'est un pari de suivre une voie plutôt qu'une autre.

Et oui on a de l'argent. D'une part parce que dans le budget de l'État est une question de remise en cause des priorités. De l'autre parce qu'on a des capacités à emprunter énorme et que c'est typiquement de l'investissement. On parle pas d'argent qui parts dans des frais de fonctionnement, mais de comment est-ce qu'on va faire pour avoir de l'énergie demain voir qu'est ce qu'on pourra vendre comme énergie et comme technologie. Si on a pas de données claire sur la quelle marche ça vaut largement le coût de jouer sur différents tableaux.

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

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