Manuel Menal a écrit 516 commentaires

Non. Guillermito est chercheur en biologie moléculaire dans un laboratoire qui dépend du Massachussetts General Hospital, lui même rattaché à l'Unversité d'Harvard (USA). Rien à voir, même avec "un truc du genre", donc.

Ah mais H* (je vais pas non plus tout dévoiler ;-), c'est simplement parce que j'ai déjà développé le sujet dans un commentaire précédent sur DLFP. Si tu mets les commentaires sur cette question là précise, ça doit bien remplir tes critères :-)

Les Loadable Kernel Modules (LKM pour les intimes) ne changent fondamentalement rien à la nature de Linux, comme pBpG le faisait remarquer. Ce qui change, c'est la façon dont on constitue le noyau, en ayant une base et en rajoutant/enlevant à volonté ce que l'on souhaite dedans. Mais le résultat est exactement le même : un gros logiciel avec les privilèges maximaux sur le matériel (mode "noyau"), plein de fonctionnalités, sans séparation claire entre les parties, sans cloisonnement.

Les LKM ne sont rien de plus qu'une facilité de plus pour l'utilisateur. Qui plus est, comme tu y vas fort quand tu parles de noyau "minimaliste" : les parties essentielles du noyau (gestion de la mémoire, ordonnancement, VFS, fondement de la gestion des périphériques) se trouvent encore présentes. Il n'y a, grosso modo, que la partie "pilotes de périphériques" (qui est, contrairement à ce qu'on se représente souvent, une partie assez peu conséquente d'un noyau "classique") et les systèmes de fichiers qui soit "modularisée". Et les initiés se rendront compte que ce sont là deux des parties les plus simples à comprendre du noyau, de par leur modularité justement.

Mais ça ne change rien aux problèmes de fond : celui de la sécurité, celui des effets de bord, celui de la substituabilité des composants, celui, tout à fait lié, de la stabilité des interfaces (l'instabilité des interfaces est au contraire un dogme pour Linus, de la même façon que la non-séparation des parties répond à son dogme du "No design, code"), et j'en passe.

Pour en revenir à la question "Peut-on qualifier Linux de monolithique ?", il faut définir "noyau" au sens où on l'entend classiquement en développement d'OS. Il s'agit de l'ensemble du code qui tourne avec des privilèges particuliers sur le matériel. Il est assez difficile ensuite de définir micronoyau et noyau monolithique de façon "statique", à instant 't' : c'est le mouvement "vers le noyau" ou "vers l'espace utilisateur" qu'on considère souvent comme définissant s'il s'agit d'un noyau monolithique ou non. Dans Linux, tout (VM, ordonnancement, pilotes de périphérique, systèmes de fichiers, gestion des droits, ...) se trouve en "mode noyau". Et de plus en plus de choses se retrouvent dans le noyau, et très peu de choses sont bougées en user space. C'est définitivement un noyau monolithique. Quel que soit la façon dont on construit le monolythe. :-)

Je ne pense pas que ce soit la personnalité d'un Linus qui manque au Hurd. Et je ne pense pas que DLFP soit le meilleur endroit pour en discuter. Il est acquis que le Hurd a suscité moins d'engouement que Linux. Mais si on prend l'évolution du développement du Hurd, les choses sont loin d'être linéaires ou désespérées. Le développement du Hurd a commencé vers 1990 avec principalement Thomas Bushnell et Roland McGrath, tous les deux alors employés par la FSF. Il a suscité l'intérêt de développeurs peu nombreux, mais qui s'y sont investis à fond : Miles Bader (développeur Emacs & Glibc bien connu), Okuji Yoshinori (maintainer de Grub), Mark Kettenis, .... Mais l'équipe n'a pas su intégrer de nouveaux éléments, et quand Thomas et Roland ont quitté la FSF aux alentours de 94/95. Aussi, le développement a été presque entièrement stoppé entre cette date et l'arrivée de Marcus Brinkmann vers 98/99. Mais comme quoi les choses ne sont pas inéluctables, d'un développeur vraiment actif on est repassés à 2 (Neal H. Walfield), puis les anciens développeurs sont revenus un peu sur la scène, et maintenant on a un noyau de développeurs d'environ 5 à 10 personnes actives. Ce point historique montre bien, je pense, qu'un projet, ça se redynamise en assez peu de temps. Et l'arrivée du port sur L4 a permis, comme je le disais, d'amener encore d'autres gens, tous d'autant plus motivés. Il faut que le Hurd s'affranchisse des clichés, s'affranchisse des réticences liées à la FSF, et c'est en avançant de façon résolue et indéniable qu'il peut faire cela.

Quant au "switch", je pense au contraire qu'il pourrait se faire extrêmement rapidement, une fois le Hurd arrivé à maturité. Tout dépend bien sûr de quelles entreprises ou de quels particuliers on parle. Pour les particuliers, l'arrivée à GNU/Linux et aux logiciels libres se fait quasi-systématiquement par un tiers, qui fait la première installation, la première initiation. C'est cette frange de "prosélytes" qui répand GNU/Linux. C'est à celle-là que tiendra l'implantation de GNU/Hurd chez les particuliers. Et ils ne rencontreront probablement aucune opposition, parce que GNU/Hurd fournit une interface de compatibilité POSIX totale, et que le changement sera (ou plutôt, pourra être) totalement transparent. Le grand pas a été fait avec GNU/Linux. GNU/Hurd pourrait très bien profiter de ça. Dans le milieu professionnel, il faut distinguer les petites unités indépendantes, les petits CRI, les PME/PMI/TPE, où la décision revient couramment à quelques personnes, ça se passera probablement pareil. Évidemment, il y a ensuite les réticences des grandes organisations. Mais il y en a toujours. Et je crois qu'on aura peu de mal à convaincre.

La force du Hurd, c'est de respecter à la lettre le GNU Manifesto : totalement compatible avec Unix (l'existant), mais repoussant les limites, permettant toujours plus, "à côté". Nul besoin de changer ses habitudes : vous le pouvez, et vous n'en tirerez que plus d'avantages. En attendant, même avec des logiciels purs POSIX et une utilisation purement Unixienne classique, GNU/Hurd s'efforcera d'être au moins aussi performant, stable et puissant que l'existant.

