Sytoka Modon a écrit 4551 commentaires

> ya que le Perl objet qui est imbitable et qui n'aurait jamais du exister

Tu as regardé du coté de Moose ?

Je ne trouve pas personnellement le code Python ou Ruby particulièrement lisible, voila pour une partie de ma réponse.

Ensuite ta comparaison sur les voitures est intéressante, j'en conclue que Perl est la Mercedes et Ruby la 2CV ;-)

Exact, j'ai des amis chercheurs qui enregistrent des sessions de travail afin d'analyser cela avec des sociologues et essayer de comprendre ce qui se passe et surtout détecter les points clefs qui amène à l'innovation.

Ils travaillent avec de la HD et des systèmes pour mettre 4 films en 1 afin d'avoir un aperçu de toute la(les) scènes. Malgré cela, c'est jamais assez précis...

Je pense que c'est un outil qui dans ce cadre de l'observation du comportement sur des personnes qui sont évidement de plein grès dans l'expérience, cela peut être intéressant.

Tu connais le Perl Moderne ?

Quelque soit le langage, il est assez facile d'écrire du code incompréhensible... Perl est un langage qui évolue régulièrement et en 10 ans, la manière de programmer est devenue très différente.

Un petit exemple que j'ai vu passer il n'y a pas longtemps. L'objectif est de piloter mpd depuis une interface web écrite avec dancer. C'est pas un exemple archi-compliqué mais c'est intéressant à voir à mon sens.

http://blog.preshweb.co.uk/2010/11/dancerjukebox-music-queui(...)

https://github.com/bigpresh/DancerJukebox

Justement, je voudrais pouvoir virer la couche samba...

C'est que notre ami Pierre n'est plus tout jeune ;-)

Tu peux mais personnellement, je lance un script avec les classes de cfengine en option via cfengine. C'est un script que j'ai bidouillé à partir d'un script développé par Steve Kemp pour debian.

Le problème que j'ai eu la version intégré dans cfengine, c'était trop verbeux et surtout, dès qu'il y avait trop de paquet à installer, ça plantait pour un histoire de longueur de ligne si je me souviens bien...

Sous Linux, je déploie avec cfengine qui est bien plus souple ;-)

Chez nous, la fonction première de l'agent OCS est de déploiement ;-) Le projet FusionInventory est très bien mais c'est surtout la partie agent d'installation qui m'intéresse le plus...

La manière qu'à OCS pour déployer un paquet est génial, découper en petit morceau de manière automatique, le client récupère tout cela via http en prenant son temps, tout simplement génial et bien mieux que tout le reste ou malheureusement, cela passe trop souvent par un partage samba ;-(

Pour Pulse2, ma remarque est que je ne connais personne l'ayant utilisé et je ne sais pas s'il est utilisé ailleurs que sur un serveur Mandriva. C'est tout.

L'agent OCS fait deux choses : remonté de l'inventaire et déployer un logiciel. Il fait donc deux choses.

Ce qui n'est pas bien. Si l'installation plante, le code retour n'est pas toujours bon. Donc parfois OCS dis que le logiciel est déployé mais en fait non. Si on veut de nouveau l'installer, il faut aller effacer la ligne avec le timestamp du logiciel dans le fichier history... Un peu nul. On devrait avoir une option pour forcer une ré-installation sans avoir à refaire un nouveau paquet identique !

Autre chose pas terrible, pas possible d'installer un logiciel toutes les x fois, chose que fait très bien cfengine. Par exemple, un logiciel est en pratique un bête script qui bidouille trois clefs de registre pour forcer des sécurités. On veut les ré-appliqué toutes les deux heures par sécurité. Impossible avec OCS puisqu'il n'installe le logiciel qu'une fois. Faut passer ensuite pas la commande AT mais la gestion de celle-ci est un peu pourris.

Dans le même esprit, on pourrait lancé un nettoyage via CCleaner ou une défragmentation régulière...

En fait, il y a presque tout dans l'agent pour faire cela.

