Sytoka Modon a écrit 4576 commentaires

De même, peu de langage informatique accepte le souligné _ dans les nombres afin de les rendre plus lisible. C'est dommage.

Sinon, je cherche une police de caractère sous Linux (et sous TeX) qui aurait le 7 barré comme on les fait à la main. Attention, je veux un vrai 7, pas un caractère spécial.

Tu as tout écrit. Un des gros soucis est la latence des appels parallèle et puis aussi les petits bouts ou ils faut tout synchroniser...

Bref, avec un programme bien écrit, tu montes (assez facilement) à 1000 coeurs. Ensuite, pas sur que le passage a 10000 coeurs te permette le même gain. Ton programme peux marcher mais avec une efficacité de plus en plus moindre.

Comme souvent, tu as 10 calculs à faire. Tu vas lancer 10 calcul de 1000 coeurs en parallèle plutôt qu'enchaîner 10 calcul de 10000 coeurs. Mais dans l'absolue, il faut commencer à avoir des codes efficaces avec 10000 coeurs voir réfléchir à l'étape suivante et le passage au 100000 coeurs.

Ensuite, il faut avoir accès à tous ces coeurs sur une machine de calcul. Même sur les centres universitaires, on << paye >> à l'heure donc plus on utilise de coeur, plus notre crédit d'heure tombe vite !

On parle ici de code de calcul.

Sinon, les cluster de google sont plus puissant mais ne sont pas destinés à faire du calcul HPC ou il faut une liaison très rapide entre noeuds pour diminuer la latence des appels parallèles (MPI par exemple).

Je suis admin système et je développe des petits trucs mais pas bien gros. On développe dans mon labo des gros trucs mais en Fortran pour la plupart (c'est du calcul numérique) et tout le jargon du Java n'est pas encore intégré au fortran ;-)

Il n'y a pas que le Linpack dans la vrai vie. Je dirais même qu'il est assez rare de faire du Linpack...

Il est même pas courant d'avoir un code qui tourne réellement sur 10000 coeurs et qui reste performant. Ces grosses machines sont finalement des datacenters de calcul plus que des machines de calcul. D'ailleurs, il n'y a pas d'interconnexion rapide entre tous les noeuds deux à deux généralement...

Bref, il faudrait AUSSI un vrai classement mettant en oeuvre des vrais codes sur des vrais problèmes.

> Les machines IA-64 sont à l'article de la mort avec seulement 5 machines et la transition
> de Bull

Et la nouvelle est gentille en citant Bull sur ce passage sachant que c'était SGI les rois de l'Itanium avec leur Atix4600 qui était vraiment une belle machine SMP.

Pour info, SGI fait maintenant des machines SMP sur base Nehalem.

Encore un beau journal ou on n'a rien compris au final.

En français dans le texte, ce serait mieux ;-)

> et une ergonomie de merde sous Windows et OS X, mais ça c'est un autre problème

Gimp est conçu pour le mode FollowMouse de X car au début de Gimp, tout le monde (quasiment) sous X était en mode FollowMouse et personnellement, je déteste les autres modes ou il faut faire click click click avant de pouvoir faire la moindre chose !

Le problème est que les applications d'aujourd'hui suivent pour la plupart la mode Windows ou Mac du click click et on complètement oublié le mode FollowMouse.

Parce qu'il y en marre des applications qui obligent au mode ClickToFocus.... ;-)

> - Faire une demande, attendre, se la voir refuser dans 99.999%

Je suis d'accord avec toi.

Dans mon labo, on essaye d'être souple du coup on gère toute la misère du monde parce qu'en face, c'est impossible !

Je ne te parle pas des thèses en co-tutelle (CIFRE) ou la boite empêche carrément son thésard de faire du boulot car elle refuse une sortie SSH de son système.

Bref, les DSI sont psycho-rigide et elles ont une grosse part de responsabilité dans la propagation du HTTP à tout et n'importe quoi. Il serait temps que les DSI ouvre les yeux et voie que les principaux problèmes sont actuellement ailleurs.

Sur le fond, je suis assez d'accord avec toi aussi depuis le début.

Cependant, il ne faut pas penser que tous les composants sont interchangeable aussi facilement. Ce sont des puces Intel contrôlé par les USA. La concurrence AMD aussi. L'intégration ne marche pas avec des puces bas de gamme.

La connectique est InfiniBand (enfin, je suppose). Quel est le degré de concurrence réel à ce niveau là, je ne sais pas.

A mon sens, l'avenir des machines de calcul passe par le format << container >> des bateaux. Sur ce créneau là, SGI a me semble-t'il une longueur d'avance avec un savoir faire provenant du cloud. Je ne sais pas quels sont les compétences de Bull sur cette thématique.

Sinon, dans le TOP 500, on trouve pas mal de constructeur qui ont fait très peu de machine (BULL est dans ce gros tas). J'en conclue, peut être à tord, qu'assembler une grosse machine de type cluster avec des racks du commerce n'est pas si difficile que cela. Par contre, ce que fait SGI avec le cloud, c'est à dire concevoir la machine pour optimiser globalement l'application qui va tourner dessus me semble un cran au dessus.

> personne ne prendra le risque de confier une composante essentielle de la sécurité
> nationale à un prestataire que l'on ne peut contrôler.

Combien de composant de Tera-100 sont conçu et fabriqué en France ?

As tu fais un tour dans les armées ? Quelle est la proportion de poste des armées tournant sous les OS de Microsoft ?

...

Cela fait longtemps que l'armée ne maîtrise plus toute la chaîne...

