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é.
Vous pouvez éditer ce paragraphe en cliquant dessus
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 redo_fr . É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).
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Autre projet sympa
Posté par Zylabon . Évalué à 8.
Pas libre du tout celui là.
Please do not feed the trolls
[^] # Re: Autre projet sympa
Posté par ledom . É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 fredix . É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 ledom . É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 William Steve Applegate (site web personnel) . Évalué à 5.
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 ledom . É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 Grunt . É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 jemore . É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.
[^] # Re: fonctionnalités
Posté par manatlan (site web personnel) . Évalué à -1.
ubuntu one ... non ?
[^] # Re: fonctionnalités
Posté par GeneralZod . Évalué à 6.
sapusaipalibre
# Intérêt ?
Posté par madhatter (site web personnel) . É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 yanntech . É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 yellowiscool . É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 LeMagicien Garcimore . Évalué à 4.
Comique de répétition ?
https://linuxfr.org/users/linkdd/journaux/synchronisez-vos-donn%C3%A9es-avec-dropbox#comment-1229821
[^] # Re: Intérêt ?
Posté par madhatter (site web personnel) . É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 fredericabel . É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 madhatter (site web personnel) . É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 fatypunk . É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 Vlobulle . É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 yanntech . É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 fredericabel . É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 Zylabon . É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 ledom . É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 Zylabon . É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 ZeroHeure (site web personnel) . Évalué à 2.
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 madhatter (site web personnel) . É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 Zenitram (site web personnel) . Évalué à 2.
Ton prix de du Gigaoctet sauvegardé calmera le gain de tes watts non consommés.
Tu as de superbes idées théoriques. Tu me files l'argent qui va avec?
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par passant·e . Évalué à 1.
réveil difficile?
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
Pléonasme.
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par Zylabon . Évalué à 2.
Un disque dur éteint consomme 0 watt, ou peut être un tout petit peu plus 0.001 watt (?)
Tout les disques durs modernes peuvent être allumé et éteint par le système d'exploitation.
Et pour les 2 watt dont je parlais, c'est la consommation de la puce ARM cortex A9 double cœur à 2Ghz. (très largement surdimensionnée donc) la consommation d'un ARM plus modeste ce compte en milliwatt, le genre qu'on alimente avec un panneau solaire de 30cm².
Please do not feed the trolls
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par FDF (site web personnel) . Évalué à 1.
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 ledom . É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 ledom . É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 Christophe Turbout . Évalué à 1.
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 Juke (site web personnel) . É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 Christophe Turbout . Évalué à 1.
oui :D
comme quoi je suis cohérent ...
tu remarqueras que mon premier argument est nouveau ... et promis à un bel avenir
car rapidement nous allons devoir changer nos comportements mais c'est un autre débat ...
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par insert_coincoin . Évalué à 3.
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 ondex2 . É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 madhatter (site web personnel) . É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 sifu . É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 serge D. . É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 insert_coincoin . É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 madhatter (site web personnel) . É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 LupusMic (site web personnel, Mastodon) . Évalué à 0.
Git, sinon rien :)
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par madhatter (site web personnel) . É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 El Titi . Évalué à 2.
http://mercurial.selenic.com/wiki/PublishingRepositories
Le push est possible avec hgserve. Et tu as à a ta disposition et tu as des cgi.
Moi avec tous les tests que j'ai fait avec msysgit pa moyen de partager en push sous Windows avec git:. (Bug ouvert qu'ils ne savent pas corriger)
Seule solution si tu veux pas mettre de ssh partager un répertoire sous Windows. Chouette.
Hg est définitivement plus user-friendly
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par madhatter (site web personnel) . Évalué à 0. Dernière modification le 06 juin 2011 à 00:52.
Comment tu fais ? J'ai essayé hier avec une machine virtuelle, j'ai mis en route le serve dessus et j'ai essayé à partir de mon portable de faire un push dessus, mais ça n'a pas marché.
There is no spoon...
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par Albert_ . Évalué à 3.
push has no authentication, so can only be used on trusted internal networks
Un truc a vraiment pas mettre en "ON" a mon avis. Vu comment sont "joueur" certains collegues parfois.
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par Albert_ . Évalué à 0.
Je pense que l'on peut te citer une phrase sur le site du logiciel que tu detestes:
Note: if you are not willing to put in an effort to get the problem solved, you should expect other people to be as enthusiastic about fixing it.
Ah tiens amusant en lisant le bug:
http://code.google.com/p/msysgit/issues/detail?id=457
Ca fonctionne le push, il suffit de ne pas utiliser le protocole git mais ssh...
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par barmic . Évalué à 2.
svn co -> git clone -> hg clone (si je en me trompas pas pour ce dernier)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par madhatter (site web personnel) . Évalué à 0.
Ah oui, effectivement, hg clone. J'avais pas vu. Merci ;)
There is no spoon...
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par KiKouN . É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 ledom . É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 Anonyme . Évalué à 10.
Merci Captain Obvious !
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par ledom . É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 LupusMic (site web personnel, Mastodon) . É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 Vlobulle . É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 Zylabon . É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 jigso . É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 Schnouki . É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 Kerro . É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.
[^] # Re: Ligne de commande ?
Posté par Olivier (site web personnel) . Évalué à 5.
Dropbox dispose d’une ligne de commande. Il y a en fait plusieurs outils :
http://linux.dropbox.com/packages/dropbox.py
ou http://wiki.dropbox.com/DropboxAddons/DropboxLinuxCLI
Il peut être installé sur un serveur ou tout autre machine sans serveur graphique.
# Sinon y'a iFolder
Posté par maat (site web personnel) . Évalué à 1.
http://www.ifolder.com/
Et ça marche depuis un bout de temps...
[^] # Re: Sinon y'a iFolder
Posté par ZeroHeure (site web personnel) . É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 clement . É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 Stéphane Klein (site web personnel) . Évalué à 3.
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 clement . Évalué à -1.
merci c'est bookmarké !
[^] # Re: Sinon y'a iFolder
Posté par ZeroHeure (site web personnel) . É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 Albert_ . É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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Sinon y'a iFolder
Posté par Albert_ . Évalué à 1.
Et merde rippage :)
[^] # Re: Sinon y'a iFolder
Posté par ZeroHeure (site web personnel) . É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 El Titi . Évalué à 4.
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 Albert_ . É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 El Titi . É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 claudex . Évalué à 1.
Tu es au courant pour les alias?
Chez moi, ça s'ouvre instantanément. Et mon vim est très joli.
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 El Titi . Évalué à 2.
Oui et toi tu sais ce que signifie "out of the box"
Et les alias ca marche dans Egit ?
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$.
"Hé Coco tu peux y aller depuis chez toi ?"
[^] # Re: Sinon y'a iFolder
Posté par Albert_ . É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 Albert_ . É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 El Titi . É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 Albert_ . É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 El Titi . É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 Juke (site web personnel) . Évalué à 2.
d'accord !
[^] # Re: Sinon y'a iFolder
Posté par Albert_ . É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 barmic . Évalué à 3.
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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sinon y'a iFolder
Posté par Albert_ . É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 barmic . É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é.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sinon y'a iFolder
Posté par Albert_ . É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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sinon y'a iFolder
Posté par Albert_ . É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 barmic . Évalué à 2.
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.
Tu crois vraiment qu'il y a beaucoup de logiciels propriétaire et/ou Windows qui ont était fait pour faire chier les linuxiens ?
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.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sinon y'a iFolder
Posté par Albert_ . É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 barmic . Évalué à 6.
Comme les autres font de la merde, il est normal d'en faire aussi ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sinon y'a iFolder
Posté par Albert_ . É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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sinon y'a iFolder
Posté par Albert_ . É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 madhatter (site web personnel) . É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 El Titi . É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 Albert_ . É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 Albert_ . É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 Albert_ . É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 beagf (site web personnel) . Évalué à 3.
Personnellement ça doit me servir à peu près tous les jours...
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 LupusMic (site web personnel, Mastodon) . É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/ ?
Elles sont où tes 10 min ?
[^] # Re: Sinon y'a iFolder
Posté par Albert_ . É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 El Titi . Évalué à 2.
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 Albert_ . É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 El Titi . É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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sinon y'a iFolder
Posté par clement . É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 Gniarf . É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 barmic . Évalué à 3.
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 :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sinon y'a iFolder
Posté par Juke (site web personnel) . Évalué à 1.
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 barmic . Évalué à 2.
Tu as raison.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sinon y'a iFolder
Posté par ckyl . É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 clement . É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 ckyl . É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 barmic . Évalué à 2.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sinon y'a iFolder
Posté par ckyl . É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 Albert_ . É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 Stibb . É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 romu . É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 Ymage . É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 romu . É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 sifu . É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 ploum (site web personnel, Mastodon) . É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.
Mes livres CC By-SA : https://ploum.net/livres.html
# une (autre) alternative...
Posté par gide . Évalué à 1.
en cours de test sur mon serveur :
http://philcryer.github.com/lipsync/
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 :
[^] # Re: une (autre) alternative...
Posté par Nicolas Ecarnot (site web personnel) . Évalué à 0.
Manque le versionning, parmi tant d'autres choses...
[^] # Re: une (autre) alternative...
Posté par Tof . Évalué à 0.
Aujourd'hui j'utilise unison.
Y'a un bout de versioning (option "backups").
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.