Syncany, une alternative libre à Dropbox avec bien plus de fonctionnalités

Posté par . Modéré par patrick_g. Licence CC by-sa
45
30
mai
2011
Internet

Après Dropbox et Sparkleshare, Syncany est une nouvelle application de synchronisation de données « au fil de l’eau » entre plusieurs machines. Ses points forts : logiciel libre et indépendance du service de stockage sous‐jacent, grâce à un système de greffons.

Syncany est écrit en Java et est hébergé sur Launchpad. Le projet est encore jeune, mais très prometteur.

Vous connaissez peut‐être le service Dropbox, qui vous permet de garder des répertoires synchronisés entre plusieurs machines ? Bien que très pratique, ce système souffre de plusieurs défauts :

  • propriétaire ;
  • dépendant d’une seule entreprise pour le stockage ;
  • pas très sûr, comme de récentes informations l’ont montré.

Un projet libre du même type existe : c’est Sparkleshare, dont on avait récemment parlé sur LinuxFr.

Mais un autre projet libre commence à faire parler de lui : Syncany. Son point fort est que les systèmes de stockages sont fournis par des greffons, ce qui le rend extrêmement souple et adaptable à l’hébergement dont vous disposez. Sont actuellement pris en charge :

  • répertoire local ;
  • FTP ;
  • IMAP : les données sont stockées comme des pièces attachées ;
  • Google Storage ;
  • Amazon S3 ;
  • Rackspace Cloud Files ;
  • WebDAV ;
  • Picasa Web Albums : les données sont encodées dans des images (!) ;
  • partage Windows ;
  • Box.net ;
  • SFTP.

Sur le plan technique, Syncany est écrit en Java et est encore instable. Les fichiers locaux sont découpés en tronçons dont on choisit la taille et qui sont chiffrés (AES ou 3DES) avec une clef choisie par l’utilisateur avant d’être transmis. La synchronisation ne se fait que sur les tronçons modifiés.

