Rakoshare est un logiciel, en Go, sous licence MIT, de synchronisation de dossiers entre plusieurs machines. Il se veut simple d'installation et d'utilisation par le plus grand nombre. Fonctionnellement, il est très largement basé sur Bittorrent Sync, un logiciel équivalent mais non-libre.
Sommaire
Rakoshare est un projet sur lequel je travaille depuis l'annonce de Bittorrent Sync, et après avoir vu que depuis tout ce temps il n'y a même pas une annonce de l'ouverture de son code source.
Le but de cette application est de rester extrêmement simple, tant à l'installation qu'à l'utilisation, parce que ce sont là des critères essentiels à l'adoption d'un logiciel. L'une des conséquences est ainsi qu'il n'y a pas besoin d'installer un serveur central; n'importe quelle machine compatible peut se joindre au partage.
Installation
Le binaire en question est prévu, mais pour le moment il vous faudra le compiler par vous-même. Les instructions sont sur la page du projet, il s'agit tout simplement d'une application Go standard.
Utilisation
L'utilisation se résume à choisir un dossier que l'on souhaite partager, créer un id aléatoire (pour être sûr qu'il ne soit pas déjà choisi), et lancer l'application en liant les deux:
$ rakoshare -fileDir ~/myDir -id <myId> -useLPD=true -useDHT=true
La même commande pourra être lancée sur chaque ordinateur qui doit recevoir une copie du dossier. Notez que l'emplacement du dossier ne doit pas nécessairement être le même sur toutes les machines.
Les dessous
Comme les plus attentifs auront pu le remarquer, Rakoshare ré-utilise le protocole bittorrent qui se trouve être un excellent protocole de transport de données. Rakoshare est principalement une glue par dessus celui-ci pour permettre un plus grand dynamisme, notamment sur la manière d'informer les pairs d'un changement dans le dossier et propager ce changement. L’intérêt principal est que l'identifiant est la seule information qui a besoin d'être partagée avec les autres participants: une suite de 40 caractères est suffisante pour mettre d'accord un nombre potentiellement infini de machines
Rakoshare s'inspire également de Couchdb, qui a des idées réellement intéressantes pour la gestion des versions que je réutiliserai. D'autres technologies, comme du multiplexing de connexions, du chiffrement et une gestion des autorisations sont prévues pour les versions à venir.
Rakoshare n'est pas parti de zéro, je suis parti de Taipei-Torrent, un client bittorrent écrit en Go. Le choix de ce langage ne s'est d'ailleurs pas totalement fait au hasard : bien sûr, j'ai commencé à m'y intéresser quand on a commencé à parler de lui, et mes premières impressions ont été celles que tout le monde a à peu près eues: une sémantique extrêmement simple (si vous savez déjà programmer, vous n'apprendrez rien de spécialement neuf) mais suffisamment puissantes pour construire des applications performantes et fiables très rapidement. En plus de ça, les binaires créés sont all-inclusive, c'est à dire qu'ils contiennent absolument tout ce qui est nécessaire; il n'y a plus de problèmes de déploiements. Enfin, la gestion de la concurrence en fait un langage tout à fait adapté pour tout logiciel qui reçoit des informations de l'extérieur à des moments indéfinis, comme par exemple un serveur.
Limitations
Rakoshare en est à sa version Make It Work: ça marche pour un dossier seulement (impossible de synchroniser plusieurs dossiers en même temps), ça passe en clair, il y a quelques instabilités, c'est verbeux et c'est en ligne de commande, il y aura certainement des problèmes si vous êtes derrière un NAT/pare-feu… mais ça marche. Je pense que ce logiciel peut servir à beaucoup de monde, donc j'ai décidé de l'annoncer pour attendre les retours des moules les plus aventureuses.
Rakoshare se limitera fortement à la synchronisation de dossiers. J'estime que ce cas d'utilisation est suffisant pour remplir la majorité des besoins (puisque tout est potentiellement fichier, et à peu près n'importe quel utilisateur comprend les principes de base du système de fichier).
Pourquoi ne pas avoir choisi…
rsync ?
rsync est le vénérable outil de transfert de dossiers, initialement connu pour son efficacité dans le protocole de transport lui-même (rsync considère à juste titre que les échanges réseau sont la partie la plus couteuse d'un échange de données, et se débrouille pour minimiser la quantité d'information à faire transiter) mais qui a su s'imposer comme le standard du transfert ad-hoc par son incroyable quantité d'options.
Malheureusement, rsync est un outil assez « bas-niveau », dans la mesure où son invocation reste relativement manuelle, et il n'est fait que pour synchroniser 2 machines entre elles.
unison ?
Unison est écrit en OCaml, un langage qui m'intéressait également, en tout cas théoriquement. Par rapport à rsync, il a l'avantage de gérer les synchronisations dans les deux sens ; malheureusement il est également fait pour les échanges entre 2 machines.
owncloud/seafile ?
L'un des prérequis que je voulais était de ne pas avoir à installer de serveur, pour garder une simplicité maximale. Mon but est bien que les gens qui utilisent Bittorrent Sync (voire Dropbox) utilisent Rakoshare; il ne faut pas passer par une étape aussi limitante.
camlistore ?
Camlistore est un projet de « dépôt » personnel d'un peu tout et n'importe quoi; lâchez-y vos photos et votre musique, et un système d'indexation vous permettra de vous y retrouver plus facilement dans votre masse d'information. Je pense que Camlistore est réellement intéressant pour ceux qui produisent/reçoivent beaucoup d'informations et souhaitent en garder une trace dans un lieu sûr; malheureusement la procédure d'installation n'est pas encore aussi simple, et dans l'état, vous devrez dupliquer vos informations entre votre système de fichiers et Camlistore, les garder en synchronisation…
clearskies ou syncthing ?
Ces deux projets semblent être les alternatives libre les plus connues à Bittorrent Sync; l'une est en Go et introduit une notion inutile (à mon avis) de nœuds en plus d'un nouveau protocole, qui fait (encore à mon avis) l'erreur d'être trop orienté fichier, au lieu d'avoir une vision globale du dossier, comme le fait git avec succès, et l'autre est en C++, que je ne connais pas assez pour pouvoir y contribuer. Oh et il a également son propre protocole.
Les autres ?
Il doit exister encore des dizaines d'alternatives que je n'ai pas citées, mais aucune d'elles n'a su me convaincre dans la simplicité d'installation et d'utilisation. Peut-être fais-je une erreur, l'avenir nous le dira.
L'avenir
Comme dit précédemment, il y a un minimum de points à implémenter avant de pouvoir prétendre avoir un remplacement à Bittorrent Sync, mais je compte justement garder les choses simples (le protocole, basé sur Bittorrent, a peu de chances d'évoluer même si c'est techniquement possible) pour que la communauté de développeurs puisse venir renforcer la bête. Dans un avenir lointain, il sera certainement possible de carrément remplacer Dropbox ou encore réinventer le web… mais ne brusquons pas les choses !
En attendant, vous pouvez jouer avec; n'hésitez pas à remonter les problèmes sur le tracker et à venir discuter sur la liste de diffusion (rakoshare servi-par librelist.com).
Note: ce document est placé sous licence CC0
Aller plus loin
- Page du projet rakoshare sur GitHub (1104 clics)
- Bittorrent Sync (176 clics)
# Bravo
Posté par JoeltheLion (site web personnel) . Évalué à 10.
Bravo, il y a vraiment quelque chose à faire dans ce secteur. Je pense que tu as très bien cerné les besoins et les enjeux.
Petite question: est-il prévu à un moment ou un autre de garder quelques versions des fichiers, comme Dropbox?
[^] # Re: Bravo
Posté par rakoo (site web personnel) . Évalué à 6.
Merci pour les encouragements !
Ce n'est pas prévu pour le moment, mais tout est fait pour que ce soit simple: en pratique chaque version du dossier a un seul et unique identifiant, le hash du torrent qui le décrit. On pourrait imaginer stocker ces versions et leur contenu dans un dossier spécial, éventuellement compressé, et fournir une GUI qui permette de naviguer dedans… Il y a beaucoup d'idées à reprendre de git et bup dans ce domaine, mais ça n'est pas encore la priorité :)
[^] # Re: Bravo
Posté par JoeltheLion (site web personnel) . Évalué à 3.
Je pense que les projets de synchro qui se basent sur git utilisent une enclume pour écraser une mouche: git est prévu pour des logiciels, mais pour un logiciel de synchro seules quelques versions sont nécessaires, et tout le reste (branches, tags, etc.) est complètement superflu. Et d'ailleurs git n'est pas du tout fait pour stocker des binaires.
Tu utilises un torrent par dossier? Est-ce que ça va marcher sur une arborescence avec des milliers de dossiers?
[^] # Re: Bravo
Posté par rakoo (site web personnel) . Évalué à 7.
J'ai dit reprendre les idées, pas réutiliser :)
Notamment, reprendre le modèle de donnés, qui permet de stocker des blobs de n'importe quel type (comme par exemple un torrent) et de les ordonner dans le temps. Tout le reste est du bricolage rendu possible parce que les fondations sont solides.
Un torrent par dossier racine partagé; les sous-dossiers ne font pas pas partie d'un autre torrent (à moins que l'utilisateur ait explicitement choisi de le partager… ce qui n'est même pas encore possible). La hiérarchie exacte n'a à peu près aucune influence sur le partage ("à peu près" parce que si c'est plus profond, le dictionnaire qui décrit le torrent sera plus gros, mais c'est le seul impact)
# Merci
Posté par tuxicoman (site web personnel) . Évalué à 4.
Je trouve le principe de Bittorrent Sync vraiment génial et c'est dommage que son code ne soit pas libre. Ca aurait fortement accéléré son adoption mais ca peut se comprendre si le business model de Bittorrent Inc en dépend.
Mes petites questions bêtes :
- Est ce que ca fonctionne si les 2 ordis sont derrière un NAT?
- Est ce qu'un chiffrement des données transitées (données, ID et clé d'accès au dossier partagée) est prévue à terme?
- Comment penses tu faire pour rendre cela multiplateforme ?
[^] # Re: Merci
Posté par rakoo (site web personnel) . Évalué à 10.
Tout pareil: le concept de Bittorrent Sync est génial, dommage qu'il ne soit pas libre.
Pas testé, mais si le NAT-PMP marche "ça devrait".
La solution que je vois est d'avoir une troisième machine qui fait tourner rakoshare et est accessible de l'extérieur. Techniquement cette troisième machine est un nœud tout à fait standard, mais en pratique elle va agir comme passerelle. Le but est qu'il n'y ait aucune configuration supplémentaire à faire, et qu'on ne s'embête pas avec ces bêtises de NAT.
Il n'y aura pas de clé au sens où tu l'entends; je compte réutiliser ce qui a été fait pour tahoe-lafs, à savoir avoir une suite de caractères qui contient toutes les informations nécessaires (autorisations, clé de chiffrement/déchiffrement, …) et qui ne doit avoir aucune signification pour l'utilisateur: ça doit être totalement opaque.
Le chiffrement est prévu à 2 niveaux:
Les échanges devront bien entendu être chiffrés. Les récentes nouvelles sur OpenSSL m'ont un peu refroidi sur l'utilisation de TLS, d'autant plus qu'il n'y aura pas besoin de toute sa complexité. Je pense utiliser spiped qui a l'avantage d'être compréhensible dans son intégralité sans y passer des années
Les données elle-même devront être chiffrées indépendamment de l'échange. L'intérêt est de pouvoir envoyer les données à une machine tierce qui n'a pas les éléments nécessaires pour déchiffrer; cette machine tierce pourra agir comme passerelle (voir juste au-dessus) ou comme stockage longue durée (NAS, Dropbox, …). Bien sûr, encore une fois, rien de spécial à faire pour l'utilisateur si ce n'est choisir le bon id qui donne les bonnes capacités.
Par 2 moyens:
rakoshare est écrit en Go, et toutes les plateformes où rakoshare compile peuvent le faire tourner. Aujourd'hui, ça inclut DragonFly BSD, FreeBSD, Linux, NetBSD, OpenBSD, OS X (Darwin), Plan 9, Solaris et Windows; de quoi voir venir.
Plus important encore, je compte garder le protocole simple et le documenter, pour que des implémentations alternatives puissent voir le jour.
[^] # Re: Merci
Posté par Firwen (site web personnel) . Évalué à 5.
Si je peux me permettre, evite ce genre de choses à la "spiped".
Faire une gestion correcte d'une couche TLS dépasse largement le simple "cmd line tool" + "pipe" que tu configures avec quelques variables passés en arguments. Sans parler que ça va te causer un over-head non négligeable si tu as un grand nombre de connexion ( ce qui est le cas dans un système p2p ).
C'est certes facile à dire, mais si OpenSSL te repousse (ce que je peux comprendre aisément), je te conseille d'aller voir du coté de PolarSSL si ta license te le permet, ou de gnuTLS ou si tu es courageux, de libnss.
Adev
[^] # Re: Merci
Posté par rakoo (site web personnel) . Évalué à 2.
Pas d'inquiétude, il n'est nullement question de passer les échanges dans un pipe, je pensais plutôt réutiliser une bibliothèque existante.
En fait je me demandais si tout ce qui vient avec TLS était réellement nécessaire dans mon cas: gestion des authentifications, certificats avec tout le tintouin, négociation des algorithmes, renégociations de sessions, heartbeat, …
Du coup, plutôt qu'utiliser un système qui fait tout jusqu'au café, j'ai envisagé un protocole simple, robuste, écrit par quelqu'un qui s'y connait, mais qui malheureusement a vu beaucoup moins de recherche et d'implémentations.
Après, si mon choix se porte sur tls, je prendrai certainement la librairie standard
[^] # Re: Merci
Posté par Loïc Ibanez . Évalué à 1.
Sinon pour faire plus simple stunnel ne conviendrait-il pas ?
[^] # Re: Merci
Posté par rakoo (site web personnel) . Évalué à 3.
stunnel c'est pour piper du flux réseau dans du TLS. J'ai pas envie d'avoir plusieurs dépendances et d'essayer tant bien que mal de piper l'un dans l'autre, avec tous les problèmes que ça a pour le déploiement, la portabilité…
[^] # Re: Merci
Posté par Loïc Ibanez . Évalué à 1.
Oui je comprends. C'est juste que j'aime bien les pipe ( no joke here). Une question d'habitude j'imagine ( goto no joke here).
Mais dans le cas présent effectivement le logiciel se voulant complet doit intégrer la couche sécurité en interne. Le but étant de proposer à l'utilisateur une solution simple à utiliser se limitant quasiment à "clic-droit partager ce dossier avec ce groupe".
Enfin "bash script" -> websocketd -> stunnel c'est quand même résoudre tellement, tellement de problèmes en seulement deux pipes…
Les netcateux adeptes du nc|ossplay me comprendront ;-D
# Syncthing
Posté par rewind (Mastodon) . Évalué à 10.
J'ai un autre avis. Je partage avec l'auteur de Syncthing l'idée que le protocole BT n'est pas fait pour faire de la synchronisation de dossier. Il y a plein de mécanismes existants dans le protocole BT qui sont complètement inutiles pour synchroniser des dossiers, notamment des mécanismes qui forcent un minimum au partage alors que dans le cas de la synchronisation, on veut partager donc pas besoin de forcer (je n'arrive plus à remettre la main sur le lien qui en parlait).
Et sur l'aspect fichier plutôt que dossier, je dirais qu'on verra à l'usage. Une synchronisation de dossier, ce n'est pas une gestion de version, même s'il y a une intersection non-vide entre les deux. Le protocole de Syncthing a l'avantage de la simplicité.
[^] # Re: Syncthing
Posté par rakoo (site web personnel) . Évalué à 10.
Tu veux certainement parler du tit-for-tat, qui est effectivement inutile dans notre cas: ça tombe bien, je ne l'implémente pas !
Mon calcul était plutôt de dire qu'il est plus facile d'adapter les innombrables bibliothèques bittorrent plutôt qu'inventer un protocole from scratch, et ainsi pouvoir réutiliser les infrastructures et surtout le travail existants.
[^] # Re: Syncthing
Posté par rewind (Mastodon) . Évalué à 4.
Oui, tu as raison, BT est probablement ce qui répond le mieux au problème. Maintenant, ce n'est pas forcément l'unique réponse et je trouve qu'explorer des alternatives est une bonne chose. Parce que si on voulait réutiliser l'existant, on aurait pu prendre FTP aussi. De toute façon, je préfère voir deux ou trois ou même quinze propositions de protocoles de synchronisation distribuée, plutôt que zéro comme c'était le cas jusqu'à il y a peu.
# Autre exemple "d'installation"
Posté par bubar🦥 (Mastodon) . Évalué à 8. Dernière modification le 21 juin 2014 à 16:27.
# yum install mercurial go
$ export GOPATH=/opt/go
$ go get github.com/rakoo/rakoshare
$ /opt/go/bin/rakoshare -fileDir ~/<mydir> -id <Id> -useLPD=true -useDHT=true
# Ultracopier
Posté par alpha_one_x86 (site web personnel) . Évalué à 2.
Il y as aussi Ultracopier avec le plugin rsync, qui apporte simplicité un une GUI.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# ID
Posté par flagos . Évalué à 2.
C'est quoi cette histoire d'ID ? C'est ce qui identifie ce qui est partagé ? Il n'y a aucune autre sécurité, n'importe qui qui récupère l'ID peut recuperer les données ?
[^] # Re: ID
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 2.
Comme l'auteur l'indique dans sa description, le logiciel ne semble pas totalement fini (il fonctionne, et c'est déjà pas mal ;) ), et j'ose espérer qu'il prendra en compte ce genre de problématique pour la première version stable.
[^] # Re: ID
Posté par claudex . Évalué à 3.
Je ne vois pas la différence entre un ID à donner et un couple login/password. À un moment, il faut bien les renseigner pour que le logiciel puisse télécharger le bon fichier.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ID
Posté par KiKouN . Évalué à 5.
Le mieux serai une clé voir des clés asymétriques en plus de l'ID.
Si tu n'as pas la clé, tu ne pourra pas chiffrer ou déchiffrer. Avec des clés asymétriques, on peut aussi donner des droits sur certains fichiers ou n'autoriser que certains transferts.
Par exemple, un mobile ne pourra synchroniser uniquement vers un seul pair, limitant ainsi son traffic. Ce pair retransmettant alors aux autres pairs. Si le premier pair, n'est pas disponible, il suffit d'activer une autre clé public sur le mobile en attendant.
Si le mobile est perdu, on peut invalider sa clé public sur les autres pairs.
[^] # Re: ID
Posté par jyes . Évalué à 3.
Dans ce cas autant partager un fichier chiffré avec GPG. Toute le monde peut alors transporter les données (aider à le faire transiter) mais seuls ses destinataires peuvent le déchiffrer. Bien sûr, on peut vouloir intégrer ça de façon plus couplée avec le protocole de partage pour gérer des droits ou du versionnement, mais dans ce cas l’approche de l’auteur me semble plus pertinente que je système de clefs asymétriques.
[^] # Re: ID
Posté par ziliss . Évalué à 1.
Question: est-ce que le hash du torrent est directement lié à l'ID ? Car si c'est le cas, il sera facile de faire la liste de toutes les IDs en cherchant tous les hashs publiés dans la DHT.
[^] # Re: ID
Posté par rakoo (site web personnel) . Évalué à 2.
Pas directement.
L'ID est fixe et généré aléatoirement. Il permet de garder une identité tout au long des échanges. Le hash du torrent est tout à fait standard. Il n'y a aucun moyen de dériver l'un à partir de l'autre, il faut nécessairement faire partie des échanges pour pouvoir faire le lien.
Il est possible de scraper les hashs publiés dans la DHT (ou sur les trackers, c'est possible aussi). Déjà, ces hashs sont dérivés des IDs de manière à être le plus stable possible. Mais ces hashs sont dérivés de l'ID, donc il est impossible de savoir de quoi on parle quand on récupère un de ces hashs (il ne sera même pas possible de stocker la version chiffrée du contenu; impossible de remonter). La seule information éventuellement disponible sera l'ensemble des ips qui font partie du swarm.
[^] # Re: ID
Posté par rakoo (site web personnel) . Évalué à 10.
Je suis désolé, la terminologie est un peu confuse, les détails ne sont pas encore là, mais voilà comment je vois les choses:
Le système est calqué sur les capabilities de Tahoe-LAFS: les utilisateurs ne se soucient que de ça. C'est une chaine de caractères, opaque pour l'utilisateur (ie il copie-colle sans se poser de questions), qui contient toutes les informations nécessaires; voici en gros ce qu'il y a pour Tahoe-LAFS:
Du coup, pour qu'un utilisateur donne accès à une ressource à quelqu'un d'autre, il lui suffit de copier-coller cet id. C'est d'ailleurs pour ça qu'on l'appelle également capability: ça indique les autorisations de celui qui connait cet id.
Là où ça devient intéressant, c'est que tu peux dériver les capabilities: à partir d'une capability qui a les droits d'écrire, tu peux dériver une capability qui n'a que le droit de lire. Du coup si tu ne donnes que cette dernière, tu seras le seul à pouvoir modifier le contenu.
Encore une fois, ce qu'il faut retenir, c'est que l'utilisateur n'a pas à comprendre le contenu de cet id; il doit juste copier-coller le bon (celui qui donne le droit d'écrire, celui qui ne donne que le droit de lire, celui qui ne permet que de stocker la version chiffrée mais pas de lire le contenu en clair).
Après, ça veut dire que si tu colles cet id dans un email en clair qui passe chez Google, oui, Google aura les mêmes droits. Mais ça sera la même chose avec un login/mot de passe, et comme personne parmi les personnes visées n'utilise (voire connait) PGP, la sécurité n'est pas amoindrie. Disons que le point faible est dans la transmission de cette information de base, et ça sort du cadre de rakoshare. Je pars du principe que les utilisateurs sont un minimum conscients des personnes qui ont accès à ce qu'ils copient-collent dans une fenêtre de discussion ou un email.
Note: pour plus de détails sur comment marche Tahoe-LAFS, voir cette présentation. Tahoe-LAFS est vraiment bon, j'espère que des fournisseurs de stockage auront une offre compatible.
[^] # Re: ID
Posté par flagos . Évalué à 2.
Merci pour ces eclaircissements, c'est intéressant.
Je m'inquiétais d'une attaque en mode force brute, où un attaquant essaierait simplement de générer des ID et de voir si la peche est bonne. Si la chaine est longue, effectivement ca reduit les risques.
# Specs ?
Posté par ckyl . Évalué à 4. Dernière modification le 23 juin 2014 à 10:56.
Et il est déféni où le protocole et ainsi que les machines à état du bouzin ? En fait fonctionnellement tu n'expliques même pas ce que ca fait (multi-directionel ou non, révisions, gestion des conflits etc.)
Pour ce genre de projet j'ai tendance à avoir un avis très négatif sur les projets qui "make it work" avant de pouvoir expliquer en détail pourquoi et comment leur système allait tenir le coup d'un point de vue conceptuel. Je passe mes journées à bosser avec des gens créant des systèmes distribués qui ne pourront jamais fonctionner correctement par ce que la phase théorie à juste été oubliée. Un système distribué ca ne se concoit pas au niveau du code.
[^] # Re: Specs ?
Posté par rakoo (site web personnel) . Évalué à 2.
Dans ma tête :)
Si les commentaires m'ont bien montré une chose (merci à la communauté d'ailleurs) c'est que la documentation est vitale. Elle manque très clairement, je la remplirai au fur et à mesure de mes avancements.
Pour avoir une première idée, voilà comment ça marche:
Voilà en gros les choses. Mais une documentation reste nécessaire (et viendra!)
[^] # Re: Specs ?
Posté par tetraf . Évalué à 1.
Comment tu gères les conflits ? Les changements simultanés sur plusieurs nœuds différents ?
[^] # Re: Specs ?
Posté par rakoo (site web personnel) . Évalué à 7.
Comme Couchdb.
Chaque fois qu'une modification est enregistrée, je lui associe une révision de la forme
où counter est un compteur incrémental, et hash est un hash sha1.
Le compteur permet d'avoir un ordre dans les mises à jour; si j'en suis à la version 6 et qu'un changement sur le disque est enregistré, je passe à la révision 7 et j'update le hash (on verra après comment).
Maintenant on passe du côté du receveur: je reçois un message qui me dit Nouvelle version: 7. Si j'en suis déjà plus loin, je rejette. Sinon je prends la nouvelle version après avoir vérifié la signature.
Là où ça se gâte c'est si je suis déjà à la version 7. Dans ce cas je vérifie le hash.
Celui-ci est calculé à chaque révision à partir de la révision précédente et de l'infohash de la version courante. L'idée est que ce hash identifie de manière unique l'historique de l'échange. Du coup, si le hash que je reçois est le même que celui que j'ai, je suis totalement sûr qu'il n'y a pas eu de conflits puisque l'historique est le même; si les hash diffèrent alors j'ai un conflit. Dans ce cas-là ce qui est prévu (et pas encore présent) est de stocker les différentes versions en parallèle, avoir un indice suffisamment compréhensible pour que l'utilisateur voie qu'il y a un conflit:
le résolve (ça ne devrait pas être plus compliqué que ça):
après quoi rakoshare devra considérer la version gagnante pour ses futurs échanges.
Note que si j'en reçois 2 messages comportant le même compteur mais deux hash différents en même temps, il y en a un que je traiterai avant l'autre puisque je ne traite pas les choses en parallèle, donc on retombe dans le cas précédent.
Pour faire court, rakoshare ne résoud pas les conflits, mais délègue ça à l'utilisateur pour qu'il s'en occupe, tout en éliminant les cas où on a l'assurance qu'il n'y a en fait pas de conflits.
# Dossier ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -3.
C'est quoi un dossier ? Quel type de logiciels sont capables d'ouvrir ces fameux dossiers ?
[^] # Re: Dossier ?
Posté par rakoo (site web personnel) . Évalué à 3.
Je parle de ce dossier, que j'aurais certainement dû appeler répertoire si c'est le message derrière ton commentaire :)
[^] # Re: Dossier ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -2.
Évidement, ce serait bien d'utiliser les termes techniquement pertinents. Surtout sur un site qui est censé avoir un public averti. Mais vu mon score, il est à craindre que la jeunesse corrompue par l'inepte 'dossier' de la conspiration Applomicrosoftiste n'ait gagné la bataille, et la logique balayée.
« Dossier » est un terme tout à fait inadapté, car un dossier n'existe pas dans un système de fichier, puisqu'un répertoire est un annuaire de fichier, là où un dossier contient des fiches. Or, un répertoire ne peut pas contenir des fiches, il est une fiche !
[^] # Re: Dossier ?
Posté par ariasuni . Évalué à 4.
{{Référence nécessaire}}
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Dossier ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
C'est un bon départ : http://en.wikipedia.org/wiki/Advanced_Programming_in_the_Unix_Environment
Ensuite tu peux aussi réfléchir, et comprendre ce qu'est un fichier, qu'un répertoire est un fichier particulier qui référence d'autres fichiers, puis tu peux faire des recherches sur l'historique de l'apparition de la terminologie « folder » dans les année 80, etc.
Un bon début : http://en.wikipedia.org/wiki/Folder_(computing)
[^] # Re: Dossier ?
Posté par ariasuni . Évalué à 6.
Si tu pouvais directement nous donner l’information, je vais quand même pas acheter le livre juste pour voir ce dont tu parles.
…
Ça fait des années que dossier et répertoire sont utilisés indifféremment. D’après ton lien vers Wikipédia, «dossier» est la métaphore d’interface graphique utilisé, et «répertoire» qui est un concept dans un système de fichier.
Dans tous les cas je ne vois pas bien pourquoi il faudrait éliminer une appellation en faveur de l’autre.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Dossier ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Ben tu devrais acheter et lire le livre, il est très intéressant.
Supprimer une erreur est toujours une bonne chose. Et parler de dossier est une erreur.
[^] # Re: Dossier ?
Posté par barmic . Évalué à 8.
Et le quel du dossier et du répertoire gère les droits d'accès, les fichiers cachés, les liens symboliques ou non ?
Les allégories informatiques ne sont pas complètes quoi qu'il arrive. Utiliser dossier ou répertoire n'est pas très important vu que les 2 sont très bien compris. Ça doit pas choquer grand monde à part toi et Tanguy Ortolo.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dossier ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
Justement, les deux ne sont pas compris. Avec folder/dossier, on se retrouve avec des prétendus développeurs qui ne comprennent pas qu'un répertoire peut référencer un même fichier parce qu'ils ne le comprennent pas.
ln toto/tata tutu/tete
Oui, moi ça m'emmerde cette "allégorie", qui opère un raccourci trompeur. Un répertoire ne contient pas, il ne peut pas contenir. Si maintenant on appelle les répertoire des dossiers, pourquoi aller plus loin dans la confusion et de parler de curseur en lieu et en place de pointeur (de souris) ?
[^] # Re: Dossier ?
Posté par ariasuni . Évalué à 3.
C’est pas un problème de terminologie, c’est un peu problème de développeur qui ne savent ce qu’est un lien symbolique.
Ah bah là j’ai compris où tu voulais en venir. Néanmoins, je doute que ça soit pertinent d’éliminer l’allégorie du dossier pour l’individu lambda. Doit-on expliquer à quelqu’un comment fonctionne l’implémentation du système de fichier avant qu’il puisse utiliser un ordinateur?
Je ne sais pas dans quelle grotte tu vis, mais c’est déjà le cas. Et là du coup, ça m’intéresse aussi de savoir pourquoi c’est une mauvaise idée selon toi.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Dossier ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
Bien joué, tu es tombé dans le piège, puisque tu ne sembles pas savoir ce qu'est un lien dur (hardlink).
Oui. Quand tu prends des leçons de conduite automobile, tu apprends comment ça marche, une voiture. Ben là c'est pareil, il faut un minimum de notions.
Si je ne le savais pas, j'aurais inventé une association moins stupide :p Ben le curseur, c'est le machin qui clignote, qui court quand tu tapes.
Le pointeur de la souris sert à pointer quelque chose dans une GUI.
Le curseur sert à indiquer où on en est de la course dans la frappe des caractères.
Sémantiquement ça se pose.
[^] # Re: Dossier ?
Posté par ariasuni . Évalué à 2.
Bien sûr que je sais ce que c’est. D’ailleurs on traduit habituellement ça par «lien physique» ou «lien matériel», et pas «lien dur» (cf. le manuel de
ln).En pratique c’est la même problématique que le lien symbolique: quand on modifie un fichier, ça peut foutre la merde ailleurs. Et c’est même plus simple à gérer que le lien symbolique parce que si on supprime le lien physique on sait que ça ne posera pas de problème ailleurs.
Oui, tu as raison, c’est plus logique d’avoir curseur/pointeur et de ne pas mélanger les termes. Le problème c’est que c’est un peu tard… Si encore ça n’étais pas utilisé dans GNOME/KDE.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Dossier ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 0.
Je ne lis jamais la documentation en français.
Nope, ça fout la merde à un endroit, dans un seul fichier.
C'est un grand malheur que ces directions prises par ces projets ces dernières années. Je me demandes quand Gnome Web sera renommé en GNOME Internet Explorer. Le problème n'est pas de venir tard ou tôt. J'ai toujours combattu l'appellation « dossier », mais c'est la première fois que je la rencontre sur DLFP pour parler d'un logiciel qui s'occupe de gérer ou transférer des fichiers, en dehors des news sur l'ignoble GNOME.
[^] # Re: Dossier ?
Posté par ariasuni . Évalué à 3.
C’était juste un exemple. Tu parles jamais à des humains de type francophones? :p Bon d’accord j’arrête de t’embêter.
Ça fout la merde dans un ou plusieurs autres répertoires.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Dossier ?
Posté par KiKouN . Évalué à 2.
Il faudrait un lien CoW.
[^] # Re: Dossier ?
Posté par barmic . Évalué à 4.
Celui qui n'avait pas compris et qui t'a sorti cette affirmation, s'est trouvé à la fois une excuse et une bonne poire pour le croire. Comme dis plus haut le répertoire non plus ne porte pas le sens du comportement des répertoires informatiques. D'ailleurs les fichiers non plus. Les méta données (ou les inodes si tu préfère) n'ont pas de sens pour un fichier. Les fichiers éparses, binaires etc n'ont pas de sens dans le monde physique et on utilise des mots qui cachent le mécansimes d'extends.
C'est pas le raccourcis qui est trompeur, c'est les cours fait ou suivi à l'arrache, c'est les IHM qui ignorent encore totalement ces concepts,…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dossier ?
Posté par Psychofox (Mastodon) . Évalué à 0.
Ce n'est manifestement pas le cas puisque tu sembles confondre les deux. Le répertoire est un élément du filesystem, le dossier un concept lié aux interfaces graphiques. Un dossier correspond souvent à un répertoire dans un filesystem, mais ce n'est pas forcément le cas. Donc non ce n'est pas bien compris.
[^] # Re: Dossier ?
Posté par barmic . Évalué à 4.
Waow ! On va loin dans la mauvaise fois !
Aller on va chercher les système de fichier fuse pour trouver des contres exemple avec des répertoires qui se comportes de manière parfaitement identiques à des dossiers ou on va chercher des IHM qui utilisent des dossiers virtuels ?
La zoophilie est interdite en France même sur les drozophiles !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dossier ?
Posté par Psychofox (Mastodon) . Évalué à 0.
Tu mélanges mauvaise fois et précision. Pas étonnant que tu aies des problèmes à ne pas mélanger d'autres mots.
[^] # Re: Dossier ?
Posté par ariasuni . Évalué à 2.
mauvaise foi
Écrit en Bépo selon l’orthographe de 1990
# Lier à des services externes
Posté par Tiroly . Évalué à -7.
Ce genre de services ne sont-ils pas en trains d'apparaître de manière de plus en plus rapide sur le net, sans proposer de réels nouveautés ?
Pourquoi ne pas proposer l'intégration de services externes plus avancés comme de l'impression en ligne avec http://printime.fr en France ou https://www.lob.com aux US ? (Ce ne sont que des exemples)
[^] # Re: Lier à des services externes
Posté par Wawet76 . Évalué à 2.
C'est du spam ce commentaire ?
[^] # Re: Lier à des services externes
Posté par KiKouN . Évalué à 2.
Sauf si pour imprimer sur l'imprimante de son bureau depuis n'importe où.
Mais bon, pour cela, on peut utilisé Rakoshare ou autre. On dépose le pdf dans un dossier. Le pair avec l'imprimante lit le fichier, l'imprime et l'efface une fois fini.
# Syncany
Posté par srm . Évalué à 1.
Et Syncany alors ? Ça me semble le candidat le plus intéressant et de loin
# Langage GO
Posté par C. OB (site web personnel) . Évalué à 5.
Bonjour,
Tant syncThing que Rakoshare sont écrit en Go.
Fort bien, mais je trouve que ça complique significativement leur portage sur autre chose qu'un PC, notamment via les framework embarqués: Buildroot/OpenWRT/Yocto/…
Or, pour moi, si l'intérêt d'avoir ça sur PC est indéniable, le vrai plus (et là où Bittorrent Sync commence à arriver) c'est dans les NAS et autre box embarquées. Et là…. c'est nettement plus compliqué, surtout en terme de compilation, mais aussi en terme de place occupé par le binaire & en mémoire.
J'essaie depuis quelques jours de porter SyncThing sur OpenWRT (mais le problème sera identique pour Rakoshare), et bien …. il y a un bon nombre de pré-requis, ça ne se fait pas tout seul (J'avoue que j'ai pas encore testé sur Yocto; par exemple un usage que je verrais bien c'est sur un MediaServer , qui récupérerai ainsi tout seul les média).
[^] # Re: Langage GO
Posté par rakoo (site web personnel) . Évalué à 2.
C'est vrai, Go n'est pas adapté aux plateformes limitées en mémoire. C'est pourquoi j'ai prévu de garder le protocole simple pour qu'il puisse être ré-implémenté par d'autres si nécessaire (et puis ça me donnera une excuse pour essayer de nouveaux langages, comme ça).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.