Sytoka Modon a écrit 4546 commentaires

Il existe déjà et s'appelle YAML !

Ca marche très bien et il est très facile de mettre une structure d'arbre la dedans.

Pour ceux qui n'y crois pas et pense que dans deux ans, le YAML est mort, ils se trompent. Tous les paquetages perl du CPAN sont décrit par un fichier YAML qui décrit le contenu du paquet. A comparer avec les fichiers abscons des modules de Tomcat...

On voit vite les limites du XML pour faire des fichiers de configuration. Je suis persuadé qu'on mets moins de temps à faire un fichier YAML de config pour un paquetage Perl que faire le fichier XML du module applicatif Tomcat. D'autant plus que sur mes serveurs, il n'y a aucun outils graphique.

Sur une debian, il n'y a pas besoin de modifier pam pour prendre en compte l'identification ldap ! Il suffit en effet de modifier comme tu l'as fait le fichier /etc/nsswitch.conf et de configurer le fichier /etc/libnss-ldap.conf

Comme on est obliger de modifier ces fichiers pour que le systeme connaisse son identité (commande id), il est absolument inutile de rajouter une ligne ldap dans pam, ou si cela est nécessaire, merci de me dire pourquoi car j'ai 20 machines qui fonctionne parfaitement sans ! Bref, pam c'est bien mais ce n'est pas encore suffisant, ce nsswitch traine encore...

Au niveau d'apache, cela n'a rien a voir. Apache tourne sous son identité propre et il n'y a aucun besoin que l'identification sous apache ai un quelconque rapport avec celle du système. Les deux problèmes sont donc dissociés à 100%. A mon avis, tu as une erreur dans ta configuration ldap au niveau d'apache.

Bon courage

D'un autre coté, on peux aussi chiffrer avec des algorithmes assez léger en ressources comme bowfish. Par exemple

ssh -c blowfish

Sur un réseau local dont on est quasi-sur, chiffrer de la sorte évite de tout faire passer en clair ce qui peut tout de même être dangereux et offre une garantie en générale suffisante.

J'ai utilisé LTSP (version 3) pendant quelques temps. Ca marche plutôt bien mais, il ne fallait pas utiliser gnome ou kde. Trop lourd. Cela surcharge le serveur central inutilement.

J'avais fait une configuration aux petits oignons pour mes utilisateurs avec icewm et rox-filer. C'est moins beau mais tu peux alors facilement doubler ou tripler le nombre d'utilisateur sur le serveur central !

Un autre solution à LTSP consiste avec mettre un serveur XVNC sur le serveur central et à installer un client vnc sur les postes des utilisateurs. Cela permet d'éviter de rebooter. Cela n'a pas le même objectif non plus mais permet d'augmenter encore le taux d'utilisation du serveur central (en plus au niveau de la configuration du serveur X du serveur central, c'est quasiment la même chose).

Enfin, plutôt que d'utliser ssh -CX pour chiffrer les transactions, on pourrait aussi mettre freenx. Ca gère une bonne partie de la problèmatique (et ca s'appuie sur ssh). D'ailleurs, ce serait bien que freenx fusionne dans les projets xorg et ssh.

Non, ce n'est pas un projet de gestion de projet mais de gestion des collaborations. Au sein d'un projet, il est clair que l'on peux s'arranger.

Maintenant, essayes de mettre tout le CPAN dans un seul projet ! Ca explose. Le but d'un "namespace" est de permette à des projets différents de mutualiser du code source. c'est pour cela que l'approche java qui préconise de prendre les noms de domaine DNS a l'envers n'est pas bonne et que l'approche du CPAN de Perl est excelente. Elle permet de mutualiser un maximum le code des bibliothèques entre projet.

C'est pas ton Makefile, si bien fait soit-il, qui va te faire cela. Comme je le dis depuis le début, ce n'est pas un problème technique, c'est un problème sociologique. Il fait donc intervenir de multiples personnes. Si vous souhaitez que Lisaac marche, il faut tenir compte un minimum des problèmes sociologiques.

OK, je vais aller lire ton lien...

En voici un sorti de la documentation de Sather. Il est vrai qu'il vaut mieux comprendre un peu le système de type de Sather pour tout piger.

http://www.icsi.berkeley.edu/~sather/Documentation/EclecticT(...)

Par exemple, il faut savoir que l'héritage de code et d'interface sont dissociés en Sather. Lorsqu'on dis qu'une classe hérite d'une autre, elle n'hérite que de l'interface. L'héritage de code doit être explcité avec le mot clef "include".

