barmic 🦦 a écrit 5211 commentaires

je ne leur jete pas trop la pierre, si c'est une boite privée qui l'avais pondu, ca aurait couté plus chère ET ca ne fonctionnerais pas.

Bien sûr on montre les exemples qui marchent le moins, mais les logiciels de l'état ne se limite pas à quelques exemples comme louvois. service-public.fr et ces prédécesseurs fonctionnent bien par exemple.

peut etre faire un logiciel libre sur gitlab avec des domaines attribué au université informatique/ministère + les contributeurs bénévole, un peu comme linux.

1. ce serait bien de rétribuer les développeurs seul l'état en a un intérêt donc ça se rapprocherait beaucoup de l'existant
2. c'est quoi le modèle de gouvernance du projet ? il peut y avoir des pressions fortes de la part de contributeurs pour pousser des idées dans le code (ça existe potentiellement déjà, mais c'est exacerbé en acceptant des contributions extérieures)

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

Du point de vu dev oui, c'est la stack de déploiement qui me donne l'impression de se chercher. Éventuellement la configuration (ce qui est fait avec helm ou kustomize par exemple). L'état de l'art de la manière d'empiler orchestrateur + runtime + dépôt + configurateur évolue évolue pas mal (je dis pas qu'il n'a pas à évoluer, je dis que se tenir à jour demande un travail conséquent et une compréhension relativement approfondie). Et il faut séparer les annonces des réalités, beaucoup d'entreprises font des annonces ou des gens publient des articles, mais sans forcément qu'il y ai quelque chose derrière ou que ça prenne (kubernetes pour des machines virtuelles, il y a plus de gens qui en parlent que de gens qui en utilisent par exemple, IBM annonce des fois des outils pour orchestrer des orchestrateurs,…).

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

swarm en prod

On utilisait ça pendant pas mal de temps, le passage à un orchestrateur plus complet est assez salvateur. En tout cas quand tu déploie sur plusieurs machines. Rien que la répartition des instances sur les serveurs n'est pas folles avec swarm. Le passage à docker stack ou une alternative, ça demande un effort de s'y mettre mais le retour sur investissement et plutôt pas mal je trouve.

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

Pour en ajouter une couche :)

Le paradigme "tout est fichier" commun aux unix est une base sur la quelle les différents unix ce sont construit.

La base c'est de considérer toutes les entrées/sorties des programmes comme des fichiers (donc la sortie standard aussi, les pipes, les sockets,…).

Du coup je suis allé vérifier les pseudo systèmes de fichiers sont apparu dans unix himself et là il s'agit d’interagir avec un programme au travers d'un système de fichier. On utilise le fait de voir des dossiers/fichiers et lire le contenu d'un fichier comme les sorties d'un programme et le déplacement dans un dossier, la création de dossier/fichier et l'écriture dans un fichier comme les entrées du programme.

L'intérêt est évident pour les programme qui ne peuvent que difficilement avoir des interfaces comme le noyau, mais c'est aussi très intéressant car les gestionnaires de fichiers et éditeur de texte peuvent naturellement interagir avec ce type de programme.

Sur linux tu trouvera 3 pseudo systèmes de fichiers classiques : udev (monté sur /dev et qui représente le hardware de la machine), procfs (monté sur /proc qui représente tous les processus de la machine (c'est une mine d'or d'aller s'y balader quand on ne connait pas)) et cgroup de plus en plus qui représente des limitations et quotas données aux processus. Mais fuse en possède pleins pour faire pleins de choses rigolotes : liste de filesystem de fuse.

Dernier point hurd avait un concept de translator pour faire ça qui a l'air plutôt cool.

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

Tu n'a même pas forcément besoin de remplaçant tu peut juste utiliser containerd si tu le souhaite (ça évite d'avoir le deamon docker que certains n'aiment pas).

J'ai l'impression que l'écosystème docker/k8s n'est pas encore arrivé à son niveau de maturité pour être stable (dans le sens ne pas changer l'état de l'art architectural tous les 2~3 ans).

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

