SaintGermain a écrit 544 commentaires

Je trouve que c'est quand même un point fondamental (pourquoi Matrix n'est par parti de XMPP) que je suis personnellement incapable d'expliquer correctement.
J'avoue que je me sentais un peu incompétent à écrire le passage sur XMPP donc j'ai tout simplement recopié ce qui était écrit dans leur FAQ. Mais cela me semblait important d'écrire quelque chose sur XMPP plutôt que rien. J'aurais peut-être dû contacter un dev de XMPP pour m'aider, désolé.

Cependant même après ton message, il me semble que la différence fondamentale est bien que Matrix intègre (kitchen sink…) à la base beaucoup plus que XMPP ? Et du coup est clairement moins flexible au niveau des extensions ?
Cela me rappelle un peu le débat micro-noyau et noyau monolithique.

En tout cas j'ai jeté un oeil vite fait, et rien ne semble avoir bougé sur leur FAQ au niveau de XMPP depuis un moment. Un point que je ne comprends pas très bien, c'est pourquoi tu te refuses à proposer un changement (pull request) pour leur FAQ ?
C'est je trouve assez constructif de leur part, d'essayer d'expliquer les différences avec XMPP. Et c'est risqué car du coup ils s'exposent aux critiques si ce n'est pas parfait (seuls ceux qui ne font rien ne font jamais d'erreurs).

De mon point de vue, je vois deux approches : ou bien du côté XMPP vous faites aussi une FAQ pour expliquer les différences avec Matrix (et là vous allez voir les fanboys de Matrix rappliquer avec leurs critiques) ou bien vous mettez à jour leur FAQ pour corriger ce qui est faux.

J'aurais bien proposé mon aide pour mettre à jour la FAQ, mais cela me semble vraiment très pointu techniquement.

Merci, je voyais plutôt cela comme icône (celui en haut à gauche), mais cela va aussi comme cela !

Bonne remarque. Est-ce qu'un modérateur pourrait remplacer le logo par celui-ci (provenant de matrix.org) :

Voici mon htop (Atom N2800 avec 4 Go de RAM):

Mais bon effectivement je ne l'utilise pas beaucoup, on est juste 3 utilisateurs pour l'instant. Cela m'étonne quand même que cela mette à genoux ton Kimsufi.

Tu peux faire toi aussi un htop et me dire dans quel contexte tu l'utilises (combien d'utilisateurs, quel genre de salon) ?

Sinon pour Dendrite, je crois avoir lu qu'ils ont constaté des gains de performance (à configuration égale je suppose) de 300x. Donc oui cela devrait améliorer les choses pour les petites machines.

Oui tu as tout à fait raison, si un modo pouvait corriger…

Merci ! ;-)

Mais j'ai repris quand même pas mal d'informations sur les sites de Matrix et Riot, donc le mérite revient aussi et surtout à eux.
Donc si l'article vous plaît, essayez de leur verser une petite obole.

Un truc que j'ai oublié de préciser et qui me semble très important : si vous vous engagez à leur verser de l'argent (via Patreon ou Liberapay), vous aurez accès à un support privilégié (entre autres choses).

C'est personnellement la première fois que je vois cela dans le logiciel libre (donations récurrentes + support privilégié) et je trouve l'idée à première vue assez bonne.

Bizarre j'ai aussi un tout petit kimsufi et cela tourne sans problème je n'ai pas tenté de joindre Matrix HQ cependant, je ne suis pas fou !).
Est-ce que tu as bien réglé le paramètre SYNAPSE_CACHE_FACTOR ?

En tout cas, le nouveau serveur Dendrite semble beaucoup plus efficace. C'est une des priorités importantes du projet (ils en parlent encore dans leur dernier post sur leur blog)

Est-ce une coïncidence que la dépêche soit publiée presque un vendredi ?
Je m'attends à ce que cela trolle bien fort en tout cas. ;-)

