🚲 Tanguy Ortolo a écrit 12509 commentaires

Et alors ? Je pense que ni la fondation Apache ni la fondation Document ne sont complètement cons, tous deux œuvrent pour le logiciel libre, donc ils devraient bien s'entendre. En tout cas je les vois mal se faire la guerre, et de toute façon du code donné à la fondation Apache, c'est en pratique du code libéré.

Bon, je recentre la discussion. À la base je répondais à ça :

Et un github/gitourious decentralisé consisterait a pouvoir faire du clone/pull request a partir de son instance de serveur sur l'officiel ou sur celui d'un autre gars.

Et ca on en est franchement loin.

Et je répondais donc ceci :

Bah, ça on s'en moque, clone et pull c'est du Git de base, ça n'a pas besoin de GitHub.

Ce à quoi tu m'avais rétorqué que GitHub fournissait d'autres fonctionnalités. Alors, certes mais ça n'a rien à voir avec le sujet : ça ne change rien au fait qu'on n'a pas besoin de GitHub pour faire des clone et des pull, choses qu'on peut, pour en revenir au sujet, très bien faire avec un service git perso.

Ah oui, et pour ceux qui penseraient que Git seul, c'est trop nul pour un projet, je rappelle qu'il existe un projet hénaurme projet libre qui utilise Git, à coup de clone et pull, et qui se débrouille très bien sans GitHub. Linux.

Eh bien, git pull c'est du git de base. Deux moyens de proposer une modification au responsable d'un projet :

• si c'est une petite modification : git format-patch, puis envoyer le résultat par courrier électronique ;
• si c'est plus gros : mettre un dépôt git quelque part, puis écrire au responsable pour lui demander de faire un git pull.

Ça m'énerve, cet espèce de vague mythe comme quoi GitHub permet un truc génial qui sont les requêtes de pull : ça n'a rien à voir avec GitHub, ils proposent peut-être une interface web kikoolol pour ça mais une requête de pull c'est du {courrier électronique|messagerie instantanée} + Git de base !

Quelqu'un m'a d'ailleurs signalé qu'un de mes projets serait mieux sur GitHub pour qu'il puisse me faire des requêtes de pull : eh ben non, si tu veux me suggérer de récupérer des modifications sur ton dépôt, pas besoin de GitHub, j'ai une adresse électronique et un identifiant Jabber, ça suffira.

Et de manière générale, les chatrooms XMPP n'apporte rien d'innovant/nouveau/révolutionnaire par rapport à IRC. Donc, on garde l'ancien.

1. Une véritable identité. Tu peux bannir untel@example.com de ton salon.
2. La possibilité de choisir librement son pseudo et de le réserver de façon indépendante de l'identifiant.
3. Aucun effort supplémentaire à se connecter à un salon sur un serveur différent, aucun inconvénient à héberger un salon sur un serveur autonome.

Ensuite, des avantages qui ne sont pas liés aux salons, mais au fait que c'est un protocole de messagerie instantanée et de présence et non seulement un protocole de salons de discussion :

1. La possibilité de discuter de personne à personne directement.
2. Les informations de présence.

En pratique, pour parler d'auto-hébergement, j'avais besoin d'un salon. J'avais le choix entre :

• créer un salon sur un réseau IRC connu : ç'aurait été antinomique avec l'idée d'auto-hébergement ;
• faire tourner mon serveur IRC autonome : je n'aurais eu aucun visiteur ;
• faire tourner mon propre serveur Jabber et y héberger ce salon : là c'est auto-hébergé et j'en ai, des visiteurs.

Je croyais que tu ne comptais pas jouer. Si c'est vraiment le cas, prends une carte avec contrôleur graphique intégré, ça consommera moins et ça coûtera moins cher à l'achat. Si possible une Intel, comme ça ça marchera d'office sous GNU/Linux.

D'ailleurs la carte mère que tu as sélectionnée, que je te recommande également — j'ai presque la même chez moi, version Mini-ITX —, est équipée d'un contrôleur graphique intégré utilisant la GPU intégrée aux processeur de la famille i.

Mais qu'est-ce que tu vas faire d'une telle puissance électrique ? Une machine de joueur, ça doit bien tirer dans les 300 watts, une machine de bureau puissante dans les 150 watts, et une Micro-ATX, je dirais dans les 100 watts. Bref, pas la peine de prendre une alimentation surpuissante.

. carte graphique Nvidia GeForce 9800MGTX

Je croyais que tu ne comptais pas jouer. Si c'est vraiment le cas, prends une carte avec contrôleur graphique intégré, ça consommera moins et ça coûtera moins cher à l'achat. Si possible une Intel, comme ça ça marchera d'office sous GNU/Linux.

. disque hybride interne 500 Go

Bof, perso, si je voulais de la vitesse au démarrage j'achèterais un SSD de 10 Gio pour y caser le système d'exploitation avec une marge confortable, et une disque dur d'une capacité suffisante pour y mettre mes données personnelles qui elles prennent de la place mais n'ont pas de raison de nécessiter des vitesses de lecture démentes.

