lasher a écrit 2732 commentaires

Note: Je ne suis pas complètement d'accord avec Briaeros, mais grosso-modo, je pense être sur la même longueur d'onde.

Concernant les jobs en info qui ne demandent pas 5 ans en informatique : je dirais qu'un technicien avec un DUT (ou un BTS, ça dépend des contextes) est largement capable d'assurer une grande (la majeure ?) partie du développement informatique demandé par les boites. J'ai acquis plus de bonnes habitudes en 1 and d'IUT concernant le développement logiciel (et confirmé en 2è année) qu'en 3 ans d'école d'ingénieur. Et surtout, ce qui m'a fait grandir en tant que développeur, c'est la pratique lors des stages, en plus des projets parfois un peu trop « scolaires ».

Ce qu'on m'a demandé de faire en projet de fin d'étude en école d'ingénieur, j'étais franchement capable de le faire en fin d'IUT (disons que ça m'aurait sans doute demandé 1 mois de plus, vu que j'ai principalement fait de l'auto-formation aux différents frameworks Java que je devais utiliser à l'époque).

Il y a aussi beaucoup de choses qu'on sait (soit théoriquement, soit en pratique) une fois arrivé en fin de second cycle, mais qu'on devrait pouvoir savoir faire aussi après un certain temps à bosser en tant que professionnel. Et donc la seule différence, c'est que dans un cas, il faudra former le technicien en interne (mais ce sera a priori spécialisé et une formation courte, voire appris « sur le tas » grâce à un collègue), là où dans l'autre cas, l'état paye (via le master ou l'école d'ingé).

Ceci dit, ce que je raconte est spécifique à l'informatique, ça ne veut pas dire que c'est vrai pour toutes les formations (la formation des médecins dont tu parlais est un bon contre-exemple).

Les deux syllabaires, les ~10000 idéogrammes du chinois simplifié, etc., n'entrent en compte que pour le nombre de combinaisons possibles (sans tenir compte de la grammaire ou de la logique inhérentes à ces langues). Oui, les deux syllabaires du japonais peuvent (et sont) être mélangés dans une même phrase, mais au final, ça ne fait que 2×46 symboles avec la ponctuation et le chiffres en plus. Et tout ne sera pas utilisé en même temps.

Au final, si j'écris « わたしはラシャーと私はのフランスアム » (mélange d'hiragana et katakana, avec un idéogramme, car j'ai oublié tout mon japonais et j'ai laissé google traduire), je me retrouve avec 18 caractères, donc la plupart sont sans doute codés sur deux octets, et un peut-être sur plus, soit ~40 octets pour une phrase simple, mais comme on parle de noms de fichiers, ça devrait aller. :-)

C'est "l'esprit" des gens conseillant. Si pour une personne qui a un problème avec des espaces dans un nom de fichier, on lui sort "tu as tort, remplace par des underscores, comme moi", ça ne donne franchement pas envie de rester sur cet OS. C'est un "détail", mais détail+détail+…

Pour le coup je suis assez d'accord. Gamin, j'utilisais DOS, puis quand Windows 95 est arrivé, j'ai usé et abusé des noms avec espaces (malgré l'abstraction un peu ratée, vu qu'utiliser un terminal DOS pouvait parfois toujours être nécessaire, et du coup on se retrouvait avec monfic~1.txt au lieu de monfichieràmoiquejaime.txt). Avec bash_completion je peux facilement utiliser des espaces en ligne de commande (il rajoute les guillemets tout seul, et je suis sûr que zsh peut faire pareil), mais c'est vrai que mon réflexe est d'utiliser des underscores, et c'est vrai que je peste un peu contre les espaces dans les noms de fichiers, mais je me rends bien compte que c'est un réflexe de vieuxcon™®©.

En règle générale, les espaces dans les noms de fichiers ne gênent absolument pas lorsqu'on utilise une GUI (je n'ai pas trouvé d'exemple gênant en tout cas), mais en ligne de commande ça force juste à rajouter quelques symboles (guillemets), mais bon, on s'y fait. :-)

En préambule, notons que je ne suis pas la personne à qui tu répondais au début. Je ne cherche pas à « avoir raison » à tout prix, mais simplement il y a tout un tas de gens qui utilisent des langages non déclaratifs, non fonctionnels, et qui ont un réel intérêt à utiliser des globales dans ce contexte.