C’est un problème qui s’apparente au problème des mariages stables qui s’attaque relativement bien vu comme un problème de satisfaction de contraintes, donc dans un cadre ensembliste.

Pour ceux qui préfèrent une vidéo explicative il y en a une sympa sur la chaine de ScienceEtonnante (j'ai découvert en recherchant cette vidéo, qu'il y a un mouvement de vidéos « réaction aux résultats ParcourtSup' »)

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

Les ERP utilisent pas mal de requêtes complexes comme les requêtes OLAP. Je n'ai pas rencontré d'ORM qui savaient en faire.

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

Le jour ou tu dois ajouter un champs ou gérer une liaison supplémentaire tu comprends très vite que d'avoir des INSERT en dur c'est une très grosse connerie.

Tu peut avoir des problèmes similaire avec des données structurée. Si ta modification est simple et qu'il s'agit d'ajouter une colonne ou une liaison sur du SQL correctement formaté ça n'est pas très compliqué à faire. C'est moins souple, moins performant, etc

En plus ça peut être tout à fait être ce que tu dis sauf qu'ils n'ont pas intégré l'outil à leur build pour de bonnes ou de mauvaises raisons même si c'est une bonne pratique qu'il soit intégré.

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

Ça ne va pas de poser des problèmes pour la relecture ?

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

J’espère qu'il y a des droits plus fin, genre --allow-net:domain.net

Tu gère comment la transitivité ? Tu as une bibliothèque sur un domaine A qui tire une dépendance sur le domaine B (et pour le fun dans la version suivante cette dernière passer sur le domaine C ou A).

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

Je suis entièrement d'accord avec toi sur ce point.

Donc pourquoi être aussi catégorique au dessus pour dire qu'il faut proposer un SGBDR uniquement et que ça n'a pas de sens de parler des NoSQL?

Mais comment sais-tu comment je travaille ? Tu proposes MongoDB en remplacement de MySQL, je te dis que proposer une BD NoSQL pour remplacer un SGBD ne marche pas à tous les coups et que cela dépend fortement des cas d'usage (besoins !), et tu es capable de me dire l'âge du capitaine ? Niveau "supposition", je pense que tu fais fort !

Tu t'es lancé dans une tirade avant même d'avoir véritablement lu mon premier commentaire. J'ai bien dis que ça dépendait des cas. Je l'ai dis clairement dès mon premier commentaire. Tu t'es lancé dans un long commentaire pour t'en offusquer sans chercher à comprendre ma phrase. Ce genre de réaction donne forcément des impressions.

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

Je critique aussi ton choix de proposer MongoDB en tant que remplacement pour MySQL car ils ne répondent pas au même besoin. Mais à aucun moment, je n'ai dénigré (pour reprendre tes propos) MongoDB.

Ce n'est pas comme ça que je travaille. Le besoin pour moi lorsque l'on construit un logiciel ce n'est pas "avoir une base de données SQL" (sauf bien sûr dans des certains contexte), mais "j'ai besoin de stocker de la donnée" et il y a une pluralité de réponse à cette question. Quand on se pose la question de cette façon sans présupposé sur la réponse technique, on ne segmente pas autant que ce que tu semble faire. Et moins on a de contraintes plus le champs des possibles est ouvert. Au contraire que plus tu as de contrainte moins tu aura de solution.

Pg et mongo sont pour moi les 2 bases qui sont les meilleures solutions quand tu es peu contraint. Ils ballaient un très large champs de besoin fonctionnel. Pg allant jusqu'à marcher sur les platebandes de ce qu'on appellerait NoSQL (le type json n'est pas 3NF) et mongo allant lui aussi taquiner des choses que l'on trouve d'habitude chez les SQL (avec des transactions).

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

Dès lors, proposer l'un pour l'autre sans connaitre le contexte d'utilisation derrière est juste… impossible.

L'objet de mon premier commentaire c'est que d'après ce que tu dis MySQL a du mal avec les propriétés ACID en particulier avec la durabilité. Il est donc logique de commencer à regarder du coté des bases qui sans se venter d'être ACID cherchent à s'en rapprocher. Mais surtout, dès le départ j'ai dis explicitement que ce n'était pas une règle générale.

Je vais le dire plus simplement du coup. Je en dis pas :

Mongo déboite MySQL

mais

Vu les souci que semble avec MySQL, Mongo est un concurrent serieux dans certains contexte.

J'ai bien indiqué dès le début que ça dépendait des cas.

Je suis désolé, mais s'adresser à des développeurs en les nommant "programmateur", c'est une énorme erreur qui peut faire perdre toute crédibilité (à noter qu'ici, le problème est uniquement dans la traduction française, mais j'ai trouvé ça "coquet").

Pointer ça tout en faisant une grosse faute de français est au moins aussi "coquet".

Ce que je comprends, c'est que le modèle "rangées et colonnes" est dépassé (et donc, de facto le modèle des SGBD) mais NOUS nous avons la solution ultime. Ben je suis désolé, c'est des conneries de "markéteux".

Il indique clairement que c'est leur point de vu. Les gens croient en leur projet c'est normal. Leur faire un procès d'intention pour cela c'est très dommageable. Regarde pijul tu peux difficilement les taxer de "markéteux", c'est juste leur point de vu. Tout point de vu est critiquable. C'est dommage de placer ça juste pour dénigrer. D'autant que leur job c'est de faire cette base, qu'ils croient une chose ou une autre sur les autres systèmes de stockage n'est pas très important par rapport au travail qu'ils font.

Je n'ai aucune raison de "baver" sur MongoDB. Tu noteras d'ailleurs que je n'ai rien dit du point de vue technique,[…]

Quel est l’objectif de les dénigrer du coup ?

[…] car, à ma connaissance, c'est une bonne techno (pas eu l'occasion de l'employer jusqu'à présent sur des projets, mais les retours que j'en ai sont plus que positifs).

Ouai il a tout de même un paquet de défauts quand tu le pousse un peu.

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

Ouai, je ne connais pas très bien MySQL, mais avec ce genre de descriptions, j'ai l'impression qu'un mongodb est probablement plus pertinent dans la plupart des cas.

Attention, les deux ne répondent pas aux mêmes besoins ! L'un est un SGBD (enfin prétend l'être, troll inside xD), l'autre est de la mouvance NoSQL (orienté document).

C'est une dichotomie, mais il y en a d'autres. Grosso modo l'impression que me donne ton commentaire c'est : quand tu as peu de contraintes MySQL peut faire le job, mais dans ce genre de cas ça peut être intéressant d'élargir son spectre. Et d'aller voir potentiellement vers ce qui n'est pas du SQL ou d'autres bases SQL.

En particulier une base de données qui est sujette à corruption des données comme le semble l'indiquer ton commentaire. Même si je me doute que c'est des cas rares pathologiques etc. Ça baisse fortement les chances que je me tourne vers elle :)

