Julien Jorge a écrit 590 commentaires

Oui, il suffit de ne pas exporter les symboles. Cet article en anglais décrit bien les cas d'usage.

Le problème des headers est qu'ils sont interprétés des tonnes de fois. Même avec des gardes, c'est lu et relu pour chaque unité de compilation les utilisant. Sur des gros projets ou de grosses dépendances ça se sent.

De plus le résultat de l'interprétation peut varier d'une unité de compilation à l'autre selon les paramètres du préprocesseur.

// header.hpp
#pragma once

#ifdef FOO
  using bar = int;
#else
  using bar = char;
#endif

// 1.cpp
#include "header.hpp"

static_assert(std::is_same_v<bar, char>)

// 2.cpp
#define FOO // ou -DFOO sur la ligne de commande
#include "header.hpp"

static_assert(std::is_same_v<bar, char>)
// Perdu, bar est int.

Les modules sont une réponse à ces problèmes.

J'ai testé un petit peu, ça m'a l'air d'être exactement ce que je veux, merci :)

Je me retrouve dans ces 4 sources mais je ne mets pas le même poids à chaque.

En ce qui me concerne, ce qui m'intéresse c'est sans doute de devenir meilleur à ce que je fais. Je ne saurais expliquer pourquoi et je n'ai pas envie de chercher, je sais juste que ça me stimule.

Au travail ce sera ma première motivation : atteindre un objectif en apprenant des choses au passage. Construire un logiciel, un outil, du mieux que je peux, en le découpant en petites tâches que je résoudrai une à une pour construire quelque chose de plus grand et d'utile à quelqu'un. J'apprends en pratiquant et l'aboutissement du projet, la confrontation au public, sert à confirmer que je m'en suis bien sorti.

Ensuite les technos jouent beaucoup. De tous les langages que j'ai essayé, je préfère faire du C++. J'ai trouvé insupportable d'utiliser Unity. Les langages du web et tout l'écosystème qui va avec m'ennuient. J'aime aussi bosser avec un tooling léger, moins il y en a, mieux je me porte. En gros tu me files Linux + CMake + Bash + GCC et je suis heureux.

Je dirais donc énormément pour « maîtrise » (il faut que ce soit un peu plus compliqué que ce que je sais faire), beaucoup pour « autonomie » (je choisis mes outils et contribue à la méthode de résolution) et pas mal de « sens » (il faut que ce que je fais serve à quelqu'un).

Pour ce qui est de l'effet tribu, il y a de ça aussi. Effectivement c'est mieux si je suis en phase avec les collègues et que nous marchons en rythme vers un objectif commun, en accord sur les méthodes. Je ne suis pas sûr cependant qu'on puisse trouver ça dans de grandes équipes ; à un moment il y a forcément des profils disons moins stimulants. Et puis il faut voir ce que chacun apporte. J'ai eu un collègue qui était très bon sur un domaine où j'étais nul, mais à côté de ça son code était plutôt médiocre et il n'avait aucune intention de faire des efforts sur ce point. Au final il n'y a pas grand chose à faire, chacun apporte sa contribution au projet.

Tu passes sur le salaire mais ça a sa pertinence aussi, pas tant pour la somme que pour le symbole de reconnaissance. Avoir une renégociation genre une fois par an avec une petite augmentation, c'est rassurant. A contrario, voir le coût de la vie augmenter et son revenu stagner, ça donne l'impression d'être coincé dans une impasse, c'est démotivant. Pareil pour les primes, recevoir une prime quand on dépasse les attentes, c'est encourageant. Sans ça on fait vite le ratio revenu sur effort et on arrête les efforts.

Alors j'ai lu ce livre et effectivement c'est un de ceux que je pointe. Je fais aussi référence à Code Complete.

C'est plein de bons conseils et lire ça me semble être un bon moyen d'acquérir une sorte d'expérience de plusieurs décades de développement avant nous. Mais que faire quand les autres ne l'ont pas lu ? Pire, que faire quand ils ne sont même pas intéressés par la notion de code clean ?

Il y a aussi des principes qui ont un peu vieillit dans ces livres. Dans le lien de blog que tu donnes plus bas il y a un lien vers un autre article qui explique que le DRY se fait avec modération. Oui, factoriser à tout va pose aussi des problèmes. Oui je m'y suis aussi brûlé.

Pareil pour le fait de favoriser le polymorphisme à la place d'if/else ou switch/case. Ça se discute. Des fois c'est plus clair d'avoir tous les cas à plat dans un switch plutôt que d'avoir plein de classes qui éparpillent la logique.

Il y a des trucs sur lesquels j'ai du mal à faire des retours en revue. Quand il y a un problème du genre « ça ne fonctionne pas », c'est facile, mais quand c'est un problème de façon de faire, c'est dur à justifier.

Par exemple quand je vois passer des acronymes, des abréviations, des fonctions de cinq kilomètres, des dépendances inutiles dans les headers, de l'objet pour que dalle… C'est sûr ça fonctionne, mais niveau hygiène c'est pas génial. Quelle galère de lire du code comme ça. Quelle galère de revenir là dedans après quelques mois, et quelle tristesse de se traîner ça sur toute la vie du projet.

Et du coup à part faire une remarque personnelle disant que mon expérience et mes lectures m'amènent à penser que c'est médiocre, éventuellement en pointant un paragraphe d'un bouquin ou un article en guise de source externe (et bonjour l'effort pour retrouver mes sources), je ne vois pas trop comment faire pour encourager à faire du code propre.

