lasher a écrit 2730 commentaires

Je pense qu'il est compréhensible qu'on ait poussé Stallman vers la sortie après son mail pour des raisons évoquées par d'autres plus haut, mais ce que dit Vice et que tu rapportes :

Stallman wrote that the “most plausible scenario” is that Epstein’s underage victims in his campaign of trafficking were “entirely willing."

… est faux. J'ai lu le mail en question. Ce n'est pas ce qu'a dit Stallman. Il dit que très certainement ces filles « donnaient l'impression d'être consentantes » (sous-entendu : car sous la coupe d'Eptstein). Ce n'est pas la même chose que dire qu'il affirmait qu'elles étaient effectivement consentantes.

Grâce aux adverbes entre autres. Si je dis, « Je regarde ça demain » ou « Je regarderai ça demain », les deux sont compréhensibles de la même manière.

Bref, il faut contextualiser.

Justement, c'est un sujet qui n'a aujourd'hui pas de réponse évident : qu'est-ce qui est le plus efficace entre inciter ou contraindre?

Je pense qu'aux débuts du LL, oui, contraindre était important, car tout un tas d'éditeurs (Microsoft en tête, mais clairement pas qu'eux) voulaient clairement piéger les utilisateurs dans leur environnement. En particulier, il fallait qu'une masse critique d'utilisateurs et producteurs de LL soit atteinte pour que les logiciels ne se retrouvent pas absorbés par des éditeurs tiers¹. En ce sens, le GCC initial (et donc pas EGCS qui a suivi fin des années 90) ne me choque pas dans son couplage fort front-end/back-end, car oui, un certain nombre de compagnies étaient prêtes à cannibaliser ce genre de softs difficiles à écrire sans reverser quoi que ce soit à la communauté (et oui j'insinue que pas mal étaient prêtes à violer la licence, car pas de communauté du libre très organisée ni très nombreuse pour contre-attaquer comme c'est possible maintenant).

Concernant la GPL v3, c'est aussi un peu la faute aux gros éditeurs logiciels qui abusent des brevets logiciels : l'exemple de Microsoft qui a fait payer un gros nombre de fabricants de smartphones ou d'environnements grand public basés sur Linux/Android est assez criant en ce sens. Pour Linux/Android c'était trop tard, car forcément sous GPLv2, mais pour les futurs logiciels mis sous GPL je peux parfaitement comprendre.

Ce qui d'ailleurs me fait réagir à un de tes commentaires précédant dans ce fil (je crois) : si Linus Torvalds ne met pas Linux sous GPLv3, c'est parce que d'une part je crois bien qu'il a dit qu'il ne voyait pas l'intérêt (mais ça à la limite, on pourrait aussi imaginer que les gros contributeurs puissent le réclamer s'ils le voulaient vraiment), mais aussi (et surtout ?) parce que de toute manière ce n'est pas possible, étant donné qu'il faudrait l'aval de tous les contributeurs du code existant dans le noyau, alors que certains sont décédés.

Rien de nouveau de la part d'Apple, GCC les embêtait déjà avec ça (et d'autres choses) ils ont juste décidé de faire un truc mieux (LLVM) techniquement sans passer son temps à bloquer les évolutions techniques pour forcer les gens à faire ce qu'ils ne veulent pas faire

LLVM est un compilateur issu de la recherche publique US, absolument pas financé par Apple à la base. La communauté LLVM orientée logiciels libres était déjà établie au sein de l'enseignement supérieur et de la recherche US quand Apple a commencé à s'y intéresser. De nos jours il est vrai que le plus gros financeur de LLVM est Apple, mais l'impulsion initiale est bien celle de la NSF aux US (et pas mal de contributions continuent devenir de labos/universités du monde entier). Sinon, oui, la licence type BSD est clairement ce qui a attiré Apple, au moment où les nouvelles versions de GCC passaient en GPL v3.

Mais je pense que rappeler que Apple s'est largement appuyé sur les efforts communautaires est important : DarwinOS est une combinaison de noyau Mach et d'environnement FreeBSD, et les compilateurs itou (GCC/LLVM+Clang). Et évidemment, ils ont bien raison de profiter de cela, mais j'aime bien rappeler que tout un tas de trucs qui sont désormais largement financés par des boites aimant plus ou moins enfermer leurs utilisateurs dans un écosystème donné (ça vaut aussi pour Google et Android par ex) le font grâce à des efforts communautaires importants.

… D'expliquer un peu plus, non ? Quelle grande administration ?

Je viens beaucoup moins souvent qu'avant, donc pas sûr que je sois vraiment indiqué pour répondre à ça mais… en tant que Vieux Con (TM), je ne lis jamais la section liens, du coup ce qui y est posté ne change en rien mes habitudes : journaux d'abord, puis page des nouvelles (avec possiblement quand même les nouvelles tout en haut de la page d'accueil en premier).

Et de temps en temps les forums (mais vraiment pas souvent).

J'ai récemment fait l'acquisition de canards en plastique aux couleurs de différents lieux que j'ai visités. J'ai hâte de leur expliquer mes problèmes de bug.

Le staff de LinuxFR se débrouille très bien depuis plus de 20 ans, et quelque part, je dirais même qu'ils passent à l'échelle. :-)

AMD veut coller au standard et développe en open-source

Ça me semble quand même être une technique classique du challenger/outsider de faire du dev libre/open source lorsqu'il ne domine pas le marché visé dans le cas de constructeurs de matériel un peu sophistiqué. Par exemple, Intel a des drivers libres pour ses GPU parce qu'il s'est complètement planté avec ses tentatives de cartes graphiques 3D/GPU (voir aussi : Larrabee, devenu Xeon Phi, abandonné au bout de 2 générations). Ils proposent même un runtime OpenCL libre (au moins sous Linux; je crois qu'une implémentation Windows était en cours il y a quelques temps).

