Sytoka Modon a écrit 4544 commentaires

Attention, la route n'est que dans un seul sens, tu peux très bien avoir des paquets qui prennent une route à l'aller et une autre au retour. Il ne suffit donc pas de mettre sur ton poste comme route par défaut le routeur, il faut s'assurer qu'en entrée, les paquets passent par ce même routeur.

Si tu veux être sur que les paquets passent par le routeur, il faut faire des VLAN et avoir des commutateurs administrable. Avec les VLAN, rajouter des routes sur les postes clients ne suffit pas pour chinter le routeur.

Tu remarqueras que j'ai cité ma source et n'est rien modifié...

Il n'empêche qu'au final, c'est nettement moins lisisble qu'un YAML car les paramêtres du système sont noyés dans du verbiage XML. Il y a beaucoup de personne ici qui aime beaucoup le Python et le YAML oblige à bien faire l'indentation comme en Python. Il faut avouer que dans ce cadre là, cela oblige à une formatage correct sinon cela ne marche pas. En YAML, les fichiers de conf doivent être lisible et éditable ligne à ligne.

web-app:
     servlet-name:  nom_servlet
     servlet-class:   classe_servlet

     servlet-mapping:
         servlet-name:  nom_servlet
         url-pattern:      motif

Le problème n'est pas dans le seul nom des balises, il est intrinsèque au langage. Voila un exemple d'un fichier de configuration d'un module Perl pris sur le CPAN : http://search.cpan.org/src/MSERGEANT/AxKit2-1.1/META.yml

# http://module-build.sourceforge.net/META-spec.html
#XXXXXXX This is a prototype!!!  It will change in the future!!! XXXXX#
name:         AxKit2
version:      1.1
version_from: lib/AxKit2.pm
installdirs:  site
requires:
    Danga::Socket:                 1.52
    LWP::UserAgent:                0
    Test::Builder::Module:         0.03
    XML::LibXML:                   1.59
    XML::LibXML::XPathContext:     0.07
    XML::LibXSLT:                  1.59

distribution_type: module
generated_by: ExtUtils::MakeMaker version 6.17

Je prends un truc écrit pour Java et Tomcat pris sur le web aléatoirement sur le site http://www.dailly.info/java/tomcat.php Cela me semble représentatif cependant de ce genre de fichier de configuration qui plus est dans un cas simple (car souvent, c'est bien plus lourd que cet exemple).

< !-- en tête (obligatoire pour définir le type du fichier) -->
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app> <!-- Balise début de fichier de configuration -->


<servlet-name>
nom_servlet <!-- Association d’un nom au servlet -->
</servlet-name>
<servlet-class>
classe_servlet <!-- Association de la classe correspondante -->
</servlet-class>


<servlet-mapping>
<servlet-name>
nom_servlet <!—Choix du servlet visé par le mapping -->
</servlet-name>
<url-pattern>
motif <!—Choix de la forme de l’adresse sur l’URL -->
</url-pattern>
</servlet-mapping>

</web-app><!-- Balise fin de fichier de configuration -->

Je laisse à chacun son propre jugement mais je pense personnellement que la première manière d'écrire est bien plus lisible. On sais que l'important dans ce genre de chose est la lisibilité.

A propos de la dépendance, je n'ai fait que répéter le post qui me précédait...

Je sais bien qu'un bon XML se compile avec ANT sans l'IDE. L'idée du post au dessus était de pouvoir ensuite modifier ce fichier pour le faire évoluer. Et là, il dis qu'il y a une dépendance probable sur l'IDE. Encore une fois, je ne fait que le répéter.

Sinon, si tu aimes les fichiers de conf en XML, tant mieux pour toi. J'avoue que j'ai horreur de voir un truc en XML dans mon /etc. Un fichier de conf doit rester lisible par l'Homme or le XML ne l'est pas dans la plupart des cas. D'ou ma tirade sur le YAML et le fichier de config des paquetages Perl sur le CPAN.

C'est un des soucis avec java d'avoir voulu mettre du XML un peu partout et pas toujours au bon endroit. Par exemple, dans les fichiers de conf de Tomcat et dans Ant ! Du coup, on se retrouve vite avec la dépendance sur l'IDE... Erreur de conception.

Perl a trouvé une voie que je trouve médiane en mettant ses fichiers de conf sous le format YAML. C'est facile pour la machine et c'est lisible par l'homme.

Enfin, on va avoir du mal à dévier le char d'assaut Java de sa trajectoire ;-)

/cydrive/d...

Non vraiment, ca marche mais c'est pas pour madame michu !

Si on veut un service qui tourne sous une autre identité, il faut bidouiller le /etc/passwd ! ou est l'intégration dans Windows ? Pourquoi cygwin ne récupère pas ses UID dans la base SAM ?

