laurent wandrebeck a écrit 121 commentaires

Kerrighed ne semble nullement packagé (.deb cassé, visiblement pas d'autre paquets dispos).
La maintenance, je pense notamment aux sauts de version doit être assez pénible/chronophage non ?

Je ne suis pas un super-héros.

Merci du tuyau.

Mais je vais quand même garder autant que possible mes redhateries qui-vont-bien, qui sont stables, et dont le support est long :)
Avoir un parc non homogène, quelle horreur, j'ai déjà bien assez à faire pour valider les algos, alors si en plus il fallait tester avec pleins de versions (compilo etc), au secours !

Mais je vais tout de même jeter un œil à gluster, merci :)

Et non, je n'ai pas d'identité cachée…je suis juste le responsable du SI, et pas Obiwan.

Mais xtreemos n'est-il pas basé sur kerrighed ? Et d'après geb, ça ne serait pas très stable ?
Qui a raison ? :)

Hmmm on n'utilise jamais fork ou presque.
Nous avons plutôt une palanquée d'images, sur lesquelles on éxécute un code ou plusieurs, ce qui résulte en d'autres images.
Le fork and forget ne me semble pas adapté ou j'ai raté une marche ?

Les calculs sont (très) gourmands…de quelques minutes à plusieurs semaines fonction des cas. Ça se chiffre généralement en heures. On fait de la recherche en physique atmosphérique…entre autres.
Les données sont relativement précieuses, mais relativement facilement récupérables, en tout cas les données d'origines.
L'admin veut surtout mettre en place une solution qui lui permettra de faire évoluer le parc sans avoir des suées. Et tant mieux si ça l'amuse en plus :)
Le chef de l'admin, ben, c'est moi™.

Oui, c'est triste, mais la part allouée au SI n'est pas une volonté, mais un problème de budget.
Tu ne connais pas la joie des petites entreprises on dirait :)
Le SI est important/vital, des efforts ont été/sont faits, mais je ne peux en demander plus…alors il faut faire avec…

ah oui, drdb, il faut que je me penche sur cette bête, ça a l'air très bien.
Les machines sont déjà toutes pleines, il n'est pas possible de regrouper davantage les disques. Et les montages NFS en étoile, pour que chacun puisse accéder à tout depuis n'importe quelle machine, ça devient sale…
pour le ssh/ftp, c'est une petite machine toute seule dans son coin, par précaution.
Je vais regarder du côté de Rocks, merci bien !

Les codes que nous lançons sont souvent des gros bousins monothread (avec moults paramètres, lancés via des script bash/csh/python/etc), mélange de C et de Fortran, qui bouclent sur x fichiers à traiter. Il y'a bien sûr des cas différents, comme ouvrir plusieurs fichiers pour en générer un qui soit une synthèse du tout, et j'en passe.
Je n'ai pas beaucoup approfondi hadoop, mais il semblerait que pour en tirer correctement parti, il faudrait modifier les algos (par exemple pour faire que le traitement se fasse sur des parties de l'image). Voire modifier les scripts de lancement pour lancer plusieurs traitements en même temps. J'ai peut-être tort, mais en tout cas, on a déjà bien assez de boulot sur la partie scientifique du code pour devoir s'amuser à le parralléliser d'une manière ou d'une autre.
Sans compter qu'il faut qu'il reste portable afin que lorsque nous livrons le code il fonctionne sur une machine classique ou presque.
Il serait effectivement possible de se baser sur ton soft, le problème principal étant la consommation mémoire…il n'est pas rare que nous swappions avec un seul process et 8 go de ram. Mais je vais tout de même m'y pencher un peu plus.
Le but principal de la grille/grappe serait d'éviter à chacun de chercher (via munin pour l'instant) une machine « libre » pour y éxecuter du code, ou de chercher les machines dispos pour pouvoir lancer 20 ou 30 fois un code de type monte-carlo (qui lui ne prend quasiment rien en mémoire, mais qui bouffe du cpu comme pas permis).
Sans parler d'arrêter les galères du type: « il me faut 2 To pour pouvoir stocker les résultats que vont générer les calculs, je peux les mettre sur quelle machine ? ». Et ils n'aiment pas la réponse « 1to là, et l'autre là », tu te doutes :)
Bref, l'organisation d'origine était pas mal…avec 4/5 serveurs. Il est grand temps que nous passions à une solution plus évolutive, plus adaptée à nos besoins…et ce n'est guère évident de la trouver.

