/mavie=ON
Je fait de la simulation numérique depuis fin 1999: en physique des plasmas tout d'abord puis maintenant en physique de la neige
/mavie=OFF
Evidement, sur de telles machines, on lance beaucoup de calculs en même temps, par beaucoup d'utilisateurs. Donc la machine ne reste ne général pas sans rien faire, il y a toujours des choses qui tournent dessus, voir une file d'attente de jobs à faire tourner (on travail en batch, donc on soumet un job, que le système exécute quand il le juge opportun. Il m'arrive d'attendre 3-4 jours avant que ma simulation ne passe).
Avoir une puissance crête importante permet de livrer des résultats plus rapidement. Si une simulation dure 2 semaines, "débugger" la simulation n'est pas vraiment agréable: on lance la simulation, on attend 2 semaines, on voit ce qui doit être amélioré, puis on relance... donc le cycle pour obtenir une simulation dont on est content peut durer des mois. Pendant ma thèse, je devais définir des expériences a faire à partir de simulations numériques (les expériences se faisaient sur Z, voir http://en.wikipedia.org/wiki/Z_machine). Vu que ~300 personnes étaient impliquées dans la réalisation d'une expérience, il est très important que l'on ait mis toutes les chances de son coté en définissant correctement l'expérience à faire (vu le coût). Je faisait alors une succession de simulations (de 2 semaines) pendant 3-4 mois. Une machine plus puissante permet de raccourcir ce délais, donc d'essayer plus de choses et de plus rapidement pouvoir définir la simulation finale. Aujourd'hui, j'ai encore des simulations qui durent 1-2 semaines (en physique de la neige) et il faut parfois attendre la toute fin d'une simulation pour se rendre compte que quelque chose ne va pas... (et donc corriger puis relancer la simulation).
Une plus grande puissance permet aussi de complexifier le modèle: dans notre modèle de manteau neigeux, nous voudrions ajouter le transport de la neige par le vent résolu en 3D (ce qui est important pour les avalanches). Mais une telle résolution 3D est extrèmement coûteuse en temps de calcul. Il faut donc que l'on parallelise le code qui gère cela (le reste du code étant déjà parallelisé), puis que l'on espère que notre cluster actuel soit suffisant pour les simulations que l'on veut faire (notre cluster compte ~400 coeurs). Si demain nous avions accès à un calculateur plus gros, on nous demanderait très rapidement d'augmenter la résolution, d'ajouter plus de physique dans le modèle, de simuler une surface plus importante, de coupler notre modèle avec un modele météo, etc
Enfin, la simulation ne sert pas uniquement pour étudier ce qui est inaccessible: c'est aussi un moyen d'étudier des scénarios (par exemple, l'impact des divers scénarios de changement climatique sur l'hydrologie d'un canton Suisse), d'isoler certains effets ou phénomènes physique (par exemple, quel est l'impact de la suspension de la neige dans l'air sur l'humidité de l'air), de valider un modèle (je fait une simulation à l'échelle d'un canton, avec comme seul données, les mesures météo sur un ensemble de stations. Si je suis capable de simuler la décharge des cours d'eau telle qu'elle est mesurée, cela montre que mon modèle n'est pas totalement stupide quand à la constitution et la fonte du manteau neigeux), donc notre compréhension des phénomènes, d'être guidés dans la compréhension des mesures (un pic de pression mesuré sur une manip avait pu être expliqué par l'arrivé de la couronne de plasma sur le capteur d'après une simulation 2D), d'affiner une stratégie de mesures (ou dois-je placer de nouvelles stations météo pour fournir le plus d'informations pertinentes quand à l'état des routes dans une vallée), etc.
Donc en gros, plus nous aurons de la puissance, plus nous lui trouverons des applications et plus ceux qui nous financent nous demanderons des calculs qui demandent plus de puissance!
bon, j'utilisais colorgcc et c'est colorgcc qui compilait (et linkais) les programmes de tests en mode C au lieux de c++... -> l'édition de lien ne marchait pas.
Donc j'ai supprimé colorgcc et tout va bien!
Merci pour la suggestion consistant à regarder dans config.log!
Mathias
Si cela est faisable pour toi, tu peux aussi désactiver l'authentification ssh par mots de passe et n'autoriser que les clefs. Depuis que je fais cela, je dors plus serein!
Évidement, il faut alors toujours avoir sa clef ssh avec soi pour pouvoir se connecter...
Je perçois aussi cette évolution, mais la raison me fait renoncer à mes inquiétudes: cela fait presque 10 ans que tous les pc de bureaux sont vendus avec une carte 3D, un petit peu moins pour les portables, ce qui signifie qu'il faut vraiment aller chercher du matériel vraiment ancien pour qu'il n'y ait pas d'accélération 3D basique. En même dans ce cas, on peut rajouter une carte 3D ancienne de récup.
Ce qui signifie que d'ici à très peu d'années, on ne rencontrera sans doute plus d'ordinateurs sans carte 3D basique, même pour du matériel suffisamment ancien pour qu'il ne coute plus rien ou pour une installation ancienne!
Mathias
PS: et j'ai maintenu un PC sur lequel une matrox millemium 1 tournais jusqu'à noël dernier, mais c'était vraiment par manque de temps pour mettre à jour...
Exactement, c'est ce qu'il dit: si X plante en visitant un site, c'est un bug de X (peut être aussi de firefox, mais certainement de X). X ne devrait pas tomber, le noyau ne devrait pas tomber, etc Tout comportement différent est un bug de l'étage qui tombe.
Je me suis acheté plusieurs de ces cables (il s'agit d'un cable micro-USB):
*un adaptateur mini-USB/micro USB, comme ça je prend un cable très commun (USB vers mini-USB puis avec un adaptateur de 10g et de 3 cm de long, j'en fait un cable USB vers micro-USB. Pratique pour utiliser le même cable pour mon N900 et mon appareil photo). Acheté dans un magasin d'élèctronique grand public (Interdiscount en Suisse)
*un cable USB/micro USB acheté lors d'un voyage en France pour me dépanner, chez Carrefour, rayon chargeurs de téléphones (et c'est un petit Carrefour)
Mon tour de m'essayer à un commentaire naïf... :-)
Au lieux de comptabiliser la somme du trafic sur 24 heures (qui est plus ou moins ce que tu proposes), ne vaut-il pas plutôt simplement partager la bande passante disponible? C'est à dire, au lieux de dire "A a téléchargé 1G cette nuit, donc B à doit à 1G tout de suite", simplement dire "A à droit à (bande passante disponible)/(nombre d'utilisateurs)", éventuellement moyenné sur les dernières 15 minutes (mais une telle répartition doit bein être déjà disponible quelque par comme configuration standard!).
Ceci revient à favoriser les gros usages de bande passante pendant les heures creuses (car il n'y a pas de compétition, donc beaucoup de débit disponible) et à pénaliser quelqu'un qui consommerais beaucoup quand tout le monde à besoin de la bande passante. Évidement, si il y a derrière une tarification à la quantité échangée, cela ne sert à rien (mais je doute que se soit le cas!)
Mathias
PS: c'est tellement naïf que je me dis que c'est ce qui doit être le comportement par défaut de partout, mais bon...
Désolé, mais ce genre de choses me choque complètement... J'ai des collègues qui indentent avec des tabs à 2 espaces. Avec une indentation aussi "subtile", je ne vois strictement rien à la structure du code. Donc je règle mes tabs à 6 ou 8 charactères. Et je n'ai pas à leur imposer mes choix...
Le boulot d'un bon éditeur n'est pas de m'imposer la façon dont je dois voir le code, mais de faire que l'indentation s'adapte à mon souhait, et que les alignements soient respectés. D'où mon choix d'indenter avec des tabs et d'aligner avec des espaces (la version "elastic tab stops" du pauvre).
Au lieux de mettre ces flags qui sont pour les includes et l'édition de liens dans le CFLAGS, fait plutôt quelque chose comme cela:
LIBS = -lmylib
INCLUDES = -L/path/to/mylib
LDFLAGS = $(INCLUDES) $(LIBS)
Et il ne faut effectivement pas faire ces modifs dans le Makefile mais tu peux les mettre dans le Makefile.in (à condition que celui-ci ne soit pas ré-généré à chaque fois). Sinon, ce sera dans le Makefile.am (que je n'ai jamais utilisé, je me fait mon Makefile.in à la main et configure génère le Makefile)
Ce n'est pas exactement la même chose qu'OpenMoko (il reste des firmwares pas libre), mais j'en suis très content, et on peut bien bidouiller avec (j'évite car je veux tout de même que le téléphone me serve toujours à passer des appels). On peux le garder sous Maemo, installer Android dessus, ou bien le passer sous Meego (le double boot est aussi possible).
Je n'ai rien fait de tout cela sur le mien (à nouveau, je n'ai pas d'autre téléphone), et mon seul regret est de ne pas avoir de gcc packagé pour compiler dessus.
Mathias
C'est quand même subtil... (en gros, je ne vois pas la différence. SI on me donnais les deux images en me demandant de dire qui est qui, j'en serais bien incapable).
Sur la page de WebP chez google, il y a des exemples bien plus parlants: à qualité égale, des tailles jusqu'à ~70% plus petites.
Je me suis fait un tel système avec ddwrt (http://www.dd-wrt.com/site/index). Il m'avait fallu un peu bricoler pour trouver les bons paramètres, mais du coup je capte un réseau wifi qui me fourni une adresse en 192.168.1.2 -> qq une de plus et je ré-émet sur un autre canal avec une plage d'adresses différente (192.168.1.200 et au delà) et un ssid différent.
Cela marche bien, sur un routeur WRT54GL avec QoS activé.
C'est un peu différent, mais cela marchera bien pour ton cas: j'ai des implémentation d'algo standards pour le calcul de "julian date", c'est à dire de nombre de jours depuis une date de référence (en l'occurance, 1er janvier -4713). Donc tu calcul le julian date du premier dimanche suivant ta date de départ, puis le dernier dimanche avant ta date d'arrivée, tu divise cela par 7 et tu as le nombre de semaines (donc de jours ouvrés) plus les offsets du départ et de l'arrivée.
L'algo:
long Date::getJulianDayNumber(const int& _year, const int& _month, const int& _day) const
622 { //given year, month, day, calculate the matching julian day
623 //see Fliegel, H. F. and van Flandern, T. C. 1968. Letters to the editor: a machine algorithm for processing calendar dates. Commun. ACM 11, 10 (Oct. 1968), 657. DOI= http://doi.acm.org/10.1145/364096.364097
624 const long lmonth = (long) _month, lday = (long) _day;
625 long lyear = (long) _year;
626
627 // Correct for BC years -> astronomical year, that is from year -1 to year 0
628 if ( lyear < 0 ) {
629 lyear++;
630 }
631
632 const long jdn = lday - 32075L +
633 1461L * ( lyear + 4800L + ( lmonth - 14L ) / 12L ) / 4L +
634 367L * ( lmonth - 2L - ( lmonth - 14L ) / 12L * 12L ) / 12L -
635 3L * ( ( lyear + 4900L + ( lmonth - 14L ) / 12L ) / 100L ) / 4L;
636
637 return jdn;
638 }
J'utilise indefero pour plusieurs projets, et j'en suis très content. Il n'y a peut être pas autant de fonctionnalités que chez sourceforge, mais le système fonctionne bien, est agréable à utiliser et propose les projets privés ce qui peut être un plus dans certains cas (en tous les cas, pour moi c'était une condition nécessaire: du coup les projets libres comme les projets non-libres sont hébergés de la même façon).
En suivant les instructions données pour ajouter ses propres règles, après ajout de linuxfr, on obtient une grosse liste de "www.linuxfr.org : potentially vulnerable to CVE-2009-3555". Sinon, ça a l'air de marcher!
oui, le lien wikipedia ne parle pas de "jour julien", mais c'est volontaire: ma reference de date n'est pas un jour julien mais bien une date julienne (ie: nombre de jours depuis -1483 ou quelque chose comme cela). Le jour julien est ensuite simplement le nombre de jours depuis le debut de l'annee (c'est pour moi l'un des formats de sortie de la librairie (entre autre pour des calculs de rayonnement solaire), mais en aucun cas le systeme de reference car il y a incertitude sur l'annee).
en fait, une "julian date" c'est le nombre de jour depuis le debut du calendrier julien, cf http://en.wikipedia.org/wiki/Julian_day . Et ce nombre de jour est code en flotant, ce qui permet aussi d'avoir l'huere, les minutes, etc dans le jour en question.
C'est en théorie netCDF (basé sur HDF5), mais dans la pratique, les données viennent des stations en ASCII, sont mises dans une base de donnee, puis utilisées directement depuis la base de donnée, ou bien via un web service, ou bien encore converties sous un format ascii quelconque. Les doonnées de prévisions sont plutot en GRIB. Dans la pratique, je n'ai encore jamais rencontré de données en netCDF ou HDF...
De plus, le format lui meme ne fait pas tout: il faut toujours filtrer les donnees, re-echantillonner, interpoler spatiallement, etc choses que fourni notre librairie. Les meta-donnes doivent aussi etre gérées (conversions entre des systemes de coordonnes geographiques potentiellement differents), on a souvent besoin de quelques manipulations simples sur le modele numerique de terrain, de gestion des dates (convertir d'une date "lisible" vers une date "julian date", voir autre systeme, de meme vers/a destination de posix, etc), choses que notre librarie fourni de facon integree et surtout transparente.
La doc doxygen est disponible sous forme d'une archive dans les téléchargements pour ceux qui voudraient jeter un oeil à la doc sans pour autant devoir télécharger les sources et faire générer la doc doxygen...
C'est une bonne nouvelle... (bon, pas pour tout le monde).
J'ai un N900 sous Maemo, et autant j'en suis pleinement satisfait, autant je me demande parfois si je n'aurai pas dû prendre un appareil sous Android (qui fait beaucoup de buzz comparé à un Maemo dont personne ne parle).
Avec ce genre de news, je me dit que finalement, avoir un appareil ou je peux mettre à jour ce que je veux, quand je veux, où la communauté est impliquée, c'est plutôt pas mal... (et dès que j'aurai à nouveau installé un package testing sur mon appareil, package qui me casse plein de trucs, j'aurai de nouveau des états d'âme... ce qui est particulièrement stupide, car je suis vraiment satisfait de mon choix 99% du temps)
Enfin si un jour quelqu'un parvient à installer des applications Android sur Maemo/MeeGo, cela serait vraiment le moyen d'avoir le meilleur des deux mondes!
J'utilise ssh (presque) toujours avec une authentification par clefs (et password désactivés) (cela évite de laisser des chances aux attaques standard sur les mots de passe). En plus, j'économise l'entrée d'un mot de passe à chaque connexion...
Après, pour ce qui est de transférer des fichiers, j'utilise parfois konqueror via son support de sftp (donc on se balade comme dans un système de fichier local). J'ai quelques liens ssh dans mes bookmarks, donc un seul clic et je suis dessus.
J'utilise indefero (4 projets hébergés, un mélange de projets privés et publiques, un mélange de membres (=dev), utilisateurs et invités) et j'en suis très satisfait.
J'ai téléchargé l'image en haute résolution, lu les articles donnés en référence (qui effectivement parent de Barbie sous Linux), mais dans aucun cas je ne suis parvenu à voir quoi que se soit qui montre qu'il s'agit de Linux...
Ou bien faut-il en conclure que «Geek-chic» == Linux ?? (qu'elle est loin l'image du barbu!)
[^] # Re: À quoi servent tous ces flops ?
Posté par Mathias Bavay (site web personnel) . En réponse à la dépêche Sortie du Top 500 de juin 2011. Évalué à 10.
/mavie=ON
Je fait de la simulation numérique depuis fin 1999: en physique des plasmas tout d'abord puis maintenant en physique de la neige
/mavie=OFF
Evidement, sur de telles machines, on lance beaucoup de calculs en même temps, par beaucoup d'utilisateurs. Donc la machine ne reste ne général pas sans rien faire, il y a toujours des choses qui tournent dessus, voir une file d'attente de jobs à faire tourner (on travail en batch, donc on soumet un job, que le système exécute quand il le juge opportun. Il m'arrive d'attendre 3-4 jours avant que ma simulation ne passe).
Avoir une puissance crête importante permet de livrer des résultats plus rapidement. Si une simulation dure 2 semaines, "débugger" la simulation n'est pas vraiment agréable: on lance la simulation, on attend 2 semaines, on voit ce qui doit être amélioré, puis on relance... donc le cycle pour obtenir une simulation dont on est content peut durer des mois. Pendant ma thèse, je devais définir des expériences a faire à partir de simulations numériques (les expériences se faisaient sur Z, voir http://en.wikipedia.org/wiki/Z_machine). Vu que ~300 personnes étaient impliquées dans la réalisation d'une expérience, il est très important que l'on ait mis toutes les chances de son coté en définissant correctement l'expérience à faire (vu le coût). Je faisait alors une succession de simulations (de 2 semaines) pendant 3-4 mois. Une machine plus puissante permet de raccourcir ce délais, donc d'essayer plus de choses et de plus rapidement pouvoir définir la simulation finale. Aujourd'hui, j'ai encore des simulations qui durent 1-2 semaines (en physique de la neige) et il faut parfois attendre la toute fin d'une simulation pour se rendre compte que quelque chose ne va pas... (et donc corriger puis relancer la simulation).
Une plus grande puissance permet aussi de complexifier le modèle: dans notre modèle de manteau neigeux, nous voudrions ajouter le transport de la neige par le vent résolu en 3D (ce qui est important pour les avalanches). Mais une telle résolution 3D est extrèmement coûteuse en temps de calcul. Il faut donc que l'on parallelise le code qui gère cela (le reste du code étant déjà parallelisé), puis que l'on espère que notre cluster actuel soit suffisant pour les simulations que l'on veut faire (notre cluster compte ~400 coeurs). Si demain nous avions accès à un calculateur plus gros, on nous demanderait très rapidement d'augmenter la résolution, d'ajouter plus de physique dans le modèle, de simuler une surface plus importante, de coupler notre modèle avec un modele météo, etc
Enfin, la simulation ne sert pas uniquement pour étudier ce qui est inaccessible: c'est aussi un moyen d'étudier des scénarios (par exemple, l'impact des divers scénarios de changement climatique sur l'hydrologie d'un canton Suisse), d'isoler certains effets ou phénomènes physique (par exemple, quel est l'impact de la suspension de la neige dans l'air sur l'humidité de l'air), de valider un modèle (je fait une simulation à l'échelle d'un canton, avec comme seul données, les mesures météo sur un ensemble de stations. Si je suis capable de simuler la décharge des cours d'eau telle qu'elle est mesurée, cela montre que mon modèle n'est pas totalement stupide quand à la constitution et la fonte du manteau neigeux), donc notre compréhension des phénomènes, d'être guidés dans la compréhension des mesures (un pic de pression mesuré sur une manip avait pu être expliqué par l'arrivé de la couronne de plasma sur le capteur d'après une simulation 2D), d'affiner une stratégie de mesures (ou dois-je placer de nouvelles stations météo pour fournir le plus d'informations pertinentes quand à l'état des routes dans une vallée), etc.
Donc en gros, plus nous aurons de la puissance, plus nous lui trouverons des applications et plus ceux qui nous financent nous demanderons des calculs qui demandent plus de puissance!
# colorgcc
Posté par Mathias Bavay (site web personnel) . En réponse au message Autotools cassés. Évalué à 2.
bon, j'utilisais colorgcc et c'est colorgcc qui compilait (et linkais) les programmes de tests en mode C au lieux de c++... -> l'édition de lien ne marchait pas.
Donc j'ai supprimé colorgcc et tout va bien!
Merci pour la suggestion consistant à regarder dans config.log!
Mathias
[^] # Re: SSHd
Posté par Mathias Bavay (site web personnel) . En réponse au message étrange historique root. Évalué à 1.
Évidement, il faut alors toujours avoir sa clef ssh avec soi pour pouvoir se connecter...
[^] # Re: Simplement tout faire par OpenGL
Posté par Mathias Bavay (site web personnel) . En réponse à la dépêche Firefox 4 et pilotes de cartes graphiques sous Linux. Évalué à 4.
Ce qui signifie que d'ici à très peu d'années, on ne rencontrera sans doute plus d'ordinateurs sans carte 3D basique, même pour du matériel suffisamment ancien pour qu'il ne coute plus rien ou pour une installation ancienne!
Mathias
PS: et j'ai maintenu un PC sur lequel une matrox millemium 1 tournais jusqu'à noël dernier, mais c'était vraiment par manque de temps pour mettre à jour...
[^] # Re: J'ai zappé un truc
Posté par Mathias Bavay (site web personnel) . En réponse au message Le js d'un formulaire d'un site web plante xorg. Évalué à 1.
[^] # Re: Flashage du N900
Posté par Mathias Bavay (site web personnel) . En réponse à la dépêche MeeGo 1.1 est disponible. Évalué à 2.
*un adaptateur mini-USB/micro USB, comme ça je prend un cable très commun (USB vers mini-USB puis avec un adaptateur de 10g et de 3 cm de long, j'en fait un cable USB vers micro-USB. Pratique pour utiliser le même cable pour mon N900 et mon appareil photo). Acheté dans un magasin d'élèctronique grand public (Interdiscount en Suisse)
*un cable USB/micro USB acheté lors d'un voyage en France pour me dépanner, chez Carrefour, rayon chargeurs de téléphones (et c'est un petit Carrefour)
/mavie
Mathias
[^] # Re: Une réponse
Posté par Mathias Bavay (site web personnel) . En réponse au message partager la bande passante d'une connection internet mutualisée ?. Évalué à 3.
Au lieux de comptabiliser la somme du trafic sur 24 heures (qui est plus ou moins ce que tu proposes), ne vaut-il pas plutôt simplement partager la bande passante disponible? C'est à dire, au lieux de dire "A a téléchargé 1G cette nuit, donc B à doit à 1G tout de suite", simplement dire "A à droit à (bande passante disponible)/(nombre d'utilisateurs)", éventuellement moyenné sur les dernières 15 minutes (mais une telle répartition doit bein être déjà disponible quelque par comme configuration standard!).
Ceci revient à favoriser les gros usages de bande passante pendant les heures creuses (car il n'y a pas de compétition, donc beaucoup de débit disponible) et à pénaliser quelqu'un qui consommerais beaucoup quand tout le monde à besoin de la bande passante. Évidement, si il y a derrière une tarification à la quantité échangée, cela ne sert à rien (mais je doute que se soit le cas!)
Mathias
PS: c'est tellement naïf que je me dis que c'est ce qui doit être le comportement par défaut de partout, mais bon...
# QoS
Posté par Mathias Bavay (site web personnel) . En réponse au message partager la bande passante d'une connection internet mutualisée ?. Évalué à 1.
Mathias
PS: je l'utilise via un router Linksys WRT54GL tournant sous ddwrt, c'est vraiment un gros plus pour le confort d'utilisation
[^] # Re: Et les elastic tabstops ?
Posté par Mathias Bavay (site web personnel) . En réponse au sondage J'indente mon code source avec. Évalué à 1.
Le boulot d'un bon éditeur n'est pas de m'imposer la façon dont je dois voir le code, mais de faire que l'indentation s'adapte à mon souhait, et que les alignements soient respectés. D'où mon choix d'indenter avec des tabs et d'aligner avec des espaces (la version "elastic tab stops" du pauvre).
Mathias
[^] # Re: Un café
Posté par Mathias Bavay (site web personnel) . En réponse au message C++: CDT et auto-tools sous Linux. Évalué à 1.
LIBS = -lmylib
INCLUDES = -L/path/to/mylib
LDFLAGS = $(INCLUDES) $(LIBS)
Et il ne faut effectivement pas faire ces modifs dans le Makefile mais tu peux les mettre dans le Makefile.in (à condition que celui-ci ne soit pas ré-généré à chaque fois). Sinon, ce sera dans le Makefile.am (que je n'ai jamais utilisé, je me fait mon Makefile.in à la main et configure génère le Makefile)
Mathias
[^] # Re: et pour le C ?
Posté par Mathias Bavay (site web personnel) . En réponse au sondage J'indente mon code source avec. Évalué à 4.
# N900
Posté par Mathias Bavay (site web personnel) . En réponse au message Openmoko cassé... que faire.... Évalué à 2.
Je n'ai rien fait de tout cela sur le mien (à nouveau, je n'ai pas d'autre téléphone), et mon seul regret est de ne pas avoir de gcc packagé pour compiler dessus.
Mathias
[^] # Re: Comparatif
Posté par Mathias Bavay (site web personnel) . En réponse à la dépêche WebP, le format d'image libre de Google. Évalué à 2.
Sur la page de WebP chez google, il y a des exemples bien plus parlants: à qualité égale, des tailles jusqu'à ~70% plus petites.
Mathias
[^] # Re: Ce qu'il te faut s'appelle un bridge ou un répéteur
Posté par Mathias Bavay (site web personnel) . En réponse au message routeur Wifi (qui se connecte en Wifi à un autre point d'accès Wifi). Évalué à 3.
Cela marche bien, sur un routeur WRT54GL avec QoS activé.
Mathias
# En passant par les julian dates...
Posté par Mathias Bavay (site web personnel) . En réponse au message Algorithmes calculs de date. Évalué à 3.
L'algo:
long Date::getJulianDayNumber(const int& _year, const int& _month, const int& _day) const
622 { //given year, month, day, calculate the matching julian day
623 //see Fliegel, H. F. and van Flandern, T. C. 1968. Letters to the editor: a machine algorithm for processing calendar dates. Commun. ACM 11, 10 (Oct. 1968), 657. DOI= http://doi.acm.org/10.1145/364096.364097
624 const long lmonth = (long) _month, lday = (long) _day;
625 long lyear = (long) _year;
626
627 // Correct for BC years -> astronomical year, that is from year -1 to year 0
628 if ( lyear < 0 ) {
629 lyear++;
630 }
631
632 const long jdn = lday - 32075L +
633 1461L * ( lyear + 4800L + ( lmonth - 14L ) / 12L ) / 4L +
634 367L * ( lmonth - 2L - ( lmonth - 14L ) / 12L * 12L ) / 12L -
635 3L * ( ( lyear + 4900L + ( lmonth - 14L ) / 12L ) / 100L ) / 4L;
636
637 return jdn;
638 }
Pour plus de détails, regarde dans mes sources:
https://slfsmm.indefero.net/p/meteoio/source/tree/HEAD/trunk(...)
(il y a aussi la méthode inverse, à partir d'une julian date trouver jours, mois, annés)
Mathias
# Indefero
Posté par Mathias Bavay (site web personnel) . En réponse au message forge. Évalué à 3.
Mathias
PS: tu peux voir nos projets libres sur http://slfsmm.indefero.net
# HTTPS everywhere
Posté par Mathias Bavay (site web personnel) . En réponse à la dépêche Postgres, NetBeans, mod_python/mod_wsgi et HTTPS Everywhere. Évalué à 3.
mes 2 centimes
Mathias
[^] # Re: hdf5 ?
Posté par Mathias Bavay (site web personnel) . En réponse à la dépêche Bibliothèque d'entrées/sorties météorologiques. Évalué à 1.
Mathias
[^] # Re: hdf5 ?
Posté par Mathias Bavay (site web personnel) . En réponse à la dépêche Bibliothèque d'entrées/sorties météorologiques. Évalué à 1.
[^] # Re: hdf5 ?
Posté par Mathias Bavay (site web personnel) . En réponse à la dépêche Bibliothèque d'entrées/sorties météorologiques. Évalué à 7.
De plus, le format lui meme ne fait pas tout: il faut toujours filtrer les donnees, re-echantillonner, interpoler spatiallement, etc choses que fourni notre librairie. Les meta-donnes doivent aussi etre gérées (conversions entre des systemes de coordonnes geographiques potentiellement differents), on a souvent besoin de quelques manipulations simples sur le modele numerique de terrain, de gestion des dates (convertir d'une date "lisible" vers une date "julian date", voir autre systeme, de meme vers/a destination de posix, etc), choses que notre librarie fourni de facon integree et surtout transparente.
# Petite précision
Posté par Mathias Bavay (site web personnel) . En réponse à la dépêche Bibliothèque d'entrées/sorties météorologiques. Évalué à 2.
[^] # Re: Android 2.2
Posté par Mathias Bavay (site web personnel) . En réponse à la dépêche Cascade de micro-dépêches : Orbot, Android 2.2, Oracle/ODF, et autres. Évalué à 7.
J'ai un N900 sous Maemo, et autant j'en suis pleinement satisfait, autant je me demande parfois si je n'aurai pas dû prendre un appareil sous Android (qui fait beaucoup de buzz comparé à un Maemo dont personne ne parle).
Avec ce genre de news, je me dit que finalement, avoir un appareil ou je peux mettre à jour ce que je veux, quand je veux, où la communauté est impliquée, c'est plutôt pas mal... (et dès que j'aurai à nouveau installé un package testing sur mon appareil, package qui me casse plein de trucs, j'aurai de nouveau des états d'âme... ce qui est particulièrement stupide, car je suis vraiment satisfait de mon choix 99% du temps)
Enfin si un jour quelqu'un parvient à installer des applications Android sur Maemo/MeeGo, cela serait vraiment le moyen d'avoir le meilleur des deux mondes!
</ma vie, mes états d'âme>
Mathias
# Clef, Konqueror
Posté par Mathias Bavay (site web personnel) . En réponse au message Utilisation pratique d'openssh. Évalué à 3.
Après, pour ce qui est de transférer des fichiers, j'utilise parfois konqueror via son support de sftp (donc on se balade comme dans un système de fichier local). J'ai quelques liens ssh dans mes bookmarks, donc un seul clic et je suis dessus.
Mathias
# Indefero
Posté par Mathias Bavay (site web personnel) . En réponse au message Forge open-source. Évalué à 3.
Mathias
[^] # Re: Barbie ingénieur ?
Posté par Mathias Bavay (site web personnel) . En réponse à la dépêche Revue de presse de l'April pour la semaine 8. Évalué à 2.
Ou bien faut-il en conclure que «Geek-chic» == Linux ?? (qu'elle est loin l'image du barbu!)
Mathias