gasche a écrit 1151 commentaires

Je doute qu'une séparation en paragraphes soit nécessaire pour pouvoir éditer une dépêche à plusieurs. On pourrait par exemple garder le document en un seul morceau, mais avertir d'un conflit d'édition dans les (rares) cas où deux personnes modifient exactement le même endroit, et laisser les gens merger à la main. Je vois que vous avez une forme de "chat instantané" dans l'espace rédaction, il permet aussi de se coordonner sans avoir besoin de verrous logiciels.

Il y a de nombreux outils d'édition collaborative en ligne (Etherpad par exemple) et ils n'imposent pas de découpage en paragraphe.

PS: dans le même genre je me demande pourquoi vous forcez le hard-wrap des paragraphes markdown (le fait d'ajouter un <br/> à la fin de chaque ligne, comme dans le post ci-dessus). C'est contraire à la spécification, et je ne vois pas trop l'avantage puisque markdown permet déjà d'insérer des sauts de ligne en ajoutant deux espaces à la fin d'une ligne.

Ce serait bien si le hard-wrapping, au moins, était désactivable localement, quand on soumet du contenu qui a été formatté pour le parseur markdown standard.

De ce que je comprends du code, le coupable est le découpage en
paragraphes qui est fait après soumission du contenu en modération:
c'est découpé à la hache, on sépare le texte sur toutes les lignes
blanches, donc les lignes de lien sont perdues.

Il devrait être possible de repérer ces lignes et en faire des
paragraphes spéciaux, qui soient aggrégés aux paragraphes textuels
avant le rendu de chaque paragraphe individuel. Le problème c'est que
c'est une rustine qui marche une fois, pour les liens, mais il
y a peut-être d'autres fonctionnalités du genre dans la syntaxe
markdown.

Mais à quoi sert ce découpage en paragraphe, à part créer des bugs qui
sont indevinables pour l'utilisateur puisque la prévisualisation se
comporte correctement ? Je suppose qu'on peut "réordonner" des
paragraphes, mais un éditeur de texte fait aussi ça très bien. Pour
faire une gestion de conflits du pauvre ? Je pense qu'il vaudrait
mieux s'en dábarasser, et éventuellement penser à d'autres méthodes de
gestion de conflit; avec un historique disponible, ça ne devrait pas
être difficile.

Planète Linux a aussi sorti son premier hors-série consacré à Android, avec pas loin de 150 applications mises en avant, au rythme de quatre par page. Pas libres dans la grande majorité, mais pratiques pour ceux qui débarquent sur cette plate-forme.

Je ne lisais déjà pas Planète Linux avant, je vais continuer !

C'est de la presse qui essaie de vendre, sans grand intérêt par rapport à ce qu'on peut trouver sur internet (en suivant de bons sites en ligne comme par exemple Linux Weekly News ou Ars Technica).

(Heureusement ce n'est pas le cas général, MISC fait de très bons dossiers par exemple, et GMLF a aussi de bons articles régulièrement.)

Euh... C'est le libre! Tu n'aimes pas le libre, ne fait pas de libre, mais ne râle pas sur les conséquences logiques du libre. Râle plutôt sur ceux qui râles des conséquences normales du libre (bref, râle sur toi ;-) ).

Je ne suis pas d'accord. Il y a une différence entre ce qui est légitime et ce qui est légal, et il est tout à fait normal de souhaiter que les gens se montrent corrects même dans les cas où ils n'y sont pas forcés par la loi.

Il y a ce genre de débats entre GPL et BSD: la GPL impose (modulo la question de qui est le client, etc.) que les modifications au code lui-même soient redistribuées, la BSD ne l'impose pas. Pourtant les projets sous BSD préfèrent en général qu'on les tienne au courant des changements qu'on fait downstream, mais si ce n'est pas une obligation légale. Il leur arrive même de râler quand les projets ne le font pas. Je ne pense pas qu'on puisse dire qu'ils n'ont pas à râler, parce que "c'est le libre".

Plus généralement il faut savoir faire la part des choses entre ce qui est légalement obligatoire et ce qui est recommandé. Mais ça ne veut pas dire, comme ton message le laisse entendre, que seul l'obligatoire existe et que les gens qui comptent sur les bonnes actions (et qui dont se permettent de râler quand elles n'ont pas lieu) sont de doux idiots. C'est un raisonnement ultra-libéral (tant que le marché ne nous force pas à ne pas polluer en produisant, allons-y à fond et maximisons les gains, le social c'est pour les tartes, et si tu râles, bah c'est la loi du marché mon petit) qui n'est correct ni en économie, ni au sujet du logiciel libre, à mon humble avis; bien sûr c'est subjectif, tu as le droit de raisonner ainsi (tu rentres dans la catégorie "personne peu fréquentable" mais bon), mais ce n'est pas la seule position rationnelle.