Je comprends ton argument. Effectivement, un des arguments principaux de l'intérêt du Hurd est ce qu'il permet aux utilisateurs non-privilégiés sur une machine. On retrouve là la préoccupation première du projet GNU (redonner la liberté à l'utilisateur). Cette préoccupation, au niveau technique, a probablement perdu de son sens dans les dix dernières années, avec le développement de l'informatique grand public. Je crois pourtant qu'elle est toujours d'actualité, et que par delà même cette préoccupation, le Hurd n'a jamais été autant d'actualité.

Le premier point sur lequel je voudrais insister est que c'est une vision extrêmement étriquée de l'informatique que de penser qu'aujourd'hui, chacun est son propre administrateur. Il reste beaucoup d'endroits où ce genre de solutions n'est pas souhaitable ou réalisable : dans les labos en général, où beaucoup d'utilisateurs ont besoin de ressources partagées (gros serveur de calcul, serveur d'applications), sans qu'il soit envisageable que le moindre thésard ait des droits privilégiés sur la machine. Réussir à lui donner suffisamment de droits pour qu'il puisse faire son travail de façon correcte sans pour autant lui donner de quoi compromettre la machine est un éternel travail d'équilibriste, et n'aboutit que très rarement à des solutions satisfaisantes. On remarque d'ailleurs que les solutions à base de sudo(8) (sur une seule commande, par groupe, ...) deviennent de plus en plus monnaie courante, et je pense que même si c'est bien pratique, tout le monde s'accordera à dire que c'est loin d'être satisfaisant. Le problème se pose encore plus dans le contexte éducatif, puisqu'on peut rarement considérer qu'on fait confiance aux étudiants (et on nous taperait sur les doigts encore plus si on le faisait que pour les thésards). Et ça n'est pas qu'une subsistance : avec le développement des connexions "haut débit", il est de plus en plus possible de donner accès à des ressources électroniques à distance, et l'arbitrage entre utilisabilité et sécurité devient plus important que jamais (si quelqu'un travaille en télétravail 3 jours par semaine, il faut que ce soit _très_ utilisable ; mais il faut en même temps faire _très_ attention point de vue sécurité).

Par ailleurs, je crois que toute l'innovation apportée pour permettre à des utilisateurs non privilégiés de faire toujours plus sans compromettre le système est encore très profitable même dans le cas de l'informatique personnelle. D'une part, si les utilisateurs peuvent faire plus c'est parce que de moins en moins de code nécessitent des privilèges noyau : d'autant moins de risque de faire planter totalement la machine, d'autant moins de risque de l'endommager, et d'autant moins de risque de permettre à un attaquant (et le problème des attaques à distance est plus que jamais le problème de l'informatique personnelle) de gagner des privilèges lui permettant des dégâts irréparables. D'autre part, ces possibilités résolvent bien des problèmes couramment rencontrés même sur des machines où le seul utilisateur est son administrateur. Je pense par exemple aux problèmes de droit que l'on rencontre quand on monte un FS : les droits qui se retrouvent à user:user et donc la moitié des choses qui marchent plus, les comportements tout bizarres pour les suid... Et je ne parle pas du fait qu'il faille rajouter une entrée dans le fstab à chaque fois qu'on veut pouvoir monter un truc en utilisateur normal (et l'utilisateur normal a plus envie de double-cliquer pour monter que faire un "sudo mount", si, si). Sous GNU/Hurd, absolument aucun problème : vous montez vos propres FS sans vous soucier du problème de droit et des problèmes de sécurité (tout utilisateur ayant des notions d'Unix verra sa barbe se hérisser en laissant un utilisateur monter un FS quelconque sans avoir pourtant de droits privilégiés, quand bien même ça ne serait que lui ;-). Tu apprécieras aussi choisir le comportement en cas de crash par utilisateur, grâce à la flexibilité des translators, et pas se retrouver que le ~ de ta petite soeur se retrouve faire 80G du fait des .core du dernier jeu que tu lui as installé qui plantait de partout. (OK, ulimit -c ça existe, mais la soeur risque d'être surprise si tu as eu l'idée de mettre un "suspend" par défaut en cas de crash, croyez moi ;-)

Et puis, c'est être extrêmement simpliste que de limiter les avantages du Hurd à ça. Les avantages du Hurd se posent par exemple en terme de flexibilité : amusez vous à faire un système de fichiers "virtuel" un peu original, comme un FS modélisant un annuaire LDAP (un ldapfs, quoi). Le peu de flexibilité qu'offre le VFS centralisé d'un Unix, la complexité du développement de telles choses en mode noyau vous apparaîtra évidente. Et pourtant, de plus en plus on essaye d'intégrer ce genre de webservices à l'OS. Par exemple, iDisk pour MacOS X ou les WebFolders pour Windows, qui utilisent tous deux WebDAV, permettent de fournir assez facilement à des utilisateurs leurs ~ à distance, sans les problèmes de FTP (passif/actif, galères de firewall, FTPS impossible si firewalls stateful, ...) et les galères de NFS/etc. Ceci n'existe pas sous GNU/Linux, où il faut se contenter de passer par Gnome-VFS ou KIO (ou par un module totalement instable et qui fait peur à voir). Ces besoins se font sentir dans le milieu professionnel depuis déjà plusieurs années, et pourtant toujours pas de solutions pour ce genre de services, ou alors complètement insatisfaisantes (aucune sécurité, aucune stabilité). Je crois qu'on touche là aux limites de la flexibilité d'Unix.
Le Hurd, c'est aussi un système de gestion des droits totalement différent. À l'heure de Kerberos et des ST un peu partout, il est hallucinant qu'un système comme GNU/Linux soit aussi limité en terme de gestion des droits. Tous les jours, dans mes développements internes, je vois de plus en plus le besoin d'un système où je pourrais, sur mon système, fournir un certificat, un couple (login, pass), ou un quelconque autre moyen d'authentification et obtenir un jeton me donnant des droits bien particuliers. Et cela au coeur du système, pas que pour les WebServices, pas en surcouche. Ma remarque sur le développement d'utilisation de sudo(8) de plus en plus massive est un signe de la nécessité d'une gestion des droits plus fine, je pense.
Le Hurd, c'est aussi la possibilité d'avoir des personnalités multiples. Il est tout à fait envisageable, dès maintenant, de programmer des serveurs "alternatifs" remplaçant des gros bouts du GNU/Hurd tel qu'on le connaît. Tant que ces serveurs respectent les interfaces clairement définies, chaque utilisateur pourra alors facilement lancer son propre "sous-système" avec les serveurs qui lui plaisent. Et ça ne sert pas que sur des grosses stations multi-utilisateur : il est tout à fait possible que je souhaite lancer un environnement particulier que pour une seule application, et pour tout le reste je veuille rester dans l'environnement POSIX standard.
Tu parlais de UML ou de Xen. Tout d'abord laisse moi te dire ma perplexité face à ce conseil. Il est -inimaginable- d'utiliser une telle solution en production. UML peut tout au mieux servir à réaliser des tests préliminaires dans un environnement non critique. 'préliminaires', parce qu'un environnement UML a de moins en moins à voir avec un environnement 'réel' à base de Linux : Linux n'est pas fait pour tourner en mode utilisateur, et de ce fait les modifications nécessaires sont énormes, et changent considérablement le comportement de l'application. Et 'non critique', parce que du fait de la complexité d'un tel travail, UML est extrêmement peu stable, et fait même très souvent planter le noyau principal lui-même (un comble !). Si pratique que cette bidouille puisse être, elle reste une bidouille et ne devrait pas avoir d'autre ambition que d'être réservée au développement Linux comme elle l'était à l'origine. Pour le Hurd, en revanche, c'est bien différent : tous les serveurs tournant en user space, faire tourner un deuxième "co-Hurd" ou "sous-Hurd" (les deux sont possibles, selon que l'un agit comme "proxy" de l'autre pour les ressources partagées ou qu'ils agissent en parallèle, avec des bouts communs) est quelque chose de naturel, et ça ne nécessite pas une version modifiée ou quoi que ce soit.

Je concluerai enfin sur ce qui est généralement ma première remarque quand on me demande les avantages du Hurd. Le Hurd est le coeur d'un système d'exploitation. Il ne fournit directement qu'extrêmement peu aux utilisateurs. Ce qu'il fournit, c'est des -possibilités- que les développeurs d'application utilisent ou non. GaGadget parlait de la possibilité d'avoir plusieurs VM, plusieurs schedulers en parallèle. Utilisé à bon escient, c'est là une possibilité d'optimisation fabuleuse : on sait pertinemment que tel comportement de VM est bien plus adapté à tel environnement que tel autre, et d'ailleurs tout le travail d'un développeur de VM sur des systèmes centralisés consiste à déterminer ce qu'on considère comme le "cas moyen", et ce qui est moins pire dans ce cas là. Sur un système décentralisé comme le Hurd sur L4, il est tout à fait possible d'avoir plusieurs VM en parallèle qui régissent différemment la mémoire qui leur est allouée. Et je ne parle pas des négociations de QoS que permettent une conception décentralisée, et fondée sur la communication entre processus, qui représentent des possibilités de 20 à 50% d'amélioration des performances sur des applications spécifiques, comme les serveurs de base de donneés, et encore plus sur le cas du multimedia. Si les développeurs utilisent ces possibilités (que ce soit la possibilité de remplacer des serveurs, la flexibilité du système d'authentification, les notifications, ou la négociation de QoS), alors toi, utilisateur, oui, tu verras les amélirations, et pas qu'un peu.

Constraint bordel, pas Contraint ! Puisqu'on me demande à ma gauche des URLs pour approfondir/comprendre mieux, en voici :

http://www710.univ-lyon1.fr/~csolnon/Site-PPC/e-miage-ppc-som.htm a l'air très, très bien fait.
http://www-cdr.stanford.edu/NextLink/ConstraintManager/constraint-satisfaction-problem.html pour un petit exemple de DDB.
http://www2.parc.com/spl/members/dekleer/Publications/Dependency%20directed%20backtracking.pdf a une explication un peu plus poussée du DDB et des limites du backtracking chronologique.

Je crois pas que ce soit terriblement fondamental, mais bon, une petite explication rapide, pas forcément claire, est de rigueur. Il s'agit de programmation par contrainte (PPC en français, on trouve plus couramment CSP, Contraint Satisfaction Problem).

Il s'agit grosso modo de modéliser un problème par un jeu de variables, pouvant prendre leurs valeurs dans un domaine, et un jeu de contraintes. Résoudre le problème revient alors à trouver des valeurs pour les variables de telle sorte que toutes les contraintes soient satisfaites. Le grand classique des CSP est le problème des reines, où il s'agit de placer 8 reines sur un échiquier de façon à ce qu'aucune ne risque de se faire prendre au coup suivant. On peut facilement identifier les X variables (8 couples, les coordonnées), les contraintes (lignes différentes, diagonales différentes, etc.). On peut alors disposer de tout l'armada algorithmique développé pour les CSP pour résoudre le problème des 8 reines.

La méthode naïve est la méthode de recherche par arbre, où on explore toutes les possiblités. C'est codé en trois minutes, mais vous vous rendrez vite compte que vos enfants, petits-enfants et l'Humanité sera probablement décédée quand vous aurez toutes vos solutions. Pour résoudre ça, on fait appel au "backtracking", c'est à dire qu'au lieu de générer et tester naïvement toutes les possibilités on va vérifier à chaque fois que l'instanciation partielle (par exemple, 4 reines sur 8 seulement) est bien consistante (elle ne viole aucune contrainte). Quand une instanciation partielle devient inconsistante, on backtracke, et on essaye l'autre combinaison. On a donc coupé une bonne partie de notre arbre, et les choses vont beaucoup mieux.

L'idée derrière le DDB (Dependency-Directed Backtracking, ce dont Stallman parlait) est que le backtracking "simple" (backtracking chronologique) explore une grande partie de l'espace de recherche du CSP en redécouvrant à chaque fois les mêmes contradictions. Il suffit pour éviter ça de garder en mémoire une trace des inférences que l'exploration a réussi à mettre en évidence (les dépendances, donc) et les contradictions rencontrées (les "nogoods" dans le papier en question). De là, on peut s'éviter beaucoup de tests inutiles, et plus facilement inférer une solution partiellement consistante lorsqu'on se retrouve bloqué dans un cas d'inconsistance.

Le DDB est une technique très utilisée en programmation par contraintes, et en particulier dans toute la branche de la démonstration automatique, et de l'analyse de preuves.

(Disclaimer: je n'assure pas la clareté ou le sens de mes propos à 2am. Désolé ;-)

J'ai déjà répondu sur IRC, alors je synthétise pour tout le monde.

Il n'y a pas de plan immédiat pour avoir un GNU L4, pour la simple et bonne raison que L4Ka::Pistachio nous convient parfaitement dans l'état. L'équipe de développement est très sympa, très ouverte. La licence est libre, compatible avec la GPL. Le développement est actif, L4Ka::Pistachio est utilisé, a réussi à fédérer des utilisateurs.

Si un jour les développeurs du Hurd souhaitent faire des choix concernant le développement de L4 que L4Ka ne souhaite pas faire, ou que chaque équipe décide que ça a sa place plutôt dans un GNU L4 que dans l'implémentation L4Ka::Pistachio, alors peut-être y aura t'il un "fork", et comme Guillaume le faisait remarquer, ça ne pose aucun problème que le projet soit alors sous GPL.

Je rajoute que c'est un peu ce qui s'est passé avec Mach. CMU Mach n'étant plus développé, GNU Mach a été créé. La plupart des sources sont encore sous une licence de type BSD, le projet GNU Mach étant lui-même sous GPL.

Et je rajoute enfin que pas mal de projets GNU ont du code sous BSD, voire sont entièrement sous licences BSD. Ca n'est pas une licence que le projet GNU encourage dans le cas général, mais il l'accepte tout à fait, voire l'encourage dans des cas bien particuliers (comme le code dans le domaine public, d'ailleurs).

Brièvement, parce que je pense pas que parler du point de vue de Richard Stallman tel que je le connais soit absolument passionnant. Je pense que dans ces phrases, RMS fixe l'ordre de priorité qui caractérise la position de la FSF : la liberté avant tout, avant l'efficacité, par opposition au mouvement Open Source qui se soucie de créer une méthode de développement efficace fondée sur les principes énoncés dans l'Open Source Definition.

Mais RMS insiste bien sur l'apport complémentaire, comme le montre bien la dernière phrase que tu cites. Il dit donc, en résumé, qu'il faut valoriser le côté liberté plus que le côté "efficacité", sans pour autant nier que le deuxième sert le premier, ou affirmer que l'un peut s'affirmer sans l'autre. Voilà, c'est un peu plus long que ce que j'aurais souhaité. :)

Je me demande ce que veut dire "retarde le projet", et qui peut en juger. À titre personnel, je ne crois pas que le port sur L4 "retard" le projet Hurd, au contraire. La réalisation concrète du Hurd a commencé vers 1990/1991, comme Linux. Force est de constater qu'il n'a pas su susciter le dynamisme autour de beaucoup de projets Libres. Je n'irai pas me lancer dans une explication de ce phénomène (méthode de développement ? personnalités ? nature du projet ?).

En tous cas, il est clair que le port sur un micro-noyau d'une nouvelle génération, un micro-noyau moderne, sur lequel beaucoup de gens bossent (dans le milieu professionnel et dans le milieu recherche) est capable d'apporter un certain dynamisme au projet. On voit d'ores et déjà beaucoup de gens intéressés spécifiquement par L4/Hurd et s'y consacrer alors qu'ils n'avaient jamais pris le temps de s'investir dans le projet avant. On voit aussi les développeurs gravitant autour de L4 (qui sont nombreux, croyez moi) s'intéresser vivement à ce projet grand public, multi-usages (pas qu'embarqué ou que hard RT, ...) utilisant leur petit bébé. Et puis, porter le Hurd sur L4, ça veut dire re-concevoir toute une partie du Hurd, des parties fondamentales (comme la VM, le scheduler, ...), ce qui ne manque pas d'intéresser beaucoup de monde. Alors certes, le port sur L4 rajoute beaucoup à la liste des tâches à effectuer. C'est beaucoup de travail en plus. Mais c'est aussi beaucoup de gens en plus pour le faire. Je crois personnellement que la dynamique d'un projet est beaucoup plus importante que la simple TODO list.

Ensuite, opposer liberté et confort d'utilisation, c'est déjà l'expression de toute une stratégie. Ça n'est certainement pas la mienne. Et en fait, je ne pense pas que ce soit celle de Richard Stallman.

Je crois que sa vision du port de L4 est beaucoup plus liée à des questions de contrôle (à des questions politiques, oui, mais au sens le plus bas du mot). RMS suit de façon peu attentive le Hurd : il attend des développeurs qu'on lui donne des choses à mettre en avant de temps en temps, pour faire de la promotion « grand public » (grossière, quoi ;-) : ses exemples sur les FS le montrent bien. Le projet de port sur L4 est bien plus difficile à mettre en avant. De même, les développeurs GNU/Hurd échappent beaucoup au « contrôle » que RMS souhaite garder sur les projets GNU centraux, comme le Hurd. Le projet sur L4 s'est fait beaucoup sans son avis et son aval. RMS ne l'a pas forcément digéré.

My 2¢.

Comme l'auteur l'indique assez clairement, Sendmail X est une réécriture complète de Sendmail, ce que n'était pas Sendmail 8 par rapport à Sendmail 7. Ca n'est pas encore une nouvelle version de Sendmail, d'ailleurs on pourrait se demander s'il ne serait pas pertinent de changer complètement de nom (mais ça ne le serait pas pour Sendmail Inc ;-). Le passage à X marque un changement dans la numérotation, pour bien marquer cette différence. Le projet s'appelait d'ailleurs Sendmail 9 auparavant, mais il a été renommé pour ces raisons, principalement.

C'est un renommage tout à fait légitime, de la même façon que MacOS est passé de la version 9 à la version X 10.0, avec un X qui correspond que moyennement à 10, puisque sur les boîtes Panther par exemple, y a marqué Mac OS X 10.3 ;-) C'est plus un X symbolique, d'autant plus que c'est le X de Unix dans le cas de MacOS X.

Ca n'est pas exactement vrai, si on prend réellement la définition du Logiciel Libre telle que donnée par la FSF, et l'OSD fournie par l'OSI.

Chacun sait que la différence fondamentale entre Open Source et Free Software n'est pas légale, n'est pas formelle, mais que c'est une divergence de vision. Ce sont deux mouvements avec des moyens communs, des buts intermédiaires communs, mais des visions et des objectifs finaux différents. Les partisans de l'Open Source considèrent l'accès au code source et toutes les conditions posées par l'OSD comme une "méthode de développement". C'est une vision pragmatique, de gens qui pensent que le développement collaboratif à l'Open Source permet de développer des logiciels plus performants, plus sûrs, plus innovants, tout ça. La vision du Logiciel Libre, chacun la connaît, c'est celle qui met en avant le principe de liberté, celle qui met en avant les valeurs de partage, d'enrichissement, de libre accès à la connaissance, et qui pense que les logiciels libres contribuent, à leur niveau, à servir ces valeurs.

Ca n'est certainement pas une question d'habillage. Les objectifs, la vision, ça n'est pas juste du blabla pour aller agrémenter une définition "formelle". C'est au contraire ce qui donne son sens à la définition, sans ça elle n'est rien.
D'autant plus qu'en découlent des différences dans les définitions, légères, mais notables. Par exemple, le fameux "privacy right" qui spécifie qu'une licence ne peut obliger l'utilisateur à rendre publique ses modifications. Celà découle du fait que le logiciel libre est fait pour protéger les droits des utilisateurs, tandis que beaucoup de licences purement Open Source vont au contraire l'obliger pour contribuer à un développement plus dans "l'esprit Open Source". C'est en particulier le cas de l'APSL version 1, la licence de Darwin jusqu'il y a peu.

Et je ne pense pas que Richard Stallman ait dit que l'OpenSource c'était "pas bien". Richard Stallman souhaite que les gens migrent vers des solutions libres ou Open Source pour des raisons idéologiques, parce que c'est Libre. Du coup, il préfère effectivement qu'on utilise le terme logiciel libre à Open Source, pour ça. Il y a un autre aspect, c'est la réutilisation à tout va du terme OpenSource qui a conduit quelqu'un comme Bruce Perens à déclarer qu'il préfèrait Free Software à Open Source.

Ca n'est pas blanc bonnet et bonnet blanc, ce sont deux approches complémentaires, mais bien radicalement différentes. Je pense que la précision méritait d'être faite.

Euh, ça n'a rien de paradoxal. À partir du moment où ton but est la stabilité des interfaces, tu peux pas déclarer "Zope3 est sorti, les interfaces sont stables". Il te faut l'expérience derrière. Alors, tu as plusieurs choix. Soit tu considères que l'expérience a été suffisamment accumulée par les autres projets (encore faut-il qu'il existe depuis longtemps des alternatives rigoureusement équivalentes en terme fonctionnel), soit tu es bien obligé de développer toi-même ta propre expérience. Dans la deuxième configuration, il est on ne peut plus logique de déclarer une version "stable", une version donc "finale" d'une plateforme expérimentale. Les développements et utilisations de cette plateforme expérimentale sert à accumuler l'expérience nécessaire à la définition de ces interfaces, et une fois qu'elles sont stabilisées et qu'on sait suffisamment ce que ça donne, on les intègre à ce qui deviendra Zope3.

C'est en tous cas la façon dont je le vois, et c'est une procédure de développement que j'ai souvent vu mise en oeuvre et mis en oeuvre moi-même dans des projets orientés composants.

En fait, je pense que ce serait utopiste de penser qu'elles migreraient toutes seules après avoir utilisé activement les logiciels contenus dans WinLibre. Je constate de plus en plus que les utilisateurs Windows entre eux se recommandent des logiciels libres, du style Firefox. Il n'est donc pas rare de se trouver avec un portable d'un non-informaticien non-passionné non-riendutout avec Firefox. Mais passer à une distribution GNU/Linux reste un pas trop important pour qu'il soit fait tout seul.

Ca n'enlève rien à l'utilité de WinLibre. Il ne faut juste pas compter sur la logique de l'engrenage qu'engendrerait une installation de tels logiciels. En revanche, il est clair que les principales réticences des utilisateurs de base se trouveront levées, et l'accord de la personne pour qu'un tiers effectue la migration sera bieeeen plus facile.

Une plateforme expérimentale, une version finale. Tu peux très bien avoir un logiciel très stable, mais qui implémente un système qui lui, se veut amener à évoluer, au fur et à mesure justement qu'on développe et utilise la version stable. C'est une procédure en particulier très courante dans le développement des systèmes d'exploitation modernes, où les interfaces jouent un rôle fondamental (contrairement à Linux où Linus change les interfaces plus que régulièrement, par principe plus encore que par nécessité). La définition des interfaces (API et ABI) peut être amenée à évoluer dans un premier temps, ce qui fait de la plateforme une plateforme expérimentale, tandis que le noyau, lui, est tout à fait stable, robuste, utilisable.

Tout est principalement sur http://www.novell.com/collateral/4621400/4621400.html(...) ; Concernant Netware, ils continuent à le maintenir en parallèle avec leurs activités GNU/Linux mais dans les interviews ça et là, ils privilégient largement l'intégration et le port de leurs solutions sous GNU/Linux plutot que le développement Netware.

Concernant Zenworks, on peut notamment lire :

# Integrating ZENworks® Linux Management (formerly Red Carpet Enterprise) within Novell ZENworks 6.5, giving IT administrators a single management tool for all their NetWare, Windows* and Linux management

Il semble évident que l'intégration de toutes ces solutions, dont ZENWorks, dans leur "pole Linux" (avec Ximian et SUSE) marque une fin progressive pour Netware. C'est en tous cas comme ça que je le vois.

Le problème est effectivement totalement inversable : si l'ordre des boutons était le même que celui de KDE/Windows, les gens qui passent constamment d'un environnement MacOS à un environnement GNU/Linux serait bien désavantagé de voir Firefox utiliser l'autre ordre de boutons, l'ordre obscur ;-)

Dans tous les cas, c'est configurable, et c'est tant mieux. J'apprécierais que ce genre de choses se retrouver dans une configuration de Firefox utilisant GConf ou une version standardisée Freedesktop de la chose, ce qui éviterait de passer X temps à trouver le bon .css à éditer, les deux variables assez obscures malgré tout, sans compter qu'on a de la chance si ça se trouve pas à deux endroits différents ! :-) Je conçois cependant que GConf soit trop lié à Gnome pour être utilisable par Firefox, mais ça me semble être un bon objectif à terme.