Mongo est une base extrêmement flexible qui supporte des transactions. Il est très agréable à utiliser. Ce qui va le distinguer de MySQL ça va être le fait qu'il est sans schéma. Mais si ton taff c'est d'utiliser un ORM et de pas faire de requêtes trop complexes, ce qui me semble être le cas d'usage que tu dépeins. Il peut être une très bonne alternative.

Ce qu'il ne faut pas lire :/ Tout dépend des usages ! Mais bon, la je disgresse xD

Je te trouve très rude.

1. C'est assez ironique de leur reprocher leur vocabulaire pour développeur dans une phrase dans la quelle tu utilise un verbe qui n'existe pas…
2. La citation que tu pointe est très humble ils expliquent que c'est leur point de vu. C'est plutôt pas mal de croire en ce qu'on fait en tant dans le développeur d'un projet. Je pense que leur présent est un présent de vérité général ils pensent qu'en général c'est le cas. C'est discutable bien sûr mais le tourner en ridicule, je ne pense pas que ça en vaille la peine.

Si tu veux baver sur mongo, des citations du patron de la boite qui est derrière seront bien plus pertinentes.

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

Après, est-ce que cela veut dire qu'il ne faut pas l'utiliser ? Non. L'avantage de MySQL est qu'il reste répandu et léger. Donc pour de simple besoin (blog, site, etc…) où les données ne sont pas crucial, il n'y a aucun problème à l'utiliser (PS : je l'utilise pour mon site xD)

Ouai, je ne connais pas très bien MySQL, mais avec ce genre de descriptions, j'ai l'impression qu'un mongodb est probablement plus pertinent dans la plupart des cas.

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

Je ne connaissais pas flus merci pour le lien :) et oui effectivement c'est ce que je décris un peu plus haut.

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