Je pense que Zenitram a raison : on a deux composants logiciels, A et B, tous deux inclus dans de grosses distribs. Bien. Il y a des cas documentés/avérés de plantages lorsque A utilise B. Bien bien. Du coup les dévs du composant A décident que le composant B est trop problématique (possiblement à tort, mais c'est suffisamment un souci pour qu'ils se soient posé la question pendant de longs mois avant de réagir).

Si la/les distributions qui intègrent les deux composants estiment que c'est une exagération des dévs de A, les mainteneurs du paquet A n'auront qu'à patcher le code pour effectivement donner le choix à l'utilisateur. Je trouve que c'est finalement assez logique, et cohérent avec la façon dont les distributions Linux ont fonctionné jusqu'à présent.

C'est vrai, MAIS : le problème est qu'on ne parle pas que d'une tâche qu'on automatise, mais d'un ensemble de tâches au fil de l'eau. Il faudra ainsi additionner le nombre de tâches qu'on répète plusieurs fois dans la journée/le mois/l'année et leur durée pour réellement identifier ce que la somme agrégée nous coûte en temps.

Il faut aussi considérer l'aspect énervement/agacement/fatigue (mentale ou physique) à devoir répéter les mêmes tâches, parfois fastidieuse (même si possiblement rapide) plusieurs fois dans la journée, même s'il s'agit de « micro-tâches », car elles coûtent aussi en « context switch ».

(bon sinon j'aime bien ce xkcd :-))

Larry Wall (papa de Perl) le dit très bien (et je le cite régulièrement) : un bon programmeur a trois qualités :

1. La paresse : s'il faut faire plus d'une fois un traitement similaire, autant l'automatiser.
2. L'impatience : le soft ne va pas assez vite, ou ne devine pas suffisamment à l'avance ce que je veux faire. Il va falloir améliorer ça.
3. L'orgueil : lorsqu'on lui signale un bug, le bon programmeur prendra ce bug comme une offense, et ira le corriger aussi vite et bien que possible.

Idem aux US. Après, dans ces pays, beaucoup de boulots qualifiés sont aussi mieux payés que leur équivalent en France (en particulier en info). En contrepartie, le salaire minimum est bien plus bas qu'en France (et je ne parle même pas de l'équivalent de la sécu aux US).

