dani a écrit 116 commentaires

Ça fait un peu pub grossière. Beaucoup de crypto-bullshit et de c'est trop top sécure mais rien de plus concret à nous mettre sous la dent ?

Je ne vois pas en quoi avoir à gérer un seul fichier avec plein de lignes serait plus dur que de gérer plein de fichiers avec peu de lignes dans chaque

Parce que c'est bien plus fiable de générer le fichier entier que de le parser pour modifier uniquement certaines variables

on parle de la configuration du système lui-même, de l’OS quoi

Qui a quand même besoin d'être configuré…

Un système simple à gérer « à la main » sera simple à gérer avec des outils comme Ansible ou Puppet, et inversement

Je ne suis pas du tout d'accord. Ça peut très bien être adapté à une administration manuelle et pas du tout à de l'automatisation. La réponse suivante évoque les répertoires .d, ce qui supprime le pb par contre ;-)

simplicité et logique d'administration (toute la conf se passe dans un seul fichier ou presque)

Je vois souvent cet argument. Ça me semble justement un énorme inconvénient. La configuration par des outils comme ansible devient pas un peu l'enfer ? C'est peut être bien pour un serveur isolé, géré "à la main", mais dès qu'on dépasse ce cadre….

En quoi les projet en rapport avec les crypto-monnaies seraient plus impactés que n'importe quel autre ?

Parce qu'il n'y a pas que les messages, il y a énormément de meta données aussi

Les spec que j'ai donné ne représentent pas la capacité nécessaire en continu. Mais elles permettent d'absorber le pic de charge quand un utilisateur joint un "gros" salon. Avec un plus petit dimensionnement ça va marcher aussi, le temps de jonction sera juste plus important. Ça reste accessible à pratiquement n'importe qui, c'est pas du tout réservé aux "gros".

Pour utiliser Matrix depuis quelques mois, il ne faut pas tant de ressources que ça pour joindre les plus gros salons. Une VM avec 3Go de RAM, 2vCPU, et quelques Go de stockage pour la BDD et c'est bon. Certes, c'est plus que pour du Jabber, mais ça reste accessible à presque n'importe qui. Par contre, il faut déployer un serveur postgresql. SQLite3 lui ne suit pas

Thunderbird est un MUA. Aucun rapport avec un quelconque problème de confidentialité. Tes mails passent d'abord par un hébergeur, et si tu les relèves en IMAP, ils y restent. Que tu utilises TB, Outlook, rainloop, SOGo, ou gmail, pour les lire ça ne change absolument rien.

J'ai arrêté un peu avant. Quand ça s'est mis à parler de terroristes d'État. Ouf, j'ai échappé à l'écriture inclusive

Merci pour le journal. Ça me conforte dans mon idée de rester loin d'xmpp. Perso j'ai choisi Matrix, mais je pense que peu importe, n'importe quelle solution fonctionnera mieux. Ce journal est un très bon exemple de pourquoi XMPP ne prends pas.

Fedora est très bon là dessus, depuis des années. Mon desktop était installé en 14, et mis à jour par toutes les versions intermédiaires jusqu'à la 25 (j'ai fini par réinstaller pour passer sur un SSD). Dans l'ensemble très peu de problèmes, la plupart liés aux drivers NVIDIA proprio.

Aha. Merci. J'ai ri !

