BFG a écrit 904 commentaires

Est-il possible de faire quelque chose comme ça :

fac n = fact 1 1 n
fact acc i n = fact (acc * i) (i + 1) n
fact acc n n = acc

? Si oui, ce serait directement en correspondance avec la version en boucle for. (D'un lointain souvenir, il me semble que les boucles for/while sont un cas particulier des récursions (et plus précisément des récursions terminales))

Je serais toujours plus enclin à considérer comme de l'art un tableau sur lequel le gars a bossé des années qu'un truc qu'un péquenot a mis trois minutes à poser genre deux clous sur une chaise.

Et qui vous dit que ces "trois minutes pour poser deux clous" ne sont pas l'aboutissement d'années de réflexion, de travail et autre ?

Bien entendu la clef publique, mais elle n'est pas disséminée partout pour autant, tout comme l'adresse IP, qui est visible par le réseau auquel on se connecte, mais qui, au contraire d'une clef publique GPG, n'est pas accessible dans un annuaire public.

Ce qui est hébergé chez GitHub n'est pas privé comme des emails. Les seules choses privées que conserve GitHub sont les mots de passes, les adresses IP et les clefs SSH.

Je n'en compte que 5 de différentes.

Je vous invite à tester vous même. On obtient bien une distance de 7.

les journaux sont modifier avant de passer en dépêche (correction d'orthographe mais aussi de contenu si c'est nécessaire)

Même après publication, une dépêche est parfois (souvent ?) modifiée après que certains commentaires font une remarque sur une faute passée inaperçue, un lien en plus proposé, etc., donc c'est déjà le cas, et les commentaires ne sont pas supprimés après modification de la dépêche.

ce qui rendrait beaucoup de commentaires hors-sujet s'ils étaient inclus dans les commentaires de la dépêche.

Là, je ne suis pas d'accord sur la proportion. À mon avis, ce ne serait qu'une faible quantité de commentaires qui seraient touchés.

Quand un commentaire est édité par son auteur, c'est clairement indiqué, or ce n'est pas le cas ici. Et sinon, un commentaire n'est plus éditable passé 5 minutes.

rsync transfert les fichiers modifiés et rdiff les bouts de fichiers modifiés

rsync transfère les parties de fichiers modifiées, tout comme rdiff-backup. Ce qu'apporte rdiff-backup, ce sont les sauvegardes incrémentales, qui vous permettent de restaurer d'anciennes versions de fichiers par exemple.

Toutefois, dans la dépêche nous pourrons inclure un lien pointant vers le journal initial. L’ajout de commentaires sur le journal initial pourrait même être interdit.

Cela couperait les fils de discussions qui existaient déjà dans le journal. De manière générale, et dans l'état actuel, ça découpe l'information en deux, il faut aller voir les commentaires du journal et de la dépêche, et cette division actuelle est vraiment pénible aussi bien à la lecture que pour ceux qui participent aux commentaires.

Pourquoi ne pas simplement réellement transformer le journal en dépêche ? Que tous les commentaires soient transférés du journal à la dépêche ? En quelque sorte, changer le type de "journal" en "dépêche" et ne faire aucun autre changement.

C'est aussi peu flexible que la version Templeet ?

Par "xor", vous pensez au masque jetable (One Time Pad) ?

Vous répondez

Faux. Aujourd'hui, on utilise aussi Google pour aller sur un site que l'on connaît

à mon message qui disait

la barre d'adresse, c'est pour accéder à un site que l'on connait (que l'on tape son adresse ou que cela passe par Google),

J'ai du mal à voir en quoi cela me contredit, surtout que la partie importante de mon message était la suite du message, à savoir que quand l'on est sur un site (sans compter Google), et que l'on clique sur un hyperlien, que ce soit un lien interne au site, ou un lien vers un autre site, on utilise le DNS, sans utiliser Google.
Ma simplification consistait à dire que Google ne remplaçait DNS qu'au début d'une session de navigation : vous ouvrez Google et tapez "linuxfr" : OK, vous avez utilisé Google au lieu de taper linuxfr.org. Une fois sur LinuxFR, vous cliquez sur "journaux" pour voir les nouveaux journaux que vous ne connaissez pas : vous ne passez pas par Google ; ce présent journal contient un lien vers 42registry, vous cliquez sur le lien : vous ne passez pas par Google.

