Sytoka Modon a écrit 4573 commentaires

Il existe par exemple aap, c'est écrit en Python et ca utilise une syntaxe voisine du makefile.

http://www.a-a-p.org/

Je ne dis pas que je suis fanat non plus ;-) La syntaxe est plus humaine mais à mes derniers essais, il faut écrire des extensions en Python si on souhaite l'étendre. Or je ne suis pas un fan de Python par gout personnel.

Le fichier 'rules' des paquets debian est un exemple de Makefile travaillé avec des extensions par scripts. On se retrouve avec un Makefile relativement simple au bout du compte.

Mais bon, il y a une mode XML...

Sinon, je n'ai pas fait de namespace en YAML car il est vrai que je l'utilise dans des cas assez simple. Mais tout structure arborescente peux s'écrire en YAML tout comme en XML. Donc il est possible en théorie de faire un outils 'yml2xml' et réciproquement.

Avec le bout d'exemple d'un post ci-dessus, c'est typique des nouveaux outils dérivée d'ANT. Du XML partout. C'est super pour les IDE mais horrible pour l'homme.

Honnêtement, un bon vieux Makefile peut être bien plus lisible. Le plus gros défaut du Makefile à mon avis, c'est la tabulation en début des lignes de commande. Je ne comprends pas qu'on ne puisse dire que les lignes commançant par '->' soient équivalentes aux lignes commençant par une tabulation.

L'inconvénient des outils intégrés autour du XML, à part la mauvaise lisibilité, est le manque de souplesse. Ce qui est génial dans un Makefile est le mélange de deux langages dont l'un est très souple et peut être changé (variable SHELL). Rien n'empêche de développer des scripts 'a la Ant' qui rendrait la compilation pour certains langages plus claire que dans un Makefile actuel. Il n'y a pas besoin de se mouler dans un environnement de type Java comme dans Maven ou Ant.

Enfin, j'en remet une couche sur le YAML. Faites du YAML pour vos fichiers de données (configurations ou résultats) qui doivent pouvoir être ouvert par un éditeur et non du XML ;-).

Et pourquoi pas au format YAML. Personnellement, le XML me "gonfle" lorsqu'il s'agit de faire des fichiers de configuration. Avec le YAML, on a quasiment la même chose, mais avec une orientation humaine...

A ma connaissance, Catia tourne sous Linux chez Dassault mais il ne le distribue pas. Pourquoi ?

Je comprenais leur position du temps où il n'était pas facile d'avoir une accélération 3D correcte. Aujourd'hui, c'est possible d'avoir de l'opengl performant au prix de driver non libre. Mais cela, je pense que Dassault n'en a cure...

> Pourquoi pas un qemu ?

La carte graphique n'est pas accélére opengl sous qemu. Ca me parait donc pas intéressant pour Catia.

Quelqu'un sais si la version debian de xorg est compilée avec le support XMX permettant le multiplexage ?

http://www.cs.brown.edu/software/xmx/

Nous sommes d'accord. L'INRIA ne semble pas réellement motivé par l'utilisation de son langage...

Que l'équipe de recherche ne veuille pas se charger de ça, je le comprends fort bien. C'est pour cela que j'invoque l'étage au dessus.

Si l'on veut faire du transfert, il faut mettre quelques moyens humains et matériels. Ce n'est pas forcément une tache à rajouter encore aux chercheurs (on les encombre déjà bien assez avec de la paperasse sans intérêt).

Je ne dis pas que c'est trivial. Mais j'évoque l'INRIA, pas une simple association de quartier. Je pense qu'un EPST ayant un forte consonnance informatique est capable de mener ce genre de projet, sinon je trouve cela inquiétant.

> Ça existe déjà, ça s'appelle The Caml Hump

Désolé mais ca n'a rien à voir. Sur le CTAN et le CPAN, il y a TOUS les sources. Ce ne sont pas simplement des bases de données de liens.

Avec un système centralisé, tu donnes tes sources à la communauté. Dans le cas "The Caml Hump", tu acceptes que la communauté vienne chez toi. Il t'es facile ensuite de supprimer cet accès. Ce n'est pas un système pérenne.

Personnellement, je ne comprends pas qu'avec ses moyens, l'INRIA ne mette pas en place un "Comprehensive Objective Caml Archive Network", à la manière de Perl et de TeX.

C'est personnellement un de mes principals frein à son utilisation. Allez chercher ici ou là des paquets est franchement ennuyeux et peu fiable dans le temps.

Une archive centralisé permet d'avoir une dynamique communautaire forte. Je ne dis pas que ça marchera mais que serait Perl et TeX sans le CPAN et le CTAN aujourd'hui. A mon avis, peu de chose.

Je ne suis pas sur qu'aujourd'hui, OCaml ai envie de jouer dans la cour des grands...

OK, c'est bon, vous m'avez convaincu. Je vais me lancer dans le test.

Mais comme disais l'un des posts, c'est dommage de ne pas avoir une authentification classique comme ssh.

Quelqu'un a t'il deja deploye freenx avec 400 utilisateurs ?

Je n'ai jamais essaye nx, est ce vraiment moins lourd en charge reseau que la solution ssh avec compression

ssh -CX toto@computer

Normalement, comprimer le flux ssh devrait avoir a peu pres le meme effet que nx ?

Personnellement, j'utilise les scripts de Mike Rubel à peine modifié. C'est du bash tout simple avec des commandes de base.

http://www.mikerubel.org/computers/rsync_snapshots/