Surtout il a rien compris au libre

Je suis assez d'accord sur le fait que les explications données sont relativement fumeuses, et qu'elles montrent une relative mécompréhension des licences. Il n'empêche que la (L)GPL oblige une personne ayant intégré une brique sous cette licence dans son paquet applicatif à fournir les sources, et que cela peut être compris comme une "obligation de reconnaissance" (même si en fait elle n'est obligatoire qu'envers les clients; en pratique elle est en général distribuée publiquement).

De toute façon à la rigueur que la raison soit bonne ou non "on s'en fiche", si le but c'est de comprendre pourquoi les développeurs utilisent plus ou moins telle ou telle licence logiciel. Si Zed Shaw passe à la GPL pour des raisons qui ne sont pas tout à fait fondées rationnellement, il n'empêche qu'il passe bruyamment à la GPL, qu'il est écouté dans sa communauté, et qu'il pourra avoir de l'influence sur d'autres (effet mouton). Dans l'autre sens il y a aussi des projets qui quittent la GPL pour des raisons relativement bidon, comme Ruby 1.9.3.

Au final ce sont des comportements non rationnels, donc bien que ça ait de l'intérêt de comprendre finement les licences pour expliquer aux gens si leurs décisions correspond à la réalité, ça ne suffit malheureusement pas. Les gens font aussi des choix pour des mauvaises raisons et ces raisons il faut les mentionner, les comprendre et les expliquer, même si elles ne sont pas directement rationnelles...

Bien sûr, je corrige: "ils n'auraient peut-être pas eu de clients".

Si c'est une dépendance externe, pourquoi la LGPL (avec éventuellement des exceptions de linking si nécessaire) ne serait-elle pas acceptable ?

C'est très crédible.

Ce qui est clair c'est la partie "nouveaux arrivants". Après pourquoi ces nouveaux arrivants utiliseraient-ils moins la GPL en proportion, par rapport aux vieux ? Quelques hypothèses, sans désir d'exhaustivité.

• le désir d'exploitation commerciale que tu as évoqué, mais je ne pense pas que ce soit la raison première; d'ailleurs la GPL, dans un schéma de dual licensing, peut être plus propice à l'exploitation commerciale qu'une MIT/BSD; par exemple si Qt et MySQL avaient été mis sous BSD dès le départ, elles n'auraient pas eu clients.

• une mauvaise image qu'aurait la GPL, liée à la mauvaise image que l'on diffuse souvent de la FSF (des intégristes qui n'ont rien compris); ils donnent les bâtons pour se faire battre, mais il y a des phénomènes amplificateurs qui ne sont pas innocents (le bloggueur machin qui tweette sur le fait que Stallman ne veut pas de perroquets, etc.)

• la jeunesse des projets; l'intérêt de la GPL n'est pas forcément évident à premier abord, et certains développeurs passent à la GPL après d'autres projets où ils n'ont pas été satisfait par le manque d'hérédité sur leur travail. Cf. par exemple Zed Shaw : Why I (A/L)GPL (après c'est une grande gueule à prendre avec des pincettes).

• de simples effets de mode, voire de foule; il y a des communautés entières qui utilisent telle ou telle licence sans trop réfléchir, parce que les projets sur lesquels ils se basent l'utilisent, et qu'ils ne connaissent pas bien les questions de licence. Sur beaucoup de points en fait, pas seulement les licences logicielles, la communauté Ruby en particulier joue un peu le rôle de la "communauté d'inculte", qui croit tout savoir et ne prend donc même pas la peine de se renseigner sur comment c'est fait ailleurs.