Tout à fait d'accord sur le fait que la programmation parallèle est un sous-ensemble (important !) de la programmation concurrente. Après, comme d'autres l'ont fait remarquer, il existe plusieurs sortes de parallélisme. En calcul scientifique, on utilise souvent le parallélisme de données – c'est l'exemple qu'avait donné quelqu'un ici à propos des chats qui mangeraient dans la même gamelle. Un autre type de parallélisme est celui des tâches : c'est ce qu'on fait, par exemple, lorsqu'on repasse une chemise tout en écoutant la télé/radio, et possiblement en parlant avec quelqu'un. Enfin, il y a le parallélisme de pipeline, qui « chaîne » différentes tâches pour qu'elles traitent un bout de donnée successivement. Évidemment, on va fournir un autre bout de donnée à la première tâche dès qu'elle aura passé son bout de donnée traité à la suivante, etc. On peut imaginer une chaîne de montage façon « Les temps modernes », par exemple. Évidemment, on peut mélanger les trois (sinon ce ne serait pas drôle !).

Lors d'une conférence il y a longtemps, le keynote speaker avait proposé une illustration de la différence entre programmation parallèle et programmation concurrente en pratique :

En voyant une nouvelle machine de type supercalculateur, data center, etc., le programmeur parallèle s'extasie et s'écrire : « Ouahou, quelle puissance potentielle ! On va pouvoir faire des choses formidables avec ça ! »

En voyant la même machine, le programmeur concurrent prend une expression horrifiée, et se lamente : « Regardez toutes les possibilités de panne dans cette machine ! »

Un bon exemple de la différence de point de vue est dans l'utilisation d'une bibliothèque de communication et calcul très utilisée en calcul intensif/haute-performance : MPI. Les utilisateurs de MPI le font généralement sur une machine avec réseau d'interconnexion dédié (pas de TCP, trop lourd; pas d'Ethernet, trop lent – au moins niveau latences). Ils se posent des questions compliquées liées à la topologie sur le réseau, combien de sauts il faudra peut-être faire en regardant les machines utilisées, etc.¹ Au contraire, les programmeurs de la bibliothèque MPI locale doivent tenir compte de toutes les possibilités de panne temporaire ou permanente (les appels MPI de base sont bloquants, et attendent des acquittements de bonne réception/terminaison d'envoi de données; même la version asynchrone de ces appels fait de même, peu ou prou). Ils doivent composer avec les possibilités de congestion sur le réseau, et pour les versions les plus sophistiquées, prennent en compte tout un tas de possibilités de pannes transitoires ou temporaires.²

Le programmeur parallèle d'une grappe de calcul essaie de trouver des algorithmes et des implémentations qui iront vite pour une application donnée, en considérant que tout ira bien, c'est-à-dire, en faisant abstraction quasi-complètement de la couche réseau (et en-dessous). Le programmeur concurrent va devoir considérer que les latences d'envoi/réception peuvent varier, et même imaginer quel genre de panne peut survenir, et s'il veut y remédier.

Je suis à l'étranger et je ne pourrai pas aller POSS cette année. Je souhaite un bon anniversaire à LinuxFR malgré tout, et j'espère que vous aurez l'occasion de voir plein de contributeurs. :-)

Spolsky a des défauts, mais les langages qu'il utilise sont ceux de son industrie (il fait des trucs Web, donc il faut penser PHP, JavaScript, ASP, .Net, etc.).

J'aime bien le typage statique, mais ça n'empêche pas qu'il existe des cas compliqués ou à la marge. Par exemple : programmation parallèle en mémoire partagée. C'est pour ça que j'aime préfixer mes variables quand elles sortent du contexte « normal » qu'on s'attend à trouver. Par exemple :

#include <pthread.h>
#include <stdio.h>
#include <stdint.h>

#define N 100ul

volatile int g_COUNTER;

typedef struct { 
    int id;
} id_t;

void* worker(void* arg) {
    id_t id = (id_t*) arg;
/*  Façon très mauvaise de créer une section critique dans le cas général */
    while (g_COUNTER != id->id)
        ; //nothing
    ++g_COUNTER;

    return 0;
}

int main(void)
{
    pthread_t threads[N];
    id_t      ids[N];
    for (size_t i = 0; i < N; ++i) {
        ids[i].id = N-i-1;
        if (0 != pthread_create(threads+i, NULL, worker, ids+i))
            abort(); // pour faire simple
    }

    for (size_t i = 0; i < N; ++i)
        if (0 != pthread_wait(threads[i], NULL))
            abort(); // pour faire simple

    printf("counter = %d\n", g_COUNTER);
}

Dans ce contexte, presque tout suit une convention de nommage classique, mais mes macros sont écrites en majuscules pour bien montrer qu'on parle de constantes (N), et pour mes variables globales, je préfixe par g_ ET je mets en majuscules, parce que dans un contexte multi-threadé, on ne met jamais trop d'avertissements dans le nom de la variable pour qu'on se souvienne qu'il faut faire attention ⇒ g_COUNTER.

Investir raisonnablement n'implique pas qu'on va réussir.

Ai-je dit le contraire ? :-) Ce que je décris est effectivement la présence de gardes-fou pour éviter les financements participatifs qui se résument plus ou moins à une arnaque. Tous les sites ne le font pas (et évidemment, même chose pour un employé ou une boite bien entendu). Par contre, je trouve que ton post laissait entendre que c'était la loi de la jungle pour le crowdfunding. Pour les grosses plates-formes, il s'avère que pas trop, non. Et ce n'est pas juste une histoire d'image de marque dans le cas de KS : pour tout ce qui est US, c'est aussi une protection légale au cas où des gens victimes d'arnaquent se retournent contre le prestataire.