De ces scripts sont sortis tout un tas d'outils plus ou moins évolués comme baclkupppc si je ne me tompe.

L'idéal est aussi de faire une partition LVM afin de lancer une partition lvm snapshot avant de lancer le script de sauvagarde. Ainsi, on est sur de ne pas avoir de modification des fichiers lors de la sauvegarde.

J'ai vu une autre méthode qui paraissait intéressante utilisant le démon fam pour connaître les fichiers modifiés et les archiver à chaud. Malheureusement, je n'ai pas encore testé et je ne connais pas la robustesse de ce procédé.

pwc est un module noyau pour controler un camera Phillips (donc Logitech...).

Il y a avait deux modules pwc et pwcx. L'un des deux n'etait pas libre. Le développeur a jeté l'éponge il y a un an environ. Depuis, ca vient ca va.

> Je suis en train de me mettre à Ion, et de le découvrir, assez
> difficilement d'ailleurs.

J'ai essayé aussi mais ca ne me convenait pas. Depuis je suis sous pwm, simple, léger, controlable au clavier mais plus souple à mon avis.

C'est l'original !

peckwm, c'est un dérivé de pwm.

pwm, c'est minimaliste, un peu comme ion. Pas d'icone, pas de barre de menu... Des fenêtres que l'on peut mettre en onglet, c'est tout.

Mais il est très facile à configurer. Et pour les lancements rapide d'application, je lance "apwal" via un controle clavier. Très bien ce petit apwal.

Effectivement, ca vient de pwm je crois. D'ailleurs, depuis que je suis sous pwm, je ne lui trouve que du bien ;-)

C'est possible aussi avec "xvidcap". Ca marche très bien aussi. Cela génère un film au format AVI ou MPEG, on peut même le mettre ensuite sur un serveur de streaming !

L'avantage et ou l'inconvénient, c'est que c'est du natif XWindow.

Ben oui, pourquoi pas LaTeX ! Je fais la semaine prochaine une présentation de Linux avec ca.

Idée : pdflatex + beamer te génère du pdf, tu places tout ca sur un site web apache ensuite.

Pour info, beamer est un super paquetage LaTeX pour faire des présentations. Il est compatible ps et pdf, ce que ne l'était pas prosper.

Le premier jeu de transparent à mettre au point peu rebuter. Ensuite, ca va presque trop vite à faire...

Ca fait trois ans que j'en fait ! Je regrette juste une chose, ca ne marche pas avec apache2 et ca n'a pas mal de bouger beaucoup ces derniers temps.

Sinon, il faut un peu de temps pour rentrer dans AxKit mais après c'est formidable. Il est très facile de faire des formulaires. Je me suis fait par exemple ma propre extension qui charge le code perl d'une page html si un fichier du même nom existe (dans une arborescence parallèle (faut pas être fou)). Ca parait bête mais la complète dissociation code Perl / code HTML permet de ré-utiliser le code source bien plus facilement.

Il y a un peu trop de variables globales à mon humble avis dans AxKit et c'est parfois pas assez objet. Par exemple, le coup des formulaires, l'idéal aurait été de définir une classe comme nom du formulaire et de simplement connecter les méthodes de la classe au champ du formulaire... Je vais peut être le faire, ca me simplifierai grandement mon code.

Oui ! Axkit.

http://www.axkit.org/

C'est un environnement XML en Perl "à la cocoon" (Java). Tu peux mélanger le code Perl et le xhtml mais en général, il y a une complète séparation des deux. Même avec du code Perl embarqué, le xml reste valide !

Dans un reseau formé de machine Linux, nfs est pour le moment plus performant que samba. Par ailleurs, avec l'automounter, c'est une merveille.

Je suis d'accord avec un un post ci-dessus. Au niveau des droits, il manque quelques reglages ici ou là. Par exemple, le nombre de groupe par personne est limité (par nfs notament) et il n'est pas possible de faire de l'imbrication de groupe. Dans la plupart des cas, une meilheure gestion des groupes suffirait.

Enfin, il faut être honnête, c'est pas franchement utilisable pour le moment.

- nfs ne les supporte pas (en tout cas chez moi)

- tar non plus (star oui)

- rsync n'en tient pas compte (unison nnon plus)

- ...

Bref, ca marche effectivement en local sur une machine ;-)

J'ai testé Multivament il y a quelques mois. C'est une boite à outils pour manipuler les pdf, dv et html. Il y a un visionneuse multi format permettant les annotations.

http://multivalent.sourceforge.net/

C'est en Java et ca plantait assez souvent sur mon PC. Cependant, ce projet me parait à suivre...

Je suis d'accord avec toi. J'avais mis cette phrase pour conclure vite fait ;-)

De plus, OCaml et Perl ne joue pas dans la même cour du tout... J'ai toujours entendus beaucoup de bien d'OCaml, et j'utilise l'excelent programme unison, mais je n'ai quand même pas l'impression qu'il décolle.

J'entend aussi beaucoup de bien d'Haskell. Quelqu'un connais les + et les - des deux. Je crois que ce sont tous les deux des enfants de ML ?

Enfin, contrairement à l'un des post ci-dessus, vu l'état de l'INRIA (et du CNRS et de toutes les EPST...), je n'ai pas absolument confiance dans sa pérennité. Si l'INRIA décidait d'arréter, cela gènerait'il vraiment beaucoup de monde ?

Qu'est ce qui motive l'INRIA dans OCaml ?