BFG a écrit 904 commentaires

lsyncd et inosync ne sont pas bidirectionnels.
Qu'est ce que la bidirectionnalité ? C'est ce qui permet de déterminer de connecter plusieurs postes de travail à un serveur, et de propager les opérations à tous les postes.
Néanmoins, tout le monde n'a pas besoin de la bidirectionnalité (si l'on n'a qu'un seul poste, ou alors si on utilise les différents postes en séquence uniquement, et qu'on lance certaines commandes rsync à certains moments bien précis)

En quoi rsync ne permet pas cela alors qu'on pourrait appeler "rsync local: distant: ; rsync distant: local:" ? Car si un fichier est supprimé, l'opération n'est pas propagée. Et si l'on ajoute "--delete" ? Alors, il ne sera pas possible d'ajouter un nouveau fichier depuis un poste car un autre poste le supprimera, car "--delete" fera croire à rsync que le fichier est superflu.
Comment résoudre le problème ? En gardant un état, pour mieux considérer chaque fichier, et ne laisser à rsync que le transfert individuel de fichiers, et non plus le transfert d'arbres de dossiers/fichiers.

Peut-être que vous n'avez pas compris que le hash n'est recalculé qu'à la fermeture du volume TC, et non pas en permanence à chaque modification ?

J'ouvre mon volume une ou deux fois par jour, au grand maximum.

Effectivement je n'avais pas compris, mais du coup ce n'est pas utilisation en synchronisation (ou au moins quasi-) mais en "sauvegarde quotidienne".

De plus, l'utilisation d'un volume Truecrypt qui est totalement opaque au niveau gestion des fichiers empêche de faire des modification concurrentes sur des fichiers différents : par exemple, ajoutez un fichier A sur un poste, et un fichier B sur un autre poste, et après synchronisation, vous auriez pu avoir les 2 fichiers A et B sur les 2 postes.
Du coup, Dropbox ne peut même pas vous servir pour sa fonction bidirectionnelle.

Si un appel de fonction est gênant, pourquoi ne pas remplacer par des gotos ?
D'ailleurs, un switch n'est il pas transformé par le compilateur en une "table de goto", faisant qu'il ne fait pas réellement de tests sur la valeur mais uniquement une indirection ?

Je ne connais pas d'autre solution au problème (qui est, je rappelle, de combiner DB avec son propre chiffrement tout en restant portable).

Et bien avec vos demandes, actuellement, il n'y a pas de solution. (Je ne tiens pas compte de votre proposition d'utiliser Truecrypt car c'est complètement farfelu (la longévité de vos disques doit être d'ailleurs bien diminuée grâce à ça)). Dropbox ne sait pas chiffrer les fichiers avant de les envoyer, et il n'existe pas actuellement de chiffrement de fichiers à la volée portable.
Porter encfs pour les OS qui ne l'ont pas, ou utiliser autre chose que Dropbox serait une solution.

Non, car ce n'est pas bidirectionnel.

le temps de calcul du hash d'un fichier de quelques go est complètement négligeable avec les machines actuelles.

Rassurez-moi, vous n'êtes pas développeur ? J'espère sincèrement que vous n'écrivez aucun logiciel, et que vous ne participez à aucun choix technique d'un quelconque logiciel, parce qu'avec ce genre de réflexion, je n'ose pas imaginer la qualité des dits logiciels...

un exemple isolé

Vous voulez jouer à ça ? Bien, Dropbox est un exemple isolé.

qui date quand même maintenant de trois ans

Comme ça date d'il y a 3 ans, l'exemple devient invalide ?

et qui est un peu hors sujet

En quoi ?

On peut aussi faire le fameux capitaine de soirée.

Les API de surveillance du système de fichiers (inotify, etc.) ne permettent pas de savoir quelle partie d'un fichier a changé. Même si Dropbox utilise la librsync, travaille par blocs, etc., il faudra quand même qu'il calcule la somme de contrôle de toutes les parties du volume Truecrypt.
Alors, relire intégralement 50Mo (ou plus) pour la plus petite modification d'un petit fichier encapsulé dans Truecrypt, c'est inefficace.

