arnaudus a écrit 5316 commentaires

Ah oui, mais on parle du moteur de recherche, là, pas de l'email. Ça n'est pas tout à fait pareil, parce que le moteur de recherche, on lui donne les infos volontairement. On peut aussi aller trifouiller dans les options de confidentialité de Google pour lui demander de ne pas garder l'historique, je crois (après, je ne sais pas s'il le fait vraiment). La différence avec Gmail, c'est qu'on ne transmet pas volontairement un email à Google, on le transmet à un correspondant.

Mais sur le fond, je suis d'accord, les requêtes dans un moteur de recherche peuvent être beaucoup plus informatives et beaucoup plus intimes que les emails. Google sait avant tout le monde (et parfois même avant toi!) si tu es malade, si tu es enceinte, si tu t'es fait virer, si tu cherches à mettre ton fric aux Caïman, si tu aimes les photos de nains nus, si tu montes une entreprise ou si tu cherches un avocat spécialisé dans le divorce. D'un autre côté, c'est quand même plus facile de rendre ces requêtes non-nominatives si on le souhaite ; je ne suis pas certain que l'historique soit conservé si longtemps que ça (ne serait-ce que pour des raisons de stockage --- 1000 milliards de requêtes par an, ça ne fait pas tant que ça, remarque, quelques Po par an peut-être).

Après, c'est la même chose pour tout tiers de "confiance" : ta banque, ton FAI, la sécu, ton employeur, ou la RATP on des données très personnelles sur toi et les membres de ta famille. J'imagine (peut-être naïvement) qu'elles sont relativement bien protégées des intrusions extérieures chez Google comparé à ces derniers.

En fait, le problème est que personne ne semble souhaiter identifier le problème précisément. On parle de problème de vie privée ou de libertés individuelles, mais sans plus de précisions, on ne peut pas parler de solutions. Qu'est-ce qui pose problème avant tout?

1) que les emails passent par un état déchiffré avant d'être affichés sur l'écran? Mais dans ce cas, est-ce qu'on met les filtres anti-spam dans le problème? Est-ce qu'on n'autorise que le client mail à filtrer les spams, tagguer les pubs, avertir en cas de tentative de hameçonnage?

2) que les emails puissent être analysés par des algorithmes. Ceci dit, ça pose le même problème que les filtres anti-spam, et avec le développement inévitable de l'IA, les algorithmes vont de mieux en mieux comprendre ce qu'on raconte. Est-ce que des tags "personnel", "urgent", "interne", "nouveau client" ajoutés par un algo poseraient des problèmes de confidentialité?

3) que les emails puissent être interceptés par autre chose que le serveur de destination. C'est un problème, mais ça ne résoud pas le cas des webmails populaires.

4) que les emails puissent être analysés à des fins commerciales. Autrement dit, si Google veut faire des études scientifiques sur les évolutions du vocabulaire ou la longueur des phrases, OK, mais si c'est pour afficher de la pub, pas d'accord.

5) que les emails puissent être accessibles à des prestataires privés

6) que les emails puissent être accessibles à des services gouvernementaux

7) que les emails puissent être lus par des êtres humains.

8) que les emails puissent être lus par des êtres humains à des fins illégitimes, illégales, ou non-éthiques.

On peut ajouter autant de niveaux supplémentaires qu'on souhaite. Et en fonction de ce qu'on souhaite, on peut discuter des solutions, et on peut même discuter de l'existence du problème—et du niveau de fantasmes qu'il y a dans la présentation d'un grand problème qui n'est jamais réellement explicité.

Au final, on parle aussi beaucoup de problèmes potentiels, mais pas de problèmes réels. Si on désactive adBlock, on peut voir les publicités proposées par gmail. C'est une bonne expérience, parce qu'on peut réellement s'apercevoir à quel point les algorithmes ne comprennent rien. "J'ai changé le bébé, il n'y a plus qu'une couche, il faut en racheter" -> Dulux Valentine; "Le frigo est vide" -> Darty, etc. Imaginer que Google connait tout de votre vie est réellement de l'ordre du fantasme, Google a en effet les données qui permettrait de vous connaitre si un être humain passait suffisamment de temps à lire et analyser vos mails, mais les algos n'attrappent que quelques mot-clés, ne semblent avoir aucune mémoire ni aucunes capacités analytiques. Ou s'ils les ont, ils ne les utilisent pas pour cibler les pubs. Ou bien s'ils détectent un esprit critique ils font exprès de vous mettre des pubs idiotes pour vous faire croire qu'ils sont incapables de tout savoir sur vous. Ou alors ils s'en foutent réellement de votre vie.