Merci pour tes lumières en tout cas.

Il faut une version beta de FF. il ne reste plus qu'à attendre la 3.5 pour que cela se démocratise vraiment. ou tester la beta ! (et rapporter les bugs, tant qu'à faire)

Il a été grandement optimisé. Tu peux retenter ta chance :)

J'utilise F9 chez moi, et j'en suis (très) content.
Par contre, GCC 4.3.0 n'est pas assez mûr, il "ICE" (internal compiler error) lorsqu'on tente que compiler un noyau (user mode linux dans mon cas, pas essayé les versions dites "normales").
Le bug a été rapporté, mais le problème n'a pas encore été corrigé.
Pas si évident de changer de version de compilateur avec une distrib entière qui repose dessus. Ce qu'on ne ferait pas pour débroussailler les futures versions vraiment stables :) Ils ont sont sont pour l'instant à dire: 4.3.0 plante, en 4.4 ca fonctionne...d'ici à trouver le fautif, ca prendra un peu de temps ;)
Ceci dit, cela promet une excellente rhel/centos/scientific linux/etc 6, sachant que Redhat se basera probablement sur Fedora 10 pour la prochaine version entreprise.

AC a bossé sur la partie TTY, il me semble.

Petite typo: Con Kolivas

Concernant ton patch (xattr pour ext2/3), j'avoues l'avoir laissé de coté pour le moment. Il semblerait que la gestion des xattr soit en cours d'uniformisation, et cela serait sympa d'avoir le support pour tous les systèmes de fichiers plutot qu'un seul.

Quant à l'aide que tu me proposes, c'est avec grand plaisir que je l'accepte :-)
La mise en place de la fonction "network logging" devrait démarrer dans un mois environ, en temps que sujet pour un groupe d'étudiants, c'est en attente de confirmation. Quelqu'un d'autre est en train de travailler sur le format des lignes des journaux. Quant aux autres parties de la liste TODO, choisis, et préviens-moi histoire qu'on ne bosse pas sur la meme chose.
De meme, si tu as d'autres propositions, n'hésites pas.

Pour les liens, merci des précisions, je n'avais jamais cliqué dessus avant que certains parlent du coté douteux de ceux-ci. Je me suis permis dans la foulée d'envoyer un mail à Franck, mais je n'ai toujours pas de nouvelles.

PS: j'utilise GNU/Arch pour développer dans mon coin, avant de mettre le contenu de mon archive dans le cvs. Je préférerais donc que tu 1) utilises Arch pour que ca soit plus simple de nous synchroniser 2) utilises les tarballs de mon archive que je mets à dispo. Jettes un oeil à la ML, l'adresse est dispo !

Encore merci pour ton message à caractère informatif :)

Damned, je n'ai pas les droits en écriture :(
L'auteur principal, propriétaire du fichier, n'a donné aucun signe de vie sur la ML depuis que j'y suis inscrit, et ca fait un bon trois mois... *sic*
Je vais voir si je peux le contacter pour qu'il solutionne ce, hum, truc.

Bon, je me réponds...
Je suis retourné sur la page web, j'avais oublié à quel point c'était, pfiou, décoiffant.
Dès que je serais rentré du boulot, je vais au moins prendre le temps de virer ces liens à la c*n.

Et bien, si tu es doué en design web, tu es le bienvenu :)
J'ai laissé le site tel qu'il était avant, car 1) je suis nul en design 2) je n'ai pas vraiment le temps de m'occuper de ça.

Rien à voir: J'ai crée #metalog sur FreeNode, passez dire un petit bonjour !

Je voudrais aussi remercier wilk et les acolytes qui l'ont aidé dans cette tâche !