J'ai un peu de mal à comprendre ce que tu veux dire, mais j'ai l'impression que tu te compliques la vie : une variable en Erlang est comme une variable en C/Java, à quelques différences près :
- tu ne peux pas déclarer de variable en dehors d'une fonction
- tu ne peux affecter qu'une seule valeur à une variable.

Ben, « valeur » = variable à affectation unique. C'est peut-être un peu pédant comme terminologie, mais c'est celle qui est utilisée par une bonne partie des gens qui font des langages et de la compilation (« single assignment »). Le fait que tes variables soient aussi confinées à l'intérieur d'une fonction fait aussi que tes fonctions semblent devenir pures. Du coup, j'aimerais savoir ce qui te fait dire qu'Erlang n'est pas un langage fonctionnel pur¹.

J'ai l'impression que tu cherches à tout prix à avoir raison. Tu peux tourner les choses dans le sens que tu veux, il n'y a pas de variable globale en Erlang.

Absolument pas. Je suis intervenu dans la discussion parce que s'il n'y a pas de variable globale, je me demande comment on fait pour passer un (ensemble d')état(s) entre différents processus. Internet me dit « passage de message », ce qui implicitement indique une sérialisation des valeurs en cas de « conflit » (si 2 processus veulent modifier la même valeur qui est rendue accessible/visible par un processus Erlang).

Je n'ai jamais dit le contraire, je suis seulement d'avis qu'utiliser une variable pour ça est une mauvaise idée. La Lisibilité du code est une raison (qui pour moi est suffisante à elle seule).

Et comme d'habitude, tout dépend du contexte. :-) _kaos_ donnait l'exemple d'un mutex globalement accessible. Bon, perso, je créerais quand même une structure de données pour encapsuler le machin, mais c'est parce que j'aime pas les gros verrous qui deviennent potentiellement de gros points de contention dans une appli. Mais son exemple est parfaitement sûr : la sémantique-même d'une variable d'exclusion mutuelle impose de passer par des fonctions qui garantissent l'accès exclusif. Donc un mutex déclaré globalement, à défaut d'être performant, est sûr.

En général je pense que nous sommes d'accord : une variable globale non contrôlée, c'est mal. L'utilisation d'agents ou d'objets pour encapsuler la variable, ou bien limiter sa portée est évidemment une bonne pratique.

Plus spécifiquement, concernant errno, j'ai pas de doc sous la main (et la flemme, il est près de 5h du mat ici, et au lieu d'aller pioncer je te réponds… :-P) mais il me semble que dans les systèmes POSIX modernes, il y a une transformation de errno en mode TLS (thread-local storage), histoire que chaque thread ait sa copie. Évidemment, c'est pas standard pour le langage C (et pas sûr que C11 ait adopté la pratique), mais ça permet quand même d'éviter tout plein de trucs chiants.

L'important c'est donc de bien spécifier les modes d'accès aux variables globales : soit complètement globales « lexicalement », soit globales sous un espace de nom, de classe, etc., mais qui peuvent quand même risquer un accès concurrent. Dans un soft que je maintiens vaguement, j'ai rajouté tout un ensemble de variables globales qui servent principalement à l'initialisation au tout début du programme. Certes, ces variables se trouvent dans un espace de nom, mais bon, si tu utilises mon truc, tu vas vite arriver à faire un using namespace tartempion; parce que sinon ça devient vite relou : ces variables sont souvent lues (et uniquement lues) par les threads générés ensuite. Bref. Oui, il faudrait que je prenne le temps d'écrire des fonctions qui vont se charger d'accéder à la variable, et au minimum garantir qu'elle sera mise à jour « atomiquement ». Mais en pratique, le main vérifie quelle valeur donner à ces variables une fois pour toutes et tous les threads vont ensuite simplement les lire, et si par malheur un utilisateur les modifiait, ben, ça ne changerait sans doute pas grand chose (oui, ça pourrait provoquer des bugs, mais ce serait quelque chose d'assez aisé à traquer).

… Et oui, je m'invente des excuses pour ne pas mieux encapsuler mes variables globales (parce que c'est du code de recherche avec grosso-modo 5 utilisateurs qui savent ce qu'ils font).

Je n'ai jamais fait d'Erlang, donc je dis sans doute une connerie. En supposant qu'on parle de langage fonctionnel pur (ce qu'est censé être Erlang si je me souviens bien), il n'y a généralement pas de « vraie » variable, et uniquement des « valeurs ». Du coup, il y a uniquement des affectations uniques, et si l'on « modifie » la valeur, alors en réalité on crée une nouvelle valeur qui est visible pour l'appelant ou bien pour la portée lexicale « inférieure ». Du coup une valeur créée « tout en haut » de l'arbre de visibilité syntaxique sera visible de tous, mais ne pourra être modifiée (puisqu'il s'agit d'une valeur et pas d'une variable).