Quand je dis qu'une prod avec SLA ou du moins dont les gens veulent une disponibilité 24/7, ce qui me semble être sous-entendu par « la prod tombe le vendredi soir », demande un travail en équipe, des astreintes,… Tu me répond que je suis dans ma tour d'ivoire. Tu peux me dire que non c'est une prod qui n'est pas 24/7, mais du coup tu n'a pas à t'en occuper après ta journée de travail comme tu le dis dans le premier commentaire au quel je répond.

J'arrive même pas à comprendre ou tu veux en venir : en quoi tu considères que mon exemple est du travail illégal ?

Vouloir une prod 24/7, c'est avoir quelqu'un qui régis aussi vite que possible aux problèmes. C'est ce dont tu parle dans ton premier commentaire : je ne l'invente pas. Ça s'appelle une astreinte et tu as légalement un quota d'heure d'astreinte limite donc tu dois travailler en équipe.

S'il s'agit d'une prod non 24/7, c'est en effet légal. Mais faut déclarer ses heures sup' ou que ce soit dans le cadre du forfait cadre et il faut surtout éviter de responsabiliser l'employé pour des défauts de la prod. L'importance de cette prod doit venir avec des moyens équivalents. Mais ça c'est juste une remarque.

La logique derrière ton allégorie de « la prod qui tombe à 18h » me semble être l'une des 2. Évidement je peux me tromper et évidement en ayant la facilité d'imaginer qu'une prod était généralement 24/7, j'ai suivi un raccourcis.

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

Quand tu as vu, comme moi des softs hyper critiques être maintenu depuis des années par 1 seul bonhomme (qui est le seul à connaitre le code, la partie métier) à quart de temps dessus et qui n'a jamais eu d'astreinte pour ça…
tu descends un peu de ta tour d'ivoire. (attention : j'ai jamais dit que c'était bien mais c'est un constat)

Tu n'a peut être pas dis que c'était bien, mais tu considère que quelqu'un qui dis que si un environnement a des SLA il faut travailler en équipe et gérer des astreintes est dans sa tour d'ivoire. C'est juste le droit de travail. Être totalement hors des clous comme ça ce n'est même pas légal. C'est pas une question d'aimer le travail bien fait ou la passion pour ce qu'on fait. Accepter de travailler dans ces conditions et en plus considérer cela comme normal (pointer comme un quelqu'un qui ne veux pas s'engager et prendre pour soit le résultat de cet état de fait), ça dévalue ton travaille.

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

En fait, barmic, tu construis ton argumentaire autours de plusieurs postulats qui ne sont pas forcément vrai.

C'est toi qui parle d'une prod qui casse un vendredi à 18h. Le fait d'avoir une prod implique beaucoup de choses (la presque obligation légale d'être en équipe - tu n'a pas le droit d'être en astreinte 24/7 -, le fait qu'il s'agisse d'un service,…) que tu es entrain de remettre en cause dans ce commentaire.

Je pense plutôt qu'il y a une constante : n'importe quel boite souhaite la meilleur qualité et donc des salariés le plus compétents possibles, agiles, volontaires etc.