Oui en effet il peut adapter la compression, mais est-ce que tu constates une nette dégradation de la qualité de l'image par rapport à ceux qui ont une bonne connexion ?

Peut-être aussi que appear.in a changé quelque chose dans son protocole depuis, on ne peut pas savoir…

Si appear.in fonctionne comme indiqué dans mon lien plus haut, je ne vois pas très bien comment cela peut bien fonctionner sur des liaisons « moyennes » dès qu'il y a plus de 2-3 participants.
Il semblerait que chaque participant doive envoyer un flux vidéo de 1.2 Mbps à chaque autre participant, donc cela devrait vite dépasser la capacité d'upload pour peu que l'on n'ait pas la fibre (ou un gros upload).

Voici un comparatif des technologies derrières pour comprendre les avantages/inconvénients de appear.in (mesh) et Jitsi (SFU) :
https://testrtc.com/different-multiparty-video-conferencing/

Encore une fois Framatalk c'est Jitsi qui est derrière. Si on utilise toujours uniquement le nom du logiciel/service/framework qui encapsule la technologie, c'est beaucoup plus difficile de trouver de l'information pertinente à son sujet.

Par exemple ici :
https://www.reddit.com/r/StallmanWasRight/comments/5jxe6p/encrypted_messengers_why_riot_and_not_signal_is/dbkmup1/

It has had its share of problems early on as the early design was kind of overeager. The dev community also suffered nasty takeover/schism/drama (gsoc fund embezzlement, domain held hostage, the usual) a while ago.

Ou encore là :
https://www.reddit.com/r/privacytoolsIO/comments/4uk89e/ring_vs_signal_vs_vector_vs_wire_vs_jitsi_vs/d5qqkmk/

So, there's that. Trying to change/improve tox.chat and people behind it is a waste of time, I know from experience.
It's quite sad how tox.chat refuses to point to qTox osx binaries, or correct instructions for Linux repos, even going as far as lying that there's no support for $distros. Some of the reasons why own qTox website was needed.

Et ici :
https://www.reddit.com/r/privacytoolsIO/comments/4uk89e/ring_vs_signal_vs_vector_vs_wire_vs_jitsi_vs/d5s5p7u/

People will tell you different on reddit and 4chan, but if you look at official statistics of tox, decreasing number of contributors to toxcore, µtox and qtox, stagnation of antox https://toxstats.com/ number of design problems that are impossible to solve with such (good and secure!) architecture… you will see that tox won't matter soon.

Nextcloud video calls c'est Spreed WebRTC derrière ?
Tout comme Framatalk c'est Jitsi Meet derrière ?

Je pense qu'il vaut mieux parler du logiciel directement plutôt que du projet/framework qui l'encapsule. C'est plus facile ensuite de trouver des retours d'expérience.

Google Duo ne fonctionne malheureusement que sur Android et iOS.
Il semblerait qu'il ne soit aussi pas possible de faire de la voix seulement ? Si la bande passante n'est pas bonne, je suppose que l'on ne peut rien faire donc ?

J'en avais entendu parler, mais pour moi ce n'était pas encore utilisable au quotidien.
Est-ce que tu peux au moins confirmer que les appels vidéos 1:1 fonctionnent bien entre toutes les plate-formes et que la qualité est correcte ?

Quelques critiques que j'avais trouvées :
https://www.reddit.com/r/privacytoolsIO/comments/4uk89e/ring_vs_signal_vs_vector_vs_wire_vs_jitsi_vs/
https://www.reddit.com/r/privacytoolsIO/comments/58u5my/little_help_needed_with_setting_up_jitsitoxring/

Ring: works reasonably well on the desktop and on mobile (Android, no iOS client); the desktop client on Linux is UI-wise still very rough (e.g. no real address book). For me, the UI is too annoying to use it for simple messaging. As it relies on a DHT, the mobile client can be used only on Wi-Fi, making it unsuitable for mobile messaging on the go. I have never tried group chat or group calls but would assume that it is inferior to Tox with regard to these advanced features. You can't share one user id across different devices. Advantages include that it is developed by a company and thus has a somewhat sustainable future (one might hope). It also includes a traditional SIP client that you can use to call regular phone numbers.