Ca fait bizarre la première fois mais dans les fait, c'est pas du tout génant, c'est même mieux car très clair. Et maintenant, pas mal de langage rajoute la notion d'interface à la notion de classe (Eiffel compris) quand elle n'ajoute pas aussi l'inclusion de code ! Bref, la aussi, Sather en séparant les rôles a finalement simplifié et se montre au final plus souple.

Pour en revenir à la fin de ton POST, il parait qu'il n'est pas facile de faire du code portable entre compilateur Eiffel. Ca ne l'aide pas non plus. A cela s'ajoute qu'Eiffel ne gère pas les "namespace" et ce point là est très génant si on veut avoir une grosse bibliothèque "a la CPAN". Le C s'en sors très bien sans mais pour des raisons historiques.

IIl parait que Benoit Sonntag n'est pas chaud pour rajouter cette fonctionalité dans Lisaac. S'il est vrai que cela n'a aucun intérêt technique pour le compilateur, ca a un intérêt social énorme pour les développeurs.

> ça oblige à continuer avec les mauvais choix de design qui ont été
> faits au début. Et il ne faut pas se leurrer, on fait toujours des
> mauvais choix au début :)

Je ne suis pas d'accord. On fait effectivement des mauvais choix mais on fait aussi des bons choix à l'instant t qui s'avère être des mauvais choix à l'instant t+1. C'est normal, inévitable et même une bonne chose, cela signifie tout simplement que l'objet technique évolue et est vivant (cf Bruno Latour).

C'est donc dans la conception du langage, des bibliothèques... qu'il faut s'accorder des espaces de liberté et ne pas trop contraindre le langage, les bibliothèques... Sinon ceux-ci auront du mal à évoluer et seront donc condannés à une mort quasi-certaine.

C'est d'ailleurs ce que je critique un peu dans Eiffel, il est très beau mais trop contraint.

Meyer se fait parfois le chantre de la programmation objet, notament dans son bouquin. Il a cherché a faire un langage unifié et cohérent. Il passe beaucoup de temps a fusionné le concept de "thread" et celui d'objet dans scoop (toujours pas implémenté à ma connaissance) et il laisse un brèche ouverte avec le concept de covariance qui, tu es d'accord, peut rendre les programmes invalides !

Les personnes qui ont développés Sather ont montré que les exemples de Meyer était "bidon" et qu'on pouvait très bien les refaire en contravariant en utilisant la généricité. Je ne suis pas spécialiste des langages mais je n'aime pas le sacrifice qu'a fait Eiffel, ce trous dans le langage, surtout s'il y a une autre possibilité, qui elle n'a aucun trous !

Par ailleurs, il ne faut pas en faire un plat non plus. Le C++ n'a pas de variance du tout et des milliers d'applications réelles sont développés avec. Eiffel est un nain négligeable à coté, Sather étant lui même un nain à coté d'Eiffel.

Sather est malheureusement virtuellement mort aujourd'hui, l'équipe de recherche qui le développait aux états unis ayant vu ses crédits arrétés. Au moment de son arrêt, vers 1999 d'après mes souvenirs, l'environnement de développement était pas si mal (il y avait même une option de compilation pour activer la reflexivité).

Je me suis amusé un peu sur Eiffel vers 1998 puis j'avais essayé Sather. Il a lui aussi des défauts mais comparativement, quel bonheur. Le langage semble bien moins lourds ;-) Il est clair que pour celui qui débite du code Eiffel à longueur de journée, ce type d'argument n'est pas valable.

Si je parle de Sather ici, ce n'est pas pour changer Eiffel, la suppression de la covariance dans Eiffel reviendrait à refaire un autre langage. Mais justement l'INRIA avec Lisaac fait un nouveau langage et ils trainent sur ce forum. Mes quelques post de néophite ne sont que des messages subliminaux ;-)

Pour en revenir au compilateur Sather, il existe toujours et doit toujours marcher. Le paquet debian a été malheurement enlevé de l'archive. Je ne conseille à personne de développer un gros projet en Sather aujourd'hui. Cela n'empêche pas de voir en lui un petit frère d'Eiffel qui a trouvé un voie intéressante mais non finit.

Je suis assez d'accord avec toi avec les + et les manques. Je continue de penser que la contravariance est mieux qua la covariance, surtout qu'elle n'engendre aucun problème de typage. les personnes qui ont développé Sather l'ont bien montré.

Il manque aussi les itérators de Sather qui simplifie grandement l'arbre des classes.