Concernant sort, là tu bloques sur l'écriture OO mainstream on dirait.

Bah non, ma compréhension du problème est que la généricité de la fonction sort() impose l'utilisation d'itérateurs uniquement parce que les containers de la STL n'héritent pas d'une interface commune.

L'écriture qui est sympa c'est sort(v) pourquoi est-ce que cela devrait être v.sort()?

L'intuition est peut-être la chose au monde la moins partagée, mais pour moi les signatures "intuitives" de ces deux fonctions devraient être

std::vector<T> sort(const std::vector<T> &);
void vector<t>::sort();

Je trouve très surprenant en général que y = f(x) puisse modifier x, et les compilos récents n'ont aucun mal à optimiser v = sort(v) correctement. Ceci dit, j'ai peut-être tendance à tenter de retrouver en C++ des concepts qui viennent des langages de plus haut niveau.

elle va supporter l'écriture vi |= action::sort | action::unique;

On peut voter quelque part pour le support du Brainfuck dans C++19?

Je veux un tableau dans une classe concrète? std::vector<>. C'est générique et je m'en sers.

J'ai l'impression qu'on ne se comprend pas, et au bout d'un moment ça tourne en rond. Je pense que personne ici ne parle de ne pas utiliser les conteneurs de la STL ; utiliser la STL n'a pas grand chose à voir avec la programmation générique.

La question (telle que je la comprend), c'est de choisir entre

struct EtatCivil {
   string nom;
   string prenom;
};

et

template<typename n, typename p>
struct EtatCivil {
    n nom;
    p prenom;
};

comme paradigme de base. Sans aller jusqu'à prétendre qu'il faut 100% de l'un ou de l'autre, mon argument c'est que la plupart des problèmes ont une solution avec l'un ou l'autre, et que comme les deux sont très difficilement fongibles, on va orienter l'ensemble de l'architecture du programme dans un sens.

Je veux trier un tableau ? std::sort()

Je pense que c'est un excellent exemple. C'est générique? OK. Mais l'ergonomie est dégueulasse, parce que tu as oublié que ça s'utilisait comme ça : std::sort(v.begin(), v.end());. Évidemment, à force de voir ça, on est habitué, mais tu ne trouves pas que v.sort() serait bien plus élégant? Il permettrait aussi le polymorphisme si tous les containers dérivaient d'une interface STL_cont. Bref, la programmation générique pour la bibliothèque standard, c'est un choix technique, mais ça me semble assez excessif de prétendre que c'est pratique et ergonomique ; d'une manière générale, la STL est relativement imbittable, les syntaxes sont contre-intuitives, et le code est assez illisible.

je sais ne pas pouvoir vouloir d'un T ITruc::operator non plus—oui, de connaitre la limitation, ça oriente fortement ce que je m'autorise à vouloir faire.

Oui, donc dans les faits si tu ne veux pas utiliser le polymorphisme, bah la programmation à base de templates ne te pose pas de problème :-) Encore une fois, mon point de vue n'est pas de dire que la programmation générique c'est pourri, c'est de dire que le C++ OO et le C++ générique (au sens de templates non triviaux sur des objets complexes) sont philosophiquement et techniquement incompatibles. On peut concevoir tout un projet en C++ OO ou en C++ générique, mais ça va fortement conditionner le sous-ensemble du C++ et les designs qu'on va utiliser.

Bien sûr, on peut écrire des trucs hybrides, ça va compiler, et ça va faire d'excellents exercices pour les gens qui aiment se prendre la tête. La question, c'est plutôt "est-ce que des projets réels vont utiliser ça"?

PS: Truc peut tout à fait hériter de ITruc ou de TrucImpl. C'est même assez classique quand on veut combiner une variabilité dynamique avec une statique.

C'est super bancal comme solution, parce que ça demande une surcouche, et que l'interface n'est pas templatée. Prenins un exemple trivial : je veux faire un vecteur de vecteurs de différents types. On peut bien créer quelque chose comme vector<MyVec*> avec des MyvecT<T> qui dérivent d'une classe MyVec, mais à ma connaissance on ne peut pas avoir une méthode MyVec::at(size_t i) const qui retourne le bon type (*).