Oui mais ton salon Jabber est attaché à ton serveur

Ou à mes serveurs. Qui te dit que je n'en ai qu'un ? Oui, on peut fournir un service Jabber réparti sur plusieurs serveurs.

On parle de forks (clone) et de récupérations (pull), alors j'indique que ça tombe bien, c'est du Git de base, pas besoin de GitHub pour ça. Et là, tu me rétorques qu'il y a d'autres fonctionnalités : c'est exact, mais c'est hors sujet.

Oui ? On parle d'adresse Internet, et ? IPv6 c'est mieux, certes, mais il est pertinent de parler d'adresse IPv4 quand même.

Super, des fonctionnalités pour coder en kikoolol. Comme si on avait besoin de ça…

Je crois que tu te trompes. Techniquement, ça pourrait être utilisé de façon aussi acentrée, mais la conception de base du protocole ne favorise pas cet usage.

En pratique, ça donne ça :

• avec IRC, on crée habituellement des salons sur un « réseau » existant ; crée ton serveur et met le salon officiel d'un projet dessus : tu resteras seul dessus, personne ne viendra voir ;
• avec Jabber, on peut créer des salons sur n'importe quel serveur existant ; crée ton serveur et met le salon officiel d'un projet dessus : ça ne dérangera aucun visiteur.

Bah, ça on s'en moque, clone et pull c'est du Git de base, ça n'a pas besoin de GitHub.

Je n'utilisais pas le terme d'anneau au sens topologique. J'ignore quel est le terme approprié, mais en tout cas IRC est fait pour fournir un ou plusieurs services disjoints par un ou plusieurs groupes de serveurs privilégiés. Ce qui est très différent du courrier électronique ou de Jabber.

Alors certes, c'est un vieux protocole, mais il est décentralisé.

Pas exactement. IRC a une conception en anneau de serveurs privilégiés, comme le vénérable USENET et les serveurs PGP synchronisés.

Contrairement au courrier électronique ou à Jabber, qui sont vraiment acentrés : avec ces protocoles, on peut créer son propre service sans grand désavantage.

Et l'énorme avantage à cette fragmentation est que à terme certains disparaîtront, d'autre seront venu se rajouter, il y a tout de même pas mal de chance que le meilleur l'emporte.

Dans le cas d'un système à effet de réseau, comme le service d'avatars, le « meilleur », c'est l'existant, dans ce cas. Ce qui est vraiment dommage lorsqu'il souffre d'une grave lacune.

Comme il est prioritaire d'avoir des ponts entre, par exemple, des formats de paquets des distros, pour que les gens doivent pas faire 10x un même paquet si ils veulent diffuser un logiciel comme il ne devraient pas faire 10x le même avatar si ils veulent diffuser un avatar?

Linux Standard Base. De rien.

Les paquets RPM LSB, c'est parfait pour permettre aux gens de distribuer eux-mêmes leurs logiciels s'ils ne sont pas assez intéressants ou libres pour être intégrés aux distros. Bien sûr, ça ne remplace pas l'intégration aux distros qui est généralement de qualité supérieure.

Ah, au fait, après il faudra ajouter les Gravatar, les Libravatar, et puis les 3 types d'avatars Jabber (dans la VCard, dans les infos de présence, en PubSub). ;-)

J'ai l'impression que c'est complètement idiot comme discussion. Pour faire clair !

• un protocole ouvert et acentré permet à n'importe qui de fournir son propre service ;
• beaucoup d"internautes pourraient mettre en place leur propre service sans devoir ajouter une machine de plus ;
• pour ceux qui ne souhaitent pas le faire, l'hébergement mutualisé ou le service géré, ça existe…

C'est à nuancer tout de même. On peut par exemple, lorsqu'il s'agit d'ajouter quelques fonctionnalités, étendre un protocole existant. Et lorsqu'on a vraiment une rupture à faire, en créer un nouveau.

après, libre à moi de choisir si je déploie leurs correctifs.

Voilà tout le problème. Imagine qu'il y ait 4 protocoles différents de courrier électronique, et de temps en temps un nouveau qui apparaît. Et que les administrateurs de services de courriers décident d'implémenter l'un ou l'autre de ces protocoles selon leurs goûts.

Ah, eh bien désolé alors. Ainsi expliquée, ta formulation est correcte, mais elle reste à mon avis trompeuse.

Tu permets aux gens qui postent des commentaires sur ton blog de modifier le code de ton moteur, toi ?

La fragmentation peut être un problème

Non, la fragmentation est un problème majeur dans ce genre de système. Tu monte ton blog, et tu dois implémenter Gravatar, Pavatar, Libravatar et les avatars Jabber. Ah, eet puis tous les futurs nouveaux qui auront cru intelligent de concevoir encore un autre protocole. Tu fais quoi ?

Le décentralisation, c’est bien dans l’idée, mais il y a des choses qui n’ont aucun intérêt à être décentralisées.

On en reparlera dans cinquante ans, quand Gravatar sera devenu… eh bien, on n'en sait rien justement, il n'y a aucune garantie.