Je ne suis pas du tout d'accord. La plupart des boites ne savent pas ce qu'est et se foutent de la qualité logiciel. C'est simple elles ne la définissent pas. Parce que c'est une notion complexe et ça peut devenir très chère. Donc non la plupart veulent le niveau suffisant de qualité pour ne pas être trop emmerdé et que ça ne coûte pas trop chère.

Mon constat c'est que beaucoup de choses "critiques" (les fameuses 500 qui font tant plaisir) peuvent être évités en amont avec du typage, du pattern matching et de l'immutabilité.

J'ai vu des projets utilisant les même techno à des niveaux de résilience et de correction très différents et c'est la qualité des tests qui les départagées. Bien sûr le contexte joue sur la qualité des tests, mais c'est mécanique : tu test, ça marche, tu test pas, ça ne marche pas.

La simplicité du rollback, c'est bien mais faut pas que ça devienne une solution de facilité.
Bien entendu qu'il est impossible de livrer en prod sans un dérapage mais ce qui me semble plus important que le rollback en lui-même c'est les mesures prisent après rollback :
pourquoi c'est arrivé et comment on évite à l'avenir.
Avec ça, on réduit leur fréquence graduellement et on peut se permettre d'éviter des dettes techniques : maj des libs régulières, refacto etc.

Je ne suis pas d'accord. Évidement que tu va réfléchir à ce qui s'est mal passé en cas de rollback sinon tu ne livre plus. Ça n'est pas une question de bonne pratique, c'est mécanique. La capacité de rollback c'est ce qui te permet de ne pas avoir peur de ta prod. Les projets qui ont peur de leur prod accumulent de la dette. Les projets qui n'en n'ont pas peur vont se permettre de mettre en prod plus régulièrement donc vont déployer.

En plus, il y a tellement de cas ou un rollback n'est pas possible (ou que celui-ci a un coût) que de s'appuyer dessus c'est le désastre assuré.

Donc tu dis, « bon désolé mais si on a raté quelque chose, tout sera cassé jusqu'au prochain fix ou desaster recovery pour pouvoir remonter des données cohérentes ». Ça tu peut le faire quand tu as des SLA très petites, que la valeur de ta prod est plus faible que celle de ton dev et/ou que tu a le goût du risque. Il arrive qu'on ne puisse pas le faire, mais c'est un défaut à assumer (se préparer à faire un desaster recovery ou un hotfix en urgence. Travailler dans l'urgence, perso j'évite autant que possible.

Reproduire, c'est souvent 90% du taf et quand je fais le constat amer d'avoir passé des heures a arriver à reproduire un bug qui est lié à du typage, ça me fait rager parce que je sais qu'il pouvait être évité en amont.

Je n'ai jamais vu ce type de bug arriver dans une prod. Je ne connais pas tout, hein, mais ça ne m'est jamais arrivé. Du moins dans ce qui est classiquement le rôle du typage. Donc pas les types dépendants par exemple qui s'approche presque plus de la preuve de programme.

Néanmoins, je pense que l'apprentissage de Rust m'a permis de m'améliorer sur plein de sujets et je recommande vivement de sortir de sa zone de confort avec ce genre de langage.

Je n'ai jamais remis ça en cause. Ni les qualités intrinsèques de rust. Comprendre et jouer avec une variété de langage est très enrichissant. Regarder du coté de rust, de lisp, de smalltalk,… C'est très enrichissant, pour comprendre et utiliser le langage que tu utilise au quotidiens.

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

Avec un langage fortement typé et qui fait un max de vérifications à la compilation, tu t'évites l'écriture d'une paires de tests (débiles pour la plupart) qu'un langage interprété et faiblement typé t'oblige pour avoir la même rigueur avant déploiement.

Je ne suis pas d'accord. Ça joue sur lors du développement. Si tu laisse passer un problème de typage en prod, le problème c'est pas le langage, c'est la qualité que tu livre. L'effort pour fournir la même qualité ne sera effectivement pas la même, mais hors cas pathologique (comme ce pourquoi a était fait rust pour remplacer c++), la différence ne sera pas si grande.