PS : Lors d'une visite chez Bull il y a quelques temps déjà, ils me montrent fièrement leur petit serveur 1U et là, surprise, c'était une copie conforme de celui que j'avais acheté via le marché CNRS chez NEC ! J'ai alors eu toutes les peines du monde a leur faire avouer que c'était le même.

Grâce à l'armée, Bull, ce fleuron français sans qui l'informatique ne serait pas, est encore là. Vivement Tera-1000 que l'on soulage notre dette.

Entre temps, l'IDRIS a eu droit a un IBM sans appel d'offre alors que le CINES a eu toutes les peines du monde pour acheter sa machine SGI. Et que dire de la tanche 2 de celui-ci.

Bref, il y a du ménage à faire dans les procédures de choix des grosses machines...

Le CERN est 100% civil au grand dam des militaires... Il n'y a aucune expérience classifiés au LHC.

Pour une fois que la recherche civile n'est pas financé par les militaires et ne leur rends aucun compte. Je connais des laboratoires qui aimerait que les militaires ne mettent jamais leur nez dedans mais qui les ont sur le dos.

Tiens, c'est encore un bull ->[]

[] <- pas vu de bull dans les centres scientifiques publiques...

> Fedora est beaucoup plus jeune que Debian (6,5 ans contre 17)

Il faut compter l'âge de Fedora comme étant l'âge de Red-Hat si tu veux faire cette comparaison. Prendre les chiffres ainsi en les sortant de leur contexte n'a absolument aucun sens.

Comme tout projet, celui-ci peut être utilisé à d'autres fin que celui pour lequel il a été conçu initialement. Je ne pense pas qu'il y ai le moindre soucis pédagogique dans ce projet. Celui-ci est fortement lié par les nécessités de la virtualisation sur les grosses fermes de serveurs.

Mais tout ce qui touche à la virtualisation est un formidable laboratoire pédagogique. Tant mieux !

Fedora est un peu un laboratoire des dernières technologies. L'idée est un peu de suivre la mode au sens noble du terme quitte à couper des branches pour ne pas exploser en énergie (par exemple, élimination à terme de la branche PowerPC).

Debian a pour objectif d'être le système universel. C'est plus une approche encyclopédique. Il faut donc tout empaqueter pour toutes les architectures et faire que les programmes marchent sur autre chose que sur x86. Pour ne pas exploser, debian est obligé d'avoir des logiciels qui ne changent pas tous les quatre matins. Elle ne peux donc suivre la mode de trop près.

En pratique, les deux distributions sont parfaitement complémentaire et sont toutes les deux essentielles l'une pour l'autre.

Parfaitement d'accord sur toi la dessus surtout qu'ici, ça n'a pas la lourdeur de la dépêche de Fedora. C'est bien plus léger et fin.

Je ne connais pas Lamson mais j'utilise personnellement QPSMTPD et c'est assez génial à utiliser.

http://smtpd.develooper.com/

C'est un serveur SMTP modulaire en Perl. Je ne sais pas ce qui les rapproche et/ou les éloigne. Si quelqu'un connaît les deux, ce serait intéressant d'avoir un avis la dessus.

Moi j'ai trouvé pénible ces "merci Red-Hat, merci red-Hat...".

Cela donne l'impression que Red-Hat fait tout de A à Z or la plupart des projets sont communautaires.

Quelques noms sur quelques points spécifiques et qui m'ont paru nouveau (par exemple gestion des couleurs) m'aurait semblé suffisant.

En effet, tu as du sauter un mot ;-)

Ok mais OpenSSH 5.5 est un boguefix de la version 5.4. C'est normal, après chaque grosse version, les suivantes corrigent des petits détails. Sur certain projet, cette version aurait été 5.4.1 ;-)

Pour retrouver cette dépêche, j'ai taper OpenSSH en haut à droite sur linuxfr. La première réponse est la bonne.

Les principales nouveautés sont décrites ici

http://linuxfr.org/2010/03/15/26585.html

pub perso ;-)

Pour l'agrégation de lien, je ne sais pas trop... Pour le spanning tree, cela permet d'éviter des erreurs si tu a par exemple 50 machines virtuelles !

Sinon, ce genre de switch virtuel est censé pouvoir se positionner au dessus d'une ferme d'hyperviseur Xen par exemple. La gestion des VLAN est donc importante car les domU sont connectés sur ce switch virtuel, dans le bon VLAN et la migration de cette machine d'un dom0 vers un autre est complètement transparente.

Donc, je ne pense pas que l'idée est d'éliminer le noyau mais d'avoir une couche au dessus permettant plus de souplesse.

Par exemple, pouvoir mettre une sonde NetFlow et ré-utiliser tous les outils que l'on a déjà pour analyser les flux, c'est bien. Le but est aussi un peu là, connecter les machines virtuels sur ce genre de switch comme si tout cela était vrai afin de ré-utiliser au maximum tous les outils existant.

J'ai un outil maison qui me dis sur quel switch est branché une machine. Je récupère tout cela par SNMP. Je ne sais pas faire cela avec les bridge linux alors que j'ai bon espoir que cela marche à terme que ce genre de switch.

Pour les fermes de calcul, plutôt que de charger des batch via un outil de type qsub (sge, pbs...), tu pourras (projet XCP si j'ai compris) charger ta machine virtuelle sur le cluster et ton calcul se fera dedans sur ton environnement ! Avec des fermes à 20000 coeurs, si tu n'as pas un outil pour gérer les connexions des machines virtuelles sur les différents noeuds, je pense que c'est vite l'enfer.

J'en dis un mot aussi en début de nouvelle.

J'ai cherché un comparatif entre les deux solutions mais je n'ai rien trouvé hier soir. Si tu as quelques chose, je suis preneur.