As for Ring, well… I couldn't get it to even start any chat conversation let alone audio or video call. That's it really. I double checked that I exchanged correct IDs with the other party, but neither side could receive chat messages or see pending calls.

I also tried Ring (which I was unable to get working correctly during my tests)

La voix/vidéo dans les conférences ne marche aussi que si son propre serveur est fédéré :
https://github.com/vector-im/riot-web/issues/2546#issuecomment-258650141
Pour être honnête au niveau vidéo c'était complètement inutilisable pour moi (3 appareils sur mon réseau local avec une bonne connexion vers le serveur Matrix).

Mais par contre pour les appels 1:1 la qualité est vraiment très bonne !
Et je n'ai pas encore trop essayé le chiffrement des communications (c'est secondaire pour moi) mais cela avait l'air de marcher.

Bravo à l'équipe Riot et Matrix-Synapse ! Le résultat actuel est déjà assez impressionnant. Le gros point positif est pour moi la facilité d'installation du serveur et des clients. C'est assez facile de se décourager en installant/configurant, mais là je n'ai même pas eu le temps de me décourager.

Un petit tutoriel d'installation pour ceux que cela intéresse :
https://blog.cryptoaustralia.org.au/2017/03/21/run-your-end-to-end-encrypted-chat-server-matrix-riot/

Framatalk c'est Jitsi Meet.

J'avais bien remarqué Tox, mais de ce que j'ai pu en lire, il y a un drame qui se joue en arrière-plan entre les développeurs. Cela ne m'a rassuré sur son avenir.

Attention à ton lien pour vroom :

WARNING: I unfortunately lost the original vroom.im domain name. The cybersquatter who owns it now has put a fake VROOM nstance on http://vroom.im/. Please do not go here anymore, and use the new https://vroom.fws.fr address instead.

J'avais testé vroom vite fait et cela n'a pas bien marché (catastrophiquement lent pour rafraîchir, même entre deux clients sur mon propre réseau).

Dans ce qui me manque par rapport à Riot: le partage de fenêtre/écran, et le suivi de la personne qui parle.

Tu veux dire ce qui te manque par rapport à Jitsi ?

Le partage de fenêtre/écran sous Riot cela marche en shift-clickant sur l'appel vidéo :
https://github.com/vector-im/riot-web/issues/3025#issuecomment-275418688
Ce n'est pas du tout documenté car je crois que c'est encore à l'état de brouillon, mais cela a très bien marché pour moi.

En gros je fais un snapshot de mon /home qui contient entre autres tous les emails.

intègre la protection contre la corruption de données (via checksum effectué par l'outil même

Quand ton disque fou aura corrompu la copie courante et le backup local, tu seras heureux que bup te dise "ouh la le checksum est pas bon là !" :-)

Ben justement si c'est le but. Si la donnée (et le backup local) est corrompu, je veux le savoir afin de ne pas écraser le backup distant. On peut faire cela avec un Btrfs RAID1 ou avec un utilitaire de sauvegarde intégrant une protection contre la corruption de données.
Si le dépôt local de bup est corrompu, bup va me dire "ouh la le checksum est pas bon là !" et c'est exactement ce que je souhaite (et que peu d'utilitaires de sauvegarde proposent).

Je pense qu'on commence à tourner en rond donc je remets l'appel à l'armistice que j'avais déjà mis plus haut : dans ce fil j'ai l'impression qu'on est à peu près tous d'accord, même tes contradicteurs d'autres fils, à quelques détails près, et que ça repose principalement sur une question de formulation et de vocabulaire.

Oui merci. J'ai bien compris que lorsque je parlerai de sauvegarde, il faut faire très très attention aux termes non techniques. À la limite pour éviter le bikeshedding, il vaut mieux éviter de vulgariser et entrer directement dans les détails techniques.

