Octabrain a écrit 1674 commentaires

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/

Alors, je ne comprends toujours pas, dans le deuxième exemple Vala, je lis "DelegateType d1 = foo.f1;" donc bien une référence à "foo". Dans ton exemple C#, où se trouve la "OnClickMethod" ? Dans la classe où la ligne que tu donnes se trouve ?

Ok ok, tu veux parler de ça ?

% ./python 
Python 1.2 (Apr  9 2011) [GCC 4.3.3]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> class A:
... 	def m(self):
... 		print self.foo
... 
>>> a=A()
>>> a.foo=42
>>> a.m()
42
>>> a.m
<method A.m of A instance at 9491258>
>>> def call(f):
... 	f()
... 
>>> call(a.m)
42

(Oui, je suis allé chercher python 1.2 (1995 selon wikipedia, déjà antérieur au brevet), je n'ai pas essayé avec python 1.0 mais je soupçonne que ça fonctionnait déjà)

Par "couche d'adaptation", j'entends le prix que le dev qui voudra faire communiquer 2 langages, devra payer dans son code : l'overhead en terme de code et de syntaxe, pas l'overhead à l'exécution.

Si l'on fait une bibliothèque dans un langage et qu'on vise l'utilisation dans un autre langage précis, on pourra obtenir quelque chose de quasi-natif en terme de code, par exemple pas mal de la lib standard de python est implémentée en C, et cette lib s'utilise très facilement. (Si par contre on a une lib C, conçue pour du C, et qu'on veut l'utiliser en Python, il faudra un wrapper, un peu chiant à écrire mais il y a pire). Si l'on veut que la lib soit utilisable dans plein de langages, même avec ce magnifique "machin" qu'est .net, je doute que l'interaction entre différents langages supportés (sans parler de langages vraiment très différents) soit gratuite en terme de code.

Pourquoi est-ce que tous les langages auraient le devoir d'interagir entre eux ? Ils peuvent avoir des concepts tellement différents que la couche d'adaptation sera non négligeable.
Comment un langage sans classes (C) pourrait appeler "facilement" des méthodes d'un langage à classes uniquement (Java) ? Comment faire interagir des langages à évaluation lazy et des langages non-lazy ? Etc...

Je vois pas ce que vala pourrait violer, sauf à interdire à des gens d'écrire ...

http://linuxpatents.blogspot.com/2010/05/language-envy.html

Tiré du blogpost :

A quick look through the patent system reveals Vala is infringing happily left and right on Microsoft property. Let us see what our Google-fu renders:
A visual development system is described which provide "method pointers" allowing a developer/user to achieve delegation between objects programmatically as well as visually. Delegation "binds" an event source with an event handler. This binding is directly supported within the programming of the system.
The Vala Tutorial:
Delegates represent methods, allowing chunks of code to be passed around like objects.

Donc ce que ce "brevet" couvre :

typedef void (*delegatetype)(int);

void apply(delegatetype d, int p) {
    (*d)(p);
}

(c'est du C)

C'est une blague ? T'en as beaucoup d'autres des brevets aussi "novateurs" ?

Ils feront tout ce qui est susceptible de les amuser, avec bien moins de retenue (ça peut aller à saloper wikipedia, ridiculiser des gens lambdas, etc. (oui, on peut trouver ça amusant)), même pour des private jokes, qui ne concernent pas forcément ceux qui s'en trouvent impliqués.

http://forum.ubuntu-fr.org/viewtopic.php?id=365418
je n'ai pas testé, mais ça m'intéresserait bien de savoir ce qu'il en est des perfs (notamment graphiques)

Tu as du mal à comprendre le sens de "for the lulz" on dirait.

Dans ces conditions, ça n'a d'intérêt (dissuasion, parce que le fait que le voleur n'en tirera pas d'argent, ça ne te rendra pas ton portable) que si le voleur sait qu'il a de grandes chances de ne rien en tirer, il faudrait alors que cette fameuse puce soit très répandue. Sandy bridge, c'est pas uniquement les processeurs haut de gamme plus rares ?

Vous me faites douter, je ne me rappelle plus bien, peut-être qu'en fait le micro ondes influençait le transmetteur de la télé, mais l'impact le plus visible du wifi était sur la télé à cause du transmetteur.

"On voit que tu n'es pas marié toi..."
Des fois au contraire, la femme n'est pas contente du wifi car ça perturbe le micro-ondes, et la télé qui utilise un transmetteur sans fil. Comme quoi... :)