Pas la peine de faire du défaitisme non plus. Les choix de licence c'est aussi des effets de mode, ça peut varier. Passer de 70% à 50% c'est une descente, mais ça ne veut pas dire automatiquement qu'on est à 0% dans 3 périodes, et les discours "on peut ne rien faire ou s'adapter à la disparition de la GPL" sont donc un peu prématurés.

On a entendu les mêmes discours au sujet d'Apache qui déclinait contre IIS il y a quelques années (du même ordre, genre de 80% à 50%). Résultat, aujourd'hui Apache n'a pas regagné l'avance perdue, par contre c'est nginx et lighttpd qui sont apparus et au final IIS n'est plus en deuxième position selon certaines mesures.

Bref, difficile de savoir ce que l'avenir ne nous réserve, mais je trouve que tu tires tes conclusions un peu vite.

En fait tu utilises deux arguments différents, qui sont chacun intéressants, mais incompatibles entre eux.

D'une part tu dis : quand les grosses boîtes libèrent du code, elles ne cherchent pas à faire vivre un projet libre autour, à récupérer les modifications des autres (ce que facilite la GPL), c'est du code vieux qu'elles ont dans les cartons et qu'elles mettent simplement sur le trottoir en se disant que c'est tant mieux, si n'importe qui s'en sert comme ça lui chante. C'est pour ça qu'ils ne s'embêtent pas avec la GPL, une licence BSD suffit pour les "code dump", et de toute façon ils ne comptent pas intégrer des retours.

D'autre part tu dis : la GPL c'est moins bien parce que regardez, les grosses boîtes utilisent d'autres licences.

Je persiste à dire que le fait d'être un individu ou une entreprise ne change rien en soit : toutes les personnes physiques ou morales qui détiennent du copyright font des choix de licence, héréditaires ((L)GPL) ou non (MIT/BSD), selon les compromis qu'ils veulent entre permissivités et retours des utilisateurs.

Il n'y a rien de spécifique aux individus ou aux entreprises qui force l'un ou l'autre choix. Ce qui change, c'est ce que les gens veulent faire du code qu'ils diffusent :
- s'ils veulent faire vivre un projet autour, le maintenir sur la durée, intégrer les contributions externes, avoir le plus de retour et d'améliorations possible, ça fait du sens de choisir une licence héréditaire (mais on peut aussi prendre une non héréditaire et compter sur le fair play des utilisateurs)
- s'ils ne comptent pas tenir le code à jour ou intégrer des modifications et ne s'intéressent pas à l'usage qui est fait par la suite, en particulier si c'est un "code dump" d'une vieille version ou d'un logiciel qui ne les intéresse plus, alors ils peuvent choisir une licence non héréditaire (donc plus permissive, donc avec un public plus large)

Il y a à la fois des individus et des entreprises qui se retrouvent dans les deux cas. Du fait que 'plein de gens font du "code dump"' tu ne peux pas déduire que les licences héréditaires sont moins bien pour le libre : cette conclusion ne s'applique pas aux gens qui veulent au contraire faire vivre un projet.

Bref, pour moi cette nuance a un intérêt, mais ne permet pas de porter un jugement entre les différentes licences. Par contre, il pourrait servir à expliquer le changement de proportion entre les licences, si plus de gens faisaient du "code dump" aujourd'hui qu'il y a 5 ans. Je ne sais pas si c'est le cas, mais c'est crédible.