Enfin, en plus de pouvoir rajouter des méthodes a des classes, il faudrait aussi pouvoir supertypé l'arbre des classes, c'est à dire introduire une nouvelle classe en plein milieu de l'arbre.

Un des problèmes d'Eiffel est que l'arbre des classes est trop rigide et trop imbriqué, du coup, c'est très difficile de le faire évoluer. Or, par définition, un langage se doit d'évoluer, il y a toujours quelques erreurs de conception.

> Ca ne t'empêche pas de le faire tourner sur une Debian si tu veux

Ca, je suis au courant. Ils ne valident que RHEL et Suse. Or la debian est super utilisé (évidement, on va tous dire que sa distribution est super utilisé mais il faut être aussi réaliste, la debian avec son développement communuatiare, indépendante... est incontournable, sauf pour les logiciels propriétaire !).

Il pourrait donc au moins faire l'effort pour la debian, surtout que la certification debian ne coute pas un centime contrairement a RHEL (enfin or cout de développemnt). Il suffit de mettre sur le site un paquet valable pour debian. C'est pas comme sous Windows ou il faut payer pour avoir le logo Microsoft Certified.

Bref, il ne se défonce quand meme pas trop....

> C'est d'ailleurs un sacré cirque pour s'assurer que ca tourne sur n
> version de Linux

Pourquoi ? Il suffit de compiler en statique et d'avoir une archive autonome... que les personnes installent où elles veulents, en général sous /opt

> frais de formation serait conséquent.

T'entend quoi par là ? La grande majorité des écoles d'ingénieur en mécanique sont des écoles publiques. Les frais d'inscription sont heureusement encore faible (je dis encore car avec leur réforme des universités qu'ils ont mis de coté mais qu'ils gardent au cas où, ca risque de faire mal).

Sinon, pour Catia, c'est un problème de CV. Tu places 10 fois mieux tes étudiants en stage s'ils ont fait du Catia, car Catia est largement numéro 1.

Pour les coùts, Dassault ou IBM sont capables de te donner en taxe d'apprentissage ce qu'ils te demandent en licence... ce que ne sont pas toujours capable de faire les concucrrents payant. Bilan : il faudrait être fou pour choisir autre chose !

Pour l'avoir enfin essayer avec XP sous Linux+qemu+kernelkqemu..., je peux dire que XP est BEAUCOUP plus reactif avec cette nouvelle version. Je ne vois quasiment pas la différence avec un Windows natif.

Tout cela est bien subjectif mais heureusement, il n'y pas pas que les chiffres pour nous guider.

Et il ne prends pas les paramètres du proxy dans la config d'IE ?

C'est FAUX !

Je connais quelqu'un qui a vu tourner Catia sous Linux ! De toute manière, tout ca sont des mensonges, ces logiciels ayant été conçu sous UNIX, le portage sous Linux devrait être relativement simple, surtout qu'OpenGL tourne maintenant relativement bien.

Catia (Dassault) est marié à IBM depuis le début. IBM doit protéger ses stations. Si Catia, comme SolidWorks tourne sous Linux, c'est la fin des stations scientifiques sous Windows ainsi que sous les autres UNIX. En plus Dassault a une politique plus proche de Microsoft, exploitant au maximum son monopole, que de l'open source. Même dans les projets RNTL (Réseau National des Technologies Logiciels), il ne joue le jeu de l'open source que du bout des doigts, contraint et forcés.

Il faut aussi savoir que pas mal des ces logiciels tournent sous Windows avec Exceed, qui est un serveur X non libre ! Alors, ne leur laissez pas dire que c'est optimisé pour la plateforme Windows ! Bref, ils n'ont aucune volonté d'ouverture.

Le seul qui fait des effort est ProE qui d'ailleurs marche très bien.

Ces histoires de logiciels scientifiques ne tournant pas sous Linux n'ont aucune raison d'être aujourd'hui autre que politique.

Pour ceux que ca intéresse, Matlab, Comsol (FemLab), Fluent, Ansys tourne très bien sous Linux. Les deux premiers ont même des versions complètement native sous AMD64 (pour fluent, il y a des bouts en 64b et d'autre en 32b, pour Ansys, je n'en sais rien).

T'as raison, j'avais oublié ma règle cfengine qui me met automatiquement nvi ou wim par defaut ;-)

Et comment tu mets à jour ta machine ?

Sachant qu'une machine qui n'est pas à jour est une machine morte, surtout sous Windows, IE est indispensable.