Exception : les (enseignants-)chercheurs ! \o/

Et en l'occurrence il n'y a peut-être pas d'obligation de résultat, mais au moins avec Kickstarter il faut quand même pouvoir démontrer que les sommes collectées ont été investies raisonnablement. Je ne sais plus pour quel projet ça avait été fait, mais en gros la personne qui avait récolté un beau pactole l'avait investi dans complètement autre chose que ce qu'il avait promis, et KS l'a poursuivi en justice, comme il était promis en cas de fraude avérée (et remontée par les utilisateurs).

Nessus aussi était copyleft, et le problème était double :

1. Les « experts » sécu lançaient Nessus sur des machines (serveurs et clients) windows, Nessus ne disait rien, et ces super consultants disaient que le réseau était clean. Sauf que… La distribution de Nessus (en GPL2) ne contenait que les filtres pour Unix/Linux, et pas de filtres spécifiques à Windows (c'était comme ça que les gens de Nessus espéraient se faire des sous, entre autres).
2. Tout un tas « d'experts » se contentaient de foutre une interface graphique par-dessus Nessus, changer les noms ici ou là dans le programme, et surtout, surtout, venaient avec « leurs » outils, en modifiant le soft ou en le corrigeant, sans rien reverser au projet, et sans dire au client d'où venaient leurs outils (c-à-d : en mentant). Et ça, y'a zéro moyen de se prémunir contre, car l'outil ne sort pas du laptop ou de la clef USB du « consultant ». Il n'y avait donc aucune reconnaissance ni contribution au projet (malgré l'aspect illégal de certaines pratiques, mais qui sont impossibles à vérifier/établir en pratique). C'est ce qui a poussé les auteurs de Nessus à fermer (dans le sens : rendre propriétaire) leur projet.

Je ne suis pas dev C++ (enfin, si, mais non). Je suis à fond pour C++11 et ses copains¹. Mais dans tous les cas je suis d'accord que (1) Tous ces nouveaux mots-clef et mécanismes sont utiles, mais que (2) ils n'en restent pas moins abscons pour quelqu'un d'un peu extérieur².