Autre chose avec OCS, la commande que tu lances ouvres une invite de commande... J'ai pas trouvé de solution pour avoir un truc 100% silencieux qui marche sur tous les postes sauf à mettre en tout début de script .bat la commande cmdow.exe (et penser à rajouter cette commande dans les exceptions des anti-virus).

J'ai regardé du coté d'OPSI mais tu deviens très dépendant de lui...

Comment on fonctionne avec OCS, on fait des zip qui ont tout dedans et surtout un script install.bat. L'idée est que l'installation via OCS ou à la main est la plus proche possible. OCS lance install.bat qui fait toute la suite. Les choses sont donc bien distinctes et simple à maintenir. Et puis, on peux diffuser les paquets zip même aux personnes qui ne sont pas gérer par OCS, ou on peut remplacer OCS par un autre système à terme.

blablablabla... cf guerre des Malouines !

Justement, je cherche un script pour installer une imprimante en IPP (ou HTTP) en mode silencieux.

Il y a aussi pour gérer un parc

- OCS Inventory : marche mais est un peu limité je trouve

- OPSI : a l'air de tout faire

- Pulse2 : un peu trop Mandriva mais je n'en sais pas plus

- WPKG : basique comme OCS

Ces systèmes me semblent basés sur des clients agents assez basique et ne reprennent pas malheureusement la stratégie de cfengine. Du coup, ça fait des gros serveurs compliqué...

J'avoue que j'aime bien cfengine qui fonctionne en deux étapes :

- 1 - synchronise une base de fichier (ensemble de règles, fichiers...)

- 2 - on applique en fonction de classe un ensemble de règle sur la version locale de la base

C'est très robuste aux pannes réseaux et tout peut être découpé en morceaux plus petits. Vraiment très très efficace.