Le problème a duré 4 heures, coté serveur. Si le client et/ou le serveur avait été libre, qu'est ce que ça aurait changé étant donné que les utilisateurs ne peuvent pas corriger les serveurs qui sont hébergés chez Dropbox, puisque l'utilisateur n'a pas de controle sur les serveurs (et non pas le code) ?
Dans ce cas là, le problème est que le service est chez un prestataire et qu'on est donc dépendant de ce qu'il a installé. Grande nouvelle.

Vous faites aussi la morale aux gens qui écrivent "linux" au lieu de "Linux" ?

Vous avez piqué ma curiosité, je viens de le tester. Si le son fonctionne bien (mais c'était déjà le cas avec Pidgin pour ma part), en revanche la vidéo est un échec total, que ce soit caméra ou "partage d'écran".

Peut-être en rajoutant "si vous avez lu cette licence" (d'ailleurs j'ai oublié d'appliquer les autorisations à la licence), pour montrer à la personne qu'elle a déjà peut-être violé quelque chose rien qu'en ouvrant le fichier de licence. C'est un peu dans le genre des signatures d'email qui disent "ne lisez pas ce texte s'il ne vous est pas adressé", alors que la signature est placée à la fin...

(Bon, le Hello World peut être rétréci)

Le fait qu'on ne puisse plus accéder à la mémoire vidéo aussi facilement, qu'il faille faire des appels d'API pour ouvrir des fenêtres etc., que les formats d'exécutables se soient alourdis ("Smallest x86 ELF Hello World [...] 142 bytes" http://timelessname.com/elfbin/, mais je ne sais par contre pas quelle confiance y accorder) n'y est-il pour rien ?

Il y a le deterministic transformable compiler (mais le nom a été choisi volontairement par un français, alors ça ne compte pas)

Licence Pessimiste
Si vous avez utilisé, copié, modifié ou distribué ce programme, on ne pourra réalistement pas vous empêcher de continuer à le faire, alors continuez...

À force d'hésiter sur la tournure de la licence et de la modifier, ça devait arriver : le résultat n'est même pas français. Je vous incite à remplacer "si" par "que" dans la licence, mais uniquement si vous pensez que ce serait mieux de le faire.

Je vous propose une licence similaire, la LLA : Licence Libre Arbitre.

Licence Libre Arbitre

Cette licence vous autorise à utiliser, copier, modifier ce travail ou cette licence, mais à la condition si vous le souhaitiez.

Il a posté dans le passé pour prévenir à temps les administrateurs pour qu'ils censurent le message récursif.

Ces tests sur les paquets sont à faire sur un système/une machine (éventuellement machine virtuelle) dédiée. Il faut donc mettre en place cette infrastructure (et il faut des compétences particulières pour le faire !).
Comme c'est un projet libre et qu'on veut en général que toute autre personne puisse lancer les mêmes tests que les développeurs principaux, simplement à partir du dépôt de code, il faut donc documenter cette infrastructure et la rendre reproductible chez tout autre potentiel futur développeur.
Tout cela peut être particulièrement lourd et long à mettre en place.
C'est aussi une question de moyens, je ne sais pas combien il y a de développeurs, mais en plus le projet semble être divisé, et les efforts sont encore plus fragmentés.

/home j'ai juste à détarer le backup de la veille, 10 minutes maxi

Pour les utilisateurs qui font des sauvegardes uniquement.

/usr faut tout réinstaller, plusieurs heures au minimum!

Pour l'utilisateur lambda qui ne fait pas de sauvegardes, la réinstallation de /usr se résume à mettre le CD de sa distribution, cliquer à répétition sur "suivant", car un utilisateur lambda se contente souvent de l'environnement complet GNOME ou KDE et les quelques logiciels non-intégrés viendront après.

"/conf" aurait tout de même été plus lisible.

L'humour, une chose tellement difficile à comprendre...

Je ne sais pas si la WTFPLv2 n'est pas libre. En tout cas votre LRL est inutilement compliquée. Pourquoi pas tout simplement :

Permission is granted to copy, modify and/or distribute this work and/or license, without conditions.

?