J'ai une petite question toutesfois: Le tutoriel version anglaise est un peu en retard par rapport à certaines fonctionnalités ayant été implémentées après l'écriture du tuto anglais. Qu'en est-il de la version française (Mea Culpa, je n'ai pas encore eu le temps de le lire) ?

Et un second merci à Wilk pour avoir mis en formes mes maigres traductions dans le wiki !

Pour en arriver à l'esprit de contradiction que wilk évoque plus bas, je ne sais pas, les francais sont-ils plus allergiques que le terrien "moyen" aux programmes non GPL ? Ceci dit, subversion, on en fait tout un foin, beaucoup de gens travaillent dessus, ce qui lui donne des avantages (disponibilité d'interfaces graphiques abouties etc). Soit, néanmoins, je ne lui trouve rien de vraiment terrible. C'est assez pénible à mettre en place, nécessité d'un serveur web etc, et ca ne reste un cvs un peu évolué. J'ai le sentiment qu'Arch est capable de faire bien plus que cela. De plus, une fois qu'on a assimilé les concepts, c'est quand même bien plus aisé à déployer, à mon humble avis. Attention, je ne crache pas dans la soupe, je ne dis pas que j'aurais fait mieux :)
Voila, c'était mes 0.02€.

Pour ce dont je me rappelle de cette époque, le fork Lunar est apparu quelques mois avant le départ que je qualifierais de surprise de Kyle.
Nous sommes donc basés sur une même distrib, mais je pense que nous avons pris des directions un peu différentes. Le nom des commandes a changé du côté de chez eux (lin je crois), tandis que nous avond gardé en grande partie les noms des commandes relatives à Sorcery de l'époque, même si (quasiement?) tout a été réécrit. Pour plus de détails voir les deux sites, car je n'ai jamais utilsé Lunar.

emerge -pv abiword avant d'emerger pour avoir la liste des USE utilisés par l'ebuild à installer.

ok, donc pour connaitre les dependences optionelles d'un ebuild il faut taper une commande. Du côté de chez nous, c'est demandé une bonne fois pour toutes (à moins bien sûr que tu es envie de les modifier, auquel cas cast -r (reconfigure)). C'est probablement une simple question de goût, mais je préfère "notre" approche...plus simple, tu n'as pas à taper des commandes supplémentaires, ni à te poser de questions, c'est la machine qui te les pose :)

Gentoo propose également une multitude de frontends graphiques pour "faciliter" l'utilisation de portage.

vous c'est emerge pour installer en ligne de commande, nous c'est cast. sorcery permet aussi d'installer/désinstaller/"freezer"/etc des spells, et il existe une interface: ncurses, gtk, qt. ce n'est pas cependant ce que je qualifierais de multitude :)

hmmmm un détail m'interpelle:
ccache existe aussi sous Source Mage, et c'est utilsé pour accélerer les compilations lors de mises à jour. A savoir que son utilisation est optionnelle.
à ne pas confondre donc avec la présence de cache des sources et des binaires, aussi proposés de manière optionnelle par sorcery.
Voilà, c'était juste pour clarifier ce point.

On peut aussi ajouter Unet, qui fait partie de la même équipe :)
Comme quoi, les petits francais ne sont pas si inactifs que ça dans la monde du libre. félicitations à tous (des développeurs aux rapporteurs de bugs en passant par ceux qui ont le courage de rédiger la (très importante) documentation.

/me slaps crevetor...
euh non je m'égare :) C'est peut-être l'occasion de rappeller que la SMGL est basée sur la Sorcerer, à l'époque où son créateur original (Kyle Sallee) s'est sauvé avec le site, les sources et tout le reste, et qu'on a repris le bébé. Notons que ce même auteur est revenu quelques mois plus tard avec "sa" Sorcerer, qu'on lui a bien gentillement rendu son nom, pour qu'il refasse "sa" distrib sous une licence non GPL (berk). Une espèce de dérivé de la QPL à ce que j'en sais...mais le destin de "sa" distrib ne m'intéresse plus.