barmic 🦦 a écrit 5915 commentaires

  • [^] # Re: N'importe quoi…

    Posté par  . En réponse au lien Électricité bas carbone et vision politique en cette période de canicule. Évalué à 2.

    brennilis n'est toujours pas terminé

    Ils ont pris 5 ans dans la tête à cause d'un permis de construire plus quelques années pour des raisons purement politique (Sortir du nucléaire qui s'oppose à EDF par principe).

    à chooz A, le démantèlement du réacteur est sous-traité à une entreprise américaine

    Je n'en ai pas trouvé trace. J'ai vu qu'Onet (français), Areva (français) et Mammoet (néerlandais) en plus d'EDF sont impliqués. Tu as un lien ?

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

  • [^] # Re: N'importe quoi…

    Posté par  . En réponse au lien Électricité bas carbone et vision politique en cette période de canicule. Évalué à 2.

    Je suis pas d'accord avec toi mais je t'ai pertinenté. Je comprend pas comment on peut mettre une note négative a un commentaire aussi argumenté et développé simplement parce qu'on a une opinion différente.

    Je n'ai fais ni l'un ni l'autre. Mais bon samwang aurait à redire du fait que des commentaires argumentés et développés sont mal vu :)

    Ici moi je trouve sincèrement que l'argumentation est plutôt faible :

    • prendre son exemple comme argument pour la consommation des mĂ©nages sans chercher Ă  prendre en compte le système de chauffage, le type d'habitation, la situation gĂ©ographique, la ruralitĂ© ou non. S'appuyer sur une moyenne globale sans regarder l'Ă©cart-type ce qui aurait mis en Ă©vidence ces disparitĂ©s ;
    • l'industrie plastique qui est amenĂ©e sans la moindre forme d'explication. Le fait qu'il ne l'aime pas n'est pas un argument suffisant pour imaginer qu'elle consomme particulièrement de l'Ă©nergie. Quant Ă  la notion de bullshits job (qui est ici utilisĂ© sans en comprendre le sens1), il faut vraiment faire attention parce qu'il y en a qui disent la mĂŞme chose de nous. Donc amener ça sans plus d'argumentation c'est vraiment pas très pertinent ;
    • le paragraphe "Le biais de la sĂ»retĂ© par les statistiques" (alors qu'il amène des stats juste avant) ne conceptualise pas du tout ce qu'il veut dire : la notion de risque/danger. Ça rend le paragraphe compliquĂ©, tortueux et ça tente d'amener un biais lĂ  oĂą il n'y en a pas, il veut parler de l'omission du danger.

    1. un bullshit job est un travail qui est considéré par l'employé comme inutile. C'est une notion qui est là pour parler de boreout par exemple. Tu peux considérer ton travail comme totalement inutile qu'il le soit ou pas. Dites-vous que ça arrive pour des gens dans nos métiers. Ce n'est pas quelque chose qui est fait pour pointer du doigt certains métiers. ↩

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

  • [^] # Re: Briser la glace

    Posté par  . En réponse à la dépêche À la découverte de FreeBSD. Évalué à 4.

    La carte survie à ce genre de traitements ?

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

  • [^] # Re: Briser la glace

    Posté par  . En réponse à la dépêche À la découverte de FreeBSD. Évalué à 6.

    DragonflyBSD est un fork de FreeBSD de ce que j'en sais il a 2 particularités :

    • le SMP : Ă  l'Ă©poque FreeBSD avait un Big Kernel Lock (maintenant ils sont passĂ© un un lock Ă  grain fin comme linux) dragonfly utilise un mĂ©canisme de sĂ©rialisation par token, je crois que c'est arrivĂ© plus tard mais il a LWKT qui sont des threads lĂ©ger kernelland, je ne me suis pas plus penchĂ© dessus, mais ça doit ĂŞtre une implĂ©mentation de green thead/coroutine cotĂ© noyau
    • le FS : ils ont revu le VFS pour tirer partie de leur multithreading et ont hammerfs qui est un fs qui s'aligne plus ou moins sur zfs et btrfs

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

  • [^] # Re: Comment ça, Google sait ?

    Posté par  . En réponse au journal Nous avons un super‑pouvoir pour faire déguerpir les automobilistes 📱 => ⛔ 🚗. Évalué à 2.

    j'utilise mon telephone un p30 pour telephoner et recevoir les photo par sms, comme reveil et chez moi pour certain sites. hors domicile je n'utilise jamais les données. d'ailleurs la batterie tiens 3 a 4 jours :D, je pensait que je devais recherger tous les jours mais non :p

    C'est pas totalement overkill ?

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

  • [^] # Re: Low tech

    Posté par  . En réponse au journal Nous avons un super‑pouvoir pour faire déguerpir les automobilistes 📱 => ⛔ 🚗. Évalué à 10. Dernière modification le 07 août 2020 à 00:40.

    dans smartphone, smart vient de "intelligence", renseignement en anglais.

    Euh….

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

  • # Berlin

    Posté par  . En réponse au journal Nous avons un super‑pouvoir pour faire déguerpir les automobilistes 📱 => ⛔ 🚗. Évalué à 10.

    L’allemand Simon Weckert, s’est baladé avec 99 téléphones dans les rues de Berlin, récupérés auprès de ses amis, et s’est retrouvé seul sur des rues habituellement denses !

    Je ne connais pas Berlin et je ne doute pas que les capitales de l'UE sont de manière générale chargées en voitures, mais j'ai du mal à croire ce qui est présenté. Il n'y a absolument personne ni avant ni après. Il y a tout juste 2 voitures qui passent. Aucun scooter, juste 2 voitures qui passent (aucune ne passe à coté et vois que c'est vide ?), aucune voiture avant qu'il arrive dans une rue (il y a quand même une latence pour la prise en compte par gmaps + la prise en compte par les automobilistes),…

    Je ne pense pas que c'est faux, juste qu'il a choisi le moment le plus propice possible pour augmenter l'impact, mais ça en devient presque mensonger (c'est plus proche du cinéma que du documentaire dans l'intention). Oui il parle d'œuvre, mais l'intention politique donne une responsabilité en plus.

    Je suis d'accord avec le propos en plus c'est juste qu'il montre quelque chose qui est plus proche de du vaisseau de Wall-e que du monde actuel, il me semble.

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

  • [^] # Re: En informatique comme dans la "vrai" vie

    Posté par  . En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à 4.

    Sinon oui, l'originalité n'est pas un critère de sécurité, il ajoute à la sécurité.

    Ça peut être un critère de sécurité mais dans un approche différente. Tu peux vouloir avoir 2 implémentations différentes séquentielles (si elles sont en parallèle ça n'a pas de sens) pour éviter qu'une faille traverse tout.

    Ça peut vouloir dire utiliser un système différent dans la DMZ qu'ailleurs. Si quelqu'un arrive à entrer dans la DMZ il faudra qu'il abuse d'une autre faille pour entre dans le reste du réseau.

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

  • # HTTP ?

    Posté par  . En réponse à la dépêche Haiku a 19 ans. Évalué à 6.

    Haiku dispose d’une implémentation d’un client HTTP, mais celle-ci est complexe à utiliser et peu performante.

    Je ne comprends pas bien. Les OS exposent une API de socket plutôt qu'un protocole applicatif (il y a des fonctionnalité de plus haut niveau proposé comme la résolution de nom, mais c'est plus qu'un protocole). Là il est question d'API du noyau, d'une bibliothèque inclue de base, d'un utilitaire type curl ?

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

  • [^] # Re: Aie mes yeux...

    Posté par  . En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à 2.

    Je croyais que tu soutenais que c'était impossible de comparer des langages informatiques au niveau efficacité. Je sais que c'est complexe, mais pas impossible.

    Désolé je n'ai pas était très clair et même certains raccourcis font penser ça. Non c'est "juste" que le bench devrait être là pour appuyer une hypothèse ou être expliqué par une hypothèse.

    C'est véritablement compliqué de faire un bench et l'auteur de celui-ci a fait un travail (tester plusieurs compilateurs, donner une description de la machine sur le quel il a fait son test, donner les sources du test,…) mais ce n'est pas plus que de l'amusement perso (ce qui est très bien !).

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

  • [^] # Re: Critique du SMS en second facteur, pas du 2FA en tant que tel

    Posté par  . En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à 2.

    Je ne sais pas ce qu'il en est d'Apple, mais je trouve Google pas mal. Ils "auditent" ton téléphone pour te dire s'il n'a pas de verrouillage par exemple.

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

  • [^] # Re: Aie mes yeux...

    Posté par  . En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à 2.

    Donc à partir d'un point précis, tu pense que l'on peut faire une déduction sur des langages ? S'il n'y a pas d'hypothèses posée avant, alors ton hypothèse c'est le test. En quoi ce test là plutôt qu'un autre ? Quels sont ses propriétés ? Pourquoi choisir ses paramètres (surtout quand on ne les fais pas varier) ?

    Donc on prend 2 bout de code, dont rien indique l'effort qui a était fait pour qu'ils soient pertinents. On les a lancé et on a ni hypothèses initiales qui cherchée à être vérifiée, ni conclusion qui tentent d'expliquer les résultats.

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

  • # DĂ©terminisme

    Posté par  . En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à 5.

    il est contre les 'reproducible builds' car ça se contourne

    Je suis pas vraiment d'accord avec :

    Q. A reproducible build is a good quality build. Whether there are security benefits or not, I just want people to do it.

    Whether reproducible builds are better quality or not is a matter of opinion, and we shouldn’t be trying to force our opinions on others by claiming it’s for security.

    Un code déterministe est une qualité objective. On peut choisir que ce n'est pas la qualité la plus importante pour nous, mais c'est une qualité objective.

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

  • [^] # Re: Highway to dependency hell

    Posté par  . En réponse au journal DD: entre le marteau et l'enclume. Évalué à 2.

    ne surtout pas devoir recompiler chaque programme

    Pourquoi ? Parce que la machine de build est sous l'eau ? Ça je peux le comprendre mais par principe, sur changement d'une dépendance faire du rebuild n'est pas une mauvaise chose au contraire. Ils n'ont d'ailleurs pas le choix avec les programme go.

    Je comprends mieux la volonté de partager et c'est un choix, tu as le même avec toute dépendance quelque soit la techno1, est-ce que tu préfère optimiser pour chaque cas ou utiliser une solution réutilisable mais moins optimale.

    Mais en soit rebuilder les logiciels c'est tout de même pour ça qu'ils utilisent du logiciel libre et tu as des distributions qui font ce choix. On pense bien sûr à gentoo, mais elle n'est pas seule. Et tu peux très bien demander à ta gentoo de compiler en statique il me semble.

    C'est une décision qui a des impacts on est d'accord, mais une décision et pas une obligation.2

    Mais au final le jdk est probablement plus Ă  comparer aux runtimes de flatpak, c'est quelque chose qui arrive batteries inclues (qu'il ne faut pas comparer avec juste la libstdc++ ou gtk) et sa taille n'est plus si grande.


    1. si tu compile tes logiciels C++ en statique, tu va pouvoir bénéficier d'une élimination de code mort plus agressive. ↩

    2. après c'est un dogme d'ops (dont on a déjà beaucoup parlé ici) de vouloir changer les dépendances des logiciels sans repasser par les développeurs parce que de toute manière les développeurs ne comprennent rien aux problèmes des ops ↩

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

  • [^] # Re: Highway to dependency hell

    Posté par  . En réponse au journal DD: entre le marteau et l'enclume. Évalué à 3.

    Oui à savoir aussi pour ceux qui cherchent la perf que graalvm n'est pas forcément plus performant. Il démarre plus et à une empreinte mémoire plus faible, mais sur des charges qui créent/détruisent un certain nombre d'objets, le fait que le gc va se débrouiller pour compacter la mémoire peut devenir vraiment utile.

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

  • [^] # Re: Highway to dependency hell

    Posté par  . En réponse au journal DD: entre le marteau et l'enclume. Évalué à 3.

    graalvm c'est vraiment particulier. C'est presque un fork de java qui ne peux compiler qu'un sous-ensemble du langage.

    Par contre en standard, depuis java9 tu as la modularisation du jdk avec jlink tu peux créer un jdk sans les parties qui ne t'intéressent pas et c'est une étape que tu ne fais qu'une fois et si d'aventure tu change les module du jdk dont tu as besoin, mais ça ne devrait pas arriver tous les 4 matins.

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

  • [^] # Re: Aie mes yeux...

    Posté par  . En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à 3.

    C'est l’intérêt du benchmark game que chaque fan boy puisse développer pour son propre langage préféré.

    Il faut que le bench soit vraiment établi pour ça mais bon…

    Tu confirmes donc bien que si 2 personnes du même niveau d'expertise […]

    Non à l'état de l'art. Sinon tu risque de juste comparer la simplicité des langages.

    […] avec un minimum de complexité, on peut comparer la vitesse du langage

    Non, tu compare 2 implémentations données, sur une machine donnée, à un moment donné sur un test donné.

    Et attention ! Tu gagne 3.7s, on ne sait pas comment évolue cette valeur par rapport aux paramètres du test.

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

  • [^] # Re: Aie mes yeux...

    Posté par  . En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à 2.

    Quand tu es CPU bound, tu as une part de ta performance qui vient de ton algo (ne pas refaire des calcul n fois comme le décrit freem) et une autre part qui va être très pointue les différentes formes de parallélisation, la manipulation des registres, l'utilisation des extensions que te proposent ou non ton CPU,…

    Peut-on imaginer un algo numérique de l'ensemble des algo numériques qui soit 3x plus rapide dans un langage A par rapport à B, mais qui serait 2x plus lent pour tous les autres en moyenne ?

    Tu établi comment que tes algos sont au niveau à l'état de l'art ? Que cette implémentation du ray tracing ne tire pas particulièrement parti d'une opti qui est plus anodine généralement ? Même sans pointer une malfaçon, on tombe facilement dans les biais. Rien que l'expertise que tu as ou pas sur un langage et son écosystème peut avoir des conséquences (ne pas utiliser la bonne implémentation de ta structure de données par exemple).

    En plus là il n'est pas question de tel rapport de différence. Deux versions de compilateurs donnent plus de différence que ce qu'il y a entre nim et c++.

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

  • [^] # Re: Highway to dependency hell

    Posté par  . En réponse au journal DD: entre le marteau et l'enclume. Évalué à 4.

    Ne pas dépendre d'un énorme et gigantesque runtime et même d'un petit en fait. Bonnet d'âne: Java. Bon élève: ???

    Je me suis toujours dis que le JDK était gros puis, un jour, j'ai installé beam et son écosystème :)

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

  • [^] # Re: Aie mes yeux...

    Posté par  . En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à 2. Dernière modification le 03 août 2020 à 16:54.

    Si l'algorithme est le même entre 2 logiciels, on peut conclure que pour ce logiciel, le code est plus ou moins compact, rapide, expressif, etc…

    Ça c'est pas du bench :) La seconde partie de l'article est intéressante de ce point de vu à ce titre.

    Et pour la vitesse ça te dis que cette implémentation de l'algo dans tel langage est plus rapide que l'implémentation de l'autre. Si tu as besoin de cette implémentation de l'algo, ça doit être utile ^^

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

  • [^] # Re: rustines++

    Posté par  . En réponse au journal DD: entre le marteau et l'enclume. Évalué à 2. Dernière modification le 03 août 2020 à 16:19.

    Hé hé tu vois je ne l'avais même pas vu… Comme quoi

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

  • [^] # Re: business

    Posté par  . En réponse au journal DD: entre le marteau et l'enclume. Évalué à 4.

    Ça reste tout à fait minimaliste comme filtrage. En tout cas bien loin de ce qui est proposé plus haut.

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

  • [^] # Re: Aie mes yeux...

    Posté par  . En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à 3.

    Ah non ce n'est pas une question de complexité, mais d'information qu'il apporte. Si tu ne peux pas conclure mieux que « ce snippet de code est plus performant actuellement que celui-ci » alors l'effort ne t'apporte rien. Le plus difficile dans un benchmark ce n'est pas d'écrire du code, c'est de faire quelque chose de tes résultats, de pouvoir comprendre la différence et d'où elle vient.

    Pour voir quelque chose de bien fait c'est simple, on peut regarder les journaux sur pythran où c'est l'inverse ou tu peut regarder les bench du noyau où les dev prennent le noyau avec et sans leur feature et montrent l'impact du code qu'ils ont produit. C'est à ça que ça sert un bench. Les concours de phallus c'est de l'énergie perdu pour rien.

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

  • [^] # Re: Aie mes yeux...

    Posté par  . En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à 4.

    Quel est l'intérêt ? Un benchmark devrait être là pour répondre à une hypothèse.

    La démarche peut être de prendre le même algo est de l'écrire dans les 2 langages. Plus que les langages1 tu compare les compilateurs. Mais pour que ça ai un intérêt il faut ensuite faire le travail d'analyse des résultats (quels optimisations ont jouées dans un sens comme dans l'autre ?). Sinon ça n'apporte rien et tu ne pourra pas en déduire que l'un est plus performant que l'autre. Juste que dans un contexte donné, il est arrivé que l'un soit plus rapide que l'autre.

    C'est pour ça que ce genre de papier ne sont là que pour générer de la visibilité et tenter de créer une hype.


    1. pas totalement vrai car selon la sémantique des langages il est possible pour le compilateur d'émettre certaines hypothèses ou pas ↩

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

  • [^] # Re: rustines++

    Posté par  . En réponse au journal DD: entre le marteau et l'enclume. Évalué à 2.

    "T extends {}" est littéralement le code TypeScript à utiliser

    C'est probablement moi, j'ai tendance à vocaliser ce que je lis et c'est un mot sur le quel je butte. Je sais que c'est un mot clef du langage, mais ce n'est pas un bout de code que tu as donné ce mot clef est un verbe de ta phrase.

    "example" est le nom du paramètre choisi par le développeur initial

    D'acc je comprends mieux et je suis tout Ă  fait d'accord.

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