lasher a écrit 2738 commentaires

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.

D'où mon « généralement » pour les UB. ;-)
Pour MapReduce il s'agit réellement d'un modèle de programmation parallèle assez limité. Et qu'on parle d'API (ce qui est le cas pour MPI par exemple), ou de syntaxe (pour Erlang, OpenMP, Java, ou C#), ça reste des modèles de programmation et d'exécution parallèles.

L'article de Hoare est très bien, dans le sens où il propose son idée, mais donne aussi des problèmes connus de programmation concurrente pour montrer comment son langage y répond. Par contre, ça reste un article un peu académique sur la forme.

Hoare a aussi écrit un bouquin complet sur la question mais c'est tout plein de maths/info théorique. J'avais trouvé il y a un moment cette présentation qui me semble pas mal pour introduire le concept.

Tu peux enlever les guillemets à « "modèles de programmation parallèle" ». ;-)
Plus sérieusement, tu as techniquement raison, mais ce qui est intéressant avec les langages qui offrent un modèle de programmation parallèle, c'est qu'ils ont aussi tendance à définir un modèle d'execution parallèle qui va avec. Dans le cas de C11/C++1x c'est un modèle très (trop) relâché selon moi, mais c'est parce qu'ils sont tributaires de l'existant (Pthreads en particulier, mais aussi le besoin de pouvoir laisser une machine parallèle optimiser tout un tas de trucs à sa façon).

Mais les langages/modèles de prog de type OpenMP offrent un modèle d'exécution expliquant quand une région parallèle peut être créée (modèle de concurrence), quel est le mode d'orchestration des threads (modèle de synchronisation), et comment et dans quel ordre la mémoire peut être accédée (modèle mémoire). Dans le modèle de synchro, on compte par exemple une proposition de moniteurs dans OpenMP (via la construction critical), etc. Maintenant, ça n'empêche pas qu'il reste possible d'avoir une data race, mais justement, c'est l'intérêt d'un modèle d'exécution : il spécifie un modèle mémoire. Dedans, on spécifie le mode d'adressage (au minimum, si on a une mémoire partagée ou distribuée), et le modèle de constance mémoire (memory consistency). Dans ce dernier cas, on spécifie dans quel ordre les différentes opérations mémoire peuvent arriver, s'il y a une différence entre des opérations normales ou des opérations « synchronisantes » (par exemple dans OpenMP, il y a la clause atomic; dans Java, il y a le mot-clef volatile; etc.).

De façon générale, la question n'est pas tant de savoir s'il peut y avoir un conflit sur les données partagées — dès lors que tu autorises le partage mémoire implicite, ça peut arriver. Cependant, si le modèle mémoire que tu utilises est logique/compréhensible, tu peux espérer débugger ton code plus facilement qu'avec un modèle complexe. Ironiquement, je pense qu'il est plus facile de débugger du code C++ concurrent, car data race = UB, et donc généralement ça veut dire « on laisse le matériel sous-jacent se débrouiller », alors qu'en Java par exemple, c'est plus subtil, et potentiellement le compilateur a fait des trucs pas cool (aka « des optimisations » — qui sont légales hein).

Il y a même un bouquin chez O'Reilly qui doit être un peu dépassé maintenant, mais qui était le résultat d'un cours de programmation système où les profs faisaient étudier le code de Linux 2.6 (donc pas très loin avant 3.0) et c'était il y a ~10 ans. Ça se fait « très bien » mais il y a beaucoup de boulot, et ça suppose une forme par projet où les étudiants doivent modifier un ou des aspects du noyau de façon bien précise et balisée.

Il tenait un « journal secret » sur sa page facebook qui était ma foi très sympathique à lire.

En même temps, même sans être libre, un auteur peut demander explicitement à ce qu'on retire son nom. Par exemple : on peut écrire une histoire "d’après l’œuvre de…", ou bien simplement dire que c'est "dérivé de " sans préciser les auteurs (cas de Watchmen, From Hell, etc., écrits par Alan Moore). Œuf corse, si le (ou les) auteurs en question ne sont pas consultés car l’œuvre est libre, c'est plus compliqué, car on peut redistribuer le tout massivement avant que les auteurs ne puissent demander à être retirés des crédits.

Mais globalement que les solutions envisagées aient des désagrément ça ne doit surtout pas être l’argument massue pour ne rien changer.

