SaintGermain a écrit 544 commentaires

C'est pas pour faire le RH-fanboy mais j'ai un peu l'impression que dans toutes les conversations autour de ce journal, le problème commun est btrfs.

Euh c'est pas un peu normal dans un journal parlant de Btrfs que l'on parle surtout des problèmes rencontrés autour de Btrfs ? ;-)
Mais de tête quelques soucis que j'ai eus (qui n'ont rien à voir avec Btrfs) :

• n'avoir à entrer qu'une seule fois le mot de passe pour tous les disques, cela n'a pas été évident.
• avec du RAID, il faut se poser la question de mettre le chiffrement au dessus ou en dessous du FS, les performances ne sont pas les mêmes (chiffrer plusieurs fois la donnée vs chiffrer une seule fois).
• problème au démontage : https://github.com/systemd/systemd/issues/1620

Et sinon le chiffrement avec du RAID c'est clairement moins facile qu'avec un seul disque, ne serait-ce que parce que la plupart des tutoriaux/ressources sur le sujet abordent le cas le plus courant : un seul disque. Donc c'est plus difficile de trouver des infos/retours.

Faire proprement du RAID, ce n'est pas donné à tout le monde. Et faire proprement du chiffrement, ce n'est pas non plus très accessible. Alors faire proprement du RAID + chiffrement, je doute que ce soit facile et accessible pour tout le monde, d'où mon adjectif pas du tout scientifique de « sportif ».

Il me semble que la page sur la vie privée n'est plus trop à jour.
Tu as une case 'opt-out' pour la récolte des analytics dans les paramètres.

Sinon comme le code des applications mobiles est libre, tu peux aller regarder dans le code ce qui est réellement récolté en cas d'opt-in et en cas d'opt-out.

Si tu as un seul disque en ext4, le chiffrement ne pose pas de problèmes particuliers. À part le fait qu'en cas de soucis, c'est plus difficile de débrancher le disque et de le lire sur un autre ordinateur.

Avec du RAID en Btrfs, c'est quand même plus sportif mais pas impossible. Mais si cela se trouve, c'est ce qu'il fait, donc attendons sa réponse.

Pour l'anecdote, la plupart des gens à qui j'en parle me prennent pour un paranoïaque quand je dis que je chiffre mon NAS (pourtant leur iPhone est chiffré par défaut…). Il ne faut pas perdre de vue que les problèmes de vie privée, cela passe complètement au-dessus de la tête de la grande majorité des gens.

La probabilité de se faire cambrioler me semble quand même assez forte. Pour mon cas personnel, je connais vraiment beaucoup de gens à qui cela est arrivé.

En tout cas j'ai bien plus de gens ayant subi un cambriolage, que de gens ayant subi un crash disque brutal entraînant la perte de toutes les données (mais c'est sans doute que c'est un sujet moins populaire).

Si tu n'as pas de RAID, avec un système de fichier exotique comme Btrfs, c'est pourtant relativement simple de chiffrer.

À une époque, la compression finissait en deadlock sur des fichiers de quelques GiB si on modifiait des blocs au milieu du fichier.

Hormis les VMs, est-ce que tu as d'autres exemples de modifications de fichiers de ce type ?

Globalement dès que tu passes en utilisation intensive ça commence à piquer. Pour l'utiliser en backups sur de gros volumes, les hung tasks et le freeze sont pas si rares que ça.

Dans le cas d'une utilisation pro ou perso ?

Merci !

Ok tu fais donc à peu près comme moi et je vois que l'on à peu près les mêmes besoins.

D'après ce que je comprends, tu vas donc avoir aussi les mêmes problèmes avec ton approche :