Un langage qui se veut générique de toute utilisation doit développer des idiomes propres, qui font l'intérêt d'un langage. Et ces idiomes ne sont pas que des idiomes locaux mais peuvent changer complètement la conception du code. Si une conversion automatique transformait le C++ en Rust, ce ne serait qu'une transformation de syntaxe, ce qui n'apporterait donc strictement rien.
D'ailleurs, découvrir les nouvelles possibilités et usages de Rust va prendre un certain temps, comme pour tout langage. Passer directement Firefox à Rust — que ce soit par conversion automatique ou par réécriture par des humains — dès Rust inventé ne serait rien de plus qu'une expérience, qui à mon avis se solderait par de mauvais résultats dus à la méconnaissance (forcée) de Rust.

Pour ma part, me fixer ce genre d'objectif m'évite le syndrome boulimique qui consiste à lancer un jeu, tester quelques heures, puis passer à autre chose...

Je ne comprends pas bien, si votre façon naturelle de jouer est de changer de jeu après quelques heures, en quoi est-ce un problème, pourquoi en changer ?

qui vont entraîner une autre façon de jouer et inciter les joueurs à tester plus de choses

C'est ce que j'appelle "manque d'imagination de certains joueurs". Je pense pourtant que les joueurs sont capables de trouver bien des choses que les développeurs n'ont même pas soupçonné, comme par exemple le rocketjump de Quake.

Voir également ce qu'en dit Mailinator.

Le problème est que "Qt" a l'air de désigner bien d'autres choses aussi.

J'ajouterais qu'un email n'est pas Twitter, et que la limite de longueur est à mon avis un peu plus élevée. Que diriez-vous d'une recommandation de limitation à 80 caractères (valeur complètement arbitraire), avec dépréciation de tout ce qui cause des échappements ? Actuellement sur DLFP, une simple apostrophe devient "%27", et une apostrophe française devient "%E2%80%99" !
Il est vrai qu'il est dommage de devoir se passer d'accents et apostrophes, car cela réduit la lisibilité, mais c'est un moindre mal. Et nous avons de la chance, le français utilise beaucoup les lettres A à Z, ma suggestion ne conviendrait pas pour un site japonais (il faudrait en venir à la translittération).

http://linuxfr.org/n/78ajdf

Je trouve que quelque chose comme http://linuxfr.org/n/120122/1 (contenant la date et éventuellement un autre identifiant) serait suffisamment court et cependant beaucoup plus parlant. Aussi, à la création de la dépêche, on pourrait en option spécifier une URL avec un préfixe imposé (par exemple : "/news/120122/plainte-astrologie-tzdata", seule la partie après le dernier slash est modifiable).

Si certaines urls sont vraiment longues (comme celle que vous prenez en exemple, et pas vraiment parlantes à cause de l'échappement des accents français), je pense que les urls ne doivent pas tomber dans l'excès inverse au point qu'elles n'aient plus aucun sens (comme "/n78ajdf").
Personnellement, je lis souvent l'url avant de cliquer sur un lien, ça me permet d'avoir déjà une idée, et même de savoir si j'ai déjà lu cette page (oui, je conserve une sorte d'historique dans ma tête, je m'en sers en plus de la coloration par le navigateur des liens déjà visités).

Bienvenue dans HTML 5.0, le nouveau standard qui établit un nouveau record d'alourdissement du logiciel du Web 2.0.

Google Trends ne remonte qu'à 2004...

On croyait avoir touché le fond, mais certains creusent encore !

(Pour rire) Je ne dirais pas ça, car les hardcore gamers aiment bien se faire souffrir.

En simplifiant énormément : la barre d'adresse, c'est pour accéder à un site que l'on connait (que l'on tape son adresse ou que cela passe par Google), et pour accéder à une page que l'on ne connait pas, on suit un hyperlien sans passer par Google (que ce soit un lien sur un site ou dans un email ou autre).

Il me revient que Stack Overflow fait aussi une place aux badges.

Je pense que l'objectif est d'encourager les casual gamers à continuer, et d'éviter qu'ils se sentent mauvais par rapport au jeu. Les hardcore gamers n'ont pas besoin de ce genre de carotte. Or aujourd'hui les premiers sont de plus en plus ciblés par l'industrie du jeu.

Je pense aussi qu'il y a un calcul coût / bénéfice chez les développeurs de jeu. Ce genre de choses (les achievements) ne coûte pas grand'chose à ajouter, et ne présente pas d'inconvénient rédhibitoire, donc autant les ajouter au cas où.

Je n'avais effectivement pas pensé à cet aspect là.

casual gamers

Que diriez-vous de "joueurs occasionnels" ? "Joueurs du dimanche" ?

hardcore gamers

"Joueurs passionnés" ? "Joueurs endurcis" ?

Soit. Le seul intérêt est de faire un clin d’œil au joueur quant à ce qu'il vient de faire ? C'est un peu mieux mais tout de même bien limité.