On est bien d'accord. Dans mon exemple pour tripler la fréquence de certaines lignes, il y a déjà le fait que les bus ont des voies qui leurs sont réservées (et donc limite les problèmes de trafic), mais effectivement, je n'imagine pas pouvoir généraliser ce genre de mesure sans incitation au covoiturage (comme j'en parlais auparavant). Les gens se plaignant du flicage des voitures auront raison dans le sens où on contrôlerait effectivement qu'ils ne se placent pas dans une file réservée aux transports contenant au moins 2 personnes, mais auraient aussi « tort » dans le sens où on ne cherche pas à leur interdire de circuler du tout (il faudrait toujours qu'il y ait une voie ou deux qui soit ouverte à tous de toute manière), mais bien à inciter les gens, certes en rendant la circulation en voiture plus contrainte/contraignante, à user de transports en communs.

J'avais commencé à faire une réponse plus générique, mais comme effectivement la question sentait l'exercice (et avec le recul, au vu des questions supplémentaires qui ressemblent plus à des exigences), j'ai préféré donner une solution « littérale » pour la chaîne donnée.

Ceci étant dit, il y a plusieurs façon de faire. Par exemple :

s/c;1;2;3/c 1 2 3/

(Comme tu parles d'une chaîne spécifique, je donne une solution spécifique)

Si tu parles de « banalités » dans le sens « c'est malheureusement une conséquence banale de la vie dans les transports d'IdF » je ne peux qu'acquiescer. Mais si c'est pour en gros rejeter cet argument, au prétexte que ça ne nous dit pas « comment on s'en sort », je trouve ça bien condescendant : « on s'en sort » aussi en prenant en compte les contraintes de chacun et en essayant de trouver un compromis. Si mon pote avait un bus qui allait dans son coin à des horaires et fréquences corrects, même si le RER ne se pointait pas, il aurait au moins cette alternative pour rentrer chez lui.

Pour moi, la solution est de tripler la fréquence des bus, car dans le court terme, c'est le seul transport public qui peut être triplé en fréquence sans pour autant nécessiter d'énormes travaux au niveau des infrastructures. En plus des voies de bus/taxi, on pourrait aussi faire comme en Californie, et limiter certaines voies au covoiturage (dans certaines villes c'est déjà en train ou bien déjà mis en place). Ça veut aussi dire fliquer bien plus les voitures sur la route (et les radars automatiques ne pourront pas vraiment aider dans ce cas). Évidemment comme d'habitude, le problème tient aussi aux coûts.

Dans le moyen terme, au moins en IDF, ce qui aiderait pour de vrai serait que le grand Paris se fasse en temps et en heure, mais on sait déjà que c'est compromis (surtout avec les JO qui se pointent…).

Le problème étant que, lorsqu'on fait des journées de 10-12 heures comme le pote en question, si les trains roulent normalement, alors pas de souci, mais si à l'heure de pointe le train se traîne, et qu'en heure pas-de-pointe il se pointe pas du tout, ben la journée qui allait déjà être de 12h mini (transports et pause déjeuner compris) devient une journée de 13 ou 14h.

C'est aussi pour ça que j'ai commencé par expliquer que le pote en question avait tout d'abord tenté de venir en transports. Il n'était pas spécialement fan de devoir payer une assurance auto, l'essence, etc. Mais au final, ça lui rend la vie tellement plus simple (parce que non, il ne peut pas simplement changer de boulot, ou d'appart : il est en couple, et il n'est pas le seul impliqué dans la décision du lieu de vie).

[À propos de changement d'inconvénients pour des niveaux de nuisance comparable] C’est acceptable, globalement si les problèmes sont de désagrément similaire mais que la collectivité y gagne globalement

Je suis d'accord avec toi sur le principe. Sauf qu'il ne faut pas s'étonner que les individus décident de choisir ce qui rend leur vie à eux plus simple si les moyens existent. Dans le cas de mon pote, le soir après 20h (donc plus en période d'heure de pointe), il met moins d'une demi-heure en voiture pour arriver dans son quartier, et ensuite moins de 10 minutes pour trouver une place pour se garer en moyenne. Rajoutons aussi 5 minutes de marche à pied pour rentrer chez lui. Soit au total ~45 minutes. En RER (qui se trouve à ~5 minutes à pied de son boulot), il mettrait déjà ~45 minutes rien qu'en transport, plus 10 minutes pour rentrer chez lui depuis la gare. En soi, mon pote était OK pour « perdre » 15' le matin et idem le soir en transport, mais à condition de pouvoir rentrer chez lui à des horaires corrects (i.e., vers 21h). Ben en RER, il ne rentre pas avant 21h30, en fonction du bon vouloir du réseau transilien.

Un autre exemple bête : je suis un fervent défenseur des transports en commun (que j'utilise tous les jours — je n'ai pas et ne veux pas de voiture). Hé bien, malgré tout, plus jamais on ne m'y reprendra à prendre les bus PC1/PC2/PC3 (qui font des arcs de grands boulevards autour de Paris), même si en théorie ce sont les moyens les plus courts pour aller de mon ancien chez moi parisien jusque chez certains amis : je n'ai pas spécialement envie de respirer l'odeur des aisselles de mes voisins, et les miennes ne doivent pas sentir bien meilleur à leurs narines non plus. On y est ultra-serré, on manque de rater son arrêt tellement il y a de monde devant soi, etc. Évidemment, si magiquement la fréquence de ces bus pouvait être doublée ou triplée, peut-être que je reconsidérerai la chose, car on pourrait respirer un peu mieux dans le bus. C'est le même problème sur certains segments de certaines lignes de métro ou de RER aux heures de pointes (RER A & B vers les Halles, ligne 13 près de la Fourche, ligne 7 près de Maison Blanche, je vous vois !). Peut-être que c'est un problème purement francilien, mais avoir l'impression d'être parqué comme du bétail à certaines heures est vraiment désagréable, et franchement, fuck le bien de la société dans ces cas précis.

J'expliquais les difficultés d'un pote qui s'était résolu à acheter une voiture car les transports en commun n'étaient pas fiables/prenaient trop de temps dans son coin. On m'a répondu « bah alors il n'a qu'à habiter plus près de là où il bosse ! » C'était un autre pote, alors je n'ai pas décidé de lui foutre ma main à la gueule. Le côté « faisons fi de toute contrainte extérieure histoire de rendre le problème simple à résoudre », ou encore « explique moi ton problème je te dirai comment le contourner avec une méthode au moins aussi désagréable que le problème initial, mais différent » est bien représentative de certaines personnes malheureusement.

Je réponds très tard, mais selon moi, ce qu'on apprend sur la documentation de code, etc., vient principalement pour 2 raisons:

1. Tout le monde n'est pas un real programmer¹: pas mal de gens sont « moyens » en termes de programmation, et ont besoin d'une doc « à part » pour pouvoir rapidement trouver la doc des interfaces².
2. Il y a des environnements où le turnover est plutôt énorme (et en France c'est encore plus vrai) : sans une doc un minimum plus détaillée que la « méta-doc » évoquée, tu te retrouves potentiellement avec une catastrophe ambulante…

La combinaison des deux points précédents peut être fatale je pense.

Ce n'est pas exactement la même situation : comme je le dis un peu plus bas :

• Pendant toute la période où parcoursup était ouvert, tout était ouvert 24h/24 (nuit comprise donc)
• Au mieux, on pourrait imaginer que si la date limite est le jour X du mois Y, alors on peut soumettre jusqu'à 23:59:59 au jour X.
• En pratique, on doit considérer que tout le monde n'a pas forcément accès à un PC hors heures « normales » de bibliothèques, etc., donc avoir une deadline qui correspond aux heures administratives ne me semble pas complètement déconnant. Ça correspond possiblement aussi aux horaires où du personnel peut régler des problèmes/pannes si jamais elles ont lieu, car encore officiellement au bureau.

L'image que tu postes n'est pas franchement pertinente selon moi : il ne faut pas oublier qu'on parle du dernier jour pour la soumission de vœux d'élèves, et en particulier de la dernière heure (ou des deux dernières heures). Alors oui, les élèves (et les étudiants ­— et, soyons honnêtes, beaucoup d'adultes en règle générale) s'y prennent souvent à la dernière minute, mais autant on peut conspuer l'administration car elle n'a pas prévu le cas de grosse montée en charge en prévision du dernier jour (et du coup il s'agit surtout de prévoir que pendant 8h d'affilées, on aura une grosse charge quoi qu'il arrive), autant dire « ouin c'est pas juste, moi je peux me coucher plus tard que d'autres » ça me semble un peu ridicule : parcoursup était ouvert dès le 22 janvier.

TL;DR: gueuler contre le SI de parcoursup car ils n'ont pas supporté la charge du dernier jour de soumission, je comprends. Gueuler contre le fait que ça se termine arbitrairement à 18h (heure où plus aucun personnel ne peut aider si y'a plantage/problème), je trouve que c'est un peu de la chouinerie.

Dans tous les cas, il ne s'agit pas de niveler par le bas, ni de nier leurs spécificités aux usagers (ce qui est le thème de l'image postée).

Pour faire vite : tu supposes que tout le monde a accès à un ordinateur avec une connexion internet (décente) h24. Sauf qu'on ne peut pas nécessairement faire cette supposition pour des particuliers dans le cas général.

D'ailleurs, je me souviens qu'il y a vingt ans quand j'ai utilisé l'équivalent de l'époque, l'échéance était à minuit. À 22h, le serveur (Minitel) était saturé mais à 23h30 il n'y avait plus de problème pour se connecter

Ça me semble raisonnable, mais il ne faut pas oublier que même il y a 20 ans, on pouvait louer/emprunter un minitel gratuitement aux P&T (pas d'abonnement) tant que c'était la version noir et blanc.

Pour donner un exemple dans un autre domaine : je donne cours en IUT. J'aimerais bien pouvoir supposer que tous mes étudiants ont un ordinateur (fixe ou portable) chez eux, et du coup leur dire « vous pourrez finir le TD [ou le TP] chez vous ». Sauf que je ne peux pas, car ce n'est pas équitable pour tous mes étudiants.

Enfin, il ne faut quand même pas oublier que toutes les autres nuits et tous les autres jours qui ont précédé la date limite on pouvait soumettre à n'importe quelle heure.

Tu as raison, mais après, typiquement, pour les JPO, les facs/prépas/etc. font exprès de les organiser en Décembre/Janvier/Février justement pour que ce soit encore « frais » dans la tête des lycéens et de leurs parents.

Concernant les choix entre prépa, STS, IUT, fac, etc., comme tu as 10 choix (sans compter les sous-choix dans une catégorie donnée), tu peux relativement facilement les inscrire. Il s'agit vraiment principalement d'un problème de méthode à la rache™.

C'est aussi vrai dans le supérieur, soit dit en passant. Enfin, pas moi, hein, mais les autres… O:-)