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.
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 ?
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.
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).
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).
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).
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" ?
mais par exemple finir un niveau sans être touché,...
C'est un classique des anciens jeux de combats, qui correspond bien à la définition d'un haut-fait.
Cependant, cette mode actuelle des hauts-faits a une différence avec ce que l'on pouvait trouver avant. Elle nivelle beaucoup par le bas : il y en a toujours une grande quantité, pour une qualité très très basse. 394 succès pour TF2 ! 378 pour StraCraft 2 [la page est organisée en sous-listes] ! 49 pour Magicka. J'ai pris différents types de jeu, je n'ai même pas cherché à choisir les pires exemples.
Je vous invite à survoler ces listes et juger combien sont vraiment intéressants.
De ce que je lis, la majorité d'entre eux consiste (en caricaturant à peine) "passer le niveau 1", ou bien "passer des heures et des heures sur le jeu". Le jeu manque tellement d'intérêt qu'il faut inventer des récompenses juste pour avoir "testé 10 fois chaque mode de jeu" ?
Que dire des "haut-faits" qui suggèrent "battre un ennemi de <telle façon relativement improbable>" ? Faut-il à ce point assister le joueur dans son plaisir ? Ça me fait furieusement penser à des rires enregistrés.
Tiens, je ne savais pas qu'il était possible d'associer des mots-clefs aux moteurs de la barre de recherche. Je connaissais les mots-clefs associés aux marques-pages.
Dommage que les deux fonctions ne soient pas plus unifiées que ça (par exemple que les marques-pages ayant un mot-clef soient présents dans la barre de recherche, et que la barre d'adresse indique qu'elle a reconnu un mot-clef non plus uniquement avec les marques-pages).
[^] # Re: Une déception de plus...
Posté par BFG . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 0.
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.
[^] # Re: Légalité ?
Posté par BFG . En réponse au journal Black march. Évalué à 3.
Je vous invite à tester vous même. On obtient bien une distance de 7.
[^] # Re: Déplacer au lieu de copier
Posté par BFG . En réponse à l’entrée du suivi Masquer le journal initial, lorsqu'une dépêche en est issue.. Évalué à 1 (+0/-0). Dernière modification le 24 janvier 2012 à 00:35.
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.
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.
[^] # Re: mémé du cantal
Posté par BFG . En réponse au journal Vers la fin du direct download ?. Évalué à 3.
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.
[^] # Re: --linkdest
Posté par BFG . En réponse au journal Synchroniser deux répertoires rdiff-backup. Évalué à 7.
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.
# Déplacer au lieu de copier
Posté par BFG . En réponse à l’entrée du suivi Masquer le journal initial, lorsqu'une dépêche en est issue.. Évalué à 3 (+0/-0). Dernière modification le 23 janvier 2012 à 17:43.
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 ?
[^] # Re: C'est un peu comme l'hydre tout ça
Posté par BFG . En réponse au journal Vers la fin du direct download ?. Évalué à 1.
Par "xor", vous pensez au masque jetable (One Time Pad) ?
[^] # Re: Le DNS? on s'en ...., on a Google
Posté par BFG . En réponse au journal De la possibilité de décentralisation de la gestion des noms de domaine. Évalué à 3.
Vous répondez
à mon message qui disait
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.
[^] # Re: Pour quoi faire?
Posté par BFG . En réponse à la dépêche Sortie de la version 0.1 de Rust. Évalué à 6.
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.
[^] # Re: "Achievements"
Posté par BFG . En réponse au journal Microsoft Visual Studio Achievements. Évalué à 2.
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 ?
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.
[^] # Re: Ou pas ?
Posté par BFG . En réponse au journal Sus aux threads. Évalué à 2.
Voir également ce qu'en dit Mailinator.
[^] # Re: Pas mal du tout
Posté par BFG . En réponse au message Connaitre la migration de personne d'un communauté à une autre. Évalué à 2.
Le problème est que "Qt" a l'air de désigner bien d'autres choses aussi.
[^] # Re: Lien court
Posté par BFG . En réponse à l’entrée du suivi Faire des liens courts pour accéder aux dépêches. Évalué à 2 (+0/-0). Dernière modification le 22 janvier 2012 à 16:33.
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).
# Lien court
Posté par BFG . En réponse à l’entrée du suivi Faire des liens courts pour accéder aux dépêches. Évalué à 3 (+0/-0). Dernière modification le 22 janvier 2012 à 16:16.
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).
[^] # Re: ca fait peur
Posté par BFG . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 3.
Bienvenue dans HTML 5.0, le nouveau standard
qui établit un nouveau record d'alourdissement du logicieldu Web 2.0.[^] # Re: ok Merci
Posté par BFG . En réponse au message Connaitre la migration de personne d'un communauté à une autre. Évalué à 3.
Google Trends ne remonte qu'à 2004...
[^] # Re: rigolo
Posté par BFG . En réponse au journal Microsoft Visual Studio Achievements. Évalué à 1.
On croyait avoir touché le fond, mais certains creusent encore !
[^] # Re: "Achievements"
Posté par BFG . En réponse au journal Microsoft Visual Studio Achievements. Évalué à 4.
(Pour rire) Je ne dirais pas ça, car les hardcore gamers aiment bien se faire souffrir.
[^] # Re: Le DNS? on s'en ...., on a Google
Posté par BFG . En réponse au journal De la possibilité de décentralisation de la gestion des noms de domaine. Évalué à 4.
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).
[^] # Re: "Achievements"
Posté par BFG . En réponse au journal Microsoft Visual Studio Achievements. Évalué à 3.
Il me revient que Stack Overflow fait aussi une place aux badges.
[^] # Re: "Achievements"
Posté par BFG . En réponse au journal Microsoft Visual Studio Achievements. Évalué à 2.
Je n'avais effectivement pas pensé à cet aspect là.
Que diriez-vous de "joueurs occasionnels" ? "Joueurs du dimanche" ?
"Joueurs passionnés" ? "Joueurs endurcis" ?
[^] # Re: "Achievements"
Posté par BFG . En réponse au journal Microsoft Visual Studio Achievements. Évalué à 1.
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é.
[^] # Re: "Achievements"
Posté par BFG . En réponse au journal Microsoft Visual Studio Achievements. Évalué à 2. Dernière modification le 21 janvier 2012 à 21:40.
C'est un classique des anciens jeux de combats, qui correspond bien à la définition d'un haut-fait.
Cependant, cette mode actuelle des hauts-faits a une différence avec ce que l'on pouvait trouver avant. Elle nivelle beaucoup par le bas : il y en a toujours une grande quantité, pour une qualité très très basse. 394 succès pour TF2 ! 378 pour StraCraft 2 [la page est organisée en sous-listes] ! 49 pour Magicka. J'ai pris différents types de jeu, je n'ai même pas cherché à choisir les pires exemples.
Je vous invite à survoler ces listes et juger combien sont vraiment intéressants.
De ce que je lis, la majorité d'entre eux consiste (en caricaturant à peine) "passer le niveau 1", ou bien "passer des heures et des heures sur le jeu". Le jeu manque tellement d'intérêt qu'il faut inventer des récompenses juste pour avoir "testé 10 fois chaque mode de jeu" ?
Que dire des "haut-faits" qui suggèrent "battre un ennemi de <telle façon relativement improbable>" ? Faut-il à ce point assister le joueur dans son plaisir ? Ça me fait furieusement penser à des rires enregistrés.
[^] # Re: «achievement»
Posté par BFG . En réponse au journal Microsoft Visual Studio Achievements. Évalué à 3.
Tiens, je ne savais pas qu'il était possible d'associer des mots-clefs aux moteurs de la barre de recherche. Je connaissais les mots-clefs associés aux marques-pages.
Dommage que les deux fonctions ne soient pas plus unifiées que ça (par exemple que les marques-pages ayant un mot-clef soient présents dans la barre de recherche, et que la barre d'adresse indique qu'elle a reconnu un mot-clef non plus uniquement avec les marques-pages).
# FreeDB
Posté par BFG . En réponse au message Freedb-like mais pour toute sorte de fichiers?. Évalué à 3.
L'original s'appelle CDDB, dont le nom est sans doute plus connu. Sinon, non, je ne saurais pas répondre à votre question.