Pour la nature du terrain, je suis allé regarder, le lien ci-dessus n'est pas le bon : « Information about the physical surface of roads/footpaths and other features ». Donc je crois qu'il faut utiliser la balise "natural" et non "surface".
En fait, j'ai trouvé une page exactement sur le sujet : [http://wiki.openstreetmap.org/wiki/Mountain_mapping]. Si j'en crois cette page, la description des montagnes n'est pas encore standardisée et plusieurs points sont en discussion. Et ils ne parlent pas encore du balisage des GR par rapport aux autres sentiers ;-)
Non, c'est logique qu'il compare le site mentionné dans la dépêche, OpenStreetMap, avec le site de référence pour la rando, Geoportail. Il semble donc que "syj" n'utilise (malheureusement) pas "maps.refuges.info".
Au passage, je doute de l'affirmation : il "suffit de mettre [ce qui manque] dans la base". Comme son nom l'indique, OpenStreetMap n'a pas été conçu pour cartographier la campagne. Existe-t-il un système libre où l'on puisse inscrire tout ce que contient une carte top 25 ? Par exemple, la nature du terrain (type de végétation, pierrier...), la présence de sources, de barres rocheuses, de rochers remarquables, etc.
Pour en revenir au fond, j'ai cherché à savoir dans quelle mesure la stabilité de Ruby 1.9 avait progressé. Le fichier "NEWS" n'en parle pas (ou alors j'ai raté le passage à ce sujet). Le changelog ne fait pas référence à un bugtracker ou à des tests unitaires, donc rien d'évaluable de ce côté là. Sans vouloir dénigrer le message initial, je suis un peu dubitatif (j'ai toujours du mal à croire sur parole).
A titre perso, le langage Ruby me plaît globalement. En dehors de quelques détails, mes principales critiques allaient à la documentation officielle (peu d'exemples, description parfois incomplète, pas de références SeeAlso, "ri" n'est pas terrible, etc.) et à l'API standard (fileutils et Cie déclenchent des tonnes d'avertissements en mode debug, REXML est pénible, l'abstraction d'accès SQL est instable et mal documentée, etc.). Mais, comparés à la recherche de performance, ce ne sont pas des sujets très motivants pour les développeurs de Ruby (j'aime pas non plus écrire de la doc).
rares sont les développeurs à les avoir utilisées.
Ou "peu nombreux sont...", mais c'est plus lourd, et ça sent un peu la traduction du "few" anglais.
Puisqu'on est dans les détails, c'est étonnant de constater la quasi disparition du mot "progrès", au profit du néologisme "avancée" : « apporter les dernières avancées techniques à Ruby ».
Ce sens de "avancée" ne figure même pas dans mon Petit Robert de 1996, bien qu'il soit apparu dans le vocabulaire journalistique depuis quelques décennies.
Pas perdu, un dromadaire est juste un chameau un peu particulier.
Il fut un temps où l'on ne disait pas "dromadaire", mais "chameau dromadaire" (Cf Littré http://francois.gannaz.free.fr/Littre/xmlittre.php?requete=chameau ).
> >> La manipulation inverse, retrouver le code compréhensible depuis le code machine est impossible
>Faux, dans la mesure où l'on peut écrire du code machine directement, juste à l'aide de mnémoniques (quiconque a fait de l'ASM sur HP48 versera une larme nostalgique). Un desassembleur donnera donc le code source.
> Le problème est que l'on perd le recul qui permet de comprendre le « grand design » et que l'on a juste accès à une information dont le grain est trop fin.
La phrase de départ me semble totalement juste : on ne peut remonter au code source à partir du code machine.
Le cas litigieux d'un programme écrit en assembleur n'est à mon sens même pas une exception. D'abord parce qu'il est très rare, et presque toujours sur des portions de programme uniquement. Et ensuite parce que le code source utilise par exemple des macros qui seront pas déductibles du code machine. Enfin, de l'assembleur sans commentaire est vite épuisant. Le code désassemblé est donc différent du code source.
Il y a quelques années, j'ai passé des journées entières sur du code désassemblé (IDA rulez!), dans des débogueurs (Softice) et à écrire de l'ASM i86 (ah, l'apparition du "memory flat mode" sur i286 !). On en vient même à connaître les opcodes (74 03). Mais le code source, c'est plus que des opcodes.
> Mon ordinateur ne comprend pas plus le C que les chiffres
Pas d'accord. Un ordinateur ne comprend que les chiffres. Que tu les représentes en binaire, en hexadécimal ou en décimal ne change rien. Si tu édites un fichier quelconque dans un éditeur hexa, tu ne verras que des chiffres. C'est le rôle de l'ordinateur de traduire, dans certains cas, ces chiffres en instructions.
Le document d'origine n'est pas parfait, mais il ne faut pas aller lui chercher des poux sur les orteils. Surtout quand on n'a pas ses lunettes ;-)
Ces récompenses Big Brothers me semblaient plutôt justifiées, et leur côté très politique ne me gênait pas. Mais quand à la fin de la liste, j'ai vu que PMO a été récompensé pour « son minutieux travail d’information et de réflexion » j'ai hésité entre le fou-rire et l'agacement. Du coup, j'ai des doutes sur l'ensemble.
J'avais reçu par mail un texte de PMO il y a quelques années. Comme il m'était envoyé par un ami, j'avais un a priori positif. Mais après avoir lu cette logorrhée d'une dizaine de pages, je n'avais plus aucune considération pour eux. Cela manquait de rigueur sur les faits comme sur les raisonnements, et développait en plus des amalgames assez malhonnêtes. Le tout noyé dans des pages de baratin hors sujet. Un petit tour sur leur site web permet de constater que toute leur production est du même tonneau.
Quand une dizaine de militants gauchistes (c'est pas péjoratif !) se réunit pour donner des récompenses, ça ne vaut pas mieux que quand d'anciens députés norvégiens attribuent un prix Nobel de la paix.
[^] # Re: La montagne, ça vous perd
Posté par rogo . En réponse à la dépêche syj: site de partage d'itinéraire. Évalué à 2.
En fait, j'ai trouvé une page exactement sur le sujet : [http://wiki.openstreetmap.org/wiki/Mountain_mapping]. Si j'en crois cette page, la description des montagnes n'est pas encore standardisée et plusieurs points sont en discussion. Et ils ne parlent pas encore du balisage des GR par rapport aux autres sentiers ;-)
[^] # Re: La montagne, ça vous perd
Posté par rogo . En réponse à la dépêche syj: site de partage d'itinéraire. Évalué à 3.
Au passage, je doute de l'affirmation : il "suffit de mettre [ce qui manque] dans la base". Comme son nom l'indique, OpenStreetMap n'a pas été conçu pour cartographier la campagne. Existe-t-il un système libre où l'on puisse inscrire tout ce que contient une carte top 25 ? Par exemple, la nature du terrain (type de végétation, pierrier...), la présence de sources, de barres rocheuses, de rochers remarquables, etc.
# Quels progrès de stabilité ?
Posté par rogo . En réponse à la dépêche Sortie de Ruby 1.9.2. Évalué à 4.
Pour la performance, on peut regarder les benchmarks de Debian (avec toutes les restrictions d'usage sur le sens de ces mesures) :
http://shootout.alioth.debian.org/u32/benchmark.php?test=all(...) (à ce jour, Ruby 1.9.2 / Ruby 1.8.7)
A titre perso, le langage Ruby me plaît globalement. En dehors de quelques détails, mes principales critiques allaient à la documentation officielle (peu d'exemples, description parfois incomplète, pas de références SeeAlso, "ri" n'est pas terrible, etc.) et à l'API standard (fileutils et Cie déclenchent des tonnes d'avertissements en mode debug, REXML est pénible, l'abstraction d'accès SQL est instable et mal documentée, etc.). Mais, comparés à la recherche de performance, ce ne sont pas des sujets très motivants pour les développeurs de Ruby (j'aime pas non plus écrire de la doc).
[^] # Re: Petite correction grammaticale
Posté par rogo . En réponse à la dépêche Sortie de Ruby 1.9.2. Évalué à 5.
rares sont les développeurs à les avoir utilisées.
Ou "peu nombreux sont...", mais c'est plus lourd, et ça sent un peu la traduction du "few" anglais.
Puisqu'on est dans les détails, c'est étonnant de constater la quasi disparition du mot "progrès", au profit du néologisme "avancée" : « apporter les dernières avancées techniques à Ruby ».
Ce sens de "avancée" ne figure même pas dans mon Petit Robert de 1996, bien qu'il soit apparu dans le vocabulaire journalistique depuis quelques décennies.
[^] # Re: quels chameaux ces dromadaires
Posté par rogo . En réponse à la dépêche Sortie de Rakudo Star. Évalué à 2.
Pas perdu, un dromadaire est juste un chameau un peu particulier.
Il fut un temps où l'on ne disait pas "dromadaire", mais "chameau dromadaire" (Cf Littré http://francois.gannaz.free.fr/Littre/xmlittre.php?requete=chameau ).
[^] # Re: Commentaires
Posté par rogo . En réponse à la dépêche Le logiciel libre : comment ça marche ?. Évalué à 3.
> >> La manipulation inverse, retrouver le code compréhensible depuis le code machine est impossible
>Faux, dans la mesure où l'on peut écrire du code machine directement, juste à l'aide de mnémoniques (quiconque a fait de l'ASM sur HP48 versera une larme nostalgique). Un desassembleur donnera donc le code source.
> Le problème est que l'on perd le recul qui permet de comprendre le « grand design » et que l'on a juste accès à une information dont le grain est trop fin.
La phrase de départ me semble totalement juste : on ne peut remonter au code source à partir du code machine.
Le cas litigieux d'un programme écrit en assembleur n'est à mon sens même pas une exception. D'abord parce qu'il est très rare, et presque toujours sur des portions de programme uniquement. Et ensuite parce que le code source utilise par exemple des macros qui seront pas déductibles du code machine. Enfin, de l'assembleur sans commentaire est vite épuisant. Le code désassemblé est donc différent du code source.
Il y a quelques années, j'ai passé des journées entières sur du code désassemblé (IDA rulez!), dans des débogueurs (Softice) et à écrire de l'ASM i86 (ah, l'apparition du "memory flat mode" sur i286 !). On en vient même à connaître les opcodes (74 03). Mais le code source, c'est plus que des opcodes.
> Mon ordinateur ne comprend pas plus le C que les chiffres
Pas d'accord. Un ordinateur ne comprend que les chiffres. Que tu les représentes en binaire, en hexadécimal ou en décimal ne change rien. Si tu édites un fichier quelconque dans un éditeur hexa, tu ne verras que des chiffres. C'est le rôle de l'ordinateur de traduire, dans certains cas, ces chiffres en instructions.
Le document d'origine n'est pas parfait, mais il ne faut pas aller lui chercher des poux sur les orteils. Surtout quand on n'a pas ses lunettes ;-)
# Ça commençait bien, mais ça part en sucette
Posté par rogo . En réponse à la dépêche Big Brother Awards 2010. Évalué à 4.
J'avais reçu par mail un texte de PMO il y a quelques années. Comme il m'était envoyé par un ami, j'avais un a priori positif. Mais après avoir lu cette logorrhée d'une dizaine de pages, je n'avais plus aucune considération pour eux. Cela manquait de rigueur sur les faits comme sur les raisonnements, et développait en plus des amalgames assez malhonnêtes. Le tout noyé dans des pages de baratin hors sujet. Un petit tour sur leur site web permet de constater que toute leur production est du même tonneau.
Quand une dizaine de militants gauchistes (c'est pas péjoratif !) se réunit pour donner des récompenses, ça ne vaut pas mieux que quand d'anciens députés norvégiens attribuent un prix Nobel de la paix.