Bref, cygwin, cela marche mais je préfère mon xfig sous Linux ;-)

> Le libre ne propose pas, la personne constate, et prend ce qui lui
> convient.

C'est pour cela que j'utilise Linux, car j'ai besoin d'avoir xfig et que celui-ci ne tourne pas en natif sous Windows ;-)

Je ne suis pas spécialiste mais un des problèmes de la virtualisation aujourd'hui est que le matériel n'est pas prévu pour. Au niveau processeur, le changement de contexte coute cher (cela va s'améliorer) et à part le processeur, le reste n'a pas d'instruction de virtualisation. Du coup, si tu laisses un OS invité avoir accès au matériel via le BUS PCI, il est possible pour elle de prendre le contrôle de la machine physique !

Certes, la paravistualisation n'est pas la panacée mais il est /a priori/ plus difficile aujourd'hui de sortir d'un environnement paravirtualisé que virtualisé.

Dans l'avenir, on va aller vers un architecture matériel qui sera je l'espère virtualisable, mais par exemple, au niveau de la carte graphique, pour le moment, il n'y a rien à l'horizon.

Au niveau serveur, le système vserver s'améliore petit à petit et on va arriver au final à un modèle proche de Xen à mon avis.

Xen est vraiment taillé pour les serveurs. Alors oui sous debian, cela marche sans interface graphique et c'est tant mieux. Je n'ai pas X11 sur mes serveurs !

Ensuite vmware n'est pas libre...

Enfin, Xen est bien plus performant car on est en mode paravirtualisé et non virtualisé. Les OS invité ne passe pas par exemple par un BIOS. Il n'y a pas de changement de contexte au niveau du microprocessuers. /a priori/, c'est plus sécurisé d'après cet article :

http://taviso.decsystem.org/virtsec.pdf

En gros, si mes souvenirs sont bons, l'OS invité n'accède pas au matériel (le bus PCI n'est pas virtualisé) et les échanges entre l'OS invité et le dom0 sont limités à un petit nombre d'appel qui sont bien écrit sous Xen.

Sous debian, Xen s'installe et est opérationnel en quelques minutes. Cela marche super bien. J'ai en moyen 6 machines virtuelles par machines physiques. Le plus important, cela ne plante JAMAIS....

Il suffit d'estimer effectivement ce qu'un homme est capable de faire à la minute, par exemple max 20 cliques et de mettre cela dans iptables au niveau du parametre limit. J'ai ce genre de règle en permanence et aucune injection de règle à chaud et cela marche très bien.

Je met surtout cela sur un serveur ssh. Je n'autorise par exemple que 2 ou 3 nouvelles connections par minutes et du coup, je n'ai quasiment plus d'attaque sur ce port...

Oui mais si on prends un générateur de nombre aléatoire auquel on rajoute des pertubations du aux paramêtres internes de la machine, si l'ensemble est bien fait, on devrait être plus aléatoire que le générateur logiciel cablé dans la puce et peu prévisible puisqu'on a quand même la sécurité du générateur logiciel ?

C'est d'ailleurs depuis ce temps là que c'est la mode de coder comme un pied chez Micorsoft ;-)

J'ai du mal à comprendre pourquoi, dans un PC moderne, il n'y ai pas un générateur de nombre aléatoire matériel. Il y a tellement de paramêtre sur un PC que cela devrait être possible d'en faire un truc qui sort des nombres impévisibles...

Il manque aussi les machines des grands groupes pétroliers... Par exemple, Total a des calculateurs à faire rêver plus d'un chercheur. Mais pour des problèmes de communication, il ne veulent pas en parler.

> Et à l'IDRIS, tu peux faire tourner ton job sur 3000 processeurs
> pendant deux jours, parce qu'il te faut des résultats sur 3000
> processeurs, sans que personne ne râle?

Tu obtient a peu près ce que tu demandes, dans la limite de ce qui est possible de donner. Si tu ne demande rien, tu n'as rien... Avoir 100% de la machine pendant deux jours me semble tout à fait réaliste si ton projet et cohérent.

> D'abord, l'IDRIS n'a pas de machines dans le top500, à ma
> connaissance

Exact car la recherche publique française n'est pas la priorité de nos gouvernements actuels. Cela n'empêche que ce sont quand même des bonnes machines.

Je parlais de l'IDRIS mais il y a aussi les machines du CEA qui sont accessibles même si cela est plus difficile... Je connais moins ce que propose l'INRIA.

Dans les grosses fac, il y a aussi parfois des moyens communs qui sont loin d'être nul.

Sauf à travailler sur les performances d'un code utilisant plus de 1000 coeurs et ou MPI donne des signes de faiblesse, il y a de quoi jouer en recherche.

> Tu as accès à l'IDRIS, cool pour toi, mais ça ne change rien à la
> situation des japonais ou américains.

On parle ici de recherche publique. Mon tord a été de donner un exemple un peu franco francais. A ma connaissance, les exemples que tu prends sont parmi les plus mauvais car ce sont les pays ou les chercheurs ont accès à des machines bien plus puissantes qu'en France.

Il serait temps de faire quelques centres Europpéens de calcul sur le modèle de l'IDRIS afin que tout chercheur européen ait ses chances. Je ne pense pas que les politiques puissent prendre sur ce point une quelconque décision mondiale, donc restons à l'échelle européenne.

> Tu fais tourner quel type de jobs à l'IDRIS ? Il s'agit bien de
> recherche en informatique ?

Moi rien car il y a des administrateurs système à l'IDRIS qui font très bien leur boulot et qui n'ont pas besoin de moi. Les chercheurs de mon labo, oui ;-)

Encore une fois et comme le dis le post ci-dessus. Ercit ton projet de recherche et soumet le à l'évaluation. Tu n'auras aucune heure sur une quelconque machine de calcul tant que tu n'auras pas présenté le moindre dossier. Et c'est normal vu le cout de des machines et des ingénieurs qui passent pas mal d'énergie à essayer de les faire tourner au mieux.

> car leurs labos n'ont pas assez de sous pour leur payer les droits
> d'accès.

FAUX.

Mon labo a accès à l'IDRIS et à ma connaissance, cela ne coute RIEN. Enfin, pas vraiment... Il faut faire un dossier scientifique pour obtenir des heures qui tiennent la route et que celui-ci soit jugé correct par le comité de sélection.

Il ne vous reste donc qu'a construire un dossier bien ficelé.

Les clusters, c'est bien mais au niveau des 'belles' machines de type vectoriel ou SMP (Un OS pour toute la machine et de la mémoire partagé), il n'y a quasiment plus de machine. J'ai trouvé en début de liste

15 - HLRB-II - Altix 4700 1.6 GHz - SGI

30 - Earth-Simulator - NEC

En effet, en général, ces 'belles' machines ont une architecture mieux intégrée et donc les programmes parallèles ou vectoriels sont plus performant dessus.

Je me demande en pratique quel est l'efficacité des machines du TOP 500 car je doute qu'il y ai beaucoup de programes qui puissent tirer de la capacité totale d'une seule machine.

Il faudrait en parallèle du TOP 500 des machines faire un TOP 500 des programmes en terme de consommation de GFlops, voire rapporter cela à la capacité de la machine.

En effet, c'est très différent de faire tourner un programme sur 5000 coeurs que de faire tourner 100 programmes sur 50 coeurs. J'ai comme l'impression que ces grosses bécanes du TOP 500 sont surtout positionné sur le second cas d'utilisation.

Pour finir, j'espère que la nouvelle SX9 de NEC va bien marcher car sur le papier, elle semble impressionnante

http://www.geekzone.co.nz/content.asp?contentid=7458

Le rapport de puissance crête entre le premier et le 500ième est constant depuis des années et est quasiment égale à 100.

Au chose constante, en moyenne, la machine numéro 1 se retrouve 500ième 7 ans après.

Oui, c'est elle. D'ailleurs, c'est ainsi qu'elle a été connu ici.

Rien à voir mais Richard Cazenave (UMP) a été battu au dernière élection grace au retour d'Alain Carrignon qui a foutu le bordel et perdu lui-aussi l'élection ;-)

