Bonjour tous,
Le test du samedi: Bittorrent Sync. Profitant de quelques minutes, j'ai testé ce matin celui qui pourrait bien répondre à quelques problèmes de dropbox et consorts: espace disque limité, et absence de confidentialité des données. Le principe de Bittorrent Sync est simple: à chaque répertoire partagé correspond une clé unique qui donne accès à ce dernier.
Installation
En 2 clicks sous Mac OSX, et guère davantage sous Arch puisqu'il existe un package dans AUR. Pour les autres distributions, il est possible de télécharger un binaire directement depuis la page officielle
Utilisation
L'interface MacOSX est intégrée au systray, alors que la version Linux nécessite un navigateur web et le passage par http://localhost:8888/gui pour accéder aux réglages.
Pour partager un répertoire, il suffit de l'ajouter à la liste idoine, puis de générer une clé. Pour synchroniser ce répertoire sur une autre machine, il suffit d'ajouter un nouveau répertoire à prendre en compte, et de renseigner la clé correspondante.
C'est simple, ça marche, ça fonce. À noter qu'il est possible de créer des clé valables une seule fois, et également de ne donner accès qu'en lecture seule.
Réserves
Pour être accessibles, au moins une des machines contenant les données doit être allumée. Pas de client pour smartphone pour l'instant. Les autres limites m'importent peu pour l'instant, hormis….
… la licence ! Le code source n'est pas disponible, ce qui fait perdre beaucoup d'intérêt par rapport à Dropbox: au lieu d'avoir nos données dans une machine "boite noire" chez Dropbox (amazon?), elles restent chez nous mais sont prises en charge par un logiciel "boite noire". Le problème est déplacé, mais pas résolu, et la chaine de confiance est brisée.
Bref, après avoir été largement emballé, cette histoire de licence m'a bien refroidi. Moi qui pensait avoir trouvé un système simple, sans trop de limitations (Win/Mac/Lin), sécurisé, rapide et décentralisé, me voilà bien dépité.
Voilà, c'était le coup de gueule du samedi, merci d'avoir lu jusque là :-)
Aurel.
# Protocole
Posté par Victor . Évalué à 2.
Je me demande si ça ne suffit pas d'avoir le protocole pour en faire une implémentation open source / libre / maison.
J'ai regardé un peu sur le net, c'est clair qu'ils ne planifient pas de rendre l'appli open source (http://forum.bittorrent.com/topic/17782-bittorrent-sync-unofficial-faq/) mais je n'ai rien trouvé sur le proto…
[^] # Re: Protocole
Posté par fravashyo . Évalué à 10.
l'argument donné, par ce qu'il semble être un développeur ou admin de chez bittorrent, est vraiment bidon :
Ça avait l'air alléchant dans le début du journal, mais finalement ce n'est plus trop le cas quand on sait que les sources ne sont pas publiées.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Protocole
Posté par aurel (site web personnel, Mastodon) . Évalué à 10.
Et oui, et c'est bien pour évacuer ma frustration que j'en ai fait un journal :-)
[^] # Re: Protocole
Posté par StreakyCobra . Évalué à 9.
Argument convainquant! C'est sûr que le principe de la sécurité par l'obscurité est connu pour son efficacité!
[^] # Re: Protocole
Posté par François (site web personnel) . Évalué à 1.
J'ai eu une autre réponse sur twitter: https://twitter.com/aifsair/status/325135614980792320
En gros, ils disent que baser la confiance sur le client est suffisante.
[^] # Re: Protocole
Posté par Victor . Évalué à 3.
Tu réponds à quoi ?
C'est une autre app avec un modèle différent (il y a un serveur, qui est closed source !), non ?
[^] # Re: Protocole
Posté par François (site web personnel) . Évalué à 1.
Oui pardon, j'ai complètement confondu …
En plus je n'arrive pas à corriger mon post initial. Désolé!
[^] # Re: Protocole
Posté par Victor . Évalué à 2.
:P ça nous aura au moins permis de découvrir ce truc
[^] # Re: Protocole
Posté par yohann (site web personnel) . Évalué à 4.
J.vachez bosse chez bittorent ?
# Ce qu'il manque
Posté par Victor . Évalué à 5.
Et ce qu'il manque à un outil comme ça, c'est la possibilité de mettre en place un réseau de confiance pour sauvegarder ses trucs chez les autres sans pour autant qu'ils puissent voir le contenu…
Un espèce de tarsnap (https://www.tarsnap.com/) distribué…
[^] # Re: Ce qu'il manque
Posté par aurel (site web personnel, Mastodon) . Évalué à 4.
Le principe du réseau de confiance, ce serait justement de ne pas avoir besoin de chiffrer les données, puisqu'on leur ferait confiance :-)
Si des tiers mettent à disposition de l'espace disque, sans confiance particulière et donc avec la nécessité de chiffrer les données, il y a par exemple Tahoe-LAFS, un projet qui semble très joli mais que je n'ai pas testé.
[^] # Re: Ce qu'il manque
Posté par Maclag . Évalué à 8.
C'est parce que "confiance" est un terme trop vague, soyons précis.
Lui, il voulait dire "confiance dans l'incompétence du mec qui va héberger tes données à trouver la clé de déchiffrement"
-----------> [ ]
[^] # Re: Ce qu'il manque
Posté par un_brice (site web personnel) . Évalué à 2.
Pour les sauvegardes, je ne suis pas convaincu de l'utilité du pair à pair. Étant donné que tes donnés sont cryptées le fournisseur de stockage n'y a pas accès. Du coup avoir un système géré par une seule entité semble plus efficace car il peut ordonnancer les maintenances planifiées pour réduire le surcoût lié à la redondance, réduire les coûts liés au réseau, intervenir directement sur les nœuds en cas de problème…
En revanche il semble que Tarsnap soit lié à un fournisseur. Tu peut vouloir utiliser Duplicity qui en supporte de très nombreux. En choisissant ton fournisseur, tu module le risque à tes besoins avec tes contraintes de coût.
PS: Bien évidement, ceci est sous l'hypothèse à priori très réaliste que tu ai la possibilité de trouver un fournisseur de stockage (tu a accès à un moyen de paiement etc etc).
[^] # Re: Ce qu'il manque
Posté par Victor . Évalué à 3.
Je suis globalement d'accord avec toi, pour le pair-à-pair, l'idée était surtout de se débarrasser d'une entité dont les intérêts ne sont peut-être pas les miens, et puis il y a aussi l'idée plutôt utopique de suppression d'un contrôle central, et surtout d'un point central de défaillance (genre vous vous rappelez de megaupload ? ;)
C'est comme quand on découvre l'administration sous linux, il arrive souvent un point où on monte son serveur mail perso, et quand on est plusieurs à faire ça, l'idée de chacun servir de backup mx pour les autres émerge tout naturellement : c'est un peu aussi dans ce même esprit que ma question apparaît (et bon, on en revient, et on fini sur google apps :)
# Pas dropbox killer
Posté par ribwund . Évalué à 4.
Ça fait pas du tout la même chose que dropbox non ? J'ai l'impresssion que c'est plus l'équivalent de unison (avec un protocol pour faire du NAT traversal), mais si par exemple t'as une seule machine, si ton disque crashe t'as perdu tes données (avec bt sync).
(Dites moi si c'est pas le cas, leur site est vraiment pas clair)
[^] # Re: Pas dropbox killer
Posté par rakoo (site web personnel) . Évalué à 4.
SyncApp c'est comme dropbox sans les serveurs de dropbox. Ces derniers assurent la disponibilité des données, mais portent atteinte dans leur fonctionnement à la confidentialité des données. En parallèle, dropbox te permet d'avoir un utilitaire sur chaque machine qui se synchronise avec tes autres machines et les serveurs centraux. Ici, pas de serveur central qui stocke tout ce qu'il y a chez toi, toutes tes données sont uniquement sur tes ordinateurs.
Enfin, à priori, puisqu'on ne peut pas savoir ce qu'il fait.
[^] # Re: Pas dropbox killer
Posté par ribwund . Évalué à 4.
Du coup je vois pas trop l'interet par rapport à une solution comme unison. Si la confidentialité des données est un problème, tu peux aussi chiffrer tes fichiers chez dropbox.
[^] # Re: Pas dropbox killer
Posté par rakoo (site web personnel) . Évalué à 4.
unison synchronise tes machines une à une. Si tu as 10 machines, tu dois mettre en place toutes les synchronisations. Comme tu te rends compte que c'est vite la galère, tu vas mettre en place un serveur central auquel tout le monde va se connecter, mais si le serveur tombe, plus rien ne marche. Ici, à supposer que le protocole est pas trop différent de Bittorrent, chaque machine partage et récupère en fonction de ses besoins et de sa disponibilité, sans administration lourde.
unison ne gère pas le versionnement des fichiers. SyncApp non plus, mais c'est dans les tuyaux. De même, il est prévu une version mobile pour SyncApp
De manière générale, SyncApp est soutenu par une entreprise, unison n'est même plus développé. unison est très bien pour les barbus qui savent se débrouiller, mais encore une fois, Mme Michu n'est pas capable; c'est plus à ce besoin de "je clique, ça marche" qu'autre chose que répond SyncApp.
Aujourd'hui, d'un point de vue purement technique, je ne vois rien qui se rapproche de SyncApp (tout particulièrement sur l'aspect décentralisé; la plupart des solutions mettent tout sur un serveur centralisé, et les autres machines vont récupérer les infos dessus).
[^] # Re: Pas dropbox killer
Posté par fravashyo . Évalué à 4.
j'espère que si quand même… la dernière beta date d'un an, mais le développeur principal est bien actif encore sur la mailing-list. C'est un logiciel que j'utilise tous les jours, j'espère qu'il ne deviendra pas obsolète…
Cette page indique qu'il y aura quand même des correctifs en cas de découverte de problèmes sérieux, et que l'auteur est prêt à rajouter des fonctionnalités si on veut payer pour ça :
http://www.cis.upenn.edu/~bcpierce/unison/status.html
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Pas dropbox killer
Posté par fredix . Évalué à 1.
AeroFS
[^] # Re: Pas dropbox killer
Posté par rakoo (site web personnel) . Évalué à 2.
Je me suis mal exprimé, pardon : je ne vois rien d' open source qui rivalise techniquement avec SyncApp.
[^] # Re: Pas dropbox killer
Posté par Albert_ . Évalué à 2.
Et Owncloud ? Bon ok il faut l'installer soit même sur un serveur mais après c'est très ressemblant a dropbox et il semble y avoir un truc de gestion de version et une application pour smartphone.
[^] # Re: Pas dropbox killer
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
Owncloud n'est pas un remplacement à Dropbox car il fait beaucoup plus de choses. Il est moins facile à installer, nécessite un serveur quelque part, et d'après mon expérience ces derniers mois, il n'est parfois pas super fiable: conflits de fichiers, synchronisation très lente même sur le LAN, le chiffrement disponible pour la version 4 qui n'est plus disponible pour la version 5, ce qui oblige de repartir sur une sauvegarde de ces dernières… et j'en passe et des meilleures.
Après, ça s'améliore avec le temps, et je l'utilise au quotidien malgré tout. Le problème pour les programmes de ce genre, c'est qu'ils se doivent de fonctionner: on leur confie les données qu'on veut synchroniser ou accéder depuis une interface web, ce sont par définition des données dont on a besoin, et le moindre crash ou bug est donc extrêmement gênant. Sur ce point, il faut reconnaitre que Dropbox fait assez fort.
[^] # Re: Pas dropbox killer
Posté par flagos . Évalué à 6.
Après tu as sparkleshare. Tu instancies un serveur git avec git init --bare et derrière sparkleshare se connecte a ton serveur git en ssh.
Ca marche plutot pas mal (meme s'il faut que sparkleshare soit au moins en version 1.0 pour éviter des bugs de synchro).
Je l'utilise de manière assez intensive, ma femme y met tous ses fichiers liés a son activité professionnelle. Ca synchronise sur 5 pc en parallèle. De temps en temps, il faut que j'aille faire un git pull a la main sur un des pc pour décoincer sparkleshare, mais sinon ca commence a être fiable.
[^] # Re: Pas dropbox killer
Posté par fravashyo . Évalué à 5.
le client android n'est vraiment pas super : par exemple il ne va pas faire de synchronisation avec les dossiers dans lesquels on navigue, mais avec l'ensemble des fichiers sur le compte.
Ainsi moi qui ai environ 4 Go de données avec des dizaines de milliers de fichiers, si je modifie un fichier sur le serveur (par exemple en local ou via l'interface web) et que je veux rapidement accéder à ce fichier depuis le client android, c'est vraiment impossible, la synchro n'aboutit pas la plupart du temps, et dans le meilleurs des cas ça prend plus de 20 minutes pour synchroniser (c'est à dire vérifier tous les fichiers), alors que je préférerais synchroniser en priorité les dossiers que j'utilise réellement (ou en tout cas forcer la synchro dans un dossier particulier)
Ils en parlent ici mais ce n'est pas dans les priorités : https://github.com/owncloud/android/issues/96 (oui je sais, c'est libre, je n'ai qu'à contribuer). Bizarre parce que ça me semble primordial mais bon.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Pas dropbox killer
Posté par _alex . Évalué à 3.
Avec un serveur central : http://sparkleshare.org/
Pas testé plus que ça.
Plus "compliqué" pour Mme Michou à mettre en place de DropBox puisqu'il faut des clés public / privée mais il y a ça : https://github.com/hbons/SparkleShare/wiki/Invites
Quelques liens :
- https://github.com/hbons/SparkleShare/wiki
- http://www.generation-linux.fr/index.php?post/2013/03/20/Installation-d-un-serveur-Sparkleshare-sur-Debian-et-d-un-client-Sparkleshare-sur-Ubuntu
# vous oubliez juste ...
Posté par i M@N (site web personnel) . Évalué à 0.
que ça fonctionne avec le protocole bittorrent, c'est du P2P contrairement à dropbox et compagnie et c'est très simple à mettre en place.
J'ai mis en place la synchronisation de 4 dossiers en Read-Only avec la personne avec qui je gère un site et ça fonctionne très bien.
Avant il envoyait des fichiers sur le FTP du site, je les récupérais par FTP, je les retravaillais sur ma machine et je les mettais sur le site par rsync + ssh.
Maintenant je lance btsync, je retravaille les fichiers et je les envoie sur le site. ça remplace un aller-retour FTP par une syncronisation en P2P.
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: vous oubliez juste ...
Posté par ckyl . Évalué à 7.
Et surtout sembles remplacement un mauvais outil par un autre mauvais outil. Ce que tu sembles vouloir c'est un SCM pour d'une part faire travailler en collaboration, et d'autre par déployer le produit. FTP, rsync, ou bittorrent ca semble plutôt crado pour ce que tu décris.
[^] # Re: vous oubliez juste ...
Posté par i M@N (site web personnel) . Évalué à 1.
C'est pas sur du code qu'on se synchronise, juste des fichiers images et son … c'est donc parfaitement adapté.
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: vous oubliez juste ...
Posté par GuieA_7 (site web personnel) . Évalué à 1.
Dans l'absolu il existe des SCM spécialisés dans la gestion d'assets. J'en ai même vu passé un qui était libre, mais je sais pas ce qu'il vaut.
[^] # Re: vous oubliez juste ...
Posté par Victor . Évalué à 2.
Franchement, c'est difficile de contre-argumenter sur son témoignage : btsync correspond parfaitement bien au besoin.
Pas de serveurs, de configuration ou je ne sais quoi à mettre en place, et les trucs qu'il partage ne sont pas versionnés.
[^] # Re: vous oubliez juste ...
Posté par ckyl . Évalué à 2.
Quand je bossais avec des designers ce qu'ils nous produisaient était versionné; sinon on s'en sort pas et c'est n'importe quoi.
Versionné de ne pas forcément dire pouvoir faire un diff. Ca veut dire avoir une cohérence et un historique de livraison et de travail. Autrement ca devient La Rache. Si j'ai besoin de refaire le boulot que tu as fait y'a 3 jours comment je fais ? Comment je fais pour m'assurer que j'ai rien raté ? Comment je fais pour pousser en prod de manière cohérente ?
[^] # Re: vous oubliez juste ...
Posté par fearan . Évalué à 2.
C'est même la différence entre une méthode dite Agile et la Rache ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: vous oubliez juste ...
Posté par i M@N (site web personnel) . Évalué à -2. Dernière modification le 30 avril 2013 à 23:24.
Merci Victor … je sais pas si je me suis mal exprimé ou si certains essayent de me faire sodomiser des mouches mais je ne vois pas l'utilité de "versionner" puisque c'est lui qui met des images et des sons à ma disposition pour que je les retravaille en illustrations et en samples. On fonctionne comme ça et les rôles ne changent pas parce qu'il ne saurait pas traiter les images et les sons à ma place.
t'arrête de boire
wind0w$ suxX, GNU/Linux roxX!
# SparkleShare
Posté par JoeltheLion (site web personnel) . Évalué à 3.
Est-ce que quelqu'un a essayé SparkleShare? ( http://sparkleshare.org/ ) Sur le papier, ça a l'air pas mal.
[^] # Re: SparkleShare
Posté par Anonyme . Évalué à 1.
A part le fait de ne pas avoir à commiter manuellement, SparkleShare ne me semble pas apporter grand chose de plus qu'un simple depot git.
[^] # Re: SparkleShare
Posté par NilugeKiWi . Évalué à 2.
Pas besoin de commiter, mais aussi pas besoin de puller, bref, c'est transparent. Et ça peut s'utiliser par des gens qui connaissent pas git. Bon il manque encore la présentation des vielles versions sans passer par git à la main.
J'ai cru comprendre qu'ils utilisent un 2em protocole pour pusher les notifications aux clients: "Hey, il y a un nouveau commit, vas-y, pull". Je ne sais pas s'il est company firewall-friendly. S'il ne n'est pas ça perd beaucoup d'intérêt…
# Alternative a Dropbox: git-annex assistant
Posté par Mildred (site web personnel) . Évalué à 4.
En parlant d'alternative a Dropbox, il existe le projet git-annex assistant issue du crowdfunding: http://git-annex.branchable.com/assistant/
Compatibilité: GNU-Linux, OS-X, Android (en cours)
# Pourquoi faire simple quand on peut faire compliqué ?
Posté par zebra3 . Évalué à 0. Dernière modification le 29 avril 2013 à 12:52.
Pourquoi pas un simple Apache configuré en WebDAV, avec SSL et un htpasswd ?
En plus, ça marche avec Internet by Orange et ça passe au travers des proxy…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Zenitram (site web personnel) . Évalué à 4.
Tiens, comme par miracle, c'est rapide (écrire à distance plutôt qu'avoir un truc temporaire sur le disque local, c'est pas chiant du tout), ça gère l'historique (le grand avantage de Dropbox est le droit à l'erreur), la configuration ce fait en 3 clics et ça coûte pas cher de gérer son serveur (hébergement physique réellement dispo donc pas chez soit et prix de l'admin).
J'utilise ce dont tu parles, mais voila : je sais très bien que ce n'est pas terrible pour tout le monde (y compris moi, cette histoire de backup manquant m’embête un peu par rapport à Dropbox)
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par zebra3 . Évalué à 0. Dernière modification le 29 avril 2013 à 14:39.
Justement, il me semble qu'avec Dropbox tu as un répertoire local qui est synchronisé, donc tu n'évites pas l'écriture locale.
OK, alors il suffit d'ajouter un git couplé à incron.
Je pense que si on veux du prêt à l'emploi, faut pas s'attendre à avoir le contrôle comme l'auteur du journal semble le souhaiter.
Il se plaint des défauts de DropBox et de BT Sync, mais pour avoir quelque chose qui corresponde exactement à nos besoins, pas d'autre choix que de se sortir les doigts.
Moi aussi, mais le but n'est pas de faire un truc pour tout le monde, mais que ça réponde juste au besoin de l'auteur.
À ce que j'ai compris, si c'est juste un partage accessible partout (à partir du moment où il a internet), ça me paraît suffisant.
Un rsync sur un DD externe, ça ne suffit pas ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Zenitram (site web personnel) . Évalué à 2.
L'écriture local est justement un avantage de Dropbox, et un inconvénient de webdav (il y a parfois, avec certains logiciels, une gestion d'un cache, mais il est pas grand)
Justement, la critique de ce genre de bidouilles est que c'est pas simple, donc il vaut mieux avoir le critère numéro 1 (l'utilisabilité) avant d'avoir le critère numéro 3 (le contrôle, le 2 étant le prix par exemple)
Je pensais au backup de Dropbox (historique), Dropbox utilisant Amazon sur 2 sites, c'est déjà pas mal (avant que je puisse avoir le même niveau de service chez moi tout seul, ben ça va douiller)
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par zebra3 . Évalué à 1.
Au temps pour moi, j'avais compris l'inverse.
Ça à mon avis, c'est une affaire de choix.
Personnellement, je mets le critère 3 avant le critère 1, surtout qu'une fois que tu as le contrôle, tu peux améliorer plus facilement l'utilisabilité.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Comme dit : moi aussi. Mais je regarde pour les autres, et comprend grandement (tout le monde n'est pas tranquille financièrement et/ou connait suffisamment).
Il ne faut pas faire de certains cas (toi, moi) un cas général et critiquer les choix des autres suivant ses critères 'en oubliant qu'ils ne s'appliquent pas à tous).
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par zebra3 . Évalué à 2.
Je ne pense pas avoir fait de cas général.
Je n'ai fait que proposer une solution qui me semblait correspondre au besoin de l'auteur du journal (la confidentialité).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Zenitram (site web personnel) . Évalué à 3.
Vu la teneur du journal, je suppute que la confidentialité est importante, mais dans sa recherche de logiciel utilisable pour son besoin. La meilleure confidentialité et utilisabilité est un ordinateur éteint, mais ne répond pas forcément au besoin ;-).
# Git ?
Posté par Ely . Évalué à 0.
Personnellement j'utilise un repo git en guise de dropbox. Je sais ce que vous allez dire : "mais cépafépoursa". N'empêche que :
bien que mes fichiers ne soient pas du "code" et que je sois seul sur le "projet", cela reste toujours très utile.
En plus, il existe même des GUI permettant directement de commit/update depuis l'explorateur de fichier, alors pourquoi se priver :) .
[^] # Re: Git ?
Posté par rakoo (site web personnel) . Évalué à 1.
Si tu as des fichiers volumineux, pour lesquels git n'est pas adapté, je te conseille de regarder bup, qui combine le stockage haut-niveau de git avec la déduplication bas-niveau de rsync. Un concept vraiment joli.
[^] # Re: Git ?
Posté par claudex . Évalué à 3.
Ce qui m'intéresse avec Dropbox, c'est que c'est fait automatiquement, ça évite d'oublier quand on change de PC.
« 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
# retour d'expérience
Posté par i M@N (site web personnel) . Évalué à 1. Dernière modification le 05 mai 2013 à 20:24.
le concept est intéressant, le gros souci c'est que c'est en beta et que c'est jusqu'à preuve du contraire foireux!
Comme j'expliquais plus haut j'ai testé et tous les fichiers ne sont pas synchronisés comme prévu (il en manque en gros 10%), bien que j'ai relancé de mon côté et fait relancer à l'autre bout btsync.
Conclusion : solution pas fiable, exit, retour au FTP.
Dommage. :-/
wind0w$ suxX, GNU/Linux roxX!
# cloud et P2P pour video surveillance
Posté par P2P_cloud . Évalué à -1.
Good morning Mrs,
I am first year PhD student, my dissertation topic entitled " Amélioration de la qualité de service pour un système de vidéo surveillance en utilisant conjointement un cloud computing et une architecture Peer to Peer"
j'ai vu dans un article qu'il utilise HDFS (hadoop file system) pour construire cette architecture (pour video surveillance). Alors ma question existe t'il d'autre file system comme hdfs mais qui se base sur un reseau P2P structuré (DHT). Si non , pourriez vous me donner quqes idées qui pourra m'aider dans ma recherche. MErci
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.