Comment faites vous pour faire des retours sur ce genre de soucis ?

J'ai déjà entendu cette histoire et… bof. Elle sous entend que la réponse à un problème est d'augmenter les ressources sans chercher, mais je ne vois pas en quoi c'est plus malin ou plus économique que de trouver la cause du problème.

C'est sûr qu'on a l'impression d'avoir perdu de l'argent avec ce fameux expert, mais bon il faut bien quelqu'un pour trouver la cause du problème. Après que la solution soit d'ajouter de la RAM ou de réduire la conso mémoire, ça se discute. Le problème c'est que si ce gars n'était pas là quelqu'un d'autre aurait augmenté les ressources au hasard en espérant contourner le problème. Plus de CPU ! plus de RAM ! plus de serveurs ! Ça va bien finir par passer… Cette augmentation de ressources ça se paye aussi sur la durée, et ça ajoute de l'incompréhension pour ceux qui entrent dans le projet par la suite.

Enfin je dis ça, à la base je ne suis déjà pas fan de l'idée d'ajouter toujours plus de puissance. Déjà parce qu'en terme de satisfaction personnelle je préfère chercher la cause du problème, et ensuite parce que, d'une manière générale, je crois que la surconsommation de ressources cause des problèmes plus grands sur le long terme. La survie c'est principalement de l'endurance, pas que du sprint, même en informatique. T'imagine un peu si on appliquait la même méthode en dehors de l'informatique, à mettre toujours plus de puissance au lieu d'économiser ? On cramerait toute nos ressources.

Attend une minute…

Je suis peu familier de Qt mais si je me souviens bien leurs signaux font partie des extensions au langage, du coup je doute que l'auteur du benchmark puisse l'intégrer facilement et par conséquent je ne le mets pas non plus dans les tests.

Au niveaux des outils chez nous c'est aussi Slack & Hangout pour la communication. Hangout ne fonctionne malheureusement plus avec Firefox mais il y a moyen de faire du partage d'écran avec (sous Chrome, donc).

Après 6 ans en télétravail et différentes équipes je peux te dire les trucs qui ont bien fonctionné pour moi :

• Dire bonjour à l'équipe sur Slack quand on commence à bosser. J'avais au début l'impression de spammer mais ça permet aux uns et aux autres de savoir que l'on est dispo.
• Faire un point en visio le matin. Ça fait un point de synchro et ça permet de planifier sa journée. En général toutes les questions en suspend sont traitées à ce moment puis ensuite on est tranquille pour le reste de la journée.
• Avoir un bon micro-casque.
• Faire le chiffrage en visio et le répartir sur plusieurs jours. J'ai eu des sessions de trois heures de chiffrage et ça chauffe bien les oreilles. C'est mieux de faire quelques stories par jour.
• Ne pas hésiter à s'appeler en visio sans prévenir.

Pour les réunions à plusieurs en visio, c'est pratique d'avoir un « chef d'orchestre » qui se charge de donner la parole aux un et aux autres. Sans ça on se retrouve à parler en même temps à cause des latences, sans savoir si on a été entendu. S'il y a en plus dans l'équipe des gens qui ont tendance à couper la parole, ça devient vite cacophonique.