Si la programmation générique était fongible avec la POO, alors le langage devrait assimiler un template à une interface, et autoriser des choses comme vector * v; qui se comporteraient comme des pointeurs vers des classes virtuelles pures. Je ne sais pas si c'est pour des raisons techniques ou philosophiques que le C++ a choisi des syntaxes incompatibles, mais je ne vois pas comment on peut l'interpréter autrement que par la volonté de définir deux dialectes qui ne sont pas destinés à cohabiter dans le même code.

(*) Enfin si, je crois qu'on peut si la méthode retourne un void* qu'on peut caster avec un typename qu'on aurait défini dans Myvec<T>. Je ne sais pas s'il existe une personne sur terre qui pourrait croire que c'est une bonne idée.

Ces paradigmes ne doivent pas être opposés. Ils offrent des choses complémentaires.

Et du coup, il faut combien de décennies d'apprentissage avant de savoir choisir le bon paradigme?

pour gérer la mémoire, par défaut je vais utiliser des unique_ptr<> qui sont génériques.

Je pense que personne ne considère qu'utiliser les conteneurs de la STL revient à faire de la programmation générique.

Je comprends que devoir écrire ce genre de classe from scratch fasse peur à quelqu'un qui n'est pas habitué

Je n'aime pas le fenouil braisé. Est-ce que ça veut dire que j'ai peur du fenouil braisé? Est-ce légitime de m'expliquer que la seule raison pour laquelle je n'aime pas le fenouil braisé est que je n'y suis pas habitué? Au bout d'un moment, c'est agaçant.

Reste que ce ne sont pas des paradigmes opposés.

Si, parce qu'ils sont incompatibles, et qu'ils répondent tous les deux au même besoin de base (utiliser le même code pour appliquer les mêmes opérations à des objets différents qui partagent un certain nombre de propriétés). Si on va au-delà des simples conteneurs style STL, on se retrouve avec des possibilités d'architectures parallèles (d'un côté, Truc<A> et Truc<B>, d'un autre côté TrucA et TrucB qui dérivent de Truc), avec chacun leurs paradigmes, leur syntaxe, leurs contraintes et leurs avantages. Mélanger les deux dans un projet un peu complexe me semble assez incongru, au moins autant que de mélanger des paradigmes C et C++, par exemple.

Je pense qu'en 2017 nous publierons de petites dépêches pour expliquer les aspects de la programmation générique et surtout la méta-programmation (et un peu de programmation fonctionnelle) car c'est l'intérêt de coder en C++.

Bah, je n'ai rien personnellement contre la programmation générique. C'est juste que le C++ OO et le C++ générique ressemblent de plus en plus à deux dialectes distincts, au moins autant que le C et le C++98. Et s'il est techniquement possible de mélanger les deux (le compilateur le comprend), c'est de plus en plus compliqué de les faire cohabiter dans le même projet. Mon impression est que de toutes manières les programmeurs ne vont plus pouvoir s'en sortir avec les deux paradigmes à la fois; d'un côté on aura le monde des design patterns et du typage dynamique, et de l'autre côté on aura les templates de templates et le typage statique.

Par contre, du coup, appeler tout ça "C++" et continuer à prétendre que c'est le même langage, ça n'est pas très sain. Pour recruter quelqu'un dans une boîte ou dans un projet, il va falloir préciser quels aspects du C++ on souhaite privilégier. De même, il pourrait être sympa de commencer à définir des sous-ensembles plus ou moins officiels qu'on pourrait passer aux compilateurs, pour vérifier qu'on respecte bien le cadre imposé. J'ai appris il y a peu de temps que pour émuler ce comportement, certains n'acceptaient que d'anciennes versions des compilateurs, ce qui me semble profondément stupide (on peut ne pas vouloir autre chose que du C++98 tout en voulant profiter des corrections de bugs et des optimisations des compilos récents).

Le mot-clé template fait peur, démystifions-le ;-)

Je ne pense pas que ça soit les templates qui fassent peur, c'est l'ensemble pas très intuitif des syntaxes associées.

D'abord, merci pour cette série d'articles, c'est assez agréable de pouvoir passer 5 minutes à lire quelque chose d'assez compact sur chaque nouveauté plutôt qu'une énorme dépêche ultra-résumée.