J'aurais fait un journal pour parler de Btrfs snapshot/send/receive et un journal pour parler de Btrfs RAID1 pour la protection contre les données corrompues, personne ne serait montée sur ses grands chevaux. Comme c'est deux notions complémentaires, cela ne m'a pas semblé illogique de combiner les deux dans mon journal. La grosse erreur ayant été d'oser parler de « sauvegarde locale » au lieu de simplement « snapshot » ou de « cache de sauvegarde ».

Enfin en conclusion grâce aux questions sur bup, j'ai trouvé pas mal de gens qui font comme moi (bup avec dépôt local + dépôt distant pour gérer les sauvegardes) donc cela me rassure sur mon approche.

bup te cause quand même de comment l'envoyer à distance, ta "sauvegarde locale" ;-))

Je ne suis pas spécialiste de bup, mais il semble quand même que son fonctionnement standard c'est de faire une sauvegarde locale, de l'envoyer ensuite par rsync vers une sauvegarde distante et ensuite d'utiliser la sauvegarde locale. Par exemple ce n'est pas possible avec bup de faire un restore depuis la sauvegarde distante (ou bien il faut faire le restore depuis la sauvegarde locale ou bien se connecter sur la machine distante pour « opérer en local » pour peu que l'on ait bien tout installé sur la machine distante).
Cela ressemble quand même très très fortement à ce que je suis en train de faire. ;-)

Sans doute parce qu'en général la sauvegarde s'occupe d'avoir une copie des données […] et est considérée suffisamment orthogonale pour ne pas parler de protéger des aléas de la copie courante […]