Il n'y a donc peut-être pas de variable globale à proprement parler en Erlang, mais il y a des valeurs globales (et en demandant à un moteur de recherche comment créer des variables globales en Erlang, on tombe sur différentes réponses qui proposent de créer un process/serveur pour gérer l'état de la/des variables, ou bien de passer par un équivalent de table associative, ou bien…).

Plus généralement, j'essaie d'éviter les globales comme la peste (parce que je code des logiciels très bas niveau et lourdement parallèles, mais aussi que d'un point de vue génie logiciel, c'est pas top), mais pouvoir créer/modifier un état global à tous les threads, à certains niveaux du programme, oui, c'est utile. À noter que je compte une variable de classe comme une globale, et idem pour une variable déclarée dans un namespace en C++ par exemple. mes variables « totalement » globales sont généralement en lecture seule.

Les licences sans copyleft fonctionnent très bien : […]

J'irai même plus loin : Nessus a changé de licence pour passer de GPL à un truc propriétaire en grande partie parce que des entreprises qui font du « consulting sécurité », n'avaient aucun scrupule à virer les copyrights/crédits, modifier/corriger les bugs, et utiliser Nessus en disant qu'ils étaient à l'origine du produit. Et comme les « consultants » ne laissaient pas leur soft derrière eux (ils faisaient juste le scan des réseaux, etc.), il n'y a aucune preuve matérielle de la manipulation.

Plus prosaïquement : même si les boites avaient été honnêtes et avaient dit qu'elles utilisaient Nessus, puisqu'elles ne distribuaient pas le soft aux clients, rien ne les obligeait à distribuer le code source modifié avec leurs patches.

GPL ou BSD/MIT, dans ce cas, n'a rien changé.

En droit français (et européen si je ne m'abuse), si le code a été publié, à moins d'avoir déposé le brevet avant de publier le code, tu ne peux plus breveter quoi que ce soit (car la publication fait automatiquement rentrer le procédé en état de l'art). En droit US, tu as un an à partir de la publication pour breveter ton invention (que la publication soit sous forme de journal, code source, présentation, etc., n'importe pas). Au-delà, la publication devient de nouveau du « prior art ».

Pour moi, un très gros contributeur, c'est juste un contributeur qui publie régulièrement des patch. Ça n'a, contrairement à ce que j'ai pu laisser ressentir (mea culpa d'ailleurs) rien à voir avec la quantité de lignes de code. Ceci dit, je crois (et je ne vais pas vérifier, pour deux raisons: 1) perte de temps 2) remise en question difficile) que les plus gros contributeurs au LL sont des gens non affiliés. Un logiciel libre qui aurait une personne (physique ou morale) comme contributeur majeur, c'est typiquement le genre de logiciel libre que j'essaierai d'éviter en milieu professionnel, car il aurait peu de potentiel de pérennité.

Alors euh, en 2007, d'après Andrew Morton, 80% des contributeurs réguliers au noyau le faisaient parce que c'était leur job. Les 20% restants sont bien des amateurs (dans le sens « noble » du terme). Tout ça pour dire que si, dire qu'une boite X est bien un gros contributeur a du sens : et ce qui fait la pérennité du code n'est pas qu'une boite y ajoute beaucoup et régulièrement ou pas, ou bien au contraire que ce soit un individu. Tant que le patch peut être testé/qualifié par les gens qui sont responsables de leurs branches respectives (avec L.Torvald tout en haut et un droit de véto si nécessaire), je ne vois pas où est le risque. Au contraire : les gens qui sont responsables de diverses branches du noyau appartiennent à des boites différentes (Red Hat, Google, etc.) : il n'y a aucun intérêt à laisser l'autre boite être seule responsable de certains aspects du noyau.

