rakoo a écrit 932 commentaires

Attention !

Lorsque tu montes un ftp en local, le dossier est vu comme un dossier local. Et voila ce que fait rsync lorsqu'il traite deux dossiers locaux, extrait du man:

-W, --whole-file
Avec cette option, l'algorithme rsync incrémental n'est pas utilisé ; au lieu de cela, le fichier entier est envoyé tel quel. Le transfert peut être plus rapide grâce à cette option lorsque la bande passante entre les machines source et cible est plus grande que la bande passante vers le disque (en particulier lorsque le «disque» est en fait un système de fichiers sur réseau NFS). Cette option est utilisée par défaut lorsque la source et la cible sont sur la même machine.

Du coup, tu peux utiliser --no-whole-file, mais rsync va telecharger le fichier a distance, le comparer avec le local et n'envoyer que les differences. Pas glop.

XMPP c'est mieux, mais c'est pas ce qu'il y a de meilleur d’après les types de psyc:

• il est très verbeux (beaucoup de "presence stanzas" en double, du XML…)
• il ne sait pas faire de smart unicast (même SMTP sait le faire…) même si dans le monde parfait ou chacun possède son serveur, ça ne changera rien
• globalement, il ne fait pas de multicast, ce qui est un énorme problème lorsqu'on a des millions d'amis et qu'on héberge son serveur chez soi.

Bref, PSYC est sympathique, mais XMPP possède l'avantage d’être déjà implémenté et connu par pas mal de monde.

Bien vu, mais justement Apple distribue le rendu, pas la base de donnés sous-jacente, donc tout va bien.

Justement, d'après le wiki, il semble que la nouvelle licence soit "à l'avantage" d'Apple :

Avec la nouvelle licence, la carte [construite avec au moins des donnés sous ODbl] peut hériter de n'importe quelle licence, selon le souhait de son auteur, dès lors qu'il met à disposition toutes les améliorations apportées aux données OSM lors de la fabrication de sa carte.

Il y a 2 cas possibles:

1. C'est le site qui te fait payer, auquel cas je me demande comment il peut dire à ta banque de lui donner de l'argent.
2. C'est ton FAI qui te fait payer, et peut le faire parce que tu lui as donné libre accès à ton compte en banque.

On est dans le deuxième cas non ?

-Est-ce que FDN protège de ce problème ?

Si on rentre dans le premier cas, FDN ne te protègerait de rien. FDN n'est pas une nounou; FDN transporte les paquets de ta machine à l'autre machine et vice-versa sans s'occuper de leur contenu. Si le paquet contient le message "Vider mon compte" et que tu ne le sais pas, tant pis; FDN acheminera quand même ce paquet.

Si on tombe dans le deuxième cas, je doute fortement que FDN s'adonne à ce genre de pratiques.

Note: je ne connais pas exactement les pratiques de FDN, mais vu les interventions du chef et la philosophie de l'association, je ne pense pas me tromper sur eux.

Ah, effectivement, merci. Je retire ma complainte.

On est sûrs qu'Apple utilise les cartes OpenStreetMaps ? Je n'en vois aucune mention nulle part, alors qu'elle devrait y être.

(Je viens de me rendre compte que c'est vieux, mais je viens de l'apprendre et ça me choque.)

elle n'a simplement pas fait attention aux clauses du contrat d'édition

Et bien tant pis pour elle. Elle a signé un contrat, elle a donc accepté tout ce qui est écrit dessus. Qu'elle l'ait lu ou pas, c'est a dire qu'elle ait une confiance aveugle en son éditeur ou pas ne regarde qu'elle.

Bon sang, on croirait qu'un contrat n'a plus aucune valeur.

Merci pour le retour.

ça utilise le scripting lua de redis, or la version de redis qui tourne actuellement sur LinuxFr.org ne prend pas en charge cette fonctionnalité ;

C'est "prévu" : le script tente d'utiliser le code lua, et passe par le code ruby si ce n'est pas possible. C'est possible grâce au bloc begin, qui va tomber dans le cas rescue si la commande eval n'existe pas sur le serveur. Le jour où le serveur évoluera, le script marchera.

D'ailleurs, le site officiel de Redis dit qu'il ne serait pas impossible que les transactions deviennent un jour obsolètes, en faveur des scripts lua. Je me prépare à l'avenir =]

ça passe par le hub de google, alors que l'on essaye d'éviter les services centralisés,

Judicieuse remarque, mais :