Et lorsque tu as un GROS logiciel de type Catia, il serait idiot de la part de Dassault de le livrer sans toutes les librairies (Non, ne rêvez pas, Catia n'existe pas en version Linux sauf chez Dassault).

Pour être complet, il y a aussi : vym == View Your Mind

http://www.insilmaril.de/vym/

Un des problèmes est que Fabrice n'est pas très clair. A une époque, il parlait d'une certaine somme d'argent pour libérer le code. Combien ?

Si on ne sais pas la somme qu'il souhaite, ni le valeur du compteur à un instant t, qui irait donner de l'argent. Le module se développant, la somme souhaité augmente...

Bref, on n'a aucun moyen de savoir où on en est, et ce point là est effectivement génant.

Surtout que j'ai lu hier que le module libre qvm86 pouvait aller aussi vite que l'ancien module kqemu dans certain cas, il est donc un peu bête que ce module ne soit pas intégré en standard dans qemu. On arrive à la limite de la logique du semi-libre où un module non libre est privilégié devant un module libre, du seul fait du principal (et génial) développeur.

Personnellement, je récupère qemu sur

http://www.dad-answers.com/qemu/

Il y a une image réalisée quasiment toutes les nuits. Par exemple

qemu-snapshot-2006-03-30_23.tar.bz2

De même qu'il y a des bouts de boch dans qemu (au niveau du driver de la carte reseau et de la carte vga si mes souvenirs sont bons). Il serait idiot de ne pas reprendre du code qui marche bien et de ne pas en profiter pour l'améliorer au passage.

Je ne sais pas comment Fabrice Bellard à mis en place la virtualisation dans kqemu mais je ne serais pas étonné qu'il se soit inspiré des idées implémentées dans Xen.

Sauf que je crois que c'est nvi l'editeur par défaut sous debian. En effet, nvi est plus proche des bogues de l'original que vim. Mais j'ai vu passer sur une liste debian qu'ils envisagent de remplacer nvi par vim-tiny.

Je ne parle pas d'une debian où tu installes tout. Je parle d'une debian minimale. Si tu installes vim, il prend la place de nvi par défaut car il a une priorité plus élevée (voir le système des update-alternative de debian pour cela).

Qemu et Xen n'ont aucun rapport en tant que projet.

Qemu était (et est toujours) un émulateur, au même titre que boch. Qemu tourne en espace utilisateur (c'est une application standard). Cependant, depuis quelque temps, il y a un module noyau, kqemu, qui permet d'accélérer le code qui tourne en espace utilisateur dans la machine virtuelle (il y en a même un autre qvm86 si mes souvenirs sont bons qui est libre mais moins performant). Conclusion, jusqu'a il y a peu, avec qemu+kqemu, on lancait une machine virtuelle et tout le code des applications dans la machine virtuelle était directement envoyé au CPU de la machine réelle, seul le code du noyau virtuel était émulé (donc aussi tous les appels systèmes que l'on trouve dans une application).

Xen virtualise un système. Ce n'est pas un émulateur. Donc avec Xen, on lance des machines virtuelles et Xen se charge de la répartition des ressources physiques, notament du CPU, pour chacune des machines virtuelles. Dans Xen, le code noyau ainsi que les applications des machines virtuelles sont directement exécutés par le CPU de la machine réelle. En pratique, avec Xen, les applications tournent quasiment aussi vite dans une machine virtuelle que si elles étaient directement exécutés sur une machine normale. Au niveau des serveurs, c'est très intéressant, il vaut bien mieux virtualiser. C'est bien plus souple dans ces conditions.

Maintenant, avec la dernière version de kqemu, on peux faire de la virtualisation complète, même du code noyau ! Donc qemu marche un peu sur les plate-bande de Xen. D'où ma remarque finale et le lien entre les deux projets.

Cependant, il ne faut pas se tromper. En production, avec des machines virtuelles, il faut être capable d'attribuer des ressources aux différentes machines, de superviser en temps réel. Je ne suis pas sur que les deux projets soit comparable de ce point de vue là aujourd'hui.

Je vois que tu limites à la plateforme windows pour ton développement. Tu peux donc prendre des modules Win32:: de perl. Par exemple les Win32::Gui qui utilisent la couche graphique native de Windows (jamais testé, je préfère personnellement perl/tk ou perl/gtk+glade).

Pour ta connection avec Excel via COM, tu as ton bonheur avec Win32::OLE. Ca parle même d'Excel sur la documentation du module OLE (j'avoue que je n'ai pas été plus loin).

http://search.cpan.org/~jdb/libwin32-0.26/OLE/lib/Win32/OLE.(...)