Parce que (comme souvent :-P) tu apportes une info intéressante et factuelle (LO 4.4 qui vire les commentaires en Allemand) et juste après tu fais une remarque pleine de condescendance en disant que tu toi tu as la vision d'être le roi du monde du code alors que les autres se contentent d'être maires ou chefs de collectivités locales (comment ça, j'exagère ?)¹.

Ceci étant dit, je reste sur mon avis précédent : le contexte joue énormément. Le logiciel (libre) utilisé pour implémenter le serveur des impôts, etc., aura certes des parties qui pourraient, peut-être, à terme, être réutilisées dans un autre logiciel pour implémenter un autre type de logiciel qui soit servira à la déclaration d'impôts d'autres gens, ou bien à implémenter un autre type de logiciel côté serveur qui s'interfacerait avec les serveurs de l'État français. Mais en règle générale, le contexte est franco-français, payé par et pour les Français, et je ne vois pas vraiment en quoi commenter en Anglais servira à qui que ce soit au final (au contraire, si jamais des formules, hypothèses, etc., sont exprimées dans les commentaires, on pourra ainsi plus facilement les copier-coller à un non-informaticien spécialiste des impôts et qui sans doute a un niveau limite en Anglais²).

A contrario, le soft que tu développes a clairement un contexte transnational : il est logique que tu commentes en Anglais, car ça encourage les contributions/corrections de bugs, tout en permettant de distribuer le tout à des clients non-francophones ou germanophones. Maintenant, je me dis que si une équipe chinoise développait un soft pour le marché chinois, elle n'en aurait absolument rien à faire (au moins au début) de développer en Anglais : (1) Le niveau en anglais de la plupart des chinois n'est franchement pas top, et (2) leur marché est déjà potentiellement composé de 1,3 milliard de client (et plus raisonnablement/de façon plus réaliste, sans doute ~300—500 millions). C'est à peu près ce qui se passe avec les clones de Facebook & co en Chine.

Mince, tu as raison. Je voulais trop que ce soit Joy. :)

Oui, parce que l'équipe voulait pouvoir élargir son nombre de contributeurs. Du coup, le seul moyen de faire ainsi est de choisir une langue qui est comprise par le plus grand nombre de développeurs potentiels.

Cependant, j'ai des anecdotes, comme par exemple une connaissance qui bossait (en Europe) pour une boite japonaise. Il préférait quand les dév japonais commentaient en Japonais, vu que leurs tentatives d'écrire en Anglais rendaient souvent le code incompréhensible.

Mais tu vois ce que je veux dire ? Pour moi, les commentaires sur les structures de données, ou bien qui précèdent la définition d'une fonction sont une pratique saine. Idem pour un point de code qui risque d'être idiomatique plus loin dans le code, ou pour quelqu'un qui connaît le domaine que le code modèle. Par exemple, il m'est déjà arrivé d'écrire un truc du genre (en Perl) :

open my $fh, '<', $filename or die "Couldn't open $filename: $!";
# this is idiomatic. More info: <url>
my $raw;
{
    local $/;
    $raw = <$fh>;
}

# do something with full-text-as-string in $raw

Le "slurp" est un idiome qu'on retrouve dans plein de bouquins / articles qui parlent de Perl. Du coup, plein de gens ont même créé une fonction pour « généraliser » le procédé, mais c'est tellement rapide à écrire que la plupart du temps personne ne s'emmerde à faire ça. Comme je savais que des stagiaires auraient peut-être à relire cette partie du code, j'ai rajouté une URL qui explique ce que ça fait, mais c'est vraiment uniquement pour eux que j'ai fait ça. Et je ne le fais que dans le fichier qui sera le plus vraisemblablement ouvert en premier. Dans les autres je ne m'embête pas.

Super, je vais pouvoir renommer mes noms de politiques d'ordonnancement de threads en