Pour le moment, il n’y a pas encore de binaires, et seule une version GNU/Linux est disponible (de l’aide est demandée pour les portages Windows et Mac). Il y a tout ce qu’il faut pour l’intégration à Nautilus et à la zone de notification de GNOME (pas d’infos pour KDE pour l’instant).

  • # Autre projet sympa

    Posté par . Évalué à -3.

    J'en profite pour glisser un petit lien sur un autre projet que je trouve intéressant : WUALA

    En particulier, la fonction "troc": Cette option permet d'échanger de l'espace local contre de l'espace en ligne, moyennant un temps minimal de connexion (17% du temps, actuellement).

    Il n'y a pas de mauvais outils, il n'y a que de mauvais ouvriers

    • [^] # Re: Autre projet sympa

      Posté par . Évalué à 8.

      Pas libre du tout celui là.

      Please do not feed the trolls

      • [^] # Re: Autre projet sympa

        Posté par . Évalué à 1.

        Basé sur des technologies opensource: http://www.wuala.com/en/learn/technology

        En tout cas, je l'utilise est c'est efficace mais surtout c'est décentralisé grace a du p2p.

        ...et je ne comprent pas que tout ce petit monde qui fait du libre continue a penser centralisé (pour le social:diaspora, movim, elgg -alors que des trucs comme peerscape existent- ou pour le stockage avec ce projet).

        A quand la meme chose en p2p?

        • [^] # Re: Autre projet sympa

          Posté par (page perso) . Évalué à 4.

          en P2P ca existe déjà http://tahoe-lafs.org/trac/tahoe-lafs et ca doit marcher pas mal puisqu'une boite l'utilise http://www.jtek.fr/news/2011/04/18/technologies-de-sauvegarde-chez-jtek/

          • [^] # Re: Autre projet sympa

            Posté par . Évalué à 2.

            Merci je ne connaissais pas. Ca à l'air interessant, mais dommage qu'on ne puisse pas partager de l'espace disque avec d'autre utilisateurs comme avec wuala.

            Avec wuala je laisse une partition en accès et des données (chiffrées) des autres utilisateurs y sont stockée. En échange je gagne environ 10Go de stockage chez les autres. Pas besoin de serveurs. Chaque PC allumé devient un serveur, pas besoin d'hébergeurs. J'ai pas l'impression que Tahoe-LAFS fonctionne de cette façon.

            • [^] # Re: Autre projet sympa

              Posté par (page perso) . Évalué à 5.

              En échange je gagne environ 10Go de stockage chez les autres. Pas besoin de serveurs. Chaque PC allumé devient un serveur, pas besoin d'hébergeurs

              Moui. J'espère quand même qu'il y a une copie sur un vrai serveur pour le cas où les machines qui stockent tes données sont éteintes, hors ligne, ou déjà trop sollicitées (la plupart des machines perso, elles sont derrière un ADSL avec une BP montante ridicule).

              Mais j'avoue cependant que l'idée d'une plateforme P2P est intéressante d'un point de vue technique. En tout cas, ça parait plus innovant que de blablater en permanence sur le « cloud » quand tout ce que veut dire apparemment ce mot, c'est « on vous loue de l'espace de stockage sur nos serveurs » : quelle révolution, mes aïeux ! :-/

              Envoyé depuis mon PDP 11/70

              • [^] # Re: Autre projet sympa

                Posté par . Évalué à 1.

                Tout dépend du nombre de machines perso avec un BP ridicule. C'est le principe du P2P non?
                D'accord avec toi sur le deuxieme point. Meme plus qu'innovant, révolutionnaire!

            • [^] # Re: Autre projet sympa

              Posté par . Évalué à 1.

              Une fonction qui serait sympa, ce serait de pouvoir "donner" un fichier aux gens qui l'hébergent, en leur envoyant ce qu'il faut pour déchiffrer. Juste ce fichier là.

              Ce serait une espèce de grand disque dur global où chacun aurait ses données persos, et des données publiques.

              THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # fonctionnalités

    Posté par . Évalué à 1.

    Je n'ai pas compris si cet outil surveille tout seul les répertoires qu'on lui a indiqué, et qu'il les synchronise dès qu'une modification est détectée, ou si il faut synchroniser "à la main".
    Je cherche un outil de back-up qui permette de faire cela : surveillance automatique des fichiers modifiés, synchro sur FTP ou via upload HTTP, client Win et Linux, chiffrage des données.

  • # Intérêt ?

    Posté par (page perso) . Évalué à -6.

    Je ne vois pas trop l'intérêt d'une solution de ce type par rapport à un simple partage NFS par exemple, quelqu'un peu m'éclairer ?

    There is no spoon...

    • [^] # Re: Intérêt ?

      Posté par . Évalué à 2.

      Synchro au fil de l'eau (asynchrone donc). Tu as une copie en local et sur un serveur distant. Tu installe autant de client que tu veux qui se synchro tous ensemble

    • [^] # Re: Intérêt ?

      Posté par (page perso) . Évalué à 5.

      Les données sont synchronisées en local de manière automatique. C'est plus performant, et bien plus pratique quand on a pas accès au net. Ça prends plus de place par contre…

      Et t'as des notifications à la growl qui préviennent quand un fichier change, c'est trop la classe.

      Envoyé depuis mon lapin.

    • [^] # Re: Intérêt ?

      Posté par . Évalué à 4.

      • [^] # Re: Intérêt ?

        Posté par (page perso) . Évalué à 3.

        Ha ! Excellent !
        Je n'avais pas vu. Effectivement, j'aurais voulu la faire volontairement, j'aurais pas fait mieux ;).

        There is no spoon...

    • [^] # Re: Intérêt ?

      Posté par . Évalué à 2.

      Pour plébisciter Wuala (qui est propriétaire de mémoire, mais j'utilise alors bon,mais j'ai pas de ...)
      j'ai un répertoire "synchronisé" entre 2 postes, un windows au bureau et un linux a la maison. Dans ce contexte de partage au lieux d'un share de type NFS je devrait plutôt utiliser un sshfs mais ça marcherait, ça eut marché, j'ai fait.
      Par contre le répertoire en question est surtout local des 2 côté donc si je suis offline j'ai quand même accès aux données qui ont eut le temps d'arriver.
      après pour la syncho arrière... je n'ai pas regardé... je suis en single user donc je "sais" approximativement ce que je fais.

      Le soucis de Wuala, c'est qu'ils risquent de se retrouver comme dropbox à propos des données.

      • [^] # Re: Intérêt ?

        Posté par (page perso) . Évalué à 4.

        Ok je vois. Effectivement, il n'y a pas de copie locale avec du NFS, donc plus rien si offline.

        Merci ;)

        There is no spoon...

        • [^] # Re: Intérêt ?

          Posté par . Évalué à 2.

          Ce qui te permet, par exemple avec ton mobile, de synchroniser en wifi mais pas en 3g si tu as 2Gio dans ton dossier partagé et une limite download inférieure... Ou la première fois en wifi (pour prendre les 2Gio) et ensuite c'est égal si les changement sont pas trop important.

  • # Standardisation des protocoles de synchronisation ?

    Posté par . Évalué à 10.

    Entre SparkleShare, UbuntuOne, WUALA, Box.net, et les dizaines d'autres projets, open source ou non, vapoware ou non qui sont apparus durant ces dernières années, tous tentant de surfer sur le succès de DropBox, j'en viens à me demander si ça ne serait pas une meilleure idée de définir des protocoles une bonne fois pour toute.

    Un des gros attraits de DropBox est justement qu'il y a des clients disponibles (et fonctionnels, et assez léchés) sur la majorité des architectures utilisées, y compris le web et les smartphones. A chaque fois qu'un nouveau projet veut réinventer tout ce que DropBox fait, il se retrouve toujours devant ce boulot monstrueux à accomplir, comme si mettre en place le système de synchro n'était pas déjà assez délicat.

    Standardiser une bonne fois pour toute les protocoles utilisés lors des synchro, même si cela demanderait un travail non-négligeable (vu la quantité d'applications imaginables au principe de base) et de bien travailler sur l'extensibilité du protocole, permettrait à n'importe qui d'aller utiliser un nouveau client ou serveur de synchro, sans avoir à se demander si oui ou non il y aura un moyen d'accéder à ses fichier en passant par son Android. Et a priori, il n'y a pas de raison que Dropbox s'oppose à l'idée, leur business model me semble tout à fait compatible avec un protocole standard (vu que ce qu'ils vendent c'est vraiment l'accès à un serveur de synchro de qualité).

    • [^] # Re: Standardisation des protocoles de synchronisation ?

      Posté par . Évalué à 2.

      Un standard est une évidence ;) en attendant synancy réutilise le client libre de dropbox pour nautilus

    • [^] # Re: Standardisation des protocoles de synchronisation ?

      Posté par . Évalué à -3.

      Ben là justement je suis pas d’accord :
      Le standard, ou la norme, va brider la créativité sur les algorithmes de synchronisation.
      Autant refaire la roue, sinon on copie et là...

    • [^] # Re: Standardisation des protocoles de synchronisation ?

      Posté par . Évalué à 10.

      On pourrait l’appeler Remote SYNChronisation par exemple.

      Plus sérieusement, les technologies existent déjà depuis 30 voir 40 ans, le problème c'est juste de vendre un truc madame Michu complient.

      De toute façon, propriétaire ou libre, le problème de la centralisation des données reste entier. Si on veut un plein contrôle sur ses données on ne peut pas faire l'économie d'avoir son propre serveur, ou mutualiser l'espace disque et la bande passante avec un système en P2P par exemple, une sorte de mélange entre Gluster et bittorent.

      Please do not feed the trolls

      • [^] # Re: Standardisation des protocoles de synchronisation ?

        Posté par . Évalué à 0.

        Ben voilà, j'avais pas lu les commentaires jusqu'au bout, mais ton truc P2P avec espace disque partagé avec d'autres ca existe, c'est basé sur du libre et ca s'appelle wuala (racheté par lacie).

        Entierrement d'accord avec toi, le probleme c'est la centralisation alors faisons un pas de coté. On n'a pas besoin d'hébergeur, on a tous un serveur à la maison et le P2P permet la persistance des données.

        • [^] # Re: Standardisation des protocoles de synchronisation ?

          Posté par . Évalué à 4.

          "basé sur du libre" ça veut dire privateur, le problème des logiciels privateur c'est qu'il suffit d'une seule ligne de code (même sur des millions) pour ouvrir une porte dérobée par exemple.
          De plus, il me semble que Wuala n'est que semi-décentralisé (quid du "Qu'est ce qui arrive au données si demain Lacie décide que Wuala n'est pas rentable ?")

          Bref ! Vivement les petits serveurs ARM (ou autre) qui consommeront 2 Watt et couterons moins de 50€ à l'achat.

          Please do not feed the trolls

          • [^] # Re: Standardisation des protocoles de synchronisation ?

            Posté par (page perso) . Évalué à 2.

            Bref ! Vivement les petits serveurs ARM (ou autre) qui consommeront 2 Watt et couterons moins de 50€ à l'achat.

            mais le stockage consommera beaucoup plus que 2 watts

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

            • [^] # Re: Standardisation des protocoles de synchronisation ?

              Posté par (page perso) . Évalué à -2.

              Ben ça dépend : la mémoire flash, ça consomme plutôt pas grand chose. Et si le débit a besoin d'être un peu couillu, il y a les SSD...

              There is no spoon...

            • [^] # Re: Standardisation des protocoles de synchronisation ?

              Posté par (page perso) . Évalué à 1.

              mais le stockage consommera beaucoup plus que 2 watts

              C'est clair j'ai un petit serveur maison a base d'atom ce qui chauffe le plus (rien n'est ventilé donc c'est assez facile de comparer) c'est de très loin le disque dur. et en plus c'est le plus gros, donc en terme de conso énergétique c'est bien lui le pire...

            • [^] # Re: Standardisation des protocoles de synchronisation ?

              Posté par . Évalué à -1.

              J'ai un Eeepc 700 sous xubuntu utilisé en stockage. Backintime me permet d'y sauvegarder mes données importantes de facon incrémentale. Il me sert aussi de serveur de musique avec Subsonic, j'ai la musique partout dans la maison en wifi sur un HTC que je branche sur l'ampli que je veux.

              Il se met en veille seul quand il n'est pas utilisé, les disques usb aussi.

              Consommation mesurée avec disque en veille et ecran eteint: 8W
              0W si inutilisé.

              J'aime bien l'idée des petits serveurs, mais franchement avec un systeme comme wuala ce n'est pas nécessaire.

          • [^] # Re: Standardisation des protocoles de synchronisation ?

            Posté par . Évalué à 0.

            Attention je ne fais pas la promo de wuala, je dis juste que ce serait plus que bien d'avoir quelque chose basé sur le meme principe en libre.

            Et en effet c'est semi-décentralisé, ils ont des serveurs pour ceux qui achetent de la place, au lieu de troquer. Mais rien n'empéche de développer un truc similaire décentralisé avec uniquement du troc et là on aura vraiment un stockage sûr à tous les niveaux. Vu la taille actuelle des disque je ne vois pas de probleme a partager une partition de 100Go pour bénéficier d'environ 50Go de stockage en ligne.

            Un vieux projet de reseau social nommé peerscape fonctionne sur le meme principe, et ce serait à mon avis une bien meilleure solution que les diaspora ou autres.

        • [^] # Re: Standardisation des protocoles de synchronisation ?

          Posté par . Évalué à 1.

          Entierrement d'accord avec toi, le probleme c'est la centralisation alors faisons un pas de coté. On n'a pas besoin d'hébergeur, on a tous un serveur à la maison et le P2P permet la persistance des données.

          sauf que :

          1) je n'ai pas envie de laisser tourner ma machine chez moi 100% du temps alors
          qu'elle va servir 20% du temps ... si tout le monde fait ça on explose les besoins
          de ressources en énergie pour pas grand chose ...

          2) je n'ai pas nécessairement envie de voir mes données perso sur d'autres machines,
          donc le p2P, bof ...

          • [^] # Re: Standardisation des protocoles de synchronisation ?

            Posté par (page perso) . Évalué à 2.

            Le mardi 31 mai 2011 à 16:07 +0200, Christophe Turbout a écrit :
            > 2) je n'ai pas nécessairement envie de voir mes données perso sur
            > d'autres
            > machines,

            c'est le meme probleme avec DropBox ou autre.

          • [^] # Re: Standardisation des protocoles de synchronisation ?

            Posté par . Évalué à 3.

            1) je n'ai pas envie de laisser tourner ma machine chez moi 100% du temps alors
            qu'elle va servir 20% du temps ... si tout le monde fait ça on explose les besoins
            de ressources en énergie pour pas grand chose ...

            Mon serveur maison est un atom 1.6GHz (Aspire Revo 3600 version Packard Bell, acheté 100€) : conso constatée < 25W/h (http://www.vimeo.com/4793492) : sachant que la carte graphique ne sert quasiment à rien dans mon cas, je dois être bien en dessous de ça (disons 20W). Si on part sur la base d'un abonnement EDF de 6kW, ça nous fait le kW/h à 0.1152€ (http://bleuciel.edf.com/abonnement-et-contrat/les-prix/les-prix-de-l-electricite/tarif-bleu-47798.html#acc52401)

            (0,1152 / 1000) * 20 * 24 * 365 = 20,18€/an. En passant on peut constater que le W/an vaut environ 1€, pratique pour ce genre de calcul.

            Pour conclure, 20€ de plus par an, j'appelle pas ça exploser les besoins énergétiques.

            • [^] # Re: Standardisation des protocoles de synchronisation ?

              Posté par . Évalué à 2.

              Le monsieur a dit "besoin énergétique", pas "facture d'énergie".

              Et un coût n'est pas obligatoirement financier. Quel sera le coût environnemental si 25 millions de foyers laissent fonctionner un "Aspire Revo 3600" 24/7 ?

              • [^] # Re: Standardisation des protocoles de synchronisation ?

                Posté par (page perso) . Évalué à 5.

                Alors très simplement :

                Pour une personne, ça fait environ 175kWh/an.
                Pour 25M de personnes, ça fait 4TWh/an.
                Sachant que la centrale de Civaux (juste à côté de chez moi), a fourni pour 2008 (selon Wikipedia) 21 milliards de kWh, on peut considérer donc que la production est de 21TWh/an.

                Ça représenterait donc un poil plus d'1/5 de la production de cette centrale, qui possède 2 réacteurs, sur les 58 dont nous sommes équipés en France.

                Or, toujours selon Wikipédia, la production de 2008 de ces 2 réacteurs représentait 4,4% de la production nationale...

                Autrement dit : si 25 millions de foyers faisaient tourner un "Aspire Revo 3600" 24/7, ben ça serait peau-de-zob.

                CQFD

                There is no spoon...

                • [^] # Re: Standardisation des protocoles de synchronisation ?

                  Posté par . Évalué à 7.

                  Le truc c'est qu'en considérant toujours que c'est "peau de zob" on ne fait jamais d'effort, on change pas les mentalités et on devient des gorets de la consommation électrique ;-)

                  • [^] # Re: Standardisation des protocoles de synchronisation ?

                    Posté par . Évalué à 1.

                    Le fait de chercher à consommer le minimum pour ses besoins est déjà un acte écologique en soi, ne pas le faire serait ne pas faire d'effort.
                    Quid de la consommation d'un serveur externe commercial, est-ce facilement quantifiable ou vérifiable ?

                  • [^] # Re: Standardisation des protocoles de synchronisation ?

                    Posté par . Évalué à 0.

                    Tu peux largement compenser cette peau de zob en plus en achetant un chouette frigo A++audelàdesétoiles et un chauffe-eau de science-fiction.

                  • [^] # Re: Standardisation des protocoles de synchronisation ?

                    Posté par (page perso) . Évalué à 2.

                    Tout à fait.

                    Et c'est pour cela que je préférerais largement 25 millions de "Aspire Revo 3600" aux fermes de serveurs de Google et consorts, pour le côté écologique rapport à la conso électrique, mais aussi pour le côté éthique (Internet VS Minitel 2.0).

                    C'est d'ailleurs pour cette raison que j'ai un VIA C7 chez moi qui héberge mes services : Web, Stream audio, Jabber, Data (NFS), Versioning (Subversion, que je risque remplacer par Mercurial ou GIT, j'hésite encore :D) et Mail (quand j'aurais fini de tout configurer :p)

                    There is no spoon...

                    • [^] # Re: Standardisation des protocoles de synchronisation ?

                      Posté par (page perso) . Évalué à 0.

                      Git, sinon rien :)

                      • [^] # Re: Standardisation des protocoles de synchronisation ?

                        Posté par (page perso) . Évalué à 2.

                        Ben j'étais parti sur cette idée au départ. Non pas que je sois mécontent de SVN, mais j'avais envie de tester autre chose.

                        Mais avec le débat qui fait rage un peu plus bas, j'ai testé rapidement Mercurial hier soir et c'est plutôt pas mal. Simplissime et efficace.
                        Par contre, étant habitué à SVN, l'aspect standalone de Mercurial est un peu déroutant. J'ai pas trouvé d'équivalent au checkout de SVN par exemple. Certes il y a "hg update", mais il faut initier le projet en local d'abord. Bref, c'est différent quoi. :)

                        De plus, bien que le serveur soit archi simple à mettre en œuvre ($ hg serve) il ne permet que de distribuer et pas la multi-contribution en push, du moins pas en faisant simplement un "hg serve". J'ai regardé un peu la doc et du coup je trouve que ça fait un poil plus bidouille que le reste en donnant le sentiment que c'est un aspect qui a été pensé après coup.

                        Mais ce n'est que mon avis, sur 1h de test rapidos.

                        There is no spoon...

              • [^] # Re: Standardisation des protocoles de synchronisation ?

                Posté par . Évalué à 2.

                Pour un usage personnel, un serveur n'a pas besoin de rester totalement opérationnel 24/7. Il peut très bien dormir entre deux requêtes. Un pc en veille mets 2 à 4 secondes pour se réveiller. C'est encore un temps acceptables pour une première requête. Il peut ensuite rester éveiller 5 minutes le temps de répondre aux requêtes suivantes et retourner à l'état de pied d'étagère (vécu) ensuite.

          • [^] # Re: Standardisation des protocoles de synchronisation ?

            Posté par . Évalué à 0.

            1: Justement, pas besoin de laisser tourner la machine. C'est là tout le savoir faire de wuala. Il y a des documents sur le net présentant l'algo: http://www.youtube.com/watch?v=3xKZ4KGkQY8. Le concept, c'est de répliquer les données un nombre de fois suffisant pour que quoi qu'il arrive elles soient toujours disponibles (sur le nombre de pc les contenant, il y en aura toujours au moins un allumé)

            2: Les données sont coupées en paquets, les paquets sont chiffrés avant d'être émis. Rien ne permet de dire que quelqu'un possède l'ensemble des paquets correspondants à un fichier complet.

            Donc le P2P de mon point de vue c'est le meilleur moyen de ne plus être centralisé :)

            • [^] # Re: Standardisation des protocoles de synchronisation ?

              Posté par . Évalué à 10.

              Donc le P2P de mon point de vue c'est le meilleur moyen de ne plus être centralisé :)

              Merci Captain Obvious !

              • [^] # Re: Standardisation des protocoles de synchronisation ?

                Posté par . Évalué à -2.

                Ben c'est à dire que ça n'a pas l'air Obvious pour tout le monde... puisque la majorités des projets que ce soit pour le stockage ou le social sont presque tous basés sur un hébergement, donc hyper centralisé.

                • [^] # Re: Standardisation des protocoles de synchronisation ?

                  Posté par (page perso) . Évalué à 1.

                  Ce qui est évident, c'est que le P2P est décentralisé. Ce qui est autrement plus évident, c'est que ça n'a pas d'intérêt pour un acteur qui se veut majeur et contrôler son outil.

                  Ceci dit, FB a laissé un projet P2P sur le chemin de sa croissance. PAs pour des raisons techniques, mais plutôt une crainte de la part du créateur de Napster qui n'avait pas envie de revivre les joies des procès avec la RIAA.

      • [^] # Re: Standardisation des protocoles de synchronisation ?

        Posté par . Évalué à 4.

        Je pensais que rsync était un logiciel conçu pour la synchronisation asymétrique. Le protocole utilisé permet-il de faire des synchronisations entre deux (ou plus) clients, dans les deux sens et en même temps (à compter que ça ne soit pas le même fichier qui soit envoyé des deux cotés à la fois, évidemment) ?

        Les seules utilisations que j'ai pu faire de rsync se résumaient à donner l'ordre de backup et d'attendre un bon moment le moindre début d'envoi de la diff, donc j'ai un peu de mal à voir ce que le protocole permet.

        Mais si c'est effectivement possible d'utiliser le protocole pour faire la synchro en background et bidirectionnellement, alors pourquoi pas, effectivement...

        • [^] # Re: Standardisation des protocoles de synchronisation ?

          Posté par . Évalué à 0.

          Oui, c'est possible. Il est aussi possible de le configurer pour qu'il soit plus rapide. (par défaut il calcule le hash d'une foultitude de blocs des deux fichiers à synchroniser et ne synchronise que les blocs dont les hash. (il peut se contenter de regarder les dates et les tailles des fichiers)

          après, je ne sais pas comment il gère (si il gère) d'éventuelles modifications sur les fichiers en cours de synchronisation par exemple.

          Please do not feed the trolls

    • [^] # Re: Standardisation des protocoles de synchronisation ?

      Posté par . Évalué à 1.

      WebDAV ? on a de base toute la gestion de répertoires avec des fichiers, mais également des collections d'objets (il n'est pas nécessaire de mapper les urls sur des fichiers après tout), donc on peut imaginer acceder à des base de musiques, de vidéos.
      Commes c'est de l'HTTP, ça passe partout, y compris à travers les proxys.
      Coté sécurité : HTTPS et tous les systèmes d'authentification et de session qui vont avec.
      Reste le pb de la synchro "à la rsync", cad avec juste le transfert du delta... Comme en HTTP on a déjà le GET d'un morceau de fichier via le header Range, on doit pouvoir reimplémenter l'algo de rsync.

  • # "Bien plus de fonctionnalités"

    Posté par . Évalué à 10.

    Je m'interroge sur le "bien plus de fonctionnalités".

    Dropbox a pas mal de fonctionnalités sympas, comme le fait de pouvoir rendre des fichiers publics (et zouu la jolie URL qu'on peut envoyer à ses amis), de pouvoir partager des dossiers avec le compte de quelqu'un d'autre, de pouvoir faire d'un dossier de photos une galerie web simple et fonctionnelle... (Je ne parlerai même pas de la possibilité d'avoir un client sur smartphone & cie, ça a déjà été dit, ni que le client Linux, natif, évite tout le bloat de la JVM : troller sur Java, c'est vraiment trop simple.)

    À part la tétrachiée de supports de stockages supportés (ce qui est très sympa, il faut bien l'avouer), quelles sont donc les "bien plus de fonctionnalités" de Syncany par rapport à Dropbox ou SparkleShare ?

  • # Ligne de commande ?

    Posté par (page perso) . Évalué à 6.

    Je suis probablement un vieux crouton, mais j'aime bien pouvoir utiliser les bonnes idées sur des machines sans interface graphique. Par exemple un serveur, une machine de sauvegarde, etc.

    Donc rsync. Mais c'est limité à ce que sait faire rsync.

  • # Sinon y'a iFolder

    Posté par (page perso) . Évalué à 1.

    http://www.ifolder.com/

    Et ça marche depuis un bout de temps...

    • [^] # Re: Sinon y'a iFolder

      Posté par (page perso) . Évalué à 10.

      c'est une boutade, mais quand même: pourquoi ce genre de truc est-il toujours écrit en Java ou en Mono (syncany, sparkleshare, ifolder)?

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Sinon y'a iFolder

        Posté par . Évalué à 1.

        Parce que leurs auteurs préfèrent java et/ou mono ?

        Autrement, reimplementer un système de surveillance des fichiers/répertoires, qui soit multiplateforme ca doit pas être de tout repos, alors autant prendre ce qui existe déjà (nio en l’occurrence).

        Mais si tu connais des apis multiplateforme pour python/ruby/php qui permettent de surveiller avec finesse le FS sous jacent sans faire de polling, je suis preneur.

        • [^] # Re: Sinon y'a iFolder

          Posté par (page perso) . Évalué à 3.

          Mais si tu connais des apis multiplateforme pour python/ruby/php qui permettent de surveiller avec finesse le FS sous jacent sans faire de polling, je suis preneur.

          Oui, Watchdog : http://packages.python.org/watchdog/index.html
          Plateformes supportées : http://packages.python.org/watchdog/installation.html#supported-platforms-and-caveats

        • [^] # Re: Sinon y'a iFolder

          Posté par (page perso) . Évalué à 4.

          C'était une boutade pour rappeler qu'on s'attend plutôt à un truc léger et discret, qui se fait oublier sur la machine quoi. Pour qu'on puisse l'installer partout: de la tour au portable en passant par le petit netbook, le téléphone multifonction, etc.
          Ce que fait Dropbox, en somme, dont le client Linux est écrit en C si je ne me trompe.

          Enfin ta dernière remarque me fait penser au développement de Git: alors que le changement de license de Bitkeeper était perçu comme une catastrophe et le développement d'un DVCS à la taille du noyau Linux comme pas "de tout repos" (pour reprendre ton expression), Linus est arrivé très rapidement avec une solution en C. Je veux dire par là qu'il ne faut pas baisser les bras et se rabattre sur la facilité.
          Pour l'instant on clone Dropbox à tout va (UbuntuOne (?), Sparkleshare, Syncany, Time Capsule, etc.) en essayant diverses solutions (peer to peer, jabber, dépot git, etc.), mais viendra un moment pour imaginer "un système de surveillance des fichiers/répertoires, qui soit multiplateforme".

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Sinon y'a iFolder

            Posté par . Évalué à 2.

            Oui mais bon Linus est tres legerement special voir genial pour arriver a pondre un truc comme linus et git. Il y a peu etre d'autres developpeurs aussi fort voir plus que lui mais je n'en vois aucun qui a lui tout seul ait change autant l'informatique.

            • [^] # Re: Sinon y'a iFolder

              Posté par (page perso) . Évalué à 7.

              pour arriver a pondre un truc comme linus

              Sa mère devait être géniale !

            • [^] # Re: Sinon y'a iFolder

              Posté par (page perso) . Évalué à 4.

              Je crois plutôt que Linus ne s'est pas contenté de "ce qui est enseigné dans les écoles" (comme tu dis un peu plus bas). La différence est là. On a tous un cerveau, faut qu'il serve.

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Sinon y'a iFolder

            Posté par . Évalué à 4.

            Enfin ta dernière remarque me fait penser au développement de Git:
            ...
            mais viendra un moment pour imaginer "un système de surveillance des fichiers/répertoires, qui soit multiplateforme".

            Faut jamais avoir bataillé pour essayer d'utiliser Git et partager un repo sous Windows sans passer par cygwin pour affirmer ça.

            • [^] # Re: Sinon y'a iFolder

              Posté par . Évalué à -1.

              Enfin si git avait ete fait dans l'optique d'etre utiliser pour windows cela se saurait aussi... et puis c'est pas comme si le libre avait pas d'autre solution comme mercurial mais bon je peux totalement comprendre que lorsque l'on est habitue a git mercurial soit vraiment un deuxieme choix.

              Oups on est pas vendredi mais bon ceux qui auront essaye de mimer le comportement des branches avec mercurial comprendront je pense. Je dois avouer que la philosophie de mercurial ne me convient pas, faire un clone de tout le repository c'est un peu penible surtout si dans ton repository tu mets de gros fichiers de donnees. Avec le comportement par defaut de mercurial, tu utilises deux fois la place sur le disque et le pseudo comportement git est tout sauf simple a utiliser je trouve. En tout cas contre intuitif.

              • [^] # Re: Sinon y'a iFolder

                Posté par . Évalué à 5.

                Ah ben moi je préfère largement un hg branch et un hg resolve

                Je vois pas où est le pb ?

                Ca comparé à un git fetch/update/rebase/pull ... Plouf plouf
                ou encore les remote tracking ou pas, les staging area dont on se sert une fois tous les 15 ans alors qu'on veut juste commiter, les add --all alors qu'on veut toujours tout ajouter par défaut et autres options qu'il faut toujours rajouter pour obtenir le comportement "normal".

                L'option -m qu'il faut surtout pas oublier pour pas qu'il poireaute 2h avant de t'ouvrir un ugly vim par défaut.

                L'usine à gaz qu'il faut monter pour partager son repo en http lorsqu'on veut pas utiliser le protocole natif

                Le packing régulier sous peine de voir la taille de son repo exploser.
                Vive l'usine à gaz

                Les hooks qui passent leur temps à forker des process au lieu de prévoir des appels de fonction dans des processus legers (Vive python)

                Les supers perfs qui font qu'il faille 10 mn pour "cloner" un repo de 8 Mo parce qu'il s'amuse à examiner/compresser les objets un par un au lieu d'envoyer tout d'un bloc (ben ouais git-upload-pack sait faire que ça). Essayez le repo de jgit pour rire.

                Git taillé pour les perfs ....Mouarf !

                Plus je l'utilise plus j'ai l'impression qu'ils ont copié Clearcase en plus lourd et moins fini.

                Hg au moins ca marche out of the box vite et bien.

                J'espère que le kernel est moins fait à l'arrache et plus consistant mais les propos de Linus lui-même sur son embonpoint ne me rassurent pas.

                T'es sûr pour Vendredi ?

                • [^] # Re: Sinon y'a iFolder

                  Posté par (page perso) . Évalué à 1.

                  autres options qu'il faut toujours rajouter pour obtenir le comportement "normal".

                  Tu es au courant pour les alias?

                  L'option -m qu'il faut surtout pas oublier pour pas qu'il poireaute 2h avant de t'ouvrir un ugly vim par défaut.

                  Chez moi, ça s'ouvre instantanément. Et mon vim est très joli.

                  L'usine à gaz qu'il faut monter pour partager son repo en http lorsqu'on veut pas utiliser le protocole natif

                  Webdav, ce n'est pas non plus la mort

                  « 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: Sinon y'a iFolder

                    Posté par . Évalué à 2.

                    Tu es au courant pour les alias?

                    Oui et toi tu sais ce que signifie "out of the box"
                    Et les alias ca marche dans Egit ?

                    Chez moi, ça s'ouvre instantanément. Et mon vim est très joli.

                    Mon hg m'ouvre un beau Notepad.
                    Mais bon je vais plutôt te répondre que mon FF déchire sa race sous mon W$.

                    Webdav, ce n'est pas non plus la mort
                    hg serve

                    "Hé Coco tu peux y aller depuis chez toi ?"

                    • [^] # Re: Sinon y'a iFolder

                      Posté par . Évalué à 2.

                      Ca se configure l'editeur par defaut et de tout de facon ce que tu me dis ne reponds pas a ma problematique de la place disque. La facon de faire de mercurial avec les branches est, pour moi, non intuitives. Devoir faire un clone pour tester un truc c'est carrement penible.

                      Tes 10mn pour cloner un repo de 8meg m'etonne un tout petit peu. Certains de mes repos sont de l'ordre de plusieurs Giga et j'ai pas de probleme (heureusement)...

                    • [^] # Re: Sinon y'a iFolder

                      Posté par . Évalué à 1.

                      Au fait si tu te sers de Egit je vois pas trop comment tu as le probleme de vim...

                      Putain applique toi quand tu trolls, la cela se voit trop :)

                      • [^] # Re: Sinon y'a iFolder

                        Posté par . Évalué à 2.

                        Ben facile !

                        Avec Egit tu peux pas partager ton repo même en lecture.
                        msysgit ou git/cygwin obligatoire ou workflow centralisé

                        • [^] # Re: Sinon y'a iFolder

                          Posté par . Évalué à 2.

                          Donc tu es en train de dire que git c'est de la merde parcque que Egit en est a la version 0.12 et tres loin d'avoir implementer l'ensemble de git/C?

                          C'est une facon de juger git/C, je ne suis pas sur que cela soit la meilleur.

                          • [^] # Re: Sinon y'a iFolder

                            Posté par . Évalué à 3.

                            Oh je ne crois pas, EGit n'est qu'un des pb et je t'en ai cité un paquet d'autres.
                            Je t'ai juste expliqué que pour pouvoir faire le moindre truc avec Egit en distribué, tu as de toute facon besoin de git qui est archimerdique sous Windows.

                            Mais je sais ce n'est pas ton pb.

                            Tant mieux, on passera sous Hg dans ma boîte comme ça.

                            • [^] # Re: Sinon y'a iFolder

                              Posté par (page perso) . Évalué à 2.

                              Tant mieux, on passera sous Hg dans ma boîte comme ça.

                              d'accord !

                            • [^] # Re: Sinon y'a iFolder

                              Posté par . Évalué à 2.

                              Comme ca tu seras content. Tu auras montre avec "objectivite" que git etait une merde sans nom. Cool.

                              Le truc rigolo dans cette histoire c'est que ce soit git qui soit considere comme de la merde alors que tu veux t'en servir sur la plateforme pour laquelle il n'est quasiment pas maintenu, c'est curieux ca... Ce logiciel qui a ete fait pour linux et dont les besoins et evolutions sont decide pour et quasiment uniquement pour Linus et linux (qu'il soit utilisable pour autre chose c'est presque un coup de pot). si en plus on rajoute le fait que tu veuilles utiliser une implementation non fini cela n'arrange pas les choses.

                              Heureusement moi je m'en sert sous linux sans aucun probleme et mes collegues sous mac n'ont eux aussi aucun probleme, de ce point de vue la je dirais que en realite la merde c'est windows mais bon ca on le savait deja...

                              • [^] # Re: Sinon y'a iFolder

                                Posté par . Évalué à 3.

                                Le truc rigolo dans cette histoire c'est que ce soit git qui soit considere comme de la merde alors que tu veux t'en servir sur la plateforme pour laquelle il n'est quasiment pas maintenu, c'est curieux ca...

                                Tu trouve rigolo que la portabilité soit si mal considérée ? Que ce soit git, pulseaudio, systemd, dbus,... Ils sont tous centrés GNU/Linux et font un gris fuck au reste du monde. C'est exactement la même chose que tout les logiciels Windows ou Mac pur.

                                Je préfère un logiciel qui ne me fait pas le café (parce que de tout manière ma cafetière le fait mieux), mais du tout terrain que je peux proposer à mes amis sous Windows/Mac/autre, qu'un logiciel dont je n'utilise pas 90% des fonctionnalités (qui sont bien tout de même).

                                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                                • [^] # Re: Sinon y'a iFolder

                                  Posté par . Évalué à 1.

                                  Mais si des windowsiens veulent se mettre a developper la version windows un petit peu mieux ils seront bienvenus je suis sur. Mais n'exige pas que des personnes qui sont "tres legerement" plus interesse par l'ecosysteme linux/unix fasse ce boulot.

                                  • [^] # Re: Sinon y'a iFolder

                                    Posté par . Évalué à 3.

                                    Sans faire le portage eux même, ils peuvent documenter ce qu'ils font et où prévoir un portage et regrouper dans le code les parties spécifique à leur système. C'est aussi ça travailler sur la portabilité.

                                    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                                    • [^] # Re: Sinon y'a iFolder

                                      Posté par . Évalué à 0.

                                      Mais ils s'en foutent de la portabilite.

                                      Comme je l'ai deja dit git a ete fait pour linux et que cela soit utilisable pour d'autre projet c'est un coup de chance. Il n'y a aucune raison que les devs principaux de perdre du temps pour qu'il fonctionne sur un autre systeme.

                                      • [^] # Re: Sinon y'a iFolder

                                        Posté par . Évalué à 4.

                                        Alors il ne faut pas se plaindre d'avoir des drivers uniquement pour Windows, des sites optimisés pour IE, du matériel conçu pour des OS spécifiques.

                                        Ignorer la portabilité c'est enfermer ses utilisateurs sur une plateforme données. C'est exactement du même niveau que ce qui est fait autour de Windows (mais quand c'est pour Windows c'est mal et quand c'est pour linux c'est bien).

                                        Il y a une époque où j'appréciais GNU/Linux parce qu'il y avait ce souci de portabilité et de ne pas ignorer les minorités, je pensais que c'était du fait que linux est une minorité. Il semble soit que je me suis fourvoyé soit que la/les communautés ont évoluées.

                                        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                                        • [^] # Re: Sinon y'a iFolder

                                          Posté par . Évalué à 1.

                                          Tu es en train de dire que un binaire de driver est equivalent a logiciel libre?

                                          Si tu veux chacun son opinion.

                                          Que je sache git n'a pas ete fait pour faire chier les windowsiens mais il a ete fait pour aider les developpeurs de linux, je sais c'est subtile. Et si tu trouves si important que ca le port de git pour windows pourquoi ne fais tu pas le port ou pourquoi ne le sponsorise tu pas? Les devs actuels ne font rien contre windows, ils font pour linux.

                                          • [^] # Re: Sinon y'a iFolder

                                            Posté par . Évalué à 2.

                                            Tu es en train de dire que un binaire de driver est equivalent a logiciel libre?

                                            J'ai jamais dis ça. J'ai dis que le fait de ne pas prendre en compte la portabilité est une caractéristique qui est à combattre dans le logiciel libre comme dans les logiciels propriétaires et qu'il est bizarre de s'en offusquer dans un cas mais pas dans l'autre.

                                            Que je sache git n'a pas ete fait pour faire chier les windowsiens mais il a ete fait pour aider les developpeurs de linux, je sais c'est subtile.

                                            Tu crois vraiment qu'il y a beaucoup de logiciels propriétaire et/ou Windows qui ont était fait pour faire chier les linuxiens ?

                                            Et si tu trouves si important que ca le port de git pour windows pourquoi ne fais tu pas le port ou pourquoi ne le sponsorise tu pas?

                                            C'est la démarche que je trouve importante. Je vais pas me mettre à travailler et/ou financer tout les projets que j'aimerais voir devenir portable, pour la simple et bonne raison que je n'ai ni les capacités ni le portefeuille. Mais encore une fois c'est la démarche qui est mauvaise, dans l'absolu, je ne me sert ni de windows ni de git.

                                            Les devs actuels ne font rien contre windows, ils font pour linux.

                                            C'est foireux comme argument. Les développeurs de directX ne font rien contre linux, il font pour windows. Les constructeurs ne font rien contre linux, ils font pour windows.

                                            Je peux t'en sortir pleins des comme ça.

                                            Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                                            • [^] # Re: Sinon y'a iFolder

                                              Posté par . Évalué à 1.

                                              Tu crois vraiment qu'il y a beaucoup de logiciels propriétaire et/ou Windows qui ont était fait pour faire chier les linuxiens ?

                                              Ca tombe bien il n'y en a aucun qui fonctionne sous linux nativement (ie pas wine) et surtout strictement aucun d'une certaine boite de Redmond. Dans l'autre sens c'est plethore les exemples...

                                              • [^] # Re: Sinon y'a iFolder

                                                Posté par . Évalué à 6.

                                                Comme les autres font de la merde, il est normal d'en faire aussi ?

                                                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                                            • [^] # Re: Sinon y'a iFolder

                                              Posté par . Évalué à 0.

                                              C'est foireux comme argument. Les développeurs de directX ne font rien contre linux, il font pour windows. Les constructeurs ne font rien contre linux, ils font pour windows.

                                              Rien a voir mais alors tellement rien a voir que cela en est risible. On parle d'un DVCS, j'espere que tu as ecrit a microsoft pour te plaindre que aucun de leur outils pour developper ne soit pas multiplateforme. De plus, git fonctionne sous windows, ce qui ne fonctionne pas c'est Egit ou plutot cela fonctionne... pour une version incomplete.

                                              http://code.google.com/p/msysgit/

                                              Si j'ai bien compris, ce dont se plains le cancre c'est que la partie serveur se sert des outils present par defaut sur le systeme linux et non present sous windows par defaut (je pense a SSH en particulier). Parceque c'est la seule chose dont tu as besoin pour partager un repo.

                                              • [^] # Re: Sinon y'a iFolder

                                                Posté par . Évalué à 3.

                                                Je me fous de ce dont parle le Cancre Las, je dis qu'il y a une tendance à dénigrer la portabilité hors c'est une notion fondamentale.

                                                Et arrête de me citer tout les exemples de logiciels non portable de la planète parce que je m'en fou. C'est une qualité que j'aimerais voir préservée dans le logiciel libre.

                                                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                                                • [^] # Re: Sinon y'a iFolder

                                                  Posté par . Évalué à 0.

                                                  Ce que tu dis c'est que git ne fonctionne pas sous windows et tu as un lien qui te prouves que ce que tu dis est faux. Donc tes pleurs sont totalement non fondes.

                                            • [^] # Re: Sinon y'a iFolder

                                              Posté par (page perso) . Évalué à 1.

                                              Je pense que ce que veut dire Albert, c'est que bien que les développeurs de GIT n'assurent la compatibilité parfaite sur Windows, le fait que ce soit un logiciel libre permet à celui qui veut ET qui a les compétences et le temps, d'assurer ce portage.

                                              Or s'il est bien une chose que l'on peut reprocher à l'écosystème Windows et aux logiciels propriétaires, c'est bien ce point. Le fait qu'ils ne soient pas libres implique que même si quelqu'un veut et a le temps et les compétences, il ne pourra pas porter le logiciel (ou redistribuer le portage).
                                              Parfois c'est une volonté réelle de faire chier de la part du développeur/éditeur, ou d'enfermer les utilisateurs dans l'usage de son appli, parfois c'est simplement une conséquence malheureuse du closed-source sans intention réelle de bloquer le portage de la part du dev.

                                              C'est en ça je pense que l'on peut considérer que les dev de DirectX sont contre Linux alors que les dev de GIT ne sont (ou ne font pas) pour Windows.

                                              Après on ne peut décemment pas obliger quelqu'un à faire un développement ou un portage qui ne l'intéresse pas, surtout si il est bénévole. On pourra simplement le remercier de faire du libre pour permettre à d'autres de faire ce qu'il ne veut/ne peut pas faire.

                                              There is no spoon...

                                    • [^] # Re: Sinon y'a iFolder

                                      Posté par . Évalué à 2.

                                      Qu'ils s'en foutent on le sait, (et ca tombe bien les windosiens se contrefoutent des linuxiens en grande majorité).
                                      Faut juste pas affirmer que le multiplateforme va venir en citant en exemple Linus comme dans le post initial auquel j'ai répondu, alors que c'est tout le contraire.
                                      Git a été prévu pour tout sauf pour être "multi-plateforme"

                                      C'est juste un contresens !

                                      • [^] # Re: Sinon y'a iFolder

                                        Posté par . Évalué à 1.

                                        Que dalle: Git n'a pas ete prevu pour etre multiplateforme ce qui est tres legerement different de "sauf pour etre".

                                        Au passage il fonctionne tres bien sous Mac.

                  • [^] # Re: Sinon y'a iFolder

                    Posté par . Évalué à 1.

                    il est vrai que hg serve c'est le truc pas mal de mercurial mais comme je met generalement gitolite pour gerer les personnes pouvant faire tel ou tel truc sur mes repos, ce n'est pas un gros probleme pour moi.

                    • [^] # Re: Sinon y'a iFolder

                      Posté par . Évalué à 1.

                      Je me repond car cela peut interesser quelques personnes. Il y a un equivalent de hg serve pour git:

                      git instaweb

                • [^] # Re: Sinon y'a iFolder

                  Posté par (page perso) . Évalué à 3.

                  les staging area dont on se sert une fois tous les 15 ans

                  Personnellement ça doit me servir à peu près tous les jours...

                  add --all alors qu'on veut toujours tout ajouter par défaut

                  C'est pour moi une des choses les plus agréable avec GIT combiné avec le mode interactif. Au minimum une fois par jour je me retrouve à faire un patch que j'aurais comité d'un seul coup sous SVN alors que maintenant je le découpe en deux ou trois commit propres.

                  L'exemple typique c'est la correction d'un bug qui demande une petite modification d'API interne pour que la solution soit propre. Tu fais tout le boulot normalement avec les tests pour être sûr que ça marche et au moment de commiter, tu découpes en un premier commit qui fais le changement d'API et un deuxième qui corrige le bug.

                  Je ne répond pas au reste du troll... mais je me suis apperçu que la majorité des reproches que les gens font à GIT concerne généralement le fait que GIT est conçu pour avoir un dépôt propre avec des commits les plus atomiques possible et un historique bien organisé.
                  C'est sûr que pour un petit projet perso ça peu sembler contraignant, mais dès que le projet deviens un peu plus gros ça change la vie.

                • [^] # Re: Sinon y'a iFolder

                  Posté par (page perso) . Évalué à 1.

                  Commiter toutes les modifications d'un coup n'est jamais une bonne idée. J'ai vu beaucoup de bugs introduits comme ça, parce que le développeur qui a commité n'a pas regardé ce qu'il commitait. Personnellement, après avoir corrigé un bogue, je fais toujours un git diff avant d'ajouter un fichier dans le stagging area.

                  Si git ouvre vim et que tu n'utilise pas vim, ça veut dire que ton environnement est mal configuré. C'est ta faute. Si tu préfère qu'il ouvre eclipse, ben, tu peux.

                  Tu es au courant que cloner un répertoire c'est équivalent à un mkdir -p $dest && cp -arp .git $dest/ ?

                  builder@mickael:~$ time git clone http://egit.eclipse.org/jgit.git jgit
                  Cloning into jgit...
                  remote: Counting objects: 21832, done
                  remote: Finding sources: 100% (21832/21832)
                  Receiving objects: 100% (21832/21832), 8.16 MiB | 341 KiB/s, done.
                  remote: Total 21832 (delta 9509), reused 19260 (delta 9509)
                  Resolving deltas: 100% (9509/9509), done.
                  
                  real	1m4.630s
                  user	0m0.808s
                  sys	0m0.416s
                  builder@mickael:~$ time git clone  jgit jgit-clone
                  Cloning into jgit-clone...
                  done.
                  
                  real	0m0.268s
                  user	0m0.048s
                  sys	0m0.032s
                  

                  Elles sont où tes 10 min ?

                  • [^] # Re: Sinon y'a iFolder

                    Posté par . Évalué à 0.

                    Tu triches tu utilises pas windows... Apres certaines mauvaises langues pourraient suggerer que le probleme vient de windows mais naturellement ce n'est pas possible c'est un logiciel d'une entreprise qui a fait ses preuves pas comme ce truc d'amateur de git.

              • [^] # Re: Sinon y'a iFolder

                Posté par . Évalué à 2.

                faire un clone de tout le repository c'est un peu pénible surtout si dans ton repository tu mets de gros fichiers de donnees.

                Des gros fichiers de données avec des DVCS c'est de toute façon à éviter.
                Récupérer 300 versions d'un binaire pour n'accéder qu'à une seule c'est juste idiot.

                Les branches locales c'est le seule truc bien de Git mais quand on voit le reste je préfère encore cloner.
                En plus tu as une extension qui le gère
                http://mercurial.selenic.com/wiki/LocalbranchExtension

                • [^] # Re: Sinon y'a iFolder

                  Posté par . Évalué à 1.

                  C'est peut etre idiot mais quand le fichier de donne qui sert de test fait plusieurs Giga et que tu veux que tous les developpeurs puissent faire les memes test avec le meme fichier a jour c'est bien pratique.
                  Tes besoins ne sont pas les miens et clairement git me convient plus pour des raisons pratiques.

                  • [^] # Re: Sinon y'a iFolder

                    Posté par . Évalué à 2.

                    Donc tu prônes l'usage d'un outil qui n'oblige pas récupérer toutes les versions d'un binaire aka un VCS centralisé.

                    • [^] # Re: Sinon y'a iFolder

                      Posté par . Évalué à 2.

                      Je sais pas pour mercurial, mais avec git tu n'es pas obligé de tout récupérer (il y a une option du clone pour choisir la profondeur).

                      Versionner du binaire c'est moche mais ça n'a pas de rapport avec la centralisation ou non. Peut être que le mieux c'est d'avoir ce genre de gros fichiers accessibles via FTP/HTTP/NFS/... toujours avec la même url pour que tout le monde l'ai à jour ou avec la version dans l'URL.

                      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

          • [^] # Re: Sinon y'a iFolder

            Posté par . Évalué à 0.

            Linus y est arrive très rapidement lui, surement parce qu'il préfère le C a java :)

            Les développeurs C doivent sont de plus en plus rare en proportion et ça demande quand même plus de maitrise que de développer avec un langage de plus haut niveau. Maintenant on a tendance a privilégier la facilité de développement, portabilité, support du langage plutôt que les performances.

            Entre les deux je préfère encore un truc lent et gourmand mais qui fonctionne plutôt que appli prompte a planter...

            • [^] # Re: Sinon y'a iFolder

              Posté par . Évalué à 3.

              la bonne blague, tu vois, c'est que le truc lent et gourmand plantera tout autant, même si c'est pour d'autres raisons.

            • [^] # Re: Sinon y'a iFolder

              Posté par . Évalué à 3.

              Maintenant on a tendance a privilégier la facilité de développement, portabilité, support du langage plutôt que les performances.

              Et c'est pas un mal. La recherche de la performance ça entraîne du code régulièrement cryptique (parce que tu comprend il ne faut pas faire de deeep copy), complexe (parce que tu utilise des points hyper spécifiques liés à l'implémentation de l'OS que tu utilise : "je sais comment cet appel système est codé et je sais que si on fait ça il économise un test"), très difficile à maintenir (c'est difficile de garder le même niveau d'optimisation dans le temps) et moins fiable (on cherche un peu trop à économiser sur les tests).

              Ce n'est pas le cas de tout les logiciels ce n'est pas aussi dramatique mais c'est la direction que prend le code. Alors que la facilité de développement permet une bien plus grand maintenabilité et d'augmenter la base de développeurs potentiel, la portabilité ça consiste à ne pas enfermer ses utilisateurs sur une plateforme.

              D'ailleurs tu remarqueras que si tu fais du code pour la performance :

              • tu n'es pas portable parce que tu utilise des optimisations spécifiques à ton environnement
              • tu empêche tes utilisateurs de contribuer à un portage parce que le niveau requis pour cela est nettement plus élevé

              Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

              • [^] # Re: Sinon y'a iFolder

                Posté par (page perso) . Évalué à 1.

                • tu empêche tes utilisateurs de contribuer à un portage parce que le niveau requis pour cela est nettement plus élevé

                Non au pire tu ne facilite pas mais tu n'empêche pas. C'est comme si tu disais à un auteur qui écrit en français qu'il empêche les anglophones de le lire.

                • [^] # Re: Sinon y'a iFolder

                  Posté par . Évalué à 2.

                  Tu as raison.

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: Sinon y'a iFolder

          Posté par . Évalué à 1.

          Depuis quand les nio sont un système de surveillance des fichiers/répertoires multiplateforme ?

          D'ailleurs si tu connais une api multiplateforme Java qui permettent de surveiller avec finesse le FS sous jacent sans faire de polling, je suis preneur.

          • [^] # Re: Sinon y'a iFolder

            Posté par . Évalué à 1.

            Çe n'est pas la fonctionnalité principale, mais dans le package tu as tout ce qu'il faut pour faire ça relativement aisément (WatchService), sans avoir a te préoccuper des spécificités du filesystem. La lib fait des appels au fonctions native de l'os, et uniquement lorsqu'un système de notification n'est pas disponible, alors elle bascule en mode polling.

            • [^] # Re: Sinon y'a iFolder

              Posté par . Évalué à 2.

              Tu oublis surtout de dire que c'est les NIO2 donc Java 7.

              Si on est un peu plus objectif, on peut dire qu'il aura fallu attendre 2011 ou 2012 pour des possibilités super avancées telles qu'accéder aux attributs d'un fichier (owner, permissions), copier un fichier, gérer des path ou être notifié de changement sur le FS. Plutôt de d'affirmer que Java à une longueur d'avance dans le domaine.

              Dès que tu veux faire des choses systèmes triviales c'est souvent la misère. Un exemple parmi des centaines; en 2011 il est toujours impossible de faire un select sur les input streams retournés par un Process.

              Java a des qualités mais mettre ça en avant, faut oser... Dès que tu sors des sockets c'est le moyen age.

              • [^] # Re: Sinon y'a iFolder

                Posté par . Évalué à 2.

                Java a des qualités mais mettre ça en avant, faut oser... Dès que tu sors des sockets c'est le moyen age.

                Si tu parle des socket comme IPC, je suis d'accord, Java c'est de la daube pour accéder au système (de fichier ou non). Pour le réseau, RMI est pas mal, mais il faut travailler uniquement en Java, sinon il y a les serveurs d'application qui permettent de faire du HTTP et du REST de manière simple.

                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: Sinon y'a iFolder

                  Posté par . Évalué à 2.

                  Parler de RMI/HTTP/REST c'est un peu hors sujet. Il s'agit uniquement de protocoles au dessus de TCP. Mon point c'est que la gestion et les outils autours des sockets sont (très) au point en Java. Tout autre interaction avec le système est pourrie. Manipuler des fichiers, des processus, des grosses données, des signaux, gérer sa mémoire, faire de l'IPC, les utilisateurs et bien d'autres choses vont de pénibles à l'enfer pur et simple.

                  Le post de base c'est que Java était un choix naturel pour implémenter quelque chose qui surveille un FS et qui fait des coms réseau. Je signalais juste que c'est un peu mentir par omission quand même.

                  Pour RMI c'est totalement un autre sujet mais faut vraiment avoir des besoins très simples et pas l'avoir utilisé beaucoup pour le recommander pour faire de vraies applis (mon job c'est faire des protocoles réseaux & systèmes distribués en Java depuis quelques années).

      • [^] # Re: Sinon y'a iFolder

        Posté par . Évalué à 4.

        Parceque beaucoup d'offre d'emploie tournent autour de java et C# et que c'est ce qui est enseigne dans les ecoles.

        • [^] # Re: Sinon y'a iFolder

          Posté par . Évalué à 1.

          Je suis d'accord avec le commentaire plus haut, ce n'est pas parce que le Java est très enseigné qu'il est adapté dans cette situation. Il ne l'est pas, un démon en C ou C++ l'est bien plus dans le cas d'un petit démon de synchronisation.

  • # Fonctionnalités à venir

    Posté par . Évalué à 4.

    Bonjour,
    J'ai été en contact par mail avec le codeur de Syncany car j'attends depuis longtemps un truc comme ça, et j'avais quelques fonctionnalités à lui suggérer, à priori, il avait lui aussi les mêmes idées, ça tombe bien.

    Syncany va donc prochainement, si tout va bien, implémenter une sorte de fonction RAID, qui pourrait être proposée selon 2 principes :
    - type RAID0, ou miroir, là, on pourra déclarer des dossiers à gérer en miroir et leur contenus sera donc dupliqué sur les différents Cloud spécifiés, c'est la solution "sécurité maximum",
    - type RAID1, ou agrégation, là c'est la solution "espace maximum", où là, on pourra agréger les différents Cloud pour avoir un seul grand espace, unifié, de stockage.

    Voili.

    • [^] # Re: Fonctionnalités à venir

      Posté par . Évalué à 6.

      Tu as sans doute interverti RAID0 et RAID1.

      J'ai du mal à voir l'intérêt d'un pseudo RAID0 distribué ... à la rigueur une sorte de JBOD et encore avec un suivi au niveau fichier (et non bloc) pour savoir ce qui a été perdu en cas de crash de l'un des noeuds...

      Si vous n'aimez pas ce commentaire c'est qu'il est ironique.

      • [^] # Re: Fonctionnalités à venir

        Posté par . Évalué à 0.

        Oups oui, bien vu, merci.

        Perso c'est bien le mode miroir (RAID1, donc, je corrige) qui m'intéresse le plus. Mais l'autre est intéressant pour ceux qui veulent avec un max de place...gratos.

        Finalement, si tu crées un compte sur toutes ces plateformes, tu as à ta disposition une place non négligeable...si tu arrives à agréger. Après, on peut faire pareil sans agréger, et c'est effectivement plus sur pour les données, mais un outil qui te fait ça tout seul, rend les choses plus faciles , il l bosse pour toi.

  • # Architecture ?

    Posté par . Évalué à 3.

    D'après ce que j'ai lu Syncany est écrit en Java.

    Est-ce que les clients Windows et MacOS X parlent au Java ou est-ce qu'il s'agit d'autres implémentations dans d'autre langages ?

    Merci.

  • # Génial!

    Posté par (page perso) . Évalué à 0.

    Mais c'est génial! Même si c'est écrit en Java. Après, il ne restera plus qu'à faire une interface web par dessus.

  • # une (autre) alternative...

    Posté par . Évalué à 1.

    en cours de test sur mon serveur :

    http://philcryer.github.com/lipsync/

    Server - Linux 2.6.x, rsync, unison, opensshd.
    Client - Linux 2.6.x, rsync, unison, openssh, lsyncd

    et avec une interface web sur le serveur comme ajaxplorer :
    http://www.ajaxplorer.info/wordpress/

    on n'est pas loin d'une dropbox. Il ne manque qu'une chose :

    I'd be interested in working with others that want to build a gui front end to talk to the backend

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.