Il y a souvent un flottement en fin de visio, où personne n'ose raccrocher en premier. Il ne faut pas hésiter. À+ et on raccroche. C'est pratique quand le « chef d'orchestre » clôt clairement la réunion.

Pour référence : https://linuxfr.org/news/experience-s-de-teletravail

C'est corrigé.

Ta solution est sans doute très efficace, malheureusement elle ne répond pas à la question ! Le but est d'ignorer les valeurs pour lesquelles il existe un zéro plus haut dans la même colonne. Là ton algo ignore le reste de la ligne quand il rencontre un zéro.

Ça fonctionnerait si la matrice était en column-major, ce qui est d'ailleurs pris en considération dans le journal, mais ça demande de changer la structure de donnée. C'est un peu tricher par rapport à l'exercice. J'aurais bien voulu croire que tu considères que la matrice est en column-major mais comme tu as nommé ta variable row je ne doute pas que tu la considères en row-major.

En tout cas merci pour les insultes et le mépris, c'est top ! <3

Tiens, dis-moi, j'essaye le même genre de truc sur la version indices, qui maintient une liste les indices des colonnes pertinentes :

int matrix_elements_sum_indices_branchless
(const std::vector<std::vector<int>>& matrix)
{
  const int row_size(matrix[0].size());
  std::vector<int> usable_columns(row_size);

  const auto usable_columns_begin(usable_columns.begin());
  auto usable_columns_end(usable_columns.end());

  std::iota(usable_columns_begin, usable_columns_end, 0);

  int remaining_count(row_size);
  int result(0);

  for (const std::vector<int>& row : matrix)
    for (auto it(usable_columns_begin); it != usable_columns_end; )
      {
        const int i(*it);
        const int v(row[i]);
        result += v;

        const int keep_mask((v == 0) ? 0 : -1);
        usable_columns_end += ~keep_mask;

        // discussion ci-dessous sur le code d'ici…
        const int distance_to_last(usable_columns_end - it);
        const auto new_i_it(it + (distance_to_last & ~keep_mask));
        *it = *new_i_it;
        // …à là.

        it += -keep_mask;
      }

  return result;
}

Ça ne fonctionne pas très bien et je pense que c'est à cause de l'écriture dans le bloc d'ici à là. Si je mets à la place de ce bloc la condition suivante :

        if (~keep_mask)
          *it = *usable_columns_end;

Alors ça fonctionne très bien.

Ma compréhension est grosso-modo que dans la première version on réécrit inconditionnellement dans la mémoire pointée par it, et bien qu'elle est probablement en cache (on vient juste d'y accéder) et que sa valeur ne change pas toujours, la ligne de cache devient toujours dirty et il faut la renvoyer en RAM. Du coup on paye une écriture à chaque itération, qui coûte bien plus cher qu'une misprediction occasionnelle. Qu'en penses tu ?