rsync utilise de manière transparente ssh si tu passes par le réseau donc il n'y a aucun soucis de flux avec ce logiciel.

Que l'INRIA a les moyens de le tester en grandeur nature sur un grosse machine ;-)

Il y a un problème avec les calculs sur les nombres flottants. Généralement, il y a des impasses de faites sur les cas particuliers qui font qu'un compilateurs va plus vite que l'autre.

J'avais lu quelques part que ifort ne respectait pas les règles 'IEEE Floating point exception' et que les respecter coutait très chère en temps de calcul.

Donc au niveau du bench annoncé, il faut voir ce qui est réellement calculé et dans quel condition.

D'après SGI, un programme OpenMP s'écroule avant 100 coeurs et un programme MPI s'écroule au dela de 1000 coeur en règle général et indépendanment du langage.

Ici le problème est d'arriver à écrire un programme très fortement parallèle qui ne passe pas son temps en communication. C'est donc plus un problème d'architecture matérielle et logicielle que de programmation pour commencer.

SGI propose d nouveau Rad-Hat ou Suse...Mais je suis d'accord, c'est un point de détail. Les debian n'ont plus ne tournent pas avec le noyau 'Linus'. L'important est qu'il est possible de reprendre le noyau Suse avec les optimisations SGI pour les remettre sur une autre distribution. Et cela n'a rien d'exceptionnel à faire puisque c'est ce que font les distributions entre-elles depuis longtemps.