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...
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é).
En principe, si tu sais que tu perds 10% de ton capital par an, tu vas seulement épargner une somme "de sécurité", mais ça ne rime à rien de laisser de l'argent fondre pendant 20 ans.
Attention, l'inflation d'une devise n'implique pas que l'argent de l'épargne fonde. Ca implique simplement qu'il faut le convertir en quelque chose de moins touché : soit une autre devise, soit des titres, soit des biens.
Même en forçant une inflation de 15% sur toutes les monnaies du monde, on empêchera personne d'épargner. Par contre on verra tout de suite surgir des montages financiers promettant au moins 15% de rentabilité.
Même si l'on utilise un live-CD pour copier la clef, elle sera inutilisable sans le mot de passe connu uniquement de la personne à qui appartient la clef.
Sauf erreur, pouvoir utiliser un live CD permet de se logger en root sur la machine et donc de pieger le compte de l'utilisateur pour récupérer sa clef.
Dans tous les cas on en revient au même problème : il faut que l'utilisateur soit le seul administrateur potentiel de sa machine (et donc que personne d'autre n'y ait accès).
Sauf qu'en pratique l'utilisateur lambda, il a déjà du mal à être administrateur tout court et plein de gens ont accès à sa machine (toute la famille, le technicien qui lui a configuré -c'est probablement lui le véritable administrateur-, sans parler des différents virus et autres rootkits qui peuvent avoir été installés). Bref, de toute façon, dès que l'on parle de Mme Michu, la sécurité est compromise.
Le but n'est donc pas de protéger l'utilisateur dans l'absolu, mais simplement de le protéger relativement à son environnement (d'autres Mme Michu). A partir de là, où est le problème à avoir quelques options de sécurité supplémentaires (comme du PGP dans le webmail en l'occurrence) ?
Il faut laisser le choix à l'utilisateur d'où stocker ses clefs. Que ce soit sur sa machine, sur une machine distance, ou dans un cloud ne lui appartenant pas. C'est sa décision.
Comment vous, libristes, protégeriez-vous une telle invention ?
Pourquoi réfléchir sur la notion de licence ? Le problème n'est pas là.
Une telle invention étant par construction incontrôlable, il faut mieux, à mon avis, se concentrer sur comment limiter les dégâts (matériels, sociaux, humains) qu'elle peut causer.
Une analogie avec l'ère numérique et ses conséquences sur la création en général peut être faite assez facilement. La question des licences n'y est qu'une étape, le problème de fond reste là : on ne peut matériellement empêcher les utilisateurs de copier une oeuvre numérique si on veut conserver la liberté de communication. Comment alors essayer de mitiger les dégâts sur la création ?
Même question, même si un peu plus ancienne, à une autre échelle avec le nucléaire. Si tous les pays du monde commencent à maitriser l'énergie nucléaire, que cela soit sous forme de production d'énergie ou d'armes. Jouer sur les législations n'est venu que des décennies après les premiers dégâts...
Les camping cars utilisés en résidences principales sont sujets à une taxe d'habitation (réduite) depuis peu. Je trouve logique d'appliquer la même chose pour les tentes.
Je n'ai que moins d'un Go de données que je juge importantes, donc j'ai tout mis dans un volume TrueCrypt, le tout sur DropBox. Elle est dupliquée sur 3 ordinateurs, dont un qui n'est pas chez moi (au boulot). Je change la pass-key de temps en temps.
Le reste de mes disques durs, tout est récupérable d'une manière ou d'une autre sur internet, je n'ai donc pas particulièrement envie de me casser la tête à le sauvegarder...
Comme j'ai dis, le client, le protocole et le serveur travaillent par blocs. Je n'en connais pas la taille, mais ils sont petits je suppose (quelques Ko sans doute).
Je n'ai pas les détails techniques, mais avec un volume TrueCrypt de plus d'un Go, c'est complètement transparent à utiliser.
à moins bien sûr de synchroniser avec Dropbox un fichier image de périphérique bloc TrueCrypt
Ben oui.
DropBox synchronise les fichiers par blocs, TrueCrypt ne modifie les blocs qu'on a utilisé dans le volume, donc tout marche de manière transparente. Y compris sur des fichiers très volumineux.
Voilà, ça ressemble à ça. Le service offrant en plus le serveur (gratuitement pour des petits volumes de fichiers) et surtout, le programme permet d'utiliser le tout en un seul clic/executable à lancer.
Et malheureusement, il n'y a aucune solution complètement équivalente. Ni au niveau du protocole de synchronisation, ni au niveau de l'application cliente, et encore moins au niveau du serveur.
Et c'est particulièrement dommage, vu la foutre praticité de ce truc (dès lors qu'on rentre dans le cadre d'utilisation, of course).
Parce qu'un virement:
- c'est plus complexe à réaliser qu'un paiement (il faut se connecter sur un autre site, recopier un RIB et une valeur qui changent à chaque fois d'un site vers l'autre, alors que pour un paiement on reste sur le même site, et on ne recopie que du papier vers le site, et toujours le même identifiant);
- il n'y a pas de moyen d'identifier facilement et systématiquement la provenance d'un virement (les identifiants qui leurs sont associés dépendent de la banque d'envoi et de réception);
- ça prend du temps à être pris en compte (variable selon la banque, l'heure ou le jour de la semaine);
- un bon nombre de personnes ne savent pas trop ce que c'est (on peut tout à fait vivre sans jamais avoir à en faire un, et les banques ne mettent pas leur existence en avant, contrairement aux chèques, par exemple).
Genre donner ton numéro de carte, le trigramme qui va bien avec, à un tiers (amazon, sony, etc) ... c'est pas un comportement imprudent et fautif pour toi ?
Pour les banques, non, et c'est ça qui compte.
communiquer ton numéro de carte, trigramme en dehors de ta banque est tout simplement imprudent, même si ton super site de commerce en ligne est PCI-DSS.
Je suis d'accord, mais en pratique, on ne peut pas faire autrement, sauf à avoir une CB virtuelle que toutes les banques ne proposent pas, ou à ne pas acheter en ligne.
Ou plus simplement les numéros de CB temporaires, valables une seule utilisation. Plusieurs banques offrent ça, et je pense que toutes le font gratuitement (y compris une banque déjà gratuite).
C'est ce que j'utilise lorsque je paye sur un site un peu louche. ("un peu louche" signifiant "tout sauf les impots")
Le délais de réclamation est de 13 mois (article L133-24 du Code monétaire et financier)
La banque est tenue de rembourser "immédiatement" (article L133-18)
En pratique, si la banque ne réagit pas à un recommandé (oubliez les rendez-vous avec les conseillers, ils ne connaissent pas ces détails en général) il suffit de contacter une association de consommateur et elle le fera sur le champ.
Et pour info l'argent du remboursement vient de la banque du débiteur...
je doute que cette appli libre ne recevra pas de rapport de bug public si elle n'honore pas la configuration proxy.
Honorer la configuration proxy ça fait partie de l'intégration. Être mal intégré ce n'est pas (encore) un bug.
Accessoirement, sous Windows ou sous Linux, il n'y a pas vraiment de moyen de définir une configuration proxy system-wide. Ou s'il y a, ce n'est pas utilisé.
Donc à part sous Android et MacOS (et je dis ça au hasard)...
Il y a un moyen d'exporter l'intégralité d'un compte Gmail dans un format d'archivage ?
De mémoire, l'imap ne supporte pas de système de tags mais uniquement des dossiers, même si c'est un moindre mal en cas de catastrophe, ça serait plus agréable de conserver son classement (sauf si on ne le fait qu'à l'aide de filtres).
Et une fois qu'on y a accès en imap, comment l'archiver ? Est-ce que Thunderbird ou équivalent propose un moyen d'exporter un dossier complet sous un format standard ? (autre chose que de faire une copie du profil de l'application quoi)
Et tout ça, y'a moyen de l'automatiser, avec une mise à jour incrémentale de la sauvegarde ? (histoire de ne pas avoir à retélécharger des giga de mails à chaque fois).
Parce que pour l'instant, j'ai la sale impression d'être bloqué sur Gmail (et je n'ai pas vu d'alternative qui me convienne).
Mon message insistait sur la différence entre LaTeX (l'usine à gaz avec ses centaines de packages mal documentés et pas toujours bien compatibles) et TeX (le système de typesetting qui fait des jolies équations et des paragraphes, mais pas beaucoup plus).
De la syntaxe TeX et de la mise en forme générée par TeX dans un document otd, cool. Mais par pitié, pas de lien de près ou de loin avec LaTeX.
Par contre, un éditeur LaTeX directement sur docs, je ne dis pas non... (on va me rétorquer que ça existe, mais bon, c'est pas encore ça au niveau de l'usabilité)
[^] # Re: Standardisation des protocoles de synchronisation ?
Posté par Vlobulle . En réponse à la dépêche Syncany, une alternative libre à Dropbox avec bien plus de fonctionnalités. É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...
# Standardisation des protocoles de synchronisation ?
Posté par Vlobulle . En réponse à la dépêche Syncany, une alternative libre à Dropbox avec bien plus de fonctionnalités. É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: Un truc intéressant
Posté par Vlobulle . En réponse au journal Les bitcoins n'intéressent pas que les geeks. Évalué à 5.
Attention, l'inflation d'une devise n'implique pas que l'argent de l'épargne fonde. Ca implique simplement qu'il faut le convertir en quelque chose de moins touché : soit une autre devise, soit des titres, soit des biens.
Même en forçant une inflation de 15% sur toutes les monnaies du monde, on empêchera personne d'épargner. Par contre on verra tout de suite surgir des montages financiers promettant au moins 15% de rentabilité.
[^] # Re: Quand ?
Posté par Vlobulle . En réponse au journal [GPG pour les nuls] C'est pour quand ?. Évalué à 2.
Sauf erreur, pouvoir utiliser un live CD permet de se logger en root sur la machine et donc de pieger le compte de l'utilisateur pour récupérer sa clef.
Dans tous les cas on en revient au même problème : il faut que l'utilisateur soit le seul administrateur potentiel de sa machine (et donc que personne d'autre n'y ait accès).
Sauf qu'en pratique l'utilisateur lambda, il a déjà du mal à être administrateur tout court et plein de gens ont accès à sa machine (toute la famille, le technicien qui lui a configuré -c'est probablement lui le véritable administrateur-, sans parler des différents virus et autres rootkits qui peuvent avoir été installés). Bref, de toute façon, dès que l'on parle de Mme Michu, la sécurité est compromise.
Le but n'est donc pas de protéger l'utilisateur dans l'absolu, mais simplement de le protéger relativement à son environnement (d'autres Mme Michu). A partir de là, où est le problème à avoir quelques options de sécurité supplémentaires (comme du PGP dans le webmail en l'occurrence) ?
[^] # Re: Quand ?
Posté par Vlobulle . En réponse au journal [GPG pour les nuls] C'est pour quand ?. Évalué à 2.
Il faut laisser le choix à l'utilisateur d'où stocker ses clefs. Que ce soit sur sa machine, sur une machine distance, ou dans un cloud ne lui appartenant pas. C'est sa décision.
# Mauvais problème ?
Posté par Vlobulle . En réponse au journal Comment protéger une invention révolutionnaire tout en la rendant accessible au plus grand nombre ?. Évalué à 3.
Pourquoi réfléchir sur la notion de licence ? Le problème n'est pas là.
Une telle invention étant par construction incontrôlable, il faut mieux, à mon avis, se concentrer sur comment limiter les dégâts (matériels, sociaux, humains) qu'elle peut causer.
Une analogie avec l'ère numérique et ses conséquences sur la création en général peut être faite assez facilement. La question des licences n'y est qu'une étape, le problème de fond reste là : on ne peut matériellement empêcher les utilisateurs de copier une oeuvre numérique si on veut conserver la liberté de communication. Comment alors essayer de mitiger les dégâts sur la création ?
Même question, même si un peu plus ancienne, à une autre échelle avec le nucléaire. Si tous les pays du monde commencent à maitriser l'énergie nucléaire, que cela soit sous forme de production d'énergie ou d'armes. Jouer sur les législations n'est venu que des décennies après les premiers dégâts...
[^] # Re: "Construire" une yourte ?
Posté par Vlobulle . En réponse au journal De la liberté de loger dans un logement de son choix. Évalué à 5.
Les camping cars utilisés en résidences principales sont sujets à une taxe d'habitation (réduite) depuis peu. Je trouve logique d'appliquer la même chose pour les tentes.
# DropBox + TrueCrypt
Posté par Vlobulle . En réponse au journal Et vous, quelle sécurité pour vos sauvegardes?. Évalué à 3.
Je n'ai que moins d'un Go de données que je juge importantes, donc j'ai tout mis dans un volume TrueCrypt, le tout sur DropBox. Elle est dupliquée sur 3 ordinateurs, dont un qui n'est pas chez moi (au boulot). Je change la pass-key de temps en temps.
Le reste de mes disques durs, tout est récupérable d'une manière ou d'une autre sur internet, je n'ai donc pas particulièrement envie de me casser la tête à le sauvegarder...
[^] # Re: Serveurs de Dropbox
Posté par Vlobulle . En réponse au journal Synchronisez vos données avec Dropbox. Évalué à 2.
Comme j'ai dis, le client, le protocole et le serveur travaillent par blocs. Je n'en connais pas la taille, mais ils sont petits je suppose (quelques Ko sans doute).
Je n'ai pas les détails techniques, mais avec un volume TrueCrypt de plus d'un Go, c'est complètement transparent à utiliser.
[^] # Re: Serveurs de Dropbox
Posté par Vlobulle . En réponse au journal Synchronisez vos données avec Dropbox. Évalué à 3.
Ben oui.
DropBox synchronise les fichiers par blocs, TrueCrypt ne modifie les blocs qu'on a utilisé dans le volume, donc tout marche de manière transparente. Y compris sur des fichiers très volumineux.
[^] # Re: Serveurs de Dropbox
Posté par Vlobulle . En réponse au journal Synchronisez vos données avec Dropbox. Évalué à 5.
Non le client n'est pas libre. Même le protocole n'est pas ouvert.
Les devs de DropBox recommandent eux-mêmes d'utiliser TrueCrypt ou équivalent pour y mettre des données sensibles. Et ça marche très bien.
[^] # Re: sapu
Posté par Vlobulle . En réponse au journal Synchronisez vos données avec Dropbox. Évalué à 2.
La dernière fois que j'avais regardé Ubuntu One n'avait pas de client Windows. Ca semble avoir changé. Je re-regarderai où ça en est.
[^] # Re: Intérêt ?
Posté par Vlobulle . En réponse au journal Synchronisez vos données avec Dropbox. Évalué à 1.
Voilà, ça ressemble à ça. Le service offrant en plus le serveur (gratuitement pour des petits volumes de fichiers) et surtout, le programme permet d'utiliser le tout en un seul clic/executable à lancer.
[^] # Re: NFS mais en mieux ?
Posté par Vlobulle . En réponse au journal Synchronisez vos données avec Dropbox. Évalué à 4.
Comme au dessus, ça permet de travailler hors ligne.
Ca ne transfert que les modifications des fichiers (le delta à la rsynch).
Ca effectue la synchro automatiquement en background.
Et ça synchronise aussi sur un serveur à eux et permet d'avoir accès aux fichiers avec un simple accès web.
[^] # Re: sapu
Posté par Vlobulle . En réponse au journal Synchronisez vos données avec Dropbox. Évalué à 3.
Toutafé.
Et malheureusement, il n'y a aucune solution complètement équivalente. Ni au niveau du protocole de synchronisation, ni au niveau de l'application cliente, et encore moins au niveau du serveur.
Et c'est particulièrement dommage, vu la foutre praticité de ce truc (dès lors qu'on rentre dans le cadre d'utilisation, of course).
[^] # Re: Payer par virement
Posté par Vlobulle . En réponse au journal Toujours confiance ?. Évalué à 1.
Parce qu'un virement:
- c'est plus complexe à réaliser qu'un paiement (il faut se connecter sur un autre site, recopier un RIB et une valeur qui changent à chaque fois d'un site vers l'autre, alors que pour un paiement on reste sur le même site, et on ne recopie que du papier vers le site, et toujours le même identifiant);
- il n'y a pas de moyen d'identifier facilement et systématiquement la provenance d'un virement (les identifiants qui leurs sont associés dépendent de la banque d'envoi et de réception);
- ça prend du temps à être pris en compte (variable selon la banque, l'heure ou le jour de la semaine);
- un bon nombre de personnes ne savent pas trop ce que c'est (on peut tout à fait vivre sans jamais avoir à en faire un, et les banques ne mettent pas leur existence en avant, contrairement aux chèques, par exemple).
[^] # Re: Ça tombe bien...
Posté par Vlobulle . En réponse au journal Toujours confiance ?. Évalué à 3.
Pour les banques, non, et c'est ça qui compte.
Je suis d'accord, mais en pratique, on ne peut pas faire autrement, sauf à avoir une CB virtuelle que toutes les banques ne proposent pas, ou à ne pas acheter en ligne.
Ou a changer la legislation pour imposer l'eCB.
[^] # Re: et Paypal ? carte prepayé
Posté par Vlobulle . En réponse au journal Toujours confiance ?. Évalué à 2.
Ou plus simplement les numéros de CB temporaires, valables une seule utilisation. Plusieurs banques offrent ça, et je pense que toutes le font gratuitement (y compris une banque déjà gratuite).
C'est ce que j'utilise lorsque je paye sur un site un peu louche. ("un peu louche" signifiant "tout sauf les impots")
[^] # Re: Quand on tends déjà les fesses, c'est pas dramatique d'aller un peu plus loin
Posté par Vlobulle . En réponse au journal Toujours confiance ?. Évalué à 7.
En pratique, si la banque ne réagit pas à un recommandé (oubliez les rendez-vous avec les conseillers, ils ne connaissent pas ces détails en général) il suffit de contacter une association de consommateur et elle le fera sur le champ.
Et pour info l'argent du remboursement vient de la banque du débiteur...
[^] # Re: intox
Posté par Vlobulle . En réponse au journal santé libre, journal bookmark. Évalué à 1.
Merci beaucoup pour le lien.
La vidéo exacte de ce journal est aussi commentée par le même auteur sur son blog:
http://www.syndicat-simples.org/actualites/petition-defensemedecinenaturelleeu-propagande-desinformationet-recuperation
[^] # Re: Mauvais titre, changer titre
Posté par Vlobulle . En réponse au journal Pédagogie de couloir à l'usage des démarchés. Évalué à 4.
Je leur demande comment ils sont entrés dans l'immeuble et leur demande d'en sortir sur le champ.
[^] # Re: Solution libre
Posté par Vlobulle . En réponse au journal Avec Android, vous en avez plus pour votre argent. Évalué à 1.
Honorer la configuration proxy ça fait partie de l'intégration. Être mal intégré ce n'est pas (encore) un bug.
Accessoirement, sous Windows ou sous Linux, il n'y a pas vraiment de moyen de définir une configuration proxy system-wide. Ou s'il y a, ce n'est pas utilisé.
Donc à part sous Android et MacOS (et je dis ça au hasard)...
# Exporter entièrement les données Gmail ?
Posté par Vlobulle . En réponse au journal Bien joue Google. Évalué à 1.
Il y a un moyen d'exporter l'intégralité d'un compte Gmail dans un format d'archivage ?
De mémoire, l'imap ne supporte pas de système de tags mais uniquement des dossiers, même si c'est un moindre mal en cas de catastrophe, ça serait plus agréable de conserver son classement (sauf si on ne le fait qu'à l'aide de filtres).
Et une fois qu'on y a accès en imap, comment l'archiver ? Est-ce que Thunderbird ou équivalent propose un moyen d'exporter un dossier complet sous un format standard ? (autre chose que de faire une copie du profil de l'application quoi)
Et tout ça, y'a moyen de l'automatiser, avec une mise à jour incrémentale de la sauvegarde ? (histoire de ne pas avoir à retélécharger des giga de mails à chaque fois).
Parce que pour l'instant, j'ai la sale impression d'être bloqué sur Gmail (et je n'ai pas vu d'alternative qui me convienne).
[^] # Re: À comparer avec les nouveautés de LibreOffice
Posté par Vlobulle . En réponse au journal Google Docs fait peau neuve mais.... Évalué à 1.
Bon, alors après, pour faire un joli d droit, je ne saurai dire...
[^] # Re: À comparer avec les nouveautés de LibreOffice
Posté par Vlobulle . En réponse au journal Google Docs fait peau neuve mais.... Évalué à 1.
De la syntaxe TeX et de la mise en forme générée par TeX dans un document otd, cool. Mais par pitié, pas de lien de près ou de loin avec LaTeX.
Par contre, un éditeur LaTeX directement sur docs, je ne dis pas non... (on va me rétorquer que ça existe, mais bon, c'est pas encore ça au niveau de l'usabilité)