Puisque tu as l'air de connaître un peu le sujet, est que tu serais me dire si au niveau performance cela est équivalent ? Bien sûr c'est fortement dépendant de comment on code la gestion...

Je connais pas particulièrement ;-).

Niveau performance, oui, ça dépends comment tu gère les pertes de paquets. Pour NFS, j'ai souvenir d'avoir lu dans le man que TCP était plutôt plus rapide vu que la ré-émisson en cas de perte se faisait au niveau paquet alors qu'en UDP c'était au niveau requete, mais j'ai un man différent sous la main qui ne parle pas de ça, et qui dit qu'UDP est le défaut, il doit y avoir une raison !

Sinon, un protocole non-fiable peut aussi être utilisé dans les cas où tu sais traiter les paquets dans le désordre : un paquet perdu ne t'empêche pas de continuer à traiter ce qui arrive au fur et à mesure et attendant la ré-émission.

[ Répondre ]

TCP est _un_ moyen d'avoir une connexion fiable, mais tu peux tout à fait ajouter l'équivalent dans la couche applicative. L'intérêt étant que l'application peut savoir mieux que le protocole quoi faire quand on perd un paquet, mais par contre, ça fait plus de boulot pour l'applie.

Par exemple, NFS peut tourner sur du UDP, je ne retrouve pas précisément, mais je suis 99% sur qu'il y a un méchanisme de checksum comparable à celui de TCP, et « man nfs » par le méchanisme de ré-émisson de requetes NFS quand elles sont perdues.

[ Répondre ]

> si je veux du fiable, j'utilise TCP

ça, il ne faudra pas lui dire trop fort, à ton prof de réseau.

[ Répondre ]

Si j'ai bien compris, sa défense était en partie basée sur le fait qu'il pensais que sa femme était toujours vivante, probablement partie en Russie. Donc, ce qui est flagrant, c'est qu'il a menti, et qu'il a basé sa défense sur un mensonge. En soi, ça ne prouve pas que ce soit lui qui a tué, mais du point de vue du tribunal, ça confirme quand même qu'ils ont eu raison de le condamner.

[ Répondre ]

Euh, on doit pas parler du même RMS alors.

Parce que

http://www.gnu.org/philosophy/linux-gnu-freedom.html
http://www.fsf.org/blogs/rms/can-we-rescue-olpc-from-windows

Ça m'a tout l'air de dire le contraire quand même ...

[ Répondre ]

Euh, tu le fais exprès ou quoi ? Relis bien le morceau que tu cites toi-même (le morceau, pas ta traduction), il dit le contraire de ce que tu dis.

À part ça, ce que tu cites est un texte « philosophique » et non la licence. Quand j'ai dit « relis la GPL », je voulais vraiment dire « la GPL », par exemple ce bout là (point 3b) :


Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, [...]


ou en GPL v3 :


for a price no more than your reasonable cost of physically performing this conveying of source,

[ Répondre ]

Non, relis la GPL.

[ Répondre ]

> La licence est claire, libre à vous de ne pas utiliser ce code.

Euh, c'est quoi la différence avec les licences propriétaires du coup ?

Windows aussi, tu es libre de ne pas l'utiliser ...

[ Répondre ]

que rsync copie d'une source vers une destination, et ne fait pas de fusion bi-directionnelle, comme le fait par exemple unison (ou alors carrément des gestionnaires de versions, mais c'est une autre histoire).

[ Répondre ]

Oui l'intérêt semble maigre, surtout vu les exemples d'applications « Linux » donnés : Firefox, OpenOffice ... réputés pour avoir une version native meilleure que la version Linux !

[ Répondre ]

> Pire, il ne semble même pas donner l'impression de se renseigner un minimum sur ce qu'il avance.

Malheureusement, c'est même un fait avéré.

Pour une raison que j'ignore, Stallman s'interdit de surfer sur le Web, sauf sur les sites gnu.org et fsf.org. Donc, quand il dit « OpenBSD contient du non-libre », il ne faut pas lire « je suis allé sur openbsd.org et j'ai vu que ... », mais bien « il parait que ... ».

