déjà merci pour ce journal, il est intéressant et j'aimerais aussi voir d'éventuelles suites.
Juste une petite remarque, il y a une tendance à penser que quelque chose de « distribué » (dans le sens utilisé ici) est nécessairement mieux que quelque chose de « décentralisé » (dans le sens avec un serveur intermédiaire). C'est à mon sens une erreur.
Un système « distribué » comme compris ici (que j'appelle plutôt « entièrement pair à pair » pour éviter les confusions), ne se passe pas de serveur, c'est juste que le serveur est placé au niveau du client, ou en d'autres terme c'est le client qui fait le boulot.
C'est intéressant sur plusieurs points (on devrait pouvoir couper une partie du réseau sans grosse conséquence sur les autres par exemple), et c'est clairement très très intéressant sur le plan technique/recherche.
Mais placer le serveur au niveau du client a ses conséquences : le client devant faire le boulot, c'est autant en plus sur la bande passante et la charge processeur, ce qui est particulièrement gênant pour le monde mobile où ça va en plus influer sur la batterie.
Il y a d'autres problèmes : l'accessibilité des données par exemple ; et d'ailleurs on le voit dans ton journal, dans le paragraphe « Pseudo synchronisation asynchrone » :
Une solution simple consiste à partager le répertoire également avec une machine C qui reste allumée entre temps
En gros tu mets un serveur en place...
Autre soucis : l'identifiant. Il n'y a pas aujourd'hui — à ma connaissance — de solution simple et facile pour identifier une machine sans serveurs intermédiaires.
Avec Syncthing: pas de nom d'utilisateur, pas de mot de passe, tout passe par des clés, des hashs, et des QR codes très pratiques.
des hashs et des QR codes, je trouve pas ça très pratique moi, les QR codes sont plutôt des cache-misères.
Le choix d'un serveur intermédiaire est généralement voulu, et en simplifiant, il suffirait de mettre serveur et client sur la même machine pour en faire ce que tu appelles « distribué » (et de trouver un substitut au DNS avec probablement à la clef des hashs imbitables et autres QR codes).
J'avais d'ailleurs fait un billet sur mon blog à ce sujet, lisible ici.
Enfin bref, du 100% pair à pair c'est intéressant, mais c'est pas forcément mieux qu'un serveur intermédiaire, à mon sens du moins.
Si ton but principal c'est la simplification de la configuration, c'est peut-être de ce côté qu'il faut regarder (un serveur intermédiaire ne devrait pas être synonyme d'un truc relou à installer).
Ceci-dit, je vais lire tes prochains articles avec intérêt :)
# Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 9. Dernière modification le 24 mars 2016 à 11:37.
Salut,
déjà merci pour ce journal, il est intéressant et j'aimerais aussi voir d'éventuelles suites.
Juste une petite remarque, il y a une tendance à penser que quelque chose de « distribué » (dans le sens utilisé ici) est nécessairement mieux que quelque chose de « décentralisé » (dans le sens avec un serveur intermédiaire). C'est à mon sens une erreur.
Un système « distribué » comme compris ici (que j'appelle plutôt « entièrement pair à pair » pour éviter les confusions), ne se passe pas de serveur, c'est juste que le serveur est placé au niveau du client, ou en d'autres terme c'est le client qui fait le boulot.
C'est intéressant sur plusieurs points (on devrait pouvoir couper une partie du réseau sans grosse conséquence sur les autres par exemple), et c'est clairement très très intéressant sur le plan technique/recherche.
Mais placer le serveur au niveau du client a ses conséquences : le client devant faire le boulot, c'est autant en plus sur la bande passante et la charge processeur, ce qui est particulièrement gênant pour le monde mobile où ça va en plus influer sur la batterie.
Il y a d'autres problèmes : l'accessibilité des données par exemple ; et d'ailleurs on le voit dans ton journal, dans le paragraphe « Pseudo synchronisation asynchrone » :
En gros tu mets un serveur en place...
Autre soucis : l'identifiant. Il n'y a pas aujourd'hui — à ma connaissance — de solution simple et facile pour identifier une machine sans serveurs intermédiaires.
des hashs et des QR codes, je trouve pas ça très pratique moi, les QR codes sont plutôt des cache-misères.
Le choix d'un serveur intermédiaire est généralement voulu, et en simplifiant, il suffirait de mettre serveur et client sur la même machine pour en faire ce que tu appelles « distribué » (et de trouver un substitut au DNS avec probablement à la clef des hashs imbitables et autres QR codes).
J'avais d'ailleurs fait un billet sur mon blog à ce sujet, lisible ici.
Enfin bref, du 100% pair à pair c'est intéressant, mais c'est pas forcément mieux qu'un serveur intermédiaire, à mon sens du moins.
Si ton but principal c'est la simplification de la configuration, c'est peut-être de ce côté qu'il faut regarder (un serveur intermédiaire ne devrait pas être synonyme d'un truc relou à installer).
Ceci-dit, je vais lire tes prochains articles avec intérêt :)