Ah, j'oubliais. Je poste ce commentaire depuis Safari. Un navigateur pas libre. Tu pourras vérifier en regardant la tribune, Mozilla/5.0 (Macintosh; U; PPC Mac OS X; fr-fr) AppleWebKit/, oui, c'est un OS pas libre. Jr a un Powerbook, sur lequel il fait tourner MacOS X. Je maintiens ausi un parc composé de Debian, *BSD, et de ... Solaris. Oh mon Dieu, ça n'est pas libre. Donc, franchement, les petits boutonneux enfermés dans leur bulle idéaliste, tu les inventes. Arrête de vivre dans tes fantasmes paranoïaques et reviens un peu à la réalité. Tu en deviens inquiétant, à la longue.

Tu dis décidément n'importe quoi. La dépêche Novell a été proposé par un commercial de chez Novell, travaillant dans l'équipe avant-vente. Ca a exactement le contenu d'une press release. À base de Novell Linux Desktop rend Linux immédiatement utilisable sur les postes de travail, ce qui ne représente certainement pas un jugement objectif, et qui n'a pas sa place dans une dépêche sur DLFP. Nous ne transmettons pas les press release, c'est un choix clairement indiqué, noir sur blanc, et ça sera le cas ici encore.

Nous ne cherchons pas un prétexte pour la supprimer. En fait, si ça avait été le cas, on aurait pas demandé à l'auteur de rerédiger, mais on lui aurait refusé sur un autre prétexte. C'est plutôt marrant que tu dises ça, parce que je postais justement y a quelques heures un message disant, texto, Il FAUT avoir une news Novell Linux Desktop je pense., sur l'interface de modération de la dépêche. Voilà qui montre probablement à quel point je veux chercher des excuses pour ne pas passer de dépêches Novell.

