barmic 🦦 a écrit 5976 commentaires

  • [^] # Re: Smartwatch

    Posté par  . En réponse au lien En Espagne, “Adolescence sans mobile” un mouvement spontané et suivi. Évalué à 2.

    Bon, déjà on peut faire les 2 : militer pour le changement et en même temps constater qu'en l'état actuel, la voiture est un besoin.

    Elle est un besoin parce qu'on a accepté qu'elle le devienne. On a organisé nos vie avec comme hypothèse qu'elle sera là tout le temps, que c'est un droit opposable, que c'est une ressource minimale que l'État doit nous garantir,… Et je dis ça sans blâmer parce que c'est une volonté politique depuis plusieurs décennies et on vit le résultat de plusieurs générations qui nous précédent.

    Néanmoins il ne faut pas s'attendre à faire la transition sans changement sur nos vies. Donc attendre que le système ai mis en place des solutions qui permettraient de faire exactement la même chose. De plus le politique a aussi pour fonction d'accompagner. L'évolution des pratiques se fait en même temps que celle des infrastructures.

    Mais 3 dernières choses :

    • si tu remonte dans les annĂ©es 50-60 tu verra qu'on Ă©tait dĂ©jĂ  avant le monde de la voiture reine. Je ne sais pas Ă  quelle point le changement climatique vous impact, mais il n'y a qu'une ou deux gĂ©nĂ©rations qui a connu ce tout voiture
    • je ne sais pas ce qu'il en est, mais il ne faut pas non plus tomber dans le principe des Émirats, il y a des zones oĂą il n'est pas possible de vivre de manière Ă©cologique du moins pas avec la qualitĂ© de vie qu'on connaĂ®t aujourd'hui. Avoir imaginĂ© que l'on pouvait coloniser ces lieux en ignorant leur rĂ©alitĂ© climatique Ă©tait une erreur
    • pour la question des 50km en 2h, je dirais que c'est surtout de le faire quand tu le veux s'organiser pour prendre le transport en commun et que ce dernier soit rapide ne me semble pas impossible. La situation des transports en commun que tu dĂ©cris n'existe que parce que la voiture l'a rendu acceptable, si vos dĂ©penses de voiture Ă©tait collectivisĂ©es il serait sans doute possible de faire mieux, dĂ©jĂ  on pourrait faire tomber en semaines l'arrivĂ©e des car, on peut imaginer des tĂ©lĂ©phĂ©riques, des trains Ă  crĂ©maillère et d'autres

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

  • [^] # Re: Et donc…

    Posté par  . En réponse au lien Git Koans. Évalué à 2.

    Évidemment, mais d’expérience ce point pose moins de problème qu’une branche. J’ai rarement croisé des gens qui avaient du mal à comprendre ce qu’est un commit Git ; par contre, des gens qui sont persuadés que « Une branche c’est un historique linéaire de commits » (ou quelque chose d’approchant), c’est extrêmement fréquent.

    Je pense qu'il est extrêmement fréquent de ne pas comprendre que les parents d'un commit fait parti de son identité et qu'un cherry-pick par exemple, c'est un nouveau commit qui n'a aucune relation avec sa copie d'origine au sens de l'arbre d'objet git.

    Pour le reste, à partir du moment où tu en es à « capitaliser sur ta connaissance de ZSH », tu n’est probablement pas dans la cible du billet.

    C'est un peu le problème. git n'a pas était conçu pour être un gestionnaire de version simple à poser dans toutes les mains, mais un outils qui ne fait pas de concession pour la performance et taillé pour un projet précis. mercurial (que je préfère à git) est déjà un peu plus fait pour le tout venant même si je ne suis pas convaincu qu'un DCVS soit la panacée en soit. La gestion de version par les outils de traitement de texte bien que triviaux sont déjà une gageure pour beaucoup et j'ai l'impression que les outils qui s'en sortent le mieux pour ça sont ceux qui sauvegardent tout le temps et te permettent de revenir dans le temps de manière uniquement temporel (ils ne répondent qu'à des demandes de la forme "montre moi mes fichiers il y a 3h").

    Utiliser une GUI permet de mieux comprendre fonctionnellement Git, ce qu’il fait, pourquoi, et donc de l’utiliser efficacement – même si ça demande de sortir un autre outil comme la CLI pour arriver à cette fin.

    Les meilleurs outils pour voir ce que fait git que j'ai pu voir était des outils d'apprentissage où tu a l'écran divisé en 2 et ou tu vois en temps réel (par un rafraichissement régulier d'une vue) ce qui se passe dans ton graphe au fur et à mesure que tu lance des commandes et où tu peux revenir en arrière de manière instantanée et fiable via un bouton "back".

    Après ça vient peut être d'avoir un esprit bottom-up ou top-down, mais ça me demande un effort considérable pour aller plus loin que ce qu'une GUI me propose.

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

  • [^] # Re: Et donc…

    Posté par  . En réponse au lien Git Koans. Évalué à 3.

    Désolé, j'ai ri: prendre cette commande vieille d'au moins 11 ans comme exemple de nouveauté…

    C'est surtout une réécriture du commentaire pour laquelle j'ai pas bien relu. Initialement l'exemple était pour une fonctionnalité que je n'ai jamais vu ailleurs que dans l'outil de base. Mais au delà de ta condescendance, il m'arrive d'apprendre récemment des choses de git qui pourtant existent depuis probablement l'origine. D'ailleurs je ne connais pas l'option --onto de rebase depuis si longtemps que ça, je l'ai découvert dans une release note il y a quelques années.

    Et les GUIs peuvent aussi permettre de découvrir certaines fonctionnalités d'un outil qui sinon resteraient cachés dans une donc ou un changelog qu'on ira jamais lire (pour diverses raisons. Une pouvant être qu'on la maîtrise suffisamment).

    D’expérience j'ai l'impression que les interfaces ont tendance à cacher au contraire les fonctionnalités et que ça demande bien beaucoup plus d'effort pour aller au delà de ce qui est considéré comme le case d'utilisation principal à la conception de l'interface.

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

  • [^] # Re: Et donc…

    Posté par  . En réponse au lien Git Koans. Évalué à 9.

    Quand à la question « comment savoir sure quelle branches je suis ? » quelqu'un te répond git rev-parse --abbrev-ref HEAD, tu n'a pas en face de toi un maitre de git, mais un connard. git branch, git status, git show HEAD, git log,… te donnent l'information de manière naturelle.

    Et aussi retenez qu’une branche ou un tag, c’est juste une étiquette sur un commit, […]

    Un commit est un diff + une référence sur son ou ses parents.

    Ensuite il y a quelques commandes à connaître pour manipuler le graphe de commit. Pour commencer uniquement : commit, cherry-pick, rebase, merge, branch (et pas leurs usages avancés !). Puis au fur et à mesure de l’expérience étoffer avec les usages plus complexes de ses commandes, des rebases interactifs voir du reflog.

    Utilisez une GUI !

    Personnellement l'utilisation de la CLI me permet de capitaliser sur ma connaissance de zsh, j'ai immédiatement accès aux nouveautés de git (comme rebase --onto), je n'ai pas d'opération qui de manière aléatoire prennent du temps (changer le label d'un commit précédent par exemple si tu le fais en CLI tu sais pourquoi ça n'est pas instantanné si tu le fais dans intellij tu cris sur l'outil comme quoi il est bugué), je ne suis pas en environnement inconnu quand je m'en sert sur des machines qui n'ont pas d'écran (serveur pour gérer de la configuration ou rpi pour configuration ou compilation locale), je peux faire des manipulations avec le niveau de rafinement que je veux avec les raccourcis et des scripts.

    Les gens utilisent bien ce qu'ils veulent (je n'aimerais pas qu'on me dise quoi utiliser donc je ne vais pas le faire), mais quand tu utilise de manière un minimum régulière un outil, je trouve dommage de passer à côté de ce que peut faire la CLI pour avoir une marche initiale plus simple, mais avoir au final pas mal de complexité derrière (parce qu'on ne profite pas des améliorations de l'outils, parce que c'est souvent bien moins documenté parce que faire quelque chose qui n'a pas était prévu par l'outil peut devenir une gageur quand c'est possible)

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

  • [^] # Re: caractĂ©ristiques d'un langage qui dure

    Posté par  . En réponse au lien Hare : un langage pour les 100 ans à venir. Évalué à 2.

    Idem l'affirmation inverse ne tient que sur ton avis.

    Non c'est étayé n'hésite pas à relire les commentaires plus haut et à répondre sur les points précis et vérifiable. Ce sera toujours mieux que d'envoyer une satire pour ensuite s'offusquer des réactions que ça produit.

    On part quand même de toi qui soutient que dire que Awk est un GPL est du même niveau que dire que les pyramides ont été construites par des extra-terrestre et moi qui dit que l'une et l'autre des hypothèses sont semblable.

    Non tu te perds dans la conversation. C'est affirmer que go est un DSL du cloud de Google que je trouve être du niveaux d'une théorie illuminati. Encore une fois je vois pas en quoi ce point de vu t'énerve, tu dis toi même que c'était une satire. Donc tu l'a dit pour te moquer, je t'ai répondu que c'était n'importe quoi et tu t'emporte parce que j'ai réagit à ta moquerie ?

    Ta véhémence semble aller de paire avec l'absence d'éléments concrets.

    Des enfantillages pour tenter de m'énerver ? Ce n'est pas parce que tu t'émeus en lisant à moitié ce que les gens te répondre que je vais en faire autant.

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

  • [^] # Re: caractĂ©ristiques d'un langage qui dure

    Posté par  . En réponse au lien Hare : un langage pour les 100 ans à venir. Évalué à 2.

    un gars a écrit un doom like en awk

    Ça montre qu'il est Turing complet ce que personne n'a démenti. Est-ce pour autant une pratique en dehors d'une démonstration ?

    MĂŞme si mon commentaire sur Go tient plus de la satire,

    Attends tu présente ton argument comme une satire et tu trouve injurieux que je dise que c'est n'importe quoi ?

    il est du mĂŞme acabit que ta comparaison avec CSS (qui plus est fausse).

    Que CSS est Turing complete ? Ça n'est vraiment pas dur à vérifier.

    Dire que AWK est un GPL est tout aussi valable que de dire que c'est un DSL donc c'est avant tout une question de point de vue et c'est le mien.

    C'est une affirmation qui ne tiens que sur ton avis (et sur le fait qu'il est turing complete comme l'est SQL, le langage de template de C++, CSS, le format des string de printf).

    J'ai aucun problème à ce que tu ne soit pas d'accord avec moi, mais ta véhémence semble aller de paire avec l'absence d'éléments concrets.

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

  • [^] # Re: caractĂ©ristiques d'un langage qui dure

    Posté par  . En réponse au lien Hare : un langage pour les 100 ans à venir. Évalué à 1.

    Tu as décrété que AWK était un DSL.

    J'ai donné des éléments concrets indiquant qu'il n'est probablement pas un langage à part entière. On peut ne pas être d'accord, mais je peux réfuter une affirmation qui n'est elle corroboré par rien de concret et qui n'essaie même pas de l'être. Le fait qu'une définition soit floue ne veut pas dire que tout est possible. Quand les historiens expliquent ne pas pouvoir affirmer comment a était fabriqué une construction ça ne permet pas de présenter une hypothèse extraterrestre comme équiprobable avec leurs hypothèses.

    Enfin je tiens à préciser que je n'ai insulté personne en aucune manière.

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

  • [^] # Re: GUI alternative simple ?

    Posté par  . En réponse au lien Is this radical redesign of GIMP possible now?. Évalué à 2.

    Chez moi il se lance énormément plus vite qu'un firefox par exemple. J'ai peut être un biais avec une machine particulièrement rapide, mais globalement contrairement à intellij gimp ne fait rien de lui même, il ne scrute pas le disque pour détecter des modifications en lançant différentes tâches plus ou moins en arrière plan. Gimp au démarrage semble, je crois avoir lu un chargement de quelque chose babl (mais j'avoue ne pas avoir le temps de lire…), il serait peut être possible d'alléger encore ces chargements (les charger une fois puis dump sur disque le résultat et repartir de mmap de ce dump ensuite par exemple).

    C'est un travail qui peut se faire indépendamment d'un mode simplifié et qui bénéficie aux 2 modes. Pour la suite gimp ne fait que ce que tu lui demande.

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

  • [^] # Re: GUI alternative simple ?

    Posté par  . En réponse au lien Is this radical redesign of GIMP possible now?. Évalué à 4.

    Pour moi c’est juste que dans ce cas, Gimp n’est pas l’outil adapté.

    Il n'est pas adapté parce que son interface est un peu trop complexe ? Un peu la simplifier ou avoir 2 interfaces peuvent probablement résoudre le problème plus facilement que de créer un nouveau logiciel.

    Après il me semble que la distinction entre « créer un nouveau logiciel » et « créer une nouvelle interface  » devrait complètement se recouper avec gimp 3 et l'arrivée de GEGL si j'ai bien compris.

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

  • [^] # Re: caractĂ©ristiques d'un langage qui dure

    Posté par  . En réponse au lien Hare : un langage pour les 100 ans à venir. Évalué à 1.

    Il n'y a pas grand chose de factuel pour l'étayer. Par exemple tu va avoir du mal à trouver des usages awk hors d'unix et sans binutils là où il n'y a qu'à s'y intéresser pour trouver même pas simplement des programmes, mais des communautés entières indépendantes de ce contexte (comme son utilisation sur RaspberryPI par exemple).

    Le « soupçon de mauvaise foi » ne permet pas de raconter n'importe quoi non plus.

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

  • [^] # Re: LSD

    Posté par  . En réponse au lien DOS Subsystem for Linux: allowing users to make use of both DOS and Linux applications from DOS. Évalué à 2.

    A quand un Linux Subsystem for Dos? :D

    C'est exactement ça.

    Linux subsystem for Windows, ça s'appelle Wine.

    Wine ce serait Windows subsystem for Linux

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

  • [^] # Re: Questions de redondance

    Posté par  . En réponse au lien DOS Subsystem for Linux: allowing users to make use of both DOS and Linux applications from DOS. Évalué à 4.

    La description me paraît limpide pourtant. Ça permet d'utiliser linux quand tu es sur DOS

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

  • [^] # Re: caractĂ©ristiques d'un langage qui dure

    Posté par  . En réponse au lien Hare : un langage pour les 100 ans à venir. Évalué à 3.

    Awk a plus était pensé comme faisant partie d'un ensemble avec les binutils que comme un langage permettant de construire des programmes à part entière. Pour qu'il soit turing complet, il faut prendre soin de ne pas l'utiliser comme le man l'indique. Au passage un dsl peu très bien être turing complet. C'est le cas de CSS par exemple.

    Awk étant décrit dans le même standard et conçu pour fonctionner avec ne devrait pas être séparé de ses petits copains. C'est la programmation shell POSIX dont il est question.

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

  • [^] # Re: SimplicitĂ©?

    Posté par  . En réponse à la dépêche L’installation et la distribution de paquets Python (1/4). Évalué à 3.

    Le C est vraiment simplissime comparé à python niveau syntaxe,

    Au niveau de la syntaxe c'est faux. Le duff device est un exemple de comment on peut tordre la syntaxe du C, python est plutôt aride et n'a même pas d'opérateur ternaire par exemple. Python ne peux pas écrire d'affectation à la place d'une condition pas exemple. Techniquement le concours d'offusquation est bien moins drôle en python.

    La sémantique de python est plus complexe par contre. Il peu se passer beaucoup de choses pour une ligne de code donnée.

    Par contre le lien perdu avec la donnée à traiter peut rendre les choses peu évidentes en python même dans de l'applicatif à mon sens.

    Tu parle de fuite mémoire ?

    Puis si l'auteur de la dite librairie abandonne sa maintenance,

    Ça existe aussi en C. Par contre en C tu n'est pas outillé pour décrire tes dépendances et donc les faire évoluer. C'est souvent au petit bonheur la chance si l'ABI des dépendances est stable ou non.

    (cf passage de python 2 Ă  3)

    Reprocher ça a python c'est un peu comme reprocher les nombres à virgule flottantes IEEE 754-1985 de C99. Ça a beaucoup fait parler mais ce n'est un sujet de problème pour personne au quotidien.

    et on se retrouve à devoir maintenir des dizaines de milliers de lignes de code plus maintenu écrit par d'autres, refaire la partie que l'on utilisait from scratch voir continuer les cochonneries avec un wrapper sur une lib alternative maintenue (pour combien de temps?)…

    Tu crois sincèrement que le langage serait aussi populaire si c'était un cas un minimum régulier ?

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

  • [^] # Re: caractĂ©ristiques d'un langage qui dure

    Posté par  . En réponse au lien Hare : un langage pour les 100 ans à venir. Évalué à 2.

    Python commence Ă  avoir des concurrents

    Il en a toujours eu Perl est arrivé 4 ans avant, ruby 4 ans après. Basic était là. Il y a lua qui est arrivé à la même période.

    Il me semble que le langage récent qui a le plus séduit de pythoniste c'c'est go. Justement pour ne pas avoir besoin de cette dépêche.

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

  • [^] # Re: Ils veulent aussi pĂ©ter SSL Ă  la chinoise...

    Posté par  . En réponse au journal La carte d'identité européenne eIDAS bientôt requise pour utiliser les grandes plateformes?. Évalué à 1.

    SSL n'a pas attendu l'UE pour être pété.

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

  • [^] # Re: Le monde change !

    Posté par  . En réponse au lien Mon premier kit de télétravail (via TechTrash). Évalué à 6.

    Le problème c'est l'enfant qui imite ou le parent qui est en détresse ?

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

  • [^] # Re: Lisp voire Forth voire C

    Posté par  . En réponse au lien Hare : un langage pour les 100 ans à venir. Évalué à 4.

    Ça a pas trop bougé et ça a peu de chance de bouger même si ce sont surtout des dialectes qui sont pratiqués (Clojure, CLISP).

    Je considère pas lisp comme un langage mais comme une famille de langages personnellement, comme le BASIC par exemple. C'est difficile d'en parler comme un seul langage quand il n'y a pas d'interroperabilité (tu ne prend pas un bout de code écrit en clojure dans emacs, pas sans les mêmes carabistouilles que pour appeler du python).

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

  • [^] # Re: Le monde change !

    Posté par  . En réponse au lien Mon premier kit de télétravail (via TechTrash). Évalué à 4.

    Faut tout de même rappeler que ce n'est que le reflet des parents pour le coup. Les enfants n'ont par exemple pas attendu que l'industrie se mette à la page pour prendre les télécommande ou tout autre objet qui y ressemble et téléphoner comme leur parents le font.

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

  • [^] # Re: caractĂ©ristiques d'un langage qui dure

    Posté par  . En réponse au lien Hare : un langage pour les 100 ans à venir. Évalué à 5.

    Pour illustrer les langages immortels on peut prendre C, Cobol et mĂŞme Pascal ou Vhdl.
    À l'inverse si on prends Awk et bien d'autres que je ne connais point ils ont disparu (ou pratiquement).

    Tu vois c'est vachement lié à la perception parce que Cobol et Awk de mon point de vu c'est bonnet blanc et blanc bonnet. L'un survie dans quelques vieux trucs et l'autre fait simplement parti de POSIX. Est-ce que Cobol (le quel ?) est vraiment considéré pour des projets qui démarrent from scratch aujourd'hui ?

    Si l'ambition en tant que langage c'est de devenir un dette technique insurmontable je suis pas sûr que ce soit enviable.

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

  • # Bof

    Posté par  . En réponse au lien Hare : un langage pour les 100 ans à venir. Évalué à 9.

    Je ne sais pas ce qui excite avec Drew DeVault, mais là c'est assez succinct. Il veut être aussi populaire que le C sur au moins une aussi longue période. C'est pas comme si d'autres n'avaient pas essayé, mais bon. Et il dit qu'il va être conservateur plus toucher à rien etc… Soit.

    Il n'exprime pas l'objectif être comme machin n'est pas un objectif pourquoi être un langage de 100 ans et qu'est-ce que c'est qu'être un langage de 100 ans. S'il reste 3 développeurs qui codent de temps en temps sur un logiciel d'une station dans le désert de Gobi c'est réussi ?

    Surtout il n'analyse pas la réussite de son exemple qui :

    • Ă©tait très innovant Ă  sa sortie
    • a Ă©voluĂ© avec le temps
    • est arrivĂ© avec et pour un OS novateur et Ă  succès
    • …

    Bref il fait beaucoup de choix contraire à son exemple et espère avoir le même résultat et ne dit pas quel problème cherche t'il a résoudre.

    À part pour faire parler je ne vois aucun intérêt

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

  • [^] # Re: merci et venv

    Posté par  . En réponse à la dépêche L’installation et la distribution de paquets Python (1/4). Évalué à 3.

    Je ne sais pas comment tu travail, mais si tu utilise TOUJOURS ton shell peut être que direnv permet d'être plus rigoureux : quand tu va dans ton dossier tu as automatiquement les variables d'environnement qui vont bien ?

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

  • [^] # Re: merci et venv

    Posté par  . En réponse à la dépêche L’installation et la distribution de paquets Python (1/4). Évalué à 2.

    Ça n'est pas lié à docker. Quand le principe c'est d'utiliser des environnements différents que tu les cloisonne à base de variables d'environnement + liens symboliques, chroot, pyenv, de docker, de machines virtuelles, d'environnement nix,… on est presque dans du détail par rapport au besoin initial.

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

  • [^] # Re: avis partial

    Posté par  . En réponse au lien «En français, le masculin fait l’homme, le dominant, il ne “fait pas le neutre”» (article partiel). Évalué à 6.

    Un peu comme si pour un auteur noir il fallait dire "auteur noir" pour bien le distinguer.

    Le français n'a pas prévu de genre pour la couleur de peau, mais il prévoit qu'on parle d'une femme avec le pronom "elle" et d'un homme avec "il". C'est pour ça que les 2 ne sont pas comparables.

    On devrait peut-être arrêter d'avoir des genres en français pour arrêter d'être misogyne ou ségrégationniste ?

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

  • [^] # Re: Le point le plus important selon moi (et qui n'est hĂ©las prĂ©sent dans aucune solution libre)

    Posté par  . En réponse au lien Pourquoi sommes-nous tellement accros à Google Maps et Waze ?. Évalué à 0.

    Où ai-je employé les mots « scientifique » et « irrationnelles » ?

    Tu parle de preuves en refusant son expérience parce qu'elle ne constitue pas une preuve selon toi en lui reprochant son manque de rigueur. Vous parlez évidemment de démarche scientifique même sans utiliser le mot. Pour ce qui est d'irritationnelle c'est un synonyme d'absurde.

    Où ai-je fait état de dédain ?

    En présentant cela comme absurde qui est péjoratif en soit et en présentant comme normal le fait que ça face l'objet de moquerie.

    En rappelant l’évidence qu’un ressenti n’est que cela et ne peut pas être transformé en fait vérifié ?

    Et il en donne une avec la mesure de ses temps de trajet, mais ça n'a pas l'air de suffire.

    Tu confonds vérifier et conforter son impression. Tu instrumentalises des mesures isolées et non comparables : Il se trouve que j’ai eu à faire l’expérience & justement je refuse le culte du cargo !

    Voilà la démarche n'est pas scientifique selon toi. Tu demande une expérience scientifique que personne ne fait dans son quotidien et refusant le fait qu'avec une observation tu peux déjà formuler des hypothèses. Il n'a peut être pas éliminer toutes variable une par une et n'a pas recherché de variable cachées mais qui fais ça dans son quotidien ? Quand j'ai froid je met un pull est-ce que le pull me donne plus chaud, est-ce que c'est l'action de mettre un vêtement qui me donne l'impression, est-ce que c'est la sensation d'avoir une couche en plus qui me fais croire que je suis au chaud ? La majorité des gens sur Terre s'en foutent et n'en ont pas besoin pour mettre un pull.

    Voilà quelque chose proche d’une expérience en double aveugle où le détour n’a pas été profitable

    En quoi c'est répliquable à tous ? C'est loin d'être rigoureux. Je connais des gens qui se perdent avec une carte IGN et d'autres qui savent s'orienter via les azimuts, est-ce que ça veut dire que les cartes ne servent à rien ? Strash ne dit pas que quiconque utilise un GPS gagne 15 à 20 minutes. Il dit que lui ça lui fait gagner 15 à 20 minutes et donc probablement à d'autres.

    S’il ne devait se fier qu’à sa mesure sans pouvoir vérifier/comparer il pourrait affirmer qu’il a gagné vingt minutes alors qu’au final on a mis le même temps.

    Ton trajet quotidien tu en connais la durée moyenne, minimum, maximum et l'écart type même intuitivement, tu sais quand tu dois partir pour ne pas être en retard. Donc tu peux observer des temps qui sortent de l'ordinaire. Ça peut être un coup de chance, le trafic de ce jour là qui est particulier, mais si tu réplique suffisamment de fois faut se rendre à l'évidence : c'est que le conducteur un moins bon que le GPS pour choisir un chemin.

    on ne peut pas affirmer doctement que les itinéraires alternatifs font automatiquement gagner du temps.

    Qui l'a affirmé ?

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