J'ai mis 10000 mais on aurait pu mettre autre chose, c'est juste pour dire qu'on n'utilise pas 100% de la machine. Pas mal de code MPI ont du mal au delà de 1000 (source SGI d'il y a quelques années), on a un code qui fonctionne avec 2000 coeurs mais son efficacité est moindre et aller au delà n'est pas forcément "rentable". En effet, on n'a pas non plus un nombre d'heure illimité et comme tu payes (sur tes crédits d'heures) à la minute par coeur, plus tu prends de coeur, plus ton compteur descend vite vers zéro !

Comme tu as pas mal de "run" à faire (type plan d'expérience), on va pas souvent à plus de 2000 coeurs sur nos codes.

Je suis intéressé de savoir s'il y en a beaucoup ici qui font des gros calculs sur 20000 coeurs par exemple et quelles est l'efficacité du parallélisme à ce niveau là ?

Au niveau du calcul, il y a encore du boulot pour améliorer/inventer la programmation très massivement parallèle.

Ce qui est idiot dans ce classement, c'est qu'il est fort probable qu'aucun calcul ne tourne sur la totalité du cluster. On en revient dont à la question sur Google. Google a des grosses machines, certainement plus puissante en cumulé mais pas en calcul global, c'est à dire sur un code parallèle utilisant la totalité des noeuds.

Le Linpack n'est déjà pas représentatif des codes qui tournent sur ces machines. Il faudrait trouver une dizaine de code max et leur faire calculer un vrai problème de simulation et à la fin, comparé les temps et l'énergie électrique consommée.

Combien de code tournent de manière efficace de nos jours sur 10000 coeurs ?

En plus, ces machines du TOP500 ont des architectures ou tous les noeuds ne sont pas à égales distances. En fait, ce sont des clusters de clusters et le franchissement de la barrière inter-cluster est normalement visible coté latence. Ce sont en fait des fermes de clusters ou l'utilisateur ne pourra jamais se voir affecté plus de x% de la puissance globale. On ne peux plus /a priori/ parler de calculateur au singulier !

Il serait vraiment intéressant d'avoir un comparatif de la performance de calculateur en terme de puissance consommation qui permettrais de mettre en évidence la différence des architectures matérielles sur des benchs réalistes mono-calcul. Par exemple, simulation d'un vol d'avion, interaction électromagnétique dans un super calculateur... pas des trucs avec couplage très faible du type traitement de X images !

Si mes souvenirs sont bons, mes oncles ont du aller en Algérie malgré eux... Mon père a évité tout cela pour raison de santé. En fait, il ont fait leur service militaire la bas mais comme c'était obligatoire... en plus, pendant la guerre d'Algérie, le service est passé de 18 à 30 mois !

http://fr.wikipedia.org/wiki/Service_militaire_en_France

En plus, l'Algérie était un département Français.

Sinon, je suis moi aussi un fédéraliste convaincu, les grands esprit au final se rejoignent ;-)

Je rajoute juste pour ne pas laisser une erreur traîner, la première guerre mondiale, c'est 14-18 donc ensuite, il n'y a que 21 ans de paix (relative).

La guerre froide est finie depuis la chute du mur de Berlin en 89 (21 ans déjà) et depuis, c'est la paix ;-)

La guerre froide a eu son heure. Une solution a un problème humain à l'instant t peut s'avérer mauvaise à l'instant t+1. Nous ne sommes plus dans le même contexte ce jour.

Tu oublies la décolonisation ! La fin de la guerre, c'est 62 pour la France (indochine + algérie).

Ah ben alors, le traité de Rome date de 57. Et si la construction Européenne était plus efficace (question ouverte) dans la gestion des conflits sur le territoire européen ?

Je suis sur un projet avec un industriel qui a choisi le Scala pour faire son développement. Il s'en mord les doigts car le code ne lui semble pas plus maintenable qu'avec un autre langage et il doit former chacun des développeurs qu'il embauche car il ne trouve pas de compétence Scala sur le marché. Sa boite est sur Paris.

Bref, personnellement, je n'ai pas d'opinion sur le sujet mais pour ce premier projet industriel, cela ne semble pas gagné.

La pakistan et l'inde ont l'arme nucléaire et sont en guerre pour une question de territoire depuis... Idem avec la chine, les frontières ne sont pas claires. Les trois ont la bombe.

La dissuasion est une (fausse ?) bonne idée mais qui ne fait pas tout. La survie de l'humanité veut que la puissance nucléaire ne puisse faire trop de mal à la planète, on n'en a pas encore une de rechange. J'ai grandis dans l'ambiance de la guerre froide, c'est pas non plus la panacée...

Les protocoles pour faire une bombe qui marche sont parfaitement connus de l'armée française. En refaire des pareils ne posent aucun soucis !

Il s'agit ici d'en faire des nouvelles, donc différentes des anciennes, qu'ils ne pourront pas tester en grandeur nature. Du coup, il est possible (mais peu probable) que dans 20 ans, notre dissuasion ne marche même plus en pratique s'il y a eu une erreur quelque part !

Je voudrais bien savoir la proportion de Fortran et de C ou de C++ sur une grosse machine de calcul ;-) En tout cas chez moi, le coeur est quasiment toujours en Fortran. Le python est utilisé en post-traitement donc pas en calcul parallèle pour le moment.

Lorsque ton code utilise plus de 1000 coeur avec MPI et qu'il tourne plus d'un mois, crois moi, on essaye quand même d'optimiser !

Sinon, le Fortran a énormément évolué, bien plus que le C et c'est maintenant un langage objet dans sa dernière version. La version suivante (ou en cours sur les différentes implémentations) est l'intégration du clustering au coeur du langage via les Co-Array.

Bref, on n'est pas près de voir le Fortran disparaître des machines de calcul, surtout que les doctorants et les chercheurs ne sont pas des informaticiens en général et qu'il est à mon sens plus facile d'écrire du code propre et lisible en Fortran qu'en C ou C++.

J'irais presque jusqu'à dire que du code Fortran peux se lire aussi facilement que du langage script python si la personne écrit en Fortran moderne.

Exact, j'ai dis une bêtise !