Quant aux modérateurs enfermés dans leur bulle, c'est si ridicule que je ne prends même pas la peine de répondre. J'ai, de toutes façons, déjà répondu à ça. Les modérateurs et relecteurs sont d'horizons diverses. D'opinions diverses. N'ont pas d'appartenance partisane commune, d'un point de vue politique, et encore moins point de vue distribution. Jr n'a pas franchement un avis tranché en faveur du logiciel libre, a développé lui-même dans son boulot du logiciel propriétaire. Et rien dans nos propos ne te permet de dire ça. Tu cherchais juste un moyen de le dire, en partant dès le début dans ta paranoïa, en t'y enfonçant un peu plus à chaque post.

Je pense que plus personne n'est dupe. Je sais pas si c'est un petit jeu ou si tu en es vraiment convaincu, et ça m'est assez égal. À toi de régler tes problèmes.

Le rôle des relecteurs et modérateurs n'est pas de réécrire chaque nouvelle qui passe entièrement. Il est de les corriger, de les améliorer, de rerédiger des parties maladroites. Demander de réécrire les nouvelles qui passent, si on pense qu'elles doivent faire l'objet d'une nouvelle, c'est comme demander aux modérateurs de passer des nouvelles sur tous les sujets : ça n'est pas leur boulot, et ils n'ont pas le temps de le faire.

