Sytoka Modon a écrit 4538 commentaires

Tu t'es planté de journal, c'est celui qui précède qui parle de nouveau.

C'est effectivement la génralisation du /etc/alternatives de debian.

Plutôt que /Program, je mettrais un /pkg

Cela a un défaut aussi, l'arborescence d'UNIX a été faite pour être mise sur des points de montage différents ayant des droits différents...

Les données de type /var/www, elles sont ou ?

Les log, ils se retrouvent ou ? Sous Windows, les programmes écrivent parfois dans leur dossier et c'est TRES pénible.

> L'idée de mettre un programme par répertoire est super, au
> contraire.

Oui, mais pour tout ce qui est partagée : bibliothèque, fontes des polices...

Finalement, sous Linux aussi, cela se simplifie car il n'y a plus de dossier /usr/X11/bin donc plus de sépcificité pour X11.

De même, les programmes qui en ont besoin ont un dossier sous /usr/lib a leur nom...

J'ai parlé pour debian que je connais mais je pense que les autres vont dans le même sens...

Au final, les deux approches convergent.

LabView pose même des problème en développement car les fichiers sont au format binaire et on n'a pas d'outil de 'diff' dessus. On perds donc une grande partie du suivis de projet que nous donne des outils comme svn.

Ok, je n'avais pas compris ce point la. C'est pas gagné encore Ipv6...

> iface xenbr0 inet static

Pourquoi montes-tu le pont (bridge) à la main ? Normalement sur une debian etch, il est crée automatiquement par les scritps de démarrage de Xen.

Sais-til aussi gérer les fenêtres flotantes ? wmii se débrouille pas trop mal mais a un problème tout de même a ce niveau car il n'est pas facile de gérer les différents plan des fenêtres flotantes (ni de les fermer).

Je sais que c'est bizarre comme question mais je n'utilise les fenêtres flotants que pour quelques applications mais qui me sont fondamentales, par exemple clusterssh qui 'ouvre en parallèle 50 fenêtres sur 50 machines à la fois. J'ai besoin de pouvoir voir les 50 fenêtres en même temps. Tant ion que wmii ne savent pas faire cela en dehors du mode flotant.

> L'objectif de parrot 6 est d'être comme comme une jvm qui saurait
> faire du système ?

Oui, Parrot est une JVM à registre spécialisé pour les langages de script donc à typage dynamique, ce qui n'est pas le cas de la JVM java et .Net il me semble.

Comme Parrot a son propre assembleur, tu peux écrire des couches basses au niveau de Parrot qui seront accessible depuis tous les langages de scripts.

C'est d'ailleurs ce qui va se passer je pense, une partie des couches basses sera écrit à terme en Parrot et pourra ainsi être mutualisé entre les langages. Mais bon, là je m'avance peut être un peu trop, je ne suit pas au jour le jour le développement de Perl6 et de Parrot.

> Est ce que cela veut dire que perl va proposer de fait une abstraction
> du système avec des concepts évolués de threading, de droit ... ?

C'est déjà un peu le cas pour Perl5 donc je pense que cela va être encore plus fait dans Perl6 car Perl6 prends bien plus en compte le parallèlisme d'après ce que j'ai compris. Ce serait d'ailleurs dommage aujourd'hui de faire un nouveau langage qui ne soit pas intrinsèquement parallèle.

> qui seront portés de système à système. Mais cela sera pas dans
> parrot non ?

A mon avis, voir ci-dessus, les couches basses seront petit à petit intégré dans Parrot. Même si ce ne sera pas dans Parrot dès le début, cela va se faire au fur et à mesure du développement à la fois de Perl6 et de la machine Parrot.

J'ai pas le souvenir d'avoir vu un truc en PHP qui n'existait pas déjà en Perl... Au moins jusqu'a la version 4 de PHP. A ma connaissance, toutes les bonnes idées qui ont été développées dans un langage X ou Y qui sont faisable avec un langage de type déclaratif ont été implémenté en Perl.

Par contre, ce qui est vrai, c'est que lorsque PHP a décollé chez les providers (parce ce c'était un Perl simplifié à l'époque et que cela devait leur faire moins peur), il était plus difficile d'avoir Perl sur ses pages web.

> Le truc c'est que PHP avait de net avantages par rapport aux
> concurrents : web dynamique, simple et libre/gratuit (par rapport à ce
> que se faisait à l'époque). Ces atouts combinés n'avaient pas
> d'équivalent et l'ont rendu populaire auprès des développeurs
> amateurs et des plateformes d'hébergement. On connait la

Pour avoir connu les début de PHP, à mon sens son succès tiens en deux mots : langage basic et easyphp sous Windows. Pour le programmeur Perl que j'était à l'époque, PHP n'avait aucun avantage, on croyais revenir à Perl 1 alors que l'on avait la puissance de Perl5 sous la main avec des classes déjà bien faites comme CGI.pm (pour l'époque) puis est venu assez vite DBI...

J'ai même eu des collègues qui ont bloqué et refusé le Perl et trouvaient génials le PHP du début. J'ai jamais vraiment compris pourquoi ?

Par contre, une chose est sure, easyphp sous Windows a bien aidé, je pense même que c'est la clef principale du succès de PHP.

> Il semblerait que ni PHP ni Ruby ni Python, out of the box ne
> permettent de batir des architectures scalables... Serait-ce peut être
> le moment de revoir les copies ?

Il suffit de revenir aux fondamentaux, c'est à dire au Perl qui a toujours su garder une bonne performance tout en évoluant ;-)

Il y a des 'framework' qui vont bien, par exemple Catalyst

http://catalyst.perl.org/

Une des questions que l'on pourrait se poser est : faut-il continuer à développer samba ? En effet, on pourrait mettre toute cette énergie dans NFSv4 et avoir un protocole ouvert avec une implémentation multi-plateforme, Windows compris.

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 ;-)