• On ne perd strictement aucune fonctionnalité, et il n'y a aucune dépendance. Si le hub tombe, l'aggrégateur RSS peut toujours poller le flux directement chez LinuxFr.org
• On peut définir autant de hubs que l'on veut (solution partielle, mais potentiellement gratuite : SuperFeedr et Ayup! fournissent un service de publication qui ne coûte rien)
• LinuxFr.org peut avoir son propre hub (ça demanderait quand même du développement et des ressources à l'utilisation, certes)

tout particulièrement ceux de grosses sociétés pas très respectueuses de la vie privée de ses utilisateurs.

Il s'agit là de flux publiquement accessibles à n'importe quel passant, la vie privée de personne n'est en jeu. Et puis, si Google peut indexer les flux concernés quand on lui dit qu'il y a du nouveau contenu au lieu de poller constamment le site, ça peut être intéressant. Mais je comprends tout à fait le fond du message et suis d'accord.

À vrai dire, il y a un petit quelque chose qui m'embête vraiment :

error = begin
         Redis::CommandError
       rescue NameError
         RuntimeError # Dirty dirty hack for redis gem before 3.0
       end

Il s'agit de l'erreur que l'on doit matcher dans le rescue dont on parle plus haut. Catcher une RuntimeError me déplait au plus haut point, parce que c'est une erreur qui peut arriver de n'importe quoi. Ce qu'il faudrait c'est upgrader la gem redis à au moins 3.0.0, qui introduit Redis::CommandError et qui me plaît largement plus, parce que c'est exactement ce que l'on veut.

Ou alors enlever carrément toute la partie script et la remettre le jour où on aura une version plus récente de Redis ?

Sinon, c'est sympa d'avoir proposé un patch

Ça ne paiera pas la bande passante dont j'ai abusé, mais ça me fait plaisir =]

Ah! Je ne savais même pas que cette solution existait. Il semble donc que j'aie posté au mauvais endroit. Merci !

Ce serait effectivement un moyen très sympathique. Le problème est qu'il faudrait adapter l'usage des suiveurs qui n'utilisent pas un MUA pour lire leurs flux Atom. PubSubHubBub a l'avantage d'être rétro-compatible avec le système existant.

Aaaah. Ce codec annonce de grande choses sympathiques pour la diffusion temps-réel, et, top cool, quelques entreprises ont pensé à nous :

Un codec libre est difficile à obtenir, surtout vu le nombre de brevets, la plupart futiles, qui encombrent ce domaine.

Bien, donc si on veut implémenter dans notre coin, il va nous falloir demander l'avis de ces dépositaires pour diffuser. Super.

Plus simple : utilise ta branche master comme base commune entre toutes tes machines, et une branche par machine. Lorsque tu veux ajouter un fichier à toutes les configs, tu le commit dans master et tu merge master dans chaque branche.

Le vrai changement serait de séparer le fond et la forme et de permettre aux utilisateurs de se focaliser vraiment sur le fond et laisser la forme à l'ordinateur.

Dans l'absolu c'est ce que fait déjà Latex. Mais pour aller plus loin, on obtient des résultats vraiment intéressants avec txt2tags. Il y a sûrement d'autres langages de balisage pour faire la même chose, mais celui-là est vraiment bien fait.

M'est avis qu'il y aura toujours le sentiment de sécurité basé sur l'obfuscation. "Si les pirates chinois du FBI ne peuvent pas voir le code, alors ils ne pourront pas le cracker."

Je vois mal une institution administrative comprendre que cette sécurité est toute relative.

Il y a peut-être aussi la liberté de pouvoir coder sans se soucier de la qualité, puisque personne ne pourra le voir.

Il y aura peut-être également la possibilité d'utiliser des briques logicielles propriétaires, non compatibles avec d’éventuelles briques GPL.

C'est pas a ça que sert le vala? Simplifier le développement ?

Tiens, j'aimerais savoir: il m'a l'air d'avoir un sacré caractère ce monsieur, donc est-ce que RH lui dit ce qu'il doit coder, ou est-ce qu'il fait plutôt ce qu'il veut (et pense être bon) et est force de proposition chez RH ?

Par exemple, Linus a un contrat avec la Linux Foundation qui dit qu'il a le droit de faire ce qu'il veut. Donc il "bosse" pour eux, mais fait ce qu'il veut.

La BnF a également un rôle de conservation des écrits. Et j'imagine qu'ils ont plus confiance en leur propre capacité de conservation d'un tel ouvrage par rapport à un particulier. Pour le coup, je suis d'accord pour que le livre soit conservé par elle.

L'histoire de distribution du contenu est tout autre.

Sa position, si je la résume, m'a l'air de tout à fait tenir :

"Si vous voulez rendre systemd compatible avec d'autres noyaux, ça va créer un machin horrible à maintenir, je ne veux pas le faire. Mais quiconque veut le faire peut"

Autrement dit : le systemd de Lennart ne sera pas compatible avec autre chose que Linux, mais rien n'empêche JohnDoe de créer JDsystemd qui sera compatible avec tous les noyaux, et qui peut même être accepté partout.

C'est incroyable ça. Le type fait le logiciel comme il l'entend, il le rend dispo à tout le monde, mais on trouve le moyen de se plaindre de lui parce qu'il ne veut pas bosser à l'oeil pour son propre noyau.

Bon sang, systemd est même sous LGPL, qui contient quand même ce bout en ALL CAPS :

COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

Si ça ne fait pas ce que tu veux, dommage pour toi, Lennart et les contributeurs ne te doivent rien. Forke donc !

Le débat NC vs DP est un troll qui n'intéresse que les mouchophiles d'ici… […] alors que toute personne normale aurait besoin de 3h d'explications pour saisir la différence.

Ça tombe "bien", les gens qui décident de la licence de ces œuvres sont des gens dont la préoccupation est la diffusion de la culture, pas de simples gens normaux qui veulent juste consommer. Et ce qui est grave c'est que malgré leur rôle primordial, ils privilégient les intérêts privés de la BnF (oui, ça a l'air d'exister) aux intérêts publics.

Ça c'est sûr, les MACistes adorent !

Réussir une attaque DOS se résume à trouver un objet assez lourd pour maintenir la touche F5 enfoncée.

Vérifié en pratique

Juste pour te contredire, je tape en aveugle, donc je n'en ai pas besoin. Mais si tu peux y trouver des usages, tant mieux pour toi =]

$ emacs --help
[…]

Run M-x info RET m emacs RET m emacs invocation RET inside Emacs to
read the main documentation for these command-line arguments.

Justement, Nvidia dépend du noyau linux et de X. Autrement dit, peu de choses qui font une distribution; c'est assez dépendant. C'est du coup beaucoup plus facile de le porter vers d'autre distributions. À l'opposé, regarde les dépendances de Firefox, et dis-toi que chacune de ces dépendances doit être remplie pour faire marcher Firefox sur une autre distribution que l'originale.