Les dépêches de Sam sont en général au format "press release", discours parfaitement marketeux. Ca n'est pas éditer qu'il faut. C'est réécrire tout, sur un ton objectif, et donc virer de grandes parties. Comme de plus le discours marketing se focalise rarement sur les nouveautés objectives, il faut faire un tri drastique, et ses propres recherches pour voir ce qui est vrai, ce qui est une exagération. Et rajouter ce qui manque. Bref, réécrire une nouvelle. Je n'ai pas le temps de le faire en général. JR pas plus. Pascal pas plus. Yusei pas plus. Si exceptionnellement ça arrive, on le fait. Mais comme contributeur, pas comme modérateur/relecteur.

Vois la différence entre une attitude constructive et une simplement de casse-pieds insultant, qui est la tienne (pédant, c'est pas une insulte ? Soyons sérieux). Par exemple, tu aurais pu essayer de comprendre ce qu'exposait Jr. Réfléchir, et te faire toi-même la remarque que je fais là, puisqu'on la répète sans cesse, depuis des années. Et, matiasf, tu es là depuis assez longtemps pour le savoir. *sigh* Et de là, tu en aurais tiré un problème : les modérateurs savent qu'il faut passer une news sur tel ou tel sujet mais n'ont pas de propositions décentes de dépêches. Il pourrait alors être intéressant d'avoir un espèce de système de proposition de rédaction de dépêches. Une boîte où les modéro/relecteurs mettraient juste des sujets du style "FC3", etc. Je sais pas si c'est une bonne idée, mais ça pourrait être une proposition discutable.

Ton avalanche d'agressivité malsaine, elle, ne l'est pas, constructive.

Ah, voilà d'où vient ta rancoeur, ta dernière news refusée. Il y a eu discussion autour de cette news, et on a considéré qu'on ne pouvait plus faire une dépêche à chaque brevet logiciel débile. Que ce soit marrant ou non, on commençait à en sortir vraiment trop souvent, et ça devenait (1) lassant (2) sans intérêt.
Cette nouvelle devrait être intégrée à une autre, plus consistante, sur les brevets logiciels, de la même façon que l'on refuse les dépêches particulières concernant la presse informatique, pour les agrégrer dans la "revue de presse". Il me semble pas non plus que la "nouvelle" en l'occurrence soit urgente, elle sert plus d'exemple à ressortir pour faire rire ou montrer l'absurdité des brevets logiciels, auquel cas il me semble qu'elle peut bien attendre une nouvelle plus détaillée (et y en a une en stock).

Tu mêlanges tout, tu agrémentes le tout d'insultes, et tu t'attends, évidemment, à ce qu'on fasse tout pour te servir. C'est vrai, j'oubliais, on est là pour ça, d'ailleurs on est payés pour ça, pas toi Yusei ?

Tu préfères le modèle LWN qui préfère passer des nouvelles de quelques lignes donnant juste l'information principale sans explications, sans détails, sans rédaction particulière, libre à toi. Rien ne t'oblige à lire DLFP. Rien ne t'oblige à adopter ce modèle. Il existe d'autres sites de nouvelles francophones, et si aucun ne te convient, crée le tiens. Je préfère, et je pense que c'est le cas d'un grand nombre de lecteurs de DLFP, avoir un site de news où j'apprends des choses, où je trouve du _contenu_ plutôt que de l'information pure, plutôt que des lignes me disant "FC3 est sortie" "Firefox 1.0 est sorti" "Nouveau logiciel : Wired". DLFP me convient pour ça, et je continuerai à le lire pour ça. C'est une question de choix de ligne éditoriale, et je ne pense pas que ce soit répréhensible, si c'est pas ce que tu attends c'est que DLFP ne répond pas à tes besoins, Point Barre.

En revanche, je ne peux pas tolérer que tu insultes ouvertement, cette fois ci, les modérateurs et relecteurs du site. Qui sont des bénévoles, rappelons le, qui ne tirent aucun bénéfice, seulement (1) la satisfaction d'avoir fait quelque chose qui leur plaît ou qu'ils pensent utile (2) le remerciement de quelques très rares (3) les insultes régulières des autres. C'était le cas à l'époque dont RedFox parlait, c'est le cas maintenant, de toutes façons rien ne va jamais, et il faudrait que le site soit tout et son contraire à la fois si on voulait pas d'insultes.
Je trouve absolument inqualifiable d'insinuer qu'il y aurait des complots pour ne pas passer des news SuSE ou Novell. C'est du n'importe quoi. Nous avons des contributeurs plus réguliers sur des sujets comme Mandrake, Mozilla, Debian, qui ont l'habitude de faire des nouvelles répondant assez bien aux exigeances de DLFP. Ca n'est pas le cas sur tous les sujets. Si certains ont été dégoûtés d'envoyer des news - des noms ? des cas précis ? des raisons objectives de l'être ? tu n'en a données aucune. -, qu'ils essayent à nouveau, et s'ils ne comprennent pas ou trouvent injuste la décision des modérateurs/relecteurs, qu'ils s'expriment, qu'ils envoient un mail, ça n'est pourtant pas compliqué. Les lobby ne peuvent que très difficilement s'exprimer dans un système de modération à plusieurs comme celui de DLFP. Ainsi, il serait ridicule de penser qu'il y aurait un lobby pro-Mandrake puisque même en comptant les utilisateurs de Mandrake parmi les modérateurs/relecteurs, on se rendrait compte qu'ils ne peuvent que très très difficilement réunir suffisamment de voix pour faire la différence (+5 !).

Si les lecteurs de LWN.net sont satisfaits de LWN.net, tant mieux pour eux. Moi, je ne lis plus LWN.net parce qu'il ne répond pas du tout à mes attentes. S'il répond aux tiennes, je t'encourage à y aller et à y contribuer. La ligne éditoriale de DLFP ne te convient pas, ça n'est pas en insultant les modérateurs et relecteurs que tu y changeras quoi que ce soit. Quant à ton journal, je n'ai aucune idée de ce dont tu parles, mais dans tous les cas les modérateurs/relecteurs ne suppriment les journaux que quand ils sortent du cadre de la légalité (et parfois ils les replacent dans les forums quand ils sont mal placés), donc c'est complètement hors de propos.

Impossible de répondre à ce post, ce qui montre très bien, je pense, l'invalidité de l'argumentation. Premièrement, quatre jours, ça n'est pas nécessairement trop. Si une nouvelle nous arrive dans un état non-acceptable (trop courte, trop pleine de fautes, ...), il peut se passer quatre jours, soit dans le temps de la navette -> rerédaction, -> reproposition, -> passage, soit le temps que quelqu'un ait le temps de réécrire la nouvelle. Si c'est une nouvelle particulièrement urgente - mettons, FC3, Firefox 1.0, où nous recevons immédiatement un grand nombre de dépêches - elles sont modérées en quelques heures tout au plus. Si c'est une nouvelle impéc' (OpenBGPd, celle-ci), même chose, quelques heures, le temps de réunir les voix nécessaires (éviter des grosses erreurs qui furent courantes).

Si tu penses qu'une nouvelle aurait dû passer et qu'elle a été refusée, tu peux en discuter sur moderateurs@, faire part de ton incompréhension. Je doute que tu te rendes comptes des différences qu'il y a entre les nouvelles telles qu'elles passent sur DLFP et telles qu'elles sont proposées. Du coup, tes jugements à la va vite sur le temps de modération sont simplement infondés, et sans intérêt. Et ton jugement global à l'emporte pièce sur DLFP, à jeter à la poubelle.

Les modérateurs, un club fermé, ça n'est pas vrai. Comme partout ailleurs, il faut évidemment un moyen de "sélection" pour ne pas avoir n'importe qui comme relecteur, et c'est difficile de trouver dans ce genre de cas des critères aisés. Alors effectivement, la cooptation joue. Sache aussi qu'à certains moments, il a été annoncé qu'on manquait de modérateurs/relecteurs et qu'on pouvait poser sa candidature. Ca n'est pas le cas actuellement pour autant que je sache, mais si ça le devient, et qu'il n'y a pas de candidat évidents - quelqu'un qui contribue régulièrement des nouvelles de qualité, comme Pierre Jarillon, a par exemple accepté de devenir relecteur, et c'est un grand apport - la procédure sera probablement relancée. Et on ne choisit pas des gens "dans la ligne éditoriale". Par exemple, il a été couramment reproché à DLFP de médiatiser beaucoup Mandrake et les modérateurs d'avoir une préférence pour eux. J'ai pu également émettre cette critique. Aujourd'hui, il est très clair que parmi l'équipe de modérateurs/relecteurs, il serait extrêmement difficile de réunir une majorité de "Mandrakeux" pour passer de façon autoritaire une dépêche sur Mandrake. En revanche, il se trouve que nous disposons d'un certain nombre de contributeurs réguliers qui sont des utilisateurs de Mandrake et qui proposent des dépêches tout à fait intéressantes à son sujet. Ca n'est pas parce qu'elles sont pro-Mandrake qu'elles passent : c'est parce qu'elles sont intéressantes. Une dépêche pro-Slack ou pro-Debian passerait de la même façon. Quand te mets-tu à l'écrire ?

Je n'ai jamais affirmé que "les modérateurs" étaient impartiaux et parfaits. J'ai en revanche affirmé que le système actuel, qui nécessite un certain consensus parmi les 25 modérateurs/relecteurs (avec des différentiels relativement élevés, compte tenu qu'il n'y a que très rarement 25 modérateurs/relecteurs actifs en même temps) limitait considérablement la possibilité de "putsch" plus ou moins autoritaire favorisant tel ou tel sujet, et bannissant tel ou tel autre. Et je pense d'ailleurs que les propos sur DLFP sont relativement équilibrés, dans les dépêches du moins.

Genre les news sur les drivers proprio NVidia, les news sur spike qui est totalement propriétaire avec des protocoles propriétaires, etc...

Quel rapport ? Je parlais des exigeances de rédaction, de contenu, avant tout. Le problème des drivers NVidia par exemple se pose à chaque fois, et le débat se tient à chaque fois. Et crois bien que la position par rapport aux logiciels propriétaires est un des principaux points de désaccord entre relecteurs/modérateurs, donc qu'on ne se prive pas de tenir ce débat. Il peut y avoir des erreurs, des news passées trop vite, mais généralement, celles-ci ne sont passées qu'en SP, et que quand elles apportent des modifications assez majeures (support Xorg, ...).

Et tu ne vois pas un problème là ? Moi je vois un gros problème.

En l'occurrence, ces dépêches ne m'ont, d'un point de vue personnel, pas manqué plus que ça. (ça n'a rien à voir avec une position de modérateur/relecteur, juste de lecteur). Mais tu ne peux pas rendre les modérateurs responsables du manque de proposition de dépêches. Ca n'est pas que nous soyons trop rigides sur la modération : il n'y a juste pas de dépêches, à la hauteur ou non. Même pas de base à retravailler. Notre boulot n'est pas de proposer des dépêches en masse, même si certains d'entre nous le font.