Une GPL n'aurait pas vraiment d'intérêt pour eux, à part complexifier les choses (problématique d'inclusion de patch dans leur version interne par exemple).

Je ne comprends pas cet argument. L'intérêt de la GPL pour les boîtes est le même que pour les individus isolés : ils s'assurent que les modifications faites à leur code et diffusées restent libres, et qu'ils peuvent donc les intégrer à leur version upstream si ça leur chante.

Pour la question de l'inclusion des patches, les groupes qui veulent se simplifier la gestion légale demandent de toute façon l'abandon du copyright (cf. ton exemple ci-dessous de la bibliothèque Closure de Google, distribuée sous licence Apache, mais qui demande tout de même un accord sur la licence des contributions (donner ton copyright à Google) avant d'accepter un patch). Donc que le projet soit en GPL ou une licence permissive ne change rien de ce point de vue là, ils conservent le copyright entier et donc la possibilité de le relicencier comme ils le souhaitent.

Pour moi c'est une question de culture et de préférences personnelles, mais dans ton message il n'y a rien qui indique pourquoi les boîtes devraient préférer MIT/BSD à GPL.

D'abord, es-tu sûr qu'il s'agit bien de "perdre un contributeur" ici ? Moi aussi je reçois de temps en temps des mails de gens "intéressés par mon logiciel" et me demandant de faire ceci ou cela. En général, quoi que je réponde par la suite (et en particulier si je prends effectivement le temps de faire ceci ou cela), je n'en entends plus parler. Est-ce qu'il a donné des preuves concrètes qu'il serait prêt à contribuer, par exemple est-ce qu'il a envoyé un patch ?

Ensuite je ne comprends pas trop l'argumentaire dans ce cas. La GPL est plus restrictive que la LGPL si tu utilises le code comme une bibliothèque, mais toi tu as écrit un programme destiné à l'utilisateur final. Quel usage de ton programme met-il en avant pour justifier l'abandon de la GPL ? Si je comprends bien l'intention de la LLGPL, il s'agit de permettre aux gens de développer et distribuer des hooks par dessus ton programme (en utilisant les facilités dynamiques de Lisp) sous une licence quelconque. Ce cas de figure me semble raisonnable, mais est-ce que ça correspond à ce que tu souhaites ?

À ta place je refuserais poliment ce genre de demandes. Quand on est un extérieur qui s'intéresse à un projet, on commence par faire l'effort de s'adapter aux coutumes locales. Quand je participe à un projet déjà existant j'accepte les licences, langages, systèmes de gestion de version etc. en place, je ne commence pas par dire "il est cool ton projet mais tu ne voudrais pas le recoder en ?". Il me semble qu'un extérieur devrait aussi s'adapter à la licence en place (après éventuellement s'être renseignés des raisons de ce choix). Les choix de licence sont personnels et du ressort des détenteurs du copyright. Si la personne en question devient effectivement contributeur et se retrouve à avoir une proportion non-négligeable de ton projet, alors il aura du poids pour suggérer un changement de licence. Avant, c'est rustre.

La GPLv3 est longue, certes, mais je ne la trouve pas "difficile à comprendre". Je ne dis pas que je comprends toutes les nuances et ce que les avocats vont en conclure, etc., mais quand je lis le texte de la licence je comprends la finalité de chaque paragraphe et je peux décider de si cela me semble acceptable ou non pour mon projet.

As-tu des exemples précis de parties de la licence que tu trouves trop difficiles à comprendre ?

Je ne comprends pas trop ta position. La Gplv3 traite plus de choses (Tivoization, brevets logiciels...) donc est plus longue, par contre je trouve que le texte est au contraire plus clair. Elle me semble plus lisible que la GPLv2.

Il y a un point que l'on pourrait qualifier de "complexe", qui est le fait que la GPLv3 prévoit son "extensibilité", elle parle de comment on peut ajouter par dessus la GPLv3 des autorisations supplémentaires pour la rendre plus permissive. C'est une partie de la licence qui n'est pas très longue mais un peu abstraite, et donc un peu plus complexe. Pour moi cela correspond à un travail de factorisation, et ma fibre de programmeur me fait apprécier l'initiative. En particulier, la licence LGPL3, du coup, est beaucoup plus courte que la précédente, puisqu'elle est présentée comme un diff par dessus la GPL3.

Après tout l'original n'est qu'à un clic de souris non ?

Ben oui, mais ça fait une différence pratique importante (en termes geek, le coût de context-switching est du même ordre de grandeur que le coût de lecture); je ne sais pas si les admins ont accès à des statistiques sur ces liens, mais je m'attends à ce que les annonces de RC originales soient très peu lues, alors qu'à priori une majorité des visiteurs les liraient en anglais sans problème si elles étaient plus mises en avant.

Dans le corps de la news il y a une dizaine d'autres liens vers des articles LWN pour ceux qui veulent approfondir un point.

Je pensais plus à quelque chose d'explicite, à la fin de l'article par exemples, "quelques bons articles sur LWN", avec des liens et une courte phrase expliquant le contenu et son intérêt. Ça permettrait de leur donner un statut un peu plus explicite, et de mentionner aussi des sujets qui ne sont pas directement en rapport avec le kernel (par exemple il y a quelques semaines il y avait eu un article intéressant sur les modèles mémoires faibles).

Enfin peut-être qu'il vaudrait mieux faire des dépêches séparées "Best of LWN", mais je me disais que le surcoût à les mettre dans cette dépêche serait faible, par rapport à celui de faire un truc spécialement pour ça (et donc enrober, etc.).

Une dépêche sur le noyau toujours aussi agréable, merci. J'ai deux méta-questions.

1. Je salue l'effort de traduction des annonces de RC (d'ailleurs je me dis à chaque fois que j'aurais pu aider, mais je ne m'en rend pas compte quand il y a quelque chose à faire, il faudrait suivre de plus près l'espace de rédaction), mais j'aime mieux lire les versions originales, ne serait-ce que parce que ça permet d'apprendre des tournures anglaises amusantes. Dans certains documents traduits comme les interview, tu mets en général le texte à la fin en commentaire, là tu mets l'adresse des annonces sur la mailing-list, mais est-ce qu'on pourrait envisager quelque chose de plus intégré? Je me dis qu'on pourrait par exemple écrire un petit bout de Javascript pour avoir un rendu "tabbed", avec un cadre qui affiche l'une des versions au choix. Est-ce que vous pensez que ça serait une bonne idée ? Dans un premier temps, je serais en faveur de mettre les deux versions à la suite, pour faciliter la lecture (sachant qu'on n'a pas à craindre le gain en longueur, vu où on en est...).

2. J'imagine que tu suis LWN.net, en plus des listes de lecture de développement du noyau. Si c'est le cas, peut-être pourrais-tu profiter des dépêches sur le noyau pour mettre des liens vers les articles LWN (sur le noyau ou pas) qui t'ont particulièrement intéressé pendant cette période ? Le coût en temps/effort me semble relativement faible, et ça pourrait intéresser les gens qui apprécient tes dépêches, voire les motiver pour s'abonner...

Il y a toujours des gens qui essaient de contourner l'esprit de la licence GPL en jouant sur son texte. La Tivoization était un problème avec la version 2 de la licence GPL de la licence, qui a été "corrigé" dans la version 3 (un choix relativement polémique). Si d'autres acteurs trouvent d'autres méthode pour contourner l'esprit de la GPL en interdisant à des gens de faire tourner du code GPL qui leur a été fourni, la licence sera encore modifiée pour corriger ça.

De toute façon ce n'est pas le point : ce que je veux dire c'est que le droit à l'utilisation fait partie de la définition du "free software" qu'utilise RMS, et que son commentaire est tout à fait justifié dans ce contexte. Il ne s'agit pas spécifiquement de la licence GPL (même si d'autres licences sont moins bien faites sur ce point) qui de toute façon n'est pas forcément la licence utilisée dans les cas cités ici, mais du fait que les partisans du "free software" se battent effectivement pour le droit à l'utilisation du logiciel en général, pour tous les usages.

Et je pense que RMS a tort cette fois, ou plus précisément, il se laisse aller à une réduction malheureuse : il ne s'agit plus que du logiciel. Il n'est plus question que de l'ouverture du code que j'exécute sur ma machine, mais de la possibilité de l'exécuter.

C'est sûrement vrai que RMS est coupable de tout ramener au logiciel libre, mais pour ce coup-ci (en tout cas le passionnant récit qui en est fait ici) il a raison: la liberté d'utiliser le logiciel (pour tous les usages) est la première liberté du logiciel libre et de la licence GPL.

Dans le texte de la GPL v3 par exemple:
> This License explicitly affirms your unlimited permission to run the unmodified Program.

Quand RMS appelle à ce que tout le logiciel que l'on utilise soit rendu libre, il pense en particulier au danger auquel pense Cory Doctorow : pour que les utilisateurs "aient le contrôle", il faut qu'ils puissent bien sûr étudier et modifier, mais avant tout exécuter (la version originale ou la version modifiée).

Concrètement ça veut dire que si un vendeur d'ordinateurs style HP/Dell/etc. te vend un ordinateur qui contient un programme GPL (dans les logiciels préinstallés) et qui emploie des techniques qui restreignent la liberté d'usage de ce programme, il est en violation de la GPL et peut être attaqué comme tel.

Tu t'es permis d'écrire "L'article aurait dû être rédigé sans ceci et cela".

Je n'ai jamais écrit ça. J'ai dit que, pour de prochains articles du genre, il vaudrait mieux les écrire sans ceci ou cela (j'ai utilisé pour ça la forme "tu devrais", mais c'est une tournure utilisée pour donner un conseil personnel, pas pour exprimer une obligation).

Malicia n'a pas cherché à choquer

Je sais, je parlais de ta réponse "Non aux tabous.", pas de la dépêche.

Par contre, la "retenue" que tu nous proposes : ne pas parler d'une étude scientifique parce qu'elle touche au sexe.

Tes trois premières phrases dans ta réponse sont en contre-sens par rapport à ce que je dis, et cette quatrième déforme terriblement mon propos; après tu me dis que tu as "tout à fait compris mon point de vue"...

Je me plains que les plaisanteries grasses occupent une partie trop importante de la dépêche, qui la rend moins agréable à lire (et moins accessible). Il y a à la fois une question de quantité (une allusion vulgaire de temps en temps ça passe, quand c'est la moitié de la dépêche c'est lourd), et une question de la façon dont c'est traité. Comme je l'ai dit je n'ai rien par exemple contre l'histoire de l'orgasme féminin dans un MRI (alors que du point de vue de la sexualité c'est évidemment la plus salace).

J'imagine que le contenu de cette dépêche ne représente pas 100% de l'information scientifique absorbée par Malicia cette année, mais qu'elle a fait une sélection de contenu qu'elle pensait susceptible d'intéresser les lecteurs. Il me semble raisonnable de donner son avis sur les critères de sélection, et j'aime mieux voir du contenu scientifique intéressant, qui marquera la discipline concernée, plutôt que du contenu choisi parce que, oh oh oh, on ne sait pas si la récolte de sperme a été pratiquée par stimulation manuelle.

Si l'information scientifique est intéressante par ailleurs, je suis tout à fait pour qu'on en parle. Ce que je regrette c'est qu'elle soit choisie non pour son intérêt intrinsèque mais pour aspect graveleux, et que la rédaction en remette une couche derrière.

Je te conseille d'essayer de lire la SF en anglais. C'est un genre dont les auteurs ont souvent un style assez clair, accessible aux gens dont ce n'est pas la langue maternelle, même si ça dépend des auteurs (Neuromancer de Gibson a été un de mes premiers livres en version originale, et je me souviens avoir eu du mal; dans un autre genre Terry Pratchett n'est pas facile d'approche) mais, même quand les traductions sont bonnes, je trouve ça plus agréable de lire le texte tel que l'a écrit l'auteur, et en plus ça fait travailler les langues.

Je dis ça parce que Le Dieu venu du Centaure, je n'ai pas compris tout de suite ce que c'était, dans mon souvenir il s'appelle The three stigmata of Palmer Eldritch, ce qui ne ressemble pas tant que ça. Le mysticisme y est en effet très (trop?) présent, surtout asur la fin, mais on peut aussi s'en détacher, et profiter de l'histoire et des beaux moments de confusion qu'elle offre.

la SF est-elle vraiment super-méga-top importante et indispensable ?

Malgré quelques défauts de jeunesse comme tout le monde, la SF est un genre littéraire à part entière. La SF n'est ni plus ni moins importante que la lecture en général. Si tu aimes lire et que tu penses que ça t'apporte quelque chose, tu trouveras certainement ton compte dans certaines œuvres de SF.

Sinon, à part si c'est justement le genre qui peut "provoquer un déclic" par son attrait et sa facilité et par là t'aider à lire plus (mais j'ai des doutes, si tu connais déjà Stephen King par exemple, qui est un très bon point d'entrée), ça te barbera sans doute comme le reste.

Après la SF (ou la Fantasy) c'est bien mais il ne faut pas s'enfermer dedans, comme dans n'importe quel autre genre.

Je suis assez d'accord avec ton analyse, en particulier sur le fait que les fins de saga sont en général déprimantes. Mais Asimov n'est pas le seul, pour moi c'est une règle ou presque : Hyperion Cantos ou Ender's Game souffrent du même défaut. Longtemps après avoir été déçu par la fin de Fondation, j'ai lu Psychohistorical Crisis de Kingsbury et trouvé ça rafraîchissant (même si ça n'est pas non plus la panacée).