Je rajouterais que, tout comme pour C (qui est toujours enseigné comme si C99 et C11 n'avaient jamais existé³), C++ reste la plupart du temps enseigné par des gens qui ne se mettent pas à jour en termes de normes. Et je ne parle même pas des gens qui enseignent le C++ en « premier langage » alors qu'en fait on parle plutôt de « C avec std::cout » (même si la POO tend à suivre ensuite).

Du coup je veux bien que quelqu'un me parse la ligne initiale. :-) Mon C++ est très balbutiant car j'ai peu d'expérience avec mis à part certains mécanismes directement utiles pour mon boulot.

Je comprends ce que tu dis. Cependant, encore une fois, tout est histoire de contexte.

Histoire de dresser un peu le tableau : les formations en informatique comptent entre 15 et 20% de femmes (en étant assez optimiste : en génie électrique et informatique industrielle, on est plus proche de 10%; en informatique de gestion, on tourne effectivement autour de 15-20%). On retrouve cette proportion dans les métiers de l'informatique (admin, dév, etc.) en général (peut-être un peu plus, autour de 20-30% si on considère les personnes qui aident à la rédaction et traduction de doc technique, specs, etc.).

Il faudrait que je retrouve des informations et sources fiables (et surtout, à jour), mais la dernière fois que j'avais participé à une discussion sur le sujet (sur LinuxFR je pense), on comptait entre 5 et 10% de femmes qui participaient régulièrement et activement à des projets open source (et ça diminuait encore plus si on se concentrait sur le côté développement uniquement). Un recherche rapide me donne cet article, qui cite entre autres cette publication sur la population de StackOverflow.

On observe donc que les femmes sont largement sous-représentées dans les projets libres, à hauteur de ¼ à ⅓ par rapport aux autres projets informatiques.

Ceci étant posé, lorsque tu dis

En gros : je préfère "si vous voulez encourager les gens à contribuer à linux, …" plutôt que "si vous voulez encourager les femmes à contribuer à linux, …"

… la seule chose que j'ai envie de répondre est oui, mais non.

Premièrement, je vais me permettre de faire une analogie pas si foireuse que ça (je pense). Prenons la mesure (et l'optimisation) de performance dans une application. Lorsqu'on évalue la performance d'une application, on utilise perf, gprof, oprofile, etc., et on détermine là où on perd le plus de temps dans le programme. Dans mon expérience, il y a généralement deux gros types de profils qui émergent :

1. On passe un temps relativement égal (à 5% près) dans toutes les fonctions du programme. Dans ce cas, on doit faire un boulot super chiant d'examiner les fonctions une à une et voir s'il n'y a rien d'évident à optimiser tout de go dans chaque fonction, mais de façon générale, on peut arguer qu'à moins de changer certains algorithmes ou structures de données fondamentaux pour le fonctionnement du système avec d'autres qui assurent la même fonction mais pour une complexité moindre, on ira grapiller les % de perf là où on peut.
2. Le programme passe un temps non-négligeable dans 1, 2, ou peut-être 3 fonctions, et le reste du temps est morcelé en fractions de pourcents pour toutes les autres. Par exemple : lorsque 50% du temps d'un programme est passé dans une fonction unique, il semble évident qu'on va devoir régler ce problème en priorité. Une fois que cette portion de code a été optimisée et son temps d'exécution est divisé par deux, deux choses arrivent : la fonction en question ne prend plus que 25% du temps original d'exécution total, mais aussi : en réalité, elle prend malgré tout 30% du nouveau temps d'exécution. Une fois que cette optimisation a été effectuée, on re-mesure le tout, car de nouveaux effets peuvent avoir été déclenchés et changer un peu la donne en termes de performance.

Si je reprends le cas de la représentation des femmes dans les projets libres :

1. Le HOWTO qui nous intéresse indique clairement qu'il concerne ce qu'il faut faire (selon ses auteurs) si un LUG veut attirer plus de femmes. Les quelques points que l'on a discuté (ne pas critiquer trop lourdement, encourager, etc.) sont à remettre dans le contexte d'une section qui parle principalement (sans exagérer) de ne pas avoir un comportement sexiste, de ne pas harceler une femme qui viendrait voir de quoi il retourne, et de ne pas réifier les femmes (je te laisse aller vérifier sur le lien que j'avais posté).
2. Si je reprends mon analogie de la mesure et optimisation de perfs, il me semble (personnellement) évident que le fait qu'il y ait des hommes qui n'oseraient pas contribuer au dév du noyau (et qui auraient les capacités pour le faire) est bien moins préoccupant que le fait qu'il y ait 70% de femmes en moins en proportion dans les projets libres que dans les autres projets info ¹. Il faut d'abord régler ce problème, on verra ensuite comment les choses évoluent.

Mon intuition est qu'une fois que le problème de comportement envers les femmes est résolu (et encore une fois, même s'il y a sans doute des instances de sexisme sur la LKML et dans le dév/la communauté libre en général, je ne pense pas que, par exemple, Torvalds soit lui-même sexiste), alors le cas des hommes dont tu parles le sera aussi par effet de bord.

En préambule, je partage globalement ton avis que l'article n'est pas bon, et cherche à donner un aspect sensationnel et apposer une étiquette « sexiste » à Torvalds qui à mon avis n'est pas méritée. Ceci étant dit, j'ai pas mal de problèmes avec ce que tu dis.

Dans n'importe quel boite, si un collègue te double à la cantine ou s'il se gare sur ta place de parking, tu lui demande gentiment de retourner à sa place, mais si c'est le boss tu ferme ta gueule et tu souris. C'est moche mais c'est comme ça.

Alors ça, ça dépend complètement de quel boss on parle. Si on parle de ton chef d'équipe, il y a de fortes chances que tu te permettes de dire quelque chose; ton chef de projet, idem; le n+3 ou n+4 ? Possiblement une remarque passive-agressive (« Hou la la, vous devez être pressé »). Ou alors effectivement tu peux t'écraser. Mais la vérité c'est que quelqu'un qui aurait un comportement injuste et toxique envers ses subordonnés ne bénéficiera pas forcément de la loi du plus fort / plus gradé. Même dans des environnement assez autoritaires (armée, etc.), un gradé qui joue un peu trop au petit chef devra faire très attention à ce qu'on lui sert à manger, à la façon dont les ordres vont être obéis, etc.

"Aurora got her first taste of programming as a six-year-old, […]" : très belle histoire… Qu'est ce qu'on en a à foutre ?

C'est une technique de narration pour montrer qu'on ne parle pas d'une personne qui se serait dit « l'informatique a l'air chouette, et en plus en ce moment on se fait plein de $$$, allons étudier ça à la fac » au sortir du lycée (j'en ai croisé beaucoup en IUT et en école d'ingénieur, hommes et femmes). C'est donc une façon de montrer qu'on parle de quelqu'un de passionné (et pour contribuer régulièrement au noyau, il faut bien l'être un minimum).

Mouarf ! Pour encourager les femmes à contribuer à Linux, il ne suffit pas de ne pas les discriminer (“Don’t stare and point when women arrive.”), mais il faut éviter de trop critiquer quand elles font de la merde et les encourager, les pauvres bichettes ?

Je trouve (j'ai peut-être tort) que cette remarque (celle que j'ai mise en gras) est carrément sexiste dans ce contexte. J'ai bien envie de te dire de peut-être aller vérifier ce qu'il y a dans chacune de ces sections (notamment celle qui parle de la critique trop appuyée) avant de commenter. Je te le copie ici (tiré du HOWTO en question) :

Women are socialized to be far more sensitive to criticism than men, as well as more critical of themselves. As a result, women are far more likely to be driven off by heavy or unfair criticism than men. When you're tempted to criticize, try to remember that absolutely no one was born knowing how to compile a kernel and that at one point, you didn't know anything about Linux, either. People will lose interest in something if they perceive themselves as being bad at it, so if you want someone to continue being interested in Linux, don't criticize her so much that she believes she isn't any good at it.

(C'est moi qui graisse.) Dans ce texte elle ne dit pas de ne pas critiquer, mais de faire attention à la forme de la critique, étant donné que par construction sociale, on ne conditionne pas les hommes et les femmes à prendre les choses de la même manière. On peut critiquer quelque chose plus ou moins sèchement, tout en restant factuel sur ce qui ne va pas.

Un exemple bête dans un autre contexte : j'avais des collègues (des femmes) qui me disaient que si leur directeur de thèse leur parlait comme le mien parlait à ses doctorants, elles se poseraient sérieusement la question d'abandonner la thèse, ou au moins elles pleureraient tous les soirs en rentrant. En réalité, les choses sont plus complexes que ça :

1. Quand il n'avait que des doctorants hommes, mon DT lâchait des blagues plus ou moins crues dans le bureau, plus ou moins sexistes.
2. Du point de vue attitude, il vouvoie tout le monde, mais ça ne l'empêche pas d'être brutalement honnête. Ça lui est déjà arrivé de me demander mon avis sur l'interprétation d'un truc qu'on avait mesuré, et de me répondre « ne soyez pas con, on sait que X et Y, ça ne peut pas s'expliquer comme ça ». Je ne l'ai jamais mal pris, car ce n'est clairement pas personnel, mais ça reste une façon de communiquer assez musclée.
3. Quand ma collègue est arrivée en thèse (un an après moi), les blagues crues ou sexistes se sont taries (alors qu'en fait ça la fait marrer, au moins pour les blagues crues). Et aussi, notre DT, qui pouvait toujours être direct et sec en termes de critique, faisait quand même très attention à sa façon de s'adresser à ma collègue, car il avait appris à ses dépends qu'on ne s'adresse pas de la même manière à différents types de personnes[ˆ1], pour des raisons principalement culturelles. Il restait « brutal » mais choisissait beaucoup plus ses mots avec elle qu'avec nous.

J'estime que la différence d'attitude que notre DT avait en fonction de ses doctorants était (et est toujours) une bonne chose. Tout le monde ne réagit pas pareil. Ça ne veut pas dire complètement aseptiser son discours, choisir des formulations ampoulées, etc. Par contre, ça veut bien dire qu'il faut s'adapter un minimum à son auditoire, si on désire pouvoir l'élargir (si ce n'est pas le cas et rester entre couilles, il n'y a rien à changer).

De même, dans le paragraphe « Do Compliment », on y explique :

Women have much lower self-confidence than men on average, and will generally judge themselves far more harshly than any outsider. Compliments help improve her self-confidence, which in turn keeps her interested in the subject. If she believes that she's not good at Linux, she'll probably stop working on Linux.

C'est quelque chose d'avéré dans pas mal de domaines techniques, et que j'observe dès les premières années de fac chez mes étudiants. Encore une fois, l'idée n'est pas d'applaudir à chaque nouveau patch soumis, ou même accepter, mais de faire du renforcement positif envers une population à qui on a répété depuis la naissance (ou presque), que les sciences (et en particulier les maths et l'info) c'est plutôt un truc de mecs, et qui est plus prompte que d'autres à faire une auto-critique sévère sans y être poussée. La liste qui est donnée dans le paragraphe est précédée d'un « The following are some guidelines for complimenting anyone » : hommes ET femmes. En résumé, ce qui est dit à propos des compliments est « il faut complimenter une contributrice sur des choses accomplies qui sont significatives, le faire précisément, et si on le pense sincèrement », et pas faire un compliment « générique » (du genre « tu te débrouilles bien avec Linux »). Le but du jeu est de donner confiance en elles aux femmes qui veulent participer au développement et à la mise en place (distributions, évangélisation, documentation) de Linux.

Une dernière chose à propos du HOWTO : il a été écrit dans le contexte du « voilà ce que vous devez faire si vous voulez voir plus de femmes participer à des groupes d'utilisateurs de Linux ». Comme je le dis plus bas, si la communauté des développeurs se dit que la population féminine existante est bien comme elle est, ben, pas de raison de changer de méthode de communication.

Je ne suis pas forcément d'accord avec tout ce qu'elle écrit, mais il y a quand même des points ou je suis 100% d'accord. En particulier l'idée de faire des critiques constructives et argumentées, mais aussi un minimum polies, c'est ce que je mets en pratique avec mes stagiaires ou les doctorants avec qui je bosse. Je peux être très sec par moments, dans le sens où j'explique que certaines choses que je demande ne sont pas discutables, mais ça ne veut pas dire que je vais descendre en flammes quelqu'un (sauf si c'est quelqu'un qui visiblement ne fout rien et est limite toxique pour le projet au final).

"Guido van Rossum, a white, male programmer (…)". Quel intérêt de préciser qu'il est blanc ? Parce qu'en plus d'être mâle il est blanc, il serait sensé être un affreux agresseur usant de sa dominance sociale pour écraser les autres ? En plus d'être sexiste, on va commencer à être raciste ?

Ben justement, il faut remettre l'article dans son contexte. Le New-Yorker est un magazine américain, lu en très grande majorité par des américains. Dans ce contexte (et dans le contexte que veut se donner l'article, celui de #MeToo, etc. – ce qui à mon avis est une connerie), l'idée est de montrer que, « voilà, on peut être un homme cis blanc et malgré tout être un allié et faire preuve de bonne volonté pour élargir sa communauté, et aussi malgré tout diriger un gros projet [libre] ».

Autant j'ai beaucoup de mal avec la caractérisation « homme blanc » en France, parce que historiquement et culturellement les choses sont beaucoup plus nuancées que ce que certaines personnes semblent vouloir nous faire croire en important un certain discours nord-américain, autant dans le contexte US je peux comprendre pourquoi dire ce genre de chose est important. En effet, le sexisme et le racisme sont loin d'être morts en France, mais aux États-Unis, ils se manifestent de façon souvent bien plus brutale (surtout la partie racisme, mais le sexisme n'est pas en reste). Pour le racisme en particulier, et la domination blanche de fait aux USA, les choses sont parfaitement explicables (esclavage sur place – contrairement à la France par exemple –, puis ségrégation pendant un siècle, et pour eux le racisme ouvert et brutal n'est que 50 ans dans le passé, sur leur propre territoire). Donc dans le contexte US de cet article, écrit par un journaliste nord-américain, ça ne me choque pas spécialement.

[ˆ1]: Il avait eu maille à partir avec une ancienne doctorante (et quelques collègues) au fil des années, une décennie plus tôt, car son attitude ne passait pas.

Dans l'article on peut lire :

Many women who contribute to Linux point to another open-source project, Python, as a guide for Linux as its [sic] faces its #MeToo moment.

Là je me suis arrêté pour crier en mon fort intérieur, « WTF ?! ». À la limite, qu'on parle du problème de l'absence de femmes dans le mouvement du Libre en général (bien plus que dans le milieu de l'informatique en règle générale), comme ça a été discuté ici moultes fois, why not. Mais « #MeToo » ? Pour des échanges principalement électroniques ? WTF.

Bon, je ne remets pas forcément en cause tous tes arguments, mais si je prends ce post et le parent dans le même fil, deux choses m'interpellent :

[tiré du post parent]

C’est ce qu’on appelle un Psychopathe ou pervers narcissique en bon français

À ma connaissance il n'y a pas d'équivalence directe (peut-être le deuxième est-il une sous-catégorie du premier, mais j'ai comme des doutes). Du coup je ne suis pas certain que tu saches de quoi tu parles sur ce sujet (je ne prétends pas du tout être expert moi-même, mais les notions de psychopathe et de PN sont précises en psychiatrie, et on ne peut pas les utiliser n'importe comment).

Dans le post auquel je réponds, tu parles de personnes atypique qui sont peut-être brillantes mais qu'il faut savoir gérer, et nous sommes bien d'accord. Par contre tu expliques que du coup il faut ne pas mettre de gêneurs dans les pattes de ce genre d'employé, car il ou elle peut être un(e)

leader naturelle

… Et ça, ça me semble antithétique[^1]. Quelqu'un qui serait naturellement un(e) leader, par définition, arriverait suffisamment à produire de l'émulation. Si un(e) employé(e) empêche un leader quelconque de faire son boulot, c'est simplement une personne toxique, indépendamment de qui est le leader.

[ˆ1] J'ai bien vu que tu émets des conditions sur une certaine introspection, etc., mais je ne crois pas que ça invalide mes arguments.