S'il y avait un modérateur un peu "pro-SuSE", une news serait passée. Pas une news spécifiquement sur SuSE/Dell mais sur SuSE 9. Certe la news aurait été profondément remaniée. Mais elle serait passée.

Encore aurait-il fallu que ce modérateur ait le temps de (1) voir la news (2) faire la réécriture. La news n'annonçait en rien la sortie de SuSE 9. Il n'y avait aucun lien qui en faisait état. Ca n'aurait pas été un remaniement, ç'aurait été proposer une nouvelle news. Les modérateurs n'ont RIEN à voir là-dedans. Pourquoi les lecteurs pro-SuSE de DLFP ne l'ont pas fait ? Pourquoi aurait-il fallu attendre qu'il y ait un modérateur ? Tu vois de la partialité là où ça n'est simplement qu'un boulot bien fait (une dépêche trop mineure pour avoir un intérêt rejetée).

Je n'ai pas vu de news Mandrake beta. Ou alors, il s'agissait d'une news avec valeur ajoutée quelconque, comme on en passe parfois : tests, interview, appel à la contribution sur des problèmes spécifiques, etc. Si une news sans ça a été passée, alors il faut le préciser dans la nouvelle, le discuter au cas par cas, râler en prenant une comparaison précise. Pas ressortir toute sa rancoeur dans des posts dégoulinant d'agressivité. Des erreurs de modération, il y en a. De là à crier au complot... Il serait plus constructif de discuter du cas sur la news ou sur moderateurs@.

