Changaco a écrit 59 commentaires

Si tu veux que ton interlocuteur comprenne il ne faut pas mélanger les contre-arguments. D'autant plus que le scandale Volkswagen n'est pas un très bon exemple puisqu'il me semble que les autorités étaient au courant de la tricherie.

Le gouvernement veut que le logiciel ne soit pas modifiable. Donc pas d’accès au code source.

Comme je l'ai dit dans ce commentaire le non-accès au code source n'empêche pas les modifications. Ce serait bien d'essayer de leur faire comprendre ça.

Ne pas publier les sources d'un logiciel ne le rend pas inaltérable, un binaire peut être décompilé et modifié, même si c'est plus difficile que quand on a la source. Le seul moyen pour que le logiciel soit inaltérable c'est de le faire tourner sur un matériel qui empêche les modifications non signées, et dans ce cas le logiciel peut tout à fait être libre. Bref, même si on interprète l'article comme exigeant l'inaltérabilité du logiciel plutôt que celle des données, ce qui est une interprétation plus que douteuse, ça n'interdit en rien le logiciel libre.

J'ai aussi demandé l'autorisation d'insérer des liens hypertextes renvoyant vers leur site web […]

Je ne vois pas quelle base légale permettrait à une personne d'interdire les liens vers son site. Si on se met à respecter les "mentions légales" qui n'ont pas de base légale, ça va mal finir…

Ça ne fait que déplacer le problème, d'une compétition entre individus à une compétition entre équipes.

Pas sûr que "compétition" soit le mot le plus adapté. Ce n'est pas comme un match de foot où il y a un vainqueur et un perdant, le nombre de "gagnants" dans Gratipay n'est limité que par la capacité de financement des donateurs. Théoriquement si on trouvait suffisamment de donateurs on pourrait financer tous les créateurs à 100%.

Pourquoi ? Je ne comprends pas le lien logique. Tu peux très bien donner à quelqu'un pour le remercier ou le récompenser.

Oui tu peux, je dis juste que dans le cas des personnes qui reçoivent des dons importants via Gratipay, c'est en général parce qu'elles travaillent sur des projets que leurs donateurs trouvent utiles.

Supprimer les leaderboards en tant que symptôme du problème, ce serait dommage. Il vaudrait mieux les anonymiser et les déplacer dans les pages de statistiques, pour que la distribution des revenus reste visible. Sinon, Gratipay deviendra un truc complètement opaque.

Oui il faudrait ajouter des statistiques sur la distribution des revenus, cf #317.

Ça fait des années qu'on me rétorque ça sans fournir de preuve. Après quelques recherches je n'ai personnellement rien trouvé pour appuyer cette affirmation. Si les entreprises n'ont pas le droit de recevoir des dons manuels alors quelqu'un devrait pouvoir fournir un lien vers l'article de loi idoine sur Legifrance.

C'est contradictoire. Si je te dis "donne-moi dix balles", comment peux-tu savoir si ces dix balles vont, par exemple, financer un projet logiciel libre ?

On ne peut pas vérifier comment l'argent est utilisé, mais à priori si tu reçois des dons importants c'est que tu as réussi à convaincre des donateurs que tu vas faire quelque chose d'utile avec, i.e. que tu as des projets sur lesquels tu vas pouvoir travailler grâce aux dons qui te permettront de (sur)vivre.

Je n'en sais rien ! Le gros problème est que des gens qui veulent faire un don monétaire sont, en général, des gens qui n'ont pas envie de s'impliquer plus concrètement : ils n'ont donc pas trop envie de faire les recherches nécessaires pour choisir réellement à qui donner, ils vont juste donner aux causes ou individus les plus populaires.

D'où l'intérêt d'afficher des suggestions qui ne se limitent pas aux plus populaires, pour aider et encourager les donateurs.

Ça veut dire que tu t'es greffé sur une équipe qui est elle-même populaire.

La différence est qu'il est plus simple de faire de la communication pour une équipe que pour tous ses membres individuellement.

