Octabrain a écrit 1685 commentaires

Et on arrête où ? Tu traverses (piéton) quand le feu est rouge, t'as pas droit à la sécu ? Tu fumes t'as pas droit à la sécu ? Tu fais pas 3 repas par jour (parce que t'as pas beaucoup d'argent), t'as pas droit à la sécu ?

C'est trop compliqué pour toi, retourne regarder TF1.

Le faire-part est une information qui parait éventuellement publiquement dans le journal, et quand bien même les archives du journal sont conservées par le journal même 100 ans après (bien qu'après la mort de la personne née, l'idée de "vie privée" est plus discutable à mon avis), cette information a une portée limitée : au delà de quelques jours, cette information est beaucoup moins publique, et les archives du journal ne sont pas publiques.

Je crois que tu as toute la sagacité d'un balai.

Il en a déjà parlé avec ses amis, cf sa citation, ici il cherche un autre avis, on n'est pas ses potes ou pseudo-potes (comme trombi est rempli de pseudos-amis, non la famille c'est pas des "amis", non la personne qui m'a ajoutée et que j'ai laissée faire n'est pas "amie", etc.), je vois vraiment pas la contradiction.

http://fr.wikipedia.org/wiki/M%C3%A9taphore Ah, le langage, c'est tellement complexe...

2 fois plus vite on dirait :)

bitcoin est un logiciel libre

c'est un argument fallacieux, bitcoin n'est pas qu'un logiciel, et toi dans tes journaux tu ne parles quasiment pas de l'aspect logiciel de bitcoin avec lequel tu prétends te justifier

De plus, mon intérêt à promouvoir Flattr est plus que limité

tu espères en tirer de l'argent (tout comme de bitcoin), ton intérêt est au contraire très loin d'être limité...

Enfin, last but not least, les journaux sont historiquement l'endroit où on peut dire ce que l'on veut, sans aucune contrainte de qualité. Si ça te plait pas, t'es pas obligé de lire.

tout à fait, d'ailleurs l'épisode applefr.org est là pour rappeler à quel point on apprécie d'être submergés par des journaux faisant la promotion d'apple

C'est pas clair du tout

L'utilisateur final possédant la clef privé (algorithme/cryptosystème à définir) doit être en mesure de déchiffrer la clef AES au début du fichier et déchiffrer le reste du fichier.
Jamais l'utilisateur final n'a connaissance des clef AES.

C'est pas un peu contradictoire ça ?

Tu n'as pas parlé de tes besoins, parce que "utiliser un chiffrement symétrique", "utiliser AES", etc., ce ne sont pas des besoins, ce sont des débuts de solutions.

Et c'est pas ce que fait gpg peut-être ? (relis https://linuxfr.org/news/gpg-les-concepts-en-clair-et-p%C3%A9dagogiquement)

Sauf que cette méthode ne peut pas différencier "nouveau fichier du coté A" de "fichier supprimé du coté B", car rsync ne garde aucun état.

C'est gratuit uniquement si tu utilises moins de 2go : http://www.dropbox.com/pricing

C'est complètement con, ça rajoute un overhead énorme :
- il faut mettre un fs par dessus, ça prend de la place supplémentaire et des ressources supplémentaires
- niveau serveur aussi, ils auront beau utiliser librsync, un "objet s3" (vu qu'ils utilisent s3) ne peut pas être modifié en place, il faut donc créer un fichier temporaire pour traiter le diff et envoyer un nouvel "objet s3"
- à moins qu'ils ne stockent l'objet original + tous les delta et fassent faire tout le travail aux clients
En plus, les objets s3 sont limités en taille à 5go.

encfs serait largement plus adapté.

Un "rsync bidirectionnel" (le "vrai rsync" n'est pas bidirectionnel)

Ubuntu One est du même genre, mais je ne sais pas ce que ça vaut/comment ça remplit les critères.

Une grosse différence : il y a une copie locale des fichiers et on peut accéder au contenu sans être connecté au serveur. Les modifications apportées localement ou sur le serveur seront synchronisées à la reconnexion.

dropbox ça pue c'est pas libre, c'est même pas chiffré et ça pue du point de vue sécurité : http://dereknewton.com/2011/04/dropbox-authentication-static-host-ids/

Je crois que j'ai le droit de réimplémenter une lib GNU, sous licence différente, en partant du manuel. P.ex. wine implémente sous licence GPL l'API d'un OS sous licence proprio.

Possible, bien que pour wine, c'est dans le sens contraire.

À l'édition des liens, on pourrait choisir entre libProprio et libGNU.

T'as peut-être raison, tu peux peut-être réécrire "from scratch" les headers de la lib et donner une implémentation bidon. Du coup, j'aurais pensé que le problème se pose chez le client au link :
On ne pourrait se lier avec libGNU que si le programme qui se lie est compatible GPL, et avec libProprio que si le programme qui se lie est compatible avec la licence de libProprio, et non pas uniquement que l'on peut s'y lier dès qu'il y a compatibilité d'API/ABI.
Comme tu aurais développé libProprio avec une licence spécialement pour que le client puisse s'en servir "légalement", il pourrait s'en servir, mais il ne pourrait pas se lier avec libGNU vu que hello_world.o ne serait pas compatible GPL.

Mais tes exemples gnuplot ou freecad semblent prouver le contraire, alors je sais pas.

Disclaimer: je ne connais pas akonadi, je n'utilise pas kde
Peut-être c'est possible avec pyqt/pyside, mais en Qt/C++, il n'est pas possible d'avoir un slot sur une fonction qui ne se trouve hors d'une classe héritant QObject. Ta fonction fetch n'est même pas dans une classe.

Essaye comme ça :

class Displayer(QObject):
    def fetch(self, job):
        print "plop", job

# ...
d = Displayer()
fetchJob.result.connect(d.fetch)

Essaye peut-être aussi de créer la QCoreApplication avant tout le reste.

j'écris un logiciel hello_world.c qui appelle des .h d'un projet sous GPL. Je compile mon programme (gcc -c hello_world.c) chez moi, je dispose d'un .o

Je dirais que pour suivre la GPL (dans les includes de hello_world.c), si tu donnes hello_world.o à quelqu'un, tu dois aussi lui donner hello_world.c (sous une licence compatible GPL je pense, voire GPL).

Le C type-safe... Tu cast sans que ca pose le moindre problème au compilateur.

C'est un pléonasme, le cast (quel que soit le langage) n'a jamais servi à rien d'autre qu'à permettre au développeur de rendre le compilateur content, soit en lui forçant la main (cast C), soit en lui disant de la fermer et de ne vérifier qu'au runtime (dynamic_cast, casts Java). Si tu veux être type-safe, tu n'utilises pas de casts, et ça tombe bien, c'est possible pour les pointeurs de fonctions en C.

Suffit de voir le tollé que ça a fait sur ce site même quand ils ont été ajoutés... (et encore, je trouve les avatars presque supportables dans un contexte forum/mail où les messages sont plus longs et où l'avatar bouffe proportionnellement moins de place visuelle par rapport à l'ensemble du message)

En bref, ce brevet est ridicule, le passage de contexte, on savait le faire (cf. python), et le type-safe on savait le faire (cf. C)...

irc n'a pas besoin d'extensions pour gérer des chats à plusieurs (xep 245 (+ 249 pour /invite)). irc n'a pas besoin du tout de vcard ou d'avatars (84+153+292), ni de captcha (wtf?! xep158), ni de plein d'autres trucs inutiles. Et surtout, irc n'a pas besoin d'xml ! \o/