Les règles sont précises et appliquables pour toutes les nouvelles. On ne passera pas une nouvelle annonçant simplement que X version Y va être mise à disposition du public dans Z jours. On ne passera pas une nouvelle annonçant simplement la sortie d'une beta. On ne passera pas une nouvelle annonçant une version mineure. SAUF si la nouvelle contient une valeur ajoutée, par exemple celles que j'ai citées. Je n'ai pas plus d'intérêt dans les news Mandrake que dans les news SuSE, utilisant moi-même Debian et exclusivement Debian depuis de bien nombreuses années. Je ne voterai pas pour une news Mandrake parce que c'est Mandrake ou une news SuSE parce que c'est SuSE.

Si quelqu'un proposait une nouvelle SuSE 9.2 annonçant sa disponibilité, assez objective, faisant plus de quelques lignes et annonçant les nouveautés majeures, alors elle serait sans aucun doute passée. Si vous n'êtes pas d'accord avec une décision de modération, vous pouvez contacter les modérateurs, bordel. Plutôt que de déverser une haine complètement infondée sans s'être jamais donné la peine de comprendre comment marche la modération, et pourquoi telle ou telle nouvelle ont été passées plus que d'autres. *Sigh*

Mais qu'est-ce que tu racontes ? Quel exemple de partialité as-tu ? D'abord, l'argument de l'abus de pouvoir me fait doucement rire. Un modérateur ne peut pas refuser une news sans obtenir un différentiel de 4 voix en faveur du contre. Pas plus qu'il ne peut la passer "autoritairement", puisqu'il faut, là, +5 voix. Cela signifie que administrateurs, modérateurs et relecteurs se seraient tous ligués pour qu'un sujet, une personne ou que sais-je encore ne soit jamais traîté dans LinuxFR ? Celà représente tout de même 25 personnes en tout et pour tout. Et loin de partager le même avis, sur les logiciels libres, les distributions, etc., etc. J'ai du mal à croire au complot organisé, et dans ce cas on me l'a bien caché.