Ta présentation parle de revenu de base, mais il faut constater que la distribution des revenus générée par Gratipay est ultra-inégalitaire (je ne sais pas s'il y a encore les leaderboard pour comparer, mais c'était brutal : une très petite minorité au top qui reçoit des montants substantiels, et le reste de l'anecdotique).

Les leaderboards existent encore sur les pages des communautés, et il est vrai qu'ils amplifient l'effet d'agrégation sur les plus populaires, c'est pourquoi on envisage de les remplacer (#1928).

Dans Gratipay on donne à quelqu'un point barre, il n'y a pas d'objectifs fixés ni de promesses de tâches effectuées. Donc je ne vois pas comment on peut appeler ça du financement de projets, le terme gratification affiché par Gratipay me semble beaucoup plus approprié : j'aime bien ce que fait machin(e), je lui donne de l'argent. Rien ne me dit que l'argent servira à financer de l'activité sur un projet, ni lequel (plutôt qu'à aller boire des coups, par exemple).

Je suis d'accord avec ce que tu dis, et j'aime bien aussi le terme "gratification", mais je maintiens qu'à travers les individus et les équipes qui reçoivent des dons sur Gratipay ce sont bien des projets qui sont financés, même si les dons eux-mêmes ne sont pas liés à un projet spécifique et qu'ils n'impliquent aucune promesse de la part du gratifié.

Ensuite l'idée d'un système de gratification n'est pas mauvaise, c'est l'implémentation que je critique.

Selon toi comment pourrait-on améliorer l'implémentation ?

Un exemple typique, c'est une distribution Linux : il serait raisonnable que je gratifie les auteurs des logiciels que j'utilise (il y en a certainement beaucoup), comment je fais ?

Actuellement c'est plutôt difficile, dans le futur tu pourras entrer le nom du logiciel dans la boîte de recherche (#469) et avec un peu de chance trouver les personnes qui y contribuent.

Avec Gratipay, je suis conduit à choisir le ou les plus populaires, ceux qui ont pour politique de se mettre en avant.

Conduit par quoi ?

Note que le fondateur de Gratipay admet l'existence du problème :

Et il propose une solution: les équipes. Par exemple je reçois actuellement + de 100 $/semaine, et ce n'est pas parce que je suis populaire (mon compte Twitter n'a qu'une centaine de followers), mais parce que je fais partie de l'équipe Gratipay.

Gratipay est bien un système de crowdfunding, ce terme n'implique pas le financement d'une tâche spécifique mais seulement le financement de quelque chose par une multitude de particuliers.

Je comprends ce que tu veux dire par "pas comme un système de financement de projets", mais "projet" est un terme trop vague dans cette phrase, c'est pour ça que je dis plutôt "tâche spécifique". Gratipay est centré autour d'individus (cf mon profil par exemple) et d'équipes (par exemple l'équipe Gratipay que je cite dans le billet), mais à travers les personnes ce sont bien des projets qui sont financés (à moins de donner à quelqu'un pour qu'il ne fasse rien, mais bon…).

En ce qui concerne la langue, il est vrai que le site lui-même ne fournit pas de moyen de la modifier, bien sûr tu peux toujours le faire dans ton navigateur. La traduction française n'est pas obsolète, elle ne date que d'une semaine.

Il y a en effet un problème de difficulté à attirer des dons, mais il n'est pas spécifique à Gratipay. Pour n'importe quelle campagne de crowdfunding il faut savoir communiquer de manière à atteindre et convaincre des donateurs.

Gratipay a tout de même une lacune qui amplifie ce problème, c'est le manque de discoverability, nous n'affichons pas de suggestions qui permettraient aux donateurs de trouver plus de personnes à qui donner. Là encore patience, on y travaille.

Très bonne idée, les Pull Requests sont bienvenues.