J'ai une fois prononcé les mots « Red Hat » à porté de l'oreille de Stallman, il s'est mis à crier « Red Hat contains non-free software ». J'ai demandé (en toute bonne foi) lesquels, il a répondu qu'il ne savait pas, mais que c'était sûr, puisqu'on lui avait dit qu'il y en avait.

[ Répondre ]

oui mais non : d(sin(7x))/dx = 7cos(x).

Mais t'as de la chance, le coefficient 7 part dans la division par zéro de toutes façons.

[ Répondre ]

Le RPN, c'est un langage à pile.

Pour (1 + 2) * (3 - 4), tu fais

1 2 + 3 4 - *

et je vois pas comment tu pourrais faire sans séparateur (entrée ou espace, c'est pareil).

[ Répondre ]

Bien plus de 10 ans. J'ai appris à l'utiliser sous word 5, vers 1990 je crois.

[ Répondre ]

Et c'est du XML "tout-sur-une-ligne", donc un diff bête et méchant dessus ne fait pas grand chose d'intéressant.

[ Répondre ]

http://www-verimag.imag.fr/~moy/opendocument/

(même texte que celui cité plus bas sur le Wiki de Mercurial)

En fait, à partir du moment où on a un truc un peu flexible, et qu'on connait odt2txt, c'est assez facile de générer des diffs sur ces fichiers.

Par contre, c'est un diff visuel, mais hors de question de l'appliquer avec patch. Plus généralement, je ne crois pas qu'il existe de bons outils de merge sur ce genre de fichiers.

[ Répondre ]

http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.5(...)

Deprecation notices
-------------------

* From v1.6.0, git will by default install dashed form of commands
(e.g. "git-commit") outside of users' normal $PATH, and will install
only selected commands ("git" itself, and "gitk") in $PATH. This
implies:

- Using dashed forms of git commands (e.g. "git-commit") from the
command line has been informally deprecated since early 2006, but
now it officially is, and will be removed in the future. Use
dash-less forms (e.g. "git commit") instead.

- Using dashed forms from your scripts, without first prepending the
return value from "git --exec-path" to the scripts' PATH, has been
informally deprecated since early 2006, but now it officially is.

- Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
PATH" early in your script is not deprecated with this change.

Users are strongly encouraged to adjust their habits and scripts now
to prepare for this change.


Les raisons pour ça, entre autres :

* Les git-bidule ne permettent pas les aliases. Par exemple, chez moi, « git st » fait « git status », mais pour que « git-st » le fasse aussi, Git ne peut pas.

* Les git-bidule ne permettent pas les options globales, genre « git --no-pager foo ».

[ Répondre ]

A noter qu'Emacs est en train de migrer vers bzr.

http://thread.gmane.org/gmane.emacs.devel/90798/focus=91834

Et ça s'est un peu fighté sur les mailing-lists de Bazaar et Emacs à partir du moment où les gens ont comparé les performances de bzr avec celles de git (par exemple, "bzr log" met 1 minute avant de commencer à afficher le log sur une machine moderne).

Bon troll, c'est bientôt vendredi ;-).

[ Répondre ]

Oui, ce qui une pas bête idée du tout.

Ceci dit, y'a pas de solution parfaite : avec SVK, si tu déplaces ta copie de travail, ça met aussi le bronx. Mais l'argument est que ça arrive moins souvent de déplacer sa copie de travail que de faire des conneries avec les .bidules/ à l'intérieur de la copie de travail.

Au passage, avec Git, on peut simuler un comportement à la SVK en positionnant $GIT_DIR. Mais évidemment, si on a plusieurs repositories, c'est affreusement pas pratique de devoir changer la variable d'environnement à chaque fois qu'on change de copie de travail. C'est plus un truc pour cas particuliers dans des scripts que vraiment adapté à une utilisation quotidienne.

[ Répondre ]

C'est surtout qu'ils se sont (enfin) rendus compte que LUG voulait dire « Linux User Group », et que comme il-faut-dire-gnu-linuske-et-pas-linusque, il se sont tous renommés en GLUG.

[ Répondre ]