typedef enum {
  ROUND_ROBIN, 
  ROUND_ROBIN_RANDOM_STEAL, 
  ROUND_ROBIN_RNDROB_STEAL,
  PUSH_THREADS_UNTIL_QUEUE_IS_FULL_THEN_GO_TO_NEXT_QUEUE,
  PUSH_THREADS_UNTIL_QUEUE_IS_FULL_THEN_GO_TO_NEXT_QUEUE_RANDOM_STEAL,
  PUSH_THREADS_UNTIL_QUEUE_IS_FULL_THEN_GO_TO_NEXT_QUEUE_RNDROB_STEAL,
} Policies;

… Ou alors, j'écris un truc du genre

typedef enum {
   RNDROB,               // Round-robin policy: push thread in scheduler, then move on to next queue
   RNDROB_RDMSTEAL,      // RNDROB + random stealing of tasks if idle
   RNDROB_RNDROBSTEAL,   // RNDROB + steal in a specific order
   PUSHFULL,             // Fill a thread queue until it's full, then move on to next thread queue
   PUSHFULL_RDMSTEAL,    // PUSHFULL + random stealing
   PUSHFULL_RNDROBSTEAL, // PUSHFULL + ordered stealing
} Policies;

Je trouve qu'utiliser l'anglais pour les noms des variables, fonctions, etc., dans le code, c'est une pratique saine (mais comme tu le fais remarquer, du « vrai » anglais, et donc il faut éviter les faux amis, etc.). Par contre, des commentaires dans la langue de l'équipe qui programme, ça ne me choque pas (et c'est même mieux que de tenter de parler anglais si on n'a pas un niveau assez bon).