Une authentification classique par email + mot de passe est une demande de longue date (#1052) qui devrait être implémentée prochainement.

Il n'y a pour le moment pas de moyen de contacter ses donateurs (#2521), ni de savoir qui ils sont (#236). Comme je le dis dans le billet le site a de nombreuses lacunes, on a réparé pas mal de problèmes "sous le capot" ces derniers mois. Dans les mois qui viennent il devrait y avoir de grosses améliorations côté utilisateur.

Non, là aussi les frais évoqués sont ceux des intermédiaires financiers, en l'occurrence Paypal qui prend 2% sur chaque transaction. Les transferts directs vers les comptes bancaires en dehors des États-Unis seront disponibles quand le service qu'utilise Gratipay les aura implémenté. Si cela traîne trop longtemps l'alternative envisagée est de créer une structure légale en Europe de façon à pouvoir utiliser un service de paiement européen. Vous pouvez suivre les progrès sur GitHub.

Je ne connaissait pas le texte "For a truly acentric Internet".

Tu devrais parcourir les liens de DNS problems and alternatives, qui est l'équivalent en anglais du billet de bortzmeyer.

Lequel choisir ? Est-ce que je prend PrénomNom, Nom ou PNom ? Avec quel tld (.org, .com, .fr) ?

Dans ma proposition tu n'as pas de TLD à choisir, tu enregistres directement un nom top level.

Comment gérer les conflits ? Premier arrivé premier servi ? Comment tu fais pour ceux qui ont le même nom ?

Premier arrivé premier servi oui, à part si quelqu'un d'autre a une raison légitime de réclamer un nom qui a déjà été enregistré. Pour les conflits où plusieurs entités sont légitimes une solution possible est de mettre en place l'équivalent d'une page d'homonymie de Wikipedia.

Je vois que tu cites le billet de bortzmeyer sur la difficulté à remplacer le DNS, et la solution que tu proposes est d'abandonner l'aspect "parlant/mémorable" des identifiants. C'est une idée qui revient régulièrement (e.g. For a truly acentric Internet), ta réflexion est plus centrée sur les personnes que sur les noms de domaines mais en réalité c'est le même problème.

Je suis plutôt partisan d'abandonner l'aspect totalement décentralisé pour conserver des identifiants "parlants/mémorables", plus stables et plus simples à utiliser que des nombres aléatoires. C'est la base de ma proposition Internet Naming System.

Et après j'en lis plus haut que XMPP est un vieux truc alors qu'on est parmi le top de la technologie Internet […] et qu'on est constamment à innover sur tous les fronts et à prendre des risques en adoptant des technologies avant les autres.

L'un n'empêche pas l'autre. Il y a des mises à jour mineures qui étaient prévues par les RFC précédentes, mais le cœur reste inchangé et commence à se faire vieux. Le W3C aussi innove dans tous les sens, le Web n'est pas pour autant le meilleur possible, car on ne peut pas toucher aux fondamentaux.

Alors bien sûr on cherche aussi la rétrocompatibilité en même temps. Mais après si on cassait l'interopérabilité entre les serveurs récents et anciens, vous iriez encore vous plaindre (et un peu plus à raison pour une fois)!

Personne n'a proposer de casser le réseau XMPP.

Je parlais bien de changement de JID, et ce que je voulais dire c'est que cette opération est pénible car XMPP mélange localisation et identité, ce qui fait qu'on ne peut pas «se déplacer» facilement.

Je pense que le protocole serait plus simple (et les implémentations plus légères) s'il avait été conçu autour d'un mécanisme de pub-sub générique.

XMPP fonctionne à peu près correctement en tant que protocole de messagerie instantanée, mais contrairement à ce que soutiennent ses partisans il n'est ni générique ni efficace.

• XMPP repose sur XML ce qui le rend :
  • lourd, c'est pas gigantesque mais ça joue quand même
  • lent, d'autant plus que tous les serveurs sont censés valider chaque paquet si je me souviens bien
  • incapable de transporter efficacement (ni base64 ni ouverture d'une nouvelle connexion) des données binaires comme des images
• XMPP n'est pas basé sur des concepts génériques qui permettraient une factorisation du code et des standards :
  • PubSub n'est qu'une XEP parmi d'autres alors que ce concept fondamental devrait être au cœur du protocole, par exemple pour gérer la liste de contacts
  • la sémantique de base ( <message>, <presence> et <iq> ) est liée à la messagerie alors qu'elle devrait se focaliser sur le routage des paquets dans le réseau XMPP
• XMPP ne règle pas le problème de l'identité sur Internet, le JID est dépendant du serveur et en changer est pénible

Bref, XMPP est un vieux protocole et la XSF fait partie de la même église que le W3C, celle de la rétro-compatibilité à tout prix et de la vision à court terme. Maintenir voire améliorer XMPP est tout à fait louable, mais réfléchir à sa succession me parait nécessaire si l'on ne veut pas que les futures innovations soient privatisées et privatrices comme l'est Facebook aujourd'hui.

Pour la configuration c'est surtout un problème d'implémentation ÀMHA.

Pour le par-feu ça ne fait que repousser le filtrage des paquets IPsec jusqu'à la machine cible.

Pour la QoS je ne sais pas trop, mais au pire on peut toujours utiliser un chiffrement de plus haut niveau pour ce qui est prioritaire et considérer les paquets IPsec comme non prioritaires.

C'est juste optparse qui est limité, avec argparse ça doit être facilement faisable.

Si les anciennes versions des paquets sont encore en cache on peut revenir en arrière sans problème à condition d'attendre la fin des téléchargements pour commencer l'exécution des scripts ( post-installation, etc ) si ceux-ci effectuent des opérations irréversibles ( mise à jour de config par exemple ).

Si les anciennes versions ne sont pas en cache on peut imaginer de créer ce cache de sauvegarde avant de commencer la mise à jour mais au final ça risque de ne pas valoir le coup, à part si la mise à jour concerne 200 paquets et qu'un seul n'est pas en cache.

Étant donné que c'est exactement ce que j'ai dit j'ai du mal à voir ce que je n'avais pas compris selon toi.

Quant au fait qu'on y gagnerait en performance je répète ce que je disais dans mon premier message, à moins de garder la base des paquets dans le format du résolveur il y aura un coup de transcodage à chaque opération.

J'ai également un doute sur l'utilité de la chose pour une distribution en rolling-release et do it yourself style Arch Linux où il y a peu de conflits. Sortir l'attirail de recherche automatique de solution ne serait pas forcément bénéfique, quand bien même l'algorithme de résolution serait plus efficace.

Si j'ai bien compris ce que tu veux faire c'est télécharger et installer en parallèle, par « vague » de dépendances. Ça me semble être une bonne idée même si quand on télécharge on écrit aussi sur le disque. Une option pour faire passer les paquets par un dossier temporaire, par exemple /tmp, pourrait peut-être accélérer la chose en utilisant tmpfs.

Je pense qu'une raison pour laquelle ça n'existe pas est que la parallélisation est souvent plus pénible à coder. Il est également plus difficile de rendre compte de l'avancement de travaux parallèle dans un terminal.