Sytoka Modon a écrit 4551 commentaires

Si tu utilises le compilateur NAG, tu as une GC si tu veux en Fortran 95.

Pour les bibliothèques mathématiques en Fortran, tu peux regarder du coté de BLAS, LAPACK...

Question graphique, je ne les ai jamais fait dans Fortran mais à coté en Perl histoire de séparer les choses. Mais je serais surpris qu'il n'y ai pas un accès à PLPLOT depusi le Fortran.

Comme c'est du H264, je voulais être sur que cela soit lisible sous Linux avant de faire la nouvelle. Donc j'ai testé avec VLC qui est multi-plateforme.

Après, l'idée n'était pas non plus de faire tous les tests avec tous les lecteurs vidéo de toutes les distributions...

> dans le genre relou a configurer (modification des sources), on fait
> difficilement pire.

Disons que c'est bien adapté pour l'embarqué mais inutilisable sur le bureau d'un PC multi-utilisateur.

Donc la cible n'est à mon sens pas la même.

PS : un utilisateur de wmii

> Python et Ruby suivent un processus évolutif, le fait qu'ils n'aient pas
> besoin de tout chambouler pour s'améliorer est un signe de qualité.

C'est exactement ce que je disais à la phrase suivante de mon argumentation je te signale.

Je te fait aussi remarquer que mes programmes écrit en Perl-5.004 d'il y a 10 ans marche toujours dans la dernière version 5.10 donc question longévité, c'est pas mal aussi.

> Oui, et Fortran est resté archaïque et dépassé. Ce n'est peut-être
> pas la meilleure analogie possible pour défendre Perl6...

Tu ne connais rien à Fortran pour dire cela. Sais-tu que la dernière norme Fortran intègre un système objet ainsi que le parallélisme dans le langage... Fortran est un langage spécialisé pour traiter un certain type de problème avec un certain type de développeur et il fait cela très bien.

Si un langage n'a pas su évoluer, c'est à mon avis le C et à mon sens, cela va finir va poser des problèmes. Il devrait être possible de faire de l'objet avec héritage simple en C car cela ne change pas grand chose pour le compilateur et au niveau du système des types et au final, cela simplifie pas mal le code source.

> il semblerait que seule la communauté Perl s'intéresse réellement
> à Parrot...

C'est un peu vrai et c'est dommage. Cependant, Parrot ne tourne pas 'bien' depuis des années et avec une implémentation de Perl6 sur Parrot qui commence à marcher, je pense que l'intérêt des personnes de Python va revenir.

> Ce qui est plus "ambitieux" que Parrot qui, à ma connaissance,
> continue à être écrit en C.

Parrot n'est pas un langage de script mais une machine virtuelle dont l'objectif est de tourner sur un maximum de plateforme. Parrot, c'est la future couche basse d'un maximum de langage de script (dont Perl6), il me semble normal pour des questions de portabilités de linkage avec les bibliothèques de le mettre au plus proche du langage des OS d'aujourd'hui donc de l'écrire en C. Tu aurais voulu écrire Parrot dans quel langage ?

Par contre, le compilateur Perl6 devrait être écrit en Perl6 pour une bonne partie ;-)

Bref, tu ne veux pas voir que Perl6 et Parrot sont des "évênements de grande ampleur" pour le libre. Libre à toi.

> Au contraire de Python et Ruby, d'ailleurs

Je pense qu'aucun langage ne sort du chapeau de nos jours san tenir compte des autres. Python par exemple provient d'ABC, de même, Ruby est inspiré par Perl et Smalltalk. Je ne vois pas en quoi les dernières versions de Python et de Ruby sont ambitieuses d'ailleurs. Ce n'est pas forcément un mal. Une certaine stabilité est aussi une bonne chose.

Au niveau de Perl6, il y a quand même pas mal de changement par rapport à Perl5, changement qui sont nettement plus important que ce que l'on a l'habitude de voir dans un langage. Cela me rappelle personnellement le passage du Fortran 77 vers le Fortran 90. C'est quasiment un autre langage.

Quand à la conception de Perl6, elle a pris beaucoup de temps notament car elle a pris en compte les demandes de centaines de personnes sur des sujets très variés. Et l'idée de l'équipe de développement n'est justement pas de refaire un langage objet de script classique : Ruby est déjà là.

> Les évolutions de Perl6 n'ont rien de révolutionnaire, elles tendent
> juste péniblement à hisser Perl au niveau de langages plus modernes

Je pense que tu portes un regard plus que péjoratif sur Perl6 et n'a même pas regardé ce qu'il propose. D'ailleurs, cela se resent sur la fin de ton paragraphe.

> Reste à voir si cela donnera quelque chose de concret un jour... Ca
> fait pas mal de temps que c'est en gestation, Parrot.

Comme je l'ai dis, le projet est très ambitieux et va bien au dela de ce que l'on voit par ailleurs sur les langages que tu cites. Il y a eu peu de monde pour développer Parrot mais aujourd'hui, il est possible d'écrire dans un sous ensemble de Perl6 et Parrot marche.

En lancant les deux chantiers Perl6 et Parrot, la communauté Perl s'est ouverte aux autres langages de script pour développer une plateforme optimisée pour ces langages. Ces deux chantiers commencent à donner des résultats intéressants. C'est suffisament rare d'assister à une construction aussi complexe et aussi ouverte dans son mode de fonctionnement pour mériter mon plus grand respect.

> Après tout quitte à réapprendre un langage ....... pourquoi ne pas en
> utiliser un plus propre et qui existe maintenant?

Parce que Perl6 et Ruby n'ont pas la même ambition. Perl6 est un des projets libre les plus ambitieux puisqu'il s'agit de concevoir un langage de manière communautaire 'from scratch' et de baser tout cela sur une machine virtuelle à registre (Parrot) qui se veut universelle et orientée pour les langages de script.

Les évolutions de Ruby et de Python sont certes non négligeables mais elles n'ont pas cette ambition.

Au final, je ne sais pas si Perl6 sera ou non un succès. J'espère que Parrot sera une machine virtuelle sur laquelle on pourra faire tourner pas mal de langage. Au niveau de Perl6, le nombre de concept qu'il est possible d'utiliser est impressionant et c'est peut être son défaut. Le langage est peut être trop riche pour une grande partie des développeurs...

La version 5.10 est sortie le 18 décembre pour fêter les 20 ans du langage Perl. En effet, la version 1.0 a tout juste cet âge.

Merci à Larry Wall ainsi qu'à tout les contributeurs pour ce langage merveilleux.

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