• est-ce que ton NAS ne te sert que de support de sauvegarde ? Autrement il te faudra aussi sauvegarder les données qui ne sont que sur ton NAS (c'était la principale difficulté de mon journal).
• si tu chiffres tes disques externes, je suppose que tu chiffres aussi ton NAS (autrement quelqu'un volant ton NAS aurait accès à toutes les données de toutes tes machines) ? Si oui il y a pas mal de problèmes associés
• tu sauvegardes une partition Btrfs sur une partition NTFS, du coup si je comprends bien tu perds tout le bénéfice de la déduplication des données (2 snapshots incrémentaux seront sauvegardés comme 2 ensembles indépendants).
• tu fais énormément confiance à ton RAID1 si je comprends bien ? Si jamais il y a un problème qui n'est pas détecté/corrigé par ton RAID1, le problème sera recopié sur ton disque externe ?

Je vois d'autres soucis potentiels, mais j'aimerais d'abord confirmer les points que j'ai donnés.

Mais du coup je n'ai pas compris, tu fais des snapshots de ton NAS sur ton NAS, ou bien tu fais des snapshots de ton PC personnel et tu envoies ensuite les snapshots sur ton NAS ?

Je ne parle pas de la recopie des snapshots de ton NAS sur le disque dur externe, ça j'ai bien compris.

Ici on parle de base de données qui deviennent suffisamment grosses pour ralentir Btrfs significativement.
Les bases sqlite de quelques centaines de Mo, je ne pense pas que cela ralentisse Btrfs.

Tu as sans doute des cas particuliers de gens qui arrivent à avoir des dizaines de Go dans leur base de données sqlite avec Firefox, Tracker ou autres. Mais on parlait de 100% des utilisateurs de linux donc on ne prend pas en compte les cas particuliers

Je me sers des snapshots BTRFS pour faire des sauvegardes incrémentales […] sur mon NAS. Combiné avec […] et des sauvegardes offline mensuelles.

Ah j'ai peut-être mal interprété en effet. Est-ce qu'il fait des snapshots de son PC personnel et qu'il les envoient sur son NAS après (et cela devient alors des sauvegardes). Ou bien est-ce qu'il fait des snapshots de son NAS ?

L'article est chouette et bien écrit, cependant je trouve que cela peut porter préjudice à Btrfs en laissant penser que le système de fichier est mature et sans bogues.

Avec un système de fichier encore en développement comme Btrfs, il faut quand même faire très attention.
Le genre de commentaire que donne AP plus haut devrait être plus mis en avant pour donner un cadre dans lequel on peut utiliser Btrfs sans s'exposer à trop de problème.

En particulier quand tout va bien, c'est nickel. Mais dès que vous commencez à avoir des problèmes, réparer les choses avec Btrfs est tout sauf facile. Bien lire le wiki et surtout ne pas hésiter à aller sur la liste de diffusion de dev avant de faire des bêtises irréparable (oui oui aller sur liste de diffusion de dev).

Le cas d'utilisation actuel théorique est plutôt la fiabilité et la possibilité de valider l'état des fichiers (bitrot et tout ça, surtout quand on a de mauvais contrôleurs et disques), ou les snapshots.

Oui et notons que Btrfs en RAID1 permet de détecter et corriger le bitrot. Certaines personnes ici me juraient que ce n'était pas possible dans mon dernier journal.

Je trouve cela particulierement redhibitoire aujourd'hui. Parceque a vus de nez les BD et les VM sur une machine linux cela doit toucher … 100% des utilisateurs.

Il faudrait penser à ne pas exagérer. Il y a des gens (dont moi) qui utilisent linux sur leur machine personnelle et on a pas tous forcément besoin de grosse base de données ou de machines virtuelles.

Je tourne en RAID1 Btrfs aussi, et je n'ai eu aucun soucis particulier dans le cadre d'un usage domestique.

Notons cependant que le RAID 1 avec « N-way mirroring » (N > 2) n'est toujours pas possible avec Btrfs.
Du coup il faut faire très attention lorsque l'on remplace un disque dans son RAID1.

De plus (je peux retrouver les liens si quelqu'un est intéressé) mais lorsque un des deux disques du RAID1 est subitement mort, il faut faire très attention car on a juste une chance (i.e. un reboot) pour remplacer le disque. Autrement il faut patcher et recompiler le noyau car tout passe en read-only de manière définitive dès le deuxième reboot (sauf à utiliser le patch).

Je fais exactement pareil, mais quand j'ai décrit cette approche dans mon dernier journal :
https://linuxfr.org/users/saintgermain/journaux/gestion-de-versions-et-sauvegarde-de-donnees
Certains personnes ont hurlé à l'hérésie car ces snapshots ne sont pas considéré comme des sauvegardes.

J'essaye justement de me mettre à leur place (à XMPP et à Matrix).

L'équipe Matrix : on nous pose régulièrement la question de la différence avec XMPP, donc on fait une FAQ à ce sujet. La FAQ n'est pas bonne et les gens d'XMPP sont mécontents On corrige comme on peut et ils sont limite encore plus mécontents. Plutôt que d'itérer ainsi et de s'enfoncer encore plus, on leur demande de modifier eux-même pour être sûr que cela leur convienne.

L'équipe XMPP : un nouveau venu refuse de partir de notre technologie et donne de mauvaises raisons dans leur FAQ. On leur dit qu'ils se sont trompés et de corriger leur FAQ. Ils corrigent mais c'est limite encore pire qu'avant. On veut bien leur donner le bénéfice du doute (quoique) mais faut pas pousser, on va pas faire leur travail pour eux.

Donc si chacun campe sur ses positions et ne fait aucun effort, il ne se passera rien.

Effort que peut faire Matrix : retenter une nouvelle version de leur FAQ sans aide de XMPP, et risquer de mettre encore plus le feu aux poudres (ou bien retirer purement et simplement la FAQ, mais du coup il faudra sans cesse répondre aux commentaire sur XMPP à chaque présentation de Matrix).
Effort que peut faire XMPP : corriger un minimum la FAQ de Matrix et se taper un boulot que l'on trouve inutile, désagréable et ingrat.

Si l'un et l'autre refuse de faire l'effort en premier, au final on fait quoi ? Rien ? Et du coup on aura toujours des gens mécontents, intervenant sur les présentations de Matrix et XMPP ? Peut-être qu'il faut juste se contenter de cela.

Sinon on peut aussi tenter la médiation, réunir tout le monde à la même table autour d'une bonne bière limonade et se rendre compte que tout le monde travaille dans le même sens. Mais c'est sans doute naïf et utopique.

L'e-mail façon GMAIL est clairement centralisé, l'e-mail façon RetroShare est décentralisé.

Pardon ? Si Google s'arrête demain, on ne peut plus s'envoyer d'email du tout ?

Appréhendes-tu se qu'est la décentralisation?

Je pense, et toi tu fais la différence entre centralisé, décentralisé et distribué ?

Où se trouve le principe de l'email dans la figure ci-dessous ?

C'est surtout que je n'avais pas compris (vu que tu ne l'avais pas explicitement dit) que la comparaison devait être faite à 100% par l'équipe Matrix sans l'aide des devs de XMPP.

Du coup je ne trouve pas ton approche constructive, parce que tout simplement je crois qu'elle ne marchera pas (on peut essayer hein, on a rien à perdre).
Si on demande juste à l'équipe Matrix de retirer l'entrée sur XMPP de la FAQ sans aucune autre argumentation que dire : « ce que vous avez écrit n'est pas juste, il vaut mieux le retirer », je suis pratiquement sûr que l'on va se faire envoyer balader.
Et comme c'est une question fréquente, bah ils vont la laisser dans la FAQ (dont c'est quand même le but de répondre aux questions fréquentes) parce que sinon à chaque fois ils auront des commentaires sur XMPP quand ils parleront de Matrix (comme c'est le cas ici d'ailleurs).

Alors que si on démonte proprement chaque point, au final Matrix aura le choix entre garder une entrée qui n'avance pas le schmilblick (vu que techniquement il n'y aura plus vraiment d'avantage à l'un ou à l'autre), refaire une entrée qui soit plus juste (i.e comme dit Goffi, que la différence est plus dans la politique/gouvernance) ou bien simplement retirer l'entrée.

Si un logiciel nécessite un serveur, alors il n'est pas décentralisé.

Tu considères que l'email est une technologie centralisée ?

Si les gens doivent installer leur propre serveur, on perd 99,9% de la population.

Pourquoi les gens doivent installer leur propre serveur ? Tu as installé ton serveur pour pouvoir avoir un email ?

Et utiliser le serveur d'une assoc ou d'un pote revient au final au même (voir pire) que directement passer par facebook.

Tu as utilisé le serveur d'une assoc ou d'un pote pour avoir un email ?

On va essayer d'être constructif avec toi et Goffi et de lancer une passerelle vers Matrix.

Voici donc ma traduction approximative de la FAQ de Matrix.org sur XMPP dans le wiki de LinuxFR :
https://linuxfr.org/wiki/xmpp_et_matrix

Donc maintenant pour toi et Goffi (ou tout autre dev de XMPP) qui sont présents sur LinuxFR, vous avez juste à corriger directement sur le wiki.
Cela devrait prendre à peine un peu plus de temps que répondre à mes commentaires.

Ensuite je me charge de traduire en anglais, de faire le pull request, le suivi et tout et tout.

Cela convient à tout le monde ?
Si quelque chose de positif sort de cette discussion, j'en serai ravi.

Tu ne veux pas aller faire un tour sur le salon LinuxFR pour éviter de polluer la discussion ici ?
Ce serait plus pratique.

Sinon tu as changé le paramètre SYNAPSE_CACHE_FACTOR ? Cela devrait améliorer les choses pour la RAM (pour peu que tu ne fréquentes pas des salons trop fréquentés).

Sinon au niveau de la charge CPU, c'est vraiment bizarre comparé à ce que j'ai. Pour moi tant que je ne fais rien, c'est vraiment presque à zéro tout le temps. Il faudrait enlever ton salon Yunohost pour voir si c'est le cas pour toi aussi (je ne peux malheureusement pas aller sur le salon Yunohost car j'essaye de garder mon serveur hors du réseau de fédération, tant que je n'ai pas fini mes tests).

Je t'accorde que ce n'est pas très constructif pour les développeurs (qui ont autre chose à faire).

Si on suit ta logique, il faudrait presque effacer l'entrée XMPP dans leur FAQ et faire comme si cela n'existait pas ?
Comme une FAQ est surtout là pour répondre aux questions fréquentes et que c'est l'une des premières questions que je me suis posé (et XMPP ?), à mon avis c'est pertinent de mettre la réponse en FAQ.

Ils s'y sont peut-être mal pris par le passé, mais ne peut-on pas leur donner le bénéfice du doute (ou bien pardonner) et tenter de ramener tout le monde à table ?

Si c'est perdu pour perdu et que les deux mondes sont irréconciliables, je peux proposer une entrée type « langue de bois » de la FAQ avec : « XMPP et Matrix poursuivent un objectif similaire mais avec une vision différente ou vice-versa, il est inutile de vouloir les comparer. »
Mais je trouve que l'on y perd.

Matrix souhaite un chemin similaire d'après ce que j'ai compris, mais est développé par des membres issus d'une même entreprise, avec un financement privé, une influence et une prise de décision très concentrée, et un but probablement lucratif.

Je crois que la création de la fondation (à but non lucratif) censée diriger Matrix sera faite dans la semaine (cf. leur blog).

Pour moi la différence se situe plutôt là que sur le plan technique.

Je suis incapable de dire si c'est juste ou pas mais là je pense que l'on avance sur un terrain miné.

Je pense aussi que je suis trop biaisé pour modifier ça moi même, et que c'est à eux de le faire de toute façon.

À partir du moment où tu soumets juste une demande de modification, ils sont libres de la modifier et de l'accepter par la suite. Mais au moins il y aura une trace (les commentaires du pull request) s'ils font quelque chose de pas fair play. Et ils t'encouragent en plus à proposer un pull request, donc il ne faut vraiment pas s'inquiéter de ton avis biaisé à mon avis.

Mais là de mon point de vue ils ont fait le premier pas officiel (même si mal fait) en tentant d'expliquer les différences. Et comme cela nécessite un effort commun pour le faire (XMPP + Matrix), ce serait chouette si quelqu'un de XMPP pouvait faire le second pas officiellement (via pull request plutôt qu'un message dans un blog).

Ce que je reproche c'est la manière dont ça a été fait, et dans la FAQ les réponses sont mises, mais toujours avec une formulation qui fait douter.

Peut-être qu'ils ont tout simplement pas envie de ré-éditer encore une fois leur FAQ et d'être encore sous le feu des critiques ? Plutôt que d'itérer jusqu'à ce qu'ils écrivent quelque chose qui convienne aux devs de XMPP, ils attendent peut-être que les devs leur disent directement ce qu'ils doivent écrire (via pull request…).

Et effectivement répondre aux commentaires sur le sujet prend à mon avis est moins efficace que de faire le pull request.
J'attends avec impatience pour pouvoir enfin bien comprendre les différences avec XMPP ! ;-)

Bref: je pense qu'un client comme Riot avec les mêmes fonctionnalités et multiplateforme basé sur XMPP plutôt que Matrix aurait eu tout autant de succès.

Ça on ne le saura malheureusement jamais. C'est quand même très regrettable.

Mais je ne militerai pas pour Matrix tant que le problème de l'accès aux gros salons par des petits serveurs ne fera pas partie des priorités.

Je sais que cela parle beaucoup de Dendrite, et que la sortie ne devrait pas trop tarder. À voir si cela résout ton problème.
Par contre tu as vu mon htop sur mon kimsufi ? Synapse n'est vraiment pas gourmand chez moi…

Excellent exemple effectivement, merci.

Ah ! Merci pour l'exemple !

Bien que Matrix semble avoir près de deux fois plus d'utilisateurs que Mastodon, je ne suis pas sûr que l'on peut dire que Matrix ait pour l'instant « réussi » (après la notion de réussite est toute relative).

Une question cependant : pour vendre quelque chose, est-ce qu'un slogan/discours qui se place en opposition est une bonne idée ?