La solidité de ton déploiement : c'est pas forcément au dev de gérer ça donc hs.

Tu parle de prod, parler de prod sans parler d'opérationnel, ça n'a pas de sens. Mais surtout si la prod est le problème du développeur alors son déploiement aussi. Sinon le fait que la prod tombe le vendredi à 18h ça n'est pas son problème.

La simplicité du rollback : si tu rollback, c'est que t'as cassé la prod, non ? (donc pouvoir rollback c'est bien mais éviter de casser la prod, c'est mieux)

Donc c'est bien une question de qualité de ce que tu livre. Mais les prods les plus solides vivent avec le fait qu'ils casseront leur prod. Parce qu'il est humainement impossible d'avoir un niveau de test suffisant pour garantir que tu ne casse jamais. Ça ne veut pas dire que tu ne va pas tout faire pour améliorer ta qualité, mais tu sais que reproduire la charge de ta prod est impossible par exemple. C'est pour que les canary release ou l'A/B testing existent.

Niveau workflow, j'aurais plutôt parlé des logs, des métriques, des envs de recette avec cahiers de tests (tu sais, piloté par des humains : c'est encore ce qui se fait de mieux).

Il faut les twelve factors et oui on est d'accord, mais dans tout ça il n'y a pas le typage de ton langage.

Je vais le dire autrement…

Tu veux fournir de la qualité. Tu as 2 stratégies possibles. Soit tu embauche les meilleurs développeurs possibles et ils choisissent le meilleur langage existant et code un excellent logiciel. Tout repose sur la qualité de chacun des développeurs. Soit tu cherche à avoir une qualité « systémique », c'est l'organisation de l'équipe qui produit de la qualité. C'est parce que les tests sont écrit par un autre développeur (entre autre) que tu obtiens de la qualité. Cette seconde stratégie est plus fiable car elle ne repose pas sur un recrutement trop complexe et est résiliente aux faiblesse ponctuelles qu'auront les développeurs.

Bref tout ça pour dire que les typages dynamiques et pire encore les typages faibles, je suis pas fan du tout, mais je ne les prendrais pas comme boucs émissaires en cas de problème en prod.

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

tu espères amortir ce temps perdu à développer proprement en évitant de casser ta production au moment où tu le souhaites le moins (comme d'habitude, le vendredi à 18h…)

Pour moi ce n'est pas le langage qui permette ça. C'est plutôt le workflow de déploiement (les tests que tu fais avant déploiement, la solidité de ton déploiement, la simplicité du rollback,…).

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

Il y a un glissement dans ta réflexion entre, « j'ai trouvé des outils en rust » et « rust doit être mieux que les autres pour des outils cli ».

Si tu prendre d'autres exemples, par exemple httpie, vegeta et vtop. Ils sont écrit respectivement en python, go et js.

Je suis d'accord qu'en principe l'absence de runtime rend le démarrage plus rapide et que ce temps de démarrage peut être désagréable. Personnellement sur PC et laptop je ressent pas le temps de démarrage de python ou go, sur rpi je trouve que python commence à se faire sentir.

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

J’avais présenté, il y a quelque temps, trois utilitaires écrits en Rust pour remplacer grep, ls et find (à savoir ripgrep, exa et fd). Cette dépêche est l’occasion de présenter trois nouveaux utilitaires également écrits en Rust : delta, dust et watchexec.

Il y a une forme de fétichisme pour rust ?

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

Je ne suis pas si vieux dans la communauté :)

Mais quand je suis arrivé, beaucoup disait que gnome2 c'était le DE pour pas trop te brusquer quand tu venait de windows. Je suis d'accord que c'est sujet à caution.

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

Pour être passé par là, ça ne doit pas être l'unique cause de très loin. Si totof a voulu partir souhaitons lui bonne continuation.

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