BFG a écrit 901 commentaires

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.

?

Encore un peu et ils n'autorisaient que le copier/coller à la place des fonctions/méthodes.

Impossible, la fonction "copier/coller" n'existe pas sur iPhone.

Il y a aussi un système d’installeur sous OS X c’est au dev de l’application, de choisir s’il veut que l’installation de son appli ce fasse soit par un simple drag n’ drop, soit en empaquetant l’application, et en fournissant un installeur, qui pourrat aussi désinstaller son bordel.

Alors, je repose les questions de mon précédent commentaire : comment sait-il si une bibliothèque partagée peut être désinstallée ?

Dans ce cas, ça ne peut pas copier les bibliothèques partagées dans "/usr/lib", on est donc dans un système type Windows (désinstalleur en moins).
(Ne copier que le ".app" ne marche que pour des applications autonomes simples, si l'on veut faire des choses un peu plus compliquées, comme installer des extensions à d'autres programmes, s'enregistrer au démarrage, etc., il faut autre chose)