C'est un peu à la frontière je te l'accorde, mais certains outils de sauvegarde comme bup (encore lui !) intègre la protection contre la corruption de données (via checksum effectué par l'outil même).

Le fait que l'outil ait un "sas" local ne valide pas pour moi la pertinence d'une sauvegarde locale contre autre chose qu'un bête rm (et avant que tu remettes sur le tapis à toutes les sauces les corruptions de bits, si ton disque commence à chier dans la colle sur les fichiers courants, il peut tout aussi bien chier dans la colle sur les fichiers de la sauvegarde locale, et si les deux sont corrompus… d'où la problématique orthogonale mais nécessaire aussi d'outils contre ça).

Là j'ai du mal à te suivre. Dans mon approche, les fichiers courants et les fichiers de la sauvegarde locale sont exactement les mêmes (reflink). Donc si l'un est corrompu, l'autre l'est automatiquement aussi. Mais j'ai justement un RAID1 pour empêcher que la donnée originale soit corrompue (et donc automatiquement la donnée localement sauvegardée). Donc sauf à considérer une erreur dans la carte mère ou le FS/Kernel, on peut dire que les données ne peuvent pas être corrompue dans mon approche.

Et pour la protection contre le bête rm, il y a un admin plus haut qui donne des statistiques sur l'utilisation de ses sauvegardes. En très très grand majorité, c'est suite à un bête rm qu'il utilise les sauvegardes. Donc cela ne me semble pas idiot d'optimiser mon approche pour me protéger contre le rm et de « négliger » un peu la protection contre les autres risques (même s'ils sont couverts en fin de semaine lors de la sauvegarde distante).

Merci pour la discussion posée ! C'est quand même sacrément plus agréable.

Attention on te l'a dit plus haut, tu fais une erreur qui te conforte à tort dans ta comparaison : bup n'utilise pas git, il utilise le format de stockage de git mais d'une manière différente (c'est expliqué dans la doc de bup).

Pas vraiment d'accord, hormis pour les métadatas, bup est un git optimisé (nombre + taille des fichiers).
J'ai parcouru la doc de bup et j'ai mis les extraits plus haut (personne ne m'a répondu d'ailleurs).

Et il y a quand même cela dans la doc :

The purpose of bup is essentially to let you "replicate" data between two main data structures:
1. Your computer's filesystem;
2. A bup repository. (Yes, we know, that part also resides in your filesystem. […])
Essentially, copying data from the filesystem to your repository is called "backing stuff up,".

Oui donc en gros tout le monde est d'accord : tu fais une bonne sauvegarde, distante, une fois par semaine. Et en local t'as une assurance contre les rm intempestifs et le claquage d'un disque :-)

Et surtout la corruption de données. Ce « détail » n'est quasiment jamais pris en compte dans les solutions ou architecture de sauvegarde. Je ne sais pas si j'ai la poisse, mais rien que l'année dernière, cela m'est arrivé deux fois.

Et justement, ce que je voulais dire dans mon message initial, c'est que l'analogie est douteuse car les buts sont vraiment différents (dans l'un, collaborer dans le temps (donc y compris avec le soi de dans un mois) sur des fichiers textes, dans l'autre se prémunir d'accidents).

Bien entendu on ne peut pas faire l'amalgame complet, ce sont quand même deux thèmes distincts. Mais quand je vois un outil comme bup qui est en gros git utilisé comme outil de sauvegarde (cf. ma réponse à steph1978 pour prouver que bup c'est grosso modo git), je me dis que les deux thèmes doivent partager beaucoup de choses en commun.

Bon là c'est moi qui ai été trop succinct, par "distant" je voulais vraiment regrouper tout ce qui ne repose pas sur la techno de ton ordi (CoW, RAID…) ni de son matériel (même disque), donc je comptais presque "un disque USB" dans distant. L'idée simplifiée étant toujours "si tu fais confiance au CoW c'est chaud".

C'est dommage car on est passé à côté de la discussion sur la confiance au CoW dans toutes ses discussions.

Déjà pour mettre les choses au clair, le snapshot (CoW) est envoyé toutes les semaines sur le serveur distant. Donc à la fin de la semaine, j'ai quand même une copie physique distante.

Donc c'est pendant cette semaine où le snapshot est uniquement présent sur mon disque local, que se joue vraiment le risque.

Étant donné ces deux solutions :

1. Deux disques durs en Btrfs RAID1, snapshot des données sur le même RAID1 et envoie par rsync des données à la fin de la semaine
2. Un disque contenant les données, copie physique (via cp/rsync) des données sur un disque externe USB et envoie par rsync des données du disque USB à la fin de la semaine

Mon idée est justement que la première solution est apparemment peut-être plus fiable que la deuxième.
La première solution a comme avantage que si la carte mère et le kernel/FS marchent bien, on est sûr que la donnée n'est pas corrompue, autrement on peut perdre une semaine de données en cas de défaut [1]
La deuxième solution a comme avantage que si la carte mère ou le kernel/FS déconne, on a pas perdu la semaine de données. Par contre au niveau des inconvénients :

1. Si le disque de données lâche, on a perdu les données n'ayant pas été sauvegardées sur le disque USB
2. Si le disque USB lâche, on a perdu les sauvegardes (donc l'historique et les données qui ne sont plus présentes sur le disque original)
3. S'il y a une corruption des données sur le disque original ou sur le disque USB, les données corrompues seront recopiées sur le disque USB et iront ensuite écraser les données sur le serveur distant

Donc l'analyse de risque que j'ai faite c'est que je n'ai jamais eu de problème ayant abouti à une perte de données utilisateur avec la carte mère et le kernel/FS. Par contre j'ai souvent eu des données corrompues (mauvais disque, mauvais câble).
Donc tout « naturellement » j'ai choisi la première solution. Je serais donc intéressé par les critiques sur mon raisonnement (et j'espère avoir été clair cette fois).

[1] Il y aussi le cas où un disque dur du RAID1 lâche et que le deuxième lâche aussi pendant la reconstruction du RAID1. Je ne sais pas à quel point c'est probable lorsque l'on a deux disques de marques différentes.