Perdu. Microsoft (ainsi que d'autres boites) a tenté d'imposer sa définition du terme « open source » en disant qu'ils proposaient des licences « open source » de Windows à certain de leurs clients, ce qui effectivement donnait accès au code source de l'OS mais ne donnait en rien le droit de redistribuer, et je ne sais même pas s'il y avait droit de modification, même en interne (je suis sûr qu'au moins pour certains contrats/clients c'est possible).

En résumé, un « logiciel libre » satisfait aux 4 libertés exprimées par Stallman et la FSF : liberté d'exécuter le programme comme tu le désires, de l'étudier et le modifier, de le distribuer pour aider ton voisin, et même de distribuer des versions modifiées. Mais un logiciel dit « open source » fait de même. La différence entre « libre » et « ouvert » est philosophique : un logiciel libre respecte les 4 libertés pour une raison morale, alors qu'un logiciel ouvert le fait pour des raisons techniques. Je détaille plus bas.

Le point de vue « open source » dit en gros qu'un logiciel devrait être redistribuable, modifiable, etc., car d'un point de vue pragmatique et technique c'est comme ça qu'on obtiendra les meilleures versions d'un logiciel donné. Il y a un côté très « darwiniste » de ce point de vue : seuls les meilleurs logiciels libres survivront.

Dire qu'un logiciel est « libre » c'est dire qu'il satisfait les 4 libertés énoncées par Stallman et la FSF, exactement comme pour les logiciels open source. Cependant, dans le cas des logiciels libres, la raison de soutenir cette façon de faire du logiciel est que la connaissance ne devrait pas être enfermée derrière des barrières propriétaires. Entre autres choses, il y a l'idée qu'une fois que le logiciel fait fonctionner une machine que tu as achetée, tu devrais pouvoir faire ce que tu veux de la machine, et donc par transition, tu devrais pouvoir modifier le logiciel qui la contrôle, et distribuer tes modifications à qui tu veux. La liberté qui est visée est celle de l'utilisateur final, plus que celle du développeur qui a développé le logiciel.

Zut, j'oubliais :

Google se sert effectivement des produits open source pour faire fructifier son business. Les licences open source n'interdit en aucun cas des pratiques commerciales. Mais contrairement à Microsoft, Google contribue énormément au noyau Linux et à Android, les produits Google sont bien basés sur ces mêmes logiciels open sources.

À un moment les mainteneurs du noyau ont dû menacer de séparer les modifications faites pour faire marcher Android, tellement ils ne faisaient aucun effort pour que tout soit homogène. Et en pratique, sans être aussi mauvais, la gestion du source d'Android ressemble quand même pas mal à une quasi-tivoïsation : lorsque des gens essaient de faire une distribution Android indépendante, s'ils cherchent à ajouter leurs propres modifs qui ne correspondent pas aux critères qualité de Google (perte en autonomie, etc.), ils se font menacer d'être ± coupés du play store… Je comprends que c'est parce que Google ne veut pas perdre en image de marque, et que du coup une fonctionnalité utile mais qui fait perdre trop de batterie, trop vite (par exemple, dans le cas des applications qui s'exécutent en parallèle sur le même écran) est mauvais pour la réputation du système, mais c'est quand même abuser. Alors que lorsque c'est Samsung qui l'a fait malgré les menaces de Google, ben comme ils ont les reins solides, ils peuvent se permettre.

Sauf erreur de ma part je ne connais aucune autre société, à part Microsoft, qui se sert de brevets logiciels bidons pour rançonner des sociétés utilisant des produits open source comme Linux et Android. Mais si tu as des exemples, je suis intéressé.

Je n'arrive pas à retrouver son post de blog, mais Bill Joy (fondateur de Sun Microsystems) a parlé de sa guerre de brevets avec Bill Gates (MS) à propos de StarOffice, mais aussi Steve Jobs à propos de CDE. En substance, chacun est venu le voir et le menacer de poursuites, et à chaque fois il a répondu qu'eux-mêmes utilisaient des technos dont Sun possédait les brevets. Donc tu as au moins Microsoft (œuf corse) mais aussi Apple.

Et en pratique, IBM aussi — contrairement à ce que beaucoup de (grosses) boites US aimeraient faire croire, une fois qu'elles sont un chouïa fossilisées et ont plus de mal à grossir/grandir/innover, elles ne se gênent pas pour utiliser leurs brevets pour intimider les plus petits.

En même temps, xbill, c'est toujours un jeu rigolo. :-)

Plein de sites ont fermés les commentaires de leurs blogs, et ouvert un board sur reddit par exemple.

D'autres proposent de passer par un système de chat alternatif qui force les gens à s'identifier avec une « vraie » identité : si tu veux commenter, il faut démontrer que tu es une vraie personne, et pas un maychant anonyme.

Enfin si tu veux un exemple de site avec des trolls en permanence, je te proposer d'aller voir Wikipedia, qui a des robots qui détectent quand des modifications trop fréquentes ont lieu sur une page, etc. Et au final, ça a le même inconvénient que bannir des plages entières d'IP : il y aura des faux positifs, et il faudra ensuite traiter au cas par cas.

Dans ton exemple de coca vs. pepsi, on n'est plus dans un exemple de petite communauté du tout. Dans ce cas précis, PepsiCo aurait tout intérêt à démontrer que les IP appartiennent au groupe Coca-Cola, et de tout bannir sans exception (et tant pis pour les innocents). Bref, de faire de l'anti-pub à Coca (toute pub est bonne à prendre lorsque t'es un petit nouveau ou bien que tu joues sur le côté sulfureux de ton activité, mais si tu es Coca-Cola Company, ton image est d'être pote avec un ours polaire : si tu te fais prendre à spammer à mort ton concurrent, ton image va réellement en pâtir).

En règle générale, si tu peux démontrer que les IP qui tentent de te spammer proviennent d'un même « propriétaire », je suis quasi-certain que tu as des recours légaux.

Enfin il y a une différence profonde entre des spammeurs (qui « bénéficient » d'êtres dans des listes noires, etc., qu'il faut mettre à jour, certes, mais qui peuvent être censurés avec une relative fiabilité) et les trolls, qui sont de vrais humains, et pas juste des robots stupides (bientôt on aura des IA presque intelligentes et qui agiront pour les trolls, mais c'est pas encore pour tout de suite).

Bon en même temps, j'ai lu à peu près la moitié du truc, et clairement le monsieur qui a écrit ce… truc, emploie des mots sans réellement savoir de quoi il parle. Une fois arrivé à la comparaison avec « la banalité du mal », j'ai lâché l'affaire. Ce n'est pas tant le point Godwin implicite prématuré, que le fait que cette comparaison n'est pas pertinente, et invoquer Arendt ainsi est juste une façon d'essayer de se poser en victime (tout en ayant le pouvoir de poster ses opinions teintées de délire de persécution paranoïaque).

Pas laisser de trucs chelou pouvant être gobé par un utilisateur un peu bête (tout le monde n'a pas un esprit critique)

Si tu gères une communauté quelconque, tu dois établir des règles concernant les limites que tu laisses à la liberté de parole:

• Il y a les limites légales, celles qui engagent ta personne en tant qu'éditeur/hébergeur de contenu : en France, les commentaires ouvertement racistes, incitant à la haine, etc., sont passibles d'amendes ou pire.
• Il y a ce que toi tu considères comme pas acceptable : « ici on parle de Pokémon, pas de Digimon ! Si vous commencez à lancer des fils de discussion sur les Digimon, même pour dire pourquoi Pokémon est mieux, nous nous réservons le droit de vous bannir »
• Évidemment, si des abus sont commis pour contourner les règles, tu peux amender ces dernières pour t'adapter.

Donc concernant l'histoire de l'esprit critique, etc., au-delà des règles que tu as établies, vouloir censurer le contenu au nom de la bienséance, et, franchement, d'une certaine condescendance envers les visiteurs de ton site (car selon toi certains sont trop cons pour se faire leur propre opinion—pardon, sont "dénués d'esprit critique"), ça me semble contre-productif. Si tu as un fâcheux qui propage des idées qui ne te plaisent pas, en tant que modérateur/admin de ta communauté, tu peux bien entendu le bannir, mais s'il ne contrevient pas à tes règles de modération, tout ce que tu arriveras à faire c'est donner envie à tes utilisateurs d'aller voir ailleurs, puisque, visiblement, les règles sur ce qu'on peut poster changent régulièrement et sans avertissement.

Ben c'est « simple », tu fais comme certains font sur IRC : tu bannis des grosses plages d'adresses IP pendant que la guerre fait rage, tout en laissant un moyen de contacter les modérateurs/admin pour demander à faire une exception si tu as la malchance d'être un utilisateur légitime.

Si tu as des milliers de trolls sur le dos, de toute manière, et que ta communauté est de 20 personnes, tu seras potentiellement DOSé avant d'avoir à te poser la question. :-)

Si je ne me trompe pas (ça fait un bout de temps), arnaudus fait référence au théorème d'Arrow (et dans une moindre mesure, aux équilibres de Nash), qui, appliqué à l'économie, dit en gros qu'en cas de d'équilibre trouvé sur un marché totalement libre et non faussé, on peut bien entendu se retrouver avec tout un tas d'acteurs qui réussissent à gagner « un peu », mais on peut (et souvent on va) se retrouver avec un gros acteur (pour un marché donné) et plein de petits qui n'auront que des miettes (en bref : un monopole).

Je pense que tu sous-estimes fortement le sentiment d'infériorité qu'ont certaines personnes, renforcé par la façon dont la société fonctionne. D'un côté tu as un « spécialiste » des opérations bancaires, le gestionnaire de compte. De l'autre tu as un client qui aimerait obtenir un crédit, et n'est pas forcément des plus informé en ce qui concerne les produits et les offres en général. Ça fait que tu as quelqu'un qui doute, qui se sent sans doute déjà mal de demander un emprunt, mis face à face à quelqu'un qui sait, ou en tout cas donne l'illusion de savoir.

L'accumulation d'un savoir a un impact « exponentiel » : plus tu sais comment te renseigner sur un système, mieux tu sais te renseigner sur des systèmes. Plus tu comprends comment fonctionne un système, et plus vite tu comprends ses évolutions, même quand elles sont drastiques. C'est quand même 'achement plus simple de prendre des décisions à tête reposée lorsqu'on t'a formé à penser de façon critique. Lorsque j'étais ado et que je bossais dans un poste de magasinier l'été, en rentrant le soir, j'étais lessivé mentalement, bien plus que maintenant, alors que je bosse bien plus d'heures dans l'absolu. La différence c'est que je suis dans un domaine qui (1) est moins physique, (2) est moins répétitif, (3) me demande de garder un esprit critique en permanence, et (4) ne m'impose pas une hiérarchie à la con avec des règles abrutissantes, tordant ainsi mon esprit critique à accepter l'arbitraire.