J'ai découvert Philip K. Dick plus récemment et je ne peux que le recommander. Ubik est très bon, mais j'ai trouvé certaines autres nouvelles encore plus puissantes, comme Do Androids Dream of Electric Sheep?, et surtout A Scanner Darkly et Martian Time-Slip.

Tu es un peu dur avec la Horde du contre-vent. C'est un livre qui ne m'a pas convaincu non plus, il a des défauts (et pas de fin) mais ça reste un exercice original et a de bons moments. C'est bien de lire de la SF en langue originale française de temps en temps, et si c'est le pire livre que tu as lu depuis longtemps, dis-toi que tu as de la chance et des critères de sélection remarquablement efficaces.

Du coup c'est bien, je vais pouvoir aller regarder ce que je ne connais pas dans ta liste, Egan et Spinrad. Merci pour ton commentaire.

Surtout pour un désaccord concernant l'édition de commentaires...

Comme toi, je pensais que ce serait une fonctionnalité sans histoire (à part l'effort de développement initial). Résultat, après des heures de travail, rien n'a changé ou presque, parce que les gens sont contre le changement (mais ne prennent pas la peine de faire un retour sur les propositions faites pour satisfaire tout le monde). C'est de là que vient la frustration; mais en fait elle n'est pas tellement liée au travail perdu dans le passé, plutôt à l'impression déprimante que la communication n'est pas possible et qu'il n'y aura donc pas de contribution future.

Je salue aussi le travail de Bruno Michel qui fait l'effort de développer le site et qui y investit un temps considérable. Je regrette, par ailleurs, que l'ouverture du code et les encouragements à contribuer n'aient pas plus d'effets, concrètement il développe tout seul, ce qui est un peu triste pour un site communautaire. J'ai passé du temps à dire aux gens qui refusent de libérer leur site web que ça a des avantages concrets, mais force est de constater que LinuxFR, pour l'instant du moins, n'est pas un exemple éclatant.

Je mets là un lien avec un vague rapport, Open Sourcing Your Game While It's Still Popular, au cas où ça intéresse des gens. C'est ce que la "nouvelle génération" de développeurs de jeux vidéos, sans idéologie (je veux dire sans la culture du libre), pense de la libération du code pour ses intérêts pratique.

Étant donné que je répondais directement au commentaire de M4rotte, mon message utilisais la deuxième personne pour parler de lui, et la troisième personne pour parler de toi. Je suis désolé si ça t'a vexée, ce n'était pas du tout mon intention.

J'ai l'impression que vous faites des efforts importants pour ne pas comprendre ce que je veux dire. Je suis désolé si tu as été contrariée par mon insistance. J'ai commencé par un message court, clair et condensé, et j'ai développé parce que M4rotte visiblement ne comprend pas mon point de vue.

Je regrette qu'il soit si difficile de donner (et surtout de faire comprendre) son avis, et que tu te sentes obligée de m'insulter quand tu n'es pas d'accord avec moi. Tant pis.