L'interface et l'API de ublas sont super mais malheureusement les perfs ne suivent pas :(

Ce n'est pas évident que ce branchement soit inliné, il aurait été bien d'avoir un extrait du code assembleur, et de comparer avec une version sans multiplication.

Bien vu ! Voici une version sur Compiler Explorer où on peu voir le corps de la version branchless :

.L31:
        mov     rdx, QWORD PTR [r8]
        movsx   ecx, BYTE PTR [rdi+rax]
        mov     edx, DWORD PTR [rdx+rax*4]
        mov     esi, ecx
        imul    ecx, edx
        add     r12d, ecx
        test    edx, edx
        setne   dl
        and     edx, esi
        mov     BYTE PTR [rdi+rax], dl
        mov     rdx, rax ; à partir de là on gère le compteur de la boucle et
        add     rax, 1   ; la condition de sortie.
        cmp     r9, rdx
        jne     .L31     ; on a un seul jump par itération.

et celui avec les branches :

.L70:
        mov     BYTE PTR [rdi+rax], 0 ; usable_column[i] = 0
.L53:
        lea     rdx, [rax+1] ; gestion du compteur de la boucle, sans intéret
        cmp     rcx, rax     ; pour la comparaison de la sortie asm
        je      .L52         ; saut pour sortir de la boucle
.L59:
        mov     rax, rdx     ; fin de la gestion du compteur de la boucle
.L55:
        cmp     BYTE PTR [rdi+rax], 0
        je      .L53 ; un premier jump hors gestion du compteur de la boucle
        mov     rdx, QWORD PTR [rsi]
        mov     edx, DWORD PTR [rdx+rax*4]
        test    edx, edx
        je      .L70 ; là on a un jump qui va nous permettre de faire
                     ; l'affectation usable_column[i] = 0 puis d'enchaîner avec
                     ; la gestion du compteur de la boucle.
                     ; Ça fusionne les deux sauts du code initial (le test
                     ; if (v==0) puis le saut pour reboucler.
        add     r12d, edx ; result += v
        lea     rdx, [rax+1] ; à nouveau de la gestion du compteur de boucle
        cmp     rcx, rax
        jne     .L59

Bien vu pour la version sans multiplication :) On voit bien la vectorisation et ça marche bien mieux :

2020-02-12 08:34:50
Running ./build/matrix-elements-sum-GNU
Run on (4 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 3072 KiB (x1)
Load Average: 0.67, 0.67, 0.63
***WARNING*** CPU scaling is enabled, the benchmark real time measurements may be noisy and will incur extra overhead.
-------------------------------------------------------------
Benchmark                   Time             CPU   Iterations
-------------------------------------------------------------
branchless/2             28.4 ns         28.4 ns     24540986
branchless/4             45.6 ns         45.6 ns     15164641
branchless/8              116 ns          116 ns      5777179
branchless/16             369 ns          369 ns      1898641
branchless/32            1387 ns         1387 ns       484254
branchless/64            5847 ns         5846 ns       111630
branchless/128          22439 ns        22436 ns        30474
branchless/256          88132 ns        88125 ns         7754
branchless/512         349637 ns       349573 ns         2010
branchless/1024       1441557 ns      1441252 ns          485
branchless/2048       5766216 ns      5764464 ns          121
branchless/4096      22847843 ns     22846967 ns           31
branchless/8192      91376681 ns     91368790 ns            8
branchless/16384    367024190 ns    366997034 ns            2
branchless_2/2           34.7 ns         34.7 ns     20037235
branchless_2/4           40.5 ns         40.5 ns     17081915
branchless_2/8           62.9 ns         62.9 ns     10383991
branchless_2/16           146 ns          146 ns      4770697
branchless_2/32           435 ns          435 ns      1600480
branchless_2/64          1869 ns         1863 ns       450005
branchless_2/128         5882 ns         5882 ns       104268
branchless_2/256        24406 ns        24407 ns        28618
branchless_2/512       100493 ns       100124 ns         7202
branchless_2/1024      473645 ns       473618 ns         1248
branchless_2/2048     2284499 ns      2284170 ns          288
branchless_2/4096     6951965 ns      6951809 ns           79
branchless_2/8192    33005646 ns     33002903 ns           20
branchless_2/16384  118768214 ns    118758699 ns            5

Je disposais par contre du programme jq, qui permet d'extraire les données par nom. Mais je n'ai pas réussi à passer directement du flux à un fichier texte de type CSV.

jq est un super outil, pour lui faire sortir du csv tu pouvais utiliser @csv :

jq -r '.eventValue | [ .longitude, .latitude ] | @csv'

Ce que je lis comme : prend le sous objet eventValue, puis fait un tableau avec les champs longitude et latitude de ce sous-objet, puis affiche-moi ce tableau au format CSV. Le -r, que tu avais déjà trouvé, permet de faire une sortie brute, c'est à dire qu'il affiche les chaînes de caractères sans les guillemets.

Allez, je râle aussi :)

J'ai un peu le même sentiment, et sans doute à peu près le même âge. Une question de génération ? Perso j'ai longtemps été dans une position intermédiaire : pas du genre à ajouter de la RAM ou à booster le CPU, mais pas non plus à aller taper de l'assembleur. J'avais plutôt une culture de complexité théorique.

Après avec le temps qui passe je vois mes préférences changer, voire se confirmer. Il n'y a plus de doute, j'aime le bas niveau et l'algorithmique. Par contre la complexité théorique n'est plus suffisante sur les architectures modernes. Quand je vois des softs par exemple en JS, interprétés par un moteur, dans une sandbox, qui tourne dans une instance Docker, lancée dans une VM quelque part. Pfff, il y a tellement d'indirections :/ J'ai l'impression qu'on avait quelque chose qui marchait, pas forcément évidente pour le plus grand monde, et qu'on y ajoute régulièrement des couches intermédiaires pour rendre ça plus clair et plus accessible mais en feignant d'ignorer que chaque indirection supplémentaire est une source de frictions et de problèmes.

Au boulot j'utilise Unity, le moteur de jeu, et j'ai vraiment l'impression de lutter contre l'outil. Ça se lance en plusieurs minutes, les clics réagissent après plusieurs secondes, ça s'affiche mal, ça ne respecte pas les réglages de tailles de polices de mon système. La sélection d'un effet de particules pousse un cœur à 100%, même si les particules ne sont pas simulées. C'est aussi le premier logiciel que je trouve qui ignore complètement les raccourcis clavier en bépo (il faut y faire ctrl+x en bépo pour copier, le x du layout étant à la position physique du c). Il y a 20 ans je montais des scènes dans 3ds Max sur un 166 Mhz avec quelques Mo de RAM, le rendu était long mais l'interface était super. Aujourd'hui j'ai un quad core à 2.5 GHz et 8 Go de RAM et Unity s'étouffe sous son propre poids pour afficher un pauvre formulaire.

Ceci dit je comprends qu'on en arrive là. Comme le dit Ruminant plus haut il y a aujourd'hui bien plus d'impératifs de marchés, un besoin de livrer en premier et d'occuper l'espace. C'est impossible de justifier de passer du temps à réécrire des trucs qui existent déjà juste pour faire quelque chose qui serait plus performant alors que ça ne change pas le produit. Je m'en rends compte quand je veux faire du bas niveau, c'est un puis sans fond. Il y a tellement d'aspects à améliorer, de compromis à chercher, de benchmarks à effectuer. Puis il y a les questions de modèles de processeurs, les jeux d'instructions disponibles. Je comprends que l'industrie se contente de niveaux supérieurs.

Au passage je vous suggère de regarder la conférence Preventing the Collapse of Civilization par Jonathan Blow. Il y dit notamment que l'expertise part de plus en plus vers les couches hautes et que bientôt quasiment plus personne ne saura lire ou écrire de l'assembleur pour maintenir les systèmes sur lesquels reposent les couches hautes. Il compare ça avec certaines langues mortes que nous ne savons plus décoder.

Qui est cette assurance A qui répond rapidement et efficacement à ta demande ? On veut savoir !

Je ne suis pas convaincu que la demande soit abusive mais elle aurait pu être faite plus respectueusement et poliment. Pour retirer un contenu du site on peut, dans l'ordre

• contacter l'équipe de modération pour être mis en relation avec l'auteur du journal ;
• exprimer simplement son mécontentement (« ça m'embête que tu mettes tout ça en ligne comme ça parce que je fais mon business avec. Veux-tu bien retirer le journal ? Ou retravailler le texte pour anonymiser le service ? ») ;
• reboucler avec la modération sur le résultat de la discussion ;
• et si vraiment aucun accord amiable ne peut être trouvé, sortir la carte de l'avocat.

Perso je vois dans une mise en demeure une sorte d'anticipation d'agressivité. Un peu comme celui qui envoie la police chez les voisins ou qui tape au mur plutôt que de frapper à la porte pour demander de baisser la musique, ou juste passer le lendemain pour dire que dit-donc c'était bruyant hier fait attention à l'avenir.

On sait jamais, le voisin pourrait devenir agressif. Mieux vaut l'agresser en premier !

Pour ne pas mettre de l'huile sur le feu ? Une mise en demeure n'est pas la démarche d'une entité apaisée. Recopier ici le lien vers le journal ou le nom de l'entité ne servirait qu'à les agacer et n'aurait aucun intérêt pour LinuxFr.

Si quelqu'un veut tenter un effet Streisand, citer l'entité et republier le journal, libre à lui de le faire ailleurs (après tout les contenus sont en CC-by-sa ici) mais je ne vois pas ce qui pourrait en sortir d'intéressant.

Pur hasard, je viens de tomber sur cette courte critique vidéo d'une édition précédente (moins de cinq minutes). Le livre n'avait pas l'air au niveau. Du coup je suis allé voir la table des matières et les extraits sur le site d'Eyrolles et on dirait que ça n'a pas beaucoup bougé.

Il y a par exemple des gens qui en lisant le titre d'une offre d'emploi « Développeur expert WinDev » se disent « ah ils cherchent un développeur, un mec. » Ces gens se sentent alors inclus ou exclus de l'offre, selon le cas. Un bénéfice de l'écriture inclusive est de supprimer la supposée pertinence du genre.

Après il y a plusieurs façons d'être inclusif. Il y a cette syntaxe avec le point médian qui agace des lecteurs·ices, perturbe les correcteurs orthographiques et handicape les utilisateurs·ices de lecteurs d'écran. Mais bon, ceux·lles qui utilisent des lecteurs d'écran ont déjà la vie bien facile, bien fait pour eux.

Et il y a une autre forme d'écriture inclusive qui consiste à utiliser des mots classiques moins restrictifs ou lister les cas. Par exemple « Un ou une développeuse WinDev », « Un être humain expert WinDev » ou « Une personne experte WinDev ». C'est plutôt simple mais on manque parfois de mots. Et puis c'est pas très militant.

Sinon on peut aussi rester en genre non marqué et expliquer à longueur de journée que la forme non genrée s'écrit comme le masculin et qu'En ToUtE lOgIqUe on ne peut pas considérer que le sujet soit restreint aux hommes. Bam ! Éduque-toi avant de commenter !

Personnellement je crois que si un groupe de personnes se sent exclu à cause d'une tournure de phrase qui se voulait neutre alors ça vaut le coup de faire attention à la façon dont on s'exprime. Néanmoins le fait que les militants de l'inclusion poussent à l'utilisation du point médian au détriment de la lisibilité du plus grand nombre, au détriment de ceux qui ne lisent pas bien le français et surtout au détriment des personnes handicapées ayant déjà le plus de difficultés à utiliser l'informatique me dépasse complètement.

Pour le C++ en 10 minutes tu as mis un livre sur le SQL. Il faut que je vérifie mais il me semble que ce n'est pas tout à fait pareil :)

Je ne connaissais pas Learn C++ in {n} minutes mais en parcourant un peu au hasard je trouve des trucs surprenants :

// Containers with object keys of non-primitive values (custom classes) require
// compare function in the object itself or as a function pointer.

// […]

struct compareFunction {
    bool operator()(const Foo& a, const Foo& b) const {
        return a.j < b.j;
    }
};
// this isn't allowed (although it can vary depending on compiler)
// std::map<Foo, int> fooMap;
std::map<Foo, int, compareFunction> fooMap;

Le comparator de std::map n'est pas restreint aux pointeurs sur fonctions. N'importe quel type pour lequel bool operator()(T, T) est défini convient.

// Beware of possible circular references!!!
// There will be always a reference, so it will be never destroyed!
std::shared_ptr<Dog> doggo_one(new Dog());
std::shared_ptr<Dog> doggo_two(new Dog());
doggo_one = doggo_two; // p1 references p2
doggo_two = doggo_one; // p2 references p1

Il n'y a pas de références circulaires ici. Le premier Dog est détruit lors de la première affectation. La seconde affectation est alors équivalente à doggo_two = doggo_two. Le deuxième Dog a deux pointeurs vers lui et il est détruit quand doggo_one et doggo_two sortent du scope.

Je suis un peu déçu par ce site :/

Et sinon, qu'est-ce qu'un salaire d'expert pour toi ?

oui les modérateurs, j'abuse, vous pourrez virer ce message si vous voulez

Mais pourquoi sortir les insultes si tu sais que ton message risque d'être supprimé ?

Effectivement maintenant que nous, les modérateurs, sommes alertés, nous allons passer du temps à nous demander si oui ou non il faut supprimer cette ligne. Du temps de perdu. Et on se retrouve encore avec un membre insulté par un autre membre. Ambiance pourrie.

Pourtant la discussion, à défaut d'être calme et courtoise, avait des éléments intéressants. S'il vous plaît, toi et tes interlocuteurs, restez dans le sujet et évitez les attaques et insultes. Il n'en est jamais rien sorti de positif.

En toute honnêteté je ne suis pas en accord avec tout ce que tu as écrit, néanmoins je suis content de lire ce point de vue. Comme Zeroheure je te suggère de laisser le clavier refroidir. Reprends-le ensuite pour nous faire un journal « Comment je suis devenu indépendant », raconte nous les hauts et les bas (SDF, vraiment ?), et ce sera super.

Ton lien est mort : 404 file not found.