Sur le fond, quand je lis le code proposé, je me dis quand même qu'on est carrément en train de définir un nouveau langage avec la programmation générique. Je n'ai pas l'intention de résoudre en un commentaire la discussion éternelle sur le fait que C++ est ou n'est pas un langage orienté objet, mais mon point de vue est quand même que le multi-paradigme a une limite, c'est celle de la compréhension croisée entre les différents programmeurs.

Concrètement, j'ai un mal fou à discuter avec les «petits jeunes» qui apprennent la syntaxe générique du C++, parce que j'ai quand même l'impression que pour beaucoup d'applications, la programmation OO et la programmation générique permettent de faire des choses qui se superposent largement, mais qui sont assez incompatibles. On peut partir sur un design à base de templates ou sur un design à base de hiérarchies de classes, et une fois ce choix fait, on a quasiment deux dialectes incompatibles. Ça va devenir de plus en plus compliqué de définir ce qu'est le C++, puisqu'au final quelque chose comme "le logiciel est codé en C++" ne voudra plus dire grand chose, à part qu'il est compilable par un compilateur C++.

Tu n'as pas à le faire, la plupart des sites ont une liste de CGU longue comme le bras que tu es censé respecter quand tu consultes le site. Ceci dit, la plupart du temps, il ne s'agit que de rappels légaux (respect du droit d'auteur, etc), d'une liste de trucs qu'ils se permettent de faire avec tes données personnelles (à peu près tout, en général), de toutes les permissions que tu donnes en utilisant le site (installer des cookies, stocker ton IP et la signature de ton navigateur, transmettre tout ça à leurs partenaires commerciaux, etc), de l'adresse à qui tu peux t'adresser en cas de recours, et de leur droit à te bloquer si tu ne respectes pas les CGU.

Ceci dit, je ne sais pas vraiment à quel point tout ça est opposable, puisque c'est planqué dans un petit coin. Mais bon, ça vaut bien les conditions générales de vente des supermarchés, qui sont affichées en police 8 à 3m de hauteur derrière une pub à la caisse centrale.

Dans tous les cas, devoir cliquer sur "oui j'ai lu les CGV et je suis d'accord", ça n'est juste qu'une précaution juridique parmi d'autres. S'il n'y a pas de case, le vendeur peut toujours (à raison) argumenter du fait que le contrat de vente est conclu par la transaction financière (et que si tu payes c'est que tu as pris le soin de te renseigner), et l'acheteur pourra toujours prétendre que personne ne lit les CGV et qu'il y a tromperie quand elles ne sont pas "standard" (ce qui est vrai aussi). Sur le fond, les CGV doivent avoir plus de valeur que les CGU (parce qu'il y a contrat de vente), mais les clauses doivent en être identiques. À mon avis, la seule différence est qu'ils peuvent très facilement bloquer ton accès au site si tu n'es pas lié financièrement, alors que bloquer ton IP quand tu as un abonnement pose un réel problème.

J'imagine que tu n'as déja pas le droit de les bloquer (ça doit figurer dans les conditions générales d'utilisation). Ça ne change donc rien pour toi.

Je pense que c'est très mal expliqué, mais j'ai l'impression que l'idée est que les auteurs des blogs s'engagent à ne pas publier des choses déja protégées par le droit d'auteur ( = contenu original). Ça ne veut pas forcément dire que le contenu est librement réutilisable. De toutes manières, la formulation est tellement foireuse ("libre de droits" ne veut rien dire de particulier, à part peut-être qu'on peut espérer le réutiliser sans payer) que je ne vois pas ce qu'on peut en faire.

Je pense que c'est exactement ça: remplacer les concours de la fonction publique par des contrats de droit privé.

Ça ne coûte pas moins cher mais ça permet de singer les méthodes de management du privé, avec en plus de grosses dérogations (par exemple la possibilité de faire 5 ou 6 ans de CDD avant d'être remplacé par un autre CDD, ou l'absence de prud'hommes et la quasi-impunité de l'employeur).

Sans être normal, c'est habituel. Il arrive très souvent que la qualité de la messagerie fournie par l'administration soit tellement médiocre que les fonctionnaires utilisent des adresses perso pour pouvoir continuer à bosser.

Demande-toi qui va administer les serveurs, acheter et entretenir le matériel, etc. Si le service n'est pas fourni par l'État, les collectivités n'ont ni forcément les moyens ni la volonté de gérer des serveurs mail…

Euh… en parlant de confusion, paille, poutre, etc. Parce que là, il faut y aller mollo avec les champis, hein.

Au passage, le syllogisme est un raisonnement valide. Tu confonds avec le sophisme. En tout état de cause, tu confonds un peu tout, et c'est bien ce qu'on te reproche.

Et créer un compte juste pour pour poster des commentaires pseudo-sarcastiques de deux lignes, ça relève quoi exactement?

Honnêtement, je ne vois pas la différence entre un syndicat professionnel et une corporation. C'est juste un vocabulaire plus récent pour désigner la même chose (professionnels potentiellement concurrents qui se regroupent pour défendre des intérêts communs).

Bah, le truc c'est qu'avec le libre, c'est déraisonnable de vendre le logiciel en tant que tel (parce qu'il va arriver à plus ou moins long terme exactement ce dont on parle ici : quelqu'un va distribuer gratuitement ou moins cher ce logiciel). On peut vendre du service, vendre un site de téléchargement rapide et clair, avec une base de données fonctionnelle, on peut aussi vendre du support (développement, forum d'aide personnalisée, rapports de bugs, etc), mais en tout cas on vend une plus-value par rapport au logiciel. Si un concurrent arrive à faire la même chose moins cher, c'est soit qu'il est mieux organisé, soit qu'on fournit à ses clients un produit dont ils n'ont pas vraiment besoin.

Les business models du libre, c'est un serpent de mer. Tout le monde prétend avoir la solution miraculeuse, mais dans les faits, c'est assez compliqué d'avoir un truc rentable, et c'est rarement durable. On peut accuser la licence, le manque de fair-play des concurrents ; on peut même se demander si le besoin de lier du support ne pousse pas les éditeurs de logiciels libres à les rendre ardus à installer et à maitriser ; toutes ces discussions sont pertinentes. Toutefois, il faut bien garder à l'esprit que le logiciel libre n'a pas du tout été imaginé pour être rentable, il a été imaginé pour donner à l'utilisateur, et à lui seul, tout un tas de libertés dont il ne disposait pas avec les logiciels propriétaires. Si quelqu'un arrive à faire du logiciel libre en étant rentable, tant mieux pour lui, et s'il n'y arrive pas, tant pis. Mais ce problème de rentabilité est totalement orthogonal aux histoires de liberté (et d'ailleurs, on peut se poser les mêmes questions sur le freeware, par exemple).

la plupart des gens ne connaissent personne à qui "c'est vraiment arrivé"

Peut-être parce qu'on fréquente plus de linuxiens que la plupart des gens :-)

Sans blague, devoir réinstaller Windows tous les ans parce que le PC est blindé de virus et de crapwares, ça n'est arrivé à personne?

C'est clair que le risque d'être soumis à un traitement individualisé (intrusion et vol de données perso) est probablement plus élevé pour quelqu'un de connu et/ou riche que pour le pékin lambda, mais c'est la même chose pour les cambriolages. Est-ce une raison pour laisser les portes ouvertes? Je n'ai pas grand chose à voler, mais ça n'est pas une raison, c'est le principe d'être volé qui est chiant.

Le risque de voir son PC familial d'être transformé en botnet est par contre très réel. Même si au final ça n'a pas l'air très grave, c'est une histoire de responsabilité collective, comme la vaccination ou le tri des poubelles. Les attaques de déni de service peuvent réellement créer de vrais problèmes, et quand on sert de relai on a une part de responsabilité là-dedans.

En gros, ne pas télécharger n'importe quoi, c'est exactement pareil que de ne pas laisser rentrer n'importe qui chez soi, ou de ne pas manger n'importe quoi : c'est une question de bon sens. Tu connais beaucoup de gens qui sont morts d'empoisonnement? Est-ce que c'est une raison pour bouffer tous les champignons que tu croises? Est-ce que le fait d'avoir l'impression de ne risquer qu'une bonne journée bloqué sur les toilettes est une bonne raison pour essayer des nouvelles espèces? Le raisonnement est foireux à la base. On ne mange pas les champis qu'on ne connait pas, et on n'exécute pas n'importe quoi sur son ordinateur, c'est pareil.

Quand je vois que, par exemple, le Syndicat Professionnel des Récoltants d'Algues de Rives a gagné un combat d'intérêt général

Certes, mais est-ce que ces récoltants d'algues prétendaient lutter aussi contre les politiques corrompus, promouvoir la 6e République, restaurer la liberté de la presse, ou donnaient leur avis sur la guerre en Syrie? Mon problème, ça n'est pas l'existence d'un syndicat professionnel, c'est justement de créer quelque chose qui a des objectifs politiques complètement hors-sujet, voire assez loufoques. Il y a un risque que la plupart des professionnels ne se reconnaissent pas dans ce discours, et qu'au final le syndicat ne représente absolument pas les logiciels libres. C'est totalement contre-productif, libre = licence libre, et on a plein de trucs à défendre dans ce cadre (libre concurrence, respect des standards, etc). Le reste du discours parasite le logiciel libre et fait croire que quand on publie sous GPL on est automatiquement contre l'état d'urgence, ça n'a aucun sens (et ça montre que les initiateurs de ce syndicat ne savent pas choisir leurs combats, ils mènent une quête personnelle et ça risque de n'intéresser qu'eux mêmes).

je ne pense pas qu'il s'agisse de complot. il s'agit alors bien d'un rapport tragique au réel.

Le complot, c'est d'imaginer que quelqu'un ou quelques groupes d'intérêt pilotent ça, et c'est complètement farfelu. Il n'y a aucun pilotage là-dedans, c'est juste que les choses se font (en général dans le sens qui rapporte le plus de pognon). Par exemple, Facebook n'a pour unique but que de retenir les gens sur leur site et de leur faire bouffer de la pub. C'est juste que de leur filer des liens vers des trucs qui confortent leurs idées les fait rester plus longtemps. Tout fonctionne comme ça, il n'y a pas de grand plan anti-démocratique, il n'y a pas de grand plan du tout, d'ailleurs.

quand édicter des fausses-vérités sert à gagner des élections majeures

Je ne vois pas ce que ça a à voir avec le LL, et de toutes manières ça n'est carrément pas nouveau. Les populistes n'ont pas attendu Internet et les GAFAM pour propager de la propagande bidon et arriver au pouvoir par des moyens plus ou moins démocratiques. Je ne pense pas d'ailleurs que la vague réactionnaire dans le monde entier ne soit due qu'à Internet ; en Russie, en Turquie, en Hongrie, l'extrême droite tient le pouvoir sans que ça soit dû à Internet. On peut d'ailleurs noter que dans toutes les dictatures ou les régimes totalitaires, Internet est fortement contrôlé. Je pense que c'est plutôt une preuve que la circulation des idées nuit au contrôle des esprits.

Au passage, les thèse présentées dans la description du syndicat (complot du monde capitaliste pour contrôler les masses et biaiser le processus démocratique) est typiquement l'une des ces idées complotistes, très probablement fausses, qui circulent sur Internet à l'intérieur de cercles assez fermés, et qui tournent en rond entre les gens déja convaincus qui renforcent leurs certitudes en lisant toujours les mêmes fadaises. Je trouve ça assez étrange d'utiliser cet argument dans un tel contexte ; il suffit d'aller lire un peu les journaux de droite (voire les journaux tout court, parce que je n'ai jamais réellement vu de tels trucs ailleurs que sur des forums et sites activistes) pour se rendre compte que cette "vérité" est loin d'être considérée comme crédible par une très grande majorité de la population. Je trouve d'ailleurs un peu malheureux qu'on puisse considérer que Linuxfr soit un lieu où il est normal d'écrire ce genre de choses sans risquer la contradiction. Ce n'est pas parce qu'une connerie est "de gauche" qu'on doit faire semblant de n'avoir rien vu.

Plus il y aura d'interlocuteur pour les "décideurs" publics ou privés, mieux ca sera.

Bof, le problème est plutôt que quand il y a trop d'interlocuteurs, ça revient à dire qu'il n'y en a pas. Mais bon, là n'est pas vraiment la question, la question est plutôt de se demander qui se retrouve dans ce syndicat/lobby et qui est censé être représenté par les idées défendues. Dans le texte, j'ai l'impression qu'on a une sorte de mélange de concepts libéraux de droite (au sens européen), complotistes, et libéraux de gauche (au sens US). Il y en a beaucoup, des chefs d'entreprise Macrono-Mélanchonnistes?

Je suis d'accord pour dire que le LL a du mal à trouver des business models viables, mais en gros, là, ça veut dire que le modèle repose sur une espèce d'accord tacite pour ne pas "forker" le système de clubs, alors qu'il y a une opportunité assez nette de faire de l'argent là-dedans. Tu ne trouves pas naïf d'imaginer que ça n'arriverait pas? Il n'y a pas de "fair-play" dans le milieu des affaires, ce n'est pas une faille de la GPL d'autoriser ça, c'est une fonctionnalité de la licence d'empêcher le monopole de la distribution.

Selon l'avis de certains propriétaires de club, le nouveau meta-club est du warez.

Je ne comprends pas le raisonnement. Les clubs récupèrent du code GPL et offrent un service en échange d'un abonnement (plate-forme de téléchargement ou quelque chose comme ça). C'est tout à fait légal. Mais pourquoi souhaiteraient-ils empêcher d'autres de faire pareil? Ils pourraient éventuellement prétendre que leur base de données est protégée par le droit d'auteur, mais ça ne vaut que s'ils se sont fait piquer la structure de la bdd, et pas seulement le contenu.

J'ai comme l'impression qu'il y a une profonde incompréhension de ce qu'est le logiciel libre, là. On a le droit de faire du pognon avec en redistribuant du code créé par d'autres, mais évidemment on n'a pas l'exclusivité de ce business (qui ne peut probablement pas être rentable à long terme, puisqu'il va bien y avoir quelqu'un qui va récupérer les sources et les redistribuer dans des conditions plus avantageuses). Ça n'est pas malsain, c'est juste que le but du LL est de protéger ses utilisateurs, un peu les développeurs, et pas les distributeurs. Tout fonctionne donc parfaitement bien, non?

Personnellement, je trouve très dommage de n'offrir qu'une seule vision du logiciel libre, alors que le LL c'est avant tout la liberté et l'absence d'orientation politique. Le monde syndical est pourri par cette collusion syndicalisme/politique, je ne vois pas tellement ce qu'il y a de nouveau à offrir de nouveau une telle vision. Surtout quand on flirte allègrement avec la théorie du complot ou les affirmations vagues et péremptoires sur l'anti-démocratie ou offrir en pâture «les médias» (au passage, les médias utilisent du logiciel libre et sont aussi très concerné par le respect des sources et des communications privées).

Je crois que ça a déja été dit par ailleurs, mais l'idée de restreindre la chose aux personnes morales est à mon avis en décalage avec ce qui est la communauté du logiciel libre ; entre les travailleurs indépendants, les salariés, et le monde académique, il y a une foule de développeurs et d'utilisateurs de logiciels libres qui sont exclus de la démarche. Mais finalement, les objectifs du syndicat semble être de défendre les intérêts des éditeurs de logiciels libres, ce qui pourrait être très différent de la défense des intérêts des développeurs salariés ou fonctionnaires, ou même des utilisateurs de logiciels libres.

Ambitieusement démocrates, par la diversité de nos métiers

On est à la limite de l'argument fallacieux, là, quand même. Quel est le rapport entre le fait d'être démocrate et d'avoir des métiers diversifiés? La diversité des métiers oblige à une approche multi-disciplinaire (droit, économie, gestion, science et informatique par exemple), mais ça peut très bien être fait efficacement de manière dictatoriale…

L'avancement du projet Electrolysis dépend pour une bonne part du test des extensions

Du coup, si je comprends bien, ça veut dire que l'introduction d'une nouvelle feature dans Firefox est retardée parce qu'il faut attendre que l'écosystème des extensions se mette à jour.

Là, comme ça, ça ne fait pas très envie. Ça veut dire que le développement de Firefox est contraint par le développement d'extensions indépendantes qui s'interfacent avec FF. J'ai du mal à voir l'intérêt d'un système d'extensions (au moins en terme de cycle de développement) dans un tel contexte ; si la compatibilité d'un certain nombre d'extensions est cruciale, alors elles devraient être incluses dans le code principal (puisque de toutes manières il faut les attendre pour balancer une release), mais là, je trouve que les rapports de force entre l'équipe de FF et les développeurs d'extensions semble étrangement inversés.