Par ailleurs, DLFP est effectivement assez exigeante sur les news. Certains ont renoncé à leur statut de modérateur/relecteur à ce sujet, la discussion a eu lieu. Je pense qu'actuellement, la débit de nouvelles sur DLFP est tout à fait raisonnable, par rapport au nombre de dépêches proposées, que le temps de modération est un assez bon compromis entre le temps nécessaire pour faire en sorte que des grosses boulettes ne sont pas faites (combien de fois a t'on vu, avant ce système, une nouvelle passée à la hâte par un modérateur qui n'avait pas grande compétence dans le domaine, et qui s'est laissé prendre par l'aspect sérieux de la dépêche ?) et le temps limite pour passer une news. Sur le cas de cette dépêche, elle n'a encore une fois jamais été proposée, elle n'a pas non plus fait l'objet d'un journal, il n'y a donc pas de "faute" des modérateurs/relecteurs qui auraient omis une information majeure.

Quant aux sujets que tu cites, j'ai fait quelques recherches dans les archives de la ML moderateurs, alors répondons au cas par cas (en espérant que je n'ai pas loupé des mails) :
(1) (2) (3) Il semble qu'elles n'aient jamais été proposées.
(4) N'a été proposée qu'une nouvelle disant qu'elle serait proposée sur certains Dell, et rien sur sa sortie.
(5) La seule dépêche annonçait sa distribution publique pour mi-novembre, il a donc été décidé d'attendre cette date.
(6) Rien eu.
(7) En cours de modération, une nouvelle ayant été envoyée en rerédaction et nécessitant encore un peu de re-travail pour être objective.
(8) Rien non plus. On n'annonce en général pas les bêta, mais si une proposition avait insisté sur ce point, elle aurait été discutée sans aucun doute.
(9) Encore une fois, rien.

Qui, ici, ignore les acteurs du libre ? Je n'ai pas forcément le temps d'écumer les sites de nouvelles à la recherche de propositions à faire pour DLFP. D'ailleurs, ça n'est pas mon rôle de relecteur, et ça n'est pas le rôle des modérateurs. Il ne viendrait à l'idée de personne de critiquer les modérateurs de fcolm parce que vous trouvez qu'il ne contient pas assez de posts intéressants. Ici, c'est -pareil-. Si tu étais au courant de ces évènements, si tu pouvais les présenter de façon intéressante, alors nous étions tout à fait prêts à modérer tes dépêches. Or, si je ne m'abuse, ça n'a pas été le cas. Aucune raison d'adopter ce ton agressif, cette trame a la "on nous cache tout on nous dit rien" et ces insultes en filigrane.

Vu le ton de la plupart de tes autres commentaires, ça n'est pas tellement pour toi que je réponds, mais surtout pour les autres.