Il est possible de le faire avec Prosody (qui n'est qu'une des implémentation d'un serveur XMPP) depuis 6 ans

C'était possible avant, mais ce n'est que maintenant que c'est activé par défaut (d'ailleurs, est-ce que ça l'est, ou faut-il le configurer explicitement ?)

Sans fric, tu m'expliqueras comment tu fais pour promouvoir ton produit et gagner des part de marcher dans un contexte ultra concurrentiel.

Que l'argent y joue, probablement. Mais ce n'est pas le cœur du problème. Ce qui pousse tout ces géants à se fermer à la fédération, même si ils utilisent XMPP, c'est pour contrôler l'expérience utilisateur, et assurer que tout fonctionnera. Comme XMPP a été créé pour être modulaire, et que tout est définie sous forme d'extensions, tu ne peux pas t'assurer que la personne en face supportera quoi que ce soit, en dehors des fonctions de base. Du coup, un utilisateur de ton service qui discute avec un autre, par la fédération aura l'impression que mon service est nul parce que "ça marche pas, je ne peux pas envoyer des fichiers", alors que le problème vient de son contact, qui utilise un serveur et/ou client qui n'implémente pas ce qu'il faut. Donc pour éviter ça, on coupe la fédération, et on garantie aux utilisateurs de notre service une expérience optimale. Et ça, c'est bien un problème qui provient de la modularité d'XMPP.

C'est très à la mode de critiquer le côté modulaire de XMPP alors que c'est au contraire son grand point fort.

C'est à la fois son grand point fort, et son principal défaut

si vous prenez comme étalon un trucs très récent et en cours de standardisation comme OMEMO, forcément ça n'est pas partout

Non, je parle de fonctions de base, comme l'envoi de fichiers, ou les appels audio vidéo. Ou encore le carbon copy, l'historique côté serveur. Pour tout ça, c'est au bon vouloir de celui qui administre le serveur. Puis l'utilisateur doit vérifier si son client supporte ça aussi. C'est déjà trop compliqué (ou plutôt pénible) pour un technophile. C'est pas unique à XMPP, c'est simplement un fait. Sur un réseau fédéré, on est forcé de se limiter au dénominateur commun, c'est extraordinairement difficile d'évoluer ensuite. Le problème d'XMPP par contre (selon moi) est que ce dénominateur commun est trop limité. Tout est défini dans des XEP, et l'on ne peut pas garantir qu'elles seront disponibles sur toute la chaîne.

tu as le choix entre des dizaines/centaines de clients, mais ils fonctionnent tous ensemble.

Qui fonctionnent partiellement et/ou peut être ensemble. C'est bien là le problème. Dans le cas de la messagerie instantanée (certes pas l'unique but de XMPP, mais un des principaux), selon ton client, ton serveur, et idem pour l'autre côté, les chances que les bonnes XEP soient implémentées, activées, et correctement configurées sont si faibles, que dans la pratique, on ne peut pas vraiment compter dessus. À moins de contrôler l'ensemble de la chaîne (donc, hors fédération), on est donc obligé de retomber sur les fonctions minimales, celles définies dans le core du protocole, et quelques XEP suffisamment anciennes et simples pour être disponibles à peu près partout.

Une des utilisations les plus originales que j'ai vu c'était le projet Archipel. Un orchestrateur de VM, dans lequel XMPP est utilisé pour tout. Malheureusement, le projet semble au point mort maintenant

En effet. J'utilisais un COPR à l'époque, j'avais même pas remarqué que j'avais basculé sur la version fournie par RPMFusion. C'est donc une bonne nouvelle. J'ai plus qu'à attendre la prochaine version qui devrait intégrer le mode shuffle (indispensable pour moi)

Moi je l'utilise, il me convient très bien.

Ok, ça répond à ma question. Je me demandais si la nouvelle version pouvait convenir à certains :-)

Mouais. VLC fait tout, c'est bien son défaut. Moi je veux juste un lecteur multimédia simple, avec playlist. Gnome MPV semble pas mal, mais pas encore dans les dépôts de Fedora (je sais pas pour les autres distrib)

Dommage, il ne manque plus qu'un lecteur vidéos à cet environnement. Il y avait Totem qui était pas trop mal, avant qu'il ne soit saboté il y a quelques versions (entre autre, retrait de la playlist…). Et depuis ce sabotage, il ne bouge plus. Il y en a qui s'en servent de Gnome Vidéo maintenant ?

C'est de la bonne !

Dans RetroShare et Tox ton identifiant est une clés publique PGP.

Voilà une des raisons pour lesquelles ces solutions ne pourront que rester confidentielles, limitées à quelques geeks.

Donc pour faire tourner XMPP il te faut une machine qui tourne h24 *1 + serveur xmpp, turn et autre joyeuseté + 1 nom de domaine.

Il faut bien un nom de domaine (encore qu'un dyndns ou équivalent peut tout à fait fonctionner), mais ni turn, ni h24 nécessaire. Tu peux très bien, si tu veux, démarrer ton serveur XMPP quand tu as envie de discuter avec ton pote. Bref, pas de différence avec RetroShare ou Tox à ce niveau

Il y a au moins un cas d'usage: X2Go, qui ne fonctionne pas avec Gnome 3 (classic ou standard). C'est le seul cas où j'utilise MATE. À contre cœur parce que je préfère largement Gnome 3.

Entièrement d'accord, jamais compris pourquoi le terme privateur est apparu. Propriétaire convient très bien. Je trouve même que ça dessert la cause, privateur fait perdre toute crédibilité